Métodos Ágeis de desenvolvimento - O que é? Mitos

Muito se tem falado do tal dos métodos de desenvolvimento ágil, mas afinal de contas o que é isso? As definições surgiram em meados de 1990, como parte de uma reação contra métodos caracterizados por uma regulamentação complexa e rígida e contra a regimentação e sequenciamento usados no modelo em cascata. O objetivo era acabar com a burocracia dos procedimentos que tornavam as etapas dos processos lentas, o que era contrário ao modo de trabalho usual dos engenheiros de software.

Em 2001, Kent Beck e outros 16 notáveis profissionais da área de Engenharia de Software se reuniram e adotaram o nome de métodos ágeis e publicaram o “Manifesto Ágil”, documento que reúne os princípios e práticas desta metodologia de desenvolvimento. Esses veteranos formaram a “Aliança Ágil”, uma organização não lucrativa que promove o desenvolvimento ágil.

Manifesto Ágil:

“Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar:

• Indivíduos e interação entre eles mais que processos e ferramentas;
• Software em funcionamento mais que documentação abrangente;
• Colaboração com o cliente mais que negociação de contratos;
• Responder a mudanças mais que seguir um plano.

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.”

Os 12 princípios:

• Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.
• 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.
• Entregar software funcionando com freqüencia, na escala de semanas até meses, com preferência aos períodos mais curtos.
• Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diáriamente, durante todo o curso do projeto.
• Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
• O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.
• Software funcional é a medida primária de progresso.
• Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
• Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
• Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
• As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.
• Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

O desenvolvimento ágil envolve uma metodologia que visa minimizar os riscos por meio de desenvolvimentos em curtos períodos ou interações. A iteração típica, envolve o desenvolvimento em fases curtas, de 1 a 4 semanas, envolvendo todas as tarefas necessárias para implantar uma funcionalidade. Considerando-se o período curto de cada iteração, a comunicação mantida entre os envolvidos (stakeholders) é em tempo real, sendo preferencialmente, tratada por meio verbal( embora documentada), visando minimizar entendimentos parciais e errôneos.

De uma forma geral, os processos ágeis atendem aos projetos de software que, normalmente, apresentam:

• Dificuldade em prever com antecedência quais requisitos vão persistir e quais serão modificados, bem como prever quais prioridades dos clientes sofrerão mudanças ao longo do projeto;
• Intercalação das etapas de projeto e construção, que vão sendo realizadas juntas de modo que os modelos de projeto são comprovados na medida em que são criados;
• Análise, projeto, construção e testes não são tão previsíveis, do ponto de vista do planejamento, como seria desejado.

Mitos do desenvolvimento ágil

Ah, mas métodos ágeis não documenta os projetos? MENTIRA! Documentação é tudo aquilo necessário, e suficiente, para que alguém entenda como um sistema de software funciona. Existem diferentes formas de documentar e cada uma serve para um propósito específico. Idealmente, a documentação deve refletir, a qualquer momento, o estado atual de um software. Qualquer documentação que não reflita de forma confiável o estado em que um software se encontra, não serve para muita coisa. Se essa documentação tiver sido escrita no início de um projeto anterior e ninguém souber o quanto dela foi atualizado ao final do projeto, pior ainda. Quando o projeto faz sua entrega final, toda a documentação está certamente defasada e beirando a inutilidade. A única alternativa para que ela não esteja desatualizada é manter, durante todo o projeto, um esforço de revisão e atualização dessas especificações/documentações. Vale lembrar que apesar do Manifesto Ágil dizer “Software funcionando sobre documentação extensiva”, ele termina dizendo “mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda”.

Também se ouve falar a frase “Na minha empresa isso não vai funcionar, aqui as pessoas precisam ser controladas”. Normalmente a mentalidade empresarial relacionada com esse contexto é aquela do “Comando e Controle”. Em contextos empresariais com esse tipo de cultura, temos algumas premissas que são tomadas como verdadeiras e que afetam não só a implantação de métodos ágeis de desenvolvimento de software, como trazem ainda outros problemas organizacionais. Os métodos tradicionais de desenvolvimento de software inicialmente derivaram suas práticas dos métodos usados pelas outras engenharias. Isso aconteceu principalmente porque era o que estava disponível.

