Profissionais TI - Pra quem respira informação

Em toda carreira o profissional precisa de boas ferramentas para realizar o seu trabalho com eficiência. Além de boas ferramentas, é necessário saber como obter o melhor de cada uma delas. Assim como os papéis que conversamos nos artigos anteriores, o Scrum permite que suas ferramentas sejam customizadas conforme o entendimento e performance dos profissionais e suas organizações. Venho destacando esta flexibilidade do Scrum porque não acredito em modelos perfeitos e eficazes afinal, cada empresa, cada grupo, tem características diferentes que exigem adaptações destes modelos para atingir sua melhor produtividade.

Recomendo a leitura dos artigos anteriores para que possam chegar aqui compreendendo todo o contexto cuidadosamente criado com esta percepção de customizações. Não deixe de ler Scrum no BurnDown, Product Owner dita as Regras, Scrum Master “Agile Man” e Desenvolvimento Versátil.

Era uma vez…

Contar estórias sempre nos ajudou a refletir sobre um determinado assunto e, não diferente disto, no Scrum também contamos estórias. O Product Backlog será analisado pelo Product Owner durante a reunião de Planejamento da Sprint, que vai propor a próxima entrega à Equipe de Desenvolvimento. Estes itens propostos devem ser desmembrados em estórias objetivas e que contenham funcionalidades bem explícitas para que a estimativa seja feita com maior assertividade.

Considere o seguinte item do Product Backlog: “Qualquer munícipe pode abrir uma solicitação de serviços à prefeitura e acompanhar todo andamento, desde que resida no município.”

Aparentemente é algo simples, mas se analisarmos bem vamos encontrar alguns desmembramentos possíveis que se tornarão nossas estórias. Se existe uma restrição ao serviço exigindo que o solicitante seja residente no município, então precisamos validar esta informação. Precisamos ter um cadastro com informações desta pessoa. Precisamos fornecer um protocolo para consulta do processo ou exibir solicitações em andamento desde solicitante. Sendo assim, identificamos as estórias:

1. Precisamos registrar o solicitante
2. Precisamos verificar se o solicitante reside no município
3. Precisamos registrar a solicitação de serviço e informar o número do protocolo de atendimento
4. Precisamos consultar informações da solicitação e informar o andamento do processo

Conhecendo as estórias abstraídas de apenas um item do Product Backlog, é hora de estimar o tempo de desenvolvimento. Não esqueçam que ainda estamos na reunião de Planejamento da Sprint, que pode durar um dia inteiro.

Produtivos até durante as estimativas

Agora vamos fazer contas. Sim, a estimativa no Scrum possui algumas métricas que consideram o grau de dificuldade de cada estória e, também, a velocidade do Time de Desenvolvimento.

O primeiro passo é determinar a pontuação para cada estória identificada. Para isso, a maneira mais eficiente e agradável é usar o Planning Poker.

Considere a sequencia de Fibonacci como sendo os possíveis pontos a serem atribuídos (1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89…), acrescente o número 0 (zero), uma “?” interrogação e um desenho de uma xícara de café a esta sequencia.

• 0 – é colocado pelo membro da equipe que considera a estória pronta;
• ? – para estória que o membro da equipe desconhece completamente;
• café – apresentado quando um membro precisa de uma pausa, afinal, esta reunião tende a ser extensa, dependendo do tamanho da Sprint;

A sequencia de Fibonacci representará o tempo que cada membro estima para concluir a estória. Lembrando que para concluir uma estória é necessário considerar todas as tarefas que julgue necessária (levantamento, plano de testes, modelagem de dados, carga de tabelas, etc…).

“Recomendo que, antes de implementar o Scrum, façam um alinhamento do que significa cada valor da sequencia Fibonacci pois, um mesmo número poderá representar estimativas diferentes entre duas ou mais pessoas.”

Eu gosto muito de usar esta classificação:

