Introdução

Em geral não é possível conhecer todas as necessidades dos Stakeholders, esteja atento a todos os riscos do projeto, compreenda todas as tecnologias envolvidas no projeto ou saiba como trabalhar com seus colegas. Mesmo sendo possível conhecer todas essas coisas elas estão suscetíveis a mudanças durante o ciclo de vida do projeto. Promover práticas que permitam à equipe demonstrar valor incremental e conseguir feedback rápido e contínuo dos Stakeholders.

A intenção por trás deste princípio é obter feedback contínuo e melhorar o produto e o processo da equipe de projeto. Quando você fornece uma estrutura e cria uma mentalidade para melhoria e feedback contínuos, as mudanças são acomodadas mais facilmente. Adicionalmente, o feedback é captado antecipadamente e constantemente e os riscos de alta prioridade são confrontados mais cedo no projeto. Ao identificar e atacar constantemente os riscos passará a existir mais confiança no progresso e na qualidade do projeto.

Não somente o produto evolui, mas a equipe também encontra melhores formas de trabalhar em conjunto e se envolver com os Stakeholders. O processo seguido pela equipe pode ser ajustado apropriadamente para alavancar as lições aprendidas e ajustar o andamento e as necessidades do projeto.

Práticas

Desenvolva seu projeto em iterações

Desenvolver um sistema com um único passo linear é difícil porque isto torna muito custosa a incorporação de mudanças e novos conhecimentos. Pior, isto pode atrasar a descoberta e a atenuação de riscos por que os esforços de desenvolvimento são agendados tardiamente no ciclo de vida do sistema.

Divida o projeto em séries de iterações e planeje seu projeto iterativamente. Esta estratégia de iteratividade permite entregar capacidades incrementalmente (tal como um executável ou um conjunto usável de requisitos implementados e testados) que podem ser avaliadas pelos Stakeholders ao final de cada iteração. Isto provê ciclos de feedback rápidos e temporizados de forma que os problemas possam ser tratados e as melhorias serem feitas a um custo mais baixo. Isto também é realizado enquanto você ainda tem recurso e tempo disponíveis e você não tenha ido tão longe de forma que um re-trabalho maior seja necessário.

O desenvolvimento iterativo habilita a equipe a melhorar o software constantemente durante seu ciclo de vida de desenvolvimento.

Focalize as iterações no atendimento do próximo marco de gerenciamento

Um projeto pode parecer que está progredindo enquanto os riscos e os problemas não resolvidos estão crescendo. Acompanhe de perto os problemas importantes do projeto (tais como a concorrência entre Stakeholders, escopo e o fornecimento da arquitetura proposta).

Divida o projeto em fases (tais como Concepção, Elaboração, Construção e Transição), com cada fase tendo um marco de gerenciamento claramente visível. O foco de cada iteração em uma fase é alcançar o marco.

Gerenciar Riscos

Protelar as questões sobre dificuldades e riscos para o final do projeto, aumenta o risco de cancelamento do projeto. Esta procrastinação pode direcionar o investimento em tecnologias erradas, em um design ruim ou em um conjunto de requisitos que não atendem as necessidades dos Stakeholders.

Ataque os riscos cedo, ou eles lhe atacarão. Identifique e priorize continuamente os riscos, e elabore estratégias para atenuá-los. Determine o foco das iterações baseado nos riscos. Por exemplo, os riscos arquiteturalmente significantes devem ser tratados cedo no projeto, no máximo até o final da fase de Elaboração, quando a arquitetura estiver aprovada e com linha de base.

Para mais informações, veja Guideline: Gerenciando Riscos.

Aceite e gerencie as mudanças

As mudanças são inevitáveis, e embora as mudanças apresentem oportunidades para elevar o valor para o stakeholder, mudanças irrestritas resultarão num sistema inchado, deficiente e que não atende às necessidades do Stakeholder. Além disso, quão mais tarde uma mudança for feita no ciclo de desenvolvimento, mais custosa ela será.

Aceite e gerencie as mudanças Aceitar as mudanças lhe ajuda a construir um sistema que atende as necessidades dos Stakeholders, e gerenciar as mudanças lhe permite reduzir o custo e melhorar a previsibilidade destas mudanças. Mudanças que são executadas cedo no projeto podem normalmente ser feitas com custo limitado. À medida que o projeto progride, as mudanças podem se tornar altamente custosas.

Para satisfazer as necessidades dos clientes, você normalmente precisa fazer mudanças no projeto, porém o cliente deve ser avisado do impacto que estas mudanças causam no custo e no cronograma do projeto. Entenda o impacto de uma mudança na fase corrente, e isole os membros da equipe das mudanças repentinas durante a iteração corrente. As solicitações de mudança são revistas e priorizadas durante a iteração corrente, mas não são ativadas até serem atribuídas a uma iteração futura.

Se for necessário, documente as mudanças. Para projetos informais, uma conversa com os Stakeholders pode ser o suficiente.

Meça o progresso objetivamente

Se você não sabe objetivamente como o projeto está progredindo, você realmente não sabe se ele está caminhando para o sucesso ou fracasso. A incerteza e a mudança tornam o progresso de um projeto de software difícil de ser medido objetivamente, e as pessoas são levadas a fazer avaliações objetivas com informações subjetivas.

Tenha uma imagem clara do status do projeto medindo o progresso objetivamente. A melhor medida de progresso é a entrega de software funcional, que é algo que você faz tendo uma abordagem evolucionária. Você pode também definir um conjunto de métricas objetivas a coletar durante uma iteração (por exemplo, requisitos que foram implementados e validados, quantidade de defeitos relatados comparada com a quantidade corrigida) e revise-os como parte da avaliação da iteração.

Reavalie continuamente o que você faz.

Faça perguntas e verifique as suposições sobre o projeto, frequentemente. Encontre-se com a equipe regularmente para acompanhar o status do projeto e identificar os riscos e questões. Isto pode ser feito diariamente quando a equipe se reúne para compartilhar o status das responsabilidades individuais e identificar e tratar os problemas. Ao final das iterações, avalie o status do que foi feito e busque por áreas de melhoria que podem ser tratadas na próxima iteração. Faça uma revisão retrospectiva ao final do projeto e capture as lições aprendidas para executar projetos futuros de forma mais eficiente.

Se nós sempre desafiarmos o que nos fazemos e procurarmos formas inovadoras para desenvolver software, nos melhoraremos nossa forma de trabalho. Isto direciona para melhores resultados no projeto.