Há alguns anos vem surgindo a necessidade de se conduzir projetos de forma mais ágil do que os métodos tradicionais onde muitas pessoas dizem que não tempo para criar planos de gerenciamento de projeto ou de então ler os planos. Os projetos precisam ser mais dinâmicos.
Um dos métodos ágeis em projetos mais utilizados no mundo é o Scrum, onde há duas organizações que seus organizadores fundaram, a Scrum Alliance e Scrum Org. Essas duas organizações tem programas de certificações, onde se destaca a certificação CSM – Certified Scrum Master – da Scrum Alliance – e PSM – Professional Scrum Master – da Scrum Org.
Ainda há muitas pessoas resistentes ao framework Scrum que alegam que o Scrum não pode ser utilizado em qualquer projeto e que só podem ser utilizado em projetos de desenvolvimento de software ou na área de TI. Isso é um mito. Mais a frente será demonstrado um exemplo de um projeto de instalação de Rede NGN com a utilização do Scrum.
Antes de demonstrarmos um exemplo prático, é necessário citarmos um pouco da teoria Scrum para que o entendimento fique compreendido para que não haja dúvidas durante a aplicação prática.
O Framework Scrum
Figura 1 – Framework Scrum – Fonte: http://www.agileforall.com
Papéis e Responsabilidades
Product Owner
O Product Owner representa os interesses do cliente ou da alta administração da empresa. Ele é responsável por definir os produtos e a prioridade de entrega em cada um dos produtos dentro de uma Sprint. Ele também é responsável por sanar as dúvidas do time durante o planejamento da Sprint e no decorrer da Sprint.
Figura 2 – Product Owner
Scrum Master
O Scrum Master é o cão de guarda do Framework Scrum. Ele garante que os processos do Scrum estejam sendo seguidos e que não haja violação das regras. Ele também protege o time do projeto de interferências externas que possa tirar o foco do time e é responsável por tirar os possíveis impedimentos que possam ocorrer durante a Sprint.
Figura 3 – Scrum Master
Development Team
O Development Team é responsável pela execução do projeto. A esquipe é auto-gerenciável e ao final da Sprint precisam apresentar ao Product Owner a entrega do produto funcionando. São responsáveis também por estimar a pontuação de cada produto na qual irão se comprometer a entregar no final da Sprint.
Figura 4 – Development Team
Cerimonias
No Scrum há 4 cerimonias a saber:
Sprint Planning Meeting: É uma reunião onde os três papéis do Scrum estão presentes onde o Product Owner explica para o Development Team o detalhamento de cada produto e o Development Team estima o esforço de cada produto através da técnica Planning Poker. O resultado dessa reunião será de uma lista priorizada dos produtos e o Development Team irá se comprometer a entregar o que ela julga ser capaz, sem sofrer nenhum tipo de pressão do Product Owner ou de qualquer outra pessoa. A Definição de Pronto de cada produto deverá ser estabelecida nesta etapa, uma vez que durante a Sprint Review Meeting cada produto será confrontado com a Definição de Pronto de cada produto. Para saber mais sobre a técnica Planning Poker, acesse aqui.
Daily Scrum Meeting: É uma reunião diária feita somente entre os membros do Development Team com duração de 15 minutos, e é recomendado que seja feito no mesmo local. Cada membro precisa responder três perguntas: o que você fez da última reunião até agora? o que você fará até a próxima reunião? há algum impedimento que impeça suas atividades? Caso haja algum impedimento, o Scrum Master precisa ser acionado. Tanto o Scrum Master quanto o Product Owner podem participar da reunião, no entanto, não podem influenciar e devem estar apenas de corpo presente, sem falar uma única palavra, salvo o Scrum Master, caso o Development Team esteja violando algum processo do Framework Scrum.
Sprint Review Meeting: É a reunião onde todos os papéis participam e o Development Team apresenta as entregas dos produtos funcionando para o Product Owner, onde este poderá aceitar ou não. O Product Owner, se desejar, poderá convidar outras pessoas para participar desta reunião. E cada produto será confrontado com a Definição de Pronto realizada durante o Sprint Planning Meeting.
Sprint Retrospective Meeting: É uma reunião realizada após o término de cada Sprint entre os membros do Development Team de lições aprendidas, onde serão abordados o que foi mal e o que precisa ser melhorado para a próxima Sprint e o que foi bem e que precisa ser mantido para a próxima Sprint.
Artefatos
No Framework Scrum há 4 artefatos a saber:
Product Backlog: É a lista de produtos que o projeto precisará entregar, muitas das vezes os produtos são descritos em forma de estórias (Users Stories), como por exemplo: “Como professor gostaria de acessar o sistema de notas online para que possa consultar as notas dos meus alunos em qualquer lugar que eu esteja.”
Sprint: É o período de tempo que leva de 2 a 4 semanas para serem desenvolvidos os produtos planejados para a Sprint corrente.
Sprint Backlog: São os produtos selecionados pelo Development Team e na ordem priorizada pelo Product Owner na qual o Development Team se compromete à entregar na Sprint corrente.
Burndown Chart: É o gráfico de acompanhamento diário do andamento das atividades durante a Sprint. No eixo Y do gráfico é o indicativo dos pontos e no eixo X é o indicativo do tempo.
Figura 5 – Burndown Chart – Fonte: http://www.slideshare.net
A Sprint do gráfico acima tem 20 dias e a pontuação é de 30. A linha vermelha deve ficar em cima da linha azul ou abaixo. Caso fique acima, é porque há atraso na Sprint.
Pilares
É importante ressaltar que o Scrum possui três pilares:
Figura 6 – Pilares do Scrum Fonte: http://www.evertonbuenolima.wordpress.com
Transparência: Há uma visão clara e objetiva de todo o processo, por ser visual e que facilita a comunicação de todas as partes interessadas.
Adaptação: Como há reuniões de acompanhamentos diários, qualquer adaptação que seja necessária é fácil de implementá-la.
Inspeção: A cerimonia Daily Scrum Meeting permite que seja inspecionado diariamente.
Exemplo prático
Após o alinhamento da teoria do Framework Scrum, vamos a um exemplo prático de um projeto de instalação de uma Rede NGN (Next Generation Network) em uma operadora de telefonia no Brasil.
Escopo: será feita instalação de Medias Gateways em 6 (seis) cidades brasileiras distribuídas em 8 sites com escopos diferentes entre si.
A Estrutura Analítica do Projeto (EAP) está demonstrada na figura 7 abaixo:
Figura 7 – Estrutura Analítica do Projeto de implantação de uma Rede NGN
Os sites do projeto são: FLA PV, MCO MS, RCE AM, RJO EN, RJO AM, SDR RC, SPO PH e PSO IG.
Durante a Sprint Planning Meeting, o representante da operadora de telefonia, que assume o papel de Product Owner estabeleceu a seguinte prioridade entre os sites, que são os produtos do projeto:
Tabela 1 – Lista priorizada de sites pelo representante da operadora de telefonia (Product Owner)
Durante a mesma Sprint Planning Meeting, o fornecedor se comprometeu a entregar apenas os três primeiros sites da lista de priorização durante uma Sprint de 4 semanas (1 mês) uma vez que a velocidade estimada do Development Team é 20 pontos por Sprint, e fez a estimativa de pontuação para cada um dos 3 sites:
Tabela 2 – Pontuação dos sites pelo Fornecedor (Development Team)
Os sites que não foram estimados serão estimados na próxima Sprint Planning Meeting, para a Sprint 2.
O produto final da Sprint Planning Meeting, será a os sites priorizados com as suas respectivas pontuações e também a definição das atividades obedecendo a pontuação do produto correspondente e a definição de pronto de cada produto.
Tabela 3 – Atividades da Sprint Pontuadas
Em relação a definição de pronto, podemos dizer, resumidamente, que para cada site estar pronto, deverá estar o link de acesso sem intermitência e com taxa de erros inferior a 2%.
Concluída a Sprint Planning Meeting, a Sprint poderá ser iniciada, seguindo os processos do Scrum já citados no início deste artigo.
Há uma ferramenta utilizada em métodos ágeis chamado Quadro de Kanban ou simplesmente Kanban, onde não faz parte do Framework Scrum, mas na maioria das aplicações do Scrum o Kanban é utilizado, e pode ser adaptado de acordo com as características de cada projeto e gosto pessoal. Para saber mais sobre o Kanban, clique aqui.
Com isso, estabelecemos o seguinte Kanban para este projeto:
Figura 8 – Kanban – Projeto da Rede NGN
Na coluna “FAZER” constam as atividades apenas das atividades da Sprint corrente, e na coluna “BACKLOG” constam todos os produtos do projeto.
Para referência, a ferramenta utilizada para gerar este Kanban foi o Kanbanflow, ferramenta online gratuita. Para acessar essa ferramenta acesse aqui.
A medida que o projeto for avançando, as atividades vão sendo deslocadas para as colunas “FAZENDO” e “PRONTO”. Caso haja alguma pendência no decorrer da Sprint, deve ser colocada a atividade na coluna “PENDÊNCIAS”.
As atualizações devem ser feitas sempre durante a cerimonia Daily Scrum Meeting.
Quando as atividades forem ficando prontas, o gráfico Burndown Chart precisa ser atualizado. Ele irá dizer se a Sprint está indo bem ou mal.
Vamos supor a situação da figura do Kanban abaixo onde as atividades no dia 3 tem atividades como prontas a Realização da Vistoria e Instalação do Rack, Equipamento e Placas do site RJO AM. As duas atividades totalizam 3 pontos. Verificar a tabela 3 acima.
Figura 9 – Kanban – Atividades prontas para atualização do Burndown Chart
Com essas duas atividades prontas no dia 3, precisa-se atualizar o Burndown Chart, como mostrado na figura 10 abaixo.
Figura 10 – Burndown Chart – dia 3
Quando a linha do realizado está abaixo da linha do planejado no Burndown Chart quer dizer que a Sprint está adiantada.
Já o Burndown Chart da figura 11, mostra que no dia 9 teve um leve desvio e no dia 12 foi recuperado o desvio. Já dos dias 15 a 18, teve uma tendência de desvio e alguma ação precisa ser tomada.
Figura 11 – Burndown Chart – Desvios
Considerações
Alguém pode questionar que com a abordagem Scrum não é possível ter um horizonte de quando o projeto estará sendo concluído.
Para este projeto em questão (Projeto da Rede NGN), o time alocado para esse projeto tem uma velocidade estimada de 20 para Sprints de 4 semanas (30 dias). Para termos uma estimativa de prazo de todo o projeto, basta estimar a pontuação de todos os produtos do projeto e dividir pela velocidade do Development Team. Vamos supor que a pontuação de todo este projeto seja 60 (sessenta). Ao dividirmos a pontuação de todo o projeto (60) pela velocidade do Development Team (20), teremos a duração do projeto de 3 Sprints, e como cada Sprint tem duração de 30 dias, o projeto terá uma estimativa de 90 dias ou 3 meses.
Em projetos do modo tradicional, projetos muitos longos também é apenas uma previsão. É uma visão em alto nível. O ideal é que seja planejado em detalhe como é feito para cada Sprint, e no método PRINCE2, há uma previsão também alto nível de todo o projeto, mas a gestão é feita por estágios, onde esses tem um planejamento detalhado.
A principais barreiras de se implantar o Scrum nas organizações é a questão da resistência e mudança de cultura.
Em termos ferramentais, precisará ter um quadro, Post-Its e canetas. O quadro tem que estar visível para todos, uma vez que um dos pilares do Scrum é a transparência e tem que estar visível para todos.
Para que o Framework Scrum dê resultados, é necessário que os processos como as cerimônias não sejam burladas e que os papéis de Scrum Master, Development Team e Product Owner sejam bem definidos.
Vantagens
A vantagem do Scrum em relação aos métodos tradicionais é que entrega valor para o cliente ao término de cada Sprint, enquanto que nos métodos tradicionais as entregas são feitas em sua maioria ao término do projeto.
E as entregas são priorizadas no que gerá mais valor para o cliente, e os que estão na parte de baixo da lista de priorização, algumas vezes são não são mais necessárias, o que evita gastar tempo desnecessario.
Para complementar o Scrum, poderá ser gerada uma documentação do tipo Release Plan, onde é apresentado ao cliente a entregas das principais funcionalidades e produtos em um período de tempo.
Abaixo deixo um vídeo que explica em 10 minutos o Framework Scrum.