Com o advento e crescimento das metodologias ágeis em projetos de software, o mercado tem demandado cada vez mais vagas para profissionais com perfil de gerenciamento que são denominados Scrum Masters no Scrum.
Porém, com este crescimento foi criado um vão entre gerenciamento de projetos formal e o gerenciamento de projetos ágeis, de forma que profissionais com perfil ágil sinta falta de habilidades gerenciais de escopo, custo e prazo para gerenciar e controlar um projeto dependendo de seu tamanho e número de funcionalidades.
Com isso, este artigo visa explanar sobre uma técnica pregada pelo PMBOK como sendo boa prática na fase de planejamento, denominada WBS (Work Breakdown Structure) e como esta técnica pode se integrar ao Product Backlog, documento criado no início de um projeto Scrum para listar as funcionalidades de um sistema; funcionalidades esta que são priorizadas pelo cliente, denominado Product Owner ou Product Manager.
Para que possa haver uma integração entre uma WBS e estórias de um backlog, o artigo irá descrever um pouco sobre conceitos utilizados e empregados pela metodologia ágil Scrum. Martins (2007, p.253) diz que o projeto Scrum começa com uma visão, composta por requisitos e funcionalidades que concretizam uma lista de tarefas, denominada product backlog.
Este documento contém uma lista de user stories (estórias) priorizadas por um product owner, denominado pelo Scrum como o cliente do software. Esta é a pessoa responsável por definir o que será feito primeiro e validar ao final se o que foi feito está conforme o esperado. Ao final da iteração, o que foi desenvolvido é apresentado ao cliente em uma reunião e antes do início da próxima iteração é feita uma reunião de retrospectiva, onde é possível extrair lições aprendidas.
Papéis do Scrum segundo Schwaber e Beedle (2002, cap.3):
- Product Owner: pode ser definido como o sponsor do projeto, é o responsável por definir e priorizar as funcionalidades do produto;
- Scrum Master: é o responsável por forçar os valores e práticas do Scrum, remover os obstáculos e ensinar o processo a todas as pessoas, garantindo também que todas elas sigam o processo;
- Scrum Team: equipe responsável por desenvolver o produto, esse time está ligado diretamente ao trabalho e suas características são: ser multifuncional, ser composta por grupos pequenos, de 7 a 10 pessoas.
Fases do Scrum segundo Schwaber e Beedle (2002, cap.3):
- Sprint Planning: é uma reunião com duração de 4 horas antes do início de um sprint, para alinhar com o Product Owner o que será feito dentro do próximo sprint;
- Sprint: é o tempo estimado pelo time para produzir, testar e homologar determinadas funcionalidades, que serão priorizadas pelo product owner;
- Daily Scrum: são reuniões diárias, com duração de 15 minutos, onde cada membro do time coloca em um quadro o que fez no dia anterior, o que fará para o dia seguinte e as barreiras, que terão de ser desimpedidas pelo Scrum Master. Essas tarefas devem ser colocadas em um quadro que fique visível para o time, em forma de post its;
- Retrospective ou Sprint Review: é uma reunião de lições aprendidas que ocorre após a entrega de um sprint e tem como objetivo analisar se o que foi feito está bom e o que pode ser melhorado.
Para estimar o número de funcionalidades por sprint, Schwaber propõe um método chamado poker game, onde cada membro do time dá uma nota, que equivale a um peso.
Os pesos são denominados de acordo com uma Progressão Aritmética, ou seja, 1, 2, 3, 5, 8, 13 e 21. O peso que se repetir mais vezes pelos membros do time é o peso que valerá para a funcionalidade. Ao total de funcionalidades, os pesos são somados e essa é a estimativa de entrega em um sprint. Caso o time estime quatro funcionalidades em 40 pontos e entregue no prazo de 30 dias, essa será a velocidade de entrega do time, ou seja, seu time-box; de forma que no poker game dos próximos sprints, o time poderá estimar para desenvolvimento o número de funcionalidades que não ultrapasse 40 pontos.
Schwaber propõe também o controle de volume de trabalho pendente, chamado também de burn down charter, onde após cada reunião diária é acrescido em um gráfico o que foi feito em horas e o quanto falta para o término, no prazo de 30 dias.
WBS (Work Breakdown Structure)
Segundo PMBOK (2008, p.112), a WBS é uma decomposição hierárquica orientada a entrega do trabalho a ser executado pela equipe do projeto. A WBS deve definir o escopo completo do projeto, ou seja, todas as funcionalidades levantadas junto ao cliente.
Após o projeto e declaração de escopo aprovadas, a WBS deve ser construída, de acordo com PMBOK (2008, p.112) para auxiliar as partes interessadas a visualizar as entregas do projeto.
Dessa forma, a WBS deve ser construída seguindo uma estrutura hierárquica, de forma que as atividades sejam desenhadas partindo da forma genérica à específica, sendo desdobradas a cada nível da mesma (PMBOK, 2008, p.112).
PMBOK (2008, p.114) expõe que a decomposição é a subdivisão das entregas do projeto em
componentes menores e mais facilmente gerenciáveis, até que o trabalho e as entregas estejam
definidos até o nível de pacotes de trabalho.
Um pacote de trabalho é o nível mais baixo da WBS, segundo PMBOK. Dessa forma o desdobramento pode ocorrer em subprojetos ou fases; de fases em módulos ou grupos de funcionalidades; e de módulos em pacotes de trabalho ou funcionalidades, conforme ilustra a figura abaixo.
Além da WBS, PMBOK prega que deve ser construído um dicionário que segundo PMBOK (2008, p.117) é um documento gerado que dá suporte à própria WBS, ou seja, o conteúdo detalhado dos pacotes de trabalho. Neste dicionário podem ser inclusos responsáveis, custos e lista de marcos descrito no cronograma do projeto, além de contatos com os responsáveis e referências técnicas para facilitar o trabalho.
A integração da WBS no Scrum
Este parte irá traçar algumas analogias entre o uso do Product Backlog no Scrum e a técnica de desenvolvimento de uma WBS, descrita acima.
Após o aceite do projeto através de uma declaração inicial de escopo ou da construção de um backlog, contendo as funcionalidades desejáveis para determinado sistema, inicia-se a fase de planejamento do projeto, seja ele ágil ou tradicional.
Neste momento as estórias do backlog são priorizadas pelo cliente do projeto, o product owner e elencadas para serem desenvolvidas dentro do sprint. Em projetos seguindo PMBOK, é criado o plano do projeto e o cronograma contendo as atividades e quando serão executadas, ordenadas por prioridade.
Neste momento, em projetos ágeis, pode ser criada uma WBS contendo as fases do projeto, sendo elas decompostas por módulos e de módulos sprints, onde cada sprint conterá pacotes de trabalho que serão as estórias e dentro dos pacotes de trabalho, atividades, que poderão ser as tasks criadas para cada estória.
Dessa forma é possível desenvolver um dicionário detalhado contendo responsável, data de início e fim e custo para desenvolver determinada task. Somando os custos das tasks é possível obter o custo de cada estória e do sprint como um todo.
Conclusão
Este artigo apresentou a utilização da WBS para demonstrar e controlar de uma forma visual os itens de um backlog. Desta forma é possível gerir em termos de custo um projeto ágil sem perder os conceitos que o Scrum prega, dado que a WBS não substitui componentes como o quadro de tarefas e o burndown, mas na verdade os complementa, dado que a WBS também pode ser plotada e exibida de forma visual junto ao quadro de Scrum.
A WBS pode ser facilmente construída utilizando uma ferramenta chamada WBS Chart Pro. Dessa forma cada vez mais é possível gerir um projeto ágil seguindo as boas práticas pregadas pelo PMBOK sem perder as boas práticas pregadas pelo Scrum.
Referências
MARTINS, José. Técnicas para gerenciamento de projetos de software. Rio de Janeiro: Brasport, 2007.
SCHWABER, Ken; BEEDLE, Mike. Agile Software Development with Scrum. New Jersey: Prentice Hall, 2002.
SCHWABER, Ken. The Enterprise and SCRUM. Redmond: Microsoft, 2007.
PMI. PMBOK. 4. ed. Newtown Square, Pennsylvania: PMI, 2008. 497 p.