Category Archives: Agile

Lean no Desenvolvimento de Software

Agile No Comments
Mary e Tom Poppendieck (gurus de Lean voltado a TI, defensores do agile e autores do livro: “Lean Software Development – An Agile Toolkit” que mostra como os princípios Lean podem ser aplicados em abordagens de desenvolvimento de software ágil) usou a seguinte frase para definir Lean:
“What is Lean?

•  Deliver continually increasing customer value
•  Expending continually decreasing effort
•  In the shortest possible timeframe
•  With the highest possible quality
A journey, not a destination. ”

E acrescentam:  “Acelerar a produção do desenvolvimento de Software é geralmente uma questão de melhorar o processo ao invés de adicionar pessoas. Pare de fazer coisas que o cliente não valoriza! Vista os óculos do cliente! ”

Tentando resumir em uma frase, Lean é um princípio ágil cujo foco é cortar a “gordura” do processo de software, focando na eliminação de desperdícios.

Princípios Lean aplicados ao software:

  1.    Elimine Desperdícios
  2.    Inclua a Qualidade no Processo
  3.    Crie Conhecimento
  4.    Adie Decisões e Comprometimentos
  5.    Entregue o quanto antes
  6.    Respeite as Pessoas e “Empower” a equipe
  7.    Otimize o Todo

Vamos ver os 7 princípios de Lean e como transforma-los em práticas ágeis.

Princípio #1 – Eliminar desperdícios
Desperdícios: tudo aquilo que não agrega valor para cliente final e que não são percebidos pelo cliente. Exemplo: passos extras, processo pesado e rígido, burocracia, documentação que nunca vai ser lida, que está na prateleira juntando poeira – não necessária, etc. Outro tipo de desperdício são trabalhos parcialmente prontos, tudo que começa e não termina, funcionalidades extras que não serão utilizadas, etc.image

  1. Enfim, software útil e de funcionando (de qualidade) é o que vai trazer valor ao cliente. Os sete desperdícios de software:
  2. Inventory = Requirements / Partially done work
  3. Extra Processing Steps = Extra processes, steps
  4. Overproduction = Extra features
  5. Transportation = Handoffs, tasks switching
  6. Waiting = Waiting
  7. Defects = Defects
  8. Motion = Finding Information
Não se iluda, embora alguns sejam gritantes não é fácil identificar alguns tipos de desperdício. É preciso aprender a enxergar os desperdícios e existem algumas práticas e exercícios que podem ajudar, tais como: Seeing waste e Value Stream mapping.
Vejamos os tipos de desperdícios mais detalhadamente:
1 – Requisitos
Requisitos, especificados muito cedo que perdem sua credibilidade, eficácia e compromete a usabilidade do sistema.
Trabalho incompleto (“em-progresso”) – Parcialmente feitos
Trabalhos parcialmente iniciados / terminados tendem a se tornar obsoletos.
O maior problema é não ter idéia se eventualmente funcionam ou não. Enquanto os trabalhos não são integrados, não podem ser utilizados e não temos como saber quais problemas podem aparecer. Funcionalidades pela metade apenas atravancam o caminho para trabalhos que poderiam ser feitos. Tornando-se facilmente obsoleto.
Consomem recursos sem trazer retorno.
Exemplos: Documentação não codificada, código não sincronizado, código não testado, código não implantado.
2 – Processos/Passos a mais
Burocracia, atividades, métricas, etc que não geram valor e que diminui o tempo de resposta.
Você alguma vez já se perguntou, toda aquela documentação e papelada é realmente necessária?
Documentação desnecessária e documentação que são esquecidos ou perdem valor e se tornam obsoletos ou documentos que ninguém se importa em ler.
O seu cliente realmente acha que isso torna o produto dele mais eficiente?
Dica: Faça esse questionamento para descobrir quando a documentação tem valor agregado : Tem alguém esperando ou dependendo do que você esta produzindo?.
Ainda assim lembre-se: Mantenha-o enxuto, em alto-nível e documente o mais tardar possível.
3 – Funcionalidades a mais
80% das funcionalidades implementadas não são utilizadas.
20% das funcionalidades é que são realmente úteis.
Código não-utilizado introduz complexidade e a complexidade é um inimigo da manutenção. Mais código para ser mantido. Mais testes para serem realizados. Mais documentos de especificação para serem criados. Se o código não é necessário agora colocá-lo no sistema é desperdício.
4 – Troca de tarefas (Task switching, Handoffs)
Corrida de revezamento deve ser substituída pela equipe multi-funcional.
Quanto maior os handoff’s maior é a perda de conhecimento. Organizar pessoas em múltiplos projetos é outra forma de desperdício.
Quanto tempo se perde para parar uma determinada atividade e iniciar outra, relembrar onde parou, concentrar-se e finalmente produzir algo?
5 – Atrasos
Atrasos na entrega, atrasos em geral são puro desperdício e irão gerar aumento do custo do projeto.
Em muitos casos, atrasos são apenas a ponta do iceberg para problemas muito maiores.
Espera: Um dos maiores desperdícios no desenvolvimento de Software é a espera para que as coisas aconteçam. Espera para o início do projeto, pela montagem da equipe, espera pela produção de documentação extensa, espera por processo de revisão ou aprovação, espera para testar, etc.  Veja, analise o que deve ser mantido, o que agrega valor e o que é puro despedício.
6 – Defeitos
Equipes ágeis se esforçam ao máximo para evitar defeitos.
 “Inspecionar para prevenir defeitos é bom;