Para elaborar o cronograma de um projeto de médio porte, dificilmente o gerente de projeto consegue envolver a equipe toda que irá participar dele. Muitas vezes, por uma questão de tempo, a equipe nem foi definida ainda quando o cronograma começa a ser feito. São alocados alguns especialistas e pessoas de maior senioridade, que por sua vez às vezes também não participam do projeto posteriormente. Obviamente existe uma gama de combinações entre quem ajuda na elaboração do cronograma e quem efetivamente participa de um projeto mas, na pior das hipóteses, temos um cronograma que foi elaborado por pessoas que não participarão do projeto em nenhum momento. Levando em consideração que o único que participa tanto da elaboração quanto da execução do cronograma é o gerente de projeto, e que ele é o único responsável direto por garantir a sua execução, podemos ter sérios problemas de envolvimento da equipe do projeto. Esse envolvimento acaba sendo apenas um dos problemas relacionados a esse mito. Em empresas desse tipo costuma-se gastar muito com o gerenciamento das atividades, porém dificilmente existem mecanismos para mensurar o quanto do projeto é gasto com isto. Outra premissa comum nesse tipo de cultura, e que está ligada à raiz desse mito, é aquela de que as pessoas precisam ser vigiadas e micro gerenciadas ou não farão o seu trabalho. O grau com que isso atinge a equipe é inversamente proporcional à capacidade de liderança do gerente de projetos, mas nem o melhor e mais inspirador dos líderes consegue evitar que a equipe o veja como o único responsável de fato sobre o resultado do projeto. E muitas vezes é isso o que acontece, os louros do sucesso do projeto vão para o gerente que, se for altruísta, o divide com a equipe.

Quando precisamos de um médico, procuramos um bom médico. Quando levamos o nosso carro a um mecânico, escolhemos aquele indicado por algum amigo como sendo capaz de resolver qualquer problema. Quando vamos desenvolver software, isso muda. Achamos que um profissional pouco qualificado pode fazer um bom trabalho, contanto que siga o processo à risca. Bons profissionais, com a motivação correta e inseridos num ambiente que estimule entregas de qualidade, desenvolvem bons produtos de software. Profissionais que só querem cumprir suas horas de trabalho e usar qualquer artifício para evitar serem responsabilizados, não vão entregar bons produtos nem com o melhor e mais completo processo para desenvolvimento de software. Bons desenvolvedores produzem software bom, maus desenvolvedores produzem desculpas.

Exemplos

Como exemplos mais conhecidos tem-se o XP (eXtreme Programming), o Scrum, a família Crystal, o FDD (Feature Driven Development ), o ASD (Adaptative Software Development), o DSDM (Dynamic System Development Method) e o Lean Software Development. Esses métodos seguem princípios semelhantes, mas o que os diferencia são as suas práticas e a forma de condução do processo de desenvolvimento.

Os processos ágeis de desenvolvimento colocam não só a responsabilidade sobre o software, mas também a responsabilidade de entregar resultados de negócio nas mãos de quem pode atuar efetivamente nisso: a equipe. A equipe ser responsável pelo seu próprio trabalho traz benefícios que vão além dos ganhos no projeto. Essa prática também está ligada ao aumento da motivação intrínseca dos colaboradores, o que traz consequências positivas que nenhum bônus, participação nos lucros ou décimo quarto salário conseguem.

A dificuldade de implantar processos ágeis numa empresa é a mesma de fazer qualquer mudança na cultura organizacional, e deve começar pela mudança na dinâmica das relações hierárquicas e no que é valorizado e recompensado. Num contexto onde se valoriza o cumprimento de processos e padrões, mesmo que em detrimento do produto entregue, isso realmente nunca vai funcionar. Mas quase nenhuma empresa obtém seu lucro através do cumprimento de processos, e sim através da entrega de bons produtos no tempo em que o mercado pede.

Fontes: Revista Engenharia de Software Magazine nº 54
             Engenharia de Software, 7ª Edição, Roger Pressman

Posted in: Desenvolvimento Ágil