• 1 – estória de meu completo domínio, não requer codificação, plano de testes simples e fica pronta dentro meio período;
• 2 – estória simples, fácil compreensão, pouca codificação, não requer cargas ou implementações de banco de dados e fica pronta em 1 dia de trabalho;
• 3 – estória de baixa complexidade, porém requer alguma atividade além da codificação e plano de testes. Necessários 2 a 3 dias de trabalho;
• 5 – estória de média complexidade. Requer diversas iterações além da codificação e plano de testes. Pode chegar a 1 semana de trabalho;
• 8 – estória de alta complexidade. Requer diversas iterações, impacto em outras áreas de negócios além da codificação e plano de testes. Pode chegar a 10 dias de trabalho;
• 13 – estória de alta complexidade. Existem problemas técnicos identificados a serem resolvidos ou regras de negócios indefinidas. Pode chegar a 2 semanas de  trabalho;
• 21 – estória de alta complexidade.  Pode utilizar todo o período da Sprint para ser concluída;
• 34… – é muito arriscado trabalhar com pontuações altas, pois significa que a estória não está clara, pode ser desmembrada em outras estórias, requer uma Sprint específica ou atenção de toda Equipe de Desenvolvimento.

Todas as experiências que tive com estórias acima de 21 pontos resultaram em cancelamento da Sprint ou entrega parcial, pois foge do nosso controle quando permitimos uma estória tão complexa. Sempre que isso ocorreu, durante a reunião de Retrospectiva conseguimos desmembrar esta estória em, pelo menos, outras 3 estórias e que foram concluídas com tranquilidade na Sprint seguinte. Então fica aqui a dica de não trabalharem com estórias acima dos 21 pontos.

Existem baralhos para Planning Poker, aplicativos para smartphones e até mesmo usar a boa e velha dupla papel e caneta, mas façam a apresentação da pontuação de cada estória todos os membros da Equipe de Desenvolvimento, simultaneamente para que a pontuação do primeiro não interfira na percepção do seguinte e assim por diante.

Quando há uma pequena divergência, descarta-se os valores extremos (mais alto e mais baixo) e adota a pontuação intermediária. Ex.: (2, 2, 3, 3, 5) descarte (2 e 5) e aplique 3 pontos para a estória.

Quando há uma divergência muito grande, provavelmente este membro conhece alguma informação específica da estória e merece abrir uma discussão. Vamos aplicar esta situação no exemplo que iniciamos com nossas estórias fictícias. Fazendo o Planning Poker com a estória: “1. Precisamos registrar o solicitante”

Obtivemos as pontuações dos membros: (8, 8, 8, 13 e 2). Neste caso, quem indicou uma pontuação alta justifica que será necessário fazer todo processo de cadastramento de informações do solicitante, identificar, criar login, validar senha de acesso. Mas quem apresentou 2 pontos, explica que já trabalhou em outro projeto e que criou todo o cadastro de munícipes que utilizam o portal da prefeitura e que está integrado com a distribuição de água e esgoto, portanto, também consegue validar se é residente no município. Isto vai influenciar, inclusive, no Planning Poker da estória: “2. Precisamos verificar se o solicitante reside no município”.

Como podem perceber, o Planning Poker permite estimar prazos e esclarecer ainda mais cada estória a ser implementada na Sprint.

Velocidade da Equipe

Após pontuar todas estórias, imagino que tenha em mente a pergunta: “O que faço com estes pontos?”

Eu sugeri a utilização dos pontos entre 1 e 21, explicando o tempo que cada pontuação pode representar, mas esta é uma métrica que eu adotei depois de muitos projetos, muitos erros de estimativas, Sprints canceladas, enfim, fui ajustando conforme a percepção dos erros e acertos. Hoje executo projetos Scrum e também dou a consultoria baseado na experiência vivenciada, mas a metodologia nunca pode ser engessada! Faça uma experiência com estas diretrizes que passei e, se necessário, façam seus próprios ajustes.

Bem, somando a pontuação das estórias, você atinge um valor que será a meta da sua Sprint. A velocidade da equipe é a capacidade de concluir uma determinada pontuação dentro do período da Sprint. Vejam:

• Equipe: 5 membros
• Sprint: 2 semanas (10 dias)
• Total pontos concluídos: 40
• Velocidade da equipe: 4 pontos / dias OU 20 pontos / semana
• Velocidade individual média: < 1 ponto / dia OU 4 pontos / semana

