Concluído e desfeita

Por Ken Schwaber e David Starr, Scrum.org

Janeiro de 2012

Fornecer um Incremento concluído é importante para ter êxito com o desenvolvimento de software ágil.O usar exemplos do mundo real e teórico, os autores mostram a diferença entre a percepção entre “concluído” e a realidade de “concluído,” e como isso afeta o sucesso de um projeto.Usando esses exemplos, OS autores passam a demonstrar as ferramentas e as estratégias que podem ajudar o início de equipes com uma definição de "concluído" que faz sentido para eles, e métodos para ajudar as equipes a comunicar dependências, status, e o significado de “concluído”.

Aplica-se a

Gerenciamento do ciclo de vida do aplicativo; Team Foundation Server

Neste artigo:

• Introdução

• Transparência Perdida na Empresa de Anna

  • Que as pessoas pensaram que estava acontecendo

  • O que ocorreu realmente

  • A Lição

• Débito técnico em Nanomedtronics AZ

  • Que as pessoas pensaram que estava acontecendo

  • O que ocorreu realmente

  • A Lição

• O débito técnico amplifica com várias equipes

• O plano de versão na A Datum Corporation

  • Que as pessoas pensaram que estava acontecendo

  • O que ocorreu realmente

  • A Lição

• Técnicas de grande escala para ser feito

  • Scrum de Scrums

  • Integração contínua

• Conclusão

O scrum é uma estrutura ágil iterativa e incremental.As equipes usam para fornecer rapidamente Incrementos de “concluído” ou potencialmente funcionalidades de software úteis em cada iteração, ou Sprint.

“Pronto” é uma palavra simples mas geralmente má interpretada.Para mim, significa concluído, finalizado, e concluído.Ser feito significa que não há nada deixado para fazer.Concluído é simples para definir; no entanto, entregar um Incremento concluído permanece um dos requisitos fundamentais e mais indescritíveis de Scrum e agilidade.

Agilidade exige o fornecimento realizado, incrementos prontos para uso de trabalho do software em cada Sprint.Ainda assim a maioria das equipes ágeis e de Scrum geram incrementos parcialmente incompletos, concluídos.Quando uma equipe de scrum for solicitada porque os requisitos de Retorno do Produto não foram feitos através de uma Sprint, os membros da equipe respondem com frequência, “nós não tivemos tempo.”

Esse documento aborda problemas relacionados ao incrementos concluídos através do exemplo de casos de estudo verdadeiros do início do scrum.Os nomes e localizações dos envolvidos foram alterados, mas estou certo de que as pessoas irão reconhecer a si mesmas e seus trabalhos árduos.Em todo este artigo todas as sprints são uma iteração mensal, salvo indicação contrária.

Transparência Perdida na Empresa de Anna

Anna precisa automatizar o recebimento do seu departamento de alterações de título de propriedade.A empresa que ela trabalhado para os gasodutos criados e operados através de grande parte da América do Norte.Os direitos processados e pagos do departamento para as pessoas que possuíram a terra se cruzaram.As informações de título recebidas pela departamento da Anna eram impressões ou papéis de alteração de propriedade.O volume estava ficando incontrolável, portanto Anna quis automatizar o processo de pagamento de feeds e de royalties.

Nossa Equipe de Desenvolvimento sugeriu que construíssemos o sistema de royalty de Anna usando Scrum.Isso garantiu que ela tivesse uma peça útil de software a ser inspecionada todo mês.Ela também tinha o direito de mudar de ideia todo mês sobre o que nossa equipe faria em seguida.

Até o final do terceiro Sprint, nós tivemos um feed de uma das províncias e integramos com dados antigos.Demonstramos isso com o uso de uma solução SQL simples.Anna estava muito feliz porque a maioria do Retorno de Produto da sua equipe foi desta província.

Ela queria que ensinássemos SQL para sua equipe para que eles pudessem começar a usar imediatamente o software que a equipe de desenvolvimento tinha entregue.