Inspecionar para encontrar defeitos é desperdício” — Shigeo Shingo
Defeitos (Bugs) não agregam valor, não satisfazem o cliente, e custam muito muito caro.
7 – Movimento
Tempo e esforço gasto para encontrar informações.
Equipes ágeis valorizam a conversa e por isso trazem o cliente para perto, não devemos perder tempo lendo páginas e páginas de um documento para encontrar uma informação que ao mesmo tempo por estar na forma escrita muitas vezes são imprecisas e pode trazer mais dúvidas do que resolver o problema.
Princípio #2 – Qualidade embutida
Qualidade é inegociável. Entregue qualidade intrínseca e explícita aos seus clientes, se eles perceberem isso, significa que foi uma entrega de qualidade. Mary e Tom Poppendieck em seu livro identificaram duas dimensões de integridade: integridade percebida e integridade conceitual. A integridade percebida significa que a totalidade do produto alcança um equilíbrio entre as funções, usabilidade, confiabilidade, economia e isso encanta o cliente. A integridade conceitual significa que os conceitos centrais do sistema de trabalho em conjunto são facilitados e coesos. Essa última é fator crítico de sucesso para a integridade percebida.
Um produto possui integridade percebida quando o cliente o experimenta e diz: Isso! Era exatamente isso que eu queria! Software com integridade possui boas arquiteturas, possuem um alto nível de usabilidade e facilidade de uso, são fáceis de dar manutenção, de adaptar e de estender.
Dicas:
  • Não verificar a qualidade só no final, verificar durante todo processo e também toda equipe testa!
  • Quanto antes um problema é verificado mais barato ficará
  • Foco na prevenção, não na verificação no final do processo – Ao invés de se esforçar para gerenciar defeitos, evite-os.
  • “Logar” defeitos é desperdício, corrija-os imediatamente.
Práticas sugeridas para promover a qualidade:
  • 4 quadrantes de teste
  • TDD  – Test Driven Development
  • Refactoring
  • Integração contínua
  • Code review / code inspection
  • Standards
  • Testes contínuos e automatizados
Princípio #3 – Criar conhecimentos
Desenvolvimento é um exercício de descoberta, enquanto produção é um exercício de reduzir a variação. Desenvolvimento é como fazer uma nova receita, enquanto produção é como fazer um prato. Receitas são formuladas por chefes de cozinha experientes que de certa forma desenvolveram habilidades e capacidade de combinar os ingredientes disponíveis para produzir o prato desejado. Desenvolver uma receita é um processo de descoberta, até os chefes mais experientes produzem diversas variações de um novo prato, fazem iterações, experimentações, até encontrar a melhor combinação de ingredientes que resulte em um prato rápido e sabor agradável. Não se espera que os chefes obtenham uma receita perfeita de primeira; espera-se produzir diversas variações como parte do processo de aprendizagem. Desenvolvimento de software é melhor concebido se este fizer parte de um processo de aprendizado similar ao de criar uma nova receita. A melhor abordagem para melhorar o ambiente de desenvolvimento de software é pela expansão do conhecimento.
Práticas sugeridas para promover o conhecimento:
  • Ciclos de feedback e inspeções e adaptações;
  • Desenvolvimento iterativo;
  • Equipes pequenas e cross-functional;
  • Treinamentos e Mentoring;
  • Criação e utilização de standards, guidelines e qualquer outro artefato;
  • Code Reviews;
  • Meios de compartilhamento de informações como um Blog ou Wiki;
Princípio #4 – Adiar decisões / compromissos
O principal conceito deste princípio é diminuir as incertezas retardando as decisões até que possam serem feitas com base em acontecimentos mais firmes, previsíveis e conhecidos. Decisões tardias tendem a ser mais acertadas porque as melhores decisões são feitas baseadas em fatos, e não em suposições ou especulações. Uma estratégia chave para adiar decisões/comprometimentos quando desenvolvendo um sistema complexo e com muitas incertas é usar a capacidade e práticas que permitam abraçar as mudanças tardiamente.
Práticas sugeridas para adiar compromissos:
  • Iterações
  • Planning meetings
  • Behaviour/Feature Driven Development
  • Outros
Princípio #5 – Entregar rápido
Sem entregas rápidas não é possível colher feedback. Sem entregas rápidas não é possível aprender com erros. Velocidade na entrega garante que o cliente receberá o que ele precisa hoje e não o que ele precisava ontem.
Práticas sugeridas:
Princípio #6 – Respeitar as pessoas
Envolver os desenvolvedores nos detalhes das decisões técnicas é fundamental para o atingimento da exelência.
Dicas:
  • Um ambiente que favoreça o desenvolvimento das pessoas.
  • Uma empresa que respeita as pessoas, assim as pessoas irão respeitar a empresa
O Software produzido é como um espelho da equipe de desenvolvimento.
Para que as pessoas possam assumir responsabilidades, se sentir motivados e atuar como uma equipe eles precisam de confiança e de respeito.

Práticas sugeridas para promover o empowering do time:

  • Auto-gestão
  • Trabalho em equipe
  • feedback
 

