Como o Scrum cria um limite de qualidade transparente e compartilhado para o Increment - e por que trabalho inacabado, padrões organizacionais, qualidade compartilhada do produto e evolução contínua do conceito de Done são essenciais para um empirismo confiável
Tempo estimado de leitura: 30 minutos
Por João Ricardo Dutra••Artigo completo
Objetivo do capítulo
Ao final deste capítulo, você deverá compreender profundamente o que Done significa no , explicar a como o compromisso associado ao , relacioná-la à transparência e à qualidade do produto, entender os padrões organizacionais e as Definitions of Done compartilhadas, explicar o que acontece com Items incompletos, distinguir um utilizável de trabalho inacabado e raciocinar sobre como a pode evoluir à medida que o produto e a capacidade do time amadurecem.
Introdução: 'Done' é uma declaração de qualidade, não uma porcentagem de progresso
Ideia central
A existe porque a palavra "done" se torna perigosa quando pessoas diferentes, em silêncio, querem dizer coisas diferentes com ela.
Em muitas organizações, o trabalho passa por vários significados informais de conclusão. Um Developer diz que a codificação está pronta. Um testador diz que os testes ainda não terminaram. A área de segurança informa que a aprovação continua pendente. Operações afirma que a mudança ainda não pode ser implantada. O vê um dashboard marcando 95% de conclusão, enquanto os stakeholders presumem que a funcionalidade já está utilizável. Todos usam a mesma palavra, mas o produto possui várias realidades incompatíveis.
O resolve esse problema tornando a conclusão explícita. A é uma descrição formal do estado do quando ele atende às medidas de qualidade exigidas para o produto. Ela cria transparência ao fornecer a todos um entendimento compartilhado sobre qual trabalho foi efetivamente concluído como parte do .
O conceito faz parte do há muitos anos, mas o Scrum Guide 2020 tornou sua importância estrutural especialmente clara ao defini-lo como o compromisso associado ao . O compromete o com um objetivo de longo prazo. O compromete o com um único objetivo da . A compromete o com um estado de qualidade transparente.
Isso modifica a maneira como o progresso é discutido. Um não corresponde a 90% de um . Ele faz parte de um estado de produto Done e utilizável ou permanece como trabalho inacabado. O esforço despendido pode ser real, mas o não permite que esse esforço produza uma falsa transparência sobre o produto.
A também é mais ampla do que uma lista de verificação de testes. Ela pode incluir quaisquer medidas de qualidade exigidas para o produto: integração, segurança, documentação, desempenho, conformidade, acessibilidade, prontidão operacional, observabilidade, confiabilidade, integridade de dados, padrões de revisão ou verificações específicas do domínio. O deliberadamente não prescreve essas medidas, porque produtos diferentes estão sujeitos a riscos diferentes.
Para candidatos à , as questões sobre frequentemente verificam se você consegue preservar a transparência sob pressão. O pode aprovar uma exceção? Trabalho incompleto pode ser apresentado na ? Várias Teams podem usar padrões de qualidade incompatíveis para o mesmo produto? O time pode reduzir a qualidade quando o escopo previsto da está em risco? As respostas corretas seguem um princípio: se o trabalho não satisfaz a , ele não faz parte do .
O que 'Done' significa no
Na linguagem cotidiana, done pode significar muitas coisas: codificação concluída, análise concluída, enviado para revisão, implantado em teste ou simplesmente algo em que ninguém está mais trabalhando. No , a atribui à palavra um significado preciso relacionado ao produto.
Done significa que o atingiu o estado de qualidade exigido para o produto. O trabalho está integrado, utilizável e suficientemente transparente para que todos compreendam o que de fato foi concluído.
Isso não significa que todo resultado de negócio desejado já tenha sido alcançado. Uma capacidade Done ainda pode falhar em produzir o valor esperado para o cliente. Done é uma declaração de qualidade e conclusão; o valor continua sendo empírico e precisa ser inspecionado por meio dos resultados do produto.
Também não significa que o já tenha sido lançado. Um Done precisa ser utilizável, mas o e a organização podem decidir quando liberá-lo, de acordo com o contexto do produto. O momento do release pode depender de coordenação de mercado, regulamentação, estratégia de clientes ou outros fatores legítimos.
A , portanto, separa duas perguntas que as organizações costumam misturar: "O trabalho do produto está realmente concluído?" e "Queremos liberar agora esse estado concluído do produto?" O exige uma resposta confiável à primeira pergunta para que a segunda se torne uma verdadeira decisão de produto.
Ideia essencial
Done significa que o satisfaz as medidas de qualidade exigidas para o produto. Não significa apenas codificado, testado de forma isolada, aprovado por um gestor ou quase concluído.
como compromisso do
Os representam trabalho ou valor, e cada artefato possui um compromisso que aumenta a transparência e o foco. A é o compromisso associado ao .
A relação é direta. O mostra qual progresso do produto realmente existe. A informa a todos qual estado de qualidade precisa ser alcançado antes que esse progresso possa ser considerado concluído.
Isso evita que o artefato se torne ambíguo. Sem uma , um poderia conter itens em diferentes estados de qualidade ocultos: um totalmente testado, outro aguardando revisão de segurança, outro sem documentação, outro ainda não integrado. Os stakeholders estariam inspecionando um artefato cujo estado aparente não corresponde à realidade.
O Scrum Guide afirma que, no momento em que um atende à , nasce um . Essa formulação enfatiza que a criação do não espera o último dia da . Sempre que o trabalho atinge Done e está integrado, existe progresso real do produto.
A , portanto, não é apenas documentação de apoio. Ela determina o limite entre e trabalho inacabado.
Transparência: por que um significado compartilhado de Done é essencial
O fundamenta-se no , e o depende de transparência. A inspeção só é útil quando o estado inspecionado é suficientemente preciso para sustentar decisões.
Imagine uma em que os stakeholders vejam cinco funcionalidades marcadas como concluídas. Duas ainda precisam de testes de carga, uma precisa de correção de acessibilidade e outra não pode ser implantada sem uma migração manual que ninguém ensaiou. Visualmente, o produto pode parecer impressionante, mas o artefato não é transparente. Os stakeholders estão tomando decisões com base em um quadro incompleto.
A reduz essa ambiguidade. Se testes de carga, acessibilidade e prontidão para implantação forem medidas de qualidade obrigatórias do produto, esses itens não poderão ser contabilizados como parte do até que os critérios sejam satisfeitos.
A transparência também melhora o . Os compreendem o que o trabalho realmente exige para ser concluído ao fazerem a de . Uma forte expõe trabalho de qualidade que, de outra forma, permaneceria oculto até o fim da .
A mesma transparência apoia o . Ele pode raciocinar sobre opções de release, feedback dos stakeholders e progresso em direção ao usando um estado de produto confiável, e não estimativas sobre tarefas de acabamento ainda pendentes.
Cadeia do
clara -> transparente -> inspeção significativa -> melhor adaptação.
Qualidade: a torna a qualidade parte da entrega
A desloca a qualidade de uma atividade posterior para o próprio significado normal de conclusão. Se segurança, desempenho, integração, acessibilidade, documentação, verificação regulatória ou prontidão operacional são exigidos para o produto, essas medidas devem estar refletidas no que Done significa.
Isso altera a economia do time. Em vez de concluir rapidamente a codificação funcional e criar uma fila separada de trabalho de qualidade oculto, os consideram a qualidade ao dimensionar, planejar e implementar Items.
Uma mais forte pode inicialmente fazer o time parecer mais lento porque menos escopo chega a Done. Na realidade, o sistema anterior talvez estivesse contabilizando trabalho de qualidade inacabado como progresso. Uma transparência mais forte pode revelar o verdadeiro custo da conclusão do produto.
O afirma explicitamente que a qualidade não diminui durante a . Se os descobrirem que o escopo previsto é grande demais, a adaptação correta é renegociar o escopo com o , preservando o - e não contornar a .
A qualidade também deve ser apropriada ao produto. Uma plataforma de pagamentos regulada e um protótipo interno de baixo risco podem ter medidas de qualidade diferentes. O não prescreve uma única universal, porque o risco de qualidade depende do contexto.
O que pode fazer parte de uma ?
O não prescreve critérios específicos para a . As medidas devem refletir o estado de qualidade exigido para o produto e quaisquer padrões organizacionais aplicáveis.
Possível dimensão de qualidade
Exemplo de preocupação na
Integração
O trabalho está integrado ao produto atual e não rompe o comportamento existente.
Testes
Os testes automatizados, de regressão, de integração ou as verificações específicas do domínio exigidas foram aprovados.
Segurança
Controles, varreduras, revisões ou verificações de segurança necessárias foram satisfeitos.
Desempenho
Os critérios relevantes de desempenho ou capacidade foram verificados.
Acessibilidade
Os padrões de acessibilidade exigidos foram atendidos.
Conformidade
Verificações legais, regulatórias, de auditoria, privacidade ou políticas aplicáveis foram concluídas.
Documentação
A documentação exigida para usuários, aspectos técnicos, operações ou conformidade está atualizada.
Prontidão operacional
Monitoramento, logging, rollback, suporte ou requisitos de implantação estão disponíveis.
Qualidade de dados
Migração, validação, reconciliação ou medidas de integridade estão concluídas.
Uma útil registra expectativas recorrentes de qualidade do produto que se aplicam de forma ampla. Expectativas funcionais específicas de um item podem permanecer no próprio . Essa distinção evita repetir as mesmas regras de qualidade de produto em todos os itens.
A também deve ser compreensível. Uma referência a uma política de 200 linhas que ninguém consegue avaliar na prática pode criar conformidade formal sem transparência útil. O time deve tornar o estado de qualidade exigido visível e acionável.
versus
e resolvem problemas diferentes. A descreve o estado recorrente de qualidade exigido para o . Os , quando um time decide utilizá-los, descrevem condições ou comportamentos específicos de um determinado .
Por exemplo, a pode exigir testes automatizados de regressão, varredura de segurança, conformidade com acessibilidade, integração e observabilidade em produção para todo trabalho relevante. Um de redefinição de senha pode ter que descrevam expiração do token, comportamento do e-mail e mensagens apresentadas ao usuário.
O não prescreve , mas eles são uma técnica complementar comum. Eles não substituem a , porque satisfazer o comportamento específico do item não comprova que o produto integrado atende ao padrão completo de qualidade.
versus
= limite recorrente de qualidade do produto. = expectativas opcionais e específicas de um item.
versus
A faz parte do . A não faz.
Alguns times criam uma para descrever condições que tornam um mais fácil de selecionar na . Essa prática pode ser útil como complemento, mas não deve ser confundida com o compromisso formal associado ao .
Um gate obrigatório de readiness pode se tornar prejudicial se impedir adaptação empírica ou transformar o refinement em um processo de aprovação. O já fornece e colaborativa para aumentar o entendimento.
Para a , a distinção é direta: a é exigida pelo como compromisso associado ao ; a é opcional e está fora do .
Padrões organizacionais: a organização pode definir o limite mínimo de qualidade
O Scrum Guide trata explicitamente dos padrões organizacionais. Se a para um fizer parte dos padrões da organização, todas as Teams deverão segui-la como requisito mínimo.
Isso significa que não concede a uma permissão para ignorar requisitos legítimos de qualidade do produto ou da organização. Políticas de segurança, requisitos regulatórios, padrões de engenharia, controles de segurança, padrões de privacidade ou requisitos operacionais corporativos podem estabelecer mínimos não negociáveis.
A expressão como requisito mínimo é importante. Uma pode precisar de critérios mais rigorosos para seu contexto de produto. Os padrões organizacionais criam um piso, e não necessariamente a completa para todos os produtos.
Por exemplo, uma organização pode exigir , vulnerability scanning, verificação de dependências aprovadas e audit logging. Um produto de pagamentos pode acrescentar reconciliação de transações e validação de controles antifraude. Um produto médico pode incluir verificações adicionais de segurança e regulamentação.
O não pode dispensar requisitos organizacionais da apenas porque uma funcionalidade é urgente. Da mesma forma, os não podem declarar um item Done usando uma definição local mais fraca quando padrões organizacionais se aplicam.
Regra organizacional
Quando existe um padrão organizacional de , as Teams devem segui-lo como requisito mínimo. Elas podem ser mais rigorosas, mas não menos.
Quando não existe um padrão organizacional
Se a organização não tiver estabelecido um padrão de , a deverá criar uma apropriada para o produto.
Isso mantém a responsabilidade próxima do produto, pois a compreende sua tecnologia, usuários, riscos, stakeholders e ambiente de entrega.
O contribui com o contexto de produto e stakeholders. Os contribuem com o conhecimento técnico e de qualidade necessário para criar um utilizável. O ajuda o time a compreender o e melhorar sua efetividade. O resultado deve ser um limite compartilhado de qualidade do produto, e não uma checklist privada dos .
Os são obrigados a se adequar à . Essa accountability é importante: individuais não podem decidir que determinado critério é desnecessário apenas para o item em que estão trabalhando.
A deve existir cedo o suficiente para informar a , porque os precisam compreender qual trabalho será necessário para que os Items selecionados se tornem parte de um Done.
Uma compartilhada por várias Teams
Quando várias Teams trabalham juntas no mesmo produto, elas devem definir mutuamente e cumprir a mesma .
Essa regra existe porque há um único estado do produto. Se o Time A considera trabalho Done após testes unitários enquanto o Time B exige segurança, integração e verificação de desempenho, o e os stakeholders não conseguem compreender de forma confiável a qualidade do integrado.
Uma compartilhada cria um único significado de conclusão para todo o produto. Os times ainda podem usar práticas internas adicionais ou padrões de engenharia mais rigorosos quando isso for útil, mas o produto integrado precisa atender ao mesmo limite compartilhado de qualidade.
Isso se relaciona estreitamente à existência de um e um para o produto. Vários times podem contribuir com Goals distintos, mas a transparência do produto exige um coerente e um entendimento comum de Done.
O objetivo não é uniformidade burocrática. É integridade do produto. O usuário experimenta um único produto, e não um conjunto de definições de qualidade específicas de cada time.
Âncora para a
Várias Teams em um mesmo produto -> uma mutuamente definida e compartilhada para o integrado do produto.
O que acontece quando o trabalho não atende à ?
O Scrum Guide é explícito: se um não atende à , ele não pode ser liberado nem sequer apresentado na como trabalho concluído do . Em vez disso, retorna ao para consideração futura.
Essa regra protege a transparência sob pressão. Um time não pode rotular um item como Done porque o está disposto a aceitar débito técnico. Não pode transferir testes inacabados para a próxima e ainda contar a funcionalidade como concluída. Também não pode mostrar trabalho parcialmente finalizado como parte do apenas para tornar a Review visualmente melhor.
Retornar ao não significa que o item será automaticamente selecionado na seguinte. O poderá reordená-lo com base no valor atual. Novas evidências podem tornar o trabalho restante menos importante ou até obsoleto.
O item também pode precisar de refinement antes de uma futura seleção. Seu tamanho, descrição ou entendimento técnico podem ter mudado com base no que os aprenderam.
O esforço já investido é um custo irrecuperável. O incentiva o a tomar a próxima decisão de valor usando evidências atuais, em vez de proteger o esforço passado.
Items incompletos e o fim da
Um equívoco comum é imaginar que todo selecionado na precisa ser concluído. Os itens selecionados constituem uma . O é o compromisso associado ao .
Se um item permanecer incompleto no fim da , a não deve estender a nem reduzir a . O item simplesmente não contribui para o .
O decide como o trabalho inacabado deve ser considerado no . Os podem ajudar a esclarecer o que ainda falta e como o novo conhecimento afeta o .
Essa abordagem preserva o da , o e o limite de qualidade. Também gera aprendizado útil sobre fatiamento de trabalho, , dependências, práticas técnicas ou capacidade de cumprir a .
Um utilizável: o resultado econômico de uma forte
Uma forte produz um utilizável. Isso é economicamente importante porque progresso de produto utilizável cria opções.
A organização pode liberar imediatamente, liberar mais tarde, testar um experimento, coletar feedback de stakeholders ou simplesmente continuar construindo sobre um estado integrado e estável do produto. Essas escolhas são possíveis porque o não depende de trabalho oculto de acabamento.
Uma fraca reduz opções. O produto pode parecer concluído, mas ainda exigir estabilização, integração, revisão de segurança, trabalho de ambiente ou verificação manual antes do release. A liberação se transforma em um projeto de recuperação, em vez de uma decisão de produto.
Por isso o conceito de Done no está intimamente ligado à redução de risco. Um estado utilizável e integrado do produto expõe a realidade cedo e repetidamente, em vez de acumular incerteza até o fim de um ciclo de release.
Evoluindo a
A não deve ser tratada como imutável para sempre. Risco do produto, tecnologia, regulamentação, capacidade organizacional e maturidade do time mudam com o tempo.
A é uma oportunidade explícita de inspecionar a . Um defeito recorrente em produção pode revelar uma etapa de verificação ausente. Uma nova regulamentação pode exigir evidências adicionais. Melhor automação pode tornar viável uma medida de qualidade mais rigorosa. Uma nova capacidade de observabilidade pode permitir que a prontidão operacional passe a fazer parte de Done.
A evolução normalmente deve caminhar em direção a maior transparência e qualidade apropriada, e não ao enfraquecimento dos padrões para aumentar uma velocidade aparente. Guides anteriores descreviam explicitamente que times maduros ampliavam sua com critérios mais rigorosos para obter maior qualidade. O Guide 2020 é menos prescritivo na redação, mas ainda inclui a entre os elementos inspecionados na Retrospective e preserva a regra de que a qualidade não diminui durante a .
Uma também pode melhorar sem simplesmente ficar maior. Automação pode eliminar etapas manuais preservando o mesmo resultado de qualidade. Critérios redundantes podem ser esclarecidos. Termos ambíguos podem se tornar mensuráveis. Melhorias devem tornar Done mais confiável, e não apenas mais burocrático.
Princípio de evolução
Uma madura torna-se mais eficaz em criar qualidade transparente e utilizável - não simplesmente mais longa.
A pode mudar durante uma ?
O não define uma proibição especial segundo a qual a jamais possa ser melhorada durante uma , mas qualquer mudança precisa preservar a regra de que a qualidade não diminui e não pode produzir transparência enganosa.
Na prática, os times devem ter cautela com mudanças no meio da , porque os fazem seu com base no limite atual de qualidade. Fortalecer um critério pode revelar trabalho adicional. Enfraquecer a para "salvar" o escopo previsto comprometeria diretamente a transparência e a regra de qualidade do .
O raciocínio mais seguro para a prova é proteger a vigente e usar a Retrospective como uma oportunidade formal de inspecioná-la e melhorá-la. Se um padrão organizacional urgente de qualidade mudar imediatamente, a ainda deverá cumprir os requisitos mínimos legítimos.
Exemplo prático - para um produto bancário de APIs
Imagine várias Teams contribuindo para a mesma plataforma bancária de APIs. O é tornar APIs de pagamentos reguladas confiáveis, seguras e fáceis de consumir pelas equipes internas de produto.
A organização já define padrões mínimos de engenharia: , vulnerability scanning automatizado, verificação de dependências open source aprovadas, logging de produção e evidências de auditoria. Esses elementos tornam-se critérios mínimos da para todas as Teams.
Como o produto processa tráfego de pagamentos, as Teams acrescentam mutuamente critérios específicos do produto: testes de contrato contra versões suportadas da API, verificação de desempenho sob carga esperada, prontidão para rollback, dashboards de monitoramento e identificadores de correlação de transações.
Durante a , os consideram esses critérios ao fazer o . Uma mudança aparentemente pequena em uma API exige mais do que implementação: testes de contrato, verificação de desempenho, varredura de segurança, atualização de documentação e mudanças de observabilidade fazem parte do trabalho necessário para chegar a Done.
No meio da , um time conclui o desenvolvimento funcional de um novo endpoint de validação de token. Os testes unitários passam, mas a verificação de desempenho revela latência inaceitável. O argumenta que a funcionalidade deveria mesmo assim ser apresentada na porque um stakeholder de negócio está ansioso para ver progresso.
A se recusa a chamá-la de Done. A verificação de desempenho faz parte da compartilhada. O item não faz parte do e não pode ser apresentado como trabalho concluído do .
Os continuam investigando. Descobrem uma busca ineficiente de certificado e a otimizam. O endpoint então passa pelos testes exigidos, é integrado à plataforma, atende à compartilhada e passa a fazer parte do .
Outro PBI selecionado - um novo exemplo no portal de - permanece incompleto porque falha na validação de acessibilidade. Ele retorna ao para consideração futura. Não é automaticamente selecionado para a seguinte.
Na , vários times percebem que a preparação manual do ambiente de desempenho atrasa a chegada a Done. Em vez de remover os testes de desempenho da , criam uma melhoria para automatizar o provisionamento do ambiente. Ao longo das Sprints seguintes, a torna-se mais fácil de satisfazer sem reduzir o padrão de qualidade.
Posteriormente, uma nova regulamentação exige evidências de que headers sensíveis nunca sejam registrados em logs. A organização acrescenta isso como padrão mínimo. Todas as Teams o adotam, e a do produto evolui.
Esse exemplo ilustra o papel completo da : mínimos organizacionais, qualidade compartilhada do produto, conformidade dos , tratamento honesto do trabalho incompleto, Increments utilizáveis e do sistema que torna a qualidade possível.
Anti-patterns comuns relacionados à
Anti-pattern
Por que enfraquece o
Done = codificação concluída
Oculta testes, integração, segurança, implantação ou outro trabalho de produto necessário.
pode dispensar a
Transforma qualidade em negociação e destrói a transparência compartilhada.
DoDs incompatíveis no mesmo produto
Cria um produto integrado com qualidade ambígua.
Testing /
Sugere que Sprints anteriores não criaram Increments utilizáveis e Done.
como enorme documento jurídico
Pode satisfazer formalismo sem funcionar como limite prático e compartilhado de qualidade.
Reduzir a perto do fim da
Viola o princípio de que a qualidade não diminui.
Trabalho incompleto apresentado como Done
Engana stakeholders e enfraquece o .
=
Confunde qualidade recorrente de todo o produto com comportamento específico de um item.
=
Confunde um compromisso obrigatório do com uma prática opcional de readiness do backlog.
Sem porque o time é experiente
Experiência não substitui qualidade compartilhada e transparente.
nunca evolui
Ignora mudanças em risco do produto, regulamentação, tecnologia e capacidade.
Mais critérios sempre significam maturidade
Uma madura deve se tornar mais eficaz, e não apenas mais longa.
Armadilhas comuns da sobre
Armadilha
Interpretação correta no
A é opcional.
Falso. É o compromisso associado ao .
O decide se um item está Done.
Falso. Os são obrigados a cumprir a compartilhada.
Um PBI 90% concluído pode fazer parte do .
Falso. Ele permanece fora do até atender à .
Trabalho incompleto pode ser apresentado na como concluído.
Falso. Ele não pode ser liberado nem apresentado como parte concluída do .
Trabalho incompleto entra automaticamente na próxima .
Falso. Ele retorna ao para consideração futura e ordering.
Padrões organizacionais de podem ser ignorados por um time .
Falso. Padrões organizacionais são requisitos mínimos.
Uma sempre pode criar uma local mais fraca.
Falso. Ela precisa cumprir os mínimos organizacionais.
Várias Teams no mesmo produto podem usar DoDs incompatíveis.
Falso. Devem definir mutuamente e cumprir a mesma do produto.
e são a mesma coisa.
Falso. Resolvem problemas distintos de transparência.
é outro compromisso do .
Falso. Não faz parte do .
A deve ser enfraquecida quando o escopo previsto corre risco.
Falso. Adapte o escopo; a qualidade não diminui.
É na que o trabalho se torna Done.
Falso. O trabalho passa a fazer parte do quando atende à .
Um utilizável já precisa ter sido publicamente lançado.
Falso. Utilizável e lançado são conceitos distintos.
A nunca pode evoluir.
Falso. Ela pode e deve ser inspecionada e melhorada à medida que necessidades e capacidades mudam.
Um framework de raciocínio para questões da sobre
Compromisso: a é tratada como o compromisso associado ao ?
Transparência: todos compartilham um único entendimento sobre o que significa trabalho concluído do ?
Qualidade: a resposta preserva a qualidade exigida do produto em vez de trocá-la por mais escopo?
Trabalho incompleto: o PBI permanece fora do até atender à ?
: o trabalho inacabado fica de fora da apresentação do concluído?
Padrões organizacionais: requisitos de no nível organizacional são tratados como mínimos?
Vários times: Teams que trabalham no mesmo produto compartilham e cumprem a mesma ?
Accountability dos : os são obrigados a cumprir a ?
Usabilidade: a produz um utilizável, em vez de trabalho que exige uma fase posterior de hardening?
Evolução: a pode ser inspecionada e melhorada sem reduzir transparência ou qualidade?
Heurística rápida para a prova
Se um não atender à , ele não faz parte do - independentemente do esforço já investido, da pressão dos stakeholders ou de quão próximo pareça estar da conclusão.
Conclusão: Done é a fronteira entre evidência e esperança
A é um dos mecanismos mais fortes do para proteger a tomada de decisão empírica. Ela cria um limite compartilhado de qualidade que informa à , ao , aos stakeholders e à organização qual trabalho faz parte de fato do .
Como compromisso associado ao , a torna a conclusão transparente. Um passa a fazer parte do progresso real do produto somente quando satisfaz as medidas de qualidade exigidas. Até então, permanece como trabalho inacabado.
Essa clareza protege a qualidade sob pressão. O não pode aprovar uma exceção apenas porque o item é valioso. Os não podem chamar o trabalho de Done porque a maior parte da implementação terminou. A gestão não pode contar funcionalidades incompletas como output concluído. Se a qualidade estiver em risco, o escopo pode ser adaptado; o significado de Done não deve ser enfraquecido para salvar uma .
Padrões organizacionais estabelecem o mínimo de qualidade quando existem. Quando não existem, a cria uma apropriada para o produto. Quando várias Teams contribuem para um mesmo produto, uma compartilhada é essencial para que o integrado tenha um único estado de qualidade transparente.
Trabalho que não atende à não pode ser liberado nem apresentado na como trabalho concluído do . Ele retorna ao para consideração futura. Essa regra impede que custo irrecuperável e pressão de cronograma corrompam a transparência do produto.
Uma forte também cria um utilizável. A usabilidade oferece opções à organização: liberar agora, liberar mais tarde, inspecionar com stakeholders, continuar construindo ou coletar evidências do mundo real. Essas opções existem porque trabalho de acabamento oculto não foi adiado.
A deve evoluir à medida que produtos, riscos, regulamentação e capacidade do time evoluem. Maturidade não é medida pelo tamanho da checklist, mas por quão confiavelmente a produz qualidade transparente, integrada e utilizável.
A pode ser entendida como a linha entre evidência e esperança. Times podem esperar que um trabalho inacabado esteja quase seguro, quase integrado, quase liberável ou quase valioso. O exige algo mais disciplinado: torne a qualidade exigida explícita, atenda a ela e somente então trate o resultado como progresso do produto. Essa disciplina é fundamental para o e para o raciocínio esperado na avaliação .
Principais conclusões
A é o compromisso associado ao .
Ela descreve formalmente o estado do quando este atende às medidas de qualidade exigidas para o produto.
No momento em que um atende à , nasce um .
A cria transparência por meio de um entendimento compartilhado sobre trabalho concluído do .
Done não é porcentagem de progresso, status de codificação, aprovação de gestor nem decisão tomada na .
Um que não atende à não faz parte do .
Trabalho incompleto não pode ser liberado nem apresentado na como trabalho concluído do .
Trabalho incompleto retorna ao para consideração futura; não é automaticamente selecionado na seguinte.
Os são obrigados a cumprir a .
Se existirem padrões organizacionais de , todas as Teams deverão segui-los como mínimo.
Se não existir padrão organizacional, a cria uma apropriada ao produto.
Várias Teams que trabalham no mesmo produto devem definir mutuamente e cumprir a mesma .
A ajuda a produzir um utilizável e evita trabalho de qualidade oculto.
A qualidade não diminui durante a ; o escopo deve ser adaptado em vez do limite de qualidade.
é diferente de e da opcional .
A pode evoluir conforme mudam risco do produto, regulamentação, tecnologia e capacidade do time.
Uma madura torna-se mais eficaz em produzir qualidade transparente - não apenas mais longa.
