Metas SMART: O que são e como usar?

Você já se pegou criando uma lista de objetivos, apenas para perceber semanas ou meses depois que muitos deles ficaram pelo caminho?

 

Isso é um fenômeno comum. 

 

Às vezes, nossa aspiração de alcançar grandes coisas pode nos levar a estabelecer metas vagas, inalcançáveis ou irrelevantes.

 

E que eventualmente nos deixam frustrados e desmotivados.

 

Agora, imagine um método que te ajuda a definir metas de forma estruturada e eficiente, aumentando drasticamente suas chances de sucesso.

 

Esse método existe e é conhecido como metas SMART!

 

Ele é uma ferramenta poderosa para transformar aspirações em realizações, seja em nossas vidas pessoais ou profissionais.

 

Ao longo deste artigo, vamos mergulhar no universo das metas SMART: o que são, como são estruturadas e como você pode usá-las.

 

Para aprimorar seus projetos pessoais e profissionais.

 

Acompanhe e veja também: 4 TENDÊNCIAS EM GESTÃO DE PROJETOS.

 

O que são metas SMART?

As metas SMART são um método eficiente e detalhado para definir objetivos.

 

A abordagem SMART é uma ferramenta de gestão que originou na década de 1980 e tem se provado útil para estabelecer objetivos claros e atingíveis.

 

A sigla SMART significa Specific (Específico), Measurable (Mensurável), Achievable (Atingível), Relevant (Relevante) e Time-based (Temporal).

 

Esses critérios garantem que suas metas sejam claras, rastreáveis, realistas e alinhadas com suas prioridades.

Specific (Específico)

A primeira letra, S, refere-se a específico. Para que uma meta seja eficaz, é importante ser específico sobre o que você quer alcançar.

 

Evite metas genéricas ou amplas, pois elas podem ser difíceis de medir e podem levar à frustração.

 

Em vez disso, tente detalhar o máximo possível sua meta.

 

Responda a perguntas como: O que eu quero alcançar? Por que isso é importante para mim? Quem estará envolvido? Onde isso ocorrerá?

Measurable (Mensurável)

A segunda letra, M, é de mensurável. Uma meta eficaz precisa ser mensurável, ou seja, deve haver alguma maneira de rastrear seu progresso.

 

Isso pode incluir marcos específicos, prazos ou métricas que possam ajudá-lo a determinar se você está se movendo na direção certa.

 

No âmbito profissional, isso é particularmente importante.

 

Já que objetivos de desempenho, tais como aumentar a base de clientes ou a receita, devem ser avaliados para determinar o êxito.

 

Acompanhe: PARTE 1: Definição de DoR e DoD.

 

Achievable (Atingível)

A, de atingível, refere-se a definir metas realistas e alcançáveis.

 

Embora seja importante estabelecer metas que o desafiem, definir metas além do seu alcance pode resultar em desapontamento e desmotivação.

 

Pense cuidadosamente sobre o que é necessário para alcançar sua meta e se você tem os recursos e habilidades necessários.

 

Talvez seja necessário buscar mais formação, obter recursos adicionais ou fazer ajustes em outros aspectos da sua vida para tornar sua meta atingível.

Relevant (Relevante)

R, de relevante, enfatizar a importância de definir metas que sejam pertinentes para você e seus objetivos de longo prazo.

 

Uma meta relevante é aquela que tem um propósito claro e que se alinha com seus outros objetivos e valores.

 

Por exemplo, se você deseja avançar em sua carreira, uma meta relevante pode ser obter uma certificação ou aprender uma nova habilidade relacionada ao seu campo.

Time-based (Temporal)

Por último, mas não menos importante, T, de temporal, destaca a importância de estabelecer um prazo claro para sua meta.

 

Ter um prazo definido ajuda a manter a motivação e fornece um senso de urgência.

 

Além disso, permite que você divida sua meta em tarefas menores ou etapas que podem ser concluídas em um determinado período.

Como criar metas SMART para seus projetos pessoais ou profissionais

Definir metas SMART para seus projetos pessoais ou profissionais requer um pouco de reflexão e planejamento.

 

Aqui está um passo a passo de como você pode fazer isso:

 

  1. Comece identificando o que você quer alcançar. Seja tão específico quanto possível. Se você deseja obter uma promoção no trabalho, por exemplo, identifique o cargo específico para o qual você está mirando.
  2. Em seguida, pense em como você pode medir seu progresso em direção a essa meta. Quais serão as evidências de que você está progredindo? Para o exemplo da promoção, isso pode incluir feedback positivo de superiores ou aumento de responsabilidades.
  3. Avalie se a meta é atingível com base em seus recursos e habilidades atuais. Se não for, você pode precisar ajustar a meta ou identificar maneiras de adquirir os recursos ou habilidades necessárias.
  4. Considere a relevância da meta em relação aos seus objetivos de longo prazo e valores pessoais. Isso ajudará a garantir que você permaneça motivado e comprometido com a meta.
  5. Finalmente, defina um prazo para a meta. Certifique-se de que o prazo seja realista, mas também desafiador.

 

Imagine que você é um profissional de marketing com a tarefa de desenvolver um novo planejamento de marketing de conteúdo.

 

Definir metas SMART pode ser o elemento diferenciador que levará esse projeto ao sucesso.

 

Uma meta SMART poderia ser “aumentar o tráfego orgânico do blog em 20% nos próximos 6 meses através da publicação de 3 novos artigos otimizados para SEO por semana”.

 

Ao invés de ter uma meta vaga como “aumentar o tráfego do blog”.

 

Essa abordagem deixa claro muitos objetivos, como o que precisa ser feito, como será medido.

 

Bem como se é alcançável com os recursos disponíveis, por que é importante para a estratégia geral de marketing de conteúdo e quando deve ser alcançado.

Como acompanhar e avaliar as metas SMART

Manter o controle de suas metas SMART é crucial para garantir que você esteja fazendo progresso. 

 

Aqui estão algumas maneiras de fazer isso:

 

  • Estabeleça um sistema de acompanhamento: Isso pode ser tão simples como uma lista de tarefas no seu diário ou um aplicativo de gestão de tarefas no seu smartphone. O importante é ter um lugar onde você possa registrar e acompanhar suas metas.
  • Realize avaliações regulares: Dedique um tempo regularmente (por exemplo, semanal ou mensalmente) para revisar suas metas e avaliar seu progresso. Isso pode ajudar a identificar qualquer obstáculo que possa estar impedindo seu progresso e permitir que você faça ajustes conforme necessário.
  • Comemore suas conquistas: Quando você alcançar uma meta ou um marco importante, comemore! Isso pode ajudar a aumentar sua motivação e confiança.

 

Por exemplo, se considerarmos a meta SMART que mencionamos anteriormente, é possível acompanhar o progresso observando regularmente as métricas de tráfego do blog.

 

E também o número de novos artigos publicados e sua otimização para SEO.

 

Se, depois de três meses, você perceber que o tráfego orgânico do blog só aumentou 5%, talvez seja necessário ajustar a estratégia ou o plano de implementação.

 

Talvez você precise investir mais em pesquisa de palavras-chave para melhorar a otimização de SEO.

Ou talvez você precise alterar a frequência ou o tipo de conteúdo publicado.

 

O acompanhamento regular permitirá que você faça ajustes conforme necessário para manter seus esforços de marketing de conteúdo no caminho certo.

Conclusão

As metas SMART são uma ferramenta valiosa para ajudar você a definir, perseguir e alcançar seus objetivos sejam pessoais ou profissionais.

 

Ao ser específico, mensurável, atingível, relevante e temporal, você pode aumentar significativamente suas chances de sucesso.

 

Lembre-se, o progresso é muitas vezes uma série de pequenas vitórias.

 

Então, estabeleça suas metas SMART e comece a avançar em direção ao objetivo desejado!

 

Gostou desse conteúdo? Veja também: CRIANDO BOAS METAS DE SPRINT.

8 principais tendências tecnológicas para 2023

O futuro já começou! 

 

Essa frase nunca fez tanto sentido como atualmente. 

 

Nos últimos anos, a tecnologia tem evoluído a um ritmo extremamente acelerado.

 

Impulsionando mudanças significativas em diversos setores, como serviços financeiros, saúde, educação, transporte, etc.

 

Com isso, neste artigo vamos apresentar as 8 principais tendências tecnológicas para 2022.

 

Tendências que devemos ficar de olho e se preparar para os seus grandes impactos daqui para frente. 

 

Acompanhe!

8 principais tendências tecnológicas para 2023

O mundo da tecnologia não para de surpreender e evoluir, abrindo novas possibilidades de melhoria das nossas vidas com diversas tendências e soluções inovadoras. 

 

Vamos conhecer algumas delas agora:

#1 Web3

A Web3 é uma nova geração de ferramentas que prometem melhorar a experiência do usuário na internet, tornando-se mais segura e oferecendo maior privacidade. 

 

Com o avanço da tecnologia blockchain, a Web3 permitirá que usuários interajam diretamente com websites e aplicativos sem precisar de servidores intermediários.

 

A Web3 é como uma nova fase da internet que conhecemos, com foco total no controle da privacidade por parte dos usuários e muito mais autonomia.

#2 Tecnologia Verde

A tecnologia verde é a próxima etapa do desenvolvimento tecnológico, que tem como principal objetivo reduzir o impacto ambiental dos processos industriais. 

 

Ela inclui o uso de energias renováveis para a produção de produtos e serviços, bem como a adoção de novos materiais que são biodegradáveis ou recicláveis.

 

A tecnologia verde está em constante evolução e promete reduzir o uso de recursos naturais, além de contribuir para a preservação do meio ambiente.

#3 Eventos Híbridos

Os eventos híbridos são uma tendência cada vez mais comum, que combina a presença física de convidados com a participação online. 

 

Dessa forma, é possível atingir um alcance maior, reunindo pessoas que não poderiam comparecer presencialmente.

 

Além disso, a tecnologia também permite o uso de recursos como realidade virtual e aumentada para tornar os eventos híbridos ainda mais atrativos.

 

Outro ponto importante é que esses eventos são boas oportunidades para networking, troca de conhecimentos, acesso a contatos de um business school, e também a internacionalização das relações.

#4 Rede 5G

A rede 5G é a próxima geração de tecnologia móvel que está sendo implementada para melhorar a experiência do usuário e permitir que se conecte em qualquer lugar. 

 

Com velocidades de até 10 Gbps, a rede 5G oferece latências extremamente baixas e uso compartilhado de recursos móveis com um alcance maior.

 

Essa tecnologia permitirá que os usuários desfrutem de conteúdo em alta definição, se conectem em qualquer lugar do globo aplicativos e serviços online com maior rapidez.

 

Países como Estados Unidos, China, Coreia do Sul, Itália e Brasil já possuem a rede 5G instalada em grande parte de seus territórios.

 

Melhorando a conectividade e possibilitando o acesso para muitos usuários.

 

Para ter acesso à rede 5G, os usuários precisam contar com dispositivos específicos compatíveis, como smartphones, tablets e notebooks.

#5 SuperApps

Os SuperApps são aplicativos que permitem ao usuário realizar diversas tarefas em um único lugar. 

 

Basicamente, ela é um hub de serviços onde o usuário pode realizar diversas atividades ao mesmo tempo.

 

Como agendar consultas médicas, pagamentos online, reserva de viagens ou transferências bancárias.

 

Atualmente, esse tipo de serviço já é bastante popular em alguns países asiáticos, como China e Índia. 

 

No entanto, a previsão é que essa tendência chegue também para outras regiões nos próximos anos.

 

Essas soluções combinam recursos de um aplicativo com assinaturas eletrônicas, uma plataforma e um ecossistema em um único software. 

 

Com isso, os SuperApps prometem mudar drasticamente o modo como lidamos com serviços online, tornando tudo mais simples, prático e conectado. 

 

A tendência é que essas soluções se tornem cada vez mais populares no futuro.

#6 Cidades Inteligentes

As cidades inteligentes são um novo conceito de cidade que abrange diversos serviços e infra estruturas interconectadas, tornando os locais ideais para viver e trabalhar.

 

Esse tipo de urbanização conta com a tecnologia para aprimorar e integrar sistemas de transporte, segurança, energia, água e esgoto. 

 

Além disso, também é possível implementar soluções que reduzam o desperdício de recursos, aumentem o uso da energia solar e possibilitem maior conectividade entre os cidadãos.

 

Essas soluções são fundamentais para tornar as grandes cidades mais inteligentes, inovadoras e ecologicamente corretas. 

 

Nesse sentido, as cidades inteligentes são consideradas a tendência mais promissora para o futuro próximo.

 

Já que permitem melhorar a qualidade de vida dos moradores e reduzir os impactos ambientais causados pela urbanização.

#7 Computação Quântica

A computação quântica é uma nova área de pesquisa que explora a possibilidade de se executar tarefas usando os princípios da mecânica quântica. 

 

A ideia é usar partículas subatômicas para computação, o que possibilita a realização de cálculos muito mais rápidos do que os computadores tradicionais.

 

Com essa tecnologia, é possível processar diversas informações simultaneamente e identificar padrões mais rapidamente. 

 

Isso tem aplicações em diversos campos, como inteligência artificial, computação de alto desempenho ou mesmo na criptografia.

 

A maior vantagem da computação quântica é que ela oferece velocidades infinitamente maiores do que as atuais, possibilitando processar dados muito mais rapidamente. 

É por isso que essa tecnologia tem sido considerada a grande aposta para o futuro da computação.

#8 Mais acesso à inteligência artificial

Por fim, como podemos ver, as IAs estão dominando cada vez mais nossos meios de comunicação. 

 

Desde reconhecimento facial e personalização de conteúdo até inteligência artificial para drones, robótica, automação industrial e pesquisa na agricultura.

 

Com essa popularização dos recursos de IA, os usuários têm acesso a várias soluções que facilitam nossa vida e permitem realizar muitas tarefas com menor esforço. 

 

Além disso, a previsão é que essas soluções se tornem ainda mais avançadas e presentes no nosso cotidiano, auxiliando inclusive em metodologias ágeis.

 

Permitindo que usuários de todos os tipos possam usufruir dos benefícios da tecnologia.

 

Podemos ver que há muitas tendências que prometem mudar drasticamente nosso modo de viver e trabalhar. 

 

Além disso, elas trazem consigo um futuro mais inovador, conectado, seguro e sustentável. 

 

É por isso que o desenvolvimento dessas tecnologias é tão importante para o futuro da humanidade.

Guia Definitivo para Iniciantes em PI Planning

Introdução ao PI Planning

O PI Planning é uma metodologia crucial para equipes ágeis que buscam melhorar seu desempenho e colaboração. Neste guia definitivo, abordaremos os conceitos essenciais do PI Planning para iniciantes.

O que é o PI Planning?

O PI Planning, ou Planejamento de Programa Incremental, é um evento crucial dentro da estrutura SAFe (Scaled Agile Framework). É uma reunião que ocorre regularmente, onde todas as equipes ágeis envolvidas no programa se unem para sincronizar seus objetivos e prioridades. O objetivo é estabelecer uma visão compartilhada, alinhar as atividades e garantir que todas as equipes estejam no mesmo caminho para o sucesso.

Benefícios do PI Planning

O PI Planning oferece diversos benefícios para as equipes e organizações que o adotam. Alguns dos principais benefícios incluem:

1. Alinhamento Estratégico

O PI Planning permite que todas as equipes trabalhem em direção aos mesmos objetivos estratégicos. Isso ajuda a evitar o desperdício de recursos em atividades não prioritárias e melhora a eficiência geral do programa.

2. Melhor Colaboração

Ao reunir todas as equipes em um evento presencial, o PI Planning promove a colaboração e a comunicação entre os membros. Isso leva a uma melhor compreensão das dependências entre as equipes e aumenta a sinergia entre elas.

3. Identificação Antecipada de Problemas

Durante o PI Planning, as equipes têm a oportunidade de identificar possíveis problemas e obstáculos. Isso permite que eles tomem medidas corretivas antecipadamente, evitando atrasos e falhas futuras.

4. Aumento da Transparência

Através do PI Planning, todas as partes interessadas têm uma visão clara das atividades planejadas e dos resultados esperados. Isso aumenta a transparência em toda a organização e melhora a confiança entre as equipes.

Etapas do PI Planning

O PI Planning geralmente ocorre em um período de dois dias. Abaixo estão as principais etapas envolvidas no processo:

1. Preparação

Antes do evento, as equipes devem se preparar revisando suas metas e objetivos individuais. Também é importante identificar quaisquer dependências externas e preparar uma lista de discussão para o evento.

2. Reunião de Abertura

O evento começa com uma reunião de abertura, onde a alta administração define a visão geral e as metas estratégicas. Isso estabelece o tom para o restante do planejamento.

3. Planejamento Detalhado

As equipes se reúnem para um planejamento detalhado, onde discutem suas metas específicas para o próximo Program Increment (PI). Elas também identificam e abordam possíveis problemas e riscos.

4. Cerimônia de PI Planning

Durante esta cerimônia, cada equipe apresenta seus planos e objetivos para todo o grupo. As dependências são identificadas e resolvidas, e as prioridades são estabelecidas para o próximo PI.

5. Retrospectiva

Após o evento, as equipes realizam uma retrospectiva para revisar o PI Planning e identificar áreas de melhoria para o próximo ciclo.

Conclusão

O PI Planning é uma prática essencial para equipes ágeis que desejam alcançar uma maior colaboração, alinhamento e eficiência. Ao seguir as etapas descritas neste guia, as equipes poderão maximizar os benefícios dessa metodologia e impulsionar o sucesso de seus programas. Portanto, é fundamental investir tempo e esforço adequados no PI Planning para colher os frutos a longo prazo.

Quer saber como realizar uma PI Planning de sucesso?

Vou dar um treinamento exclusivo sobre PI Planning em 02/09/2023 junto com Leandro Goor onde vamos entender e simular toda uma PI Planning, quer mais informações clique neste link https://www.sympla.com.br/evento-online/pi-planning-bootcamp-pragma/2066881

Sprint Review: Como obter muito mais da sua revisão da sprint

A Sprint Review é uma das cerimônias Ágeis mais importantes com certeza. Normalmente, é uma reunião ao vivo perto ou no final de uma sprint ou em todos as outras sprints.

Desenvolvedores, membros da equipe de produto e partes interessadas se reúnem para ver o que foi construído desde a última revisão. Seguindo o objetivo ágil de software funcionando, a equipe deve ser capaz de mostrar novos recursos e funcionalidades.

Esta parte da revisão pode ser chamada também de Sprint Demo.

🎯 Objetivo de uma Sprint Review

Curiosamente, o objetivo fundamental e o resultado da Sprint Review são frequentemente omitidos ou ignorados, ou desconhecidos pelas equipes. O objetivo da Sprint Review é coletar feedback sobre o Incremento do Produto das partes interessadas, considerar as condições atuais de negócios (como o uso do produto, concorrentes, vendas, marketing etc.) e planejar o que fazer a seguir.

As partes interessadas, tanto internas quanto, em alguns casos, externas, devem ser convidadas para a Sprint Review.

Em algumas empresas, clientes e usuários são convidados para as Sprint Reviews – se possível, dependendo de contratos e outros fatores.

Ainda observo em algumas organizações que os Times Scrum mostram apenas uma demonstração e código para si mesmos.

Não há interessados ​​convidados. Em vez disso, os desenvolvedores mostram o código e os testes para o Product Owner.

Nesse caso, não há inspeção e adaptação verdadeiras. O Product Owner não deve se surpreender com o Incremento.

Ao contrário, todo o Time Scrum deve buscar feedback dos outros.

🔍 Demonstrar não é tudo

Mas a demonstração é apenas uma parte da revisão da sprint. Além disso, a equipe deve revisar os objetivos do produto e como o trabalho concluído se alinha com os objetivos gerais do projeto.

A equipe deve determinar se o trabalho feito na sprint anterior ajudou a atingir as metas ou ficou aquém – talvez a equipe tenha trabalhado em algo ótimo, mas não progrediu em direção à meta.

Este é o momento em que a equipe pode corrigir o curso; talvez, ele escolha histórias diferentes para a próximo sprint, ou mude o foco, ou, se necessário, procure alterar os recursos da equipe para que diferentes histórias possam ser realizadas em sprints futuras ou para impactar a velocidade da equipe.

A revisão da sprint também ajuda as partes interessadas a entender melhor o status do produto e permite que elas usem e vejam o produto, talvez pela primeira vez.

Isso pode levar a discussões produtivas sobre o produto, incluindo se ele está pronto para os clientes, o que ainda precisa ser construído, o plano de lançamento e a composição de sprints futuros.

Até este ponto, esta reunião poderia ser realizada com um número limitado de pessoas – nem todo desenvolvedor precisa apresentar e nem todo stakeholder precisa revisar.

No entanto, a revisão da sprint ganha valor quando mais pessoas participam – e participam. Isso porque, além de demonstrações e revisões de metas, essa é uma atividade onde são feitas conversas e conexões importantes.

Vejamos alguns desses outros benefícios potenciais da revisão da sprint.

🗣️ Feedback para a equipe de desenvolvimento

No gerenciamento de projetos tradicional, a equipe do produto é responsável por escrever as especificações, entregá-las aos desenvolvedores e esperar que a equipe construa o que foi solicitado.

Durante o intervalo, os desenvolvedores geralmente não colaboram muito com a equipe do produto, esperando até que estejam “concluídos” para reunir todos novamente.

Este processo sempre causou frustração. Mesmo a melhor equipe terá dificuldade para entregar exatamente a coisa certa para o produto. Isso pode ser porque as necessidades mudaram, ou novas informações do cliente foram aprendidas, ou pode ser que os detalhes estivessem faltando na especificação original, e a equipe construiu o que achava certo (às vezes conhecido como critério do desenvolvedor) e acabou errado.

O Agile contorna isso com o ciclo do-inspecionar-adaptar que é incorporado ao processo.

Em vez de esperar até que tudo esteja completo, o Agile coloca pontos de verificação ao longo do caminho, onde o que foi “feito” pode ser “inspecionado” e quaisquer mudanças de direção ou alterações no produto podem ser discutidas com a equipe e outras partes interessadas, se necessário.

Ao adicionar esse ciclo de feedback ao processo, a equipe está constantemente ajustando o que está trabalhando e o que está priorizando e mudando de direção antes que seja tarde demais.

Fazer com que as partes interessadas forneçam feedback à equipe de desenvolvimento durante a revisão da sprint é uma ótima maneira de criar um produto melhor e manter o projeto na direção certa.

📢 Feedback da equipe de desenvolvimento

O feedback é melhor quando é multidirecional. Não deve ser limitado apenas aos stakeholders dando seus comentários aos desenvolvedores, bons e ruins, e a partir disso desenvolvedores e fazem mudanças.

Este também deve ser um momento para a equipe de desenvolvimento dar feedback às partes interessadas do projeto, incluindo a equipe do produto, a equipe de design ou qualquer outra pessoa que trabalhe com os desenvolvedores.

Pode ser que os requisitos não tenham ficado claros recentemente e a equipe os queira em um formato diferente.

Ou talvez haja uma maneira melhor de fazer o que a equipe de produto solicitou, e a equipe de desenvolvimento quer falar sobre como fazer as coisas de maneira diferente.

Portanto, além de dar feedback aos desenvolvedores, os desenvolvedores devem ter o poder de dar feedback ao produto.

Mais do que apenas dar comentários sobre como o projeto está operando, os desenvolvedores também devem usar parte desse tempo para entender melhor o produto e como seu trabalho está impactando o quadro geral.

Quando a equipe entende o raciocínio por trás do trabalho, eles tendem a ser mais bem-sucedidos em construí-lo.

A equipe também deve se sentir à vontade para dar feedback sobre o produto em si. Isso pode ser novas ideias para recursos, alterações em outros adicionais ou maneiras de atender a um novo cliente ou um novo caso de uso.

Se a equipe de desenvolvimento estiver trabalhando em estreita colaboração com o produto, provavelmente terá insights e pontos de vista que outras partes interessadas não têm.

Extrair isso da equipe durante a revisão da sprint pode ser uma ótima maneira de discutir novas ideias e ajudar a colaborar em um produto melhor.

🤝 Construção de relacionamento

A revisão da sprint geralmente é um evento positivo. Novas partes do produto podem ser reveladas pela primeira vez, metas foram adiantadas ou até mesmo concluídas, e pode haver conquistas a serem anunciadas e comemoradas.

Pela natureza alegre do evento, também é um bom momento para a construção de relacionamento com os stakeholders.

Embora alguns membros do desenvolvimento possam trabalhar em estreita colaboração com algumas partes interessadas, é raro que toda a equipe trabalhe em conjunto.

Fazer com que a equipe colabore durante a revisão da sprint é uma maneira natural de todas as partes interessadas colaborarem e trabalharem juntas de maneiras que podem não ter a chance de outra maneira.

O Agile valoriza muito os relacionamentos. No manifesto original, dois dos itens valorizam as pessoas sobre o processo e a colaboração do cliente.

Usar a revisão da sprint para ter toda a equipe, stakeholders e clientes, cria o ambiente para relacionamentos melhores e fortes entre todos.

