Um guia aprofundado sobre a accountability dos Developers no Scrum: criação de Increments utilizáveis, responsabilidade pelo Sprint Backlog, conformidade com a Definition of Done, adaptação do plano diário, proteção da qualidade e exercício da autonomia técnica profissional.
Tempo estimado de leitura: 25 minutos
Por João Ricardo Dutra••Artigo completo
Objetivo do capítulo
Ao final deste capítulo, você deverá compreender quem são os no , por que o termo é mais amplo do que programadores de software, quais são suas quatro accountabilities explícitas, como criam e adaptam o , como a protege a qualidade, como funciona a responsabilização profissional mútua e onde começa e termina a autonomia técnica.
Introdução: são os profissionais que transformam a direção do produto em um utilizável
No , um Developer é definido por sua accountability na criação do do produto - e não por um cargo, uma linguagem de programação ou uma posição no organograma.
A palavra Developer cria uma das primeiras armadilhas conceituais do . Nas organizações de software do dia a dia, developer costuma significar programador. O Scrum Guide usa a palavra de maneira diferente. são as pessoas do comprometidas em criar qualquer aspecto de um utilizável a cada . Suas habilidades variam conforme o produto e o domínio. Um Developer pode contribuir por meio de engenharia de software, design, testes, segurança, dados, operações, pesquisa, análise, conteúdo, hardware, ciência ou qualquer outra disciplina necessária à criação do produto.
Essa definição ampla ficou ainda mais clara com o Scrum Guide de 2020. Guias anteriores descreviam um separado dentro do . O guia atual removeu essa distinção de um time dentro do time e define um único coeso com três accountabilities: , e . Essa mudança reforçou a ideia de que o trabalho do produto não é repassado pelo a um departamento de entrega separado. As pessoas responsáveis por valor, efetividade do e criação do pertencem ao mesmo .
A accountability dos está no ponto em que a intenção se transforma em realidade. Um pode ser estrategicamente brilhante e a ordenação do pode fazer sentido econômico, mas o valor não chega aos usuários até que profissionais transformem ideias em um utilizável. Essa transformação exige mais do que execução técnica. Os precisam planejar, colaborar, manter a qualidade, adaptar-se continuamente, fazer trade-offs e responsabilizar uns aos outros como profissionais.
Por isso, o concede aos autonomia significativa. Durante a , eles decidem como os itens do serão transformados em um Done. Durante a , atualizam o plano à medida que aprendem. A existe para que os inspecionem o progresso em direção ao e adaptem o trabalho seguinte. Ninguém de fora dos lhes diz exatamente como transformar os itens selecionados do em Increments de valor.
Autonomia, contudo, não significa independência em relação à accountability. Os atuam dentro dos limites do ,,, ordenação do , restrições do produto e da organização e da accountability compartilhada do . Liberdade profissional vem acompanhada de responsabilidade profissional. Esse equilíbrio - autonomia sem caos e accountability sem microgerenciamento - é o núcleo deste capítulo.
Quem são os no ?
O Scrum Guide define como as pessoas do comprometidas em criar qualquer aspecto de um utilizável a cada . A expressão "qualquer aspecto" é deliberadamente ampla. é um framework para produtos complexos, e não um sistema de classificação de cargos de desenvolvimento de software.
Em um produto de software, podem incluir programadores, testadores, especialistas em UX, engenheiros de dados, engenheiros de infraestrutura, especialistas em segurança, redatores técnicos e outros profissionais quando contribuem diretamente para o . Em um produto de dispositivo médico, as competências relevantes podem incluir engenharia, garantia da qualidade, conformidade, design industrial, eletrônica e conhecimento clínico. Em um produto de marketing, a accountability dos pode abranger conteúdo, design, analytics, experimentação e implementação de campanhas.
O Scrum Guide atual removeu intencionalmente muitas referências que sugeriam trabalho de tecnologia da informação para que o framework pudesse ser aplicado a uma variedade maior de produtos. Isso significa que candidatos nunca devem interpretar "Developer" como "apenas programador". O modelo mental correto é mais amplo: um Developer é um membro do que ajuda a criar o utilizável do produto.
Uma pessoa pode ter um cargo como arquiteto, engenheiro de QA, designer, analista ou cientista e ainda assim estar sob a accountability de no . O não elimina especialidades profissionais. Ele fornece uma accountability comum sobre como essas especialidades se combinam para criar um Done.
Essa distinção é importante porque títulos funcionais podem recriar sub-times acidentalmente. Se testadores acreditarem que estão separados dos , a qualidade passa a ser algo que acontece depois do desenvolvimento. Se arquitetos se enxergarem fora da accountability dos , decisões de design podem se transformar em gates de aprovação. O , em vez disso, incentiva as competências necessárias ao a colaborar como uma única unidade auto gerenciável e .
Ponto de referência para a
Developer não significa programador de software. Significa um membro do comprometido em criar qualquer aspecto de um utilizável a cada .
As quatro accountabilities explícitas dos
O Scrum Guide nomeia quatro accountabilities que sempre pertencem aos , independentemente do domínio. Vale memorizar essas quatro afirmações, mas entender por que elas existem é mais importante do que decorar sua redação.
Accountability dos
O que significa na prática
Criar um plano para a - o
Os transformam o e os itens selecionados do em um plano acionável que lhes pertence e que é continuamente atualizado.
Instilar qualidade por meio da conformidade com a
Qualidade não é uma atividade de inspeção posterior. Os devem criar trabalho que atenda ao estado de qualidade acordado para o produto.
Adaptar o plano todos os dias em direção ao
A não é executada a partir de uma lista congelada de tarefas. Os inspecionam o progresso e revisam o plano à medida que as evidências mudam.
Responsabilizar uns aos outros como profissionais
O time não precisa de um gerente externo de tarefas para impor cada compromisso; os pares compartilham a responsabilidade pelo comportamento profissional e pelo resultado.
Essas accountabilities se reforçam mutuamente. O fornece um plano aos . A define o limite de qualidade do resultado. A adaptação diária impede que o plano se torne obsoleto à medida que a complexidade revela novas informações. A responsabilização profissional mútua torna o viável sem uma hierarquia interna de comando.
Se um desses elementos for enfraquecido, os demais sofrem. Um time que não é dono do não consegue adaptá-lo de fato. Um time sem uma significativa não consegue saber com confiabilidade se o progresso representa valor utilizável. Um time que evita accountability entre pares torna-se dependente de um gerente ou para fiscalizar comportamentos. A accountability dos no é, portanto, um modelo operacional completo, e não uma lista de deveres isolados.
Criando o : a responsabilidade central sobre o produto
O é um passo concreto em direção ao . Cada se soma aos Increments anteriores, é integralmente verificado e é utilizável. Vários Increments podem ser criados durante uma , e valor pode ser entregue antes do término da . A não é um gate de liberação.
Os estão comprometidos em criar qualquer aspecto de um utilizável a cada . Isso muda a definição de sucesso de "trabalhamos na funcionalidade" para "criamos algo que atende à e é utilizável". Trabalho parcialmente concluído pode representar esforço, mas não faz parte do .
O também torna o possível. Stakeholders podem inspecionar um estado real do produto, em vez de projeções, documentos ou relatórios de percentual concluído. Um utilizável cria evidências sobre tecnologia, comportamento do usuário, integração, qualidade, custo e direção do produto. Assim, os contribuem diretamente para o aprendizado, e não apenas para a execução.
Um não precisa ser liberado para clientes em toda , mas precisa ser utilizável. A decisão de liberar é uma decisão de produto que pode depender de timing de mercado, estratégia de negócios, regulamentação ou outros fatores. O separa a capacidade técnica/do produto de liberar da decisão de negócio sobre quando liberar.
Essa distinção importa para a . A expressão "potencialmente liberável" aparece em materiais mais antigos, mas o Scrum Guide de 2020 usa o requisito mais forte e simples de que o deve ser utilizável e estar em conformidade com a . Os candidatos devem se orientar pela redação atual.
Distinção importante
O trabalho pode consumir tempo e, ainda assim, não fazer parte do . Se não atender à , não está Done e não pode ser tratado como valor de produto concluído.
O : um plano feito pelos e para os
O contém o - o porquê -, os itens do selecionados para a - o quê - e um plano acionável para entregar o - o como. O Scrum Guide o descreve como um plano feito pelos e para os .
Essa redação estabelece propriedade. O não é uma folha de atribuições do gerente, um cronograma do gerente de projetos nem um contrato de entrega do . Os o criam durante a e o atualizam ao longo da à medida que aprendem mais.
O deve fornecer uma visão altamente visível e em tempo real do trabalho que os planejam realizar para atingir o . Precisa ter detalhes suficientes para apoiar a inspeção na , mas o não prescreve um formato específico. Um time pode usar cartões, quadros digitais, tarefas, checklists, visualização de fluxo, planos de engenharia ou outras representações adequadas ao seu trabalho.
Os itens do selecionados para a são importantes, mas o cria coerência. Os não são responsáveis por executar mecanicamente uma lista congelada, independentemente de novas informações. Se o trabalho exato necessário mudar, os adaptam o enquanto protegem o . O escopo pode ser esclarecido e renegociado com o à medida que mais informações surgem.
Essa é uma diferença fundamental entre um e um plano tradicional e fixo de projeto. O é um plano emergente. Espera-se que ele mude à medida que a realidade se torne mais clara. Um plano que nunca muda diante de novas evidências pode ser sinal de que o time não está praticando adaptação empírica.
Armadilha da
O pertence aos e é gerenciado por eles. O pode colaborar, esclarecer valor e renegociar escopo, mas não atribui nem controla o plano dos .
: os decidem como o trabalho escolhido será realizado
A cria o inicial. Todo o participa, mas os têm autoridade específica de decisão sobre o trabalho que executarão e sobre como ele será realizado.
O garante que os participantes estejam preparados para discutir os itens mais importantes do e como eles se relacionam com o . Por meio da discussão com o , os selecionam itens do para a . Sua confiança é informada pelo desempenho passado, pela capacidade prevista e pela .
Para cada item do selecionado, os planejam o trabalho necessário para criar um que atenda à . O Scrum Guide é explícito ao afirmar que a forma como isso é feito fica a critério exclusivo dos . Ninguém mais lhes diz como transformar itens do em Increments de valor.
Isso não significa que os ignorem o contexto do produto. Eles precisam das informações de valor e de domínio fornecidas pelo . Podem convidar especialistas para aconselhamento. Devem cumprir a e restrições organizacionais legítimas. Mas o plano de implementação continua sendo responsabilidade dos .
A autonomia técnica funciona porque as pessoas mais próximas do trabalho podem reagir a descobertas que não podem ser totalmente previstas durante o planejamento. A arquitetura pode precisar de ajustes. Um teste pode expor um modo de falha. Uma integração pode se comportar de forma diferente da esperada. Um design mais simples pode surgir. O dá aos espaço para usar o julgamento profissional, em vez de exigir permissão externa para cada adaptação técnica.
: o limite de qualidade que os devem respeitar
A é o commitment associado ao . É uma descrição formal do estado do quando ele atende às medidas de qualidade exigidas para o produto. No momento em que um item do atende à , nasce um .
Os devem estar em conformidade com a . Essa é uma de suas quatro accountabilities explícitas. A impede que "quase concluído" se torne um status ambíguo e cria um entendimento compartilhado do nível de qualidade representado pelo trabalho Done.
Para software, uma pode incluir testes automatizados, , integração, verificações de segurança, documentação, observabilidade, limites de desempenho, prontidão para implantação e outros padrões no nível do produto. O não prescreve esses itens porque os requisitos de qualidade dependem do contexto.
Se a organização possuir padrões aplicáveis à , todos os Teams devem segui-los como mínimo. Se não houver um padrão organizacional, o deve criar uma apropriada ao produto. Quando vários Teams trabalham em um único produto, devem definir conjuntamente e cumprir a mesma .
A não é um teto. Os times podem aprimorá-la à medida que aprendem e amadurecem. Critérios mais fortes de automação, segurança, desempenho, acessibilidade, manutenibilidade ou operação podem aumentar a transparência e reduzir riscos futuros.
Uma fraca cria trabalho oculto. Uma funcionalidade pode ser chamada de concluída enquanto testes, integração, documentação, segurança ou trabalho de implantação permanecem pendentes. Isso cria falsa transparência: stakeholders acreditam que o produto está mais avançado do que realmente está. Os protegem a base empírica do recusando-se a rotular trabalho inacabado como Done.
Qualidade não é negociável por mero desejo
Se um item do não atende à , ele não faz parte do . Um prazo ou a preferência de um stakeholder não redefine Done.
Planejamento e adaptação diários: a é para os
O propósito da é inspecionar o progresso em direção ao e adaptar o conforme necessário, ajustando o trabalho planejado seguinte. É um evento de 15 minutos para os do .
Isso torna a um evento de planejamento e adaptação, e não uma reunião de status. Os não estão ali para relatar a atividade de ontem ao ou ao . Estão ali para aumentar a probabilidade de atingir o .
Os podem escolher qualquer estrutura e técnicas para a , desde que o evento se concentre no progresso em direção ao e produza um plano acionável para o próximo dia de trabalho. O antigo formato de três perguntas - o que fiz ontem, o que farei hoje, o que está me impedindo - ainda pode ser usado se for útil, mas não é prescrito pelo Scrum Guide atual.
O resultado real é a adaptação. Se um item estiver bloqueado, os podem fazer . Se uma integração de risco estiver demorando mais, podem alterar a sequência. Se o estiver em risco, podem renegociar o escopo selecionado com o . Se uma suposição for inválida, podem alterar o plano técnico.
Os não precisam esperar pela para se adaptar. Podem ajustar o plano ao longo do dia conforme aprendem mais. A cria uma cadência recorrente mínima de inspeção e adaptação, não um checkpoint de permissão.
Se o ou o estiverem trabalhando ativamente em itens do , participam da como . Caso contrário, o evento pertence aos . Esse é um detalhe comum na .
Modelo mental da
Inspecionar o progresso em direção ao -> adaptar o -> criar um plano acionável para o próximo dia. Não é um relatório de status voltado à gestão.
Adaptando o trabalho sem perder o foco
O espera que os adaptem seu plano diariamente em direção ao . Essa accountability reconhece que o trabalho complexo produz informações durante a execução. Um plano detalhado criado no primeiro dia da raramente permanecerá perfeitamente preciso.
A adaptação pode envolver sequenciamento de tarefas, design técnico, padrões de colaboração, quantidade de , estratégia de testes, alocação de especialistas ou o caminho detalhado até o . Os também podem trabalhar com o para esclarecer e renegociar escopo quando necessário, desde que as mudanças não coloquem o em risco.
O é, portanto, um limite importante para a autonomia dos . Ele oferece flexibilidade no escopo exato, preservando o propósito da . Sem um , cada mudança no plano pode parecer perda de controle. Com um significativo, os podem perguntar se uma alteração melhora ou prejudica a capacidade do time de atingir o objetivo.
A adaptação também depende de transparência. Os precisam de uma visão honesta do trabalho restante, risco técnico, qualidade, impedimentos, dependências e comportamento do produto. Se problemas forem ocultados para proteger métricas de desempenho ou reputações individuais, o plano não poderá ser adaptado de forma inteligente.
profissionais, portanto, tornam más notícias visíveis cedo. Uma integração é mais difícil do que o esperado. Um risco de segurança foi encontrado. A deixou de ser realista. Um design escolhido está criando complexidade excessiva. Transparência não é pessimismo; é a informação necessária ao .
Responsabilidade profissional e accountability mútua
A quarta accountability explícita dos é responsabilizar uns aos outros como profissionais. Isso é essencial porque o não pode funcionar se a accountability precisar ser sempre imposta externamente.
Accountability profissional não é policiamento entre pares nem exposição pública de culpa. Significa criar uma cultura em que os membros do time possam questionar comportamentos que ameaçam o , a qualidade ou os compromissos compartilhados. Se um Developer repetidamente deixa testes para outras pessoas, ignora a , inicia trabalho em excesso ou oculta atrasos, os colegas tratam o problema em vez de esperar por um gerente.
Accountability mútua também significa ajudar uns aos outros a ter sucesso. Se um especialista se torna um gargalo, a resposta pode ser pairing, mentoring, ou redistribuição do trabalho. Se um Developer estiver com dificuldades, o time não deve preservar fronteiras individuais de tarefas às custas do .
Os tornam isso possível. Respect permite que profissionais questionem ideias sem diminuir pessoas. Openness torna problemas visíveis. Courage sustenta conversas difíceis. Commitment reforça a responsabilidade pelos objetivos do time. Focus impede que otimizações locais substituam o .
A liderança externa continua importante. Problemas graves de desempenho, emprego ou ética podem exigir atuação da gestão organizacional. A accountability mútua do não elimina responsabilidades de recursos humanos. Contudo, o profissionalismo cotidiano em torno do produto não deveria exigir um gerente coordenando cada comportamento.
Accountability profissional é orientada a resultados
A pergunta não é "Todos concluíram suas tarefas individuais?", mas "Estamos coletivamente fazendo o necessário para criar um de alta qualidade e atingir o ?"
Qualidade: não negociam a
Qualidade não é uma fase separada no . Os instilam qualidade ao aderir à durante a criação do . Isso torna a qualidade parte da criação do produto, e não uma inspeção final após a implementação.
Uma pressão organizacional comum aparece perto de prazos: "Podemos pular alguns testes nesta e corrigi-los depois?" Em termos de , a resposta depende de esses testes fazerem parte da . Se fizerem, ignorá-los significa que o item não está Done. Stakeholders podem optar por não construir uma funcionalidade, reduzir o escopo ou mudar prioridades, mas não podem criar valor fingindo que trabalho inacabado atende ao estado de qualidade acordado.
Isso não é rigidez por si só. Uma protege a tomada de decisão empírica. Se Done significar algo diferente a cada , os stakeholders não conseguirão comparar o progresso nem compreender o estado real do produto. e trabalho oculto se acumulam por trás de rótulos otimistas.
Os também têm responsabilidade de melhorar a qualidade do produto ao longo do tempo. O não prescreve práticas de engenharia, mas produtos complexos frequentemente exigem automação, , testabilidade, observabilidade, design manutenível, segurança e outras capacidades técnicas para produzir Increments Done de forma sustentável.
Qualidade e velocidade são frequentemente apresentadas como opostos, mas qualidade fraca costuma desacelerar entregas futuras. Defeitos geram retrabalho, código frágil aumenta o custo de mudança, processos manuais criam filas e implantações pouco confiáveis desencorajam liberações frequentes. profissionais veem a qualidade técnica como parte da capacidade econômica de adaptação.
Autonomia técnica: liberdade para decidir como, dentro de limites reais
O concede aos ampla discricionariedade sobre como o trabalho é realizado. O Scrum Guide afirma que ninguém mais diz aos como transformar itens do em Increments de valor. Essa é a base do que muitas organizações chamam de autonomia técnica.
Autonomia técnica não significa que toda decisão arquitetural ou de engenharia seja irrestrita. Produtos podem precisar cumprir padrões de segurança, regulamentações, restrições de plataforma, estratégias de tecnologia, orçamentos, requisitos legais ou padrões organizacionais de . O time trabalha dentro desses limites legítimos.
A distinção principal é entre restrições e microgerenciamento. Uma restrição pode dizer que dados de clientes devem ser criptografados usando um padrão aprovado. Microgerenciamento diz qual Developer deve implementar a criptografia na terça-feira usando uma estrutura interna de classes escolhida por um gerente. O dá suporte ao primeiro quando ele reflete necessidades legítimas do produto ou da organização; não define o segundo.
Especialistas externos ao podem aconselhar. Arquitetos, times de segurança, especialistas jurídicos, operações ou outros grupos podem fornecer conhecimento importante. Aconselhamento não se transforma automaticamente em autoridade de comando sobre o plano da dos . Organizações saudáveis deixam claros os padrões necessários enquanto deslocam as decisões de implementação para o mais perto possível das pessoas que executam o trabalho.
A autonomia também traz uma obrigação de evidência. Um Developer deve ser capaz de explicar por que uma decisão técnica apoia qualidade, valor, manutenibilidade, redução de risco ou o . "Somos autônomos" não é justificativa profissional para complexidade desnecessária nem para ignorar necessidades do produto.
Relação com o e o
Os não trabalham isoladamente. O depende de colaboração próxima com as outras accountabilities do .
Com o , os combinam conhecimento de entrega com conhecimento de valor. O explica objetivos, ordenação do , necessidades dos stakeholders e trade-offs de valor. Os explicam viabilidade, risco técnico, custo, sequenciamento, arquitetura e oportunidades de simplificação. Durante a , essa colaboração ajuda a criar um e uma realistas.
O não atribui tarefas aos , não dita estimativas nem decide como a implementação deve ocorrer. Os são responsáveis por dimensionar o trabalho que realizam e pelo plano técnico. Em contrapartida, os não reordenam unilateralmente o apenas por preferência técnica. A ordenação do produto continua sendo accountability do .
Com o , os recebem coaching e suporte para ,, foco e . O pode facilitar quando útil, mas não é dono do , não distribui tarefas nem conduz a como reunião de status.
A relação mais forte se baseia em transparência recíproca. Os tornam a realidade técnica visível. O torna visíveis os trade-offs de valor. O torna visíveis os impedimentos organizacionais e do sistema . Juntas, essas perspectivas melhoram decisões empíricas.
Exemplo prático - construindo uma capacidade de detecção de fraude
Imagine um de serviços financeiros melhorando a detecção de fraude em tempo real para pagamentos digitais. O ordenou um item do para reduzir recusas falsas de clientes legítimos, mantendo os controles antifraude. O é melhorar a qualidade da aprovação de pagamentos sem aumentar perdas materiais por fraude.
Durante a , os incluem especialistas em APIs, engenharia de dados, machine learning, segurança, testes e observabilidade. O explica as evidências de negócio: recusas falsas estão gerando reclamações de clientes e transações perdidas. Os discutem o risco técnico e selecionam trabalho que acreditam poder sustentar um : validar uma nova combinação de sinais de risco em um segmento controlado de transações.
Os criam o . O plano inclui alterações no pipeline de dados, ajuste de uma regra do modelo, integração de API, cenários de teste, monitoramento e um mecanismo seguro de rollout. O não atribui tarefas. Os decidem que o engenheiro de dados e o especialista em API trabalharão em pair inicialmente, porque a maior incerteza está na fronteira do contrato de eventos.
No terceiro dia, os testes mostram que o novo sinal se comporta de forma diferente em um canal de pagamento. O plano original já não é suficiente. Na , os inspecionam o progresso em direção ao e decidem interromper uma tarefa secundária de dashboard. Três pessoas fazem no cenário com falha enquanto outro Developer melhora os dados de teste. O muda.
Um gerente de fora do pede aos que pulem o teste de desempenho para cumprir uma data de demonstração. O teste de desempenho faz parte da do produto. Os explicam que, sem atender à , o trabalho não pode ser considerado parte do . Em vez disso, renegociam o escopo com o e removem da uma visualização não essencial.
Mais tarde, um especialista em segurança descobre que uma das implementações propostas expõe atributos sensíveis de risco em logs. Os mudam o design imediatamente. Não esperam pela próxima , pois a adaptação técnica faz parte de sua accountability diária.
Na , o time possui um utilizável que atende à e permite avaliação controlada. Stakeholders inspecionam o comportamento real, em vez de slides sobre percentual concluído. O resultado mostra menos recusas falsas no segmento-alvo, mas revela um edge case inesperado. O usa essa evidência para reordenar o trabalho futuro.
Na , os reconhecem que o conhecimento sobre o canal de pagamento estava concentrado em uma única pessoa. Concordam em fazer pairing com mais frequência nessa área e melhorar os testes automatizados de contrato. A accountability mútua transforma-se em ação de melhoria, e não em culpa.
Esse exemplo captura a accountability dos : criar o plano, proteger a qualidade Done, adaptar diariamente, usar a autonomia técnica de maneira profissional, colaborar entre competências e responsabilizar uns aos outros pelo resultado do produto.
Armadilhas comuns da sobre
Armadilha
Interpretação correta no
significa programadores.
Falso. podem ter quaisquer competências necessárias para criar um utilizável.
O atribui tarefas da .
Falso. Os gerenciam quem faz o quê, quando e como dentro da .
O é dono do .
Falso. O é um plano feito pelos e para os .
O deve permanecer fixo durante a .
Falso. Ele é atualizado ao longo da conforme mais informações são aprendidas.
Os podem mudar o sempre que necessário.
Falso. O cria coerência; o plano se adapta em direção a ele.
A é uma reunião de status para o .
Falso. Seu propósito é a inspeção e adaptação dos em direção ao .
A deve usar as três perguntas tradicionais.
Falso. Os podem escolher qualquer estrutura que cumpra o propósito do evento.
O decide como os PBIs são implementados.
Falso. A forma de transformar trabalho em Increments fica a critério dos .
Um stakeholder pode reduzir a para um item urgente.
Falso. Trabalho que não atende à não está Done.
Trabalho parcialmente concluído pode ser contado no .
Falso. O trabalho precisa atender à .
Apenas testadores são responsáveis pela qualidade.
Falso. Os instilam qualidade coletivamente por meio da conformidade com a .
precisam de permissão do para adaptar o .
Falso. Eles adaptam o plano sempre que necessário.
trabalham de forma independente em tarefas atribuídas por especialidade.
Não é exigido e frequentemente é prejudicial. Colaboração, e competências complementares apoiam o compartilhado.
A é o primeiro momento em que um pode ser liberado.
Falso. Um pode ser entregue antes do fim da ; a não é um gate de liberação.
Autonomia técnica significa ignorar padrões organizacionais.
Falso. Os se auto gerenciam dentro de restrições legítimas do produto e da organização.
: o que o espera e o que não espera
Categoria
Interpretação
Esperado
Criar um utilizável que atenda à .
Esperado
Criar e atualizar continuamente o .
Esperado
Inspecionar o progresso em direção ao e adaptar o plano.
Esperado
Usar julgamento profissional para decidir como o trabalho é realizado.
Esperado
Colaborar entre competências complementares e ajudar a concluir o trabalho compartilhado.
Esperado
Responsabilizar uns aos outros como profissionais.
Não exigido
Todo Developer ser capaz de executar toda especialidade técnica.
Não exigido
Usar user stories, , um específico ou as três perguntas da .
Não é
Esperar que um gerente ou atribua todo o trabalho.
Não é
Declarar tarefas pessoais concluídas enquanto o permanece inutilizável.
Não é
Tratar qualidade como responsabilidade de um time de QA posterior.
Não é
Alterar a ordenação do produto sem o .
Um framework de raciocínio para questões da sobre
Quando a avaliação apresentar um cenário envolvendo , ancore-se em suas quatro accountabilities explícitas. Depois, pergunte qual artifact, commitment ou evento do está envolvido.
: a resposta preserva um plano feito pelos e para os ?
: a resposta protege o estado de qualidade acordado do produto em vez de redefinir Done sob pressão?
Adaptação diária: os estão inspecionando o progresso em direção ao e mudando o plano conforme necessário?
Accountability profissional: a resposta fortalece a responsabilidade entre pares em vez de introduzir desnecessário?
Autonomia técnica: a resposta permite que os determinem como criar o dentro de limites legítimos?
Limite do : a accountability por ordenação do e valor permanece com o ?
Limite do : o está fazendo coaching/facilitação em vez de atribuir e supervisionar o trabalho dos ?
: o trabalho concluído é realmente utilizável e está em conformidade com a ?
: o evento está sendo usado para planejamento dos em vez de reporte gerencial?
Terminologia atual: você está usando o Scrum Guide de 2020 em vez de regras antigas do ou linguagem obsoleta sobre tamanho de time?
Atalho útil para a prova
Se uma resposta transforma em meros executores de tarefas, enfraquece a , congela o ou transforma a em reunião de status, geralmente ela está se afastando do .
Checklist de diagnóstico para a efetividade real dos
Os conseguem explicar o e como seu trabalho atual contribui para ele?
O é visivelmente de propriedade dos e atualizado por eles?
Os mudam o plano quando a realidade muda ou esperam por permissão externa?
A representa um estado de produto utilizável e significativo?
Os resistem a rotular trabalho inacabado como Done?
As atividades de qualidade estão integradas à criação em vez de serem empurradas para uma fase posterior separada?
Os membros do time ajudam a concluir o trabalho mais importante em vez de proteger fronteiras pessoais de tarefas?
Especialistas conseguem fazer pairing, mentoring e compartilhar conhecimento para reduzir gargalos?
As decisões técnicas acontecem perto das pessoas que executam o trabalho, respeitando as restrições organizacionais?
A melhora o plano do dia seguinte em vez de gerar status para a gestão?
Os conseguem discutir riscos e más notícias abertamente sem escondê-los atrás de métricas de conclusão?
e renegociam o escopo quando o aprendizado muda o que é realista, preservando o ?
O fortalece o dos em vez de coordenar o trabalho por eles?
O time inspeciona resultados e qualidade, e não apenas velocity ou número de tickets concluídos?
Conclusão: são responsáveis pelo caminho profissional do plano até um Done
são os membros do que criam o produto. O termo é deliberadamente mais amplo do que programador, porque o se aplica a diferentes domínios e porque Increments valiosos exigem muitas competências complementares. O que une os não é um cargo, mas um conjunto de accountabilities.
Os criam o , instilam qualidade aderindo à , adaptam seu plano a cada dia em direção ao e responsabilizam uns aos outros como profissionais. Essas responsabilidades formam o núcleo operacional do durante uma .
O dá aos a propriedade do plano. A protege qualidade e transparência. A cria um loop recorrente de inspeção e adaptação. A accountability profissional mútua permite que o time se coordene sem exigir um gerente interno fiscalizando cada ação.
A autonomia técnica é consequência desse design. Os decidem como transformar itens do em Increments de valor porque as pessoas que executam o trabalho estão mais próximas das informações técnicas emergentes. Essa autonomia é limitada pelo , pela , pela estratégia do produto, pela ordenação feita pelo e por restrições organizacionais legítimas.
Qualidade é inseparável da accountability dos . Um prazo não transforma trabalho incompleto em Done. Uma funcionalidade que não atende à não faz parte do . Ao manter esse limite, os preservam a transparência necessária à tomada de decisão empírica.
Na minha visão, é nessa accountability que o exige profissionalismo de maneira mais clara. É fácil pedir autonomia; mais difícil é aceitar a responsabilidade que a acompanha. devem planejar de forma realista, expor riscos, ajudar uns aos outros, tomar decisões técnicas difíceis, manter a qualidade e adaptar-se sem esperar que alguém lhes diga o que fazer. Um time que desenvolve essa capacidade torna-se muito mais do que um grupo de especialistas concluindo tarefas atribuídas - torna-se um sistema auto gerenciável de desenvolvimento de produto.
Principais aprendizados
são membros do comprometidos em criar qualquer aspecto de um utilizável a cada .
Developer não significa apenas programador de software.
Os criam o plano para a : o .
O contém o , os itens selecionados do e o plano acionável para entregar o .
O é um plano feito pelos e para os e evolui ao longo da .
Os instilam qualidade por meio da conformidade com a .
O trabalho não faz parte do se não atender à .
Os adaptam seu plano diariamente em direção ao .
A é um evento de 15 minutos para os inspecionarem o progresso e adaptarem o .
Os escolhem a estrutura da e não precisam usar as antigas três perguntas.
Os responsabilizam uns aos outros como profissionais.
Os têm discricionariedade sobre como itens do são transformados em Increments de valor.
Autonomia técnica não significa ignorar objetivos do produto, padrões de qualidade, conformidade, segurança ou restrições organizacionais.
O gerencia valor e ordenação do produto; o apoia a efetividade do ; os gerenciam o plano da e a execução técnica.
Questões da frequentemente testam se dos , qualidade, foco no e propriedade do são preservados.
