Em projetos de software tradicionais, (leia-se não ágeis), geralmente fazer estimativa é algo muito chato, e que provavelmente será feito por apenas uma pessoa, que na maioria das vezes essa pessoa é o gerente de projeto, ou o líder da equipe, que utiliza métodos tradicionais para medir uma atividade com análise de ponto de função, ou por linhas de código, etc... mas acontece que quase sempre essa pessoa não conhece a fundo o negócio e as dificuldades técnicas de se implementar uma certa funcionalidade.
O que acaba gerando problemas no decorrer do projeto, pelo fato do analista de negócio (quando tem) não ter previsto uma funcionalidade adicional, ou uma regra de negócio imprescindível para o negócio.
Nesta altura de campeonato, quanto este tipo de situação acontece, geralmente o projeto já esta em um estágio avançado no desenvolvimento, e ATRASADO.. o cliente está puto,,, e sempre quem acaba levando a culpa é o incompetente do desenvolvedor.
Se você já se sentiu familiarizado com este triste relato, pois bem, não fique triste, pois isto já aconteceu comigo e acontece com milhares de pessoas nos dias atuais...
Pois bem, existe solução para este problema?
Sim, existe, se olharmos para alguns dos príncipios ágeis, conforme segue:
"Business people and developers must work together daily throughout the project. "
Traduzindo, quer dizer algo como "Analistas de negócio e desenvolvedores devem trabalhar juntos DIARIAMENTE no decorrer do projeto".
"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. "
Traduzindo este também,
“O método mais eficiente e efetivo de obter informação para o time de desenvolvimento é na conversa cara-a-cara."
"Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. "
E por último..
“Mudanças de requisitos são bem vindas, mesmo em um estágio avançado no desenvolvimento. Processos ágeis alinham as mudanças para vantagem competitiva do cliente."
Uma estimativa bem feita durante a fase inicial do projeto, reduz muito as chances de você ter dores de cabeça no futuro.
Ok, você está se perguntando, "Mas isto não respondeu a pergunta !!!", como eu posso melhorar as estimativas no inicio de um projeto ou de uma nova iteração ???
Existe um método ágil para estimativas, chamada de Planning Poker, esse método foi descrito inicialmente por James Grenning em 2002 e depois popularizado por
Mike Cohn no seu livro
Agile Estimating and Planning,, essa técnica é muito conhecido em XP.
Para "jogar" o Planning Poker precisamos apenas de uma lista de backlog e um baralho. E o baralho, geralmente composto por cartas que possuem uma seqüência fibonaci ou similar (0, ½, 1, 2, 3, 5, 8, 13, 21, 34, 50, 80 ,100, ?) e uma carta opcional com um sinal de interrogação.
Por que utilizar esta seqüência, e não um conjunto de números naturais (0,1,2,3,4,5,6,7,etc...) ?
Boa pergunta, mas vou responder com outra pergunta, você consegue distinguir o número 13 do número 14? Fica mais fácil você ter uma noção de separação de complexidade, quando você trabalha com números em uma seqüência fibonaci, imagine que para cada tarefa, quando você for dar o seu peso, pense que uma tarefa com peso 2, é 2 vezes mais difícil que uma tarefa com peso 1.
Voltando ao PP, para jogar, cada participante, geralmente os membros da equipe de desenvolvimento (programadores, testers, designers, etc..) devem possuir uma seqüência de cartas, e cada funcionalidade da lista de backlog irá corresponder a uma rodada do jogo entre a equipe. Os membros não podem conhecer as cartas uns dos outros até início da rodada.
Para facilitar o entendimento, vou demonstrar um exemplo real, imagine que temos uma lista de backlog conforme a tabela abaixo, apresentada pelo Product Owner, e o mesmo dá explicações relacionadas a cada um dos itens, onde todos os membros discutem para chegar a um entendimento do problema.
Na nossa ambiente, vamo imaginar que temos 5 membros, 3 desenvolvedores (Carlão, Maria, Zeca), um tester (Júlio) e uma designer (Rita) e o Project Manager / SM (Walter). O Product Owner neste momento, já deu uma visão dos itens de backlog e explicou a necessidade do negócio, tirou algumas dúvidas e foi embora..
É importante frizar que os membros do time devem estimar todo o trabalho relacionado ao item do backlog, e não apenas a sua parte especifica.
Antes de iniciar a primeira rodada, o SM inicia a discussão:
Walter (SM): Pessoal, o que vocês acharam dessa user story (100)?, o usuário quer um repositório para armazenas os documentos operacionais da empresa assim, assim, assado, então, vamos votar:
Então, neste momento cada membro da equipe, pega uma carta que acha que corresponde com os Story points e depois que todos escolheram suas cartas, tem inicio a rodada. No nosso exemplo, o resultado foi esse:
Rodada 1:
Perceba que na primeira rodada, tivemos pessoas que votaram 50 (Maria, Julio), duas que votaram 80 (Zeca, Rita), um 21 (Carlão) e um 34 (Walter), neste momento o mediador (geralmente o Scrum Master) questiona os resultados.
Walter (SM): Peraí gente, vamos discutir, esta tendo muita divergência, Rita e Zeca, porque vocês acham que essa atividade tem um peso 80?
Rita (Designer): É por que, fico imaginando o tamanho dessa aplicação, já é uma bagunça hoje a forma que é organizado os documentos, imagina só o trabalho de reclassificar tudo, montar um repositório, modelagem, etc... e chora.. ..
Walter (SM): Huum entendi, e você Zeca.
Zeca (Dev): Concordo com a Maria, imagina a quantidade de trabalho.. e chora mais.. etc..
Walter (SM): Carlão porque você acha que é 21, é tão fácil assim??
Carlão (Dev): Na verdade, olhando na ótica do Zeca e da Rita, o problema me parece ser mais complexo do que pensei,..
Walter (SM): Então, o que vocês acham da gente pesquisar alguma ferramenta open source que nos ajude neste trabalho, como um ECM ??? Estava pensando em algo neste tipo, senão realmente teremos muito trabalho,,,
Júlio (tester): Ok Walter, ótima idéia, mas acho que vamos ter muita customização, e com a estrutura que temos hoje não será nada fácil.. Imagine a quantidade de testes !!!
Walter (SM): Certo, se todos estão de acordo, vamos implantar um ECM, vamos fazer mais uma rodada então...
Nisso, é feito a segunda rodada (Tabela 1), podemos ver que houve um consenso..
Neste exemplo simples, podemos observar que alguns benefícios ficam bem claros:
- O Product Owner descreve cada história resumidamente, de forma que todos tem uma idéia do que esta rolando.
- A sinergia entre a equipe aumenta, cada for iniciar um Sprint, onde as tarefas estarão bem definidas, os membros do time, terão uma idéia bem definida do que esta sendo feito, do que o seu colega de trabalho esta fazendo.
- O risco de erros da estimativa diminui dramaticamente.
- As diferenças de opiniões ficam transparentes, de modo que todos passam a discutir estas diferenças.
- É possível re-estimar uma user story até que haja um consenso.
Ok, muito legal esta explicação, mas ainda falta algo, qual a relação entre os princípios ágeis
citados no início deste artigo com este jogo de cartas?
Bem, respondendo a pergunta, eu diria que tem tudo a ver, quer ver só:
"O método mais eficiente e efetivo de obter informação para o time de desenvolvimento é na conversa cara-a-cara."
Em planning poker todos estão conversando, (quase sempre olho no olho), o que dá transparência ao negócio.
"Analistas de negócio e desenvolvedores devem trabalhar juntos DIARIAMENTE no decorrer do projeto".
Ao fazer o planning poker, estamos discutindo requisitos funcionais e não funcionais, que visam a realização de um desejo do cliente, e geralmente, durate o planning poker está o Product Owner, para tirar todas as dúvidas em relação ao negócio e verificar se está sendo feito o que foi acordado.
E por último..
"Mudanças de requisitos são bem vindas, mesmo em um estágio avançado no desenvolvimento. Processos ágeis alinha as mudanças para vantagem competitiva do cliente."
Isso irá sempre acontecer, sempre haverá novas features/sistemas a serem desenvolvidos, e durante a estimativa podemos discutir de maneira mais técnica, até modelos de arquitetura, pois querendo ou não, a arquitetura/modelo que será desenvolvido o produto tem um forte peso nas user stories. Portanto, a qualidade do código e do modelo é essencial para que as mudanças de requisitos sejam menos "traumáticas".
Estive no Sun Tech Days, e uma palestra que achei interessante foi a "Usando computação social para melhorar a produtividade no seu projeto" da "Java Champion" Fabiane Nardon, onde ela apresentou várias ferramentas para computação social, e uma das ferramentas citadas foi o site "
http://www.planningpoker.com/", um site idealizado por Mike Cohn, e propõe uma ferramenta para que time distribuídos façam a estimativa em conjunto, tem algumas coisas a melhorar, mas a idéia é bem bacana..
OBS> Nas fotos acima, a 1º é uma sessão de planning poker no meu ambiente de trabalho, e na segunda foto o PO priorizando e discutindo os itens de Backlog.
Planning poker com certeza é uma ótima prática, e é também uma boa maneira de iniciar no mundo ágil..
Diversão garantida !!!
Em Janeiro, saiu a terceira e última parte do meu artigo Princípios, Padrões e Práticas para um Design Ágil na revista Java Magazine edição 86.
Postagens
