A indústria de software tende a oscilar entre processos complexos e a completa ausência de processos que governam e suportam o desenvolvimento de novos produtos. De um lado do espectro existem processos demasiado pesados com inúmeras regras e procedimentos, muitas vezes utilizados como ferramentas de microgestão. Do outro lado do espectro podemos encontrar processos soltos e desagregados entre si, que se revelam ineficientes e que não suportam convenientemente quem os está a usar.
As pessoas tendem a ficar intimidadas e/ou a reagir de forma adversa a processos demasiados rígidos. No entanto também reconhecem a necessidade de haver um processo em prática e normalmente reclamam quando o processo não existe de todo. Seja qual for o caso, o processo vigente aparenta ser inadequado à tarefa que se pretende executar.
O chamado “knowledge-based work” ou trabalho baseado em conhecimento, e onde se enquadra o desenvolvimento de software, assenta na descoberta e em ciclos de feedback. O conhecimento vai sendo adquirido à medida que as equipas de desenvolvimento se embrenham nos detalhes do produto que estão a desenvolver. À medida que esse conhecimento vai sendo adquirido deve então ser incorporado tanto no produto em desenvolvimento como no processo que suporta a equipa, e de forma eficiente e sustentável.
Em abordagens mais tradicionais de desenvolvimento, como o waterfall, em que os produtos são desenvolvidos em fases, é difícil perceber a real qualidade do código e subsequentemente do produto, até se dar entrada na fase de testes do projeto, que normalmente é das últimas fases a ocorrer. Na maioria dos casos, o feedback que é recebido neste ponto do projeto apenas pode ser usado para preparar a próxima versão do produto. O feedback não é recebido em tempo útil de maneira a que possa ser ainda incorporado na versão atual que se está a tentar libertar.
A grande vantagem das abordagens denominadas de ágeis é que se descobre rapidamente qual o real estado do produto numa fase em que é ainda possível influenciar o seu desenvolvimento. Com base nesta informação pode-se planear de forma sistemática a evolução do produto a curto prazo, o que é significativamente mais fácil do que planear a longo prazo, uma vez que há aspetos que são ainda desconhecidos e que só com o decorrer das atividades é que vão sendo conhecidos.
Na altura de definição de um processo pretende-se um modelo que seja suficientemente simples para ser facilmente adotado por uma nova equipa mas que ao mesmo tempo possa ser expandido à medida que a equipa vai ganhando conhecimento e se torna capaz de incluir esse conhecimento no modelo em uso. Um modelo equilibrado deverá compreender os seguintes aspetos:
– Estabelecer quais os princípios que governam o processo e identificar práticas que seguem e cumprem esses princípios. Não esquecer que princípios são algo universal no sentido em que podem ser aplicados em diversos contextos, no entanto as práticas são algo aplicável apenas em determinados contextos e que têm que ser adaptadas às circunstâncias.
– Criação de um ambiente que fomente a aprendizagem e que suporte o crescimento da equipa. Deve ser permitido à equipa poder experimentar diversas práticas de maneira a avaliar a(s) que se adequa(m) melhor ao seu contexto e às circunstâncias em que está a operar. Por outras palavras, é permitido à equipa falhar, no entanto a equipa tem que manter este aspeto sob controlo. O controlo é obtido através da implementação de ciclos curtos de feedback nomeadamente no que diz respeito aos métodos e práticas que a equipa está a usar. Estes ciclos curtos de feedback permitem à equipa que se possam cometer erros e ainda assim recuperar em tempo útil. O conhecimento que advém desses erros é informação valiosa que vai permitir à equipa expandir o seu modelo de forma eficiente e sustentável.
– Dar tempo suficiente às pessoas para se adaptarem ao novo processo e perceber como este funciona. Havendo uma transição para um novo processo as pessoas precisam de tempo para o assimilar. Não esperar que os resultados sejam visíveis imediatamente.
Definir um novo processo de raiz é uma tarefa gigantesca. O segredo está em ir dando pequenos passos e introduzir pequenas alterações em determinada altura ao processo vigente. É também fundamental combinar estes aspetos com uma cultura de melhoria contínua e criar um ambiente que permita que as pessoas possam aprender à medida que vão evoluindo e que possam introduzir o resultado dessa aprendizagem também no processo.
Vamos tomar como exemplo o Scrum, uma vez que é uma abordagem ágil largamente conhecida nos dias de hoje e de alguma maneira representa aquilo que a indústria de software reconhece como sendo o significado de Agile. Scrum é um esqueleto (ou uma estrutura se preferirem) que nos permite criar um processo de desenvolvimento de um produto de software que pode efetivamente ser considerado ágil.
O Scrum é composto por um pequeno conjunto de regras simples e uma equipa pode ser facilmente iniciada naquilo que é o Scrum com apenas alguns dias de formação e treino. Isto permite-nos definir um método de trabalho que não é demasiado pesado para quem o está a usar pela primeira vez e que ao mesmo tempo possibilita que seja expandido à medida que se vai ganhando experiência. Nessa altura as pessoas começam a usar a sua intuição e experiência para lidar com problemas mais complexos que não são prescritos pelo Scrum.
Estas são algumas das razões que levam o Scrum a ter uma grande propagação na indústria de software. A sua fácil adoção por indivíduos ou pequenas equipas de desenvolvimento e o facto de as suas práticas poderem ser aplicadas praticamente “out-of-the-box” tal como preconizadas pelo Scrum Guide. O Scrum é um ótimo ponto de partida para equipas que pretendem agilizar e ao mesmo tempo aligeirar o seu processo de desenvolvimento uma vez que cria a disciplina necessária exigida por um processo que se quer ágil e ao mesmo tempo é capaz de suportar a equipa de forma eficiente e sustentável no desenvolvimento de produtos de software.
Partilhar:
