Ao longo dos últimos anos, uma das áreas que mais cresceu foi justamente a de tecnologia voltada para o desenvolvimento de software e, com esse grande impulso, vieram junto enormes problemas que vão desde qualidade, prazos e, principalmente, expectativas de todos os envolvidos no processo, levando grande parte dos projetos a algum tipo de fracasso, conforme podemos observar nos principais estudos relacionados, como o “Chaos report”, promovido pelo The Standish Group.
A arte de desenvolver software é baseada em um modelo completamente criativo e dinâmico, sujeito a mudanças em cada passo, sejam oriundas de uma amplificação no entendimento do valor de negócio por parte do cliente ou em atividades emergentes que surgem logo nos primeiros minutos de codificação em qualquer projeto de desenvolvimento de software.
As disciplinas tradicionais de gestão baseiam-se em muitas ideias aplicadas na própria construção civil e tentam, usando esses princípios, determinar os mesmos fundamentos para projetos de desenvolvimento de software desconsiderando que são modelos completamente diferentes e conduzidos por pessoas criativas. Eu costumo dizer que, ao projetar um prédio nós costumamos ver a evolução da construção, desde a fundação e paredes que vão aparecendo aos nossos olhos. Rapidamente você consegue pegar e medir quanto é necessário de investimento e esforço para atingir o objetivo. Já no software a realidade é completamente diferente, pois é emergente e adaptável em cada passo dado.
É hora de mudar e adotar atitudes mais ágeis que provoquem a colaboração e comprometimento entre todos os envolvidos no ciclo produtivo do software. Estamos falando de pessoas altamente criativas e não de máquinas ou “recursos”.
Em meados de 2001 os principais pensadores da época deram um grande passo reunindo-se para formação do “Manifesto para Desenvolvimento Ágil de Software” que representou um grande marco de mudança contra os modelos tradicionais de desenvolvimento de software com 4 pilares importantes:
- 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
A base principal disso tudo são pessoas felizes colaborando com o processo produtivo que requer adaptação frequente e muita atenção para atender a expectativa do cliente dentro dos objetivos do projeto. No modelo ágil, direcionamos todas as energias em criar um software funcionando orientado aos desejos do cliente que, sabemos, nunca são iguais aos pensamentos originais. Eles emergem e amadurecem junto com as entregas frequentes de software que são apresentadas em cada final de Sprint.
Ao questionar diversos desenvolvedores sobre documentação de software durante a manutenção, nenhum deles confirmou que abre qualquer documentação e sim vai direto ao código fonte resolver o problema. Imagina agora um cenário onde precisa fazer uma mudança, seja qualquer for o tamanho, como terá certeza que não gerou nenhum tipo de impacto no projeto? Não encontrará nenhum documento word que lhe dará essa garantia no código.
Para isso nós usamos outras abordagens no desenvolvimento ágil como TDD (Test Driven Development), orientando o desenvolvimento a testes unitários, gerando uma documentação de negócio no formato de testes que são executados automaticamente, garantindo que aquele código coberto pelos testes não sofreu impacto com a mudança de negócio. Na prática nós desenvolvemos primeiro os testes e depois as regras de negócios, já validando as mesmas com os testes, diminuindo inclusive o tempo de desenvolvimento.
Para alinhar a visão do cliente com as implementações realizadas, temos uma abordagem em desenvolvimento ágil conhecida como BDD (Behavior Driven Development) que permite orientar o desenvolvimento baseando-se no comportamento de negócio desejado escrito em histórias pelo cliente, fortalecendo mais ainda um dos princípios em desenvolvimento ágil que é o valor de negócio.
Para integrar o código fonte desenvolvido usamos a abordagem de CI (Continuous integration), tendo um mecanismo automático para geração de versão e entrega do software funcionando, permitindo uma visibilidade do produto que está sendo entregue e indo além, usando os testes unitários produzidos e outras abordagens para garantir a integridade do código fonte e sua fidelidade aos valores de negócio garantidos dentro dos testes e outros padrões de projeto, como arquitetura em camadas favorecendo a reutilização de software.
A informação mais importante que devemos passar ao nosso cliente é que estamos aptos a fazer mudanças no software e adaptar ao final de cada ciclo para juntos atingirmos os valores de negócio do projeto. Ter o cliente próximo esclarecendo as dúvidas faz a diferença e reduz todo o ruído de diferenças de entendimento, permitindo esclarecer o mais breve possível sempre que aparecer qualquer impedimento ou mudança de rumo.
As pessoas tratadas como pessoas e incentivadas a colaborar produzem cerca de 10 vezes mais, pois são desafiadas a dar o melhor de si e valorizadas pelos resultados proporcionados à equipe de uma maneira rápida, pois com ciclos curtos de projetos conseguirmos alinhar rapidamente qual o resultado de cada equipe de projeto. É muito importante que todos se sintam importantes no processo. Por isso incentivar a participação e compartilhamento de informações resulta em comprometimento.
O desenvolvimento de software como um trabalho criativo e intelectual requer uma atenção dobrada na equipe, motivando e alinhando expectativas, além de iniciativas que valorizem cada entrega de projeto com sucesso, mesmo que seja tirando uma foto da equipe e uma Coca-Cola gelada para cada. Na maioria das vezes a intensão vale mais que a força empregada e, ter um ambiente de trabalho feliz é o maior impulsionador de qualquer projeto.
Compartilhe, escute e provoque criando desafios animadores nas pessoas para que juntas formem uma grande força em prol de uma causa e não de uma regra. Conquiste liderando e multiplique a visão por todos do projeto removendo impedimentos e burocracia que não contribuem em nada com o resultado.
Para ter a melhor estratégia de desenvolvimento em um projeto de software inicie pela formação da equipe e crie mecanismos de qualificação e demais incentivos para manter um grupo forte e orientado a resultados. Acabo por acompanhar muita gente preocupada com quanto tempo uma pessoa está parada na frente do computador e não com o resultado que essa pessoa proporciona ao projeto.
Até hoje venho observando em projetos de “software civis tradicionais” gerentes e analistas estimando atividades para outras pessoas assumirem o compromisso de programar. É logico que sabemos de antemão que os desenvolveres vão concordar e que você já vai dar o prazo sabendo que não será entregue, criando o que eu batizei de mundo “Alice do Software”, onde todos sabem que não vai dar certo, mas continuam vivendo até não aguentarem viver mais dentro do caos e darem o grito de mudança.
De uma vez por todas vamos entender que resultado em um projeto de software se dá pela energia criativa para construir uma solução simples e rápida e não pela quantidade de força empregada ao longo do tempo. Para ter comprometimento é fundamental compartilhar com todos do projeto as informações e objetivos e abrir espaço para escutar e colaborar.
O dia que descobrirem, finalmente, que desenvolvimento de software é empírico, mutável e não pode ser encarado como um projeto de uma obra civil, teremos atitudes diferentes com pessoas felizes desenvolvendo com qualidade desde o início e entregas rápidas alinhando a expectativa de negócio.
Para saber mais:
De 0 a 10, o quanto você recomendaria este artigo para um amigo?