Scrum e Métodos Ágeis: Um Guia Prático

Capítulo 1: Para quem não sabe nada de Agile…

• Nenhum cliente quer comprar um software, mas sim uma solução para um problema ou melhoria em algo já existente.
• Scrum é sobre entregar valor aos clientes, sem necessariamente se importar no detalhe de como isso vai ser realizado.
• Vantagens de usar Scrum
  • Adaptabilidade: O controle de processos empíricos e a entrega iterativa fazem com que os projetos sejam adaptáveis e abertos à incorporação de mudanças.
  • Transparência: Todos as fontes de informações, tais como, o quadro de tarefas (Kanban) e o gráfico Burndown, são compartilhadas gerando um ambiente de trabalho aberto.
  • Feedback Contínuo: O feedback contínuo é fornecido através de processos denominados como a Reunião Diária e a Sprint Review
  • Melhoria Contínua As entregas melhoram progressivamente, Sprint por Sprint, através do processo de refinamento do Backlog do Produto e do processo em si.
  • Entrega Contínua de Valor: Os processos iterativos permitem a entrega contínua de valor tão frequente quanto exigido pelo cliente.
  • Eficiência: O Time-boxing e a minimização de trabalho não-essencial conduzem a níveis mais altos de eficiência.
  • Motivação: Os processos de conduzir a Reunião Diária e de Retrospectiva da Sprint conduzem a níveis mais altos de motivação entre os colaboradores.
  • Alta Velocidade: Uma estrutura de colaboração permite que os times multifuncionais atinjam o seu pleno potencial e alta velocidade.
  • Ambiente Inovador: Os processos de Retrospectiva da Sprint e de Review da Sprint criam um ambiente de introspecção, aprendizagem e adaptabilidade, que levam a um ambiente de trabalho inovador e criativo.

Capítulo 2: Um guia rápido para o Scrum

• O que é Scrum? “Um framework dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível.”
• O Scrum se baseia em três pilares de sustentação, suas ideologias e suas principais qualidades: transparência, inspeção e adaptação.
• O framework Scrum divide-se em papéis, eventos e artefatos.
  • Papéis
    • Time Scrum é o nome dado ao conjunto de pessoas que possuem todo o conjunto de skills necessárias para desenvolver um produto de software.
    • Product Owner é o responsável pelo ROI (retorno sobre o investimento) do projeto, por gerenciar e priorizar o Product Backlog (veja mais adiante) e, para que o Scrum funcione realmente e ele consiga trabalhar, toda a organização deve respeitar as suas decisões.
    • Desenvolvedores são os responsáveis por desenvolver o produto. O time de desenvolvedores (que não precisa e não deve ser composto apenas por desenvolvedores) é autogerenciável, multifuncional e compartilham a responsabilidade pelo sucesso ou fracasso do projeto.
    • Scrum Master é o responsável por aplicar e garantir a adoção do Scrum dentro da equipe e até mesmo dentro da organização onde estão inseridos.
  • Eventos
    • O Scrum chama seus eventos de time-boxes, uma vez que são eventos de duração fechada. Um evento pode ser encerrado em tempo menor do que o previsto, mas nunca maior, e o Scrum Master deve garantir isso enquanto facilitador dos eventos.
    • Sprint: As sprints são time-boxes de 1 mês ou menos e são o coração do Scrum. Durante o período da Sprint um incremento utilizável do produto é criado. Mas nem só de desenvolvimento vive a Sprint, fazendo parte da mesma também o planejamento, as reuniões diárias, a revisão e a retrospectiva.
    • Sprint Planning: Time-box de 8h para uma sprint de um mês, ou menos tempo de acordo com o tamanho da Sprint.
    • Daily Scrum: Timebox de 15 min que deve acontecer diariamente, sempre no mesmo local e horário para gerar consistência e evitar perda de tempo, facilitada pelo Scrum Master. Nesta reunião, cada membro do time deve responder apenas três perguntas: o que eu fiz ontem, o que eu vou fazer hoje e se tem algo me impedindo.
    • Sprint Review: Time-box de 4h para sprints de um mês onde o incremento do produto, que está pronto para uso, é apresentado ao Product Owner (e demais stakeholders) para apreciação.
    • Sprint Retrospective: Time-box de 3h para sprints de um mês onde o time de desenvolvedores e o Scrum Master (que atua apenas como facilitador) falam sobre os resultados obtidos na Sprint que passou e as lições tiradas a partir daí, para melhorar o processo, fortemente arraigado ao pilar de adaptação.
  • Artefatos
    • O Scrum determina alguns poucos artefatos, que são ferramentas para lhe auxiliar na aplicação da metodologia.
    • Product Backlog: Lista ordenada por prioridade de tudo que deve ser necessário no produto, e origem única dos requisitos para qualquer mudança a ser feita no mesmo. Gerenciado única e exclusivamente pelo Product Owner, que o faz a todo momento, o product backlog deve ser mantido longe do time de desenvolvimento, para evitar dispersão pensando no futuro.
    • Sprint Backlog: Uma versão reduzida de backlog apenas com os itens que devem ser desenvolvidos nesta Sprint, retirados do backlog original. Cabe ao time de desenvolvimento montar o Sprint Backlog com base nas prioridades do Product Owner e é sua responsabilidade dar cabo de todos itens até o fim da sprint. Ao contrário do Product Backlog, o Sprint Backlog é imutável após sua construção e deve ser defendido pelo Time de Desenvolvimento e pelo Scrum Master, para garantir que o planejamento inicial, com suas metas, prazos e escopo, sejam realizados com sucesso.