Princípio #7 – Otimizar o todo

Otimizar desde o começo até o final:
  • Utilize Métricas
  • Diminua o número de métricas de desempenho individual mas valorize o desempenho da equipe.
  • Meça para cima:
  • Tempo de ciclo +Mapa de Fluxo de Valor
  • ROI + Modelo de Lucros e Perdas
  • Satisfação do Cliente + Entendimento das suas necessidades
Para tornar o seu processo ágil, pense Lean!
Mas lembre-se Lean requer uma mudança da cultura e dos hábitos organizacionais para que esta possa usufruir das melhorias de performance que um processo enxuto pode proporcionar.
É UMA MUDANÇA DE MENTALIDADE E COMPORTAMENTO !

Scrum

Agile No Comments

Introdução

Scrum (subs): Um framework dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível.

Scrum é:
• Leve
• Simples de entender
• Difícil de dominar

Scrum é um framework estrutural que está sendo usado para gerenciar o trabalho em produtos complexos desde o início de 1990. Scrum não é um processo, técnica ou um método definitivo. Em vez disso, é um framework dentro do qual você pode empregar vários processos ou técnicas. O Scrum deixa claro a eficácia relativa de suas práticas de gerenciamento de produto e técnicas de trabalho, de modo que você possa continuamente melhorar o produto, o time e o ambiente de trabalho.

O framework Scrum consiste de times Scrum associados a papéis, eventos, artefatos e regras. Cada componente dentro do framework serve a um propósito específico e é essencial para o uso e sucesso do Scrum.

As regras do Scrum integram os papéis, eventos e artefatos, administrando as relações e interações entre eles. As regras do Scrum são descritas ao longo deste documento.

Estratégias específicas para o uso do framework Scrum variam e são descritas em outros documentos.

O Time Scrum

Product Owner

O Product Owner, ou dono do produto, é o responsável por maximizar o valor do produto resultado do trabalho do Time de Desenvolvimento. Como isso é feito pode variar amplamente através das organizações, Times Scrum e indivíduos.

O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto. O gerenciamento do Backlog do Produto inclui:
• Expressar claramente os itens do Backlog do Produto;
• Ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões;
• Otimizar o valor do trabalho que o Time de Desenvolvimento realiza;
• Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e mostrar o que o Time Scrum vai trabalhar a seguir; e,
• Garantir que o Time de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário.

O Product Owner pode fazer o trabalho acima, ou delegar para o Time de Desenvolvimento fazê-lo. No entanto, o Product Owner continua sendo o responsável pelos trabalhos.

O Product Owner é uma pessoa e não um comitê. O Product Owner pode representar o desejo de um comitê no Backlog do Produto, mas aqueles que quiserem uma alteração nas prioridades dos itens de Backlog devem endereçar ao Product Owner.

Para que o Product Owner tenha sucesso, toda a organização deve respeitar as decisões dele(a). As decisões do Product Owner são visíveis no conteúdo e na priorização do Backlog do Produto. Ninguém pode forçar o Time de Desenvolvimento a trabalhar em um diferente conjunto de requerimentos.

O Time de Desenvolvimento

O Time de Desenvolvimento consiste de profissionais que realizam o trabalho de entregar um incremento potencialmente liberável do produto “Pronto” ao final de cada Sprint. Um incremento “Pronto” é requerido na Revisão da Sprint. Somente integrantes do Time de Desenvolvimento criam incrementos.

Os Times de Desenvolvimento são estruturados e autorizados pela organização para organizar e gerenciar seu próprio trabalho. A sinergia resultante aperfeiçoa a eficiência e a eficácia do Time de Desenvolvimento como um todo.

Os Times de Desenvolvimento tem as seguintes características:
• Eles são auto-organizados. Ninguém (nem mesmo o Scrum Master) diz ao Time de Desenvolvimento como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente liberável;
• Times de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias, enquanto equipe, para criar o incremento do Produto.
• O Scrum não reconhece títulos para os integrantes do Time de Desenvolvimento, independentemente do trabalho que está sendo realizado pela pessoa;
• O Scrum não reconhece sub-times no Time de Desenvolvimento, independente dos domínios de conhecimento que precisam ser abordados, tais como teste, arquitetura, operação ou análise de negócios; e,
• Individualmente os integrantes do Time de Desenvolvimento podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence ao Time de Desenvolvimento como um todo;

Tamanho do time

O tamanho ideal do Time de Desenvolvimento é pequeno o suficiente para se manter ágil e grande o suficiente para completar um trabalho significativo dentro da Sprint. Menos de três integrantes no Time de Desenvolvimento diminuem a interação e resultam em um menor ganho de produtividade. Times de desenvolvimento menores podem encontrar restrições de habilidades durante a Sprint, gerando um Time de Desenvolvimento incapaz de entregar um
incremento potencialmente liberável. Havendo mais de nove integrantes é exigida muita coordenação. Times de Desenvolvimento grandes geram muita complexidade para que um processo empírico seja útil. Os papéis de Product Owner e de Scrum Master não são incluídos nesta contagem, a menos que eles também executem o trabalho do Backlog da Sprint.

O Scrum Master

O Scrum Master é responsável por promover e suportar o Scrum como definido no Guia Scrum. O Scrum Master faz isso ajudando todos a entenderem a teoria, as práticas, as regras e os valores do Scrum.

