Ken Schwaber e Jeff Sutherland definiram um artefato muito importante no Scrum: o Definition of Done (DoD), em português a Definição de Pronto. O objetivo do DoD é descrever de forma muito clara para o time Scrum quais as condições necessárias para que um item do backlog (normalmente escrito no formato de user story) seja dado como feito.
Quando o item está pronto, a princípio, não há mais nenhuma tarefa a ser feita. Em empresas que utilizam boas práticas de Devops como a entrega contínua, a única atividade remanescente deveria ser o Product Owner (PO) pressionar um botão e mandar todo o incremento do produto para as mãos dos clientes.
Nós versus eles
Infelizmente, ao longo de anos, criamos especialistas e colocamos esses especialistas em unidades distintas dentro da organização. Acabamos com silos difíceis de dissolver: Desenvolvimento, Testes, Banco de Dados, Produção, Middlewares, Arquitetura, etc.
Hierarquia organizacional reforçando os silos de especialistas.
O resultado comum a diversas empresas são discursos como: “Está ‘pronto’, só falta o time de testes testar”; “Está ‘pronto’, só falta o pessoal do barramento disponibilizar a chamada”; “Está ‘pronto’, só falta a galera de banco de dados rodar um scriptzinho”. Meu favorito: “está ‘pronto’, só falta integrar”.
Integração Tardia
Um time ágil é multidisciplinar. Isso significa que ele deve ser composto por pessoas que tenham todas as habilidades e autorizações necessárias para que uma necessidade de negócio seja transformada em produto e entregue na mão do usuário.
Confira os próximos treinamentos da K21!
Qual o problema do “só falta…”?
Vamos dizer que o Time Azul, muito empenhado, trabalhou com afinco durante a Sprint e conseguiram “entregar” 5 itens que serão testados pelo Time de Qualidade. Por algum motivo, imaginamos que o pessoal de Qualidade, pegará nossa entrega, colocará no backlog deles que está vazio e em algumas horas receberemos o resultado dos testes.
Cenário Imaginário
Cenário bacana, mas falso. Normalmente, quando acontece essa passagem de bastão da entrega, encontramos outros times atolados de coisas para fazer. Além disso, temos um problema de priorização. O que é muito importante para o Time Azul, pode ser a coisa menos prioritária para o Time de Qualidade que está recebendo “entregas” de diversos outros times.
Cenário real
Saiba que esse problema se repete para cada time que você utilizar para completar a frase “Tá pronto, só falta…”. O atraso introduzido pelas dependências é exponencial.
Sprint de Testes
Não, não, não e não. Não existe Sprint de testes separada do desenvolvimento. A Sprint deve englobar todas as tarefas necessárias para que o seu produto esteja pronto para ser disponibilizada para o cliente. Separar a Sprint em partes criará refluxo de trabalho, falta de visibilidade, pouca previsibilidade da entrega e ainda reforçará a ideia de subtimes dentro do time (nós versus eles interno). Pergunte-se: Por que estamos fazendo Sprints separadas? Chegue à causa raiz do problema e resolva-a.
Refluxo no trabalho causando confusão
E como eu saio desse imbróglio?
Traga visibilidade e não esconda os problemas
Caso a sua entrega de valor para o cliente dependa de pessoas externas ao time, não esconda essa dependência. Torne isso visível e dê transparência ao seu processo. Desenhe todas as transições necessárias na cadeia de valor do seu produto. Varrer o problema para baixo do tapete trará efeitos terríveis no longo prazo.
Transparência no Quadro de Tarefas. Dependências externas são visualizadas e marcadas em vermelho.
Gosto de utilizar a seguinte analogia. Imagine que você quebrou o braço. A solução para esse problema é trabalhosa. Procurar um médico, fazer uma radiografia, imobilizar o braço por semanas, talvez até operar. Você está extremamente ocupado e não tem tempo para isso e resolve tomar apenas um remédio para dor. Com o tempo a dor aumenta e você já está tomando morfina, mas ainda se nega a ver a real situação do problema e continua tomando ações pontuais e temporárias. Quando a coisa toda se tornar insuportável poderá ser tarde demais.
Definition of Transition (DoT)
Ao colocar um quadro na parede, defina quais são as condições necessárias para que um item do backlog avance nas etapas do processo. Para cada raia do seu quadro, você pode fazer uma pequena definição de pronto que, neste caso, será uma definição de transição. Utilizando como exemplo a imagem acima, poderíamos ter as seguintes DoT:
- Desenvolvimento
- O código-fonte do programa está versionado
- Testes automatizados garantem a cobertura necessária
- Código foi revisado por par
- O produto está aprovado em 100% dos testes automatizados
- Time de Qualidade
- Aprovado pelo Time de Qualidade
- Nenhum bug impeditivo, crítico ou relevante foi encontrado
- Time de Segurança
- Aprovado nos testes de vulnerabilidade
- Não há nenhum risco impeditivo, crítico ou relevante foi encontrado
- Logs de auditoria adicionados
- …
Repare que a soma do seus DoT ajudam a compor o seu DoD.
Métricas para embasar as discussões
Jamais entre em uma reunião com o discurso: “Eu acho que…”. Isso só vai te desgastar politicamente sem necessidade. Utilize métricas como Customer Lead Time, System Lead Time, Waiting Time, Cost of Delay para embasar esse tipo de discussão.
Melhoria contínua
Em reuniões como as cerimônias de Retrospectiva, levante os desafios que fazem que os times sejam incapazes de fazer a entrega de ponta a ponta. Em alguns casos, pode ser necessário que você tenha que subir os níveis da hierarquia organizacional para resolver o problema. Faça isso sempre embasado com números e demonstrando as consequências dos desafios elencados.
Times multidisciplinares
Por que não temos todas as competências necessárias para fazer uma entrega de ponta a ponta? As respostas a essa pergunta devem ajudar a criarmos estratégias concretas que transforme os times em times multidisciplinares.
Algumas outras perguntas que podem ajudar o time a traçar as ações: Quais as competências nós não temos e precisamos? Temos pessoas interessadas em desenvolver essas competências? Quais silos devem ser quebrados para ter um time ponta a ponta? Qual a competência que nós não temos e mais impacta na nossa entrega? E por aí vai.
Autorização
“Alterar uma tabela no banco de dados. Bem, para isso você precisa: preencher o formulário A-35, B-57 e D-3, ter a assinatura de 3 gerentes Nível 1, abrir uma requisição de mudança, reconhecer firma em cartório, dar 7 voltas na Praça da Sé andando de costas, ter a benção do papa….”
Em muitas empresas o que atrapalha a entrega não é a falta de competências no time e sim a falta de autorização para fazer o trabalho necessário. As respostas que devem guiar as estratégias concretas devem vir de perguntas como: Por que não temos autorização para fazermos tal coisa (seja específico)? Quais os traumas que aconteceram no passado e levaram a essa falta de autorização?
Trabalho em par
“Ah! Mas não é todo mundo que sabe fazer o trabalho que o Time de Testes / Segurança / xpto faz”.
Trabalhe em par para que o conhecimento sobre práticas, tecnologias e conteúdo seja difundido entre os membros do time ou seja trazido para o time. O trabalho em par é uma forma excelente para a constante transformação do conhecimento do time e uma prática para estimular a colaboração.
Práticas de Devops
Muitas empresas ainda possuem unidades inteiras para executar processos manuais e burocráticos que, se não são 100% automatizáveis, podem, ter sua burocracia reduzida significativamente por automação. Procure utilizar práticas como testes automatizados, integração contínua, entrega contínua, versionamento, TI escalável, etc.
Real Definition of Done
Não estou criando um artefato novo. Apenas colocando que o Definition of Done do time deveria ser todo o trabalho necessário para que a única coisa que fique entre a entrega do time de desenvolvimento e a ida do produto para a mão do cliente seja uma decisão de negócio e nada mais.
Se o seu produto deve ser aprovado pelo dono da empresa antes de ser disponibilizado para os clientes, então essa aprovação deve estar no DoD. Se é exigido um manual do usuário, então a escrita e disponibilização do manual devem estar no DoD. Se a entrega deve ser aprovada em testes de segurança, então Aprovado nos testes de segurança deve compor o seu DoD.
Faça com que o DoD do seu time cumpra o propósito dele e descreva exatamente as condições necessárias para que o cliente receba o produto que ele precisa.
Quer saber mais sobre este assunto?
Veja os nossos treinametos
- Certified Scrum Developer (CSD) para entregar a qualidade de ponta a ponta.
- Testes automatizados para garantir a qualidade do seu software antes da primeira linha de código.
- Lean Kanban para saber como dar transparência ao seu fluxo de trabalho e promover a melhoria contínua do seu time.
- CSM para entender os importantíssimos conceitos sobre Scrum
Veja também outros artigos sobre esse tema:
