Este é um artigo técnico, sobre os conceitos usados nas metodologias ágeis e está voltado para gestores de tecnologia da informação, gerentes de projetos de software, arquitetos de software, desenvolvedores, testers e demais interessados no assunto.
Entre os diversos títulos veja, em especial, o quadro comparativo geral entre a abordagem tradicional e a ágil, e o quadro que informa quanto é ideal usar cada uma delas.

“Desenvolvimento ágil é o método de engenharia usado para desenvolver produtos (hardware, software ou serviços) de forma iterativa e incremental com flexibilidade para reagir ao feedback dos clientes. Ele reconhece que as necessidades do cliente e que a especificação do produto final não pode ser totalmente definida a priori. Agile é a antítese do Desenvolvimento Cachoeira.”

Na última empresa que participei como sócio-gestor, nossa estratégia e gestão tinham como objetivo a busca pela excelência e a qualidade total com inovação e melhoria contínua. Concentramos esforços para atender, e até mesmo superar, as expectativas dos clientes, sócio-investidores e colaboradores, onde procurávamos sempre:

• Utilizar o que havia de melhor em tecnologia da informação para satisfação de nossos clientes, seja no atendimento, seja no fornecimento de produtos e serviços.
• Manter com os clientes, associados, colaboradores e fornecedores uma relação de alto nível profissional e ético, baseado na integridade, transparência e confiança.
• Criar um ambiente alegre, saudável e propicio para a realização pessoal e profissional de nossos colaboradores.
• Contribuir com a sociedade onde atuamos para manter sustentabilidade a longo prazo.

Nos últimos anos em nossa área de sistemas, nossas equipes trabalhavam em: análise de requisitos de negócio; arquitetura de software; design de interfaces visuais com navegabilidade via protótipos; desenvolvimento de código que incluíam testes unitários; testes completos; entrega e suporte técnico ao pessoal de infra-estrutura na implantação; e suporte técnico durante o período de manutenção.

Com certeza não é fácil encontrar a efetividade, ou seja, a eficiência de fazer bem as tarefas utilizando da melhor maneira possível os recursos, somada com a eficácia que busca atingir um excelente resultado.  Entregar no prazo, com qualidade e com todas as funcionalidades do escopo do projeto sempre foi o nosso objetivo, e, além disso, precisávamos encontrar formas de manter as equipes motivadas e os clientes satisfeitos.  Foi assim que resolvemos providenciar uma metodologia própria no desenvolvimento de projetos de software, que aproveitasse o melhor daquilo que havíamos estudado e praticado ao longo do tempo.

Tomamos então por base os princípios das metodologias ágeis, considerando características do SCRUM, FDD (Feature-Driven Development) , XP (eXtreme Programming) e MSF Ágile que é uma versão leve do Microsoft Solution Framework for CMMI (Capability Maturity Model Integration). Também consideramos algumas práticas do padrão PMBoK (Project Management Body of Knowledge) do PMI (Program Management Institute) na gestão dos projetos, e alguns diagramas UML (Unified Modeling Language) para ajudar na interação e coerência entre os requisitos, a modelagem e o sistema.

O desenvolvimento é iterativo, o que permite uma compreensão crescente do problema através de refinamentos sucessivos que nos aproxima da solução. Esta aproximação permite maior flexibilidade para acomodar novos requisitos ou mudanças táticas nos objetivos do negócio além de identificar riscos antecipadamente.

Esta metodologia nos permitiu:

• Promover a integração constante entre os interessados (stakeholders) e a equipe da empresa, cliente e parceiros – para que as expectativas e necessidades fossem atendidas;
• Assegurar a mesma visão do projeto e o acompanhamento de seu desenvolvimento por parte de todos os membros da equipe;
• Contribuir para o posicionamento da empresa no mercado, com mais um diferencial competitivo.

Seguem abaixo três definições que serão úteis no entendimento dos textos apresentados neste documento:

Projeto – É um empreendimento temporário com início e término bem definidos, conduzido por pessoas para atender objetivos dentro de parâmetros de Prazo, Escopo/Qualidade e Custo.

Gestão de Projetos – Combinação de recursos humanos e materiais através de metodologias e técnicas para atender os objetivos de um projeto. Aplicação de conhecimentos, habilidades e técnicas para planejar atividades que visem a atingir os requisitos do projeto.

Metodologia – É um conjunto de técnicas e métodos; é a forma de ordenar e organizar diferentes tarefas; é um mapa de vôo; é o caminho mais inteligente a ser percorrido para alcançar o melhor resultado. É um guia de referência sobre o que deve ser considerado.

A idéia é adotar práticas que ajudaram outros projetos beneficiar o novo projeto.

O Dilema da Construção de Software