Em geral, quanto melhores forem os relacionamentos entre a equipe de desenvolvimento e as partes interessadas, melhores serão os resultados.

Os desenvolvedores terão uma melhor compreensão das necessidades dos clientes, e a equipe de produto terá uma melhor avaliação de como trabalhar melhor com a equipe.

Todos são responsáveis ​​por construir valor, e quanto mais as pessoas colaborarem e apreciarem umas às outras, melhores serão os resultados.

🎁 O take-away

A reunião de revisão da sprint é uma parte importante do processo Agile. Uma parte da revisão inclui uma demonstração do trabalho concluído recentemente, permitindo que as partes interessadas vejam o software em funcionamento pela primeira vez.

O restante da revisão se concentra nas metas, como o produto está indo, como o trabalho está ajudando a atingir as metas e algumas discussões sobre lançamentos futuros.

Além disso, a revisão da sprint tem três funções mais importantes:

  • Fornecer feedback para a equipe de desenvolvimento das partes interessadas;
  • Fornecer feedback para as partes interessadas da equipe de desenvolvimento;
  • Ajudar a construir e fortalecer o relacionamento entre todos os membros da equipe.

Pode ser tentador focar na parte de demonstração da revisão da sprint, mas isso é apenas metade da história. Ao ter uma visão mais ampla do produto, mais partes interessadas podem se envolver e participar, o que levará a uma equipe mais forte e a um produto melhor.

👥 Como envolver as partes interessadas em suas revisões de Sprint

Essa ausência de stakeholders pode ser consequência do progresso do produto, pois uma colaboração transparente entre a equipe e os stakeholders é fundamental para a construção de um produto de sucesso.

Como você pode evitar avaliações de Sprint ruins? Como coletamos feedback das partes interessadas? Como tornamos este evento Scrum valioso e significativo?

Aqui estão cinco razões pelas quais seus stakeholders não estão participando de revisões de sprint com soluções.

1. Você pode ter agendado a Revisão da Sprint na hora errada🕛

MOTIVO: O agendamento apático é uma das principais razões para a ausência de stakeholders nas revisões de sprint. As partes interessadas podem ter outros compromissos essenciais no dia da revisão da sprint.

Portanto, mesmo que estejam fisicamente disponíveis em sua agenda, sua mente pode estar absorta em outro trabalho importante.

RECURSO: Comunicação eficaz entre a equipe e as partes interessadas durante o agendamento.

Se possível, o cronograma da revisão do sprint deve ser definido no meio da semana em vez do último dia da semana. Na minha experiência, as Sprint Reviews de sexta-feira tiveram quase 50% das partes interessadas não aparecendo.

  • Pense nos resultados e no propósito do evento.
  • Tenha um cenário! Achei muito útil criar uma estratégia curta com o que deve ser discutido e quais perguntas vamos fazer aos nossos stakeholders.
  • Deixe algum espaço para perguntas, preocupações e novas ideias das partes interessadas.
  • Esteja preparado para uma discussão, não apenas uma apresentação.
  • Esteja preparado com algumas técnicas de facilitação relevantes para este evento. (tenha cuidado, nem todos os métodos de facilitação são apropriados para a Revisão da Sprint).
  • Pense no número de pessoas. Quantas equipes estarão presentes? Quantos interessados ​​virão? Escolha as técnicas que são relevantes para sua situação.

2. Sua Sprint Review é apenas uma demonstração🔎

MOTIVO: Outro motivo pelo qual um stakeholder pode pular a revisão do sprint pode ser por que você não consegue captar o interesse dele. A equipe às vezes exagera e converte a Sprint Review como uma demonstração.

Portanto, quando é apresentado apenas como uma demonstração e todos os outros interessados ​​estão apenas ouvindo, muitas vezes é sequestrado por uma discussão profunda unilateral que pode não interessar a todos os interessados.

RECURSO: O ônus está no Scrum Master para facilitar um fluxo suave de comunicação que mantém todas as partes interessadas envolvidas. A revisão pode ser mais imersiva onde as partes interessadas são solicitadas a se envolver melhor.

Pela minha experiência, costumo fazer uma pausa suave, cutucar todas as partes interessadas e convidá-las a abrir seus pensamentos. Algo muito interessante que pode ser feito é criar um acordo de trabalho.

  • Acordo de trabalho – Uma prática poderosa que pode ajudá-lo a facilitar a Revisão da Sprint e outros eventos. Achei valioso reunir as partes interessadas e as equipes. Nós criamos nossos Acordos de Trabalho (para este evento e futuras revisões também). O resultado pode
    incluir as seguintes regras:
  1. As partes interessadas fornecem feedback;
  2. Todos podemos fazer perguntas;
  3. Discussão e evidências em vez de brigas improdutivas;
  4. Respeitar os time-boxes;
  5. Compartilhar perspectivas de negócios;
  6. Compartilhar perspectivas de tecnologia e viabilidade;
  7. Pelo menos um representante do departamento X está presente nas Sprint Reviews.

Estes são apenas meus exemplos. Vocês podem criar juntos regras completamente diferentes que sejam relevantes para suas equipes, partes interessadas e situações.

3. Sua Sprint Review não está emocionante 🥲

Quantas vezes você já pensou: “Esta Sprint Review é inútil e chata!” ou “Estamos apenas revisando internamente o que já vimos antes como Time Scrum. Não temos feedback novo. Vamos pular este evento. Perda de tempo.”

MOTIVO: Às vezes, as partes interessadas não consideram a revisão do sprint necessária. Eles provavelmente não comparecerão, pois podem conhecer a discussão e as decisões tomadas durante o evento.

RECURSO: Antes do evento, as equipes Scrum devem encontrar maneiras de atrair ou puxar os interesses de seus stakeholders. É melhor estacionar o que provavelmente virá no próximo Sprint e incluir uma palavra na agenda da sua Revisão da Sprint.

Na minha experiência, isso também significaria uma participação mais ativa das partes interessadas, pois elas estarão ansiosas para ouvir o que está por vir.

  • Utilize Gravação de um vídeo – além de anotar o que foi dito, considere a gravação de um vídeo, como facilitador, você não precisa ser essa pessoa que desenha ou escreve.
    Certifique-se apenas  de que alguma gravação foi feita. A gravação de um vídeo usando a funcionalidade cria uma excelente oportunidade de visualização diferente das notas. E pode abrir nossos cérebros para mais ideias e criatividade.
  • Lean Coffee1 – esta técnica pode estruturar sua discussão quando um grupo tem muitos comentários, ideias e perguntas.

4. Fluxo 🔃

MOTIVO: O fluxo da revisão também pode desinteressar a parte interessada. Discussões dispersas durante a revisão podem tornar a reunião tediosa. Às vezes, o ritmo inconsistente e as transições difíceis também podem dissuadir as partes interessadas.

RECURSO: O Scrum Master deve intervir e ajudar a equipe scrum a definir e manter um ritmo rápido do evento. Isso pode ser feito com um planejamento meticuloso antes da reunião, incentivando uma conversa tranquila e sem esforço entre a equipe e as partes interessadas.

  • Perguntas abertas – comece com perguntas: o que, quando, por que, por que motivo, como. As perguntas fechadas são usadas apenas se você quiser confirmar algo ou terminar a atividade.
  • 15% Solutions2 – esta prática pode restringir muitos pontos de ação (também pode ser ótimo para
    outros eventos).

5. Feedback📣

MOTIVO: O objetivo principal da revisão da sprint é receber feedback das partes interessadas, mas muitas vezes, a parte interessada pode não ter a oportunidade de contribuir para a conversa, pois a equipe ingenuamente fica obcecada com sua apresentação.

RECURSO: A equipe pode planejar uma pausa para conversa após cada demonstração para que a parte interessada possa acompanhar o ritmo e os desenvolvimentos dos backlogs do produto.

Na minha experiência, após cada demonstração de recurso, há uma pequena pesquisa que acontece instantaneamente. Dessa forma, você pode realmente transformar uma demonstração em uma sessão de feedback colaborativo.

🗣️ Como Facilitar o Feedback

Crie um ambiente seguro que permita transparência. Estou ciente de que em algumas organizações, dependendo da cultura, inicialmente, alguns stakeholders chegam a Sprint Review com expectativas, energia e atitude diferentes. Achei útil configurar a cena antecipadamente nas primeiras Sprint Reviews. Pode incluir o objetivo do evento, a necessidade de perguntas e coleta de feedback, inspeção do mercado, oportunidades de negócios e tecnologia, etc.

Pense no que seria apropriado em seu contexto. Esta é uma sessão colaborativa. Certifique-se de que todos possam participar – ou fazer perguntas ou fornecer feedback.

Veja algumas dicas de técnicas abaixo:

  • Incentive as pessoas a falar.
  • Facilitar a visualização do feedback ajuda as pessoas a ver o que foi dito antes e cria um espaço para ideias criativas. Além disso, garante que todo o feedback seja coletado. Lembre-se, como facilitador, você pode pedir a alguém para ajudá-lo. Ser um facilitador não significa que todo o trabalho do escriba pertence a você.
  • Observe a dinâmica. Se o engajamento diminuir, reaja e aja de acordo. Às vezes, tornar as coisas transparentes ajuda (O que aconteceu? Por que isso aconteceu?).
  • Quando relevante, faça perguntas abertas (O que você acha? Por qual motivo você propõe isso? Que evidências você tem? O que os clientes dizem? Como eles usam o produto? O que poderia mudar o status quo? Qual é o resultado dos experimentos? Qual é o progresso em direção ao Objetivo do Produto?).
  • Foco no valor. Não se esqueça do mais importante para a Sprint Review: discutir  valor e clientes.

Conclusão

Uma vez que percebemos o propósito da Sprint Review, fica mais fácil facilitar este evento. Nesta postagem do blog, forneci algumas dicas de facilitação e respostas com base na minha experiência e conhecimento.

Agora, depois de conhecer algumas dicas, é hora de colocá-las em prática! Tente repensar seu estilo atual e dê uma olhada nestes conselhos. Espero que você encontre algo que nunca praticou até agora e que incorpore em suas revisões da Sprint. Boa sorte!

Definição de Pronto e Definição de feito (DoR e DoD)

PARTE 1: Definição de DoR e DoD

Os conceitos de Definição de Pronto (DoR) e Definição de feito (DoD) são termos usados para reforçar a Transparência, garantir a Qualidade Integrada e definir as expectativas corretas para os itens de trabalho a serem planejados, desenvolvidos e concluídos durante o desenvolvimento de um produto Ágil.

Porque?

Primeiramente a escrita de DoR e DoD são ferramentas de comunicação entre as partes, por exemplo, Dono do Produto e Equipe de Desenvolvimento para definir expectativas claras – Transparência.

Visto que é um padrão formalmente acordado e um entendimento comum reduzirão retrabalhos e defeitos, cuidando da qualidade durante a construção do produto, e não por meio da inspeção do produto – Qualidade Integrada.

Inclusive  DoR e o DoD definem um padrão de qualidade para todos os participantes envolvidos, portanto, é crucial que as próprias equipes criem seus DoR e DoD, os possuam e os sigam. Na criação dessas definições, duas coisas são cruciais: consultar os princípios do Agile (SAFe) e garantir o acordo total da equipe.

Como?

O DoR e o DoD devem ser vistos como critérios de entrada e saída, com o DoR servindo como uma pré-condição para verificar se um item está pronto para ser levado para a etapa atual e testar o DoD se um item está pronto para ser movido para a próxima etapa.

DoR e DoD podem ser aplicados em qualquer nível (por exemplo, equipe, programa, grande solução, portfólio, empresa, etc.) e a diferentes itens (por exemplo, histórias de usuário, recursos, capacidades, epopeias, iterações, lançamentos, incrementos de programa e até mesmo um programa piloto Agile completo).

A aplicação mais comum e básica dos conceitos DoR e DoD é vista no nível da equipe à medida que são aplicados às Histórias de Usuário.

Essas definições devem ser visíveis no ambiente de trabalho da equipe e usadas quando os itens são movidos de uma etapa para outra, especialmente quando os itens são levados para execução e quando são movidos para concluídos!

Os itens aos quais essas definições são aplicadas devem ter um resultado binário: Concluído ou Não Concluído. Evite a tentação de “quase pronto”, “meio que feito” ou “99% feito”.

Evolução DoR e DoD

DoR e DoD são acordos vivos que evoluem à medida que os usuários aprendem melhores maneiras de fazer seu trabalho, eles adquirem excelência em seu trabalho, sua prática amadurece, sua pista arquitetônica ou ambiente de desenvolvimento melhoram, eles adquirem melhores ferramentas, o contexto de suas mudanças de trabalho, surgem novos regulamentos ou requisitos de conformidade, etc.

DoR e DoD são um reflexo da realidade atual e não devem impor um padrão que seja irreal.

Com o tempo, o DoR e o DoD melhoram, levando os padrões e a qualidade cada vez mais alto. Em certo sentido, DoR e DoD podem ser usados ​​como um indicador da maturidade das equipes Agile e sua jornada Agile.

As equipes passam de um DoR e DoD de alto nível para um nível mais detalhado, de um nível mais flexível para outro mais rigoroso, e eventualmente alcançando a capacidade de “Produto Potencialmente Remetível” a cada Iteração.

Essa abordagem é um reflexo do princípio do Manifesto Ágil “Atenção contínua à excelência técnica e um bom design aumenta a agilidade”.

DoR e DoD vs Critérios de Aceitação (AC)

Tendo em vista que DoR e DoD são mais genéricos e frequentemente aplicáveis ​​a um amplo conjunto de itens, enquanto os Critérios de Aceitação (AC) são específicos para um item.

Por exemplo, no nível da equipe, DoR e DoD se aplicam a todos os itens do backlog da equipe, como User Stories, enquanto no nível do programa, eles se aplicam a todos os itens do backlog do programa, como Features, e assim por diante.

Já que DoD e AC são conceitos ortogonais e ambos são obrigados a considerar um item Concluído.

Entretanto DoD é uma espécie de superconjunto de AC. Juntos, DoR e DoD garantem a qualidade de um item e o AC garante sua funcionalidade. Por meio do AC, os itens de trabalho ficam mais específicos.

Ou seja a AC valida que o item certo foi construído. O DoD verifica se o item foi construído corretamente, portanto, as equipes podem incluir NFRs (requisitos não funcionais) relevantes em seu DoD como restrições no design local e nas decisões de implementação.

Para esclarecimento a diferença entre os dois é que o DoD é comum para todas as histórias de usuário, enquanto os critérios de aceitação são aplicáveis ​​a histórias de usuário específicas. Os critérios de aceitação de cada história de usuário serão diferentes com base nos requisitos dessa história de usuário.

O DoR e o DoD facilitam as mudanças culturais e promovem uma nova mentalidade, enquanto o AC visa a excelência técnica.

DoR e DoD são a autoridade da equipe, enquanto o AC é a autoridade do cliente ou de seus representantes (Product Owner / Manager).

Autonomia vs Conformidade

Uma empresa pode ter certos requisitos nos níveis de programa ou solução que devem ser incorporados ao DoR e DoD. Por exemplo, o uso de certas ferramentas, uma certa forma de relatório, teste, financiamento, etc.

Embora as equipes tenham autonomia para criar seus próprios DoR e DoD, alguns requisitos podem vir como parte da política ou padrão corporativo que exige a conformação das equipes. Esses últimos requisitos farão parte dos, digamos, critérios fixos para o DoR e o DoD.

Cuidado com o anti-padrão DoR

Por outro lado o DoR pode facilmente cruzar a linha entre Agile e Waterfall quando a equipe não consegue realizar nenhum trabalho ou trabalho suficiente para uma iteração até que algo mais seja concluído. É quando um DoR se transforma em um anti-padrão.

Visto que é normal permitir a entrada de algumas histórias de usuários se eles não estiverem 100% reclamando das regras. Lembre-se de que o princípio iterativo e incremental também se aplica às regras contidas no DoR.

De acordo com Mike Cohn:

“quando um DoR inclui uma regra de que algo deve ser feito antes que a próxima coisa possa começar, ele move a equipe perigosamente perto do processo de passagem de estágio
… E pior, pode ser um grande e perigoso passo para trás em direção a um abordagem em cascata ”.

Entretanto algumas regras no DoR devem ser atendidas, como Critérios de Aceitação e Estimativa para Histórias de Usuário, enquanto algumas das regras podem ser apenas desejadas.
Conforme as equipes amadurecem em sua prática, seu DoR pode se tornar redundante. É apenas no início da jornada ágil que as equipes precisam seguir algumas diretrizes acordadas por escrito.

PARTE 2: Diretrizes para a criação de DoR e DoD

Essas diretrizes são desenvolvidas de forma genérica e podem ser adaptadas a qualquer nível (Equipe, Programa, Grande Solução, Portfólio) ou propósito e atividade, como Liberação, Iteração, Incremento do Programa ou um programa Piloto Ágil completo.

Facilite um workshop com toda a equipe ágil1. Certifique-se de que este seja um exercício de equipe inteira. Dependendo do nível e da finalidade do DoR e do DoD, os participantes podem incluir o proprietário do produto, gerenciamento de produto, gerenciamento de solução, gerenciamento de liberação, arquitetos, equipes de desenvolvimento, equipe de sistema, escritório jurídico, clientes, fornecedores e muito mais. Providencie participantes online, se necessário.

Dependendo do nível e do tamanho da equipe, recomenda-se uma sessão de 2 a 4 horas. Uma sessão (ou sessões) de acompanhamento pode ser organizada, se necessário.

Certifique-se de que a sala tenha um quadro branco, suprimentos como post-its, marcadores e agulhas e espaço suficiente para colaboração e interação. Acomode-se para colaboração online, se necessário.

Criação de DoR para histórias de usuários / features Criação do DoD para histórias de usuários / features
  • Identifique todas as atividades necessárias para preparar uma história de usuário para o planejamento de iteração / um recurso pronto para as equipes de planejamento de PI ou Agile escreverem histórias de usuário.
    • Foco em atividades que agregam valor
    • Essas atividades podem variar amplamente dependendo do produto (software, hardware, mainframe, design ou artefatos conceituais, etc.)
  • Selecione apenas as atividades que ocorrem novamente para quase todas as histórias de usuário / recurso para ficar pronto
  • Registre todas essas atividades recorrentes em uma lista abrangente de critérios potenciais para DoR
  • Priorizar a lista de atividades de cima para baixo
  • Faça uma lista restrita apenas dos critérios que podem ser atendidos de forma realista antes que uma história de usuário seja puxada para o planejamento / recurso de iteração para as equipes de planejamento de PI ou Agile para escrever histórias de usuário
    • A equipe decide o quão completo e perfeito eles querem seu DoR neste ponto
    • Preste atenção em como a estimativa de Recursos deve ser feita antes das Histórias de Usuário associadas
    • Estimativa e depois que as Histórias de Usuário são estimadas
  • Obtenha a concordância e o compromisso da equipe com os critérios selecionados, que agora são o DoR para Histórias de usuários / recursos
  • Identifique todas as atividades necessárias para concluir uma história de usuário / um recurso.
    • Foco em atividades voltadas para a qualidade do produto (Qualidade Integrada).
    • Essas atividades podem variar amplamente dependendo do produto (software, hardware, mainframe, design ou artefatos conceituais, etc.)
    • Atividades de aprovação ou assinatura com partes externas e partes interessadas que estão fora do controle da equipe podem ser omitidas.
  • Selecione apenas as atividades que ocorrem novamente para que quase todas as histórias de usuário / recurso sejam concluídas.
  • Registre todas essas atividades recorrentes em uma lista abrangente de critérios potenciais para DoD
  • Priorizar a lista de atividades de cima para baixo
  • Faça uma lista restrita apenas dos critérios que podem ser atendidos de forma realista antes que uma história / recurso de usuário seja concluída o A equipe decide o quão completo e perfeito eles querem seu DoD neste ponto
    • Preste atenção ao que fazer se um recurso pode ser considerado completo, mas ainda está associado
    • Histórias de usuários abertas
  • Obtenha a concordância e o compromisso da equipe com os critérios selecionados, que agora são o DoD para Histórias de usuários / recursos

Uma vez que o DoR e o DoD são criados, eles devem ser publicados, mantidos visíveis, de preferência na área de trabalho da equipe e nas ferramentas Agile que usam. Imprima-o como um pôster colorido que chama a atenção para enfatizar sua importância.

Repita todo o exercício descrito nas diretrizes acima em uma cadência regular, como fim da Iteração ou PI2 para expandir e refinar ainda mais o DoR e o DoD. Use os critérios restantes da lista abrangente inicialmente criada e quaisquer novos critérios devem ser adicionados.

PARTE 3: Exemplos DoR e DoD

Os exemplos DoR e DoD abaixo contêm critérios gerais para diferentes níveis. Conforme declarado, DoR e DoD são acordos informados pela realidade por todos os participantes, portanto, a tabela deve ser considerada apenas como um exemplo.

Desenvolvimento de Produto
Definition of Ready Definition of Done
Time:

Histórias de usuários

  • Uma história de usuário está pronta se, por exemplo:
    Possui critérios de aceitação que podem ser testados objetivamente
  • Estimado por toda a equipe de desenvolvimento
    Socializado com toda a equipe
  • Tem o tamanho certo que pode ser concluído em uma Sprint, de preferência de 2 a 3 dias ou não maior do que [certos] pontos da história
  • Está em conformidade com o Modelo de INVEST (Independente, Negociável, Valioso, Estimativa, Pequeno, Testável) e não tem dependências externas
  • Carregado / criado na ferramenta / ambiente Agile da equipe
  • Escrito no formato de voz do usuário:
    QUEM <alguém>, O QUE <fazer algo>, POR QUE <algum resultado ou benefício>. Por exemplo.:
    COMO <alguém>, EU QUERO <fazer algo>, ASSIM QUE <algum resultado ou benefício>
Uma história de usuário é concluída se, por exemplo:

  • Atende aos seus critérios de aceitação
  • Testado (por exemplo, para software / hardware)
  • Validado (por exemplo, para documentos de design, modelos)
  • Demonstrado para as partes interessadas
  • Não há mais defeitos que devem ser corrigidos
  • Documentado
  • Aceito pelo Dono do Produto
Programa:

Features

Um recurso está pronto se, por exemplo:

  • Possui critérios de aceitação que podem ser testados objetivamente
  • Tem o tamanho certo que pode ser concluído em um PI
  • Tem histórias de usuário definidas
  • Carregado na ferramenta / ambiente Agile da equipe
  • Estimado (pontos da história, tamanho da camiseta, …)
  • Escrito na Matriz de Recursos e Benefícios:

Feature – Uma frase curta que fornece um nome e contexto;
Hipótese de benefício – O benefício mensurável proposto para o usuário final ou empresa

Um recurso é concluído se, por exemplo:

  • Atende aos seus critérios de aceitação
  • Testado e integrado
  • Demonstrado para as partes interessadas
  • Documentado e treinamento fornecido
  • Não há mais defeitos que devem ser corrigidos
  • Suas histórias de usuário necessárias são concluídas e todas as histórias de usuário restantes são cuidadas, por exemplo, desacopladas do recurso e movidas para o backlog, ou excluídas, ou …
  • Aceito pela Gestão de Produto
Solução em larga escala:

Capacidades

Uma capacidade está pronta se, por exemplo:

  • Tem o tamanho certo que pode ser concluído em um PI, embora por vários ARTs
  • Seus facilitadores associados para o trabalho técnico necessário são identificados
  • Socializado com a Gestão de Produto das ARTs relevantes
  • Descrito usando uma frase e hipótese de benefícios, semelhante a Características:

Capacidade – Uma frase curta que fornece um nome e contexto;
Hipótese de benefício – O benefício mensurável proposto para o usuário final ou empresa

Uma capacidade é realizada se, por exemplo:

  • Seus recursos associados estão concluídos
  • É implantado no ambiente de teste
  • Seus NFRs associados são atendidos
  • Integração de ponta a ponta, testes, validação e verificação são feitos
  • Não há mais defeitos que devem ser corrigidos
  • Demonstrado para as partes interessadas
  • Documentado e treinamento fornecido
  • Aceito pela Gestão da Solução
Lançamento do produto
Uma liberação está pronta se, por exemplo:

  • Todos os recursos / capacidades são concluídos
  • Teste de integração ponta a ponta é feito
  • Teste de regressão é feito
  • A documentação de liberação está completa
  • Não há mais defeitos que devem ser corrigidos
  • O guia do usuário é criado
  • O treinamento do usuário é criado
  • Aprovado por Gerenciamento de Produto / Solução
  • Aprovado pelo Gerenciamento de Liberação
Uma liberação é realizada se, por exemplo:

  • Testes de integração ponta a ponta e V&V são realizados
  • Teste de regressão é feito
  • O teste de desempenho é feito
  • NFRs são atendidos
  • Não há mais defeitos que devem ser corrigidos
  • Os padrões estabelecidos são atendidos
  • O treinamento é entregue
  • Aprovado pelo Produto / Solução
  • Gerenciamento e Gerenciamento de Liberação

Conclusão

