sexta-feira, abril 27, 2007

Scrum e as armadilhas das reuniões diárias

Uma das principais práticas do Scrum é a reunião diária (Daily Meeting). Essas reuniões se resumem em uma atividade de quinze minutos(pode ser um pouco mais ou menos, mas só um pouco) que deve ser realizada todos os dias. Durante estas reuniões os membros do time do projeto devem responder às seguintes perguntas:
- O que fiz desde a última reunião diária?
- O que farei até a próxima?
- Estou tendo algum impedimento?
Quando realizo apresentações de Scrum, é comum perceber o quão simples esta atividade parece ser para a maioria das pessoas, porém, por traz de uma simples "reuniãozinha", a reunião diária esconde o termômetro do seu projeto...e não é preciso dizer o que pode acontecer quando um termômetro é mal utilizado, certo?

Reunião diária não é "hora do café"
Algumas equipes, no decorrer do projeto, passam a achar que a reunião diária é algo bastante trivial, sem portanto exigir a necessidade de uma formalização com horário e local fixo. A consequência disso é que, com o passar do tempo, reuniões diárias passam a ser realizadas na sala de cafézinho, no "fumódromo" ou até na padaria. Na verdade a equipe passa a substituir o propósito do “Daily Meeting” para "conversas informais de quinze minutos sobre o projeto". As reuniões diárias devem sim ser realizadas no mesmo local e horário (pelo menos enquanto durar o sprint corrente). Isso é importante!
Uma sugestão de locais ideais para a realização das reuniões seriam: salas de reunião ou de treinamento, ou em algum local com espaço suficiente para acomodar toda a equipe. A sala do chefe é uma péssima opção.
Quanto ao horário, li em muitos artigos e/ou livros que o horário da manhã é o ideal para as reuniões diárias do Scrum, o que faz até sentindo mas, ná prática, eu realmente não vi exatamente com estes olhos. Trabalhei com reuniões no início do dia e ao final dele, e em ambos tive prós e contras. Pela manhã todos os participantes estão descansados e prontos para um novo dia de trabalho, isso é bom! Mas pela manhã sempre(e sempre mesmo) tem alguém atrasado(trânsito, chuva, filhos, etc.), ou seja, em pouquíssimas vezes você consegue realizar a reunião com toda a equipe, e isso é muito ruim! No fim do dia estão todos um pouco(ou muito) cansados, o que diminui a empolgação durante as reuniões, isso é ruim! Em compensação, é bem mais comum você ter toda a equipe presente, e isso é bom! Então, na minha opinião, analise o cenário cultural envolvido(empresa, projeto e equipe) e escolha uma das duas opções.

Reunião diária não é "conversa sobre futebol"
Se você pretende abrir as reuniões diárias para participação de pessoas apenas envolvidas com o projeto(chickens), deixe bem claro ao fazer o convite que o mesmo dá apenas direito a participação como "ouvinte". Apenas as pessoas que estejam realmente comprometidas com o projeto(pigs) devem falar durante a reunião diária. Deixar "chickens" falarem durante a reunião é permitir que pessoas que não estão tendo um acompanhamento dia-a-dia do projeto opinem sobre o seu andamento. Isto provavelmente causará um mal-estar entre "pigs" e “chickens” e, pior ainda, fará com que os quinze minutos acabem antes que você perceba.

Reunião diária não é "conversa sobre a relação"
Muitas equipes tem confundido os quinze minutos da reunião diária com momentos de desabafo e resolução de problemas. Muitas vezes já tive que interromper algum programador quando este falava sobre os impedimentos que estava encontrado: “Estou com um problema com a framework XYZ, pois lá tem a classe Zummble que preciso instanciar...mas não consigo fazer isso devido a esta classe herdar da JJJ que possui a implementação da interface U. Se eu fizer a instância direta cairei em um problema de redeclaração de método, blá, blá, blá”. Bem, este simples parágrafo geraria debates técnicos que, com certeza, ultrapassariam os quinze minutos da reunião. Qual seria a forma ideal de reportar este impedimento na reunião diária? Algo tipo: “Estou tendo dificuldades com a framework XYZ e creio que eu esteja precisando de um suporte/ajuda com isso para poder ter um ritmo mais adequado". Ponto final! Com isso, após a reunião, é papel do Scrum Master providenciar uma solução para o problema do programador, seja convocando uma reunião técnica, solicitando suporte junto ao fabricante, organizando uma programação em par com alguém mais experiente na framework...enfim.
Obviamente, você não pode sair cortando e proibindo todos os assuntos que emerjam na reunião e não estejam ligados às três perguntas, até porque é natural que esses outros assuntos apareçam. Eu particularmente costumo usar a estratégia do Rat Hole da FDD durante as reuniões diárias. O Rat Hole nada mais é que um papel de flip-chart ou mesmo um espaço em um quadro branco, que receberá entradas toda vez que algum assunto pertinente, mas que não deveria ser aprofundado durante esta reunião, emergir . Após a finalização do meeting, o Scrum Master define quando e de que forma tais assuntos serão discutidos.

Reunião diária não é um “julgamento”
Este talvez seja o erro mais freqüente nas reuniões diárias. Os times, principalmente aqueles compostos por membros que não estão habituados a fazer parte de equipes auto-gerenciadas, insistem em usar os quinze minutos da reunião para reportar-se AO Scrum Master, e na maioria das vezes se justificando por algum atraso ou problema do gênero. A reunião diária foi criada principalmente para o time, e não para o Scrum Master. E é AO time que cada membro deve se reportar. A reunião diária é o que nos ajuda a termos sempre uma visão atualizada do seguinte: de onde viemos? onde estamos? para onde estamos indo? E essa talvez seja a sua grande valia! Se você usar esses preciosos quinze minutos diários para penalizar membros da equipe por atraso, ouvir justificativas, dar lição de moral ou coisas do gênero, você não conseguirá utilizar o termômetro.
Infelizmente os times são os que mais demoram para entender isso. Se você, como Scrum Master, não conseguir avaliar se seu time está capitando bem a finalidade das reuniões diárias, experimente durante um dia não estar presente na empresa no horário da reunião – não avisando nada antecipadamente. Se ao retornar eles lhe informarem que não realizaram a reunião, afinal você não estava presente...você tem problemas! Eles realmente ainda não entenderam que a reunião diária é feita para eles.

Portanto entenda - e faça o time entender - que as reuniões diárias:
- Nos ajudam a analisar nossa velocidade/ritmo;
- Fazem com que todo o time esteja a par do que está acontecendo em todo o projeto;
- Identificam impedimentos;
- Integram diariamente o time;
- E, principalmente, nos fornecem um termômetro sempre atualizado de "Como está o nosso projeto?"

domingo, abril 08, 2007

FDD numa casca de banana

O documento "FDD numa casca de banana" tem como propósito ser um guia de rápido aprendizado para a FDD(Feature-Driven Development). Utilizando uma linguagem simples, ideal para os que pretendem iniciar-se na utilização desta metodologia ágil em seus projetos, o documento é composto de tópicos que abordam desde os conceitos básicos da metodologia, passando pelo seu ciclo de vida e pela execução de um projeto de exemplo utilizando todas as suas práticas.
Espero que o documento seja de utilidade para a comunidade brasileira e que contribua para o crescimento desta fantástica abordagem ágil em nosso país.

Faça o downlod do documento clicando AQUI!