O ela quis dizer sobre que o usar?Certamente ela não interpretou como concluído com um Sprint sendo realizado no software!

Nós dissemos isto a Anna da forma mais cuidadosa possível.Ela ficou pálida.“O que você quer dizer com não está pronto?Eu vi o primeiro Incremento, o segundo Incremento, e agora quero começar usando-os.Implante e ensine o SQL para que você possa usá-lo.”

Começamos a nos sentir inquietos.Nós dissemos a Anna que, sim, isso foi feito.Mas, não era esse tipo de realização.Foi feito para mostrar a ela, mas havia questões que ainda eram necessárias resolução antes que o software pudesse ser usado:

• Alguns registros de entrada não puderam ser processados.Nós precisamos de um recurso para armazená-las e gerenciar, em vez de jogar fora.

• Vários dos campos em registros de entrada pareceram ser usados para propósitos diferentes dos documentados.O que devemos fazer com eles?

• Os campos no banco de dados existente contiveram ponteiros ou informações que pareciam informações de referência.Isso estava em todo o banco de dados.

• Quando os nós executávamos feeds de entrada e consultávamos o banco de dados, o sistema falhou várias vezes.Parecia com dados que foram corrompidos durante estas falhas.

Anna perguntou quanto tempo irá passar antes que nós possamos criar seu tipo, uma realização usável.Estimamos outras duas Sprints necessárias para tornar os incrementos úteis.Ela nos disse para prosseguir e prepará-lo para uso do departamento.Então, ela me “solicitou” a reunir-me com ela na manhã seguinte.

Na manhã seguinte, Anna, sua chefe, e o diretor de desenvolvimento estavam lá.Eles expressaram seu desapontamento por que a transparência da qual eu havia falado tanto não estava presente.Eles sentiram que eu deveria ter tratado dos problemas não resolvidos em vez de apenas gravá-los como bugs.Eles foram incomodados porque o progresso refletido nos relatórios de burndown fornecidos a todos estava incorreto.

Após a reunião, nossos pedidos de marcha eram:

1. Investigar e corrigir os quatro bugs.

2. Conclua e implante os três primeiros Incrementos, para que o departamento de Anna possa começar a usá-los.

3. Melhorar nossas habilidades de engenharia e automação de teste para a nossa definição de feito era a mesma da definição da Anna (imediatamente utilizável pela empresa).

4. Altere a maneira como gravamos os defeitos de modo que o requisito não seja considerado concluído a menos que eles sejam corrigidos.

   Nós soubemos que isto seria uma boa oportunidade de aprendizado, se todos nós aprendemos nossas lições.

Que as pessoas pensaram que estava acontecendo

Quando nós desenvolvemos um plano da linha de base do sistema, ele representava o que os participantes e Anna pensavam que aconteceria.A equipe de desenvolvimento relatou o progresso que pareceu como se a versão estivesse no caminho certo, e as pessoas confiaram no relatório.

Na verdade, a equipe de desenvolvimento pensou que estava fazendo a coisa certa mostrando que o trabalho estava sendo realizado conforme prescrito no plano.

O que ocorreu realmente

A velocidade é a medida e o registro histórico de produtividade de uma equipe de desenvolvimento por sprint.A velocidade é medida a cada Sprint e usada para estabelecer padrões de produtividade.

Para alcançar a meta, nossa Equipe de Desenvolvimento precisava de uma velocidade sustentada de oito unidades completas de trabalho em cada Sprint.Quando algo ameaçou diminuir a velocidade abaixo de 8, nós não concluímos todo o trabalho nesses itens.

Nós entregamos a funcionalidade que trabalhou consideravelmente bem, mas não esteve completa suficiente para usar ou criar.Nós pretendemos melhorar isso posteriormente.Quando nós voltamos para estimar o trabalho desfeito, ele adicionou outras 14 unidades de trabalho.

