Formulado em 2001, o Manifesto Ágil deu origem a um novo modelo de projetos de sistema. Seus valores e princípios foram escritos de forma muito simples, porém abrem margem para entendimentos pessoais. Em especial seus valores fundamentais.
Dessa maneira, vou apresentar cada um dos 4 valores, sob um olhar mais profundo, para que possamos entendê-los melhor.
Primeiro é importante entender como os valores foram escritos. Cada valor fundamental do Manifesto Ágil descrevem a valorização do item à esquerda, frente ao item da direita, separados pelo termo "mais que". Porém, valorizar mais um item não quer dizer que o outro seja desnecessário, ou inapropriado. Diz apenas que um é mais importante que outro, como veremos a seguir.
Indivíduos e interação entre eles mais que processos e ferramentas
Indivíduos são os bens mais preciosos de uma empresa. São eles que efetivamente produzem e mantém a empresa em funcionamento. Assim, criar um ambiente favorável, confortável e produtivo para o indivíduo certamente trará inúmeros benefícios à empresa.
A forma como interagem - como a informação é propagada e como são absorvidas - é outro tema de suma importância. Uma informação equivocada pode causar mais estragos do que a falta dela. Por isso, o Manifesto Ágil tem tanto foco na comunicação, tanto dentro da equipe, como entre equipe e cliente.
Por outro lado, processos são necessários para padronizar a maneira como determinadas tarefas são realizadas. Em forma de Guidelines, os processos norteiam a equipe e evitam a dependência das empresas, em seus funcionários. Uma equipe com padrões de desenvolvimento torna-se mais capaz de compartilhar o código fonte, entre seus desenvolvedores, por exemplo.
Do mesmo modo, ferramentas facilitam o processo e aprimoram a disseminação de informações e permitem a distribuição da equipe, geográficamente.
Software em funcionamento mais que documentação abrangente
Software funcionando é a melhor maneira de mensurar o andamento do projeto, assim como seu sucesso ou fracasso. Alé disso, este é o objetivo primário, esperado por um projeto de desenvolvimiento de sistemas.
Em projetos mais simples, o próprio código fonte pode ser considerado como a documentação do projeto. Desde que bem arquitetado, modelado e comentado, para que futuras implementações tornem-se mais eficientes.
Todavia, projetos mais críticos podem necessitar de uma documentação mais apropriada. Seja por motivos legais, contratuais, ou por abordarem assuntos que requeiram maiores níveis de detalhe. Um projeto para o desenvolvimento de um sistema de diagnósticos médicos pode utilizar uma metodologia ágil. Porém, o risco inerente ao projeto implica numa real necessidade de dua documentação, assim como do sistema produzido.
Projetos formados por equipes distribuídas ou complexas, também podem ser alvo de uma documentação mais aprimorada. O motivo é a necessidade de se transmitir informações de forma que todos a recebam, e a interprete, de forma homogênea, para que não se crie dúvidas ou má informação, entre as equipes.
Em ambos os casos, o detalhe da documentação dependerá da criticidade do projeto, da necessidade por parte do cliente, e da possibilidade de manutenção de tal documentação.
Colaboração com o cliente mais que negociação de contratos
Ter a colabração do cliente durante todo o projeto é o fator mais importnate, para o sucesso de um projeto. Isso significa compartilhar, de forma transparente, os riscos, oportunidades, seu andamento e custo.
Em projetos internos, onde o cliente do projeto pertence à mesma empresa que o desenvolve, tal colaboração torna-se mais fácil, visto que não há necessidade de formalização de contratos. Ainda sim existem muitos desafios em criar um ambiente de total colaboração, entre a equipe de desenovimento e o cliente.
Entretanto, quanto mais colaboração existir entre ambas as partes, maior a possibilidade de sucesso de um projeto.
Já em projetos entre empresas distintas, onde uma empresa contrata um fornecedor, para o desenvolvimento de um projeto, raramente não será formalizado por um contrato. Neste ponto, novamente, a colaboração entre cliente e equipe torna-se fator crucial para o sucesso do projeto. Para criar um modelo ágil de projeto, onde mudanças são esperadas, diversas metodologias ágeis sugerem contratos com cláusulas que possibilitam uma maior colaboração e, por consequência, menos burocracia me mudanças de escopo.
Responder a mudanças mais que seguir um plano
Como vimos, mudanças são sempre esperados, em projetos de desenvolviimento de sistemas. Então para que criar um plano que certamente sofrerá alterações? A resposta é simples. Planos são criados para nortear o projeto, e não para amarrá-lo.
Ao criarmos um plano de projeto, prevemos seus riscos, seu custo (mesmo que superficial) e um prazo adequado para sua conclusão. Um plano de projetos ágil certamente terá um menor nível de detalhes que um projeto tradicional. E sofrerá alterações durante sua evolução. Porém, a cada nova fase, será possível validar se ainda estamos no caminho certo, dentro de um custo esperado, ou se o projeto de disvirtuou de seu objetivo inicial.
Conclusão, o Manifesto Ágil aponta um valor maior para os itens da direita, como diretrizes para um maior sucesso de um projeto. Porém o valor dos itens da esquerda deve ser sempre avalido de acordo com sua necessidade.
Até o próximo post.
Visao generalista sobre o assunto.
ResponderExcluirAdorei!