Analisando o cenário de projetos da área de Tecnologia da Informação, percebe-se que, mesmo com os esforços e investimentos realizados, as empresas têm falhado sistematicamente na entrega de seus projetos de desenvolvimento de sistemas. Pesquisas apontam diferentes causas para esse insucesso, entre elas, a falta de domínio de métodos e técnicas e/ou a adoção de práticas errôneas de gerenciamento de projetos. Em face dessa situação, verifica-se a existência de uma lacuna entre a necessidade dessas empresas e os resultados práticos de desempenho alcançados. Desse hiato, advém a urgência de se estruturar ou mesmo repensar a disciplina de gerenciamento de projetos clássico, adotado pelas organizações de desenvolvimento de sistemas.

O Agile Project Management ou Gerenciamento Ágil de Projetos – surge como uma solução promissora, com o intuito de melhorar os resultados de desempenho dos projetos de desenvolvimento de sistemas de Tecnologia de Informação.

O problema:

Projetos de software sempre foram marcados por fracassos:

• Prazos e orçamentos não cumpridos;
• Expectativas não satisfeitas;
• Retorno muito menor que o esperado;
• Impossível satisfazer ao mesmo tempo custo, prazo, escopo e qualidade.

A solução:

Utilizar uma metodologia apropriada para o desenvolvimento de software

• investindo tempo e recursos em uma fase detalhada de planejamento e design;
• garantindo o sucesso da execução com gerenciamento e processos bem definidos.

Metodologias tradicionais

Será esta a Solução? Utilizar metodologias tradicionais, como RUP, CMMI, modelos ISO e tantas outras?  Buscar a complexidade, ao invés da simplicidade?

“Uma grande solução para nossos problemas … ou um grande problema para nossas soluções?” Ou devemos ser mais ágeis, utilizando uma metodologia ágil?

Modelagem Ágil – Um apanhado geral por Scott W. Ambler

Modelagem Ágil é uma metodologia baseada na prática para modelagem efetiva de sistemas baseados em software.

A metodologia de Modelagem Ágil é uma coleção de práticas, guiadas por princípios e valores que podem ser aplicados por profissionais de software no dia a dia.

Modelagem Ágil não é um processo prescritivo, ela não define procedimentos detalhados de como criar um dado tipo de modelo, ao invés ela provê conselhos de como ser efetivo como modelador. É “no tato”, e não “pau-na-máquina” – pense em Modelagem Ágil como uma arte, não como uma ciência.

A modelagem Ágil tem três objetivos:

1. Definir e mostrar como colocar em prática uma coleção de valores, princípios e práticas pertinentes à modelagem efetiva e “peso-leve”.
2. Explorar como aplicar técnicas de modelagem em projetos de software através de uma abordagem ágil tal como XP, FDD, DSDM ou SCRUM.
3. Explorar como melhorar a modelagem sob processos prescritivos como o Processo Unificado da Rational (RUP) – atualmente da IBM.

O que são os Modelos Ágeis?

Um modelo ágil é um modelo bom o suficiente, que implica nas seguintes características:

• Atende seu propósito;
• É inteligível;
• É suficientemente preciso;
• É suficientemente consistente;
• É suficientemente detalhado;
• Provê um valor positivo;
• É tão simples quanto possível.

O que é (e não é) Modelagem Ágil?

• É uma atitude, não um processo prescritivo;
• É um suplemento aos métodos existentes, ele não é uma metodologia completa;
• É uma forma efetiva de se trabalhar em conjunto para atingir as necessidades das partes interessadas no projeto;
• É efetivo e é sobre ser efetivo;
• É uma coisa que funciona na prática, não é teoria acadêmica;
• Não é uma bala de prata;
• É para o desenvolvedor médio, mas não é um substituto de pessoas competentes;
• Não é um ataque à documentação, pelo contrário, aconselha a criação de documentos de valor;
• Não é um ataque às ferramentas CASE;
• Não é para todos.

Os 12 Princípios da Agilidade

1. Lembre que a mais alta prioridade é a satisfação do cliente, por meio da liberação mais rápida e contínua de software de valor;
2. Receba bem as mudanças de requisitos, mesmo em estágios tardios do desenvolvimento. Processos ágeis devem admitir mudanças que trazem vantagens competitivas para o cliente;
3. Libere software freqüentemente (em intervalos de 2 semanas até 2 meses), dando preferência para uma escala de tempo mais curta;
4. Mantenha pessoas ligadas ao negócio (cliente) e desenvolvedores trabalhando juntos a maior parte do tempo do projeto;
5. Construa projetos com indivíduos motivados, dê a eles o ambiente e suporte que precisam e confie neles para ter o trabalho realizado;
6. O método mais eficiente e efetivo para repassar informação entre uma equipe de desenvolvimento é pela comunicação face-a-face;
7. Software funcionando é a principal medida de progresso de um projeto de software;
8. Processos ágeis promovem desenvolvimento sustentado. Assim, patrocinadores, desenvolvedores e usuários devem ser capazes de manter conversação pacífica sempre;
9. A atenção contínua para a excelência técnica e um bom projeto (design) aprimoram a agilidade;
10. Simplicidade é essencial, devendo ser assumida em todos os aspectos do projeto;
11. As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas;
12. Em intervalos regulares, as equipes devem refletir sobre como se tornarem mais efetivas, e então refinarem e ajustarem seu comportamento.

