Princípios ágeis: entrega de valor

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (4)  (0)

Veja neste artigo os princípios ágeis e um conjunto de metodologias de desenvolvimento, providenciando uma estrutura conceitual para reger projetos de engenharia de software.

Quando falamos de agilidade, é bem comum pensarmos em Scrum, XP, Kanban ou ainda em programação pareada e TDD. Estamos acostumados a pensar em algum processo ou prática ágil. Isso não é um problema, mas essas são todas formas de aplicar os conceitos mais fundamentais, que definem o que é Agile.

Fazer uma visita à página do Manifesto Ágil de tempo em tempo para revisar a definição da agilidade e rever comportamentos recentes é uma ideia que é aplicada e recomendada a todos.

O Manifesto é, no entanto, apenas a porta de entrada. Seguindo, caímo-nos Princípios Ágeis: fases mais específicas e mais fáceis de pôr em prática imediatamente! Nesse post vamos destrinchar esses princípios, onde eles se aplicam e ver quais práticas está associado a eles.

Software funcionando é a primeira medida de progresso. Esse princípio toca em um assunto delicado: ele desafia as medidas tradicionais de progresso que incluem geração de documentos, análise e design como formas de ver que um projeto está andando.

Note, contudo, que ele não impede a criação da mesma documentação e nem entra em conflito com equipes formadas por especialistas de cada área. Apenas diz que a construção das documentações e as fases pré-desenvolvimento em si não podem ser contadas como evidência de que o projeto anda bem. Só o produto do desenvolvimento é que conta.

Nossa maior prioridade é satisfazer o cliente através de entregas frequentes e desde cedo de software de valor.

Entregar valor o mais cedo possível ajuda para o cliente entender o que vai trazer mais valor ainda em um futuro próximo: só mesmo usando o sistema é que percebemos que alguns detalhes que ficaram de fora são muito importantes para o usuário e que outros planos mirabolantes feitos a princípio seriam desnecessários.

Aqui entra o conceito de desenvolvimento incremental priorizando a felicidade do cliente e do entendimento de que software é orgânico e deve crescer como tal. E para que ele tome o rumo necessário, falamos do princípio seguinte.

Entregar o software funcionando e com frequência, em intervalos de semanas ou meses, dando preferência para períodos mais curtos.

As entregas com frequência destacadas aqui aparecem por uma razão simples: não é possível ter a certeza de que estamos avançando pelo caminho certo enquanto o software não tiver usuários reais.

Pense em quantos pontos de potencial perda de informação um projeto tem: quando o cliente fala com o levantador de requisitos, quando este repassa para o restante da equipe e, progressivamente — quanto mais especialistas no meio do caminho, mais falhas podem acontecer. E ainda que seu time funcione perfeitamente bem, seu cliente ainda tem a potencial falha de comunicação com os usuários reais do sistema.

Contudo, esse feedback constante cria uma situação que os métodos tradicionais tratam como um grande problema: o cliente vai tender a fazer novos pedidos e mudanças no que havia sido combinado. E, como os agilistas, levam tais mudanças como acontecimentos normais e oportunidades.

Receber bem a mudança de requisitos, mesmo se o projeto estiver em desenvolvimento, irá facilitar o processo ágil, sendo que essas mudanças são uma vantagem para o cliente.

Muitas vezes, temos fortes convicções sobre o que um software vai ser quando completo, e se viciar nessas expectativas iniciais é uma perigosa armadilha: é mais do que comum que encontremos formas melhores de resolver problemas do que as previstas no início do projeto.

Esse apego a um plano inicial prejudica o potencial do projeto e não são poucas as histórias de terror que ouvimos por aí de casos que seguiram um plano inicial e, no fim, não foram implantados por incompatibilidades com a realidade.

O problema do entendimento que acontece sobre esse princípio é atrelar o recebimento de novos requisitos à necessidade do aumento de prazo ou do custo do projeto. Embora essas soluções devam ser consideradas, elas não são as únicas possibilidades. Sempre é bom manter um product backlog devidamente priorizado, isso facilita imensamente na troca de requisitos e na visibilidade do que será removido do projeto com a entrada de uma nova necessidade.

Princípios ágeis: entrega de valor

Figura 1: Princípios ágeis: entrega de valor

Práticas relacionadas são agora os princípios e suas aplicações, uma sopa de letrinhas de artefatos, práticas e papéis para você saber o que procurar para se aprofundar nesses assuntos:

Product Backlog: manter uma lista priorizada do que há para fazer, melhorar a visibilidade das trocas que estão sendo feitas e dos efeitos delas;

Product Owner / Cliente próximo: o cliente próximo é o que nos dá a certeza de que o projeto está andando no melhor caminho possível e colaborar com esse cliente é fundamental;

Desenvolvimento incremental: a construção de partes do software que foca em ser utilizável o mais cedo possível permite que os feedbacks sejam assertivos;

Iteração / Sprint: uma das formas de trabalho incremental, a iteração é uma delimitação pequena de tempo que tem o propósito de agregar valor para o cliente, com a vantagem de adicionar um foco palpável e com prazo próximo de entrega para a equipe de desenvolvimento;

Fluxo contínuo: outra forma de desenvolvimento incremental são métodos que trabalham com fluxo contínuo e focam em entregar o item de maior importância o mais cedo possível, sem a pré-delimitação de trabalho por tempo;

Review Meeting: a reunião que junta em uma mesma sala os usuários e o time de desenvolvimento é uma excelente oportunidade de criar um ambiente de críticas produtivas, focando na melhoria do software em um todo.

Automatização de build: linguagens diversas têm boas ferramentas de automatização do build de projetos. Essa prática se associa aos princípios e possibilita o acompanhamento mais fino da consistência do projeto e é pré-requisito para a próxima;

Entrega contínua: uma vez que seus processos de build estejam automatizados, com mais alguns poucos passos é possível automatizar também a entrega de software e, quanto mais fácil fazê-la, menos empecilhos para entregar desde cedo e com boa frequência. 

E você? Como interpreta cada um dos princípios?

Então finalizamos aqui este breve artigo. Quaisquer dúvidas, sugestões ou críticas podem ser registradas na seção de comentários, abaixo.

Um grande abraço! 

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?