DoR e DoD são uma lista de verificação para verificar se todas as atividades de valor agregado e orientadas pela qualidade foram concluídas. Essa abordagem aparentemente simples tem um impacto tremendo na qualidade, entrega, previsibilidade e precisão do produto com a estimativa de trabalho.

Embora DoR e DoD sejam genéricos para todos os itens na categoria, nem todas as suas atividades podem ser aplicáveis ​​a cada item (história de usuário, recurso, etc.). Portanto, a autoridade e a discrição da equipe são necessárias para lidar com as exceções.

Frequentemente, essas definições são uma lista abrangente para garantir que todas as atividades importantes sejam consideradas.

Ao desenvolver o DoR e o DoD, se uma precaução deve ser tomada, não defina a barra de qualidade muito alta para torná-la irreal. Não defina-o para a altura da melhor equipe realizadora para ver apenas as novas equipes fracassarem ou lutarem para alcançá-lo.

Qualquer coisa que não seja realista para ser alcançada no nível atual pode ser movida para o próximo nível superior. Por exemplo, se o teste de integração não for possível dentro da Iteração, mova-o para o Incremento do Sistema, se não, mova-o para Release, etc. Isso é o que se considera atingir maturidade Agile com o tempo. Claro, o objetivo é mudar constantemente a qualidade para a esquerda.

Finalmente, como o SAFe Framework3 como um todo, o DoR e o DoD também são escaláveis, ou seja, os critérios são cumulativos em cada nível.

Cada definição de nível superior assume todos os critérios dos níveis inferiores. Por exemplo, o DoD no nível do programa assume todos os critérios do nível da equipe mais os novos critérios do nível do programa e assim por diante.

Da mesma forma, os critérios de liberação assumem todos os níveis predecessores mais aqueles específicos para a liberação.

User Story – O que preciso saber sobre histórias de usuário

User Story (histórias de usuários) fazem parte de uma abordagem ágil que ajuda a mudar o foco de escrever sobre requisitos para falar sobre eles. Cada história ágil do usuário inclui uma ou duas frases escritas e, mais importante, desencadeia uma série de conversas sobre os recursos e funcionalidades que a história do usuário representa.

Sumário

As histórias do usuário são uma maneira de descrever a funcionalidade desejada dos itens de lista de pendências do produto. Histórias de usuários de alta prioridade tendem a ser mais detalhadas; histórias de usuários de baixa prioridade tendem a ser menos detalhadas.

As equipes adicionam detalhes à medida que as histórias aumentam em prioridade, criando critérios de aceitação ou dividindo grandes histórias em pedaços menores ( ou ambos ).

O que é uma User Story?

Uma história de usuário é uma descrição curta e simples de um recurso contado da perspectiva da pessoa que deseja o novo recurso, geralmente um usuário ou cliente do sistema. As histórias do usuário geralmente seguem um modelo simples:

Como um tipo de usuário < >,
quero < algum objetivo >
para que < seja um motivo >.

Historicamente, as histórias dos usuários eram deliberadamente mantidas informais, escritas em cartões de índice ou notas adesivas, armazenadas em uma caixa de sapatos e dispostas em paredes ou mesas para facilitar o planejamento e a discussão.

Sua impermanência facilitou rasgá-los, jogá-los fora e substituí-los por novas histórias, à medida que se aprendeu mais sobre o produto que está sendo desenvolvido.

Atualmente, as histórias dos usuários podem ser facilmente armazenadas em um problema de Jira ou no quadro de Trello.

Não deixe que o fato de uma história de usuário existir em uma ferramenta o torne menos disposto a descartar histórias quando elas não forem mais necessárias!

As histórias de usuários são projetadas para mudar fortemente o foco, da escrita de recursos para a discussão deles. De fato, essas discussões são mais importantes do que qualquer texto escrito.

O que é uma boa User Story?

As histórias ágeis dos usuários são compostas por três aspectos que Ron Jeffries nomeou em 2001 com a maravilhosa aliteração de cartão, conversa e confirmação:

  1. Cartão: Descrição escrita da história, usada para planejamento e como lembrete
  2. Conversa: Conversas sobre a história que servem para detalhar os detalhes da história
  3. Confirmação: Testes que transmitem e documentam detalhes que podem ser usados para determinar quando uma história está concluída.

As histórias de usuários têm muitas vantagens, mas o mais importante pode ser que toda história de usuário seja um espaço reservado para uma conversa futura.

Como escrever uma história de usuário

Escrever boas histórias de usuários no Scrum requer uma compreensão do modelo básico de história do usuário, um foco no usuário ou cliente e uma imagem clara da funcionalidade desejada.

Modelo de história do usuário

Ao escrever uma história de usuário, lembre-se de que as histórias de usuário seguem um modelo padrão:

Como um tipo de usuário < >,
quero < algum objetivo >
para que < seja um motivo >.

Exemplos de histórias de usuários

Uma das melhores maneiras de aprender a escrever uma história de usuário em ágil é ver exemplos. Abaixo está um exemplo de história ou duas de usuário. Estes são alguns exemplos reais de histórias de usuários que descrevem a funcionalidade desejada em uma versão inicial do site da Scrum Alliance.

  • Como membro do site, posso preencher um aplicativo para me tornar um instrutor certificado de scrum para poder ensinar  e certificar outros Scrum Masters ( PSM ) e Product Owners ( PSPO ).
  • Como treinador, quero que meu perfil liste minhas próximas aulas e inclua um link para uma página detalhada sobre cada uma, para que os possíveis participantes possam encontrar meus cursos.
  • Como visitante do site, posso acessar notícias antigas que não estão mais na página inicial, para poder acessar as coisas que me lembro do passado ou que outras pessoas mencionam para mim.
  • Como visitante do site, posso ver uma lista de todos os próximos cursos de certificação “ ” e posso paginar por eles se houver muito, para que eu possa escolher o melhor curso para mim.

Observe que você não vê nenhuma história de usuário: “Como proprietário do produto, quero uma lista de cursos de certificação para que…” O proprietário do produto é uma parte interessada essencial, mas não é o usuário / cliente final. Ao criar histórias de usuários, é melhor ser o mais específico possível sobre o tipo de usuário.

Quem escreve histórias de usuários?

Quem escreve histórias de usuários? Qualquer pessoa pode escrever histórias de usuários.

O proprietário do produto escreve histórias de usuários?

É responsabilidade do proprietário do produto garantir a existência de um acúmulo de histórias ágeis de usuários, mas isso não significa que o proprietário do produto seja quem as escreve. Ao longo de um bom projeto ágil, você deve esperar ter histórias de usuários escritas por cada membro da equipe.

Observe também que quem escreve uma história de usuário é muito menos importante do que quem está envolvido nas discussões.

Quando as histórias dos usuários são escritas?

As histórias dos usuários são escritas em todo o projeto ágil. Normalmente, um workshop de redação de histórias é realizado perto do início do projeto ágil.

Todos na equipe participam com o objetivo de criar um backlog do produto que descreva completamente a funcionalidade a ser adicionada ao longo do projeto ou um ciclo de lançamento de três a seis meses dentro dele.

Algumas dessas histórias ágeis de usuários serão, sem dúvida, épicas. Mais tarde, as épicas serão decompostas em histórias menores que se encaixam mais rapidamente em uma única iteração.

Além disso, novas histórias podem ser escritas e adicionadas ao backlog do produto a qualquer momento e por qualquer pessoa.

Você pode mostrar outros exemplos de user history?

Como um exemplo mais genérico de escrever histórias de usuários no Scrum, essas são algumas histórias típicas de usuários para um site de postagem e pesquisa de empregos:

  • Um usuário pode postar seu currículo no site.
  • Um usuário pode procurar empregos.
  • Uma empresa pode postar novas vagas.
  • Um usuário pode limitar quem pode ver seu currículo.

Como os detalhes são adicionados às user historys?

Os detalhes podem ser adicionados às histórias do usuário de duas maneiras:

  • Dividindo uma história de usuário em várias histórias menores de usuário.
  • Adicionando condições de satisfação: Critérios de aceitação ( ).

Quando uma história relativamente grande é dividida em várias histórias de usuários ágeis menores, é natural supor que os detalhes foram adicionados. Afinal, mais foi escrito.

As condições de satisfação são simplesmente um teste de aceitação de alto nível que será verdadeiro após a conclusão da história ágil do usuário. Considere o seguinte como outro exemplo ágil da história do usuário:

Como vice-presidente de marketing, quero selecionar uma temporada de férias a ser usada ao revisar o desempenho de campanhas publicitárias anteriores, para que eu possa identificar as lucrativas.

Detalhes podem ser adicionados a esse exemplo de história do usuário adicionando as seguintes condições de satisfação:

  • Certifique-se de que funcione com as principais férias de varejo: Natal, Páscoa, Dia do Presidente, Dia das Mães, Dia dos Pais, Dia do Trabalho, Dia de Ano Novo.
  • Suporte a feriados que abrangem dois anos civis ( nenhum intervalo três ).
  • As estações de férias podem ser definidas de um feriado para o próximo (, como Ação de Graças ao Natal ).
  • As estações de férias podem ser definidas para vários dias antes do feriado.

As user history substituem um documento de requisitos?

Projetos ágeis, especialmente os Scrum, use um backlog do produto, que é uma lista priorizada da funcionalidade a ser desenvolvida em um produto ou serviço. Embora produto itens de lista de pendências pode ser o que a equipe deseja, as histórias dos usuários surgiram como a melhor e mais popular forma de itens de lista de pendências de produtos.

Enquanto um atraso do produto pode ser considerado um substituto para o documento de requisitos de um projeto tradicional, é importante lembrar que a parte escrita de uma história de usuário ágil ( “ Como usuário, Eu quero … ” ) está incompleto até que as discussões sobre essa história ocorram.

Muitas vezes, é melhor pensar na parte escrita como um ponteiro para o requisito real. As histórias do usuário podem apontar para um diagrama que descreve um fluxo de trabalho, uma planilha mostrando como executar um cálculo ou qualquer outro artefato que o proprietário ou a equipe do produto deseje.

Vantagens do “ Como, quero, para, ”

“Como um , Eu quero,  Para que que .” Embora eu considere a cláusula opcional, eu realmente gosto desse modelo. Em uma conferência, alguém me perguntou o porquê. Como recebo essa pergunta com bastante frequência, quero dar três razões pelas quais aqui:

Razão 1

Algo significativo e estou tentado a dizer que mágico acontece quando os requisitos são colocados na primeira pessoa. Obviamente, dizendo “Como tal e tal, eu quero …”, você pode ver como a mente da pessoa se move instantaneamente para imaginar que ela é uma pessoa assim. Quanto à mágica, Paul McCartney foi entrevistado e perguntado sobre por que as músicas dos Beatles eram tão incrivelmente populares. Uma de suas respostas foi que suas músicas foram as primeiras a usar muitos pronomes.

She Loves You, I Wanna Hold Your Hand, I Saw Her Standing There, I Am The Walrus, Baby You Can Drive My Car, etc. Seu argumento era que isso ajudava as pessoas a se identificarem mais de perto com as músicas.

Você pode ler mais sobre o Uso de pronomes pelos Beatles neste artigo.

Razão 2

Ter uma estrutura nas histórias realmente ajuda o proprietário do produto a priorizar. Se o backlog do produto for uma mistura de coisas como:

  • Entrega de exceção fixa
  • Deixe os usuários fazerem reservas
  • Os usuários querem ver fotos
  • Mostrar opções de tamanho do quarto

… e assim por diante, o proprietário do produto precisa trabalhar mais para entender qual é o recurso, quem se beneficia e qual é o valor dele.

Razão 3

Ouvi um argumento de que escrever histórias com esse modelo suprime o conteúdo informativo da história, porque há muito texto comum. Se você achar isso verdade, corrija-o na maneira como apresenta a história. Vi atrasos no Word que apresentam o texto comum em texto acinzentado com as partes exclusivas em preto.

Criei backlogs de produtos no Excel que usam títulos de colunas para filtrar o texto comum.

Olhe aqui e verá o que quero dizer:

COMO / UM EU QUERO… PARA QUE ENTÃO…
moderador criar um novo jogo digitando um nome e uma descrição opcional Posso começar a convidar jogadores
moderador convidar os jogadores, dando-lhes um URL onde eles possam acessar o jogo podemos começar o jogo
jogador participar de um jogo digitando meu nome na página em que recebi o URL Eu possa participar
moderador iniciar uma rodada inserindo um item em um único campo de texto com várias linhas podermos estimar
jogador ver o item que estamos estimando eu dê minha estimativa para o item
jogador ver todos os itens que tentaremos estimar nesta sessão coletar o tamanho dos vários itens
moderador ver todos os itens que tentamos estimar nesta sessão Eu possa responder perguntas sobre a história atual, como “isso inclui _____”
moderador selecionar um item a ser estimado ou reestimado a equipe veja esse item e poder estimá-lo

Sério, dê uma olhada na tabela acima antes de continuar … Eu vou esperar … Por favor, olhe para ela antes de ler mais.

OK, aqui está como eu aposto que você leu a planilha

Aposto que, ao ler a maioria das linhas que você adicionou no texto “Como um …”, “Eu quero …” e “para que então…”, possivelmente até olhando para o cabeçalho enquanto você lê em cada linha. Eu experimentei perguntando às pessoas, e é isso que a maioria das pessoas faz.

Se esse texto é desnecessário, por que mentalmente expressamos as palavras para nós mesmos ou até olhamos para o cabeçalho enquanto lemos a linha? Talvez não seja tão não essencial, afinal.

Por enquanto, e provavelmente por muito tempo, continuarei com o modelo “Como um …”, “Eu quero …” e “para que então…” por esses e outros motivos.

Por que o modelo de história de usuário de três partes funciona tão bem

Não há modelo mágico que deva ser usado para histórias de usuários. Eles podem ser escritos de várias maneiras. Mas a maneira mais popular de escrever histórias de usuários é com este modelo:

Como um tipo de usuário < >,
quero < algum objetivo >
para que < seja um motivo >.

Esse modelo se originou com a treinadora ágil Rachel Davies em uma empresa inglesa, Connextra, no início dos anos 2000. Desde então, tornou-se um padrão reconhecido para expressar histórias de usuários.

Os três elementos do modelo padrão

Descrevi as três partes do modelo padrão de várias maneiras ao longo dos anos. No Livro Histórias de usuários aplicadas de Mike Cohn1, ele descreve os três elementos desta maneira:

  • Como um papel ( ), quero uma função ( ) para que ( valor comercial ).

Mais tarde, ele mudou para que ao se referir aos três elementos como papel, objetivo e razão. Por fim, decidiu apenas se referir a eles de maneira muito mais simples como quem, o quê e por quê. Os três elementos do endereço do modelo de história do usuário padrão:

  • Quem quer a funcionalidade
  • O que eles querem
  • Por que eles querem

Vejamos cada uma dessas partes do modelo de história do usuário.

Quem: o primeiro elemento do modelo de história do usuário

Os usuários de um produto ou sistema típico geralmente podem ser categorizados. Como exemplo, estou digitando isso no Google Docs agora. Eu poderia ser considerado um usuário casual de Docs.

Não uso a maioria de seus recursos. Nunca cliquei no menu Complementos para ver o que há lá. Não faço muita formatação sofisticada porque a maior parte do que escrevo é movida para o meu site e é formatada lá. Então, vamos me chamar de Usuário casual.

Outros que usam esses recursos podem ser chamados Usuários de energia.

Normalmente, envio meus rascunhos de blog para um editor. E assim, Editor poderia ser outra função ao identificar os vários tipos diferentes de usuários do Google Docs.

Essas funções de usuário formam a primeira parte do modelo padrão de história do usuário. Portanto, alguém que desenvolve um processador de texto pode ter uma história de usuário de “ Como um usuário de energia, Eu quero um corretor ortográfico … ”

O que: o segundo elemento do modelo de história do usuário

A segunda parte do modelo padrão indica o que é desejado ou necessário. Isso é comumente declarado como “ eu quero …. ” De fato, durante anos minhas apresentações em conferências e outros treinamentos sobre histórias de usuários tiveram um slide dizendo “ Eu quero … ”

Acabei percebendo que isso era impreciso. Às vezes, a funcionalidade descrita não é algo que a função do usuário deseja. Por exemplo:

  • Como membro, sou obrigado a inserir uma senha forte….

Nenhum usuário ( normal ) quer para inserir uma senha com muitos caracteres, três símbolos especiais, sem caracteres repetidos e pelo menos algumas letras maiúsculas. Na melhor das hipóteses, entendemos por que é necessário, mas pessoalmente prefiro que o sistema saiba magicamente que sou eu e deixe-me entrar.

Então, hoje em dia eu não incluo mais quer ao mostrar o modelo em cursos ou apresentações. Em vez de sempre ser eu quer, às vezes sou eu necessário, forçado, precisa ou mais.

Por que: o terceiro elemento do modelo de história do usuário

A parte final do modelo padrão é porque o usuário deseja que a funcionalidade seja descrita na história do usuário. Isso é fornecido após o para que parte do modelo. Por exemplo, uma versão totalmente expressa da história anterior do verificador ortográfico pode ser “ Como usuário de energia, quero um verificador ortográfico para não precisar me preocupar com erros ortográficos. ”

para que a cláusula de uma história é importante porque entender por que um usuário deseja o que é descrito no o que parte da história ajuda a equipe a decidir qual a melhor forma de implementar a funcionalidade.

Como exemplo, não procure mais do que a nossa história de corretor ortográfico. Suponha que tenha sido fornecido a uma equipe sem uma cláusula simples: Como usuário de energia, quero um corretor ortográfico. Isso provavelmente levaria uma equipe a desenvolver o que eram todos os verificadores ortográficos iniciais: As ferramentas posteriores são executadas em um documento após a escrita.

Mas nosso usuário de energia não deseja um passo extra depois de terminar de escrever um documento. Em vez disso, o usuário de energia quer o que parece mais padrão hoje: correção em tempo real dos erros à medida que são cometidos. O que o usuário realmente deseja é dado pela cláusula: o usuário não quer se preocupar com erros de ortografia.

A cláusula ‘para que’ deve ser opcional?

Quando apresento histórias de usuários durante cursos presenciais, Muitas vezes me pedem para justificar minha visão aparentemente contraditória de que a cláusula é a parte mais importante de uma história, mas não deve ser obrigatória.

Não considero obrigatório porque, às vezes, simplesmente não agrega valor. Considere uma história sobre o login: Como membro, sou obrigado a fazer login.

Que cláusula você pode adicionar a essa história que agrega valor ou esclarece a intenção da história? Alguma dessas coisas realmente ajuda ou são apenas texto supérfluo adicionado para cumprir um modelo:

  • Como membro, sou obrigado a fazer login para que somente eu possa acessar meus dados pessoais.
  • Como membro, sou obrigado a fazer login para que outras pessoas não possam acessar meus dados pessoais, a menos que eu tenha fornecido minhas credenciais.
  • Como membro, sou obrigado a fazer login para que o sistema saiba que sou eu.
  • Como membro, sou obrigado a fazer login para que os hackers sejam mantidos de fora.

Enquanto eu não considero o para que cláusula obrigatória, eu escrevo quase o tempo todo. Revisei um atraso recente que escrevi e 62 de 64 histórias ( 97% ) tiveram cláusulas para que. Um pequeno número de ocasiões me impede de considerá-lo obrigatório.

Pontos fortes do modelo de história de usuário de três partes

Então, o que há de tão bom nesse modelo que ele resistiu ao teste do tempo? Afinal, uma prática introduzida no início dos anos 2000 e crescendo em aceitação tantos anos depois deve ter algo a seu favor. Eu acho que existem quatro pontos fortes principais no modelo.

Abrange três dos cinco Ws

Comecei a universidade como especialista em jornalismo. Acho que romantizei filmes cheios de repórteres de jornais que mastigam charutos e filmes como Ás no buraco, cidadão Kane, aconteceu uma noite, Todos os homens do presidente. Os jornalistas são treinados para que qualquer artigo de jornal precise responder cinco perguntas que começam com um W:

  • Quem? (Who?)
  • O que? (What?)
  • Quando? (When?)
  • Onde? (Where?)
  • Por quê? (Why?)

As histórias dos usuários abordam três dos cinco – Quem, O quê e Por quê. Ao discutir os requisitos do produto ou sistema, parece razoável deixar Quando e Onde, pois as respostas geralmente seriam “ agora ” e “ no produto. ”

Os elementos são apresentados na ordem certa

Eu acho que os elementos – quem, o quê e por quê – são apresentados na ordem certa. Pense em qualquer história – não em uma história de usuário, mas em um filme, um romance ou uma anedota ou piada que você deseja contar a um amigo. A coisa mais importante nessa história é quase sempre quem está fazendo isso. Chamamos essa pessoa de protagonista.

Quando assistimos a um filme, precisamos nos preocupar com o protagonista antes de nos preocuparmos com a trama. Eu não me importo de um jeito ou de outro com a Estrela da Morte sendo explodida até me ver um pouco em Luke, Han ou Leia e posso relacionar para eles.

Só depois que eu sei quem, eu me preocupo com o que e porque. O modelo padrão de história do usuário os coloca nessa ordem.

A história é contada a partir de uma perspectiva de primeira pessoa

Nós gostamos de histórias sobre nós mesmos. ( Bem, a menos que sejamos adolescentes e nossos pais estejam contando histórias sobre as coisas não tão fofas que fizemos quando éramos bebês. ) A próxima melhor coisa para uma história sobre mim é uma história sobre você.

O menos interessante é uma história sobre o cara do outro lado da cidade que eu nunca conheci.

Histórias sobre eu e você e nós e ela e ele são interessantes.

Os Beatles sabiam disso. Eles deliberadamente colocaram o maior número possível de pronomes pessoais em seus títulos de músicas. E se eles não conseguissem encaixar um pronome pessoal no título da música, colocariam o máximo que pudessem nas letras da música.

O primeiro álbum britânico dos Beatles ’ teve pronomes em 8 dos 14 títulos de músicas ( 57% ). Nos 19 minutos e 30 segundos dessas oito músicas, os Beatles usavam 325 pronomes pessoais, um pronome a cada 3,6 segundos.

Isso funcionou tão bem que seu segundo álbum teve pronomes em 64% dos títulos. Os Beatles então aumentaram para 79% em seu terceiro álbum.

Em entrevista à revista Billboard, o Beatle Paul McCartney disse que isso era muito deliberado: “ Todas as nossas primeiras músicas continham ‘eu’ ou ‘você.’ Fomos completamente diretos e sem vergonha para os fãs: Me ame, por favor, por favor, eu quero segurar sua mão.

O modelo padrão de história do usuário começa com eu, o mais pessoal dos pronomes pessoais. Não tenho base para essa afirmação – não sou neurologista -, mas juro que algo acontece quando temos uma história de usuário que começa com eu.

Nos relacionamos com essa história mais de perto do que se o mesmo fosse escrito como um tradicional O sistema deve… declaração.

Paul McCartney e John Lennon sabiam disso e o usavam para impulsionar suas carreiras. As equipes ágeis fazem o mesmo ao usar o modelo de história de usuário em três partes.

Nossas partes interessadas são imediatamente confortáveis preenchendo

Os espaços em branco Antes das histórias dos usuários aparecerem, adorei usar casos. Ou tentei amar casos de uso. Eu realmente os amava. Mas nunca consegui convencer as partes interessadas com quem trabalhei para amá-las tanto quanto eu.

Eles estavam muito longe de como as partes interessadas pensavam sobre seu trabalho. As partes interessadas não pensam em atores secundários, pré-condições ou pós condições. E assim, os casos de uso nunca funcionaram tão bem na prática quanto eu pensava que deveriam.

Eu nunca tive esse problema com histórias de usuários. Posso realizar um workshop de redação de histórias com as partes interessadas simplesmente escrevendo Como um _____, Eu ______ para que _______ em um quadro branco e dizendo a eles que nos reunimos para preencher os espaços em branco o máximo que pudermos.

As partes interessadas entendem. É uma maneira natural de falar por eles.

Outros modelos para expressar histórias foram propostos, e alguns têm vantagens, mas a maioria são maneiras menos naturais de falar. Por exemplo, o desenvolvimento orientado a comportamentos é uma ótima maneira de expressar testes ou especificar por exemplo. Martin Fowler descreve sua sintaxe dada quando e depois como “ um estilo de representação de testes. ” E é fantástico para escrever especificações de teste mas não é tão bom para se comunicar com os clientes.

Em parte, isso ocorre porque seu modelo é menos natural. Falo desde os 2 ou 3 anos. Não sei se já iniciei uma frase com dado. Definitivamente nunca usei dado, quando e então nessa ordem em uma frase. Eu disse sem conta “ eu quero isto de modo que aquilo.”

Desvantagens do modelo de user story de três partes

Há duas desvantagens no modelo padrão de história do usuário que merecem destaque.

Muitas histórias são escritas apenas como “ Como usuário … ”

Com demasiada frequência, os membros da equipe têm o hábito de iniciar cada história de usuário com “ Como usuário…” Às vezes, esse é o resultado de um pensamento preguiçoso e os escritores de histórias precisam entender melhor os usuários do produto antes de escrever tantas histórias “ como usuário … ”.