Dado a dificuldade das alimentações de título inicial, nós reprojetamos todo o plano para refletir uma agenda provável de vinte meses.O departamento de Anna liberou incrementos a cada dois ou meses, permitindo novos feeds.Os novos feeds automatizados reduziram tanto o trabalho manual como um todo, que foi decepcionante quando o sistema entrou em operação vinte e dois meses após ter sido iniciado.

A Lição

A verdadeira transparência exige que todos que exibe o Incremento vejam e entendam a mesma coisa.A inspeção transparente do incremento deve dar permissão a Anna para gerenciar riscos e ganhar a previsibilidade.No entanto, uma vez que o Incremento não era transparente, ela não poderá efetivamente planejar.

No início do projeto, Anna estabeleceu um objetivo de versão.Após o Sprint 1, ela avaliou o progresso em direção ao objetivo inspecionando o que pensou ser um Incremento útil.Ela tomou uma decisão sobre o que fazer no Sprint 2 com base no progresso incremental para o objetivo.Se ela tivesse pensado que o nosso progresso foi inadequado, ela poderia ter cancelado o projeto.

Em o final de sprint 3, Anna 3/10 total de acreditou que foram feitas, que está obviamente incorreto.

Infelizmente, nós tínhamos feito somente o suficiente de cada incremento para demonstrar.O trabalho não concluído inutilizou os incrementos para o departamento de Anna e opacos para a inspeção.

Exibir opacidade durante a inspeção de um incremento é equivalente a cobrir um termostato com uma toalha molhada.O termostato não sabe direito qual é a atual temperatura ambiente da sala, e iniciaria incorretamente o aquecimento em vez da refrigeração.

Sem os incrementos transparentes, os participantes não têm uma compreensão correta do que está acontecendo na verdade e podem incorretamente tomar ações que não fazem sentido.

Em suma, sem total transparência, a capacidade das equipes para inspecionar e adapta-se efetivamente é perdida.

Débito técnico em Nanomedtronics AZ

O débito técnico o trabalho adiado que deve ser concluído antes do software ser considerado concluído.O débito técnico tem várias formas como um design ruim, uma duplicação de código e recursos não testados.O exemplo a seguir demonstra a causa e o impacto do débito técnico como trabalho não concluído no decorrer de um projeto.

A Nanomedtronics AZ era uma pequena empresa startup de software.Eles tinham uma equipe de scrum trabalhando em uma nova versão do produtos críticos à vida; software usado por robôs nano para limpar as artérias obstruídas de pacientes que sofrem de pressão arterial alta.

Que as pessoas pensaram que estava acontecendo

Quando a equipe inicia, são encarregados para selecionar itens de Retorno de Produto para transformar em algo concluído (nenhum trabalho permanece, útil, potencialmente despachável) em uma sprint de um mês.A equipe de desenvolvimento tinha todas as técnica para desenvolver totalmente os requisitos em um incremento concluído.

Como a Equipe de Scrum começou o primeiro Sprint, visto que havia 80 unidades de trabalho que devem ser concluídas em 10 meses.Da mesma forma, a Equipe de Desenvolvimento selecionou respeitosamente 8 unidades de trabalho em cada Sprint.Eles perceberam que, executando apenas 8 unidades por sprint, eles estariam prontos dentro dos 10 meses exigidos pela empresa.

A equipe de desenvolvimento mostrou um incremento de trabalho no final de cada sprint.Por todas as impressão externas, o Scrum estava trabalhando e a Nanomedtronics AZ estava na trilha para fornecer seu produto como esperado.

O que ocorreu realmente

O que não estava claro além da Equipe de Desenvolvimento era que cada incremento entregue incluía realmente algumas implementações ruins, bugs não críticos, lógica repetida e o código geralmente desarrumado.Além disso, os Incrementos não foram totalmente testados porque a Equipe de Desenvolvimento parou de testar quando pressionada por hora em um Sprint.A equipe de desenvolvimento se comprometeu a cumprir o cronograma, e diminuir a qualidade foi geralmente a maneira de se manter no rumo.

