O Manifesto Ágil reconhece que a utilização de processos, ferramentas, documentação, contratos e planos pode ser importante para o sucesso do projeto, mas são ainda mais importantes os chamados valores Ágeis: os indivíduos e interações entre eles, software (ou produto) em funcionamento, colaboração com o cliente e responder a mudanças.
Experimente escutar este conteúdo! Dê o play!
Apresentaremos a seguir a visão de dois signatários originais do Manifesto, Alistair Cockburn e Jim Highsmith, e de um autor relevante, Craig Larman, acerca do significado de cada um desses valores.
Manifesto para Desenvolvimento Ágil de software
Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Por meio deste trabalho, passamos a valorizar:
- Indivíduos e interações 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 aos itens à direita, valorizamos mais os itens à esquerda.
Indivíduos e interações
Para Jim Highsmith, valorizar indivíduos e interações mais que processos e ferramentas leva em conta que, em última instância, quem gera produtos e serviços são os indivíduos, que possuem características únicas individualmente e em equipe, como talento e habilidade (Highsmith, 2004). Alistair Cockburn afirma que as pessoas na equipe são mais importantes do que seus papéis em diagramas de processos. Assim, embora descrições de processos possam ser necessárias para se começar o trabalho, as pessoas envolvidas nos processos não podem ser trocadas como peças (Cockburn, 2007). Na mesma linha, Craig Larman lembra que a programação de computadores é uma atividade humana e, assim, depende de questões humanas para seu sucesso. O autor cita como exemplo a vida social e familiar dos membros da equipe que são afetadas, por exemplo, pelo excesso de trabalho (Larman, 2003). Highsmith complementa afirmando que são críticas para o sucesso dos projetos as habilidades, personalidades e peculiaridades dos indivíduos, e eles são muitas vezes desorganizados e difíceis de entender, ao mesmo tempo em que são inovadores, criativos, exuberantes e apaixonados (Highsmith, 2002).
Cockburn afirma ainda que a qualidade da interação entre os membros do time é importante para a solução de problemas no desenvolvimento do projeto (Cockburn, 2007). Larman, sobre esse tema, destaca que o uso da comunicação e do feedback é uma diretiva essencial para a prática Ágil, especialmente a partir da conversação face a face (Larman, 2003). Highsmith lembra a importância do trabalho em equipe, afirmando que habilidades individuais e trabalho em equipe são inseparáveis em projetos de desenvolvimento de software (Highsmith, 2002).
Outro ponto levantado por Larman é que as ferramentas utilizadas para auxiliar o desenvolvimento de software devem ser as mais simples possíveis que funcionem (Larman, 2003). Projetos que utilizaram metodologias pesadas em termos de processos e ferramentas, segundo Highsmith, obtiveram sucesso fundamentalmente devido às pessoas envolvidas naqueles projetos (Highsmith, 2002). O autor afirma ainda que processos podem guiar e apoiar o desenvolvimento de software e ferramentas podem melhorar sua eficiência, mas é com a capacidade e conhecimento dos indivíduos que se pode contar para tomar decisões críticas para o desenvolvimento do projeto. Bons processos ajudam a equipe ao invés de ditar como seu trabalho deve ser feito, de forma que são os processos que se adaptam à equipe, e não o oposto (Highsmith, 2004). Ainda segundo Highsmith, um processo não é um substituto para uma habilidade, de forma que segui-lo por si só não cria bons programas de computador (Highsmith, 2002).
Software em funcionamento
Para Alistair Cockburn, software em funcionamento é o único indicador do que a equipe de fato construiu (Cockburn, 2007). Jim Highsmith afirma que clientes se interessam por resultados, ou seja, software em funcionamento que entregue valor de negócio (Highsmith, 2002).
Segundo Cockburn, a documentação pode ser muito útil para o desenvolvimento do projeto, mas deve-se produzir somente a documentação necessária e suficiente para a realização do trabalho (Cockburn, 2007). Highsmith por sua vez afirma que software em funcionamento não exclui a necessidade de documentação, pois ela pode permitir a comunicação e colaboração, melhorar a transferência de conhecimento, preservar informações históricas, ajudar a melhorias em progresso e satisfazer a necessidades legais e regulatórias. Segundo o autor, a documentação não é desimportante, ela simplesmente é menos importante do que versões em funcionamento do produto. Ainda segundo o autor, um erro comum em projetos é a crença de que a documentação substitui a interação, servindo como um meio de comunicação. A documentação, na realidade, facilita a interação, funcionando como seu subproduto na forma de documentos, rascunhos, desenhos, anotações etc., que podem (ou não) ser utilizados como um registro permanente (Highsmith, 2004).
Highsmith afirma ainda que a entrega iterativa de versões do software em funcionamento possibilita um feedback confiável no processo de desenvolvimento de formas que simplesmente com a documentação é impossível (Highsmith, 2004). Craig Larman denomina essa prática como “entrega evolutiva”, na qual há um esforço em se obter o máximo de feedback possível sobre o que foi entregue, de forma que a próxima entrega seja planejada dinamicamente, baseada nesse feedback (Larman, 2003).
Colaboração com o cliente
Para Alistair Cockburn, no desenvolvimento Ágil não há “nós” e “eles”, há simplesmente “nós”, o que significa que clientes e desenvolvedores estão do mesmo lado, colaborando para produzir o software que traga valor para esses clientes. Nessa dinâmica, ambos são necessários para que se produza software de boa qualidade. Segundo o autor, essa colaboração envolve companheirismo, tomada de decisão conjunta e rapidez na comunicação, de forma que muitas vezes pode até tornar contratos desnecessários (Cockburn, 2007).
Segundo Jim Highsmith, no desenvolvimento de novos produtos como software em que há alta volatilidade, ambiguidade e incertezas, a relação cliente-desenvolvedor deve ser colaborativa, ao invés de marcada por disputas de contrato antagônicas (Highsmith, 2004).
Responder a mudanças
De acordo com Jim Highsmith, todo projeto deve balancear o planejar com o mudar, dependendo do nível de incerteza inerente a ele. Segundo o autor, em projetos onde há alta incerteza, a investigação e a concepção mental predominam sobre o planejamento e a execução restrita de tarefas planejadas (Highsmith, 2004). Esse conceito se aplica ao desenvolvimento de software, já que, de acordo com Craig Larman, a incerteza é inerente e inevitável em projetos e processos de software (Larman, 2003). Alistair Cockburn afirma que construir um plano é útil, mas seguir o plano só é útil até o momento em que ele ainda está próximo o suficiente da situação atual. Assim, manter-se preso a um plano ultrapassado não funciona em favor do sucesso (Cockburn, 2007).
Highsmith destaca ainda que empresas que buscam prosperar na turbulenta economia atual devem alterar tanto seus processos quanto suas perspectivas em consideração à mudança, já que praticamente tudo, exceto a visão do produto, pode mudar em pouquíssimo tempo, como escopo, funcionalidades, tecnologia, arquitetura etc. (Highsmith, 2004).
Segundo Cockburn, iterações curtas de desenvolvimento permitem que mudanças possam ser mais rapidamente inseridas no projeto, de forma que atendam às novas necessidades dos clientes (Cockburn, 2007).