Capítulo 3: Roadmap ágil de produto

• Ter um roadmap ajuda a tomar decisões de escopo, de priorização e principalmente, de ter uma ideia do quão longe estamos de chegar aonde queremos.
• Matriz Valor x Risco: é um artefato ágil para dimensionar o tamanho de um projeto ou roadmap, além de ajudar na priorização do mesmo e definição dos épicos e features de um produto.
  1. Desenhe uma matriz bi-dimensional com dois eixos, tipo um plano cartesiano. No eixo vertical, escreva Valor e no eixo horizontal, escreva Risco. Cada eixo deve ter duas ou mais partes, como Baixo, Médio e Alto Valor, ou Baixo, Médio e Alto Risco, de baixo para cima e da esquerda pra direita, respectivamente.
  2. Após terminar de colocar os post its nos lugares certos cabe ao time decidir a sua estratégia de priorização do roadmap.
• Futurespective: essa dinâmica pode ser complementar à Matrix Valor x Risco ou mesmo substituí-la.
  1. Separe o seu time em grupos de até 3-5 integrantes. Evite grupos muito grandes para evitar discussões desnecessárias.
  2. Estabeleça que cada participante vai escrever 10 post-its com épicos ou features que ele acredite ser importante para o produto e que ainda não foram desenvolvidas.
  3. Após todos escreverem,  cada membro deve apresentar aos demais o que ele escreveu. Juntos, devem definir quais x itens devem ser prioridade para os próximos 3 meses (desconsiderando repetidos), sendo que x deve ser o número de integrantes da equipe que está fazendo a dinâmica. Depois, quais os próximos x que devem ser prioridade para os 3 meses posteriores e assim por diante, até os itens terminarem.
• Para tomarem a decisão de prioridade, pode ser usada a Matriz Valor x Risco, a Buy a Feature Game ou qualquer outra dinâmica que você conheça.

Capítulo 4: Histórias de Usuário, não tarefas

• Como organizar e/ou documentar as tarefas que devem ser realizadas a cada Sprint? Uma ideia é fazê-lo com User Stories ou Histórias do Usuário.
• Toda funcionalidade que vamos desenvolver vai impactar a vida de no mínimo uma pessoa, então sempre começamos com um “quem”.
• Depois de definirmos para quem estamos desenvolvendo uma nova funcionalidade, devemos definir o que será desenvolvido.
• Cabe ao P.O. especificar “o quê” deve ser feito e “para quem”, mas não “o como”. A funcionalidade deve ser descrita a nível de usuário e a nível de negócio, jamais a nível de programação.
• Sendo assim, sua história de usuário deve ser: sem detalhes de implementação; focada no que o usuário quer fazer; explicada do ponto de vista do usuário; curta e objetiva.
• O último elemento de uma user story é a motivação. Por que o usuário quer essa funcionalidade? Para quê ela vai servir exatamente (do ponto de vista de ’entrega de valor’)? O que isso vai impactar na vida dele?
• Quando a User Story possui regras de negócio ou requisitos não-funcionais específicos, vale definir os critérios de aceitação da mesma. Basicamente os critérios de aceitação são um checklist de requisitos que esta história em particular deve atender para que a mesma possa.
• O jeito mais tradicional de usar user stories é usar o Product Backlog como insumo e escrevê-las em post its, uma por post it.

