Qual a importância da reunião diária no SCRUM?

Quando comecei a estudar a metodologia SCRUM e vi que tinha uma tal de reunião diária algumas perguntas do seguinte tipo surgiram na minha cabeça:

- Essa reunião não é perda de tempo?

- Que diabo de assunto terá para discutir todo dia?

Então fui pesquisar um pouco mais sobre do que realmente é tratada a reunião diária do SCRUM em diversos blogues e qual a sua devida importância. Inclusive os seguintes blogues me ajudaram a escrever esse post:

http://www.mountaingoatsoftware.com/agile/scrum/daily-scrum/

http://www.mountaingoatsoftware.com/blog/weighty-matter-daily-scrum

http://www.effectivemeetings.com/teams/teamwork/scrum.asp

Apresentei para meus colegas de equipe, e resolvemos implementar a diária durante uma fase do projeto que estamos com o prazo apertado e esta técnica realmente nos ajudou a manter o foco e conseguir entregar o software no prazo acordado.

Uma reunião diária deve durar em torno de 15 minutos, portanto não se trata daquelas reuniões prolongadas e se que se arrastam por horas. A ideia principal desta reunião não é solucionar problemas, mas sim identificar se a equipe está no caminho certo, ou caso algum membro do time esteja com problema, este poderá sinalizar para todas pessoas presentes e ‘pedir ajuda’.

As perguntas típicas a serem respondidas numa diária são as seguintes:

“O que você fez ontem?”

“O que você fará hoje?”

“Existe algum impedimento para execução da sua tarefa?”

É recomendado que os participantes fossem os mais breves o possível em suas respostas.  Caso alguém enfrente um impedimento deve sinalizar na diária para que possa ser resolvido fora dela. Típicas assertivas para sinalizar que necessita de ajuda são:

“Eu estou com problemas em debugar o problema com o programa xpto.”

“Eu estou com dificuldades em aprender determinada tecnologia e gostaria de parear com alguém.”

“O departamento VP me pediu para trabalhar em outra coisa por um dia ou dois.”

Apesar de exigir uma equipe com uma certa senioridade em desenvolvimento de softwares, quando feita da maneira correta, a reunião diária pode ajudar qualquer tipo de equipe a manter o foco e aos membros cooperarem entre si para a entrega do software com qualidade e no devido prazo.

Cooperative game manifesto for software development

“Desenvolvimento de software é uma série de jogos cooperativos de invenção e comunicação com recursos limitados e objetivos definidos. O objetivo principal de cada jogo é a produção e entrega de um sistema de software; o resíduo do jogo é uma série de marcadores para ajudar os participantes do próximo jogo. As pessoas usam os marcadores para se lembrarem, inspirarem-se e informar uns aos outros sobre como chegar à próxima etapa do jogo. O próximo jogo é uma alteração do sistema ou a criação de um sistema vizinho. Cada jogo, então, tem um objetivo secundário de criar uma posição vantajosa para o próximo jogo. Dado que os recursos são limitados, o objetivo principal e o secundário competem por recursos.”

Alistair Cockburn : http://alistair.cockburn.us/Cooperative+game+manifesto+for+software+development

A palavra ‘jogo’ consiste em uma série de movimentos. Um jogo ‘competitivo’ é aquele que todos os jogadores tem a intenção de ganhar e fazer os outros perder. Por outro lado, um jogo ‘cooperativo’ é aquele que leva os jogadores a ajudarem uns aos outros.

Bons exemplos de jogos cooperativos são grupos de escaladas e bandas de musica. Na música não existe um ponto especifico a se conquistar, mas sim a tocar a musica de maneira mais harmônica possível. Já na escalada, onde existe um ponto que se quer chegar (topo da montanha). Para alguns escaladores chegar ao topo da montanha é algo triste, pois significa que a escalada terminou. Isto acontece com alguns programadores, onde o jogo aqui falado é ajudar uns aos outros a completar a escalada (entregar o sistema funcionando).

