Interpretando os princípios ágeis: Parte 2

Princípios Ágeis

Com a grande difusão das práticas dos métodos ágeis, é comum vermos pessoas que executam seus rituais sem conhecer suas reais motivações. Esses profissionais, muitas vezes, partem de um conhecimento adquirido na prática do dia a dia, o que pode gerar uma compreensão superficial. O que está por trás dessa abordagem? Para contribuir com esse entendimento, propomos uma revisão dos 12 princípios que originaram os métodos ágeis. Mais do que descrever o princípio, buscou-se apresentar cenários e exemplos que facilitam sua compreensão. No primeiro post da série desmistificou-se o princípio A Satisfação do Cliente. Hoje vamos ao segundo princípio!

Nenhum plano é perfeito. E quando se trata de processos e projetos complexos, como na indústria do desenvolvimento de software, as incertezas e mudanças são enormes. Por mais que planejemos minuciosamente o desenvolvimento de um sistema, novas necessidades são identificadas, outras mudam, as prioridades do cliente são revistas, e planos ficam defasados em questão de semanas.

Hoje isso é amplamente aceito na comunidade, em parte pela influência daqueles por trás do manifesto ágil. Quando ele foi lançado, o modelo tradicional de desenvolvimento de software que predominava era o denominado waterfall, pois era constituído de uma sequência de grandes blocos de planejamento, arquitetura, desenvolvimento, testes, homologação, etc. Do planejamento à entrega as necessidades haviam mudado, uma boa parte do software necessitaria revisão, outra parte seria descartada e algumas novas necessidades precisariam ser incluídas. Projetos fracassavam.

O movimento ágil percebeu que isso não estava funcionando. Um ponto crucial é que se fazia necessário aceitar que as mudanças acontecem, reformular os processos para percebê-las e incorporá-las no fluxo de trabalho, assim permitindo aos clientes maior agilidade na adaptação às mudanças do seu mercado.

Princípio: Aceitar a mudança é um diferencial competitivo

Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.

Os processos preditivos tradicionais se propõem a planejar de antemão todo um projeto. Esses processos foram criados para lidar com os problemas de escopo, prazo e custo de projetos de desenvolvimento de software. Não que mudanças de escopo não existissem, mas os problemas maiores eram outros.

Só que, com o passar do tempo, diversos fatores começaram a mostrar a fraqueza deste modelo. O aumento da complexidade dos projetos começou a evidenciar que um projeto é repleto de incertezas que ameaçam a estabilidade do tripé escopo x prazo x custo. A pressão por mudanças de requisitos da mesma forma desestabilizou este modelo.

O mercado começou a coletar estatísticas preocupantes, mostrando que a maior parte dos projetos estavam falhando. E muito.

O Cone da Incerteza, ilustrado abaixo, descreve bem como funciona a evolução do grau de incerteza durante um projeto.

cone_incerteza

Se no início dos projetos é que há maior incerteza e riscos, como é que um processo que vise prever todo o projeto de antemão pode atingir elevado grau de sucesso? Não é a toa que a maioria dos projetos tradicionais falham em atingir seus objetivos de escopo, tempo e custo.

E o resultado disso? Principalmente conflitos para mudança de escopo. O fornecedor entrega o software ‘de acordo’ com os requisitos redigidos no início do projeto, mas este de longe atende às necessidades atuais do cliente. Este aguardou muito pelo desenvolvimento do software, pagando e não recebendo nada em troca, e agora mudanças são necessárias. Cliente e fornecedor entram no processo tenso de Change Requests, para desenvolver os ajustes necessários para o software ser operacional. Nem escopo, nem prazo, nem custo foram preservados.

As práticas e ferramentas ágeis buscam endereçar este dilema, todas apoiadas no princípio de que é necessário aceitar as mudanças, e não tentar a todo custo evitá-las. Vivemos e trabalhamos em ambientes complexos, onde as incertezas são inevitáveis, e entender isso é um diferencial competitivo.

Melhorias estabelecidas a partir deste princípio

A flexibilização de escopo e a construção de contratos de escopo variável  são alternativas viáveis, visto que o maior desperdício no planejamento muito antecipado é o desenvolvimento de funcionalidades inúteis. Para construir a confiança necessária entre cliente e fornecedor para esse tipo de processo, é fundamental que o modelo de desenvolvimento seja iterativo, com entrega de software de valor de forma frequente.

Para que isso ocorra, outro ponto importante é o planejamento de projeto orientado às funcionalidades do sistema, e não ao fluxo de atividades de desenvolvimento. Funcionalidades medem o real valor de um software. Um bom planejamento ágil consiste da construção de um backlog de funcionalidades, que é elaborado e constantemente revisado em conjunto com o cliente. As funcionalidades mais prioritárias do backlog são desenvolvidas primeiro e entregues ao cliente de forma incremental e recorrente, maximizando o valor do sistema.

Ferramentas e práticas que apoiam este princípio:

  • Métodos de desenvolvimento iterativo, como o Kanban e Scrum.
  • Planejamento ágil de produto, releases e iterações.
  • Técnicas de descrição de requisitos na linguagem do negócio, como User Stories.
  • Prática de deploy contínuo, através da automação das etapas de build, testes, integração e deploy de sistemas.

Se você conhece outras ferramentas ou práticas que são alinhadas a este princípio ágil, deixe seu comentário abaixo 🙂

Você encontra a explicação dos quatro valores e a relação completa dos 12 princípios do manifesto ágil na página Manifesto Ágil.

Anúncios

Um comentário sobre “Interpretando os princípios ágeis: Parte 2

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s