O ciclo de vida do desenvolvimento de Software



O Miguel é CTO na Affinity e Product Manager do…
As metodologias de desenvolvimento de software estão ainda no princípio da sua evolução.
O objetivo de qualquer equipa de desenvolvimento deve ser sempre entregar uma solução para o problema de um user da maneira mais simples para ambas as partes. No entanto, construir uma solução simples que corrija o problema de um utilizador não é tão fácil quanto parece.
Acredito que ainda temos muito a descobrir no âmbito do desenvolvimento de projetos em equipa. Passámos da era do homo sapiens, em que saíamos das cavernas para caçar e recolher, para uma era em que percebemos que nem toda caça acontece como planeada. Também passámos de uma forma generalista de construção de projetos para uma abordagem mais especializada e, portanto, surge a necessidade de novas regras e diretrizes para trabalharmos em conjunto.
O Waterfall foi a nossa primeira abordagem às metodologias de desenvolvimento de software. As pinturas rupestres nas paredes das cavernas. Foi a estratégia usada pelos líderes para partilhar as suas visões e planos. Scrum e Kanban são hoje as estratégias de líderes experientes – sobreviventes de caçadas dolorosas. São estratégias que têm em consideração as mudanças ao plano inicial, assumindo que as coisas não acontecem exactamente como planeamos. São estratégias que nos tornam mais ágeis.
Apesar desta transição para o Agile ter sido uma melhoria extremamente significativa para os processos de desenvolvimento. Precisamos de planear, construir, testar, implementar, manter… em equipa, de forma mais eficiente.
Mesmo quando seguimos uma metodologia ágil, ainda estamos a realizar muitas tarefas ineficientementes. A maioria das nossas tarefas está relacionada com corrigir os nossos erros, planear os nossos próximos movimentos, comunicar e comunicar novamente, para evitar mais erros.
A maior parte do nosso tempo não é despendido a trazer mais valor aos nossos utilizadores, através do lançamento constante de novas features.
A maior parte do nosso tempo é despendido na correção ou prevenção de erros humanos. Ao que nós chamamos educadamente de mudanças de scope de projecto e que nascem em loops de feedback e bugs reportados.
Quanto mais um projeto cresce, menos novas features passamos aentregar. Quanto mais um projeto cresce, mais tempo a equipa gasta na sua manutenção e correção de problemas, e menos ágil o projeto se torna.
Mesmo assim, seguir metodologias ágeis é a melhor forma de conduzir um processo de desenvolvimento. Porquê? Porque a alternativa é seguir um plano rígido que eventualmente falhará. Mesmo o plano mais documentado – baseado em meses de investigação – não é bom o suficiente para evitar a falha. Porquê? Porque assim que construímos algo, reunimos novas informações ao fazê-lo. Informações que podem colocar o plano perfeito em cheque. Assim que o resultado é posto à prova por end-users, eles reagirão a essa informação.
Dito isso, temos primeiramente que aceitar que muito do tempo que gastamos nos nossos projetos será “um desperdício” e que, nem sempre vamos saber qual é a melhor solução para os problemas do nosso utilizador. A melhor solução é na maioria das vezes encontrada durante o processo de construção. Quando começamos, achamos que temos a melhor solução e, claro, devemos começar a construir com base nessa primeira visão. Ou seremos bloqueados pela paralisia da análise. No entanto, também devemos estar cientes de que o plano baseado nessa primeira visão será inevitavelmente afectado pela falta de informação inicial que só acontecerá após algum feedback do utilizador, alguma prova de conceito ou alguma interação com um MVP pelo utilizador.
Outras vezes, o plano poderá ser mal orientado pela falta de comunicação entre os membros da equipa. Colocar todos na mesma página é uma tarefa difícil. Escrever uma documentação extensa e rigorosa e partilhar conhecimento com todas as partes interessadas pode parecer a melhor estratégia mas quanto mais detalhado for esse plano mais difícil poderá ser garantir que todos os envolvidos prestem atenção aos detalhes. Quanto mais pessoas se envolvem na decisão, mais difícil ficará chegar a uma visão comum.
Assim, mesmo o ‘melhor plano’ eventualmente falhará ou pelo menos precisará de algumas mudanças.
Tendo isso em conta o melhor é mesmo aspirar por falhar o mais rápido possível.
Quanto mais rápido soubermos onde estamos errados, mais cedo ajustaremos a direção. Uma pequena correção no início do nosso projeto trará mais vantagens do que uma grande mudança no final do jogo. A melhor abordagem é aquela que nos torna mais ágeis e preparados para o desconhecido – para mudanças futuras – uma abordagem que seja amigável ao erro.
Precisamos de ser Ágeis para nos protegermos do desperdício de tempo, recursos e energia. De nós. Por essa razão, novos projetos têm crescido na área de metodologias de desenvolvimento. Projetos que nos ajudam a reduzir erros e que trazem abordagens híbridas entre o homem e a máquina:
Temos o Product Discovery que nos ajuda a validar a nossa visão com mais informações.
Temos uma fase de Ideação para melhorar a nossa criatividade em contextos de brainstorming.
Temos eventos Scrum para nos ajudar a gerir uma equipa de forma ágil.
Temos o Kanban para nos ajudar a manter um fluxo de trabalho constante observando o cycle-time da nossa equipa.
Temos ferramentas Code Complete, que baseadas em IA são capazes de nos mostrar as melhores maneiras de fazer código.
Temos decisões baseadas em dados que nos ajudam a decidir e nos impedem de dar saltos completamente às cegas.
Temos ferramentas de Code Quality para evitar possíveis problemas aplicando alguns padrões de código.
Temos Devops para automatizar as nossas tarefas de construção, teste e implementação.
Temos ferramentas de testes automatizados para impedir partir coisas que estão estáveis.
A complexidade dos projetos tecnológicos continuará a evoluir, trazendo novos desafios e necessidade de adaptação. Acredito que as metodologias de desenvolvimento serão uma aula incluída no âmbito escolar dos nossos filhos e vejo um futuro entusiasmante no que diz respeito à evolução na maneira como fazemos projectos. A tecnologia continuará a impulsionar a evolução, desafiando-nos a ir além do que sabemos e levando-nos a ajustar e melhorar metodologias no sentido de garantir que estamos prontos para qualquer caçada!
What's Your Reaction?

O Miguel é CTO na Affinity e Product Manager do Keywork. Interessado e com uma mente pioneira, passou por diversas experiências como lead engineer, product innovation, planning and software development hoje liderando a equipa de tecnologia da empresa. Quando fora do trabalho, o Miguel é um ávido leitor e gosta de aproveitar para fazer desporto e estar com os seus cães.
Excelente artigo! ?
Todos sabemos que o humano é o maior bug em todos os sistemas, desafiante é saber/conseguir prevenir essas ações.
Sou apologista de que uma metodologia bem aplicada, seja agile ou waterfall, tem efeitos positivos! Waterfall é mais straight forward, mais focada no objetivo final. Agile exige muito mais planeamento e estratégia para conseguir as entregas periódicas com qualidade garantida. Agile é uma metodologia que funciona muito bem quando bem aplicada (porém, hoje em dia, como todos querem pequenas alterações, por vezes acabam por não conseguir os resultados pretendidos culpando a metodologia).
Ainda assim, uma boa equipa com bons líderes acaba sempre por conseguir excelentes resultados! ?
Nunca esquecer a componente da segurança nos desenvolvimentos! É uma parte essencial para garantir fiabilidade e integridade dos dados fornecidos pelos utilizadores!