Continuando essa série de post (parte 1 e 2), hoje vou comentar como foi o final da primeira iteração/sprint, reuniões de review, retrospectiva e o planejamento da iteração seguinte.
Cheguei na empresa e antes de começarmos os trabalhos, reuni o pessoal e perguntei como foi a primeira semana utilizando scrum. O desenvolvedor mais experiênte, comentou que gostou do sistema com o quadro, os cartões e post’it. Ocorria muito mudança de contexto (e mudança de contexto é algo ruim), pois as ordens vinham de cima e não havia uma preocupação de trabalhar em 1 projeto de cada vez. Ele disse que pode se organizar muito melhor. O desenvolvedor menos experiente (1 mês de empresa) também gostou muito do quadro, cartões e post’it. Segundo ele, é sempre complicado ao entrar em um projeto, entender os padrões e ter uma visão geral do sistema. Utilizando cartões, ele precisa aprender apenas pequenas partes do sistema a cada semana, se preocupando com as outras partes somente quando for necessário. O dono da empresa também está satisfeito, ele disse que foi produzido bastante nessa primeira iteração, terminaram todas as tarefas e realizaram o spike planejado.
Certo, depois da conversa inicial, fomos para o review, que na verdade serviu para eles entenderem como funciona um review (agora em mais detalhes do que na apresentação teórica inicial). Como eles trabalham para vários clientes durante a iteração, eles foram desenvolvendo e apresentando (disponibilizando no site) para os clientes. Ou seja, para esses projetos não irá ocorrer aquela apresentação formal durante o review (isto também seria dificultado pelo fato da maior parte dos clientes residirem em outras cidades).
O fato de não ter essa apresentação acabou gerando um problema. A funcionalidade é desenvolvida, atualizada no servidor e então o cliente é comunicado da mudança. O problema é que nessa primeira iteração algumas funcionalidades (4 ou 5) não ficaram pronta, pois o cliente ainda não aprovou.
Além destes projetos menores, há o projeto maior, no qual o cliente pode estar presente para a reunião de review. Nessa primeira iteração não ocorreu, pois eu aproveitei pra explicar como fazer a review. Deve ser uma apresentação simples, utilizando diretamente o software (nada de slides, diagramas…) e que preferencialmente o cliente fique utilizando o software durante a explicação do que foi desenvolvido.
Como a definição de pronto, inclui aprovação do cliente, nesta primeira semana, o que foi desenvolvido nesse projeto principal, foi apresentado para o cliente. Contudo ele achou muito mais interessante o review meeting. Segundo o cliente, ao ser informado que uma nova funcionalidade estava pronta, ele acessou o sistema utilizou de forma superficial e somente isso. Ele estava ocupado e não poderia perder muito tempo naquilo. Respondeu que estava tudo certo com a funcionalidade. Agora, com um horário reservado para essa apresentação, ele irá utilizar e (importante) fornecer um feedback muito maior para a equipe de desenvolvimento (o feedback anterior havia sido um “ok”). O cliente utilizou novamente a funcionalidade por alguns instantes durante nossa review e deu algum feedback, a funcionalidade não estava exatamente como ele queria e ele decidiu gastar algum tempo na próxima iteração melhorando isso.
Assim terminamos nosso review meeting. Já combinado para a próxima semana as funcionalidades serem apresentadas para o cliente.
Após o review, iniciamos a retrospectiva. Expliquei que a retrospectiva é a hora de melhorar. Melhorar o processo (avisando que primeiro você deve praticar corretamente o processo, somente depois pode melhorar – Shuhari), melhorar o ambiente, melhorar o código, a documentação ou qualquer outra coisa.
Além de identificar o que pode ser melhorado, é importante atacar um ou poucos problemas em cada iteração, tentar resolver tudo em uma única iteração não é uma boa idéia, provavelmente você terá nada resolvido, ou vários problemas quase resolvidos (quase resolvido significa não resolvido). Após identificar o que será melhorado, deve-se definir quais ações/atitudes serão tomadas para melhorar o ponto escolhido. Finalmente, é importante que seja definida uma forma de saber se as ações trouxeram alguma melhoria ou não.
Por exemplo, você pode identificar que o problema que será atacado na próxima iteração é que somente um desenvolvedor pode trabalhar em alguns sistemas, porquê os outros não conhecem o sistema. Isso é seu problema, uma ação/atitude que você pode tomar é definir que a equipe irá utilizar programação em dupla, principalmente com esse desenvolvedor quando estiver trabalhando em um sistema que só ele tem conhecimento. Para saber se essa atitude/ação teve algum resultado, você (junto com a equipe) define que até a próxima retrospectiva deverá ser feito ao menos 20 horas dessa programação em dupla. Assim na próxima retrospectiva você checa quantas horas de programação em dupla foram feitas, podendo verificar se o problema encontrado na retrospectiva anterior foi atacado ou não.
Continuando… antes do tradicional “O que foi bom”, “O que pode ser melhorado” e “O que foi mal”. Fiz outra atividade. Comentei novamente sobre o que é desperdício no Lean e apresentei as 7 formas mais comum de desperdício no desenvolvimento de software:
- Trabalho particialmente finalizado
- Processos extras
- Funcionalidades extras
- Mudança de contexto
- Espera
- Movimentação
- Defeitos
Depois disso, utilizei a idéia de votação por pontos, onde cada desenvolvedor pode escolher 2 desperdícios e votar neles, os mais votados (ou o mais votado) seria escolhido para discussão do porquê (análise da raiz do problema) ele ocorre e o que pode ser feito para que não aconteça mais. Os mais votado foi “Defeitos”. Ficamos alguns minutos discutindo sobre isso, você pode atacar esse desperdício de várias formas, por ser algo muito abrangente. Depois de alguma discussão, eles concluiram que se utilizassem melhor as funcionalidades do Zend Framework (o problema, não conhecem a fundo o framework utilizado), eles poderiam reduzir o número de defeitos. Como isso também estava muito vago, conversamos mais uns 3 minutos e ficou definido que para a próxima semana (a ação/atitude) eles irão estudar o Zend_DB_Table. Para verificar se o problema foi atacado na iteração atual, na nossa próxima retrospectiva além de verificar se as horas foram gastas estudando o componente, também ficou combinado que, se for vantajoso utilizar o componente, deverá estar escrito em algum lugar alguns exemplos das situações que serão mais utilizadas no dia-à-dia, facilitando assim a utilização. Se não for vantajoso, será discutido onde o componente falha.
Depois seguimos para o “O que foi bom”, “O que pode ser melhorado” e “O que foi mal”. Combinamos que faríamos essa atividade, mas não iríamos atacar nenhum problema levantado nessa atividade, pois para a próxima iteração o Zend_DB_Table já irá ocupar bastante tempo. Essa atividade foi mais leve e rápida, na coluna “o que foi bom” apareceram coisas como “utilizar quadro e post’it” até coisas mais específicas como “fazer a validação do usuário utilizando ajax”. Eu acho ótimo isso, nessa hora é preciso pensar desde o processo até detalhes de implementação. Os pontos negativos levantados foram a mudança de contexto, que segundo eles diminui bastante mas ainda incomoda, além de um cliente que parece ser daqueles bem chatos.
Além disso, durante a retrospectiva, resolvemos criar mais uma coluna no quadro de tarefas. Atualmente, enquanto uma funcionalidade estava esperando a aprovação do cliente, ela ficava na coluna “Impedimentos”. O problema é que essa coluna ficou com bastante itens (4 ou 5) que eram apenas aguardo de aprovação do cliente, e havia também um pequeno impedimento de verdade, que quase sumia no meio de tanta espera por aprovação do cliente. Como a idéia é que impedimentos existem para serem eliminados, essa dificuldade em ver facilmente que existe um impedimento além de aprovação do cliente me incomodou. Então agora o quadro tem mais uma coluna: “Aprovação”, que identifica os itens que estão pendentes de aprovação. Assim a coluna de impedimentos tem novamente a atenção necessária.
Depois disso, falei para eles que estava na hora do cafézinho!
Para finalizar, fomos para o planejamento da próxima iteração. Novamente algo foi alterado. Quem realiza o papel do cliente, também é desenvolvedor. Sendo assim, ele não precisa que a equipe estime uma user story (ou funcionalidade) para saber se é maior ou menor do que outra. Ou seja, ele pode organizar o product backlog (lista de funcionalidades) sem o auxílio da equipe, pois ele tem noção do quanto uma user story é maior que outra.
Contudo eu acho que é interessante que eles continuem estimando as user stories utilizando pontos, pois caso eles comecem a desenvolver outro projeto, com outro cliente, eles já vão saber como funciona a estimativas por pontos. Esse é o único motivo pelo qual eles estão estimando por pontos as user stories, somente para conhecer bem o funcionamento para que possam usar, quando for necessário.
Então o planejamento ficou um pouco diferente, cada cartão contendo uma user story era apresentado, os detalhes eram explicados para a equipe. A equipe então estimava utilizando pontos (story points), em seguida quebrava a user story em tarefas e já estimava em horas ideais. Antes de iniciarmos o planejamento, foram calculadas quantas horas cada desenvolvedor tinha disponível, feito alguns descontos (suporte e horas ideais não representam horas reais) para chegar ao que acreditamos ser o total de horas ideais disponíveis essa semana. Então fomos estimando cada user story, quebrando em tarefas e estimando as tarefas até o total de horas disponíveis para a semana.
E foi isso, tudo devidamente estimado, cartões e post’it fixados no quadro, hora de trabalhar. Quinta-feira estarei de volta lá para ver como as coisas estão andando.
Quero ser Ágil 