“Não está nos requisitos”, tornou-se uma das frases mais faladas por um gestor de projetos nos dias que correm, principalmente se este utiliza Waterfall como metodologia de gestão de projetos. Para quem não sabe, a metodologia Waterfall pressupõe que antes de começar qualquer tipo de desenvolvimento, todos os requisitos devem estar perfeitamente fechados e aceites pelo cliente. Trata-se portanto de um processo linear, isto é, primeiro são definidos requisitos, é depois criada uma work breakdown structure (WBS), as equipas de projeto elaboram estimativas para as tarefas a serem executadas e por fim o gestor de projetos constrói o plano de projeto com tarefas, durações, precedências, atribui recursos e calcula quando é que o projeto vai terminar e quanto vai custar. De uma forma muito simplista, é isto que acontece num típico projeto Waterfall. Deixo só a nota que nem sempre é assim, pois podemos utilizar técnicas de planeamento como por exemplo elaboração progressiva ou rolling-wave, mas deixo a explicação dessas técnicas para outras núpcias. 

 

Hoje quero falar-vos de outro tipo de projetos, os projetos de software. Normalmente, e salvo algumas exceções onde os projetos podem ser críticos (por exemplo software de uma central nuclear, ou de um foguetão da NASA), a grande maioria do software produzido não apresenta graus elevados de criticidade. Isto faz com que os requisitos sejam alterados à medida que o projeto vai decorrendo, seja porque o negócio ou o mercado evoluiram, seja porque deixam de fazer sentido algumas funcionalidades que inicialmente se achavam fundamentais.

 

O ciclo de vida de um software é cada vez mais curto, impõe-se mudança constante, e as empresas têm que se adaptar continuamente de modo a não ficarem para trás. Não faz sentido que o desenvolvimento de um software leve tanto tempo como leva nos dias de hoje. É recorrente empresas gastarem meses ou anos na atualização ou construção de um software. Isso torna-as mais frágeis comparativamente aos seus adversários.

 

É por isso que muitas empresas se voltam para metodologias mais ágeis na gestão dos seus projetos. A gestão de projetos ágil transforma o processo em algo não linear, e por via de múltiplas iterações vai-se melhorando ao longo do tempo. Assim, fará sentido adoptar metodologias ágeis quando existe muita incerteza nos requisitos, quando é necessário realizar entregas de uma forma incremental ou quando é muito importante obter um experiência de utilizador verdadeiramente adaptada às necessidades do cliente. A metodologia que vos vou falar hoje é uma das mais famosas em todo o mundo, vou falar-vos de SCRUM.

 

Outra forma de trabalhar?

O SCRUM baseia-se em três grandes pilares, a transparência, inspeção e adaptação:

 

Transparência – Este pilar dita que deve existir uma visão clara e comum de quais os objetivos do projeto por todos os interessados neste. Um grande exemplo de transparência seria a criação de uma definição comum do que significa “tarefa realizada”, já que por vezes um stakeholder entende que uma tarefa já se encontra realizada enquando outro não concorda com essa mesma definição.

 

Inspeção – Este pilar dita que durante o decorrer do projeto sejam realizadas inspeções ao trabalho numa base regular, com o grande objetivo de perceber como o projeto se encontra a evoluir, e se existem desvios a considerar ou possíveis alterações aos objetivos do projeto.

 

Adaptação – Este pilar dita que é fundamental ajustar e adaptar o processo. Se numa inspeção se detetar que existem problemas que podem ser corrigidos, ou se verifique por exemplo que o objetivo do projeto mudou devido a alteração de tendências no mercado, deve-se refletir essa nova realidade.

As equipas de um projeto SCRUM são normalmente compostas por uma Development Team, um Product Owner e um ScrumMaster.

 

Development Team – De uma forma simples, é a equipa responsável por realizar todas as tarefas necessárias para completar o trabalho necessário (análise, desenvolvimento e testes);

Product Owner – É a pessoa responsável por gerir o product backlog (explicado mais à frente), incluindo a sua priorização, precisão, visibilidade e compreensão comum por toda a equipa;

ScrumMaster – Responsável por assegurar que as boas práticas de SCRUM estão asseguradas e que são realizadas. Normalmente deve ser um líder para a Development Team, removendo obstáculos, facilitando eventos e fornecendo coaching. Para além disso, também deve auxiliar o Product Owner na gestão do backlog, comunicando sempre ao máximo a visão e objetivos à Development Team.

Eventos

A metodologia SCRUM é composta por várias atividades, também chamadas de eventos. Alguns exemplos são os sprints, as sprint planning meetings, os daily scrums, as sprint review meetings e as sprint retrospectives.

 

1) Sprints

