A Verdade Sobre os Métodos Ágeis
O Manifesto Ágil diz o seguinte:
"Estamos a apresentar melhores formas de desenvolver software, desenvolvendo software e ajudando outros a desenvolver. Com base neste trabalho, acabámos por valorizar:
• Os indivíduos e as interacções mais do que os processos e as ferramentas,
• O software funcional (working software) mais do que a documentação exaustiva,
• A colaboração do cliente mais do que a negociação contratual,
• A resposta à mudança mais do que o seguimento de um plano.
Ou seja, apesar de existir valor nos itens da direita, valorizamos mais os itens da esquerda".
O Manifesto Ágil tem sido lido frequentemente de forma a ignorar na última linha da citação anterior. Para estes leitores apressados, os itens da direita não têm menos valor, mas antes valor zero. O Manifesto Ágil tem sido citado frequentemente pelos proponentes das metodologias Ágeis como justificação para não terem processos, para não documentarem o seu trabalho e para não terem planos. Curiosamente, esta interpretação dá razões justificáveis aos detractores das metodologias Ágeis para acusarem os seus defensores de serem "lacaios indisciplinados".
Os detractores dos métodos Ágeis também costumam abusar do Manifesto Ágil utilizando o mesmo mecanismo. Atribuindo valor zero aos itens da direita, imaginam o pior dos defensores das abordagens Ágeis. Tudo porque ambas as interpretações do Manifesto Ágil são incompletas e desonestas.
Ao nível meramente do discurso, quem não valorizaria os itens da esquerda mais do que os da direita? Mas convém ter em conta as origens do próprio Manifesto Ágil (veja o texto As Origens do CMMI e dos Métodos Ágeis). Em muitos dos projectos que estiveram na base da corrente Ágil existiam planos, processos e standards que eram muito detalhados, rígidos e que valorizavam tudo isso em detrimento das pessoas, dos projectos, dos produtos, dos clientes e da tecnologia.
As práticas comuns associadas às abordagens Ágeis incluem o seguinte:
• É utilizado o desenvolvimento iterativo e com curtos períodos de tempo incrementais.
• Existe feedback do cliente frequente e de forma contínua. Os clientes são normalmente incluídos na equipa de desenvolvimento. Na realidade, a utilização de conhecimento tácito é um aspecto chave nas práticas e no desenvolvimento Ágil. A utilização de conhecimento tácito é mais vantajosa em ambientes onde existe uma confiança elevada, podendo beneficiar-se directamente dos baixos custos de transacção das actividades de engenharia de software. Os riscos inerentes à utilização do conhecimento tácito - apesar de não serem normalmente geridos de forma explícita - são mitigados pela seguinte natureza do domínio:
o A duração do projecto (e o ciclo de vida esperado do produto),
o A natureza de auto-documentação do código moderno,
o A utilização de ferramentas que podem inverter desenhos e outros artefactos, bem como integrar código continuamente,
o A pequena dimensão da equipa.
• Cada incremento entrega potencialmente valor (ou seja, código funcional). O valor também pode ser "o que não fazer".
• O produto entregue está completamente testado para cada entrega. Os produtos são criados frequentemente depois da escrita de testes rigorosos, fazendo evoluir posteriormente o produto de forma a passar os testes.
• Todos são detentores da qualidade, incluindo o cliente (ou representante do cliente). As equipas de desenvolvimento são frequentemente multi-disciplinares, na medida em que todos os elementos são generalistas e detêm colectivamente o produto. Os clientes são igualmente responsáveis por garantir que o produto responde às suas expectativas. Os produtos não avançam enquanto não for estabelecida uma ideia comum sobre a funcionalidade do produto, inclusões e exclusões. Existe uma atitude inicial de fracasso com o pressuposto subjacente de que o código que funciona mal é pouco ou insignificante.
• Os requisitos detalhados são desenvolvidos just in time e evoluem com a compreensão do produto. Não se investe nenhum esforço em especular sobre os requisitos ou as expectativas. À medida que o produto a entregar vai evoluindo, os requisitos vão-se tornando cada vez mais detalhados.
• As mudanças são esperadas, bem-vindas e/ou aceites em qualquer altura. As fontes reconhecidas de mudança no desenvolvimento tradicional são as alterações a requisitos que foram objecto de baseline demasiado cedo (de acordo com a perspectiva Ágil). Além disso, a expectativa de alterações determina as decisões de desenho. Em termos de desenho, os componentes arquitecturais e de produto não estão fechados, de modo que os especialistas em desenvolvimento podem encontrar soluções de compromisso até que todos os requisitos dos componentes estejam disponíveis.
• São utilizadas equipas auto-dirigidas e auto-responsáveis. As pequenas equipas maduras, bem treinadas, coesas e de alta confiança que assumem o produto como seu não precisam de muita orientação, gestão, ou distribuição de tarefas. O produto, o projecto e os objectivos de negócio são partilhados com a equipa, de modo a que esta possa tomadas decisões informadas em termos técnicos, de gestão e organizacionais para determinar o que precisa de ser feito, quando, por quem e com que standards. É permitido às equipas responderem às condições correntes, em vez de seguirem planos muito detalhados e enfatizados. Consequentemente, os planos e o planeamento são actualizados frequentemente e a comunicação com os superiores (sejam eles organizacionais ou da própria equipa) ocorre normalmente com uma regularidade diária ou quase diária. As reuniões com grande cerimónia com a gestão, ou as avaliações com os clientes são substituídas por interacções frequentes com estes stakeholders.
• O processo é avaliado e ajustado periodicamente. As equipas maduras assumem a posse do processo que empregam e ajustam-no com base no feedback, naquilo que funciona e naquilo que não funciona.
De uma forma geral, os atributos de implementações Ágeis bem sucedidas são os que se seguem:
• Pequenas equipas de aproximadamente 10 pessoas,
• Um cliente envolvido,
• Planeamento contínuo ou por vagas,
• Equipas inter-funcionais e com todos os elementos próximos em termos de localização,
• Organizações que não têm o hábito de partir as equipas enquanto cada um dos membros não for individualmente competente na abordagem Ágil.
As metodologias Ágeis não conseguem ser bem sucedidas quando se verifica o seguinte:
• Falta de processos,
• Falta de disciplina,
• Inexistência de uma função para planos ou planeamento.
O Manifesto Ágil inclui uma lista de princípios gerais:
"Seguimos os seguintes princípios:
• A nossa maior prioridade é satisfazer o cliente através da entrega atempada e contínua de software com valor.
• Damos as boas vindas às alterações de requisitos, mesmo em fases avançadas do desenvolvimento. Os processos Ágeis acomodam as alterações para vantagem competitiva do cliente.
• Entregamos software funcional (working software) frequentemente, desde poucas semanas a poucos meses, com preferência para os espaços de tempos mais curtos.
• As pessoas do negócio e as pessoas do desenvolvimento têm de trabalhar em conjunto diariamente ao longo de todo o projecto.
• Construímos projectos com base em pessoas motivadas. Dêem-lhe o ambiente e suporte que precisam e confiem nelas para fazerem o trabalho.
• O método mais eficiente e eficaz para a partilha de informação com a equipa e dentro da equipa de desenvolvimento é a conversação face a face.
• O software funcional (working software) é a principal métrica de progresso,
• Os processos Ágeis promovem o desenvolvimento sustentável. Os patrocinadores, especialistas em desenvolvimento e utilizadores deverão ser capazes de manter um ritmo constante indefinidamente.
• A atenção contínua à excelência técnica e ao bom desenho melhora a agilidade.
• A simplicidade - arte de maximizar a quantidade de trabalho não feito - é essencial.
• As melhores arquitecturas, requisitos e desenhos emergem das equipas que se auto-organizam.
• A intervalos regulares, a equipa reflecte sobre como se tornar mais eficaz, ajustando depois o seu comportamento de acordo com as conclusões a que chegou".
Cada palavra do Manifesto Ágil e dos princípios orientadores foi objecto de consenso - um processo familiar a todos aqueles que já estiveram envolvidos em avaliações SCAMPI. Cada palavra tem o seu significado, pelo que a tradução poderá desvirtuar o original. Aconselha-se, portanto, a leitura também na língua original (inglesa). De qualquer forma, as palavras são sempre condicionais e qualificativas. Não são absolutas. Quem quer que as interprete de forma absoluta estará a desvirtuar as ideias Ágeis. O mesmo se verifica se interpretarem os produtos de trabalho típicos do CMMI como absolutos.
Baseado num texto da autoria de Hillel Glazer, Jeff Dalton, David Anderson, Mike Konrad e Sandy Shrum, com o título "CMMI or Agile: Why Not Embrace Both!"