A partir da primeira Sprint você passa a tabular dados para fazer as próximas estimativas e consegue determinar quantos pontos sua Sprint deve ter e, consequentemente, saber quantas estórias poderá incluir na Sprint. Com o passar do tempo, as equipes ficam mais entrosadas e as estimativas mais precisas. Tenho observado que equipes fixas passam a ter melhores estimativas após 4 ou 5 Sprints, atingindo completo domínio do Scrum no primeiro ano de trabalho, onde, seguindo estas estimativas, obtivemos uma performance de 8 pontos por semana (individual), o que supera a tabela de referência que descrevi. Em uma equipe de 5 pessoas representa uma velocidade de 40 pontos por semana ou 160 pontos por mês! São entregas realmente significativas!

Tendo este controle você é capaz de estimar até mesmo se um dos membros da equipe precisar se ausentar para realizar um treinamento, por exemplo.

“Cuidado para não entrarem em uma competição, como tenho visto em grupos que adotaram o Scrum recentemente. Cheguei em organizações onde o gestor não tinha entrega de produtos mas as equipes concluíam mais de 150 pontos por Sprint! Isso não existe! Então cuidado com as pontuações para que não perca a referência. A equipe pode entregar a mesma Sprint com 40 pontos ou 2000 pontos, pouco importa. É apenas uma referência para controlar o andamento e capacidade de produção da equipe. Concluir 2000 pontos não significa que um grande conteúdo está sendo entregue.”

Existem outras métricas para se calcular velocidade, estimativas e até custos que podem ser implementados de acordo com o empenho e necessidade da organização. Não vou entrar nestes detalhes porque o artigo ficará muito extenso, mas se acharem interessante, posso criar um artigo específico.

Task Board: o espelho do projeto

Basta olhar para o Task Board e o gestor será capaz de avaliar como estão suas equipes. É nada mais do que uma grade contendo todas as estórias e suas respectivas tarefas, como se estivessem em uma linha de produção.

Cada estória deve ser quebrada em tarefas a serem executadas para concluir a estória. Por exemplo, a estória: “3. Precisamos registrar a solicitação de serviço e informar o número do protocolo de atendimento”

1. Levantar com o PO a relação de serviços a serem disponibilizados no sistema;
2. Verificar se existe esta estrutura no banco de dados;
3. Fazer a carga dos serviços;
4. Levantar com o PO as informações que devem ser contempladas no atendimento;
5. Design da interface do sistema;
6. Elaboração e execução dos planos de testes.

Sem pensarmos muito, a estória proporcionou 6 tarefas a serem cumpridas e a baixa dos pontos da estória só poderá ser feita quando todas as tarefas estiverem concluídas.

Um modelo básico de Task Board pode ser visto na imagem acima, onde a grade é dividida verticalmente em “estórias”, “a fazer”, “executando” e “feito”. As estórias ficam na linha horizontal, agrupando suas respectivas tarefas. É uma boa prática anotar a pontuação das estórias para facilitar a baixa dos pontos sem consultar outros artefatos.

Em seguida vou mostrar uma adaptação do Task Board que eu gosto muito, em formato de Goal Task para facilitar ainda mais a identificação do andamento pelos gestores, inclusive o PO.

Desta mesma maneira é possível criar novas colunas para considerar o Scrum em modelo de Equipes Especialistas conforme expliquei no artigo Desenvolvimento Versátil, incluindo uma coluna para cada equipe especialista da organização (Administração de Dados, Infraestrutura, Testes, Homologação, etc…).

Os mais conservadores sugerem fazer as alterações no Task Board no instante seguinte à Reunião Diária, mas eu aconselho que as mudanças sejam feitas no instante em que elas ocorrem. Isso torna o processo mais dinâmico e tanto o PO quanto os gestores terão a posição real a qualquer momento.

No mundo ideal…