Resumo dos Princípios Centrais da Modelagem Ágil

• Mudanças são bem-vindas;
• Capacitar o próximo esforço é seu objetivo secundário;
• Mudanças incrementais;
• Maximizar o investimento daqueles que suportam o sistema;
• Modelar com um propósito;
• Múltiplos modelos;
• Trabalho de qualidade;
• Feedback rápido;
• Software é seu objetivo primário;
• Viaje com pouca bagagem.

Resumo dos Princípios Suplementares da Modelagem Ágil

• Conteúdo é mais importante que Representação (Forma);
• Todos podem aprender com todos os outros;
• Conheça seus modelos;
• Conheça suas ferramentas;
• Adaptação local;
• Comunicação aberta e honesta (integridade e transparência);
• Trabalhe com o instinto das pessoas.

Os Valores da Modelagem Ágil

A serem adotados no Desenvolvimento de Projetos de Software.

Comunicação – Modelos promovem a comunicação entre a equipe de desenvolvimento e os interessados do projeto tão bem quanto entre os desenvolvedores da equipe.

Coragem – Coragem é importante para a tomada de decisões e para permitir a mudança de direção descartando ou refazendo o trabalho quando algumas decisões anteriores foram inadequadas.

Humildade – Os melhores desenvolvedores são humildes o suficiente para reconhecer que não conhecem tudo e que estão sujeitos a falhas e que seus seguidores, líderes e outros interessados no projeto também têm suas áreas de especialidade, e de que testes do código/solução feitos por si e por outros são necessários e fundamentais para a qualidade do desenvolvimento/resultado.  Uma abordagem efetiva é assumir que todos os envolvidos no projeto têm igual valor e, portanto devem ser tratados com respeito. Devemos procurar tratar as opiniões e/ou idéias dos outros como se tivessem maior valor que as nossas. Será mais positivo e produtivo agir com proatividade procurando  criar sinergia e não reação e discórdia.

Simplicidade – É importante aos desenvolvedores entender que modelos são críticos para simplificar o software e os processos de desenvolvimento – é mais fácil explorar uma idéia e melhorá-la conforme seu entendimento aumenta, desenhando um diagrama ou dois ao invés de escrever/estudar dezenas e até mesmo centenas de linha de código.

Retorno (feedback) – É fácil obter feedback para agir quando comunicamos idéias através de diagramas universais, como os da UML.

Os Valores da Aliança Ágil

Adicionalmente aos valores listados acima, a metodologia Modelagem Ágil também adotou os valores da Aliança Ágil. Vide em http://www.agilealliance.org os valores definidos no seu manifesto:

• Indivíduos e Interações mais que processos e ferramentas;
• Software operante mais que documentações completas;
• Colaboração do cliente mais que negociações contratuais;
• Responder às mudanças mais que seguir um planejamento.

A coisa importante a se entender é que enquanto você deve valorizar os conceitos do lado direito, você deve valorizar ainda mais os itens do lado esquerdo. Uma boa forma de pensar sobre o manifesto é que ele define preferências, não alternativas.

Práticas Centrais da Modelagem Ágil

• Participação ativa daqueles que suportam o projeto;
• Aplique os artefatos certos;
• Propriedade coletiva;
• Considere a “Testabilidade”;
• Crie vários modelos em paralelo;
• Crie conteúdo simples;
• Represente os modelos de forma simples;
• Apresente os modelos publicamente;
• Passe para os outros artefatos;
• Modele em pequenos incrementos;
• Modele com os outros;
• Prove, demonstre com código;
• Use as ferramentas mais simples.

Práticas Suplementares da Modelagem Ágil

• Aplique normas de modelagem;
• Aplique padrões gentilmente;
• Descarte os modelos temporários;
• Formalize os modelos de contrato;
• Modele para comunicar;
• Modele para entender;
• Reutilize recursos existentes;
• Atualize somente quando doer.

Comparativo Geral da Abordagem Tradicional com a Ágil