Capítulo 5: Como estimar o tempo de desenvolvimento

• Como saber quantas tarefas cabem em uma sprint? Com Scrum Poker.
• Scrum Poker: conduz o time a encontrar métricas que funcionem para todos e a construir o escopo do que será feito na próxima fase de desenvolvimento de maneira colaborativa. Ok, o gerente (P.O. neste caso) ainda tem um papel essencial aqui: o de priorizar o que deve ser feito primeiro, mas não é ele quem decide quanto tempo o time vai levar para realizar seu intento.

• O Scrum Poker parte do pressuposto que somente os responsáveis por executar uma tarefa podem dizer quanto tempo ela vai levar para ser desenvolvida.
• O Poker no nome vem por conta de as estimativas serem feitas com um baralho. Não um baralho comum, mas um que usa a Sequência de Fibonacci.
• Como jogar o Scrum Poker?
  1. Uma vez que o Product Backlog esteja organizado, o Scrum Master (que não joga Poker) senta junto com o time com o topo do Product Backlog priorizado e quebrado em tarefas.
  2. O Scrum Master lê a tarefa em voz alta e responde dúvidas dos desenvolvedores, cada qual com seu baralho de Scrum Poker em mãos. O ideal é que ele comece com a tarefa mais fácil de todas,
  3. Cada desenvolvedor escolhe uma carta do seu baralho, em segredo, baseado no quão complexo acha a tarefa.
  4. Depois que todos escolhem suas cartas em segredo, revelam-se as escolhas, sendo que o Scrum Master é o facilitador dessa dinâmica. Compara-se os resultados e:
     • Se todos forem iguais, anota-se o número obtido junto à tarefa e reinicia-se a dinâmica com a próxima tarefa a ser estimada.
     • Se houver divergências, o desenvolvedor que escolheu a carta com menor valor justifica sua posição. Depois o desenvolvedor que escolheu a maior carta justifica sua posição. O Scrum Master também é convidado a explicar melhor esta tarefa. Todos jogam novamente até entrarem em consenso.
  5. Depois que todas as tarefas prioritárias foram estimadas (ou ao menos que o feeling lhe diga que já passaram tempo demais estimando tarefas) o time de desenvolvimento, baseado nas prioridades, seleciona quais tarefas ele se compromete a executar nesta Sprint.

Capítulo 6: Como priorizar o Product Backlog