Mas outras vezes, pode indicar um sistema não adequado para histórias de usuários. Isso acontece porque muitas pessoas associam ser ágil com a escrita de histórias de usuários. Para ser ágil, eles raciocinam, você precisa escrever histórias de usuários, mesmo quando não há usuários.

Eu trabalhei em um sistema de rastreamento de conformidade financeira. A grande maioria do que o sistema fez nunca seria vista ou relatada. Se um problema de conformidade fosse descoberto, no entanto, os relatórios seriam gerados e os indivíduos seriam notificados. Esse sistema se beneficiou de histórias de usuários para esse pequeno subconjunto da funcionalidade geral do produto. Mas as histórias dos usuários eram inadequadas para o resto do sistema.

Em casos como esses, as equipes precisam usar maneiras alternativas de expressar o que o produto precisa fazer. A sintaxe usada por histórias de trabalho ou desenvolvimento orientado a recursos recursos podem ser melhores escolhas.

O modelo é muito frequentemente seguido de maneira eslava

Por todos os meios, o senso comum precisa ser um princípio norteador para equipes ágeis. Ao expressar algo no modelo de história do usuário padrão, não faz sentido, não use esse modelo. Escreva de outra maneira, incluindo muito possivelmente apenas texto de forma livre.

Hoje cedo, escrevi um item de lista de pendências do produto “ Altere como os lembretes de reprodução de webinar são enviados no último dia da maneira como discutimos na ligação de sexta-feira. ”

Como um item de lista de pendências do produto, isso é péssimo. Não é uma história de usuário. Não é BDD ou mesmo uma história de trabalho. É horrível. E se não for corrigido em breve, ninguém se lembrará do bug que foi discutido em uma ligação esquecida.

Mas eu sabia que a equipe iria consertar isso em breve e, portanto, o que escrevi foi bom o suficiente. A última coisa que eu preciso seria de um Scrum Master insistindo em escrevê-lo para seguir um modelo criado na virada do milênio, não importa o quão bem esse modelo funcione para a maioria dos itens de lista de pendências do produto.

Vantagens das histórias de usuários sobre requisitos e casos de uso

A programação extrema ( XP ) introduziu a prática de expressar requisitos na forma de histórias de usuários. A história do usuário é uma breve descrição da funcionalidade – contada da perspectiva de um usuário – que é valiosa para um usuário do software ou para o cliente do software, e normalmente assume a forma de um Modelo de 3 partes.

caso de uso, por outro lado, é uma descrição generalizada de um conjunto de interações entre o sistema e um ou mais atores, onde um ator é um usuário ou outro sistema. Os casos de uso podem ser escritos em texto não estruturado ou em conformidade com um modelo estruturado.

Requisitos são tipicamente uma lista de instruções “ O sistema deve … ”, como:

  • O sistema deve permitir que uma empresa pague por um anúncio de emprego com cartão de crédito.
  • O sistema deve aceitar cartões Visa, MasterCard e American Express.
  • O sistema cobrará o cartão de crédito antes que o anúncio de emprego seja colocado no site.
  • O sistema deve fornecer ao usuário um número de confirmação exclusivo.

Histórias de usuários normalmente (mas nem sempre e não em todos os casos) são a melhor escolha para equipes que usam Scrum porque oferecem várias vantagens em casos de uso, requisitos e outras opções.

Benefícios das histórias de usuários

As histórias de usuários exibem algumas das mesmas características dos casos de uso ou declarações de requisitos tradicionais, mas são as maneiras pelas quais elas são diferentes que dão tantas vantagens às histórias de usuários.

User Story Benefício 1: Exigem conversas

Talvez o benefício mais importante das histórias dos usuários no desenvolvimento ágil de produtos seja que, diferentemente dos requisitos ou casos de uso, as histórias dos usuários não devem se sustentar por si mesmas.

Em vez disso, cada história de usuário é um espaço reservado para uma conversa futura com a equipe de desenvolvimento.

O texto de alto nível armazenado em um cartão de índice, problema de Jira, célula de planilha ou nota adesiva pode ser a manifestação mais visível de uma história de usuário, mas não é a mais importante.

A parte mais importante de qualquer história de usuário é que um entendimento compartilhado do que é necessário é elaborado em uma conversa futura.

User Story Benefício 2: São verbais, muito mais precisas

As histórias dos usuários enfatizam a comunicação verbal, para que sejam mais precisas. O idioma escrito geralmente é muito impreciso e não há garantia de que um cliente e desenvolvedor interpretem uma declaração da mesma maneira.

Agimos como se as palavras escritas fossem precisas, mas geralmente não são. Por exemplo, no almoço recentemente, li isso no meu menu: “ Entrada: vem com uma escolha de sopa ou salada e pão. ”

Essa não deveria ter sido uma frase difícil de entender, mas foi. Qual deles você escolhe?

  • Sopa ou ( salada e pão )
  • ( Sopa ou salada ) e pão

Compare as palavras escritas nesse menu com a garçonete ’ palavras faladas: “ Você gostaria de sopa ou salada? ” Melhor ainda, ela removeu toda a ambiguidade colocando uma cesta de pão na mesa antes de fazer meu pedido.

User Story Benefício 3: Têm estimativas e priorização fáceis

Uma terceira vantagem de escrever histórias de usuários é que elas recebem estimativas que tornam a priorização e o planejamento mais tranquilos. Cada história de usuário pode receber uma estimativa do esforço necessário para desenvolvê-lo; os casos de uso, por outro lado, são geralmente grandes demais para receber estimativas úteis.

Da mesma forma, quando você considera as milhares ou dezenas de milhares de instruções em uma especificação de requisitos de software ( e os relacionamentos entre elas ) para um produto típico, é fácil ver a dificuldade inerente em priorizá-los.

Se os requisitos não puderem ser priorizados além do alto, médio e baixo comuns, eles não serão adequados para um processo de desenvolvimento altamente iterativo e incremental que fornecerá software de trabalho a cada duas a quatro semanas.

User Story Benefício 4: Incentive as equipes a adiar detalhes

Uma quarta vantagem é que as histórias dos usuários incentivam a equipe a adiar detalhes da coleta.

Uma história inicial  épica – de nível ( “ Um recrutador pode postar uma nova vaga ” ) pode ser escrita, estimada e colocada no backlog do produto. Mais tarde, ele pode ser substituído por várias histórias menores, mais detalhadas, com DoR, DoD e Critérios de aceitação que é quando se torna importante ter esses detalhes.

Essa técnica torna as histórias dos usuários perfeitas para projetos com restrição de tempo – Uma equipe pode escrever rapidamente algumas dezenas de histórias de usuários para dar uma sensação geral pelo sistema. Eles podem mergulhar nos detalhes de algumas histórias e começar a codificar muito mais cedo do que uma equipe que se sente compelida a concluir uma especificação de requisitos funcionais.

User Story Benefício 5:  Oferecer um entendimento geral do produto

A quinta vantagem é um pouco mais sutil. As listas de requisitos que um analista de negócios pode apresentar não dão ao leitor o mesmo entendimento geral de um produto que as histórias de usuários fazem.

É muito difícil ler uma lista de requisitos sem considerar automaticamente as soluções em sua cabeça enquanto você lê.

Por exemplo, considere os seguintes requisitos, adaptados dos de Alan Cooper2 The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity 1ª Edição.

  • O produto deve ter um motor a gasolina.
  • O produto deve ter quatro rodas.
  • O produto deve ter um pneu de borracha montado em cada roda.
  • O produto deve ter um volante.
  • O produto deve ter uma carroceria de aço.

A essa altura, suponho que imagens de um automóvel estejam flutuando em torno de sua cabeça. Obviamente, um automóvel atende a todos os requisitos listados acima. O da sua cabeça pode ser um conversível vermelho brilhante, enquanto eu posso imaginar uma picape azul. Presumivelmente, as diferenças entre o seu conversível e a minha picape são cobertas por declarações de requisitos adicionais.

Mas suponha que, em vez de escrever uma especificação de requisitos de estilo IEEE 830 –, as histórias foram escritas da perspectiva do usuário.

  • Como proprietário de casa, quero algo que facilite e agilize a cortar a grama.
  • Como proprietário de casa, quero uma maneira de cortar a grama, onde possa me sentar, em vez de me levantar.

Ao olhar para as metas, temos uma visão completamente diferente do produto: o cliente realmente quer um cortador de grama, não um automóvel!

Histórias descrevem os objetivos de um usuário. Ao focar nos objetivos do usuário para o novo produto, em vez de uma lista de atributos do novo produto, podemos criar uma solução melhor para as necessidades do usuário.

User Story Benefício 6: Sugerem um custo

Um benefício final das histórias do usuário sobre as especificações de requisitos é que o custo de cada requisito não seja visível até que todos os requisitos sejam escritos.

O cenário típico é que um ou mais analistas passam dois ou três meses ( geralmente mais ) escrevendo um documento de requisitos demorado. Este documento é entregue aos programadores, que informam aos analistas ( que transmitem a mensagem ao cliente ) que o projeto levará 24 meses, em vez dos seis meses que eles esperavam.

Nesse caso, perdeu-se tempo escrevendo os três quartos do documento que a equipe não terá tempo para desenvolver e mais tempo será desperdiçado como desenvolvedores, analistas, e iterar o cliente sobre qual funcionalidade pode ser desenvolvida a tempo.

Na boa prática de histórias de usuários, um estimativa está associada a cada história. O cliente / proprietário do produto conhece a velocidade da equipe e o custo relativo de cada história, e pode decidir rapidamente se o produto que eles desejam pode ser entregue no tempo que eles tiverem.

Kent Beck me disse uma vez que essa diferença era como se registrar para presentes de casamento. Quando você se registra, não vê o custo de cada item. Você apenas faz uma lista de desejos de tudo o que deseja.

As listas de desejos cegas podem funcionar para casamentos, mas não funcionam para o desenvolvimento de produtos. Quando um cliente, proprietário do produto ou parte interessada coloca um item em sua lista de desejos do projeto, ele precisa saber seu custo.

Requisitos não funcionais como histórias de usuários

Um desafio comum com a escrita histórias de usuários é como lidar com os requisitos não funcionais de um produto. Esses são requisitos que não tratam de funcionalidade específica ( “Como usuário de um processador de texto, quero inserir uma tabela no meu documento”. ), mas são mais sobre um atributo ou característica do sistema.

Os exemplos incluem confiabilidade, disponibilidade, portabilidade, escalabilidade, usabilidade, manutenção.

Como você pode ver nessa lista de exemplos, os requisitos não funcionais são frequentemente referidos como “-ilidade.” Obviamente, nem todos os requisitos não funcionais terminam em “-ilidade.” Também temos segurança, desempenho, robustez e assim por diante.

Pensando na idade das trevas, lembro-me de quando li pela primeira vez sobre “requisitos não funcionais.” O termo me deu um nó. Se não é funcional, por que me preocupo com isso? Tenho certeza de que o autor desse livro esclareceu isso para mim uma página mais tarde, mas o termo sempre me pareceu estranho.

Prefiro pensar em requisitos não funcionais como “restrições” que colocamos no sistema.

Quando o proprietário do produto diz: “este sistema deve ter um desempenho adequado com 100.000 usuários simultâneos”, o proprietário do produto está colocando uma restrição no equipe.

O proprietário do produto está efetivamente dizendo: “Desenvolva este software da maneira que desejar, desde que alcance 100.000 usuários simultâneos.”

Cada restrição que colocamos em um sistema restringe um pouco as opções de design; chamar essas “restrições” em vez de “requisitos não funcionais” nos ajuda a lembrar disso. Felizmente, restrições / requisitos não funcionais podem ser facilmente expressos como histórias de usuários:

  • Como cliente, quero poder executar seu produto em todas as versões do Windows a partir do Windows 95.
  • Como CTO, quero que o sistema use nosso banco de dados de pedidos existente em vez de criar um novo, para que não tenhamos mais um banco de dados para manter.
  • Como usuário, quero que o site esteja disponível 99.999% do tempo em que tento acessá-lo, para não ficar frustrado e encontrar outro site para usar.
  • Como alguém que fala um idioma latino, talvez eu queira executar seu software algum dia.
  • Como usuário, quero que as instruções de direção sejam os melhores 90% do tempo e razoáveis 99% do tempo.

Como você pode ver nesses exemplos de histórias de usuários, eu pude facilmente ficar com o “Como um , Eu quero , de modo que ” modelo de história do usuário, que eu prefiro para a maioria das histórias de usuários. Faço isso por algumas razões, mas quero comentar mais sobre apenas uma delas aqui.

Considere o exemplo do CTO que restringe a equipe a usar o banco de dados de pedidos existente. ( Esta era a situação real; a equipe estava considerando um banco de dados de segundos pedidos que seria sincronizado à noite. O CTO ouviu isso e disse: “Não!” )

Se escrevêssemos esse requisito da mesma forma: “Deve usar o banco de dados de pedidos existente,” seria inteiramente possível que, alguns meses depois, não nos lembrássemos por que deveríamos ser restringidos dessa maneira. Perguntaríamos ao proprietário do produto se ela se importava se usássemos um banco de dados secundário e ela diria que não tinha objeções. E cometeríamos um erro de usar um.

Incorporar a pessoa que quer algo pode ser muito útil. Mas, tome cuidado para não ficar obcecado com esse modelo. É apenas uma ferramenta de pensamento.

Tentar colocar uma restrição no modelo de história de usuário em três partes é um bom exercício, pois ajuda a entender quem quer o quê e por quê. Se você terminar com uma instrução confusa, largue o modelo. Você pode achar que o modelo de história de trabalho funciona melhor para o seu contexto. Ou você pode achar que os modelos não funcionam. Se você não conseguir encontrar uma maneira de expressar a restrição, basta escrever a restrição da maneira que parecer natural.

Product Backlog, tudo o que você precisa saber

Para ter ideia de tudo que você precisa saber sobre Product Backlog neste artigo, vamos contextualizar e balizar nossos conhecimentos um pouco.

O que é um Product Backlog? Definição

Uma das características importantes do Scrum é que há um, e apenas um, backlog de trabalho aguardando para ser priorizado, desenvolvido e concluído.

Um Backlog é uma lista de requisitos e requisitos de negócios que ainda não foram implementados. Um Backlog ajuda a entender melhor o produto, além de garantir que cada recurso necessário seja listado.

No desenvolvimento de software, um Product Backlog é uma lista abrangente de tudo o que pode ser necessário no produto. Ele inclui todos os recursos que serão implementados, bem como todos os bugs e problemas que devem ser corrigidos.

Um Product Backlog eficaz ajuda o gerenciamento de produtos e a equipe de desenvolvimento a priorizar tarefas e colaborar.

O objetivo de usar um backlog de produto é garantir que os recursos desenvolvidos sejam priorizados em termos de tempo e importância de valor para o usuário final.

Quem é responsável pelo Product Backlog?

O Product Owner é o responsável e mantenedor do backlog do produto. Além disso, é responsabilidade do Product Owner entender, avaliar e selecionar os itens de backlog individuais que serão adicionados a um sprint ou release atual.

É o PO que  deve receber informações de todas as partes interessadas, incluindo clientes, membros da equipe, executivos, tendências atuais e outras funções internas, mas, em última análise, ele é o tomador de decisão final.

O Product Owner é a pessoa que determina o trabalho que será realizado em cada iteração . O trabalho real atribuído à iteração requer um diálogo colaborativo entre o Product Owner e a equipe ágil.

O PO geralmente pede que a equipe assuma mais trabalho, e a equipe do projeto – deve se comprometer apenas com o nível de trabalho que pode ser totalmente concluído durante a iteração. Em última análise, a equipe Agile é responsável por decidir sobre o trabalho exato que compõe a iteração.

O que é Sprint Backlog? E como ele é planejado?

Em um projeto ágil, a carga de trabalho é determinada no início de cada iteração (sprint). O Product Owner avalia e prioriza o trabalho que precisa ser feito, enquanto a equipe determina a quantidade de trabalho que pode ser concluída e a meta da sprint.

A reunião de planejamento de iteração (Sprint Planning) define o cenário e deve ser executada como um diálogo colaborativo,.

Um dos aspectos exclusivos de um projeto Agile é que a carga de trabalho é determinada no início de cada iteração. Ao contrário dos projetos tradicionais, a carga de trabalho não é definida com meses e meses de antecedência.

Há apenas a necessidade de um planejamento detalhado para a próxima iteração. (O  Product backlog pode ser mapeado em alto nível para iterações futuras, mas o planejamento detalhado ocorre uma iteração por vez.) Isso permite que um projeto ágil seja flexível em sua carga de trabalho e sensível às mudanças nas necessidades e prioridades do cliente.

No início de cada iteração, o Product Owner e a equipe do projeto se reúnem para determinar a carga de trabalho para essa iteração. Durante a reunião, o Product Owner avalia o backlog do produto e simplesmente extrai o próximo conjunto de histórias de usuário que são de maior prioridade.

Esse nível de esforço para concluir a história do usuário pode já ter sido estimado quando a história foi adicionada. Caso contrário, a equipe estima o trabalho na reunião de planejamento.

Essa estimativa pode assumir a forma de horas de esforço real, mas é mais provável que a estimativa seja baseada em “pontos da história” – vamos falar sobre eles depois – A estimativa inclui o trabalho necessário para implementar totalmente a história do usuário, incluindo a análise, design, construção, teste e integração.

Essa separação de histórias, para um pedaço do projeto é chamado de Sprint Backlog.

Legal! até aqui você já entendeu que o Product Backlog (backlog do produto) é a lista de tudo que consta dentro de um produto com os desejos e regras de negócios, enquanto o Sprint Backlog é uma lista priorizada que vai ser executada já na próxima iteração.

Documentação de projeto e o Product Backlog

Em um projeto ágil, você não cria documentos grandes para atender aos requisitos do usuário; na verdade, você não precisa de um documento tradicional. A técnica preferida é usar um backlog do produto, que representa uma coleção priorizada de trabalho restante no projeto em um determinado momento.

Em um projeto Agile, você não cria documentos grandes para atender aos requisitos do usuário. Na verdade, você não precisa de um documento tradicional. A técnica preferida é criar um backlog do produto.

O backlog não é um documento tanto quanto é simplesmente a coleção priorizada de trabalho que permanece em um projeto. Pode ser uma planilha ou tabela que contém uma lista de histórias de usuários. Também pode ser uma pilha de cartões de índice, cada um contendo uma história de usuário ou um item exclusivo de trabalho.

O backlog inicial do produto é gerado no início de um projeto Agile. O tempo pode coincidir com uma fase de iniciação do projeto ou durante uma iteração inicial de configuração (às vezes chamada de iteração 0). O backlog inicial do produto consiste em todo o trabalho facilmente identificado que é conhecido quando o projeto é iniciado.

À medida que cada iteração começa, uma reunião de planejamento é realizada entre o proprietário do produto e a equipe do projeto. O proprietário do produto identifica o trabalho no backlog do produto que ele gostaria que fosse concluído na iteração.

A equipe do projeto valida que pode concluir o trabalho. As negociações são realizadas se houver uma diferença de opinião sobre o trabalho que pode ser concluído durante a iteração. O trabalho mutuamente acordado é então retirado do backlog do produto e implementado durante a iteração.

O que mais existe no backlog do produto?

O backlog do produto representa a totalidade do trabalho restante no projeto em um determinado momento. A maior parte do backlog consiste em histórias de usuários que implementam funcionalidades de benefício para o usuário. No entanto, outros trabalhos também estarão na lista de pendências. Isso inclui.

Entregas do usuário Nem todos os itens do backlog do produto requerem codificação de software. Por exemplo, o proprietário do produto pode querer um Manual do Usuário, conteúdo de treinamento, perguntas frequentes etc. Se as entregas devem ser criadas pela equipe do projeto, o trabalho precisa ser priorizado e incluído na iteração apropriada.

Entregas de TI Essas são entregas exigidas pela organização de TI. Isso pode incluir um Manual de Recuperação de Desastres, documento de retenção de registros, documentação de controle de alterações, etc. Alguns deles podem ter valor para o usuário, mas às vezes são necessários para a organização de TI.

Defeitos e correções de bugs Se erros críticos e bugs surgirem durante uma iteração, eles precisam ser resolvidos para que o código do produto seja viável no final de uma iteração. No entanto, muitos bugs se enquadram na categoria de incômodos.

Eles precisam ser corrigidos, mas há discrição quanto ao momento das correções. Esses tipos de correções podem ser colocados no backlog e priorizados em uma iteração subsequente. Em alguns casos, a equipe espera até o final do projeto para uma limpeza final de bugs e erros.

Como são escritas as histórias no backlog?

As histórias de usuários são escritas de forma vaga e não contêm necessariamente muitos detalhes. As histórias devem conter detalhes suficientes para que tanto o cliente quanto a equipe do projeto se lembrem a que a história se refere.

A história também pode incluir outras informações, como uma estimativa do trabalho necessário para implementar a história. Quando a história é priorizada para uma iteração específica, deve haver informações suficientes para que o proprietário do produto e a equipe possam lembrar o contexto e possam trabalhar juntos para definir os requisitos detalhados.

Na iteração de configuração, o proprietário do produto cria quantas histórias de usuário ele conhece no momento. Não é necessário descobrir todas as histórias de uma só vez. As histórias podem ser adicionadas, modificadas e excluídas continuamente durante o projeto.

Em um projeto tradicional, as mudanças nas histórias de usuários seriam adicionadas usando o gerenciamento de mudanças de escopo. Em um projeto Agile, o proprietário do produto pode adicionar, alterar e remover quaisquer histórias.

O conceito de fluência de escopo não ocorre durante uma iteração. A quantidade de trabalho em uma iteração é fixada pela velocidade da equipe. Se o proprietário do produto continuar a adicionar novos itens à lista de pendências, pode ocorrer aumento de escopo exigindo iterações adicionais para implementar o trabalho em áreas que não faziam parte do escopo original do projeto.

Esse tipo de desvio de escopo deve ser controlado para garantir que o projeto Agile não se desvie.

Se o Product Owner é dono do Backlog, como fica o time?

Embora a equipe de desenvolvimento possa certamente expressar suas opiniões sobre o que deve ser trabalhado, eles não podem realmente agir de acordo com essas opiniões sem o consentimento do Product Owner.

Isso pode levar a uma sensação de “desempoderamento” por parte da equipe de desenvolvimento. Embora uma equipe de alto desempenho deva ser muito colaborativa e permitir que todas as vozes sejam ouvidas, a equipe pode sentir que as necessidades da tecnologia ou os sistemas não estão sendo suportados, ou talvez até valorizados.

Isso pode causar a sensação de “nós contra eles”, que é exatamente o cenário que Scrum e/ou  Agile deveriam evitar. Na verdade, algumas organizações tentam dividir o backlog entre “produto” e “tecnologia” e, às vezes, dão a cada um seu próprio Product Owner. Esta é a maneira errada de resolver este problema.

Dividir ou separar as pendências só causará confusão e interrupção, e não fornecerá transparência sobre o que está sendo trabalhado pela equipe.

O processo funciona melhor quando há um único backlog de trabalho priorizado contendo tudo o que deve ser desenvolvido e há uma maneira altamente visível (física ou eletrônica) para qualquer parte interessada ver o que está em andamento em uma iteração atual.

De qualquer forma, fazer qualquer outra coisa não é necessário – o Agile possui mecanismos para impedir que esse tipo de desempoderamento aconteça, embora o ônus seja da equipe de desenvolvimento para usá-los.

Usar esses mecanismos é a abordagem certa para manter a equipe se sentindo capacitada.

Itens chave para um bom backlog

Há seis itens chave para procurar em uma história de backlog saudável. Ao classificar cada história nessas facetas, você pode ter uma noção fácil de quão pronta a história está para ser escolhida e desenvolvida. Os seis são prioridade, requisitos, estimativas, dependências e definição de pronto e definição de feito.

O processo de refinamento do backlog e consequentemente dos requisitos até o ponto em que eles estejam prontos para serem trabalhados é conhecido como ‘limpeza do backlog’.

Mas essa tarefa realiza mais do que esclarecer requisitos; informa as partes interessadas, contribui para o plano do projeto e reforça os princípios ágeis em geral. Aqui está a orientação sobre como e quando isso deve ser feito.

Uma das inovações mais úteis da família de práticas Agile é o conceito de backlog do produto. No passado, o acúmulo de requisitos existia em um documento – geralmente chamado de Documento de Requisitos de Negócios (BRD – Bussiness Requirements Document) – que continha necessidades totalmente especificadas para o produto com base em qualquer informação que o proprietário da empresa tivesse na época.

O backlog, então, era o que estava no documento que ainda não estava concluído. Isso é realmente muito simples; se o documento contiver 50 itens e três deles estiverem completos, a lista de pendências consistirá em mais 47 itens. É melhor a equipe começar a trabalhar!.

Praticantes ágeis acreditam que duas coisas são verdadeiras: os produtos são melhores quando trabalhamos juntos e devemos abraçar a ideia de que os requisitos estão mudando o tempo todo.