A equipe trabalhou duro e compilou seu produto ao longo dos 10 meses.O cliente ficou encantado, e se preparou para implementar e usar o software.No entanto, a Equipe de Desenvolvimento havia acumulado 48 unidades de trabalho desfeito, mostrado na figura a seguir como novo débito técnico.

A equipe da Nanomedtronics AZ não considerou todas as atividades e o trabalho iria realmente precisar ser feito.O exemplo a seguir inclui coisas que a equipe não considerou, e ela não é nada exaustiva.Há muito mais coisas que podem ser incluídas.

• Análise

• Design

• Análise de dependência

• Teste de desempenho

• Teste de estabilidade

• Refatoração

• Teste de resposta imunológica

• Integração com o trabalho de quaisquer outras equipes que trabalham em um produto

• O teste de integração com o trabalho de outras equipes para o Incremento é a totalidade de todas as contribuições da equipe

• Notas de versão

• Internacionalização para as seis culturas onde o produto será vendido

• Teste de aceitação do usuário

• Testes de regressão

• Revisão de código

O trabalho acima deve ser feito para criar um Incremento completo e integrado até o final do Sprint.No entanto, a maioria das Equipes de Desenvolvimento não chegam a concluir todo o trabalho acima.Eles deixam para trás algum trabalho “não concluído” a cada sprint.Isso cria incrementos com um design pobre, código duplicado, lógica demasiadamente complexa, funcionalidade ou recurso não testado, ou outra forma de incompletude.É assim que as equipes criam uma dívida técnica no software.

A Nanomedtronics AZ descobriu que seu produto tinha todos os recursos necessários para ser oferecido aos clientes, mas também tinha muitos defeitos e não apresentava a embalagem e os detalhes de acabamento necessários para ser colocado efetivamente no mercado.A equipe de desenvolvimento tinha criado inadvertidamente uma lista de pendências de trabalho adicional, que levaria outros 6 meses para ser concluída, supondo uma velocidade já incorreta de 8 unidades por sprint.

A espera de 6 meses para enviar o produto não for aceitável para os líderes da empresa e o produto é enviado com o trabalho por fazer pendente após apenas 3 meses.O potencial perdido não foi apenas o atraso de 3 meses no envio do produto, mas na capacidade lenta de adicionar novos recursos, como a Equipe de Desenvolvimento agora teve que se esforçar com o débito técnico em sprints futuros.

A Lição

O débito técnico obscurece o progresso verdadeiro e nubla a transparência necessária para a tomada de decisão empírica pelo Proprietário do Produto e participantes.O débito técnico será paga de volta, tanto no tempo gasto deliberadamente para corrigir problemas técnicos ou na perda devido ao enviar atrasado ou com má qualidade.

Na maioria das situações, pelo menos 50% do trabalho desfeito permanece nos produtos quando eles são liberados.Da mesma forma, o trabalho desfeito se torna institucionalizado como débito contínuo.O débito técnico causa rapidamente uma fragilidade do produto e por fim pode forçar tomadas de decisões de negócios negativas como o investimento na recompilação do software ou o abandono de um produto.

O débito técnico amplifica com várias equipes

Uma Equipe de Desenvolvimento deve escolher cuidadosamente somente a quantidade de trabalho que pode fazer em um Sprint.A equipe de desenvolvimento aprende quanto trabalho é isso através da experiência.Ainda, uma equipe precisa implantar práticas de engenharia modernas como testes automatizados de compilação e regressão para realizar grande do trabalho.Se eles não estão empregados, o trabalho manual tende a sobrecarregar uma equipe pelos quartos ou quintos Sprints.

Considere uma Equipe de Desenvolvimento de três programadores e dois especialistas de QA.Cada dia os programadores estão verificando o código no sistema de código-fonte.Ele está sendo testado e os bugs são detectados e dados para o programador certo.O tempo decorre entre o código de verificação e os defeitos que estão sendo detectados e relatados.Durante esse tempo, os outros programadores que podem ter verificado o código no código defeituoso.O esforço necessário para corrigir o problema inicial é maior agora.Se a Equipe de Desenvolvimento tinha um recurso de compilação e teste contínuo, o erro teria sido detectado imediatamente.Antes de prosseguir, as pessoas teriam investigado e corrigido o erro.O trabalho adicional e o desperdício poderiam ter sido evitados.

