Como podemos definir tal técnica? É uma receita de bolo? Podemos dizer que é mais uma “bala de prata”? Ou um constante desafio, dependendo do contexto? Podemos dizer que o mais interessante é sua característica colaborativa que propicia uma discussão entre a equipe sobre as funcionalidades, incluindo uma ótica da experiência de uso dos usuários. Dificilmente destacaremos apenas vantagens de uma metodologia, embora em um cenário com premissas favoráveis, notam-se muitas vantagens em sua adoção.
Vale salientar alguns detalhes que se destacam em sua adoção. A técnica ajuda a equipe a escolher um conjunto de funcionalidades que sejam imediatamente valiosas do ponto de vista do negócio e ao mesmo tempo úteis para os usuários, desde que a equipe seja multidisciplinar ou tenha papéis bem definidos com poder para tomada de decisão. Ajudando na priorização e no planejamento de releases, obtemos detalhes sobre o usuário, freqüência de uso da funcionalidade e valor que ela tem para o negócio.
Os dois últimos itens acima merecem atenção especial, visto que, para projetos que temos uma prévia experiência sobre o assunto, seja ela fruto do conhecimento da equipe ou mesmo de outros projetos presentes no mercado, tais variáveis são mais simples de mensurar. Do contrário, em um projeto inovador, uma vez que o modelo ainda não está estável o suficiente, não existe dentro da equipe um consenso em relação a tais variáveis, tornando sua avaliação complexa e passível de outros métodos de análise, como pesquisas de campo, questionários, entre outros.
Ao realizar as etapas, algumas delas acarretaram discussões acaloradas. Ao realizar descrição das tarefas realizadas pelo usuário, ao adicionar informações quanto à freqüência de uso, a cada uma das tarefas das user stories, e na definição de valor para o negócio de cada user story, sendo essa de fundamental importância a participação de uma pessoa que tenha mais visão de retorno de investimento do sistema. Vale lembrar que toda equipe (e os stakeholders) podem participar destas etapas, o que naturalmente em alguns cenários torna o processo um pouco complicado de se chegar a um consenso, pois os interessados podem convergir o desenvolvimento de suas funcionalidades primeiro e sem critérios, o que necessariamente requer certa intervenção.
A idéia é contar uma história de como o sistema funciona, ajustando os cartões por criticidade verticalmente seguidos pela freqüência de uso horizontalmente, o que nos da uma visão muito clara e compartilhada do sistema como um todo, alinhando expectativas e idéias entre a equipe, afinal nesse momento no nosso mapa, sabemos as funcionalidades que não poderiam ficar de fora do release, principalmente quando estas representavam uma tarefa que fazia parte de um fluxo de uma atividade importante para os usuários.
Na definição de release o mais importante neste momento é a percepção de que todos compreendem melhor o produto que será desenvolvido. Esta visão compartilhada ajudará nas etapas posteriores de desenvolvimento do produto, quando novas idéias de funcionalidades apareceram e novos releases precisaram ser replanejados.
E finalmente e não menos importante tal técnica em sintonia com a abordagem ágil, ajuda a evitar o desenvolvimento de funcionalidades inúteis, e a manter a simplicidade da interface com o usuário. Como podemos perceber, a técnica oferece recursos para facilitar processos em metodologias ágeis, se fazendo presente e varias etapas destes processos. Mas não posso deixar de questionar: seria valido adotá-la em um processo tradicional? Seria possível usá-la isoladamente de qualquer abordagem? Creio que sim, e de forma empírica, aprender a lidar com as implicações que estariam por vir. Mas esta questão vale outra discussão!
Túlio César Gaio
Nenhum comentário:
Postar um comentário