O simples processo de passar semanas ou meses criando um documento enorme que é então entregue aos desenvolvedores não apenas viola os dois princípios, mas perde completamente o objetivo de como criar ótimos produtos. (além de que esse documento enorme acaba na gaveta).

Em vez de despender esforço criando um documento longo que é inferior (devido à falta de colaboração) e desatualizado (devido às necessidades de mudança do negócio), o Agile sugere a criação de algo chamado product backlog.

Esse backlog do produto é uma lista priorizada de requisitos, histórias de usuários, tarefas e atividades que a equipe do produto precisa realizar para levar o produto ao mercado.

Ele difere substancialmente do antigo BRD, pois a lista de requisitos teve diferentes níveis de energia colocados neles, e a lista é fixa e adaptável às necessidades do produto e da equipe do produto.

O processo de transformar esse backlog em algo excelente é chamado de Backlog Refinement (antigamente era grooming) e é um conceito fácil de ser mal interpretado ou usado indevidamente, tanto do ponto de vista do produto quanto do desenvolvedor.

Por que se preocupar com a limpeza no refinamento?

Existem duas dimensões que um backlog de produto Agile traz para o produto que o antigo BRD não trazia: prioridades e a capacidade de alterar ou inserir novos requisitos com o passar do tempo.

No entanto, há mais uma faceta oculta para trabalhar com um backlog priorizado: como algumas das histórias de usuários acabarão no final da lista, não há necessidade de gastar muito tempo com elas.

Acontece que é uma ideia melhor “deixar de lado” essas histórias e reorientar seu tempo nas histórias de usuários que estão no topo da pilha. Em vez de obter os requisitos “suficientemente bons” em geral, o proprietário do produto é responsável por obter os requisitos que estão no topo da pilha “prontos para a iniciar” – mesmo às custas das histórias na parte inferior da pilha.

Um backlog devidamente preparado é o ativo mais importante que uma equipe Agile pode ter. Para que seja o mais útil possível, deve ser capaz de fazer três coisas :

  1. Fornecer itens prontos para o trabalho para a equipe de desenvolvimento:
  2. Ser flexível e conter todas as informações disponíveis sobre o produto e
  3. Fornecer insights para todas as partes interessadas sobre o que está no pipeline a ser trabalhado.

O objetivo principal do backlog é dar trabalho à equipe de desenvolvimento que está pronta para começar. Isso significa que:

  • Ele está totalmente especificado,
  • Suas perguntas são respondidas,
  • O dimensionamento está completo e os critérios de sucesso registrados.

Um membro da equipe deve ser capaz de pegar um item da lista de pendências e começar a trabalhar imediatamente, não importa se é engenheiro de software, testador ou designer.

Isso realmente exige muito esforço do proprietário do produto e da equipe do produto – esforço que foi desviado dos itens na parte inferior do backlog.

Não há nada que um proprietário de produto possa fazer que afete mais a eficiência da equipe do que ter as próximas tarefas prontas para serem executadas.

Se um desenvolvedor de qualquer tipo tiver que passar por um intervalo de até meio dia enquanto espera para começar a trabalhar em algo, isso custará significativamente ao produto no final.

Enquanto isso, o backlog deve ser flexível, tanto em conteúdo quanto em prioridade. Quando o backlog inicial foi criado, ele foi feito com todas as informações, análises e inteligência que o product owner tinha.

Agora que a lista de pendências foi aberta para desenvolvedores, partes interessadas, clientes e outros proprietários de produtos, novas ideias surgirão e uma nova prioridade surgirá.

Por exemplo, trabalhei recentemente em um produto em que o proprietário do produto decidiu intencionalmente não priorizar uma parte inteira do aplicativo em favor de criar uma experiência mais rica nas outras partes.

O feedback foi instantâneo e intenso; sem a funcionalidade que faltava, o produto era inútil. Em vez de esperar um ano ou mais para recuperar essa funcionalidade, o proprietário do produto conseguiu colocar essas histórias de usuários de volta no topo da lista, prepará-las completamente, e levá-los para a próxima versão.

É assim que o Agile deve funcionar!

O backlog também deve ser usado como documentação externa. Todas as partes interessadas querem saber o que está por vir, quando seu caso de uso será criado e o que mais está na lista.

Um backlog devidamente preparado pode servir a essa função. Ao apontar as pessoas para a lista de pendências, elas podem ver o que está perto do topo, o que está na parte inferior e onde sua solicitação está em prioridade relativa.

Eles também podem ter informações ou feedback sobre as prioridades atuais, requisitos futuros ou podem até ter ideias brilhantes que não estão na lista.

Em suma, o backlog pode servir como documento de requisitos, plano de projeto e comunicação com as partes interessadas, tudo ao mesmo tempo. Mas só se for bem feito.

Itens de prioridade de um backlog antes do refinamento

Repare que existem seis itens que são prioridade num product backlog. Os seis são prioridade, requisitos, estimativas, dependências e definição de pronto e definição de feito.

Para criar um backlog saudável, ao classificar cada história em uma escala de zero a três, você obterá uma pontuação total entre zero e 18, permitindo que a equipe saiba, de relance, quais histórias estão em boa forma e quais não estão e, assim, quais a forma do backlog está no todo. Aqui está uma olhada em cada um dos fatores que compõem a “saúde da história”.

1. Prioridade.

Isso parece quase óbvio, pois as tarefas no topo do backlog são as de maior prioridade e as de baixo são as mais baixas. Isso não significa que a razão por trás da prioridade seja compreendida, o que é ainda mais importante.

A equipe de desenvolvimento geralmente prioriza mentalmente o trabalho com base em sua própria compreensão de por que algo é necessário. O papel do proprietário do produto é garantir que a equipe entenda o valor do trabalho; os desenvolvedores não precisam necessariamente concordar com ela, mas precisam entendê-la.

Desenvolvedores trabalhando em algo que não entendem é ruim para todos.

2. Requisitos.

Quase igualmente importante é a compreensão da obra em si, que, mais uma vez, parece óbvia. A parte difícil é que os requisitos nunca são completos; eles só são bons o suficiente por enquanto.

Mesmo depois que um recurso está disponível nas mãos do cliente, ainda há refinamentos, alterações e melhorias que podem ser feitas e provavelmente estão sendo constantemente adicionadas ao backlog.

No entanto, uma vez que uma história de usuário recebe um ou dois sprints de desenvolvimento, é hora de garantir que os requisitos sejam entendidos o suficiente para que um desenvolvedor possa pegá-lo e trabalhar nele.

Os requisitos não precisam ser definitivos – nunca são – mas precisam estar prontos.

3. Estimativas.

Uma parte da preparação do backlog é dimensionar as histórias, usando um mecanismo como pontos de história ou qualquer estratégia que a equipe se sinta confortável em usar.

Histórias que ainda são desconhecidas em relação ao nível de esforço, risco ou complexidade, ou histórias que têm estimativas grandes demais para serem concluídas, trazem muitos problemas para os desenvolvedores.

Quando chega a hora de planejar um sprint, um release ou até mesmo um único dia, é importante saber o tamanho do trabalho que está sendo considerado.

Sem um bom dimensionamento, a equipe fica apenas adivinhando o que pode ser concluído e nunca saberia responder se as coisas estão dentro do prazo ou não.

Estamos trabalhando com um projeto não com adivinhações.

4. Dependências.

Uma das causas frequentes de atraso envolve histórias sendo “bloqueadas” – ou seja, há uma dependência que não foi resolvida que está impedindo o desenvolvedor de progredir.

Se uma história for bloqueada durante o desenvolvimento ou, pior, entrar em um sprint já bloqueado, então é uma história inútil. Essas dependências podem estar em outras equipes de desenvolvimento, equipes fora do desenvolvimento, como criação, marca ou marketing, ou até mesmo o proprietário do produto tomando uma decisão sobre algo.

Como parte da preparação de uma história, é importante descobrir se o desenvolvedor tem tudo o que é necessário para começar o trabalho ou se o terá quando o sprint começar. Alguns podem ser resolvidos da noite para o dia; alguns podem levar vários meses para resolver.

É importante saber onde uma história está quando ela se aproxima do topo da lista de pendências.

5. Definição de Pronto. DoR – Definition of Ready

O que está sendo feito nas tarefas também tem “critérios de aceitação” – ou seja, quais casos de uso e funcionalidades devem existir e poder ser mostrados em uma demonstração para que a história seja considerada completa.

Nesse caso, está associado a cada item de trabalho individual que flui por uma equipe ágil.

Se você estivesse praticando Scrum, então seria no nível do item do backlog do produto (PBI).

Se você estiver operando como uma equipe de programação extrema (XP) ou Kanban (ou simplesmente alavancando histórias de usuários), então seria para cada história que entrasse em uma equipe.

Os critérios de prontidão seriam uma definição clara do que conota uma história de usuário ou PBI que está “pronta” para execução dentro da iteração ou sprint.

Os itens são executados desde a funcionalidade voltada para o usuário até requisitos de latência e desempenho, condições de erro e testes negativos. Quanto mais um desenvolvedor souber o que será necessário para que a história seja aceita, melhor será para todos.

Na verdade, uma metodologia de desenvolvimento requer escrever os testes de aceitação primeiro e depois fazer o desenvolvimento.

6. Definição de Feito. DoD – Definition of Done

Espero que todos estejam familiarizados com a terminologia “definition of done” (DoD), ou “done-ness”, do ponto de vista dos métodos ágeis. É uma frase comum e incrivelmente importante para a saúde e maturidade da equipe ágil. É essencialmente um critério de saída, se você preferir, para o trabalho de sprint das equipes.

No nível da história do usuário, é comum referir-se aos critérios de aceitação de cada história como a verificação de conclusão da completude da história.

Em um nível de sprint completo, é comum se referir ao objetivo do sprint como o ponto de verificação para o que a equipe estava tentando entregar. E o acabamento também permeia a forma como os membros da equipe entregam seu trabalho.

Por exemplo, as revisões de código fazem parte dos critérios de conclusão de uma equipe? Nesse caso, ele planejará e executará revisões de código consistentemente como parte do desenvolvimento e entrega de cada história.

Portanto, a definição de “feito” é um critério de saída, que determina a condição de completude para o trabalho que está sendo entregue. Mas há outro critério que é útil em equipes ágeis na outra ponta do fluxo de trabalho – a entrega a DoR.

Acontece que impedir que histórias mal definidas (ou trabalho) entrem em cada sprint em primeiro lugar é uma maneira incrivelmente saudável de evitar os desafios que descrevi na introdução. Mas vamos explorar a prontidão com um pouco mais de detalhes.

O outro lado do DoD: Descrevendo “Pronto”

Pessoalmente, gosto de uma abordagem de lista de verificação para descrever os critérios de prontidão das equipes para o trabalho. Aqui está um exemplo dos tipos de verificações que eu vi serem valiosas para as equipes aproveitarem ao amadurecer suas histórias:

  • A história é bem escrita; e tem um mínimo de cinco testes de aceitação definidos.
  • A história foi dimensionada para se ajustar à velocidade das equipes e à duração do sprint; por exemplo, algo entre 1-13 pontos.
  • A equipe examinou a história em várias sessões de preparação – seu escopo e natureza são bem compreendidos.
  • A equipe tem o conjunto de habilidades e experiência necessários para implementar a história e entregá-la para atender à definição de “pronto” da organização e da equipe.
  • Se necessário, a história teve um pico de pesquisa para explorar (e refinar) suas implicações de arquitetura e design; ou para explorar os desafios de testabilidade associados a ele.
  • A história descreve o comportamento de ponta a ponta no sistema.
  • A equipe entende como abordar o teste dos aspectos funcionais e não funcionais das histórias.
  • Quaisquer dependências de outras histórias e/ou equipes foram “conectadas” para que a história seja sincronizada e entregue como parte do “todo maior”.
  • A história se alinha com o objetivo do sprint e é claramente demonstrável.

Portanto, não há fases distintas neste caso. Uma nova história de usuário simplesmente precisa atender a todas as verificações acima para que seja considerada pronta para execução.

Como cada história fica pronta depende do proprietário do produto para cada backlog do produto, colaborando com sua equipe. Pode levar um ou 50 passos para chegar lá.

Pode ser rápido ou lento. Mas trabalhando juntos, eles decidem como conduzir uma história até a prontidão para execução.

Criando um semáforo do seu Backlog Refinado

Levando em consideração que vamos utilizar o DAP (Detalhar, Avaliar e Priorizar) para as histórias que serão refinadas, podemos criar também um semáforo com estes Seis itens que falamos acima para seu backlog, dessa forma vamos avaliar as histórias: A, B e C

História Prioridade Requisitos Estimativas Dependências DoD DoR Total
A 1 2 2 1 1 1 8
B 3 3 2 3 2 2 15
C 2 1 1 1 1 1 7

 

Neste ponto, as histórias no backlog devem ser avaliadas ao longo dos Seis vetores acima: Prioridade, Requisitos, Estimativas, Dependências, DoR e DoD.

O ideal, para se ter uma boa métrica, fazer a média de até cerca de seis sprints de histórias é suficiente, embora esse número possa ser potencialmente um pouco maior ou menor, dependendo da cadência de lançamento da organização ou do tamanho do incremento de planejamento.

Histórias classificadas entre 11 e 18 estão prontas (verde); as histórias que estão entre 6-10 ainda não estão prontas (amarelo); e qualquer coisa abaixo de seis não está pronta (vermelho). Isso fornece um mecanismo rápido de semáforo para verificar rapidamente o status do backlog da equipe.

Ter algumas histórias vermelhas não é uma coisa ruim, especialmente se elas estiverem mais abaixo na lista de prioridades. Se você estiver três meses antes da chegada dos pintores, há muitos momentos de responsabilidade antes de precisar escolher seu esquema de cores.

No entanto, histórias vermelhas, ou mesmo muitas histórias amarelas, planejadas para inclusão nos próximos dois sprints, podem sinalizar um problema ou uma lista de pendências que não está em boa forma.

Na verdade, eu sugiro que um backlog perfeito tenha principalmente histórias verdes nos próximos dois sprints, principalmente amarelos nos dois seguintes e principalmente vermelhos nos dois seguintes.

Ao fazer essa avaliação, a equipe pode dizer rapidamente quão saudável é o plano e, portanto, quão certo eles estão de que a equipe está “no caminho certo” para entregar.

Nunca haverá um caso em que não haja incógnitas; na verdade, um dos pontos do Agile é admitir que você não pode saber tudo antes do tempo.

Mas quanto mais você conseguir entender as coisas, especialmente as coisas que estão ao alcance da equipe, mais confiante ela poderá começar a investir no caminho para entregar valor ao cliente e à organização.

Expresse o valor do cliente

A primeira maneira pela qual uma equipe de desenvolvimento pode priorizar seu trabalho técnico é expressar o valor do trabalho em termos de benefício para o cliente.

Afinal, se não houver uma boa razão para fazer o trabalho em primeiro lugar, é lógico que ele não deve ser feito.

Mesmo coisas aparentemente mundanas podem ser enquadradas de forma a ajudar o cliente.

Já ouvi gerentes de desenvolvimento dizerem: “A estabilidade e a segurança de nossos sistemas é um recurso que lançamos todos os dias para nossos usuários”. Quando visto por essa lente, não é difícil descobrir quanto valor para o cliente seria criado e como a prioridade se compara a outros itens.

Esse tipo de determinação pode ser feito para muitas melhorias que parecem técnicas por natureza, mas na realidade são voltadas para o cliente.

Isso inclui itens como melhorias de desempenho, correções de bugs, dimensionamento de carga e até itens invisíveis, como a aplicação de hotfixes ou patches de segurança a uma estrutura de aplicativo.

Todas essas tarefas podem ser vistas como boas para todos e, portanto, devem ser priorizadas junto com novos recursos ou novas funcionalidades. Qualquer bom Product Owner seria capaz de entender o valor que está sendo criado e colocar isso em contexto com todo o resto.

O desafio é que esse tipo de cálculo não é natural para a maioria dos profissionais de produtos; embora reconheçam que há boas razões para fazer esses itens, muitas vezes têm dificuldade em quantificá-los.

É aqui que a equipe de desenvolvimento precisa agir como se estivesse na organização do produto, determinando o quanto os tempos de resposta serão mais rápidos ou quantas vezes um determinado defeito e acionado por um cliente ajudará a calcular o valor do trabalho.

As melhores práticas do setor podem ser citadas quando se trata de atualizações de estrutura, assim como eventos nas notícias que expõem vulnerabilidades que devem ser fechadas.

Qualquer que seja o caminho escolhido pela equipe, deve ser em termos de criação de valor; chamar as coisas de “devem ser feitas” sem fundamentação não é uma maneira útil de colaborar.

Refinar como parte da estimativa

Muitas das atividades que compõem um projeto ágil devem ser feitas em equipe, com todos no mesmo lugar. De fato, no Manifesto Ágil, um dos princípios afirma que as interações cara a cara são a maneira mais eficiente e eficaz de se comunicar.

Isso apresenta um problema para um gerente de projeto executando um projeto em que a equipe é distribuída, no todo ou em parte. Embora ter todos na mesma sala possa ser o ideal, não é realista se as pessoas trabalharem a quilômetros ou países de distância, ou se todos forem forçados a trabalhar em suas casas.

E enquanto a tecnologia pode ajudar a nos aproximar e imitar a interação face a face, há outras logísticas, como fusos horários e conectividade, a serem superadas.

Na prática, quase tudo o que pode ser feito em Agile pode ser feito de forma distribuída, desde o Daily Scrum até demonstrações e retrospectivas. É preciso apenas um cuidado extra para torná-los eficazes.

Uma atividade ágil importante que as equipes distribuídas podem realizar sem muita perda é o refinamento do backlog.

É importante para um scrum master, product owner ou mesmo um gerente de projeto que se encontra gerenciando uma equipe distribuída não tentar substituir os processos existentes pelo mesmo usando tecnologia.

Não é “o mesmo, apenas em vídeo”.

O seu objetivo é encontrar uma maneira de obter o mesmo valor de uma atividade sem necessariamente fazê-la exatamente da mesma forma que a equipe fez no passado.

O mesmo vale para o refinamento do backlog. Para uma equipe que costumava se reunir na mesma sala toda quinta-feira à tarde, simplesmente mudar para fazer a mesma coisa por videoconferência não terá os mesmos resultados.

O resultado desejado de uma sessão de refinamento é que os itens do backlog passem de ideias para itens acionáveis ​​que são compreendidos, dimensionados e priorizados.

Isso é possível, mesmo que todos estejam presos trabalhando em seus “escritórios domésticos”.

Na verdade, mesmo que todos estejam trabalhando na mesma mesa, certas partes de uma sessão de refinamento devem ser feitas em particular.

Para garantir que todos entendam um requisito, todos devem passar algum tempo sozinhos, certificando-se de que o entendem e que há informações suficientes sobre a história para que alguém possa pegá-lo e ter uma boa ideia do que precisa ser feito.

O escopo, ou determinar quanto esforço algo exigirá, também deve ser feito em particular. O conceito de “planning pôquer” é uma forma de prevenir o pensamento de grupo, e como uma forma de garantir que os desenvolvedores mais experientes, ou mais falantes, não se sobreponham a todos na sala.

Ambas as partes do refinamento devem ser feitas separadamente e, em um ambiente distribuído, às vezes pode ser feita mais facilmente.

Aqui está um exemplo de como seria uma sessão de refinamento de backlog distribuído.

Cada um analisa o refinamento por conta própria

O refinamento começa com o dono do produto ou a pessoa que possui a história introduzindo os requisitos, objetivos e resultados desejados da história.

Isso pode ser feito ao vivo por meio de discussão ou pode ser algumas linhas escritas dentro da própria história. O dono do produto deve incluir requisitos detalhados, cenários, casos de falha, regras de negócios e outros itens importantes para completar a história.

Cada membro da equipe de produto deve analisar a história por conta própria, para garantir que a história conforme escrita corresponda à compreensão do que estão discutindo.

É muito fácil em uma situação de grupo presumir que outros membros da equipe têm o mesmo entendimento, ou eles entendem ambiguidades ou partes da história que não são claras.

Façam perguntas juntos no refinamento

Ao ler a história, cada desenvolvedor deve fazer perguntas esclarecedoras. Cada membro da equipe terá uma lista de itens que precisam de mais informações ou mais detalhes e devem estar preparados para perguntar ao dono do produto.

Esta parte deve ser feita em grupo, pois haverá perguntas de outros membros da equipe, e uma pergunta provavelmente gerará mais algumas. Os desenvolvedores devem fazer perguntas ao dono do produto até sentirem que entendem bem a história e todos concordarem que todas as perguntas foram respondidas, incluindo novas perguntas que surgiram durante a própria discussão.

Isso não significa que a história seja tão detalhada a ponto de não ter mais nada a ser considerado, mas sim que a história atendeu à “definição de pronto” para a equipe.

Reunião de backlog produtiva

Estimar o refinamento separadamente

Uma vez que a história atende à definição de pronto, cada desenvolvedor decide por si mesmo sobre o tamanho da história. Diferentes metodologias usam diferentes mecanismos para decidir como definir o escopo de uma história; a maioria dos projetos ágeis usa pontos de história.

Esses pontos pretendem representar uma visão geral da dificuldade de uma história, incluem complexidades desconhecidas, riscos, dependências e esforço real para completá-la.

Quando as estimativas são feitas ao vivo em uma reunião, cada desenvolvedor as descobre por conta própria, seja usando o planning poker ou por algum outro método.

Cada desenvolvedor terá uma visão diferente sobre o quão difícil será concluir uma história, seja devido à experiência passada, ou usando uma solução da qual apenas alguns membros da equipe estão cientes, ou talvez conhecendo um ponto de discórdia da última vez que a equipe lidou um pedido como este.

Seja qual for a causa, mesmo quando feito ao vivo, cada membro da equipe cria o que pensa por conta própria. Esse valor é então revelado à equipe, de uma só vez, o que leva a uma discussão e a um resultado final.

Fazer isso de maneira distribuída, na verdade, torna essa etapa mais fácil. Cada desenvolvedor pode levar seu tempo para entender o espaço do problema, e sua solução.

Quando todos dizem que estão prontos, a discussão final pode começar e podem chegar a sua própria determinação quanto ao escopo, sem ter uma sala cheia de pessoas olhando para eles enquanto ponderam.

Discutir o refinamento e finalizar em equipe

Uma vez que as estimativas de esforço de todos são conhecidas, a equipe deve se reunir novamente e discutir o resultado. É raro que todos na equipe tenham a mesma opinião; alguns serão mais altos ou mais baixos do que outros, e pode haver um ou dois valores atípicos.

Nesse ponto, a equipe analisa os processos de pensamento uns dos outros e como eles acabaram com seu valor. A equipe pode então voltar a votar em particular ou simplesmente decidir chegar a um acordo que todos possam aceitar.

Uma vez que isso seja resolvido, a equipe pode dividir a história em tarefas que podem ser feitas individualmente. Ser distribuído pode facilitar essa parte; todos precisam estar confortáveis ​​com o valor final por conta própria.

Estar separado pode ajudar a impor isso e evitar que as pessoas concordem simplesmente em concordar ou permitir que uma pessoa domine a discussão.

A pessoa que lidera a sessão de refinamento deve garantir que os pensamentos de todos sejam ouvidos e que todos entendam o resultado final.

Pessoalmente, o líder provavelmente olharia ao redor da sala e tentaria julgar com base em acenos de cabeça ou talvez até mesmo julgando o silêncio.

Como todos estão separados, todos precisarão dizer em voz alta que estão alinhados.

Sobre fazer refinamento remoto

Em vez de tentar ler os rostos das pessoas, fazer com que as pessoas falem tornará os sentimentos das pessoas muito mais claros, o que pode realmente levar a uma equipe melhor coordenada no final.

Mais e mais empresas estão executando seus projetos de maneira distribuída. Isso é especialmente verdadeiro durante uma pandemia mundial, mas também estava se tornando cada vez mais verdadeiro devido à natureza global da indústria e aos avanços da tecnologia.

Algumas das atividades e cerimônias associadas à execução de um projeto Agile precisam de um esforço extra para garantir que ainda possam atingir seus objetivos sem que todos precisem estar na mesma sala.

O refinamento da lista de pendências, no entanto, se presta facilmente ao trabalho com uma equipe que não está reunida.

Certas partes dele, certificando-se de que as histórias sejam compreendidas e chegando a estimativas de escopo e esforço, devem ser feitas individualmente.

Outras partes, como fazer perguntas e elaborar um plano final, podem ser feitas em conjunto, com todos se revezando, tomando os devidos cuidados

Como saber quando realizar o refinamento?

Você já entrou em um sprint assumindo uma história de usuário da qual se arrependeu mais tarde? Por exemplo:

  • Uma que você deveria ter dividido um pouquinho mais?
  • Uma que a equipe não tinha uma “pista de bola de neve” de como implementar tecnicamente?
  • Uma em que o valor não era claro do ponto de vista do negócio?
  • Uma onde a estimativa e a realidade não eram iguais?
  • Uma que, quando você “fez”, você não tinha certeza de como determinar que foi feito?