O Scrum Master é um servo-líder para o Time Scrum. O Scrum Master ajuda aqueles que estão fora do Time Scrum a entender quais as suas interações com o Time Scrum são úteis e quais não são. O Scrum Master ajuda todos a mudarem estas interações para maximizar o valor
criado pelo Time Scrum.

O Scrum Master trabalhando para o Product Owner

O Scrum Master serve o Product Owner de várias maneiras, incluindo:
• Garantindo que objetivos, escopo e domínio do produto sejam entendidos o melhor possível por todos do Time Scrum
• Encontrando técnicas para o gerenciamento efetivo do Backlog do Produto;
• Ajudando o Time Scrum a entender as necessidades para ter items de Backlog do Produto claros e concisos.
• Compreendendo o planejamento do Produto em um ambiente empírico;
• Garantindo que o Product Owner saiba como organizar o Backlog do Produto para maximar valor;
• Compreender e praticar a agilidade; e,
• Facilitar os eventos Scrum conforme exigidos ou necessários.

O Scrum Master trabalhando para o Time de Desenvolvimento

O Scrum Master serve o Time de Desenvolvimento de várias maneiras, incluindo:
• Treinando o Time de Desenvolvimento em autogerenciamento e interdisciplinaridade;
• Ajudando o Time de Desenvolvimento na criação de produtos de alto valor;
• Removendo impedimentos para o progresso do Time de Desenvolvimento;
• Facilitando os eventos Scrum conforme exigidos ou necessários; e,
• Treinando o Time de Desenvolvimento em ambientes organizacionais nos quais o Scrum não é totalmente adotado e compreendido.

O Scrum Master trabalhando para a Organização

O Scrum Master serve a Organização de várias maneiras, incluindo:
• Liderando e treinando a organização na adoção do Scrum;
• Planejando implementações Scrum dentro da organização;
• Ajudando funcionários e partes interessadas a compreender e tornar aplicável o Scrum e o desenvolvimento de produto empírico;
• Causando mudanças que aumentam a produtividade do Time Scrum; e,
• Trabalhando com outros Scrum Masters para aumentar a eficácia da aplicação do Scrum na organização.

Eventos Scrum

Sprint

O coração do Scrum é a Sprint, um time-boxed de um mês ou menos, durante o qual um “Pronto”, incremento de produto potencialmente liberável é criado. Sprints tem durações consistentes ao longo de todo o esforço de desenvolvimento. Uma nova Sprint inicia imediatamente após a conclusão da Sprint anterior.
As Sprints contém e consistem de um planejamento da Sprint, reuniões diárias, o trabalho de desenvolvimento, uma revisão da Sprint e uma retrospectiva da Sprint.

Durante a Sprint:
• Não são feitas mudanças que possam por em perigo o objetivo da Sprint;
• As metas de qualidade não diminuem; e,
• O escopo pode ser clarificado e renegociado entre o Product Owner e o Time de Desenvolvimento quanto mais for aprendido.

Cada Sprint pode ser considerada um projeto com horizonte não maior que um mês. Como os projetos, as Sprints são utilizadas para realizar algo. Cada Sprint tem uma meta do que é para ser construído, um plano previsto e flexível que irá guiar a construção, o trabalho e o produto resultante do incremento.

Sprints são limitadas a um mês corrido. Quando o horizonte da Sprint é muito longo, a definição do que será construído pode mudar, a complexidade pode aumentar e o risco pode crescer. Sprints permitem previsibilidade que garante a inspeção e adaptação do progresso em direção à meta pelo menos a cada mês corrido. Sprints também limitam o risco ao custo de um mês corrido.

Cancelamento da Sprint

Uma Sprint pode ser cancelada antes do time-boxed da Sprint terminar. Somente o Product Owner tem a autoridade para cancelar a Sprint, embora ele (ou ela) possa fazer isso sob influência das partes interessadas, do Time de Desenvolvimento ou do Scrum Master.

A Sprint poderá ser cancelada se o objetivo da Sprint se tornar obsoleto. Isto pode ocorrer se a organização mudar sua direção ou se as condições do mercado ou das tecnologias mudarem. Geralmente a Sprint deve ser cancelada se ela não faz mais sentido às dadas circunstâncias. No entanto, devido a curta duração da Sprint, raramente cancelamentos fazem sentido.

Quando a Sprint é cancelada, qualquer item de Backlog do Produto completado e “Pronto” é revisado. Se uma parte do trabalho estiver potencialmente liberável, tipicamente o Product Owner o aceita. Todos os itens de Backlog do Produto incompletos são reestimados e colocados de volta no Backlog do Produto. O trabalho feito se deprecia rapidamente e deve ser frequentemente reestimado.

O cancelamento de Sprints consome recursos, já que todos se reagrupam em outro planejamento da Sprint para iniciar outra Sprint. Cancelamentos de Sprints são frequentemente traumáticos para o Time Scrum, e são muito incomuns.

Planejamento da Sprint

O trabalho a ser realizado na Sprint é planejado durante o planejamento da Sprint. Este plano é criado com o trabalho colaborativo de todo o Time Scrum.