Um sprint pode ser considerado um mini projeto dentro do projeto global. Tem uma duração limitada (por exemplo duas ou três semanas), sendo que durante o sprint não existe rotação da development team. No fim do sprint, tem que existir sempre um produto final (por exemplo um módulo do projeto global). O próprio sprint inclui a sprint planning meeting, daily scrums, a sprint review meeting e a sprint retrospective.

 

2) Sprint Planning Meeting

A sprint planning meeting tem como principal objetivo determinar o que será entregue no fim do sprint, e de que forma será realizado o trabalho. O product owner apresenta todos os items ainda em backlog, e toda a equipa os discute a fim de obter um entendimento comum do que falta realizar. A development team deve então estimar o que poderá ser entregue no sprint para que se consiga obter os seus objetivos. Por fim a development team deve ainda definir como vai ser atingido o objetivo, e como se vai organizar para o atingir.

 

3) Daily Scrum

A daily scrum trata-se de uma reunião diária de 15 minutos. Durante esta sessão a development team deve trocar informação acerca das atividades e dos problemas que possam ter surgido. Normalmente, cada membro da equipa deve responder às seguintes três perguntas:

 

O que realizei desde a última reunião?
O que será realizado até à próxima reunião?
Que obstáculos encontrei?

 

O ScrumMaster deve-se certificar que esta reunião acontece diariamente, e que é útil na resolução de problemas.

 

4) Sprint Review

Trata-se da reunião que decorre no fim do sprint, com o objetivo de verificar o impacto deste no projeto global, bem como realizar alterações ao backlog se necessário. Normalmente a development team demonstra o que foi realizado no sprint, e o product owner em conjunto com o cliente verificam se vai de encontro às suas necessidades. Seguidamente, o product owner e a development team devem olhar para os restantes items em backlog e determinar de uma forma macro o que fazer no próximo sprint.

 

5) Sprint Retrospective

É nesta sessão que existe oportunidade para melhorias dentro do próprio processo. No fim de cada sprint a equipa deve refletir sobre o processo, por exemplo, o que correu bem ou o que podia ser melhorado. A equipa deve ainda focar-se nos stakeholders, relações, processos e ferramentas. Caso existam oportunidades que mereçam ser exploradas, é aqui que devem ser levantadas.

 

Artifacts

Discutidas as atividades existentes na metodologia, resta referir ainda os entregáveis, isto é os artifacts. Existem vários tipos de artifacts, como por exemplo o product backlog, o sprint backlog e a definition of done

 

1) Product Backlog

Trata-se de uma lista ordenada de tudo o que ainda é necessário realizar para a conclusão do projeto, e funciona como uma fonte única de requisitos. O backlog pode evoluir consoante o projeto evolui, isto é, caso as necessidades do cliente ou do mercado mudem. Desta forma deixamos de ter um âmbito tão fechado e existe abertura para adaptar o produto às reais necessidades do cliente. O backlog deve ainda conter melhorias e correções que foram sendo identificadas ao longo do projeto. Items com prioridade mais alta devem ter mais detalhe, com estimativas mais precisas. Items com menor prioridade podem ser desenvolvidos ao longo do tempo.

 

2) Sprint Backlog

Tratam-se de todos o items do backlog que são selecionados para um determinado sprint.

 

3) Definition of Done

Toda a equipa tem que concordar no que significa “tarefa realizada”. Para que não exista ambiguidade entre os elementos da equipa, deve ser trabalhada a noção do que significa “tarefa realizada”. Essa definição deve ser definida por toda a equipa, e antes do trabalho iniciar.

 

Conclusões

A mensagem que se pretende passar com este artigo é que nem sempre é adequado optar pela metodologia Waterfall. Existe uma frase muito famosa de Henry Ford que diz:

 

“If you always do what you’ve always done, you’ll always get what you’ve always got.”

 

Sendo que a grande maioria dos projetos de software derrapa, pode ser proveitoso dar uma oportunidade a este tipo de metodologias mais ágeis e verificar os resultados. Dei-te uma visão muito superficial do que é o SCRUM, mas existem muitas outras que merecem ser exploradas, como por exemplo, Extreme Programming (XP), Feature-Driven Development (FDD), Dynamic Systems Development Method (DSDM), Crystal ou Lean Software Development.

 

Caso se deparem com projetos em que a mudança é constante ou onde os requisitos não se encontram perfeitamente definidos, pode ser uma oportunidade para introduzir uma metodologia ágil. Nunca esquecer ainda que é vital o envolvimento do cliente, principalmente no fim de cada sprint, de forma a verificar se o que foi realizado vai de encontro ao que é esperado. 

 

Em breve falo-vos mais sobre agile, temos muito para aprofundar :).