• Cortando o escopo: gerentes de projeto tem de lidar com escopo, custo e prazo nos projetos. Dificilmente conseguimos equilibrar essas três variáveis e, na minha opinião, escopo é a que faz mais sentido cortar.
• Princípio de Pareto Use o Princípio de Pareto ou a “regra do 80/20”,
• Scrum enfatiza o foco na geração de valor para o cliente a cada entrega e a chave para geração de valor é reduzir o desperdício priorizando muito bem o que deve ser DONE em cada Sprint, já que apenas 20% de tudo que for desenvolvido será utilizado realmente.
• Priorizar as features baseado no que agregaria mais valor ao cliente o mais rápido possível. Assim, em três sprints teremos um app de cartão funcional com os 20% de features que trazem 80% dos benefícios.
• O quê seu usuário mais utiliza no dia-a-dia? Entregue primeiro o que ele espera como “mínimo viável” em produtos do seu nicho.
• Buy a Feature Game: método de priorizar tarefas, onde os jogadores compram as features. Como jogar?
  1. Primeiro, escreva as histórias ou features do seu projeto em cards e deixe-os todos espalhados em uma mesa. Não traga qualquer feature aqui, apenas aquelas que já estão no roadmap próximo.
  2. Primeiro, escreva as histórias ou features do seu projeto em cards e deixe-os todos espalhados em uma mesa. Não traga qualquer feature aqui, apenas aquelas que já estão no roadmap próximo e/ou são minimamente importantes ao projeto. Cada card postado na mesa deve ser lido, com a atenção de todos. O ideal é que cada card possua um “preço” também, que pode ser a estimativa de horas para desenvolvimento ou os story points, mas se não estiver tudo estimado, não invalida a dinâmica, apenas reduz um pouco a sua eficiência.
  3. Para cada um dos envolvidos na priorização (de 4 a 7), geralmente stakeholders ou até mesmo usuários, entregue à eles um maço de notas falsas, tipo Banco Imobiliário. Se todas as tarefas estiverem estimadas e com “preço”, some os preços, divida o valor pelo número de participantes e distribua esta quantia em notas para cada participante (poucas notas grandes, muitas notas pequenas).
  4. Já se não estiver tudo estimado mas se você estiver trabalhando com story points ou horas e já souber quanto o seu time entrega por sprint, divida essa quantia entre os participantes em notas, seguindo aquela mesma lógica do Banco Imobiliário.
  5. Sem nenhuma regra, cada participante pode depositar o seu dinheiro sobre cada card, representando o seu interesse e/ou o quanto aquela feature vale a pena ser implementada. Esta limitação de dinheiro ilustra bem as limitações reais de um projeto como a verba, as horas-homem, etc.
  6. Caso seus cards possuam outras limitações, como precedência, crie combos de produtos do tipo “para comprar esse, tem de comprar o outro primeiro”.
  7. Quando todos terminam sem dinheiro (deixe que discutam e troquem as notas de lugar até o final da dinâmica), basta somar quanto cada card recebeu e os que receberam mais dinheiro são os mais prioritários. Opcionalmente, se estiver trabalhando com as estimativas, uma feature só vira de fato prioridade se ela recebeu um valor mínimo equivalente ao valor necessário para sua compra.
  8. Permita uma pequena discussão sobre o resultado da distribuição de notas logo após exibir os cards que se mostraram mais prioritário

Capítulo 7: Como refinar o Product Backlog

• O Product Backlog é o artefato ágil para gerenciar os requisitos de um determinado produto. Este artefato é de domínio exclusivo do Product Owner, que refina-o constantemente para que os itens mantenham-se priorizados (usando diversas técnicas), detalhados e que façam sentido com a estratégia de mercado em cima deste produto.
• Quem prioriza o Product Backlog é o Product Owner, que deve priorizar o que é mais urgente, trará maior valor aos clientes ou trará o ROI mais rapidamente. Obviamente que o mesmo deve estar alinhado com a estratégia da empresa para não criar um produto que não ajude a organização a atingir a sua visão.
• A construção do product backlog é um trabalho criativo, iterativo e incremental.
  • Mantenha um estoque de itens priorizados e detalhados para até um mês à frente, no máximo. Mais do que isso e a chance de você jogar muito trabalho fora é enorme.
  • Features que não são debatidas, priorizadas ou detalhadas há mais de um mês devem sair do Product Backlog.
  • Histórias incompletas: As histórias devem sempre buscar entregar valor ao usuário final, de uma ponta a outra, o chamado “fatiamento vertical de features”.
  • Itens de backlog: soltos Todo item de backlog deve fazer parte de uma hierarquia que faça sentido dentro da estratégia do produto, para que seja possível entender porque ele é importante ou onde ele se encaixa.
• O papel do P.O. é definir para ‘quem’ criamos ‘algo’ e ‘porquê’, mas jamais ‘como’ o time deve fazer isso.
• O Product Owner tem a palavra final sobre o Product Backlog, mas ele sempre deve ter argumentos para explicar a sua priorização e detalhamento.
• Dificilmente o Product Owner irá se atentar ou mesmo priorizar débito técnico. Cabe ao time levantar esta bandeira quando necessário.

Capítulo 8: Qualidade e Definição de Pronto

• Definição de Pronto (Definition of Done, no original) é um artefato Scrum usado para garantir a qualidade do produto desenvolvido a cada Sprint. Um documento, um contrato entre os membros do Time Scrum e demais envolvidos para que todos entendam o que um produto “pronto” (done) significa.
• Um primeiro ponto a se considerar é que a criação da definição de pronto deve ser realizada de maneira colaborativa, ou seja, por todos os membros do Time Scrum.
• Comece simples e avance rapidamente. Lembre-se que a função deste artefato é garantir a qualidade, mas lembre-se também de se manter ágil.
• Contrato moral: A definição de pronto é algo com o qual o time se compromete a cumprir para garantir a qualidade das entregas.
• Jamais crie uma definição em que não há unanimidade dentro do Time pois caso contrário ela será sabotada, mais cedo ou mais tarde.
• A definição de pronto deve ser clara e não permitir desculpas como “está pronto, só falta testar”. Exemplos:
  • Toda tarefa de software, para ser considerada pronta, deve…"
  • Ter sido atualizada com o controle de versão e permanecer compilando
  • Ter passado nos testes unitários com sucesso
  • Ter passado por testes de uso de outro colega da equipe
  • O código encontra-se dentro dos padrões da empresa
  • Softwares de apoio e documentação atualizados

Capítulo 9: Pipelines com Kanban

• Kanban é uma palavra japonesa para “cartão” ou para “sinalização”, e não é algo originário no mundo de software, sendo usado há décadas na área industrial para o controle de transporte e produção de mercadorias. O Kanban do gerenciamento de projetos é literalmente o uso de cartões para sinalizar o andamento do projeto, então o nome casa muito bem.
• Um Kanban é um painel, tipicamente uma parede, placa de vidro, placa de ferro com pintura epóxi ou fórmica. Esse painel é dividido em colunas, sendo que as mesmas podem variar conforme o projeto ou necessidades da empresa, mas tipicamente vemos essas três colunas:
  • TODO: Nessa coluna listamos as tarefas que devem ser feitas nessa Sprint (curto prazo)
  • DOING: Nessa coluna listamos as tarefas que estão em andamento, que já foram iniciadas. Deve ter também uma sinalização de quem está executando esta tarefa.
  • DONE: Nessa coluna listamos as tarefas concluídas nesta Sprint, que só são removidas após o término da mesma. Os requisitos para que um cartão chegue até esta coluna variam de equipe para equipe e, segundo os métodos ágeis, deve ser documentado em um artefato chamado Definição de Pronto.

• Outras colunas comuns de serem vistas em kanbans de times de software são:
  • IMPEDIMENTOS: Tarefas trancadas por algum motivo, com alguma sinalização do motivo do impedimento. Esta coluna deve ser revisada diariamente pelo Scrum Master a fim de resolver os impedimentos.
  • TESTING: Tarefas que estão em ambiente de testes ou homologação, com alguma sinalização de quem deve testá-la (ou quem está testando atualmente) e quase prontas para a coluna DONE.
  • IDEIAS & SUGESTÕES: Tarefas que surgiram ao longo da sprint, que não foram iniciadas para não atrapalhar o prazo, mas que podem servir de insumo para a próxima reunião de planejamento.
• Em cada uma dessas colunas são colocados cartões contendo a descrição de uma tarefa (geralmente sob a perspectiva do usuário, como uma User Story), o responsável por sua execução (podendo estar vazio no caso da coluna TODO) e o tempo de execução, seja em pontos obtidos no Scrum Poker, pontos de função ou qualquer outra métrica que estiver utilizando. Esses cartões são preenchidos durante o Sprint Planning ou logo após ele, sendo tarefa do Scrum Master.
• Cartões há muito tempo parados na mesma coluna devem ser investigados (principalmente se existir uma coluna IMPEDIMENTOS), cartões novos que surgirem devem ser muito bem pensados se entram ou não no pipeline (uma vez que podem comprometer a entrega final) e assim por diante.
• Cartões de bugs tendem a ter mais prioridade sobre os demais, sendo um dos poucos que podem ser inseridos após o início da sprint.

Capítulo 10: Prazo com Burndown Chart