Abordagem Tradicional	Abordagem Ágil
Preditivo: detalhar o que ainda não é bem conhecido	Adaptativo: conhecer problema e resolver o crítico primeiro
Rígido: seguir especificação predefinida, a qualquer custo	Flexível: adaptar-se a requisitos atuais, que podem mudar
Burocrático: controlar sempre, para alcançar objetivo planejado	Simplista: fazer algo simples de imediato e alterar se necessário
Orientado a processos: segui-los possibilita garantir a qualidade	Orientado a pessoas: motivadas comprometidas e produtivas
Documentação gera confiança	Comunicação gera confiança
Sucesso = entregar o planejado	Sucesso = entregar o desejado
Gerência = “comando-e-controle” voltado para trabalho em massa, ênfase: papel do gerente, com planejamento e disciplina fortes	Gerência = liderança/orientação trabalhadores do conhecimento, ênfase: criatividade, flexibilidade e atenção às pessoas
Desenvolvedor hábil (variedade)	Desenvolvedor ágil (colaborador)
Cliente pouco envolvido	Cliente comprometido (autonomia)
Requisitos conhecidos, estáveis	Requisitos emergentes, mutáveis
Retrabalho/reestruturação caro	Retrabalho/reestruturação barata
Planejamento direciona os resultados (incentiva controlar)	Resultados direcionam o planejamento (incentiva mudar)
Conjunto de processos, com metodologia definida	Conjunto de valores, com atitudes e princípios definidos
Premia a garantia da qualidade	Premia o valor rápido obtido
Foco: grandes projetos ou os com restrições de confiabilidade, planej. estratégico / priorização (exigem mais formalismo)	Foco: projetos de natureza exploratória e inovadores, com equipes pequenas/médias (exigem maior adaptação)
Objetivo: controlar, em busca de alcançar o objetivo planejado (tempo, orçamento, escopo)	Objetivo: simplificar o processo de desenvolvimento, minimizando e dinamizando tarefas e artefatos

Quando usar qual metodologia

Metodologias Preditivas	Metodologias Ágeis
Projetos altamente críticos	Projetos pouco críticos
Equipe iniciante	Equipe experiente
Projeto com poucas mudanças	Projeto com mudanças constantes
Equipes maiores (>= 20 pessoas)	Pequena equipe (< 20 pessoas)
Equipe distribuída	Equipe co-localizada
Cultura de controle	Cultura de adaptação

Pontos positivos e negativos das abordagens

• Partem de pressupostos diferentes!
• Podem coexistir e conviver bem em um mesmo ambiente, pois as “boas práticas” são compatíveis e podem funcionar bem, mesmo sem contemplar integralmente um modelo ou norma.
• Importante: considerar, criteriosamente, o ambiente correto.
• É necessário buscar o ponto de equilíbrio, avaliando os riscos.

O ciclo de vida ágil é semelhante aos outros

• Definir o que o cliente quer e iniciar o projeto;
• Planejar o projeto, calculando esforço;
• Executar o plano, construindo a solução;
• Monitorar resultados e entregar ao cliente;
• Ciclos mais rápidos, executados várias vezes.

O planejamento aperfeiçoa a agilidade. A agilidade dá eficiência ao planejamento.

Manifesto Ágil – par de alternativas se reforçam

• Processos e ferramentas podem melhor capacitar os indivíduos e interações;
• Documentação ajuda as pessoas a entenderem um software complexo;
• Negociação de contrato pode ser parte integrante da colaboração do cliente;
• Seguir um plano pode ser o melhor modo para responder a mudança, quando esta for previsível.

Observação: Pessoas comprometidas e suas proposições de valor são fundamentais!

Por favor, fique a vontade de contribuir com um comentário e compartilhar este artigo com seus amigos.

Meu endereço no Twitter é: @neigrando –  www.twitter.com/neigrando

Links relacionados com o assunto:

• Lean Startup – Para iniciar uma empresa enxuta e ágil
• Scrum Reference Card
• Explaining Agile
• YOW! 2015 – 40 Agile Methods in 40 Minutes
• Manifesto para Desenvolvimento Ágil de Software (em português)
• Ágile Alliance (em inglês)
• Livro grátis SCRUM e XP direto das Trincheiras
• Wikipedia: Scrum
• Wikipedia: Programação Extrema – XP
• Wikipidia: FDD
• Vídeo: Scrum em menos de 10 minutos
• Livro: Caindo na Real da 37signals (sobre desenvolvimento ágil de software)
• Outros Links interessantes:
• Project Management Institute, em São Paulo, com informações avançadas sobre projetos
• Wikipedia: Capability Maturity Model Integration – CMMI
• Wikipedia: Rational Unified Process – RUP
• Wikipedia: Unified Modeling Language – UML
• Wikipedia: Business Process Management – BPM
• Wikipedia: Service Oriented Architecture – SOA