Várias organizações usam mais de uma Equipe Scrum para criar o software.Quando isso acontece, o problema de serviço de débito descrito na seção anterior se torna muito amplificado.As oportunidades para fazer o check-in de um código em cima de um código defeituoso são significativamente maiores.O custo para remediar a fragilidade crescente do software aumenta exponencialmente conforme o trabalho progride.

O plano de versão na A Datum Corporation

Eu trabalhei recentemente com outra empresa que eu chamarei de Uma Empresa de Referência, uma empresa de software de infra-estrutura.A principal linha de produtos emprega mais de 800 desenvolvedores, incluindo 250 programadores.A infraestrutura de desenvolvimento era parcialmente automatizada e parcialmente manual.O teste frequentemente atrasou a codificação por dias.O tempo entre um programador fazer o check-in do código defeituoso e ele começar a ser detectado e reportado geralmente era de dez ou mais dias.

Para minimizar a complexidade de tantos desenvolvedores, cada equipe de desenvolvimento trabalhou em sua própria ramificação de código.Os gerentes de desenvolvimento ajudaram a organizar os requisitos da lista de pendências do produto a fim de minimizar as dependências.Se cada Equipe de Desenvolvimento mesclar seu código na linha do código principal todo dia, a quantidade de reformulação potencial seria minimizada.

No entanto, o gerenciamento sentiu que isto levaria muito tempo.O gerenciamento decidido para fundir todas as ramificações do código na raiz em cada terceiro Sprint.Testes de integração localizariam quaisquer defeitos, que passariam então a ser corrigidos.Um candidato de versão deve estar pronto até o final da cada terceiro mês.

Que as pessoas pensaram que estava acontecendo

A figura a seguir mostra o cronograma e o ciclo de versão planejados.

O suposto plano original:

• 9 Sprints

• 3 candidatos de versão e uma versão completa

• Uma organização de desenvolvimento de 800 pessoas

O que ocorreu realmente

Quando essa organização obteve a data de lançamento após nove sprints mensais, o produto não estava pronto para lançamento.O sexto candidato de versão tinha mais de 5.000 defeitos e mais de 2.000 requisitos da lista de pendências do produto estavam incompletos.Nós quisemos saber como isso poderia ser.Nós tínhamos enviado um candidato de versão a cada três meses.Quando nós investigamos, nós constatamos que a demonstração fossem de cada ramificação de código da Equipe de Desenvolvimento.Nenhuma integração havia ocorrido.Nenhum teste de integração havia ocorrido.

Para manter a velocidade necessária para a data de lançamento, as equipes de desenvolvimento tinham adiado qualquer trabalho de integração, criando assim uma grande quantidade de débito técnico.O resultado foi um deslocamento de oito meses da data de lançamento agendada.As palavras “release candidate” não tinha significado.

A figura a seguir mostra o projeto real mais o tempo necessários para a estabilização.

Os candidatos de versão tinham trabalhado parcialmente a funcionalidade da ramificação do código para cada equipe.Cinco meses de “estabilização” foram necessários antes do lançamento.Um defeito particularmente desagradável que atrasou a entrega mais do que os outros foi o “desempenho ruim”. Esse problema foi registrado no primeiro Sprint.

A Lição

Equipes diferentes trabalhando no mesmo software eventualmente mesclarão seu trabalho.Integrar software para garantir que ele funcione reduz o risco de integrações e deve ocorrer com frequência.

Aguardar para mesclar o trabalho de várias equipes é tentador visto que permite atrasar o custo de mesclagem.Entretanto, o custo final do atraso é exposto pelo número de equipes envolvidas e o número de ramificações que devem ser integradas.

Técnicas de grande escala para ser feito