O Planejamento da Sprint é um um time-boxed com no máximo oito horas para uma Sprint de um mês de duração. Para Sprints menores, este evento é usualmente menor. O Scrum Master garante que o evento ocorra e que os participantes entendam seu propósito. O Scrum Master ensina o Time Scrum a manter-se dentro dos limites do time-box.

O planejamento da Sprint responde as seguintes questões:
• O que pode ser entregue como resultado do incremento da próxima Sprint?
• Como o trabalho necessário para entregar o incremento será realizado?

Definição de Pronto na Sprint

O Time de Desenvolvimento trabalha para prever as funcionalidades que serão desenvolvidas durante a Sprint. O Product Owner debate o objetivo que a Sprint deve realizar e os itens de Backlog do Produto que, se completados na Sprint, atingirão o objetivo da Sprint. Todo o Time Scrum colabora com o entendimento do trabalho da Sprint.

A entrada desta reunião é o Backlog do Produto, o mais recente incremento do produto, a capacidade projetada do Time de Desenvolvimento durante a Sprint e o desempenho passado do Time de Desenvolvimento. O número de itens selecionados do Backlog do Produto para a Sprint é o único trabalho do Time de Desenvolvimento. Somente o Time de Desenvolvimento pode avaliar o que pode ser completado ao longo da próxima Sprint.

Durante o Planejamento da Sprint, o Time Scrum também determina a meta da Sprint. A meta da Sprint é o objetivo que será satisfeito dentro da Sprint através da implementação do Backlog do Produto, e que fornece a orientação para o Time de Desenvolvimento sobre o porquê dele estar construindo o incremento.

Como o trabalho será Pronto?

Tendo definido o objetivo da Sprint e selecionado os itens de Backlog do Produto da Sprint, o Time de Desenvolvimento decide como irá construir essas funcionalidades durante a Sprint e transformá-las em um incremento de produto “Pronto”. Os itens de Backlog do Produto selecionados para a Sprint, junto com o plano de entrega destes itens é chamado de Backlog da Sprint.

O Time de Desenvolvimento frequentemente inicia o desenho do sistema e do trabalho necessário para converter o Backlog do Produto em um incremento funcional do produto. O trabalho pode ser de vários tamanhos ou esforços. Contudo, o trabalho suficiente é planejado durante o planejamento da Sprint pelo Time de Desenvolvimento para prever o que este acredita que poderá fazer durante a próxima Sprint. O trabalho planejado pelo Time de Desenvolvimento para os primeiros dias da Sprint é decomposto até o final desta reunião, frequentemente em unidades de um dia de duração ou menos. O Time de Desenvolvimento se auto-organiza para realizar todo o trabalho do Backlog da Sprint, tanto durante o planejamento da Sprint quanto no que for necessário durante a Sprint.

O Product Owner pode ajudar a clarificar os itens de Backlog do Produto selecionados e nas decisões conflituosas de troca. Se o Time de Desenvolvimento determina que tem excesso ou falta de trabalho, os itens do Backlog da Sprint podem ser renegociados com o Product Owner.

O Time de Desenvolvimento também pode convidar outras pessoas para participar desta reunião para fornecer opinião técnica ou de domínios específicos.

No final do planejamento da Sprint, o Time de Desenvolvimento deve ser capaz de explicar ao Product Owner e ao Scrum Master como pretende trabalhar como equipe auto-organizada para completar o objetivo da Sprint e criar o incremento previsto.

Meta da Sprint

A meta da Sprint é um objetivo definido para a Sprint que pode ser satisfeito através da implementação do Backlog do Produto. Este fornece uma direção para o Time de Desenvolvimento sobre o porquê de estar construindo o incremento. Este é criado durante a reunião de planejamento da Sprint. O objetivo da Sprint dá ao Time de Desenvolvimento alguma flexibilidade a respeito da funcionalidade que será completada dentro da Sprint. Os itens do Backlog do Produto selecionados entregam uma função coerente, que pode ser o objetivo da Sprint. O objetivo da Sprint pode ser qualquer outro coerente que faça o Time de Desenvolvimento trabalhar em conjunto em vez de em iniciativas separadas.

Conforme o Time de Desenvolvimento trabalha, eles mantêm o objetivo da Sprint em mente. A fim de satisfazer o objetivo da Sprint, implementando funcionalidade e tecnologia. Caso o trabalho acabe por ser diferente do esperado pelo Time de Desenvolvimento, então eles colaboram com o Product Owner para negociar o escopo do Backlog da Sprint dentro da Sprint.

Daily Meeting

A Reunião Diária do Scrum é um evento time-boxed de 15 minutos para o Time de Desenvolvimento. A Reunião Diária é realizada em todos os dias da Sprint. Nela o Time de Desenvolvimento planeja o trabalho para as próximas 24 horas. Isso otimiza a colaboração e a performance do time através da inspeção do trabalho desde a última Reunião Diária, e da previsão do próximo trabalho da Sprint. A Reunião Diária é mantida no mesmo horário e local todo dia para reduzir a complexidade.

O Time de Desenvolvimento usa a Reunião Diária para inspecionar o progresso em direção ao objetivo da Sprint e para inspecionar se o progresso tende na direção de completar o trabalho do Backlog da Sprint. A Reunião Diária aumenta a probabilidade do Time de Desenvolvimento atingir o objetivo da Sprint. Todos os dias, o Time de Desenvolvimento deve entender como o mesmo pretende trabalhar em conjunto, como um time auto-organizado, para completar o objetivo da Sprint e criar o incremento previsto até o final da Sprint.