Eu estou supondo, é claro que você tem. Eu encontro essas cenas em equipes que estou treinando o tempo todo. E verdade seja dita, não é um evento terrível. Equipes cometem erros… o tempo todo. E eles geralmente aprendem com eles.

O verdadeiro problema, da minha perspectiva, é com as equipes que continuam fazendo esse sprint sobre sprint sobre sprint. Sim, a dinâmica muda um pouco, mas o resultado final é o mesmo. A equipe está aceitando histórias de usuários que realmente não estão prontas para o sprint!

Então a pergunta é: o que pode ser feito para evitar isso? Existe alguma técnica que impeça que isso aconteça, ou essas equipes estão condenadas a continuar repetindo seus erros? Estou feliz que você perguntou.

Relação com o refinamento do backlog

Então, você pode estar se perguntando: como uma história de usuário fica pronta? Do meu ponto de vista, é parte da preparação ou refinamento contínuo e em tempo real do backlog que uma equipe assume como parte natural do amadurecimento de seu backlog.

Reuniões regulares de preparação fornecem um local para essas discussões, e é simplesmente uma parte de preparar seus backlogs suficientemente para uma execução eficaz.

As equipes geralmente agendam até 10% de seu tempo em cada sprint para refinamento do backlog. Cerca de metade disso é focado em reuniões, talvez duas reuniões de 1 hora por semana.

O restante do tempo é gasto em refinamento individual ou em pequenos grupos. O ponto é que a equipe mergulhe continuamente em seus backlogs de produtos.

O refinamento geralmente examina:

  • Estimativa de história
  • Decomposição da história
  • Definição da história
  • Investigação da história
  • Aceitação da história

Você continua refinando cada história de usuário até que a equipe tenha alcançado um nível sólido de compreensão e a história tenha sido dimensionada adequadamente para caber em um sprint.

Muitas vezes, as equipes estão antecipando vários sprints, de modo que o refinamento não é apenas em torno do que vem a seguir, mas principalmente focando em um fluxo de trabalho para a próxima versão ou mais.

Como eu “Preparo” meu Backlog

Este artigo não pretende ser uma cartilha sobre o processo passo a passo sobre como fazer a preparação do backlog, mas as etapas gerais são as mesmas.

No Agile, existe um acrônimo chamado DEEP que é frequentemente usado. Significa: Detalhado, Emergente, Estimado e Priorizado. Cada um desses quatro poderia ser assunto de seu próprio artigo, mas vamos dar uma olhada em cada um e entendê-los melhor.

O D é para Detalhado

E muitas vezes você verá isso chamado “Detalhado apropriadamente”.

O que isso significa é que cada história de usuário ou item no backlog precisa ser detalhada o suficiente para a posição em que está e que o nível de atenção  esteja pronto para quando um desenvolvedor a pegar.

Dependendo da história, isso pode significar que todos os ativos estão prontos, todos os equipamentos adquiridos ou todos os casos de exceção são conhecidos e descritos.

Se uma história está na parte inferior, pode ser explicada com menos precisão, pois não há necessidade de prepará-la ainda.

O primeiro E é geralmente para Emergente

A ideia é que o backlog mude com o tempo e esse comportamento deve ser adotado, não resistido.

O backlog inicial vem dos pensamentos iniciais do proprietário do produto; é raro que uma pessoa trabalhando sozinha vá acertar tudo na primeira tentativa.

Na verdade, se o backlog mantiver a mesma priorização em todo o projeto, isso é mais um sinal de que algo está dando errado do que um sinal de que as coisas estão dando certo.

À medida que a equipe aprende mais sobre o produto (geralmente chamado de “discovery do produto”), novas coisas serão adicionadas, algumas serão removidas e muitas coisas mudarão de prioridade. Este é um sinal de um backlog saudável.

O segundo E é para Estimativa

Falamos acima que não se espera apenas que o backlog seja uma listagem de requisitos, mas também uma ferramenta para o planejamento do projeto.

Para que isso funcione, os itens precisam ser estimados adequadamente. A estimativa ágil é uma arte e também uma ciência, mas a mesma coisa vale tanto para a estimativa quanto para o detalhamento.

Quanto mais próximo um item estiver do topo da lista de pendências, mais detalhadamente ele deve ser estimado. Os itens na parte inferior podem ter estimativas como “grande” ou “muito grande”.

Mas para fazer um planejamento adequado, os itens no topo devem ter estimativas que ajudem a fazer um plano que funcione. Cada equipe usa um mecanismo diferente, de pontos de história a dias de esforço ou qualquer outra coisa.

O mecanismo real não importa, o que importa é que o que é usado realmente ajuda a criar um plano útil.

Finalmente, o P é para Priorizado

Embora já tenhamos falado sobre isso, o conceito de criar uma lista priorizada pode ser difícil para novos proprietários de produtos. Às vezes, os proprietários de produtos dividem os recursos em listas que não alteram o comportamento, como “obrigatório”, “crítico” e “bloqueador de lançamento”.

Dependendo do seu ponto de vista, todas essas três coisas são as mesmas. 

O Agile propõe uma classificação literal da pilha de prioridades, de um ao infinito, o que ajuda a responder às perguntas sobre o que fazer a seguir, o que está no próximo sprint e o que está fazendo o lançamento.

Se um proprietário do produto não puder priorizar, ou pior, criar várias prioridades principais, a lista de pendências se tornará inútil.

A preparação adequada do backlog o torna DEEP; os itens são devidamente detalhados, novas ideias e novos pensamentos podem surgir, estimativas são criadas e definidas e as prioridades são claras e comunicadas. Sem isso, a equipe terá um desempenho inferior.

Resumo e Conclusão

O backlog deve ser preparado constantemente; histórias de usuários devem ser esclarecidas, especificadas e preparadas para o trabalho. E os itens que estão em desenvolvimento ativo devem ficar o mais estáveis ​​possível.

Isso significa que o ato de preparar o backlog nunca deve parar; muitas equipes reservam tempo para fazer isso semanalmente, incluindo todos da equipe.

O impacto dessa preparação deve ser sentido em intervalos regulares, seja a cada sprint, a cada lançamento ou em algum outro intervalo especificado. Aderir a um cronograma beneficiará a equipe e o produto, que é a essência do Agile.

O backlog do produto serve a muitos propósitos. É a lista canônica de requisitos que são totalmente especificados, em ordem de prioridade, e estão prontos para um desenvolvedor pegar e trabalhar.

Ele também serve como uma ferramenta de planejamento que mostra quais itens estão sendo trabalhados, quais são os próximos itens e fornece algumas informações sobre os recursos que estão em baixa na lista de prioridades.

As partes interessadas podem visualizar a lista de pendências e entender para onde o produto está indo e quando podem esperar ver a funcionalidade pela qual estão esperando. É uma ferramenta poderosa.

Mas além de ser um artefato útil para executar um projeto, também é uma boa maneira de incorporar os princípios do Agile.

Ter a equipe de desenvolvimento como atores completos na preparação dos requisitos e ter o proprietário do produto envolvido no design e na estimativa ajuda a unir a equipe e remove a situação “nós contra eles” com a qual todos lutamos no passado.

A preparação adequada ajuda o produto, a equipe e a organização.

Embora pareça sem importância, pode ser a coisa mais importante que você precisa para acertar.

Estes não são tipicamente parte da definição do “core Scrum”. No entanto, como histórias de usuários e preparação de backlog, são práticas incrivelmente úteis para muitas equipes.

Se você refletir de volta à introdução, essas equipes em dificuldades perderam de vista como pré-definir adequadamente seu trabalho.

Mas, para ser muito mais sucinto: é sempre uma boa prática para equipes ágeis garantir que suas histórias estejam prontas antes de colocá-las em um sprint.

A reunião de Sprint Planning efetiva

No início de cada Sprint, a equipe Scrum e o Product Owner negociam o escopo do Sprint em uma reunião com tempo limitado para discutir e concordar com o backlog da Sprint, mas como realizar uma Sprint Planning efetiva?

O Product Owner quer que a funcionalidade seja implementada adequadamente e que seja investido o dinheiro do cliente com sabedoria no desenvolvimento, a equipe quer uma missão que consiga cumprir, e claro,  todo mundo quer que a reunião de Sprint Planning termine na hora!

Sprint Planning template

Vou deixar aqui pra você um template de agenda da Sprint Planning, para que seu planejamento de sprint seja bem-sucedido. 

A finalidade da Reunião de Planejamento da Sprint (Sprint Planning) é que o Product Owner e a equipe negociem o que deve ser realizado durante a Sprint, ou, como prefiro chamar, o contrato de Sprint.

Embora valorizemos as interações do cliente em relação aos contratos formais, os contratos ainda podem ser úteis e eu gosto de falar sobre um “contrato de Sprint“.

É simplesmente um acordo entre o Product Owner, que concorda em não mudar o combinado antes do final do Sprint, e a equipe, que se compromete a entregar um conjunto definido de funcionalidades até aquele momento.

Parâmetros Básicos do Contrato de Sprint

Um dos segredos mais bem guardados do Scrum é que um projeto consiste em uma série de mini-projetos de tempo fixo, qualidade fixa e escopo fixo, onde cada mini-projeto tem um teto de custo.

Sendo assim basta somar os resultados de todos os mini-projetos juntos e você tem o valor do seu lançamento.

Como o comprimento do Sprint, o tamanho da equipe e a definição do feito são definidos e fixados para a duração do sprint, apenas o escopo pode variar e, mesmo aqui, a equipe se esforça para definir e cumprir o compromisso.

Da mesma forma o custo depende principalmente das horas trabalhadas, o limite superior é conhecido, mas desde que as coisas acontecem.

Bem como ser chamado para ajudar outro projeto ou a visita de um médico inesperado.

Nestes casos o limite raramente é alcançado. Então você tem um teto de custo.

Enquanto a qualidade é expressa através da definição de feito e só deve mudar ocasionalmente. Como todos os parâmetros são fixos para a duração do Sprint, a única coisa a se concordar é o escopo.

Embora não seja um parâmetro do contrato, a velocidade esperada ajuda a definir a expectativa de quanto pode ser realizado dentro da Sprint.

Permanecendo dentro do time-box

O Scrum Master modera a reunião de Sprint planning, mas o Product Owner vem com a agenda, afinal ele quer que a funcionalidade seja entregue e que o projeto geral esteja no caminho certo.

Independentemente da duração do sprint ou do tamanho da sua equipe, a preparação é a chave para terminar a tempo.

Se você está despreparado, a reunião pode realmente se arrastar!

Antes de começar, a equipe de implementação deve ter visto, entendido e avaliado as histórias – As histórias devem ser pequenas o suficiente para serem implementadas em uma sprint – Os critérios de aceitação deveriam ter sido definidos.

Isso aumenta muito suas chances de o Product Owner aceitar a implementação ja na primeira tentativa.

A equipe deve saber quanta capacidade eles têm disponível. Isto é: as férias, treinamentos, eventos da empresa e outros compromissos devem ser conhecidos e contabilizados antes do início da sprint.

Alguns eventos são imprevisíveis, caso em que você apenas faz uma estimativa razoável de quanto vai consumir, concorda com as prioridades do Product Owner e aceita algumas histórias como “condicionais” – aquelas que você fará se tiver tempo.

Uma reunião de planejamento simples da sprint

Eu usei essa estrutura em vários contextos, incluindo um caso em que o Product Owner  pagou pela equipe por hora e outro com equipes distribuídas em dois ambientes (sites) diferentes.

O quanto você precisa ser formal dependerá de muitas coisas, incluindo o tamanho do projeto, quão bem o projeto está indo, a relação comercial entre o proprietário do produto e a equipe, como as partes cooperam, etc.

Quanto mais desafiador o projeto, mais você precisa pontilhar você e cruzar seu t.

Revise os parâmetros básicos – Data de início e término, hora e local da reunião de revisão do sprint, disponibilidade da equipe e definição de pronto;

Apresentar e discutir cada história – Uma caixa de tempo para cada um pode ser útil para manter toda a reunião no caminho certo, manter uma reserva no final desta seção para histórias difíceis geralmente torna mais fácil seguir em frente se a discussão estiver ficando presa em uma história;

Comprometa-se com as histórias – Percorra a lista, uma de cada vez e por ordem de prioridade, faça com que a equipe se comprometa com cada uma até que ninguém se comprometa mais;

Realize o Acordo – Confirme a lista de histórias confirmadas com o Product Owner.

Como Scrum Master, achei útil confirmar o contrato da Sprint com um e-mail para o Product Owner, nele enviei uma imagem do quadro de tarefas, um pdf da planilha, um dump de tela da página wiki, ou até mesmo o próprio chamado na ferramenta que utilizamos (com os anexos nele) pode ser uma maneira eficaz de capturar o contrato.

Todos ficam sabendo exatamente sobre o que deve ser feito e tanto o Product Owner quanto a equipe têm uma base sólida para examinar o sucesso da sprint e o estado geral do projeto na revisão do sprint.

Conclusão

Em suma, não é porque priorizamos software funcionando em detrimento de documentação que você não “pode” ou “deve” parar de trabalhar em seus documentos, você pode utilizar esse template numa reunião de Sprint Planning e conseguir “fechar” o contrato com sua equipe e seu Product Owner de uma forma simples e transparente.

Em breve enviarei mais notícias das minhas jornadas ágeis e conforme for aprendendo eu acabo compartilhando com você. Um grande abraço e até semana que vem.

 

Contratos para projetos ágeis: tudo que você precisa saber

Como cliente ou fornecedor de serviços de software no início de um projeto de desenvolvimento, você sabe que há muito em jogo para trabalhar apenas com um acordo verbal, contratos para projetos ágeis soam como algo paradoxal ao Manifesto ágil.

Embora o Manifesto Ágil1 valorize a colaboração do cliente acima dos contratos, os contratos são necessários ao trabalhar com fornecedores externos. Um contrato é realmente apenas um conjunto de “regras do jogo” escritas.

As regras certas aumentam a chance de sucesso de ambas as partes. As regras erradas dificultam a cooperação e impedem o progresso.

Quais tipos de contrato são melhores para projetos ágeis de desenvolvimento de software?

Este é o primeiro de dois artigos. Neste artigo, veremos o objetivo e o conteúdo de um contrato e alguns critérios para avaliar contratos ágeis.

Na próxima semana, veremos alternativas de contratação de projetos de software Scrum e examinaremos seus pontos fortes e fracos.

Qual é o propósito de um contrato?

Contratos definem as regras básicas de jogo para o projeto. Em teoria, eles são livremente inseridos por ambas as partes para criar as condições ideais para concluir com sucesso o projeto.

Na prática, os contratos são frequentemente vistos como jogos competitivos, em que o objetivo é colocar a outra parte em desvantagem, especialmente se as coisas correrem mal.

Contudo empresas muito grandes e o governo geralmente têm condições padronizadas que precisam ser aceitas “em bloco” como um pré-requisito para que você consiga fazer negócios com elas.

Essas condições raramente são justas, portanto, um resultado razoável do projeto depende muito de um bom relacionamento com o cliente real e de evitar o recurso ao contrato ou à lei – O Manifesto Ágil está certo neste ponto: os relacionamentos com os clientes são mais importantes do que os contratos escritos!.

Mesmo que os contratos negociados nem sempre busquem uma relação ganha-ganha, você pode precisar da ajuda de especialistas.

No entanto, da perspectiva do cliente, os contratos não produzem valor agregado. Eles são um produto residual, portanto, o esforço gasto na negociação e produção deve ser minimizado.

Um contrato distribui o risco e reflete a confiança entre as partes.

O que acontece se algo der errado? Quem paga quanto o projeto é mais difícil do que o esperado? Quem se beneficia se o projeto for concluído antes do planejado?

As regras de jogo erradas podem ser prejudiciais para o sucesso do projeto. Regras ruins podem levar a preços irrealistas, prazos ou expectativas pouco funcionais. Relações de ganhar/perder são prejudiciais para o sucesso do projeto – A qualidade sofre mais frequentemente – Você quer que a “Equipe A” ou a “Equipe B” trabalhem no seu projeto? Pense cuidadosamente sobre quanta pressão você coloca no fornecedor.

Como avaliar as formas de contrato

Os contratos comerciais podem assumir muitas formas. Quais são as alternativas de contrato adequadas para projetos de desenvolvimento ágil? Para qualquer contrato, eu olharia:

  • Como o contrato é estruturado? Quais são as regras básicas para entregar o escopo e o faturamento?
  • Como distribuir o risco e a recompensa entre o cliente e o fornecedor?
  • Como ele lida com mudanças nos requisitos?
  • Que modelo de relacionamento com o cliente ele promove: competitiva (minha vitória é sua perda), cooperativa (ganha-ganha), indiferente (não me importa – você perde) ou dependente (cara-eu-ganho-coroa-você perde) ?

Se eu não elaborasse o contrato, também procuraria por armadilhas – a negociação de contato pode ser um jogo competitivo – A questão aqui é o que você faz se encontrar uma? – Tentar eliminá-lo ou aceitar e seguir em frente? Vamos chamar isso de “decisão de negócios“.

Quais informações devem ser incluídas em um contrato?

Quanto mais confiança existir entre cliente e fornecedor, menos você precisará anotar. Na minha experiência, há alguns pontos que pertencem a todos os contratos:

  1. Objetivos do projeto e da cooperação entre as empresas. Isto reflete diretamente ao “elevator pitch” e a missão do produto.
  2. Um esboço da estrutura do projeto – processo de Scrum, papéis principais e quaisquer diferenças do Scrum que se aplicam.
  3. Key-Users – quem é responsável nos níveis operacional e de escalonamento e o que é exigido dessas pessoas?
  4. Pagamento e faturamento, incluindo quaisquer cláusulas de bônus e penalidade.
  5. Rescisão antecipada e normal.
  6. “Detalhes legais.” Dependendo da lei local e dos costumes legais, pode ser necessário limitar a responsabilidade civil, especificar local, garantir a separação (que partes do contrato permanecem em vigor, mesmo que partes do contrato sejam consideradas inválidas) ou incluir outras cláusulas no texto para evitar que várias coisas ruins com bases legais aconteçam. Exemplos de contratos de referência da sua região e realizar benchmarking pode ser muito útil (e são mais baratos que um advogado!).

Você precisa incluir o escopo no contrato?

Frequentemente o escopo está presente (pelo menos nos contratos do governo que eu participei, o escopo foi incluído por lei), mas se concentrar o contrato no escopo também faz com que o escopo fique inflexível.

Se possível, é melhor especificar como você gerenciará o escopo (por exemplo, Backlog do produto, contrato do Sprint), mas detalhes operacionais devem ser deixados para a equipe do projeto.

Os pontos 2, 3, 4 e 5 determinam as regras de jogo para o seu projeto. Se você acertar, você terá a base para um bom projeto. Mas quais são as melhores regras? Há pelo menos meia dúzia de tipos diferentes de contrato, de tempo e materiais a preço fixo, escopo fixo.

No próximo artigo vou trazer alguns tipos de contrato que vão “clarear” um pouco mais sua mente neste quesito. Até semana que vem!

Contratos Ágeis – 10 tipos de contrato

De acordo com Peter Stevens2, levantamos 10 tipos de contratos ágeis que podem fazer a diferença em seus projetos de software.

Além disso,  analisamos o propósito e o conteúdo de um contrato e identificamos critérios para avaliar contratos para projetos Scrum e ágeis.

Onde sugeri 4 pontos para comparar formas de contrato:

  • Como o contrato é estruturado? Quais são as regras básicas para entregar o escopo e o faturamento?
  • Como distribuir o risco e a recompensa entre o cliente e o fornecedor?
  • Como ele lida com mudanças nos requisitos?
  • Que modelo de relacionamento com o cliente ele promove: competitiva (minha vitória é sua perda), cooperativa (ganha-ganha), indiferente (não me importa – você perde) ou dependente (cara-eu-ganho-coroa-você perde) ?

Nesta semana, vamos analisar vários contratos possíveis e ver como eles funcionam com projetos de desenvolvimento ágeis e do Scrum:

  • O “Contrato de Sprint”
  • Preço Fixo / Escopo Fixo
  • Tempo e Materiais
  • Tempo e Materiais com Escopo Fixo e Teto de Custo
  • Tempo e Materiais com Escopo Variável e Teto de Custo
  • Desenvolvimento Faseado
  • Cláusulas de bônus / penalidade
  • Lucro Fixo
  • “Dinheiro para nada, mudanças de graça”
  • Empreendimentos conjuntos /Joint Ventures

Contratos ágeis – Contrato de Sprint

Trabalhando com o Scrum, descobri que a metáfora de um “Contrato de Sprint” que é útil para entender (e às vezes reforçar) o relacionamento entre o Product Owner e a equipe de implementação.

agile-contracts-sprint3

Estrutura: Este não é realmente um contrato comercial, mas simplesmente o acordo entre o Dono do Produto e a Equipe para um sprint.

Escopo: A equipe de implementação concorda em fazer o melhor para entregar um conjunto de recursos (escopo) acordado para um padrão de qualidade definido até o final do sprint. (Idealmente, eles entregam o que prometeram, ou até mesmo um pouco mais.)

O Product Owner concorda em não alterar suas instruções antes do final do Sprint.

Risco: Um projeto Scrum pode ser considerado como uma série de mini projetos com parâmetros fixos:

Tempo (Sprint), Escopo (Backlog), Qualidade (Definição de pronto) e Custo (Tamanho da Equipe * Comprimento da Sprint). Apenas o escopo pode variar e isso é medido a cada sprint.

Dica: Confirmar “o contrato de Sprint” via e-mail ou publicá-lo no (Wiki/base de conhecimento) do projeto no início de cada Sprint é geralmente uma boa ideia.

Cria confiança, independentemente da forma contratual subjacente.

Dica 2: O contrato da Sprint pode ser referenciado no contrato comercial.

Descobri que, depois de alguns lançamentos, o contrato comercial pode se reduzir a um contrato de tempo e material de uma página, talvez com um teto de custo para o trimestre ou para o próximo grande lançamento.

Contratos ágeis – Preço Fixo / Escopo Fixo

agile-contracts-preco-escopo-fixos3Estrutura: Concorde com as entregas, entregue-as – Envie uma fatura – Os clientes gostam de projetos de preço fixo porque lhes dá segurança (ou pelo menos eles pensam assim).

Escopo: O nome diz tudo, não é? O jogo de solicitação de alteração (correção: processo de solicitação de alteração) destina-se a limitar as alterações no escopo – Esse processo é caro e as alterações geralmente não são evitáveis – Como o cliente quase por definição quer sempre mais escopo, encerrar o projeto pode ser difícil.

O fornecedor quer que o cliente seja feliz, então o fornecedor geralmente produz. As palavras “etcetera” são muito perigosas na especificação de um requisito de preço fixo.

Risco: O risco óbvio está do lado do fornecedor. Se as estimativas estiverem erradas, o projeto perderá dinheiro.

Riscos menos óbvios são o jogo de solicitação de mudança, através do qual o fornecedor negocia receita adicional através de mudanças de escopo.

Se o fornecedor subestimou mal o esforço ou risco, ou cotou um preço irrealista baixo, as perdas podem até ameaçar a existência do fornecedor, o que também representa um problema para o cliente.

Relacionamento: De competitivo para indiferente – O cliente geralmente quer ter mais e o fornecedor quer fazer menos – O fornecedor quer que o cliente seja feliz, então normalmente o fornecedor produz.

Dica: Especifique os requisitos funcionais com histórias do usuário.

Contratos ágeis – Tempo e Materiais

agile-contracts-time-materials3Estrutura: Vá e trabalhe por um mês e envie uma fatura ao cliente.

Fornecedores gostam disso, porque o cliente corre o risco de mudar de ideia no meio do caminho.

Escopo: A priori não fixo. Mais cedo ou mais tarde, o cliente não quer pagar mais, então o projeto chega ao fim.

Risco:  São carregados em 100% pelo cliente. O fornecedor tem pouco incentivo para manter os custos baixos.

O esforço para garantir que apenas esforços e despesas legítimos sejam faturados pode ser substancial.

Relacionamento: Indiferente. O fornecedor fica feliz quando há mais trabalho porque mais trabalho significa mais dinheiro.

Dica:  Recomendado para projetos em que o cliente possa gerenciar melhor o risco do que o fornecedor.

Isso geralmente é combinado com um teto de custo. Quão bem funciona pode depender de como o escopo é tratado.

Contratos ágeis – Tempo e Materiais com Escopo Fixo e Teto de Custo

agile-contracts-time-materials-escop[1]Estrutura: Igual ao preço fixo, escopo fixo, exceto se o fornecedor concluir antecipadamente, o projeto passa a custar menos, porque somente o esforço real é faturado.

Escopo: O mesmo que preço fixo, escopo fixo.

Risco: Neste caso esse contrato parece representar o “melhor dos dois mundos” do ponto de vista do cliente.

Se requer menos esforço do que o esperado, custa menos. Mas uma vez que o teto de custo foi alcançado, ele se comporta como um projeto de preço fixo.

Relacionamento: Dependente – Do ponto de vista do fornecedor, o objetivo é atingir exatamente o limite de custo – Não há incentivo para o fornecedor entregar abaixo do custo máximo orçado.