É difícil alcançar um estado de “concluído” em várias equipes.As complexidades envolvidas são várias.As dependências entre as equipes e entre ramificações de código existem.Embora essa complexidade de escala custe, é realizável e oferece um valor tremendo quando as equipes sincronizadas entram em ritmo.

Há diversas técnicas que eu achei úteis quando várias equipes trabalham juntas.

Scrum de Scrums

Quando muitas equipes de scrum estão trabalhando no mesmo projeto, elas precisam de uma técnica para coordenar seu trabalho.Eu recomendei um “Scrum de Scrums”. Este é um evento diário, realizado imediatamente após o Scrum diário de cada equipe.Alguém técnico de cada equipe participa.Cada representante da equipe descreve o que sua equipe acabou de trabalhar.Ele ou ela descreve o que planeja para trabalhar no próximo dia.Baseado nessa informação, os representantes tentam identificar qualquer retrabalho necessário, qualquer próxima dependência e todo trabalho que pode precisar ser reprogramado.

O scrum do scrums foi útil para várias organizações.No entanto, isto é inadequado.As dependências e o retrabalho podem ou não ser identificados com êxito, porque os problemas são antecipados em vez de conhecidos.As dependências não antecipadas causaram retrabalho e testes com falhas.Algumas equipes gastam mais de 50% de cada sprint trabalhando e retrabalhando nas dependências.

Integração contínua

A Programação Extrema (XP) exige integração contínua e teste de integração de trabalho de uma equipe.Por que não estender a todas as equipes?Se há duas equipes ou cinquenta equipes, as equipes são solicitadas a gerar um incremento integrado, com a integração testada ao final da cada Sprint.Para fazer isso, as equipes precisam frequentemente integrar seu trabalho.Como qualquer trabalho não integrado pode conter dependências não resolvidas, a integração contínua é a melhor solução.

Integração contínua de todo o trabalho é semelhante às técnicas de produção magra.Em linhas de produção leves, muitas técnicas são usadas para avaliar a qualidade de um produto ao longo do processo de produção.Quando ocorrem desvios ou problemas de qualidade, a linha de produção é interrompida.Integração contínua e testes de integração fornecem as mesmas técnicas para o desenvolvimento de produtos de software.

Tão duro quanto é, recomendo que cada equipe e membros da equipe pare de codificar se uma compilação contínua ou teste falhar.Qualquer trabalho de continuação está potencialmente acumulando falhas, causando um efeito de ondinha de erros.Se a integração contínua é usada, as equipes trabalham em conjunto para evitar a falhas de integração.Seus hábitos de trabalho melhoram, o desperdício é reduzido e a qualidade aumenta.

A maioria das organizações que adotam o Scrum não começam usando todas as ferramentas e habilidades da engenharia para criar um incremento concluído.Um programa rigoroso para obter incrementos feitos deve ser iniciado e acompanhado.Os grupos com menos de cinquenta pessoas podem rapidamente alcançar um estado onde estão completando um Incremento de conclusão no Sprint.As organizações com mais de quinhentos desenvolvedores geralmente precisam de alguns anos para chegar nesse ponto.

Os incrementos desfeitos geram desperdício e impedem as equipes de atingirem a verdadeira agilidade.O custo real de trabalho não concluído é muito maior que a falta de um recurso ou função no incremento.O custo incluem os desperdícios de replanejamento e trabalho necessários quando um Incremento não é totalmente realizado, bem como os custos de baixa previsibilidade a alto risco.

Várias organizações querem os benefícios de agilidade, e empregam o Scrum para obtê-la.Fornecer um Incremento concluído é importante para ter êxito com o desenvolvimento de software ágil.As equipes devem começar com uma definição da conclusão que faz sentido para eles e então expandir deliberadamente a definição ao longo do tempo.Só nesse momento, eles realmente conseguirão agilidade.

Consulte também

Conceitos

Planejamento ágil e iterações

Comece como equipe

Criar ou adicionar à lista de pendências de produto

Limpar e estimar a lista de pendências

Executar uma iteração

Concluir uma iteração