• O Burndown Chart é uma ferramenta de acompanhamento do pipeline de desenvolvimento, mas do ponto de vista de métricas, e não das tarefas em si.
• Todos os dias o gerente do projeto, ou Scrum Master no caso de times Scrum, deve atualizar o Burndown Chart traçando um ponto no plano cartesiano (eixo x vs. eixo y) e ligando ao ponto do dia anterior como uma reta, criando um gráfico descendente (pelo menos esse é o objetivo). Comparando com a linha ideal sabemos se vamos cumprir ou não o prazo do projeto: se nossa linha de desenvolvimento estiver abaixo da linha ideal, atingiremos o prazo, caso a linha esteja acima da ideal, fracassaremos. Obviamente o dia-a-dia pode fazer com que consigamos compensar dias menos produtivos e buscar novamente a linha ideal.

Capítulo 12: Retrospectivas de Sprint que funcionam

• “A Retrospectiva da Sprint é uma oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na próxima Sprint.”
• Como organizar uma retrospectiva de sprint?
  1. Escolha uma sala da empresa com quadro branco com canetas marcadoras
  2. Na ausência de post-its, recorte pequenos cartões do tamanho de um cartão de visita que já resolve. Um bom número é 3 cartões/post-its por pessoa do time de desenvolvimento. Divida o quadro/mural em três colunas: BOM, MELHORAR e AÇÕES.
  3. Na coluna BOM devemos colocar cartões com aquilo que foi executado e que deu certo, que a equipe deveria manter na próxima sprint como uma boa prática. Na coluna MELHORAR devemos colocar cartões com aquilo que foi executado de maneira ruim e que pode melhorar na próxima sprint. Para cada coisa que precisa melhorar, deve existir um registro na coluna AÇÕES com uma ação concreta e factível para o mesmo. Tem que ser algo que possa de fato ser colocado em prática, preferencialmente que alguém da equipe se comprometa pessoalmente de que não irá acontecer na próxima sprint.
  4. As regras de preenchimento são: apenas um fala por, e somente aquele que estiver portando um token (como uma caneta hidrográfica). Esta pessoa escreve em um cartão/post-it de forma resumida e gruda no quadro/mural na coluna que tem a ver com sua contribuição.
  5. Ao término da retrospectiva o Scrum Master coleta os dados e garante a cobrança dos indivíduos sobre as considerações para que não tornem a aparecer na próxima Sprint.

Capítulo 16: Princípios acima de processos

• Princípio 1: Empirismo
  • Scrum é um framework empírico, criado com base em décadas de experiência dos seus fundadores à frente de projetos de software e essa é a filosofia central dele.
  • Scrum enfatiza que você aprenda com a sua experiência ao longo das sprints. Que você se baseie no empirismo da sua própria trajetória para, no mínimo, não cometer os mesmos erros.
• Princípio 2: Auto-organização
  • As pessoas entregam significativamente um maior valor quando são auto-organizadas e isto resulta em times mais satisfeitos e responsabilidade compartilhada; e em um ambiente inovador e criativo que é mais propício ao crescimento.
• Princípio 3: Colaboração
  • Esse princípio concentra-se nas três dimensões básicas relacionadas com o trabalho colaborativo: consciência, articulação e apropriação.
  • Quanto maior o objetivo, maior a necessidade de se trabalhar em equipe, de maneira colaborativa.
• Princípio 4: Priorização Baseada em Valor
  • O foco do Scrum é entregar o máximo de valor de negócio possível, durante todo o projeto.
  • Software funcionando é mais importante do que documentação abrangente.
• Princípio 5: Time-boxing
  • O tempo é considerado uma restrição limitada em Scrum, e que ele deve ser usado para ajudar a gerenciar o planejamento e execução do projeto com eficácia. Os elementos Time-boxed em Scrum incluem os Sprints, as Reuniões Diárias, a Reunião de Planejamento da Sprint, e a Reunião de Revisão da Sprint.
• Princípio 6: Iterativo-Incremental
  • Um desenvolvimento iterativo-incremental é aquele cujas etapas se repetem indefinidamente, e a cada iteração, um novo incremento do produto é entregue pronto.