O cliente provavelmente tratou o projeto internamente como um projeto de preço fixo e, portanto, não tem incentivos para renunciar ao escopo para economizar dinheiro.

Contratos ágeis – Tempo e Materiais com Escopo Variável e Teto de Custo

agile-contracts-time-materials-escop[2]Estrutura: Igual ao tempo e materiais, exceto um teto de custo, que limita o risco financeiro do cliente.

Escopo: O mesmo que um preço fixo, projeto de escopo fixo.

Risco: O orçamento expira sem atingir o valor comercial necessário para o cliente.

O cliente não recebe tudo o que ele pede.

Relacionamento: Cooperativa. A combinação de orçamento limitado e escopo variável enfoca o cliente e o fornecedor na obtenção do valor comercial desejado dentro do orçamento disponível.

Dica: Por experiência, eu diria que este tipo de contrato combina bem com o Scrum.

O cliente tem controle sobre cada sprint individual. Um relacionamento construtivo significa que, mesmo que os problemas se desenvolvam no caminho, as emoções estão certas em chegar a uma solução mutuamente aceitável.

Contratos ágeis – Desenvolvimento Faseado

agile-contracts-phased-development3Estrutura: Divulgue os lançamentos trimestrais e aprove fundos adicionais após cada lançamento bem-sucedido.

Escopo: Não explicitamente definidas pelo modelo. Lançamentos estão em vigor na caixa de tempo.

O conhecimento de que haverá outro lançamento no próximo trimestre torna mais fácil aceitar o adiamento de um recurso para alcançar a caixa de tempo.

Risco: O risco do cliente é limitado a um trimestre de custos de desenvolvimento.

Relacionamento: Cooperativa. Tanto o cliente quanto o fornecedor têm um incentivo para que cada lançamento seja bem-sucedido, para que o financiamento adicional seja aprovado.

Dica: Os capitalistas de risco geralmente trabalham nessa base. Isso combina bem com tempo e materiais com escopo variável e um teto de custo.

É um trabalho muito prático quando utilizamos este modelo.

Nós simplesmente especificamos a meta de liberação, a taxa horária e o teto de custo no contrato comercial.

O cliente fornece o Product Owner.

Todo o resto é determinado nos contratos de sprint.

Contratos ágeis – Cláusulas de bônus / penalidade

agile-contracts-bonus-penalti3Estrutura: O fornecedor recebe um bônus se o projeto for concluído antecipadamente e pagar uma multa se chegar atrasado. A quantia de bônus ou penalidade é uma função do atraso

Escopo: Difíceis de aceitar, porque as mudanças potencialmente impactam a data de entrega, o que certamente não é permitido.

Risco: O cliente tem um incentivo para conclusão antecipada? Os argumentos do ROI devem ser convincentes e transparentes.

Caso contrário, o cliente obtém uma solução mais barata e mais demorada.

Relacionamento: Pode ser cooperativo, mas pode degenerar em indiferença se o cliente realmente não precisar do software até a data acordada.

Dica: Geralmente aplicado a projetos de construção, por exemplo estradas, túneis e pistas, para o qual funciona bem.

Mudanças no escopo não são problema e custos econômicos genuínos levam o cliente a cumprir o prazo também.

Contratos ágeis – Lucro Fixo

agile-contracts-lucro-fixo3Estrutura: Qualquer orçamento de projeto consiste em custos efetivos e lucro. As partes concordam com o lucro antecipadamente, por ex. R$ 100.000. Independentemente de quando o projeto é concluído, o contratado recebe os custos incorridos mais o lucro acordado.

Escopo: O escopo é fixo.

Risco: O risco é compartilhado. Se o projeto termina antes do previsto, o cliente paga menos, mas o fornecedor ainda tem seu lucro.

Se o projeto exceder o orçamento, o cliente paga mais, mas o fornecedor não obtém lucro adicional.

Após a data de entrega prevista, o fornecedor não poderá faturar mais nenhum lucro, apenas cobrir seus custos.

Relacionamento: Cooperativa – ambos têm um claro incentivo para terminar antes.

O cliente economiza dinheiro e o fornecedor tem uma margem de lucro maior.

Contratos ágeis – Dinheiro para nada, mudanças de graça

agile-contracts-money-nothing3Estrutura: Isso funciona com projetos de software ágil porque há pouco ou nenhum trabalho em andamento.

Após cada sprint, a funcionalidade está completa ou não iniciada. O trabalho baseia-se basicamente em uma base de tempo e materiais com uma meta de custo, geralmente com a intenção de que o projeto não use todo o orçamento do projeto.

Depois que uma certa quantidade de funcionalidade foi entregue, o cliente deve perceber que o valor de negócio suficiente foi percebido que o desenvolvimento adicional não é necessário e, portanto, pode cancelar o projeto.

Uma taxa de cancelamento igual ao lucro remanescente é devida.

Escopo: Pode ser alterado.

Recursos planejados, mas não implementados, podem ser substituídos por outras histórias do mesmo tamanho.

Recursos adicionais custam extra.

Risco: Compartilhado. Ambas as partes têm interesse em concluir o projeto cedo.

O cliente tem custos mais baixos, o fornecedor tem uma margem maior.

Dica: Se o orçamento for excedido, as regras dos contratos de teto fixo de custo ou custo fixo podem ser aplicadas. A abordagem de lucro fixo é mais consistente com o objetivo de promover um relacionamento cooperativo.

Contratos ágeis – Empreendimentos conjuntos/Joint Ventures

agile-contracts-joint-ventures3Estrutura: Dois parceiros investem em um produto de interesse comum.

É improvável que o dinheiro flua diretamente entre os parceiros na fase de desenvolvimento, mas cada parte deve ter um ROI, que pode vir da divisão de receita ou apenas se beneficia do uso do software.

Escopo: Definido para atender às necessidades da parceria.

Risco: Dois de tudo. Cadeias de decisão podem ficar longas.

Rivalidades podem se desenvolver entre as equipes.

Modelos diferentes para extrair valor do produto podem levar a diferentes prioridades que diferem pela vontade de investir.

Dica: Trate o projeto como uma empresa separada: uma equipe, colocalizada, com desenvolvimento e marketing de produto / papel do proprietário do produto.

Pense de maneira realista sobre cenários de separação amigáveis ​​e não tão amigáveis.

Conclusão

Um contrato estabelece as bases importantes para um projeto bem-sucedido. E o Manifesto Ágil acertou: trabalhar com o cliente é mais importante que o contrato.

Então faça o que fizer, mantenha o relacionamento com o cliente positivo!

Leitura adicional Jeff Sutherland – Money for nothing3. Um projeto de contrato está sendo desenvolvido pelo Agile Project Group, iniciado por Gerry Kirk.

Método XP (Extreme Programming)

O Extreme Programming é um dos métodos ágeis. É diferente pois é Leve, Reduz o risco,  Eficiente, Flexível, Antecipado,  Fácil,  E o mais importante, é uma maneira emocionante e divertida de desenvolver software.

Sumário

O que é o Extreme Programming?

Conforme Wikipedia – Extreme Programming (XP) é uma metodologia de desenvolvimento de software que visa melhorar a qualidade e a capacidade de resposta do software às mudanças nos requisitos do cliente.

Como um tipo de desenvolvimento ágil de software, defende frequentes “libera” em curtos ciclos de desenvolvimento, que visam melhorar a produtividade e introduzir pontos de verificação nos quais novos requisitos de clientes podem ser adotados.

Por que é chamado de “ Extreme? ”

Porque aumenta a eficiência e também garante a aplicação de princípios e valores de maneira extremamente eficaz. É feito por

  • Em primeiro lugar, revisar o código a cada passo de cada iteração para torná-lo mais eficaz
  • Em segundo lugar, fazendo testes de regressão em todas as etapas do desenvolvimento para tornar os testes mais eficazes.
  • Além do acima exposto, a reutilização diária de códigos torna o design mais eficaz.
  • Além disso, iterações curtas tornam a entrega mais eficaz.

A figura abaixo mostra como as fases e valores típicos de desenvolvimento de software foram levados ao seu nível extremo neste método de desenvolvimento.

XP Praticas

Kent Beck originalmente definiu Extreme Programming (XP) em 1996; no entanto, sua segunda versão tinha uma explicação dos princípios, lançados em 1999. O foco principal da Extreme Programming é satisfação do cliente, e suas equipes de desenvolvimento alcançam isso organizando-se.

Eles desenvolvem recursos quando o cliente precisa deles. Além disso, a Extreme Programming leva as melhores práticas do processo de desenvolvimento a um nível extremo. No mercado em rápida mudança de hoje, ele usa o método de iteração para se adaptar rapidamente aos novos requisitos. É uma maneira altamente disciplinada de fornecer continuamente software de alta qualidade mais rapidamente.

Além disso, o cliente está envolvido ativamente com a equipe para executar planejamento, testes e feedback rápidos contínuos para fornecer software de trabalho com frequência.

XP é um dos métodos mais populares. É leve porque

  • Em primeiro lugar, concentra-se em obter mais feedback, em vez de perguntar aos clientes antecipadamente sobre o que ele quer.
  • Em segundo lugar, ele agrega valor ao cliente em pequenas iterações ( 1 ou 2 semanas ).
  • Incentiva a mudança. Em outras palavras, ele tenta acomodar todas as alterações sugeridas pelo feedback do cliente, depois a redesenha, a recodifica e a reteste.
  • Além disso, tenta eliminar defeitos nos estágios iniciais, reduzindo assim o retrabalho e o custo.
  • Mantém o cliente envolvido durante todo o projeto.

Quando usar a Extreme Programming:

  • O aplicativo de Extreme Programming acontece nos projetos em que os requisitos continuam mudando.
  • Em alguns projetos críticos, mesmo antes de iniciar o projeto, os cronogramas são decididos. É referido como risco do projeto, pois é um desafio cumprir esses prazos. Portanto, a Extreme Programming também aborda o risco do projeto por ciclos de desenvolvimento frequentes e mais curtos e, consequentemente, permitindo feedback antecipado.
  • O XP é aplicado onde temos um pequeno grupo de programadores, não mais que 12.

Valores, Princípios e Práticas:

Valores XPValores

Existem cinco valores de Extreme Programming

1. Comunicação

A comunicação é a parte mais crucial de qualquer projeto. É necessária uma comunicação adequada para preencher as lacunas entre o que o desenvolvedor está fazendo e os requisitos do cliente. Ajudará a reduzir o retrabalho se soubermos a condição exata. Além disso, comunicação adequada dentro da equipe (os desenvolvedores) também é necessário para garantir que todos estejam na mesma página.

Por exemplo, digamos em um restaurante se um cliente diz especificamente ao garçom que ele quer que seu prato seja

  • Menos oleoso
  • levemente picante
  • Menos salgado devido a razões médicas.

Mas o garçom diz ao chef para tornar o prato menos picante. Depois disso, quando a refeição chega, ela é rejeitada pelo cliente, o motivo é; também tinha óleo e a quantidade usual de sal. E o chef teve que cozinhar novamente. Tudo porque não havia comunicação adequada entre o garçom e o chef.

2. Simplicidade

Precisamos começar a desenvolver os recursos mais diretos primeiro e, posteriormente, devemos passar para as funcionalidades problemáticas e extras. Deve ser simples, e devemos trabalhar na necessidade no momento. Além do acima exposto, não devemos nos preocupar com requisitos futuros e não devemos complicar, assumindo que esse recurso possa ser necessário posteriormente. Os desenvolvedores e testadores entenderão facilmente código e design simples.

Por exemplo, quando o chef tem vários pedidos, ele sempre começa com o que acha confortável e está confiante de que pode cozinhar bem.

Como, durante os exames, sempre fomos sugeridos por nossos idosos para começar com o que for mais simples.

3. Feedback

O feedback contínuo ajuda a entender o desempenho de você. Funciona como um catalisador para o projeto. Em Extreme Programming, o feedback pode vir de diferentes fontes, como

  • Cliente: Após cada iteração, uma função será entregue ao cliente que executará o teste de aceitação. Com base nos resultados dos testes de aceitação, os desenvolvedores recebem o feedback e trabalham com ele posteriormente.
  • Sistema: O principal motivo para realizar o teste da unidade é obter feedback. Ao escrever o teste da unidade ou realizar um teste de iteração, eles sabem do estado do sistema se há alguma falha na codificação.
  • Dentro da equipe: O objetivo de formar uma equipe é ajudar um ao outro e trabalhar como um. Sempre que o cliente vem com um novo requisito, ele pode fornecer feedback sobre a estimativa do tempo necessário e a criação de uma expectativa com base em suas experiências anteriores.

Por exemplo, desenvolvedores são como chefs em um restaurante. Eles devem estar prontos para aceitar feedback de todas as fontes da mesma maneira que um chef pode obter feedback do cliente, de seu chef sênior, do garçom ou da gerência..

4. Coragem

No desenvolvimento de software, coragem significa:

  • Em primeiro lugar, fornecer confiança aos desenvolvedores para tomar decisões corajosas, entendendo todos os aspectos envolvidos.
  • Em segundo lugar, confere confiança ao programador e permite que ele refacte ( reutilize ) o código usado, quando e quando necessário. Em outras palavras, o desenvolvedor analisa o código atual e o altera ou modifica para se adequar a fins futuros.
  • Além do acima, ele suporta os desenvolvedores líderes na decisão de fazer o restante dos desenvolvedores funcionar com mais eficiência. Por exemplo, quando um programador fica preso em um problema difícil por um dia inteiro, ele pode preferir fazer uma pausa e resolvê-lo rapidamente no dia seguinte. No entanto, só será possível se ele for persistente.

Por exemplo, em um restaurante, o chef é responsável por decidir os ingredientes, o tempo de cozinhar e o tempero. É o tipo de fé que a equipe mostra no chef e lhe dá coragem para tomar suas próprias decisões.

5. Respeito

No Extreme Programming, todos se respeitam.

  • O respeito é a base dos quatro valores.
  • Podemos ganhar respeito adotando acima os valores no sistema.
  • Além disso, esse valor é mais sobre o trabalho em equipe.
  • Em resumo, esse valor depende dos quatro valores acima.

Por exemplo, em um restaurante, todos têm seus papéis específicos e outros valores. Um chef respeitará e valorizará o que o garçom disser; o chef nunca voltará e verificará com o cliente se o garçom está certo ou não? Da mesma forma, o garçom, enquanto serve, nunca perguntará ao chef sobre o prato. O garçom respeitará a experiência e a habilidade do chef.

Princípios

Os princípios abaixo são aplicados durante todo o procedimento de Extreme Programming:

1. Feedback rápido:

Feedback rápido significa que o tempo entre o recebimento do feedback e a implementação no sistema deve ser mínimo.

  • Os desenvolvedores projetam, implementam e testam as funções. Consequentemente, o feedback é compartilhado imediatamente e é aplicado sem demora.
  • Além disso, o código também é revisado com o sistema e o feedback é compartilhado instantaneamente.

2. Suponha simplicidade:

Esse princípio sugere que os desenvolvedores devem tentar lidar com todos os problemas com simplicidade, como,

  • Um código desenvolvido deve refactar facilmente o ( reutilize após algumas modificações ) para realizar testes adicionais realizando testes de unidade.
  • Tente manter o código simples e siga a regra de “você não vai precisar”. Em outras palavras, significa que, se não precisamos agora, não devemos mantê-lo.
  • Não se repita“, os desenvolvedores seguem esse princípio. Ou seja; você não deve manter várias cópias do mesmo documento, código, tarefa ou qualquer coisa.

3. Mudança incremental:

Alterações incrementais significam “mudanças em pequenos passos”. A Extreme Programming suporta alterações incrementais. Significa em um momento apenas muito:

  • Pequenas mudanças no plano
  • Alterações mínimas em uma equipe
  • Pequenas mudanças no design

4. Abraçando a alteração:

É a abordagem que fala sobre adotar e considerar a maioria das mudanças, enquanto o problema real está sendo resolvido simultaneamente. Portanto, abraçando as conversas sobre mudanças

  • A capacidade de aceitar as alterações no seu trabalho atual.
  • Adaptar essas mudanças sem prejudicar seu trabalho.
  • Fornecer o mesmo desempenho na implementação dessas mudanças também.

5. Trabalho de qualidade:

Fornecer o produto da melhor qualidade é o principal motivo. Para esclarecer, a equipe precisa

  • Trabalhe em equipe
  • Aproveite seus papéis
  • Deve ser de suporte
  • Deve se sentir bem e focado em fornecer um produto de qualidade

Práticas

A Extreme Programming possui as seguintes áreas de práticas –

  • Feedback em escala fina
  • Processo contínuo
  • Compreensão compartilhada
  • Bem-estar do programador

XP Práticas

As Práticas do Extreme Programming

As 12 práticas de Extreme Programming atingem o objetivo de Extreme Programming. A fraqueza de qualquer um dos métodos é composta pela força de outras práticas.

Havia 24 práticas de XP, que mais tarde foram perfuradas por Kent Beck para 12 práticas primárias:

  1. O jogo de planejamento ( histórias de usuários )
  2. Pequenos lançamentos
  3. Metáfora
  4. Design simples
  5. Teste
  6. Refatoração
  7. Programação de pares
  8. Propriedade coletiva
  9. Integração Contínua
  10. Semana de trabalho de 40 horas
  11. Cliente no local
  12. Codificação

XP Atividades

A figura acima mostra a aplicação das práticas no Extreme Programming.

  • Como o uso de terminologias normais e a estrutura do sistema subjacente ( metáfora ), o cliente no local cria as histórias.
  • Como essas histórias são passadas para os desenvolvedores e, além disso, o desenvolvedor cria um jogo de planejamento baseado nas histórias do usuário e, finalmente, inicia o desenvolvimento de todas as funcionalidades em pequenas iterações.
  • Os recursos começam a ser lançados em pequenas iterações.
  • A cor verde escura representa todos os processos pelos quais cada iteração passa. Ou seja, cada funcionalidade, em cada iteração, passa pelo teste de aceitação.
  • A integração contínua usa os dados dos testes de aceitação. Junto com isso, a metáfora também usa esses resultados para esclarecer requisitos.
  • Os padrões contínuos de integração e codificação enfatizam a propriedade coletiva. Em outras palavras, se alguém estiver ausente ou não estiver disponível, o trabalho não deve parar.
  • Devido a requisitos precisos e linguagem fácil na metáfora, o design é simples.
  • O mesmo design também pode ser refatorado para qualquer outra função.
  • O teste da unidade é realizado após a conclusão do projeto.
  • Os resultados dos testes de unidade são usados para integração contínua. Além disso, se houver algum bug, a programação em pares poderá ser feita para resolvê-lo.
  • A solução da programação de pares pode ser documentada para referência futura, a fim de simplificar o design.
  • Além disso, os resultados também são usados na definição do padrão de codificação, para que o mesmo problema, na mesma situação, não ocorra novamente.
  • O padrão e a metáfora da codificação nos falam coletivamente sobre os padrões e a estrutura da organização com base nas práticas e resultados anteriores. E de acordo com isso na indústria de software, não se deve trabalhar mais de 40 horas por semana para trabalhar com eficiência.
  • Propriedade coletiva

As quatro áreas em que as práticas de Extreme Programming se enquadram são:

1. Feedback em escala fina

  • Teste:
    • O que é – Isso inclui todos os tipos de testes
      • Teste de unidade
      • Primeiro teste de projeto
      • Vários tipos de testes automatizados
      • Vantagens:
    • Em primeiro lugar, o teste de unidade é o teste final antes do teste do usuário. Indica que não é necessário mais design ou codificação.
      • Em segundo lugar, a refatoração do código acontece usando os resultados dos testes da unidade. Reduzirá o trabalho à medida que o código for reutilizado novamente.
      • Em terceiro lugar, o teste da unidade indica que o design é claro e não são necessárias mais modificações. Portanto, o desenvolvedor conhece seus objetivos de acordo com o design e sabe o que ele tem que desenvolver.
      • Além disso, a automação fornece uma série de testes de regressão que confirmam que o recurso / função testado está funcionando bem e não há efeito adverso disso.
  • Cliente no local
    • O que é isso?
    • Alguém que tem profundo conhecimento do projeto.
    • Desempenha papéis significativos durante o “Fase de direção ( a fase em que todas as alterações são feitas, discutida em detalhes posteriormente neste artigo ) ” do projeto.
    • Ele fornece feedback rápido, pontual e contínuo à equipe de desenvolvimento.
    • Vantagens:
      • Em primeiro lugar, todas as perguntas são respondidas naquele momento; sem necessidade de e-mail ou aprovações.
      • Em segundo lugar, os clientes podem garantir que o produto esteja se moldando de acordo com seus requisitos.
      • Além disso, eles podem priorizar novamente os requisitos.
  • Programação de pares
    • O que é isso?
      • Dois desenvolvedores compartilham uma estação de trabalho.
      • Eles usam seus cérebros para descobrir como fazer a codificação e como os outros codificarão.
      • Consequentemente, eles podem mudar de função, quando e quando necessário.
    • Vantagens:
      • Em primeiro lugar, dois cérebros sempre pensam melhor que um.
      • Em segundo lugar, eles trabalham com melhor concentração.
      • Além disso, duas pessoas podem debater e responder abaixo das perguntas de uma maneira melhor
        • Existe uma maneira de executar a tarefa de maneira mais simples?
        • Essa codificação como um todo vai funcionar?
        • Quais são os casos de teste que podem não funcionar e por quê?

2. Processo Contínuo

  • Integração Contínua
    • O que é isso?
      • Adicionando novos recursos ou alterações ao sistema sem demora.
      • Além disso, acontece a aplicação de pequenas integrações ( características adicionais ) às funcionalidades.
      • Para esclarecer, um desenvolvedor estará tirando uma cópia do código base atual e trabalhará para criar um código para alguns recursos diferentes. Da mesma forma, outro desenvolvedor estará trabalhando com a mesma base de código para codificar para outra função. É assim que o código é improvisado ( integrado ) se for usado por mais de um dia.
    • Vantagens:
      • Em primeiro lugar, torna o processo menos demorado.
      • Além disso, permite pequenos lançamentos de projetos.
  • Refatoração
    • O que é isso?
      • Processo de alteração do sistema de software para melhorar sua estrutura interna sem alterar o comportamento externo do código.
      • Reutilize o código antigo ( após o teste da unidade ) para codificar algumas outras funcionalidades.
    • Vantagens:
      • Em primeiro lugar, ajuda o desenvolvedor a melhorar o produto.
      • Em segundo lugar, permite brainstorming para encontrar diferentes maneiras e, portanto, promove a formação de equipes.
      • Além disso, aumenta o conhecimento do programador sobre o sistema.
  • Lançamentos curtos
    • O que é isso?
      • Funcionalidades entregues em pequenas porções.
      • Menor os recursos, mais rápido o lançamento.
      • Suporte “Jogo de planejamento”.
    • Vantagens:
      • Em primeiro lugar, promove uma liberação mais rápida e frequente.
      • Em segundo lugar, é fácil acompanhar o progresso.
      • Em terceiro lugar, reduz as chances de grandes erros.
      • Além do acima, reduz o retrabalho.

3. Entendimento compartilhado −

  • O jogo de planejamento
    • O que é isso?
      • Aprenda histórias de usuários para planejar.
      • Planeje o que será entregue na próxima iteração.
      • Uma pessoa técnica e experiente estimará o custo e o tempo.
      • O jogo Planejamento mostra a ligação entre o desenvolvedor e o customer.
    • Vantagens:
      • Em primeiro lugar, evita o desperdício de tempo no desenvolvimento de recursos desnecessários.
      • Em segundo lugar, é uma abordagem planejada, portanto, nenhuma adivinhação.
      • Além disso, todos estão cientes do progresso.
  • Design simples
    • O que é isso?
      • Mantendo o design o mais simples possível.
      • Além do acima, fazendo o mínimo suficiente para agregar valor ao sistema.
    • Vantagens:
      • Em primeiro lugar, economiza tempo, porque nenhum recurso adicional é trabalhado.
      • Em segundo lugar, é fácil de entender.
      • Finalmente, trata-se de propriedade coletiva e, portanto, a refatoração será fácil.
  • Metáfora
    • O que é isso?
      • A arquitetura verbal de todo o sistema. Em outras palavras, a metáfora define todo o sistema em seus termos técnicos e é compreensível apenas para aqueles que fazem parte do sistema.
      • Ele usa um conjunto padrão de condições.
      • As metáforas estão comandando ferramentas de ensino. Isso é para dizer; eles se acostumam em um grande número de áreas. Além disso, uma metáfora visa criar uma ponte de entendimento entre duas ou mais partes.
    • Vantagens:
      • Em primeiro lugar, inspira terminologias comuns.
      • Em segundo lugar, reduz o uso de jargões técnicos.
      • Além disso, é uma correção rápida e direta para entender o sistema.
  • Propriedade coletiva
    • O que é isso?
      • Fala sobre responsabilizar os desenvolvedores pelo que estão fazendo.
      • Em outras palavras, todos os desenvolvedores da equipe possuem todo o código.
      • Refatorar acontece.
    • Vantagens:
      • Em primeiro lugar, não há medo de alguém deixar a equipe, pois todos na equipe conhecem o código completamente.
      • Além disso, torna cada desenvolvedor responsável por cada código no sistema.
      • Além disso, torna o desenvolvedor responsável pelo sistema como um todo e, portanto, não sendo apenas uma parte do sistema.
  • Padrões de codificação
    • O que é isso?
      • Todo código deve seguir os mesmos padrões de codificação, que é uma decisão mútua do desenvolvedor líder e do cliente no momento do planejamento.
      • Além disso, apenas o líder deve saber quem projetou qual código para que a equipe trabalhe em equipe e não como indivíduos.
    • Vantagens:
      • Em primeiro lugar, mantém todos na mesma página, pois todos seguirão os mesmos padrões de codificação predefinidos.
      • Em segundo lugar, será fácil encontrar brechas ( se houver ), pois qualquer coisa que não atenda às regras de codificação padrão não será adequada.
    • Além disso, diminui o tempo que o desenvolvedor leva para codificar, pois ele conhece o conjunto de regras a seguir.
    • Finalmente, a codificação será clara e inconfundível.