A estrutura da reunião é definida pelo Time de Desenvolvimento e pode ser conduzida de diferentes formas desde que estas foquem no progresso em direção à Meta da Sprint. Alguns Times de Desenvolvimento utilizarão perguntas, outros se basearão em discussões. Aqui segue um exemplo do que pode ser utilizado:
• O que eu fiz ontem que ajudou o Time de Desenvolvimento a atingir a meta da Sprint?
• O que eu farei hoje para ajudar o Time de Desenvolvimento atingir a meta da Sprint?
• Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no atingimento da meta da Sprint?
O Time de Desenvolvimento ou membros da equipe frequentemente se encontram imediatamente após a Reunião Diária para discussões detalhadas, ou para adaptar, ou replanejar, o restante do trabalho da Sprint.

O Scrum Master assegura que o Time de Desenvolvimento tenha a reunião, mas o Time de Desenvolvimento é responsável por conduzir a Reunião Diária. O Scrum Master ensina o Time de Desenvolvimento a manter a Reunião Diária dentro do time-box de 15 minutos.

A Reunião Diária é uma reunião interna do Time de Desenvolvimento. Se outros estiverem presentes, o Scrum Master deve garantir que eles não perturbem a reunião. Reuniões Diárias melhoram as comunicações, eliminam outras reuniões, identificam e removem impedimentos para o desenvolvimento, destacam e promovem rápidas tomadas de decisão, e melhoram o nível de conhecimento do Time de Desenvolvimento. Esta é uma reunião chave para inspeção e adaptação.

Review Sprint

A Revisão da Sprint é realizada no final da Sprint para inspecionar o incremento e adaptar o Backlog do Produto se necessário. Durante a Revisão da Sprint o Time Scrum e as partes interessadas colaboram sobre o que foi feito na Sprint. Com base nisso e em qualquer mudança no Backlog do Produto durante a Sprint, os participantes colaboram nas próximas coisas que podem ser feitas para otimizar valor. Esta é uma reunião informal, não uma reunião de status, e a apresentação do incremento destina-se a motivar e obter feedback e promover a colaboração.

Esta é uma reunião de no máximo 4 horas de duração para uma Sprint de um mês. Para Sprints menores, este evento é usualmente menor. O Scrum Master garante que o evento ocorra e que os participantes entendam o seu propósito. O Scrum Master ensina todos os envolvidos a manter a reunião dentro do Time-box.

A Revisão da Sprint inclui os seguintes elementos:
• Os participantes incluem o Time Scrum e os Stakeholders chaves convidados pelo Product Owner;
• O Product Owner esclarece quais itens do Backlog do Produto foram “Prontos” e quais não foram “Prontos”;
• O Time de Desenvolvimento discute o que foi bem durante a Sprint, quais problemas ocorreram dentro da Sprint, e como estes problemas foram resolvidos;
• O Time de Desenvolvimento demonstra o trabalho que está “Pronto” e responde as questões sobre o incremento;
• O Product Owner discute o Backlog do Produto tal como está. Ele (ou ela) projeta os prováveis alvos e datas de entrega baseado no progresso até a data (se necessário);
• O grupo todo colabora sobre o que fazer a seguir, e é assim que a Revisão da Sprint fornece valiosas entradas para o Planejamento da Sprint subsequente;
• Revisão de como o mercado ou o uso potencial do produto pode ter mudado e o que é a coisa mais importante a se fazer a seguir; e,
• Revisão da linha do tempo, orçamento, potenciais capacidades, e mercado para a próxima versão esperada de funcionalidade ou de capacidade do produto.

O resultado da Revisão da Sprint é um Backlog do Produto revisado que define os prováveis Itens de Backlog do Produto para a próxima Sprint. O Backlog do Produto pode também ser ajustado completamente para atender novas oportunidades.

Retrospective Sprint

A Retrospectiva da Sprint é uma oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na próxima Sprint.

A Retrospectiva da Sprint ocorre depois da Revisão da Sprint e antes do planejamento da próxima Sprint. Esta é uma reunião de no máximo três horas para uma Sprint de um mês. Para Sprint menores, este evento é usualmente menor. O Scrum Master garante que o evento ocorra e que os participantes entendam seu propósito.

O Scrum Master garante que o evento seja positivo e produtivo. O Scrum Master ensina todos a manter o evento dentro do time-box. O Scrum Master participa da reunião como um membro auxiliar do time devido a sua responsabilidade pelo processo Scrum.

O propósito da Retrospectiva da Sprint é:
• Inspecionar como a última Sprint foi em relação às pessoas, aos relacionamentos, aos
processos e às ferramentas;
• Identificar e ordenar os principais itens que foram bem e as potenciais melhorias; e,
• Criar um plano para implementar melhorias no modo que o Time Scrum faz seu trabalho;

O Scrum Master encoraja o Time Scrum a melhorar, dentro do processo do framework do Scrum, seu processo de desenvolvimento e suas práticas para torná-lo mais efetivo e agradável para a próxima Sprint. Durante cada Retrospectiva da Sprint, o Time Scrum planeja formas de aumentar a qualidade do produto melhorando o processo de trabalho ou adaptando a definição de “Pronto”, se apropriado e sem entrar em conflito com os padrões do produto ou
organização.

