BT

O Uso de User Stories como itens em uma WBS (Work Breakdown Structure)

Postado por Paulo Victor Gama Gross de Souza em 26 Mai 2010 |

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.


 

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Comando e controle? by Edvandro Santos

Olá Paulo, bom dia. Parabéns pelo artigo, interessante. Pelo que entendi, WBS parece um método tradicional para gestão de projetos, seguindo a idéia de comando e controle, certo? Tudo isso me parece ser apenas para justicar a necessidade que se tem ainda de um trabalho de gerência de projeto que não seja ágil, ou seja: ferramentas e processos são sempre mais importantes. O Product Backlog e deployable product já são a documentação do projeto, as inspeções e adaptações realizadas pelo Scrum Master também. Não vejo qual o benefício de se ter o WBS junto ao Agile.

Abs.

Re: Comando e controle? by Nelson Abu Samra Rahal Junior

Olá Paulo, parabéns pelo post

Nos podemos montar um WBS com Histórias, seguindo o conceito de Épicos, Temas e Histórias. Segue um link: blogdoabu.blogspot.com/2010/05/scrum-para-pmps-...

Abraços,

Abu

Re: Comando e controle? by Marcelo Torres

Descartes certa vez disse: "o bom senso é o recurso mais bem distribuído no mundo"
O comando controle é falado como uma praga, um mal, algo a ser evitado a todo o custo.O pmbok diz isto, é tradicional né?
Me diga uma coisa , tente não usar comando e controle numa obra com 3000 peoes e veja o que acontece...mas alguns diriam..mas estamos falando de desenvolvimento de software...ok.Mas lembre-se o pmbok é pra todo o tipo de área,negócio e projeto, não só pra TI.
Por isto acredito firmemente no bom senso das pessoas em usar ou não as boas práticas, isto vale mais do que qualquer PMBOK,Manifesto,etc..
Sobre o uso da WBS acho útil pois é uma ferramenta (que pode ser usada ou não) pois ajuda a decompor o problema,produto, visão em parte menores e mais fáceis de gerenciar,implantar,entender.
O conceito do quebre em partes menores é tão velho quando o desenvolvimento de software.
WBS é uma ferramenta de decomposição que é uma técnica que pode ser útil ou não.

ABS

Re: Comando e controle? by Fabiano Silva

Não pude ver o link sugerido pelo Nelson mas a idéia me parece essa mesmo. A principal diferença ocorreria no momento de "quebra" dos itens em "work packages" para a feitura do cronograma.

Paulo, tenho que discordar do ponto onde você coloca "gerenciamento de projetos formal e o gerenciamento de projetos ágeis" - Gerenciamento ágil é gerenciamento formal sim.

Re: Comando e controle? by Paulo Souza

Olá Fabiano,

Concordo com você, ali na verdade deveria ser "tradicional" e não "formal" ;-)

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

5 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT