Scrum ? O prazer de planear, gerir e executar …

“Scrum é um processo interactivo e incremental para o desenvolvimento de produtos ou para a gestão de tarefas. A agilidade que suporta esta metodologia de gestão e planeamento, traz uma nova dimensão na capacidade de resposta, adequabilidade, eficácia e eficiência na gestão actual dos processos.” – by http://scrumpt.com/

Quando leio esta definição, questiono-me “ - Como é que eu poderia pensar o quão bom e inovador era abrir o Visio, fazer uns desenhos… Abrir o Project, definir umas tarefas, atribui-las… e fazer umas reuniões mensais?”. Hoje vejo, que tal pensamento se enquadra fora da realidade do que pode e deve ser uma gestão completa e eficiente de um projecto de software.
Mas comecemos do início. Longe vão os tempos em que me sentava numa cadeira na faculdade para ouvir os professores falarem (e quando o assunto era análise de sistemas) do UML, que primeiro era preciso analisar e só depois desenvolver. Sempre fui dessa opinião também, e ainda hoje acredito que é preferível gastar ¾ do tempo a planear e o resto a desenvolver. Isto porque, nunca é demais conhecer o sistema que estamos a desenvolver, conhecer o problema que temos entre mãos. Até aqui a teoria encaixava na perfeição, o pior estava para vir com a prática.

Com o entrar na vida profissional, constato que as coisas nem sempre acontecem como se espera, ou melhor, quase nunca. E hoje que escrevo este artigo, vem-me á memória o último projecto de grandes dimensões em que entrei. Um projecto grande no inicio que se transformou em megalómano. Um cliente exigente, que coloca vários desafios, propõe várias funcionalidades a cada reunião realizada e o sistema dispara. Cada vez que achávamos que tínhamos os requisitos prontos, vinha o cliente e dizia “ – Falta isto. - Era bom que o sistema fizesse isto. “ Chegámos a uma fase que estávamos a desenvolver em velocidade cruzeiro e o levantamento de requisitos ainda não tinha terminado. Situação impensável, cria-se um desgaste na relação cliente/equipa de desenvolvimento, sucedem-se reuniões atrás de reuniões, a maior parte delas inconclusivas e improdutivas. Conclusão, o sistema vai atrasando.

“- Para onde caminhar?”, é esta a questão que se coloca perante este cenário. Após algum tempo investido da minha parte em alguns produtos e soluções, há um que se destaca… Scrum. “- Será a solução? “. O Scrum é um processo que nos ajuda a gerir projectos de uma forma hábil. Os seus primórdios tiveram origem no sector automóvel, onde equipas pequenas e multidisciplinares conseguiam melhores resultados. Em 1995, um senhor chamado Ken Schwaber implementa e adapta este mecanismo em desenvolvimento de software. A indústria de software aceita muito bem esta metodologia. “- E porquê?”. Digamos que, de entre os vários interesses que a plataforma despertou, destaco o facto de podermos estimular e intensificar o contacto cliente/equipa de desenvolvimento, através da interrupção do projecto em períodos regulares de tempo. A estas acções dá-se o nome de Sprint. No fim de cada acção o cliente recebe as funcionalidades desenvolvidas, comprometendo-se a utilizá-las, a testá-las, apontando as qualidades assim como os defeitos.

A participação activa por parte do cliente torna-o não um mero comprador de software, mas sim um elo importante no desenvolvimento de todo o sistema, na criação do produto, contribuindo na pesquisa de requisitos, na análise, na formalização de tempos, na execução, nos testes, etc, responsabilizando-o durante todo o processo.

Alguns motivos que justificam a implementação desta prática:

· As mudanças são bem vindas e não alteram a produtividade;
· O cliente participa nas reuniões e vê o produto (sistema) a ser construído;
· A equipa produz o que foi previsto e pode ir acompanhando os resultados diariamente;
· A equipa determina a complexidade da “funcionalidade” e a mesma é debatida até que todos tenham “entendido”, com a participação do cliente;
· Todos os envolvidos conhecem o que deve ser feito e todos contribuem;
· A equipa trabalha em colaboração;
· Maior comprometimento da equipa;
· Mais tempo para o Scrum Master (Gestor de Projecto) concentrar sua atenção no que realmente interessa e não apenas em relatórios;
· A equipa consegue trabalhar e concentrar esforços no que é realmente importante no momento;

Enumeremos alguns conceitos úteis:

Entidades

· Cliente ou PO (product owner)- define as funcionalidades do produto, datas de lançamento e conteúdo, faz ajustes de funcionalidade e prioridade e aceita ou rejeita resultados obtidos;
· ScrumMaster ou Gestor de Projecto – representa a entidade responsável para o projecto, responsável pela aplicação dos valores e pelas práticas do Scrum, garante produtividade e funcionalidade da equipa e serve como filtro de interferências externas;
· Equipa de Desenvolvimento – trabalha de maneira auto-organizável, em grupos de 5 a 9 pessoas, é multifuncional (programadores, testers, designers, etc.) e só pode trocar de equipa no próximo Sprint;

Itens

· Product backlog – é o que deseja desenvolver-se no projecto, é uma lista que estabelece as actividades de acordo com a vontade do cliente;
· Sprint backlog – é o que será desenvolvido, conjunto de tarefas organizado temporariamente, com cronograma e tempo de execução;
· Burndown charts – é o gráfico de andamento do Sprint, relacionando horas e data em relação ao restante de tempo hábil para o término do ciclo;

Metodologia

· Planeamento – a equipa selecciona os itens do Product Backlog que irá comprometidamente executar; cria-se o Sprint Backlog, tarefas são identificadas e o tempo é estimado (1 a 16 horas);
· Revisão – a equipa demonstra o que foi realizado durante o Sprint. Geralmente, trata-se de uma reunião informal para abordar novas funcionalidades e estrutura do projecto;
· Retrospectiva – é realizada após cada Sprint e tem como objectivo ver o que funciona e o que não funciona. Toda a equipa participa na retrospectiva, inclusive o cliente;
· Reunião diária – são tipicamente rápidas, realizadas em pé e duram cerca de 15 ou 30 minutos. Assim, mantém-se o foco no que está a ser desenvolvido.