Nota prévia: Muito dos conceitos aqui descritos baseiam-se num livro muito interessante escrito por Mike Cohn e editado pela Addisson-Wesley com o título "User Stories Applied - for Agile Software Development". Os conceitos não são originais, mas este livro faz um muito bom trabalho na sua descrição.
Já vimos como as User Stories podem funcionar com a "peça de Lego" a partir da qual o cliente pode especificar as funcionalidades que pretende para o sistema. Mas as suas virtudes não se ficam por aqui, dado que também são uma óptima ferramenta para as actividades de planeamento. Comecemos por uma tarefa basilar: estimativas.
As User Stories, dado o facto de descreverem um pequeno pedaço de funcionalidade (com valor para o negócio), devem poder ser implementadas num espaço de 1 a 5 cinco dias ideais. Um dia ideal é um dia em que trabalhamos todo o tempo na implementação de uma história. Como é natural, raramente temos esta oportunidade, mas usar dias ideiais simplifica o processo. Como as histórias têm uma curta duração, torna-se mais difícil, mas não impossível, de fazer erros muito grandes de estimativas. É de realçar que o objectivo não é realizar estimativas perfeitas, até porque isso é impossível. O objectivo é termos algo para trabalhar. Os acertos e o controlo do andamento do projecto faz-se de outras formas.
Vejamos então como estimar a duração de uma história.
Estimar como equipa
Como em tudo o que é metodologia ágil, também o processo de estimação deve ser feito pela equipa e não individualmente. Note-se que não tem de ser necessariamente toda a equipa, mas o cliente e vários elementos da equipa técnica devem estar presentes. Por um lado, estimar em equipa permite obter mais opiniões e esclarecer mais dúvidas sobre as histórias. Por outro, ajuda a criar espírito de equipa e de trabalho conjunto. É necessário sentir que todos remam para o mesmo lado, todos têm a sua quota-parte de responsabilidades. Mentes iluminadas (arquitectos...) que definem estimativas para outros cumprirem não é boa ideia a este nível.
Como estimar
O processo começar com a equipa técnica a fazer todas as perguntas que considere necessárias ao cliente, de modo a poder realizar estimativas o mais sólidas possíveis (o que não quer dizer correctas) sobre uma dada história. Note-se que não deve ser o cliente a realizar estimativas, mas a equipa técnica. Uma vez esclarecidas as dúvidas, inicia-se um curto processo iterativo. Primeiro, cada elemento da equipa técnica escreve num papel a sua estimativa, sendo muito importante que ninguém divulgue a sua estimativa antes de todos terem terminado. Em segundo lugar, todos indicam a sua estimativa. O mais natural é que existam estimativas díspares, logo o terceiro passo passa por cada um justificar as suas estimativas. Finalmente, tudo volta ao primeiro ponto. Ao fim de duas ou três iterações, as estimativas tendem a coincidir.
Triangulação
Ao fim de umas quantas histórias, começa a tornar-se possível utilizar uma técnica auxiliar, a triangulação. A triangulação é muito simples. Imaginemos que temos uma história que leva 2 dias ideais a concretizar e outra 4 dias ideais. Ao considerar uma terceira história, podemos balizá-la, comparando-a com as estimativas das outras duas histórias. Por exemplo, se estimarmos 3 dias ideais, então ela deve exigir mais esforço do que a primeira história e menos do que a segunda.
Como podem ver, o processo é simples e muito intuitivo. O processo de estimação de histórias funciona como a base para a definição do planeamento do projecto, tanto para iterações como para releases... Mas isso é tema para outros posts...
Posted
30-1-2006 23:02
por
João Hugo Miranda