Scrum

Criar uma Definição de Pronto ou DoD "Definition of Done" é um esforço colaborativo entre o Scrum Master, o ScrumTeam e o Product Owner.

Serve como um contrato entre o ScrumTeam e o Product Owner, garantindo que todo o produto gerado pelo projeto estará dentro dos padrões de qualidade estabelecidos entre eles. É uma forma de se buscar a excelência, especialmente em um cenário multi-iterativo.

O documento de DoD pode evoluir normalmente ao longo do projeto, porém recomendo que a primeira versão seja criada durante a 1ª Sessão de Sprint Planning, isto é, antes de iniciar o 1º Sprint do projeto.

É imperativo que a DoD seja revisitada a cada Sprint. Um momento que pode ser útil para verificar se a DoD está sendo adequada é o Sprint Review, afinal, se o produto apresentar qualquer “Desvio de Caráter”, a probabilidade da culpa ser de uma DoD mal definida é altíssima.

Benefícios de se utilizar DoD são:

O ScrumTeam e os demais stakeholders do projeto passam a utilizar um vocabulário único, seguro e irrestrito para a palavra 'Pronto'. Depois da DoD todo mundo entende o que significa (E o trabalho que isso dá).

A confiança dos demais stakeholders aumenta em relação ao ScrumTeam

Os Releases passam a ser mais previsíveis em termos de qualidade (Aquele susto ao final do projeto deixa de existir)

Qualquer impedimento é rapidamente identificado, tornado público e sobrepujado.

Os membros de toda a equipe passam a compreender melhor as expectativas de entrega do Projeto e trabalham para cuidar que o produto seja entregue com toda qualidade.

Os membros da equipe aprendem um novo jeito de se entregar produtos e nunca mais desejarão trabalhar de outro modo.

A Melhoria contínua passa a ser a cultura do projeto.

Transparência

Aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados. A transparência requer que estes aspectos tenham uma definição padrão comum para que os observadores compartilharem um mesmo entendimento comum do que está sendo visto.

Inspeção

Os usuários Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso em direção ao objetivo da Sprint para detectar variações indesejadas.

Adaptação

Se um inspetor determina que um ou mais aspectos de um processo desviou para fora dos limites aceitáveis, e que o resultado do produto será inaceitável, o processo ou o material sendo produzido deve ser ajustado.

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.

O time de desenvolvimento

O de Desenvolvimento consiste de profissionais que realizam o trabalho de entregar um incremento potencialmente liberável do produto “Pronto” ao final de 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.

Processos ágeis promovem o desenvolvimento sustentável. Patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante.

Ter um software funcionando é a medida primária de progresso.

A maneira mais eficiente de a informação circular entre a equipe de desenvolvimento é por uma conversa cara a cara.

Construa projetos objetivando manter uma equipe motivada, fornecendo ambiente, apoio e confiança necessários para realizar o trabalho.

Entregas regulares

Entregas de forma rápida e eficientes

Processos ágeis esperam que a mudança traga uma vantagem competitiva ao cliente.

Mudanças que não colaboram com a evolução
do projeto devem ser descartadas.

Entregas com frequência de software funcional, sempre na menor escala de tempo, de algumas semanas a alguns meses, preferindo sempre um período curto.

As equipes de negócio e de desenvolvimento devem trabalhar juntas diariamente durante o projeto.

Atenção contínua à excelência técnica e a um bom projeto aumenta a agilidade.

A equipe deve refletir sobre como se tornar mais eficaz, então
sintoniza e ajusta seu comportamento.

As melhores arquiteturas, requisitos e projetos provêm de equipes organizadas.

Simplicidade é essencial.

A gerência de riscos é uma atividade importante a ser realizada no decorrer de um projeto. Ela tem o objetivo de manter o controle sobre possíveis entraves que possam ameaçar a boa execução deste. Além disso, é imperativa a sua realização para alcançar o nível de maturidade de processos G e C do MPS-BR (Melhoria de Processos de Software Brasileiro) e 3 do CMMI (Capability Maturity Model Integration).

Estas atividades são realizadas antes do início do desenvolvimento e revisadas, posteriormente, em marcos pré-definidos do projeto.

Todo o processo é documentado formalmente e comunicado às partes interessadas no gerenciamento dos riscos.

É possível realizá-lo sem sacrificar a agilidade desta metodologia. Sendo assim, ele pode ser realizado de maneira orgânica ou evidente.

Analisando dois casos podemos identificar, no primeiro caso, os riscos são identificados naturalmente, frutos de reuniões diárias, plannings ou revisões. No segundo caso, basta incluir a realização desta atividade, explicitamente, na pauta de alguma cerimônia do SCRUM. Seja qual for o caso, após a identificação, é necessário realizar as demais atividades do processo.

Uma boa prática é a manutenção de um quadro de riscos. A idéia por trás deste é de funcionar como o quadro de tarefas do SCRUM, porém dividido em três partes: mitigar, aceitar e evitar, que são as categorias básicas de respostas aos riscos.

Evitar um risco é a ação de eliminar a causa deste inviabilizando a sua ocorrência (ex: mudança de estratégia de projeto).

Mitigação de um risco é a suavização das consequências, ou a diminuição da probabilidade de um risco por meio de um plano de mitigação (ex: compra de um seguro).

Aceitação de um risco é a ação de simplesmente aceitar suas consequências, podendo haver ou não um plano de contingência para o caso deste ocorrer.

A medida que os riscos vão sendo identificados, eles vão sendo adicionados ao quadro, de acordo com o modo de gerenciamento escolhido para os mesmos.

O mais importante é que o quadro esteja acessível para as partes interessadas e responsáveis pelo gerenciamento dos riscos.

Por que um time precisa monitorar as mudanças?
É impedir que o product owner faça adições desnecessárias ao product backlog. Isto por sua vez reflete sobre a eficiência do product owner. O grupo concordou que as vezes os itens do backlog não são bem pensados, resultando no fato de que eles tendem a mudar com muita frequência.

Suas principais recomendações são:

Registrar a mudança no backlog ou monitor de mudança

Eliminar tantas aprovaçõe quanto for possível

Ter um formulário de controle de mudança leve, se necessário

Manter envolvidos os stakeholders e o time de operações

Assim, em certas situações específicas, talvez seja necessário monitorar as mudanças. Monitorar as mudanças usando algo como o product backlog rotativo ajudaria a erradicar os resíduos no processo e possívelmente tornar o product owner mais eficiente. Há outras razões e modos de monitorar mudanças também, mas a chave é manter o processo enxuto e detalhar somente o necessário.

Backlog do Produto

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.

Backlog da Sprint

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”.

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 Ownerdecidir por liberá-lo ou não.