O Task Board ou Quadro Kanban é uma ferramenta simples e capaz de demonstrar tudo o que está acontecendo no andamento da Sprint, mas vou preparar vocês para a nossa realidade que não é u mundo ideal. Regras mudam, problemas acontecem e muitos deles não podem esperar. Apesar de defender arduamente o conceito de separar a equipe de desenvolvimento em duas frentes onde uma fica dedicada à manutenção dos sistemas em produção, enquanto a outra permanece focada no desenvolvimento de novos módulos e novas tecnologias. Mas sei que a grande maioria não trabalha desta maneira, então vamos lá…

O cartão vermelho sobre o cartão azul, significa que existe um problema a ser resolvido em uma das tarefas da Sprint. O cartão vermelho deve conter uma breve descrição do problema para que todos do Time Scrum fiquem cientes até que o problema seja sanado. Quando o problema for resolvido, remova o cartão vermelho e prossiga com a Sprint.

Os cartões verdes representam tarefas fora da Sprint que, por uma forte razão tiveram que ser feitas dentro da Sprint. Isto compromete toda estimativa realizada, por isto é necessário atribuir pontuações a estas tarefas extras para que seja justificado este tempo gasto na Reunião de Revisão da Sprint. Não é o mundo ideal, mas é uma forma de, ao menos, sinalizar os imprevistos e representar na mesma linguagem do Task Board.

Gráfico Burndown

Considerado o termômetro da Sprint, interpreta o que está acontecendo no Task Board de maneira objetiva. O eixo y contém o total de pontos da Sprint, enquanto o eixo x contém os dias válidos para a Sprint. Veja o gráfico abaixo:

A linha vermelha é traçada no início, determinando o andamento ideal da Sprint, enquanto que a linha azul é traçada dia a dia e representa o andamento real da Sprint. A linha azul estando acima da linha vermelha, significa um possível atraso em relação à estimativa. Abaixo da linha vermelha significa uma possível antecipação em relação à estimativa. O gráfico acima representa o final da Sprint dentro da estimativa inicial.

Este gráfico deve ficar anexado ao Task Board, visível por todos e atualizado a cada baixa de pontos da Sprint.

Definição de Pronto

Ainda há muito o que escrever a respeito de Scrum e ferramentas, mas eu não poderia deixar de comentar rapidamente sobre a definição de “pronto”. Cada um tem sua concepção do que é concluir a tarefa, mas lembrem-se de que é preciso respeitar e, principalmente, conhecer esta definição do Product Owner.

• Desenvolvedor: quando terminou a codificação.
• Analista de Teste: quando encerrou o teste e não encontrou nenhum bug.
• Product Owner: quando a entrega da Sprint estiver em produção.
• Usuário final: quando estiver devidamente capacitado para utilizar o que foi entregue.

Estas definições devem estar claras para todos e em comum acordo. Se não forem estas as definições de “pronto” na sua organização, então façam este exercício e definam antes mesmo de implantar o Scrum.

Em algumas organizações, o treinamento do usuário é considerado e faz parte da Sprint, quando necessário. Eu recomendo o modelo, pois percebi que praticamente não existem chamados para esclarecimentos de dúvidas, uma vez que os usuários foram treinados para um produto aprovado pelo Product Owner.

Também quero deixar para vocês algumas ferramentas online que poderão trabalhar com o Scrum, inclusive algumas você encontra para uso gratuito: Trello, Team Pulse – Telerik e Visual Studio Online. Existem muitas outras ferramentas mas eu já trabalhei com estas 3 que são excelentes mas, atualmente, estou encantado com o Visual Studio Online que conseguiu criar um ambiente completo, inclusive para gerenciar versões, framework Scrum e outros bem interessantes. Tendo um pouco mais de tempo eu crio um Gráfico Burndown dinâmico no Excel e posto aqui para vocês.

Bem, estou concluindo a série de artigos Scrum e agradeço a todos que entraram em contato comigo, assim como espero ter ajudado a esclarecer alguns pontos e enriquecer um pouco mais as ideias a respeito deste assunto. Se acharem interessante nos aprofundarmos mais no assunto, enviem as sugestões e eu volto a escrever.

Abraço e bons projetos!

Publicado originalmente em: Blog Andrey Kurka