Ao final da Retrospectiva da Sprint, o Time Scrum deverá ter identificado melhorias que serão implementadas na próxima Sprint. A implementação destas melhorias na próxima Sprint é a forma de adaptação à inspeção que o Time Scrum faz a si próprio. Apesar de que melhorias podem ser implementadas a qualquer momento, a Retrospectiva da Sprint fornece uma oportunidade formal focada em inspeção e adaptação.

Artefatos do Scrum

Product Backlog

O Backlog do Produto é uma lista ordenada de tudo que é conhecido ser necessário no produto. É a única origem dos requisitos para qualquer mudança a ser feita no produto. O Product Owner é responsável pelo Backlog do Produto, incluindo seu conteúdo, disponibilidade e ordenação.
Um Backlog do Produto nunca está completo. Os primeiros desenvolvimentos estabelecem os requisitos inicialmente conhecidos e melhor entendidos. O Backlog do Produto evolui tanto quanto o produto e o ambiente no qual ele será utilizado evoluem. O Backlog do Produto é dinâmico; mudando constantemente para identificar o que o produto necessita para ser mais apropriado, competitivo e útil. Se um produto existe, seu Backlog do Produto também existe.

O Backlog do Produto lista todas as características, funções, requisitos, melhorias e correções que formam as mudanças que devem ser feitas no produto nas futuras versões. Os itens do Backlog do Produto possuem os atributos de descrição, ordem, estimativa e valor. Os itens do Backlog geralmente incluem descrições de testes que comprovarão sua completude quando “Prontos”.

Enquanto um produto é usado e ganha valor, e o mercado fornece feedback, o Backlog do Produto torna-se uma lista maior e mais completa. Requisitos nunca param de mudar, então o Backlog do Produto é um artefato vivo. Mudanças nos requisitos de negócio, condições de mercado ou tecnologia podem causar mudanças no Backlog do Produto.

Múltiplos Times Scrum frequentemente trabalham juntos no mesmo produto. Um Backlog do Produto é usado para descrever o trabalho previsto para o produto. Um atributo do Backlog do Produto que agrupe itens pode ser então aplicado.

O refinamento do Backlog do Produto é a ação de adicionar detalhes, estimativas e ordem aos itens no Backlog do Produto. Este é um processo contínuo no qual o Product Owner e o Time de Desenvolvimento colaboram nos detalhes dos itens do Backlog do Produto. Durante o refinamento do Backlog do Produto, os itens são inspecionados e revisados. O Time de Scrum decide como e quando o refinamento está “Pronto”. Este refinamento usualmente não consome mais de 10% da capacidade do Time de Desenvolvimento. Contudo, os itens do Backlog do Produto podem ser atualizados a qualquer momento pelo Product Owner ou a critério do Product Owner.

Os itens do Backlog do Produto de ordem mais alta (topo da lista) devem ser mais claros e mais detalhados que os itens de ordem mais baixa. Estimativas mais precisas são feitas baseadas em maior clareza e maior detalhamento; Quanto menor a ordem na lista, menos detalhes. Os itens do Backlog do Produto que irão ocupar o Time de Desenvolvimento na próxima Sprint são mais refinados, de modo que todos os itens possam ser “Prontos” dentro do time-boxed da Sprint. Os itens do Backlog do Produto que podem ser “Prontos” pelo Time de Desenvolvimento dentro de uma Sprint são considerados “Preparados” para seleção no Planejamento da Sprint. Itens do Backlog do Produto geralmente adquirem este grau de transparência através das atividades de refinamento descritas acima.

O Time de Desenvolvimento é responsável por todas as estimativas. O Product Owner deve influenciar o Time de Desenvolvimento, ajudando no entendimento e nas decisões conflituosas de troca, mas as pessoas que irão realizar o trabalho fazem a estimativa final.

Monitorando o progresso

Em qualquer ponto do tempo, o total do trabalho restante para alcançar o objetivo pode ser somado. O Product Owner acompanha o total do trabalho restante pelo menos a cada Revisão da Sprint. O Product Owner compara este valor com o trabalho restante nas Revisões das Sprints anteriores, para avaliar o progresso na direção de completar o trabalho previsto pelo tempo desejado para alcançar o objetivo. Esta informação deve ser transparente para todas as partes interessadas.

Várias práticas para prever tendências foram usadas para prever o progresso, tais como burndowns, burn-ups, ou fluxos cumulativos. Estas tem se provado úteis. Contudo, não substituem a importância do empirismo. Em ambientes complexos, o que acontecerá é desconhecido.
Somente o que já acorreu pode ser usado para uma tomada de decisão a respeito do que virá.

Sprint Backlog

O Backlog da Sprint é um conjunto de itens do Backlog do Produto selecionados para a Sprint, juntamente com o plano para entregar o incremento do produto e atingir o objetivo da Sprint.

O Backlog da Sprint é a previsão do Time de Desenvolvimento sobre qual funcionalidade estará no próximo incremento e sobre o trabalho necessário para entregar essa funcionalidade em um incremento “Pronto”.

O Backlog da Sprint torna visível todo o trabalho que o Time de Desenvolvimento identifica como necessário para atingir o objetivo da Sprint. Para garantir melhoria contínua, é incluído no mínimo um item de prioridade alta sobre melhoria do processo identificado na última Reunião de Retrospectiva.