No desenvolvimento de softwares nós temos um ‘ponto de chegada’, que é a entrega do software. Não é um jogo competitivo, mas sim cooperativo. O jogo jogado pelo time de desenvolvimento é ajudarem uns aos outros a completarem o software. Podem até haver mais de um time competindo entre si para entregar um software similar em menor tempo, mas dentro de cada time é jogado o jogo cooperativo.

A definição de sucesso pode variar de projeto a projeto. Em alguns casos o tempo de entrega do começo ao fim pode ser o medidor do sucesso do time. Em outros casos o sucesso pode estar atrelado a entrega de um software sem defeitos, e ainda em outros levam em conta a usabilidade do sistema, bem como aceitação pelo cliente e o seu desempenho. O que vai ser usado para medir o sucesso da equipe não interfere na ideia de que estamos jogando um jogo cooperativo, mas sim interfere nas estratégias que o time vai usar para alcançar a entrega.

Cinco “S” (Kaizen) aplicados no desenvolvimento de software

Cinco “S” (Kaizen) aplicados no desenvolvimento de software

Seiri: separar;

Seiton: organizar;

Seiso: limpar;

Seiketsu: padronizar;

Shitsuke: manter;

Assim como a metodologia Lean de desenvolvimento de software e Kanban, o Kaizen também ‘nasceu’ no Japão, como parte da metodologia de trabalho da Toyota, conhecida também por Just in Time. O 5S foi e continua sendo muito usado para dar suporte a metodologias como Kanban para ajudar no processo de melhoria continua.

O conceito do 5S é para ser um método que visa organizar o local de trabalho ou um fluxo de trabalho. Uma que vez que aplicamos o Kaizen no local de trabalho, o time de colaboradores irá ter um local de trabalho mais limpo e organizado. Quando aplicado em um fluxo, qualquer colaborador poderá cumprir as etapas do mesmo e rapidamente identificar se alguma delas está faltando ou foi ‘pulada’.

Um time de desenvolvimento pode se beneficiar da pratica do Kaizen em sua rotina de trabalho, vamos olhar passo a passo como podemos aplicar em nossos projetos:

   Seiri: separar;

Revisar nosso código antigo para remover quaisquer funções obsoletas e não mais utilizadas, bem como muitas funções que acabam não sendo mais usada e deixamos comentadas dentro do código. Muitas vezes utilizamos ferramentas de controle de versão (git), e a mesma guardará as mudanças para nós, não precisamos deixar o código comentado para ver o que se passou. Vale lembrar aqui o conceito do YAGNI (You Ain't Gonna Need It)

   Seiton: organizar;

Muitas vezes no desenvolvimento de software, acabamos fazendo uma força tarefa para agilizar a conclusão de determinado programa. Com essa força tarefa, acabamos fazendo certas ‘gambiarras’ para entregar o software no prazo. Devemos ter a preocupação para separar um tempo e destrinchar o código, separar bem as classes e utilizar o conceito de OO.

   Seiso: limpar;

Importante que reservemos tempo para refatorar nosso código. Sempre que tivermos oportunidade devemos procurar melhorar e limpar um programa já desenvolvido. Mas devemos sempre nos lembrar de rodar as rotinas testes após a refatoração. Ter utilizado o TDD pode ser tornar muito útil quando for refatorar seu código.

   Seiketsu: padronizar;

Devemos manter um padrão de codificação. Nosso código deve estar legível e de rápida compreensão. Uma ótima técnica do Extreme Programming para criar um padrão nos times de desenvolvimento é o Pair Programming.

   Shitsuke: manter;

Uma vez que os padrões de desenvolvimento foram estabelecidos e o código foi revisado para garantir a melhor técnica e desempenho, devemos manter em alto nível tanto de nossas habilidades como desenvolvedores quanto o código desenvolvido.