4. Bem-estar do desenvolvedor / programador −

  • Semana 40 horas
    • O que é isso?
      • Limitação do horário de trabalho a 40 horas em uma semana.
      • Nenhuma hora extra promovida porque é um sintoma de um problema.
      • Além disso, trabalhar mais de 40 horas por semana não será adequado a longo prazo.
    • Vantagens:
      • Em primeiro lugar, menos horas de trabalho mantêm o desenvolvedor ativo.
      • Ao mesmo tempo, eles trabalham com mais eficiência.
      • Além disso, mantém o desenvolvedor livre de estresse e saudável .

Artefatos XP

Dois artefatos principais no XP são

  • Cartões de história
  • Cartões de tarefas

Outros artefatos importantes da Extreme Programming são os seguintes

  • Testes de aceitação
  • Estimativas
    • Plano de liberação
    • Plano de iteração
  • Design
  • Casos de teste de unidade
  • Registros de comunicação

Cartões de história

Uma história de usuário não passa de um documento que descreve os requisitos do usuário. As estruturas dos cartões de história do usuário têm os seguintes recursos:

  • O cliente projeta ou grava um cartão de usuário.
  • Descreve o sistema do ponto de vista do cliente.
  • Um cartão de usuário é uma linguagem simples e pouco técnica. Em outras palavras, o cliente usa seus termos para explicar o requisito.
  • Um cartão de usuário deve ser detalhado o suficiente para que o desenvolvedor possa estimar quanto tempo levará para que uma história específica seja projetada, testada e implementada.
  • Uma descrição do recurso requer um cartão de usuário no sistema. Em outras palavras, um cartão de usuário para cada requisito.
  • As estimativas para a entrega do recurso são feitas usando os cartões de histórias do usuário.

Cartões de tarefas

A Cartão de Tarefas é criado pela equipe de desenvolvimento para implementar a tarefa de maneira organizada. Ele terá os seguintes detalhes da tarefa em relação a uma história específica do usuário.

  • A lista de tarefas necessárias para a implementação de uma História de Usuário é chamada de Cartão de Tarefas.
  • Além disso, apenas um cartão de tarefa é projetado e emitido contra uma história de usuário.
  • eualém disso, o Cartões de tarefa trabalhar como base para tarefas e fornecer uma estimativa para concluir uma tarefa.

Testes de aceitação:

O desempenho dos testes de aceitação ocorre para garantir que todas as histórias do usuário sejam adequadamente compreendidas e implementadas. A equipe de testadores faz esses testes.

Estimativas:

Existem duas fases, onde a avaliação da tarefa, a estimativa de tempo e a estimativa de esforço acontecem.

Abaixo estão as duas fases de estimativa e seu planejamento.

  • Planejamento de Liberação– Nesta fase, a decisão de cada recurso ( iteração ) do “Plano de liberação” ocorre juntamente com a estimativa da duração da entrega e do número de pessoas / esforços necessários. A seguir, estão as razões para esta estimativa:
    • Primeiro, para descobrir a data completa de lançamento do objetivo do projeto, executada na fase de exploração.
    • Segundo, para descobrir se algum tempo ou ajuste da força de trabalho é planejado na fase de direção.
  • Plano de Liberação – Plano de liberação é o plano documentado que terá os detalhes de −
    • As histórias de usuários que foram selecionadas pela equipe de desenvolvimento para lançamento.
    • Estimativas do tempo necessário e dos esforços necessários.
    • A data que foi confirmada como a data de lançamento.
  • Estimativas – Planejamento de Iteração – Na mesma linha do planejamento de liberações, aqui nesta fase, acontece a avaliação das estimativas das tarefas relacionadas ao esforço e duração. Além disso, essa avaliação é usada para atribuir as tarefas no planejamento da iteração e equilibrar uma carga de trabalho por recurso na fase de compromisso.
  • Plano de Iteração – O projeto é dividido em pequenas iterações e cada iteração terá os planos de iteração. O plano de iteração tem os seguintes detalhes:
    • As histórias do usuário selecionadas para essa iteração específica.
    • Tarefas atribuídas e os detalhes da pessoa a quem é atribuída.
    • Uma estimativa, quando a tarefa for concluída.

Design

O desenvolvedor desenvolve o design referindo-se à história do usuário. O desenvolvedor requer esse design para a implementação da história do usuário.

Casos de teste de unidade

Após o design, o desenvolvedor faz a codificação, seguida pelo teste da unidade.

Para testes de unidade –o caso de teste da unidade é preparado pelo desenvolvedor para garantir que o recurso específico ( unit ) esteja funcionando conforme o esperado. O teste da unidade é um teste escrito pelo desenvolvedor para qualquer funcionalidade específica. Além disso, o caso de teste da unidade leva à codificação e teste da unidade para qualquer tarefa. Em resumo, é o primeiro passo no nível de testes e feito antes Teste de integração.

Registros de comunicação do cliente e do desenvolvedor:

Todas as atividades são baseadas nas histórias.

  • A história do usuário é a comunicação do usuário para um desenvolvedor.
  • O cartão de tarefa é a comunicação dentro da equipe.

Portanto, ambas as histórias são documentadas com base na comunicação entre clientes e desenvolvedores ou dentro da equipe.

Como o XP não suporta documentação desnecessária,

  • Se não for necessário – a comunicação pode ser verbal.
  • Se necessário – a documentação pode acontecer posteriormente.

Quais são as diferentes atividades da Extreme Programming?

Existem quatro atividades principais da Extreme Programming. Eles são:

  • Codificação
  • Teste
  • Ouvindo
  • *Projetando

Codificação

Antes de codificar, trata-se de coletar os requisitos e projetar conforme os requisitos. No entanto, uma vez que o design e o teste acontecem, a codificação é iniciada.

Uma equipe de desenvolvedores ou programadores fará a codificação.

Teste:

O teste é de dois tipos, a saber, Manual e Automatizado. Aqui neste método, o teste manual é realizado.

A equipe de testadores realiza testes manuais e, posteriormente, os resultados dos testes serão publicados.

  • Se os resultados do teste forem positivos, podemos prosseguir com o processo de liberação.
  • No entanto, se não, o testador precisa aumentar o defeito, classificá-lo e testá-lo novamente.

Ouvindo:

Como o desenvolvedor saberia o que deve ser codificado por ele e testado pelo testador? Ouvir permite que você entenda seu trabalho.

Testadores e desenvolvedores são uma parte crítica do sistema. Portanto, ambos precisam ser um ouvinte ativo para entender o progresso atual e as próximas etapas.

Projetando:

Manter todas as três atividades no design de uma página acontece. Em outras palavras, coloca todas as três atividades sob um guarda-chuva.

Fases de programação

O desempenho de todas as atividades acima ocorre em diferentes fases do desenvolvimento. Essas diferentes fases da programação são −

  • Planejamento de Liberação
  • Planejamento de Iteração
  • Implementação

Planejamento de lançamento

Nesta fase, planejamos o próximo lançamento. As histórias do usuário e a data de lançamento subsequente projetam isso. O planejamento da versão será feito pelo cliente e desenvolvedores mutuamente em três fases.

  • Fase de Exploração
  • Fase de Compromisso
  • Fase de Direção

Planejamento de liberação – Fase de exploração:

Em primeiro lugar, a fase de Exploração é a fase de coleta de requisitos e descoberta do impacto desse requisito no projeto e, portanto, enquadrá-los em uma história de usuário. A seguir, estão as etapas para isso:

  • Crie uma história:

Os clientes enfrentam alguns problemas e abordam o desenvolvedor com um problema e explicam sua pergunta ao desenvolvedor*.

  • Posteriormente, o cliente e o desenvolvedor discutem o problema e compreendem os aspectos técnicos dele.
  • Além disso, o desenvolvedor deve ajudar os clientes a entender os termos técnicos e não deve influenciar os requisitos do cliente.
  • Por fim, os clientes documentam o problema e fornecem um cartão de história formalmente documentado para suas perguntas.
  • O cartão de história do usuário deve ser documentado apenas pelo cliente e, posteriormente, o desenvolvedor o obtém.
  • Em resumo, no cartão de história do usuário, os clientes chamarão seus requisitos e termos exatos.
  • Estime uma história: Os desenvolvedores farão esta parte. Eles estimarão quanto tempo levará para implementar o trabalho mencionado no cartão de história do usuário. Além disso, eles podem analisar e preparar um layout para resolver o problema, para que todos tenham uma idéia clara sobre o problema e sua solução. Esta solução não deve influenciar os requisitos comerciais ou “Cartão de história do usuário“.
  • Divida uma história: Antes de passar para a próxima fase, que é “Planejamento de Iteração”, precisamos projetar complexidades críticas primeiro. Se o desenvolvedor não conseguir estimar a história do usuário, ele deverá dividi-la ainda mais e escrever / explicar novamente.

Funções usadas nesta fase: Cliente e Desenvolvedor

Artefatos utilizados: Cartão de história do usuário

Importante: A escuta ativa é crucial nesta fase para:

  • Atenda adequadamente aos requisitos do cliente
  • Entenda o cartão de história do usuário
  • Explique um cartão de história para a equipe de desenvolvimento
  • Ganhe clareza
  • Evite incerteza
  • Expresse-se claramente no caso de interrupções de entendimento.

Fase de compromisso do planejamento de lançamento:

A segunda fase é conhecida como fase de compromisso, porque envolve a resolução de:

  • Funcionalidades desejadas
  • Custo estimado
  • Impacto nos negócios
  • Lucro e
  • Data de lançamento

O cliente e o desenvolvedor resolverão isso com base em quatro componentes:

  • Classificar por valor: O cliente classificará as histórias do usuário de acordo com os valores comerciais pelo cliente.
  • Por velocidade: Os desenvolvedores tentam descobrir a que velocidade eles podem executar e entregar o projeto.
  • Classificar por risco: O desenvolvedor classificará as histórias com base no risco.
  • Escolhendo o escopo: Finalmente, as histórias do usuário com uma data de lançamento serão coletadas primeiro para garantir que sejam entregues a tempo. Em outras palavras, as histórias de usuários que terminarem primeiro no próximo lançamento serão retomadas mais cedo.

Funções usadas nesta fase: Cliente e Desenvolvedor

Artefatos utilizados: Cartão de história do usuário

Importante: A escuta ativa também é essencial aqui, devido aos seguintes motivos −

  • Primeiro, o desenvolvedor precisa ter um entendimento claro da funcionalidade exigida na versão atual.
  • Além disso, é essencial estimar os esforços e a duração necessários para a entrega dessa funcionalidade.
  • Além disso, o cliente e o desenvolvedor poderão entender e decidir se é possível cumprir a data de lançamento comprometida ou não..

Fase de direção do planejamento de liberação:

Finalmente, chega a fase de direção, que também é conhecida como fase de mudança. Os requisitos de novas mudanças acontecem nesta fase.  Em outras palavras, tudo acontece nesta fase, como adicionar um novo recurso, remover ou alterar um recurso existente etc.

Na fase de direção, o cliente pode solicitar ao desenvolvedor que “boi” o processo

  • Como, traga mudanças nas histórias do usuário.
  • Priorizar as histórias de diferentes usuários ( alterando a prioridade ).
  • Ajuste o plano de liberação em caso de estimativas incorretamente estabelecidas.
  • Para acomodar as alterações sugeridas pelo usuário.

Funções usadas nesta fase: Cliente e Desenvolvedor

Artefatos utilizados: Cartão de história do usuário

Importante: Como todas as fases, a escuta ativa também é essencial nesta fase. É importante:

  • Entenda a adição dos novos requisitos.
  • Compreender as alterações necessárias para as necessidades atuais.
  • Analise o que precisa ser removido e o impacto subsequente da remoção no sistema existente.
  • Conhecer o trabalho realizado até agora.

Planejamento de Iteração:

Nesta fase, não há envolvimento do cliente. Isso é para dizer; os desenvolvedores planejarão as atividades e tarefas para iteração.

O planejamento de iteração tem três fases

  • Fase de exploração.
  • Fase de compromisso.
  • Fase de direção.

Planejamento de iteração – Fase de exploração:

Na fase de exploração,

  • Várias tarefas obtêm a interpretação dos requisitos.
  • O cartão de tarefa registra todas as tarefas.
  • Além do acima, o desenvolvedor fará uma estimativa do tempo de implementação da tarefa.
  • Finalmente, trabalhos muito pequenos ou muito grandes são combinados / divididos para obter uma estimativa.

Funções: Desenvolvedores

Artefatos: Cartão de tarefa

Planejamento de iteração – fase de compromisso:

Na fase de compromisso,

  • O desenvolvedor recebe as tarefas.
  • O desenvolvedor reconhece a responsabilidade da tarefa atribuída.
  • Além disso, o desenvolvedor fornece uma estimativa do tempo necessário para a conclusão da tarefa.
  • Finalmente, o tempo estimado e a comparação de trabalho ocorrem quando toda a carga ( de trabalho ) ocorre entre os programadores.

Funções:  Desenvolvedores

Artefatos: Cartão de tarefa

Planejamento de iteração – Fase de direção:

Na fase de direção,

  • O desenvolvedor entende o cartão de tarefa da tarefa executada.
  • A equipe do desenvolvedor executa a tarefa usando as técnicas de programação do Pair.

Funções:  Desenvolvedores

Artefato: Cartão de tarefa

Implementação:

A implementação acontece durante a fase de direção da iteração. As atividades que se enquadram nisso são-

  • Projete a tarefa: O desenvolvedor começa a trabalhar no trabalho escrito no cartão de tarefa e, posteriormente, começa a projetar conforme o cartão.
  • Escreva um teste de unidade: O programador primeiro grava um teste automatizado conhecido como teste de unidade, antes da codificação real.
  • Escreva o código: O programador começa a codificar.
  • Executar teste:  Os testes de unidade são executados para verificação de código.
  • Refatoração: Isso significa reutilizar o código com algumas pequenas alterações.
  • Execute testes funcionais: Testes integrados e testes de aceitação do usuário estão sob este.

Papel: Desenvolvedores

Funções e responsabilidades extremas:

Na Extreme Programming, três funções são muito críticas e vitais. Da mesma forma, existem outros papéis também, mas eles trabalham sob eles. Esses papéis principais são-

Cliente:

O cliente é quem decide e transmite todo o requisito. Na Extreme Programming, o cliente deve estar em contato contínuo com os desenvolvedores. Além disso, o cliente pode ser

  • Uma comunidade específica
  • Um grupo de partes interessadas
    • Uma equipe com o membro que inclui
    • Gerentes de produtos
    • Membros de vendas e marketing
    • Usuários e gerentes finais
    • Analista de Negócios
    • Operações

O cliente será responsável pelo seguinte

  • Escrevendo histórias de usuários
  • Testando as funções finais entregues pelos desenvolvedores e escrevendo um teste funcional
  • Definindo prioridades
  • Explicando histórias para o desenvolvedor
  • Decidir se ele se encaixa no requisito do usuário final
  • Decidindo perguntas sobre as histórias

Programador:

Desenvolvedor ou programador deve ser um comunicador eficaz, porque ele é o único canal de comunicação entre a equipe de desenvolvimento, a equipe de testes e o cliente. Um desenvolvedor terá o direito de fazer o seguinte

  • Realizar conhecimento de requisitos
  • Produzir trabalho de qualidade
  • Gerenciamento de abordagem para obter ajuda, que inclui seus supervisores hieráticos e o cliente
  • Desenvolver e alterar as estimativas fornecidas
  • Seja responsável

As principais responsabilidades de um programador são

  • Primeiro, para entender e estimar histórias de usuários.
  • Segundo, definir e estimar tarefas com base na história do usuário.
  • Terceiro, para escrever um teste de unidade.
  • Além disso, para gravar código para passar no teste da unidade.
  • Posteriormente, para realizar o teste da unidade.
  • Refatorar
  • Finalmente, para integrar e tentar melhorar continuamente.

Treinador:

O papel de um treinador é significativo na Extreme Programming. Um treinador garante que todos estejam trabalhando para fazer a programação para uma Extreme Programming. O treinador deveria ter

  • Comportamento sutil para ser treinador, mesmo que todos os outros estejam em pânico
  • Excelente conhecimento da Extreme Programming
  • Natureza útil, porque ele tem que observar todos e, consequentemente, ajudar.

As responsabilidades de um treinador incluem

  • Observando todas as atividades e certificando-se de que todo o projeto permaneça no caminho certo.
  • Ele estará ajudando a equipe com qualquer coisa relacionada ao projeto.
  • Responsável por descobrir as práticas extremas de programação que ajudam a resolver quaisquer problemas no projeto.
  • Além do acima, ele garante que a equipe seja auto-suficiente.
  • Ele estará observando todas as equipes silenciosamente.
  • Se surgir algum problema, ele pode envolver ou formar qualquer equipe destinada a ajudar.

Alguns outros papéis são:

Testador:

O testador será quem fará o teste após a codificação. As responsabilidades de um testador incluem –

  • Implementando todos os testes funcionais (, exceto o teste de unidade )
  • Gráficos de todos os resultados
  • Informar o cliente e o desenvolvedor quando os resultados do teste não forem possíveis

Rastreador:

O rastreador será a pessoa que garantirá que todos estejam fazendo seu trabalho corretamente, incluindo o desenvolvedor. As responsabilidades de um rastreador incluem:

  • Organizar reuniões do desenvolvedor com os clientes quando e quando necessário.
  • Monitorando o progresso do desenvolvedor.
  • Além disso, marcar uma reunião de equipe e agir se as coisas não estiverem indo tão comprometidas.
  • Entre em contato com o treinador ou o programador para obter ajuda ( se necessário ).

Doomsayer:

Como o nome sugere, o portador será quem ficará de olho em qualquer desastre. Esses desastres podem ser como não cumprindo cronogramas, um bug devido a um pequeno erro, questões de infra-estrutura, ou algo que possa impactar o projeto de qualquer maneira. Em outras palavras, o portador tentará que nada dê errado. As responsabilidades do porteiro incluem:

  • Prever o risco, se houver
  • Garantir que todos os envolvidos nos projetos conheçam o risco envolvido
  • Manter a transparência de qualquer notícia má
  • Certifique-se de que todos estejam cientes do impacto, urgência e fatores / atividades que serão afetados.

Gerente:

O gerente é quem passará os relatórios e rastreadores para o progresso do processo. Ele será responsável perante o Proprietário de ouro em caso de problemas (O proprietário do ouro é alguém que financiará o projeto pelo lado do cliente). As responsabilidades de um gerente são as seguintes:

  • Em primeiro lugar, para garantir que a equipe de Desenvolvimento, assim como o cliente, conheça adequadamente a explicação do Jogo de Planejamento.
  • Em segundo lugar, observar o Jogo de Planejamento e modificar regras, quando e quando necessário.
  • Terceiro, para garantir a identificação e rastreamento dos defeitos.
  • Além disso, para verificar o rastreamento do tempo de resolução e do tempo gasto por cada equipe no defeito.
  • Além disso, obtenha todas as informações sem perturbar o trabalho atual da equipe.
  • Por fim, participar das reuniões dos clientes e acompanhar todas as informações úteis discutidas na reunião.

Fases do Extreme Programming

XP Fases

Esta figura nos fala sobre o fluxo da Extreme Programming, em Extreme Programming primeiro.

  • Inicialmente, os requisitos do usuário são coletados em o cartão da história do usuário.
  • Posteriormente, o cartão de história do usuário faz o planejamento de iteração. Tempo e esforço estimativas acontecer em Planejamento de iteração.
  • O desenvolvimento sábio da iteração processo começa após o planejamento.
  • Além disso, a incorporação de novos requisitos acontecem durante o desenvolvimento.
  • Além disso, quaisquer alterações necessárias durante teste de iteração estão incluídos apenas nesta fase. Além disso, a adição de Novos requisitos do usuário também acontece nesta fase apenas.
  • Após testes bem-sucedidos de iteração, ele será desenvolvido UAT ( Teste de aceitação do usuário ).
  • Depois disso, se os defeitos aumentará, em caso de bugs; voltará na fase de desenvolvimento.
  • Finalmente, se não houver bugs – Lançamento final, Acabamentos de treinamento do usuário e suporte ao produto fornecido.

Foi um fluxo de programação extremo. Isso nos leva à questão de quantas fases existem no fluxo de trabalho de programação extremo? Existem 6 fases no fluxo de processo da Extreme Programming.

Essas 6 fases são as seguintes:

Planejamento:

  • Identificação de investidores
  • Reconhecendo as necessidades de infraestrutura
  • Estabelecendo necessidades de segurança
  • Contrato de nível de serviço de assinatura ( i. e um documento formal que fala sobre a prestação de vários serviços ) com todas as restrições.

Análise

  • Obtendo histórias de usuários do cliente
  • Analisando histórias de usuários
  • Priorizando histórias
  • Matrizes para estimativas
  • Definindo iteração, por exemplo, qual iteração fornece todas as funcionalidades.
  • Planejamento para equipes de teste e desenvolvimento

Design

  • Projeto para a primeira iteração
  • Preparando um caso de teste para cada tarefa
  • Estrutura de automação de regressão

Execução

  • O desenvolvedor fará a codificação.
  • Após a codificação dos acabamentos, o controle de qualidade realiza o teste de unidade.
  • Depois disso, o teste manual acontece.
  • Relatório de defeitos gera ( se os defeitos aumentarem ).
  • A conversão dos casos de teste de regressão Manual para Automação acontece.
  • Revisão de média iteração
  • Revisão do final da iteração

Embrulho

  • Liberação de iteração acontece
  • O teste de regressão ocorre
  • O cliente recebe as demos e as revisa
  • Posteriormente, se necessário, o cliente desenvolve uma nova história após o teste.
  • Finalmente, após a revisão da iteração, os planos de melhoria serão preparados com base no feedback.

Encerramento

  • Treinamento para o usuário final fornecido
  • Lançamento da produção acontece
  • Além disso, o desempenho de várias verificações acontece se o desenvolvedor tiver cumprido o SLA.
  • Finalmente, o suporte à produção é fornecido para o produto desenvolvido.

Agora que entendemos a Extreme Programming, vamos analisar as principais diferenças entre a Extreme Programming e o Scrum.

Diferenças entre Extreme Programming e Scrum

Extreme Programming Scrum
Um sprint é concluído em 2-10 dias Um sprint leva duas semanas a 6 semanas para ser concluído
A Extreme Programming permite alterações no sprint em qualquer estágio do desenvolvimento Por outro lado, em Scrum, quando a reunião de planejamento do sprint terminar e a entrega acontecer, nenhuma alteração poderá ocorrer no sprint.
Os desenvolvedores começam a trabalhar de acordo com a prioridade dada pelos usuários. Os desenvolvedores decidem a prioridade e, posteriormente, começam a se desenvolver.
O XP possui práticas como TDD, Programação de pares, refatoração etc., que são obrigatórias a seguir Não recomenda nenhuma prática de engenharia

Por que Extreme pode falhar

  • Na Extreme Programming, o código ganha importância sobre o design. No entanto, é o design que vende o aplicativo e não o código. Quando os programadores se concentram no código e no design difere um pouco, o produto final pode deixar o cliente insatisfeito. Portanto, para evitar isso, os desenvolvedores precisam se concentrar no design e no código.
  • A Extreme Programming aceita mudanças em qualquer estágio. Por outro lado, essas alterações não são documentadas adequadamente. Por exemplo, se houver alguma falha na implementação, encontrar seu motivo será extremamente difícil devido à falta de documentação. Portanto, é imperativo ter documentação adequada para cada alteração, a fim de evitar erros.
  • Além disso, a Extreme Programming limita a gama de projetos porque requer interação cara a cara com projetos XP. Isso é ainda mais desafiador de implementar se o cliente se afastar do local de desenvolvimento.

Conclusão

Para concluir, a Extreme Programming é uma estrutura ágil de desenvolvimento de software. Melhora a qualidade e a capacidade de resposta do software aos requisitos em constante mudança do cliente. Além disso, favorece frequentes “libera” para melhorar a produtividade.