O Backlog da Sprint é um plano com detalhes suficientes que as mudanças no progresso sejam entendidas durante a Reunião Diária. O Time de Desenvolvimento modifica o Backlog da Sprint ao longo de toda a Sprint, e o Backlog da Sprint vai surgindo durante a Sprint. Este surgimento ocorre quando o Time de Desenvolvimento trabalha segundo o plano e aprende mais sobre o trabalho necessário para atingir o objetivo da Sprint.

Sempre que um novo trabalho é necessário, o Time de Desenvolvimento adiciona este ao Backlog da Sprint. Conforme o trabalho é realizado ou completado, a estimativa do trabalho restante é atualizada. Quando elementos do plano são considerados desnecessários, eles são removidos. Somente o Time de Desenvolvimento pode alterar o Backlog da Sprint durante a Sprint. O Backlog da Sprint é altamente visível, uma imagem em tempo real do trabalho que o Time de Desenvolvimento planeja completar durante a Sprint, e que pertence exclusivamente ao Time de Desenvolvimento.

Monitoramento do progresso da Sprint

Em qualquer ponto do tempo na Sprint, o total do trabalho remanescente dos itens do Backlog da Sprint pode ser somado. O Time de Desenvolvimento monitora o total do trabalho restante pelo menos a cada Reunião Diária para projetar a probabilidade de alcançar o objetivo da Sprint. Ao acompanhar o trabalho restante ao longo de toda a Sprint, o Time de Desenvolvimento pode gerenciar o seu progresso.

Incremento

O incremento é a soma de todos os itens do Backlog do Produto completados durante a Sprint e o valor dos incrementos de todas as Sprints anteriores. Ao final da Sprint um novo incremento deve estar “Pronto”, o que significa que deve estar na condição de ser utilizado e atender a definição de “Pronto” do Time Scrum. Um incremento é uma parte principal inspecionável de trabalho pronto que suporta empirismo no final da sprint. O incremento é um passo na direção de uma visão ou de um objetivo. O incremento deve estar na condição de ser utilizado independente do Product Owner decidir por liberá-lo ou não.

Transparência do Artefato

Scrum invoca transparência. Decisões para otimizar o valor e o controle de riscos são feitos com base na percepção existente do estado dos artefatos. Na medida em que a transparência é plena, estas decisões tem uma base sólida. Na medida em que os artefatos não são completamente transparentes, estas decisões podem ser falhas, valores podem diminuir e riscos podem aumentar.

O Scrum Master deve trabalhar com o Product Owner, Time de Desenvolvimento, e outras partes envolvidas para entender se os artefatos estão plenamente transparentes. Há práticas para lidar com transparência incompleta, o Scrum Master deve ajudar todos a aplicar a mais apropriada prática na falta de uma transparência plena. O Scrum Master pode detectar transparência incompleta pela inspeção dos artefatos, percebendo padrões, ouvindo atentamente o que está sendo dito, e detectando diferenças entre o esperado e os resultados reais.

O trabalho do Scrum Master é trabalhar com o Time Scrum e com a organização para aumentar a transparência dos artefatos. Este trabalho geralmente envolve aprendizagem, convencimento e mudança. Transparência não ocorre de um dia para o outro, mas é um caminho.

Definição de Pronto

Quando um item do Backlog do Produto ou um incremento é descrito como “Pronto”, todos devem entender o que o “Pronto” significa. Embora, isso possa variar por Time Scrum, os integrantes devem ter um entendimento compartilhado do que significa o trabalho estar completo, assegurando a transparência. Esta é a “Definição de Pronto” para o Time Scrum e é usado para assegurar quando o trabalho esta completado no incremento do produto.

A mesma definição orienta o Time de Desenvolvimento no conhecimento de quantos itens do Backlog do Produto podem ser selecionados durante o Planejamento da Sprint. O propósito de cada Sprint é entregar incrementos de funcionalidades potencialmente liberáveis que aderem à definição atual de “Pronto” do Time Scrum.

O Time de Desenvolvimento entrega um incremento de funcionalidade do produto a cada Sprint. Este incremento é utilizável, então o Product Owner pode escolher por liberá-lo imediatamente. Se a definição de “Pronto” para um incremento é parte das convenções, padrões ou diretrizes de desenvolvimento da organização, todos os Times Scrum devem seguila como um mínimo.

Se “Pronto” para um incremento não é uma convenção de desenvolvimento da organização, o Time de Desenvolvimento do Time Scrum deve definir uma definição de “pronto” apropriada para o produto. Se há múltiplos Times Scrum trabalhando no sistema ou versão do produto, os Times de Desenvolvimento de todos os Times Scrum devem mutuamente definir uma definição de “Pronto”.

Cada incremento é adicionado a todos os incrementos anteriores e completamente testado, garantindo que todos os incrementos funcionam juntos.
Como um Time Scrum maduro, é esperado que a sua definição de “Pronto” seja expandida para incluir critérios mais rigorosos de alta qualidade. Novas definições, quando usadas, podem descobrir trabalho a ser feito em incrementos “Prontos” anteriormente. Qualquer produto ou sistema deve ter uma definição de “Pronto” que é um padrão para qualquer trabalho feito sobre ele.