Oi pessoal,
Este post não vai ter explicações de itens técnicos, então os conceitos WBS, Cartão de Historia, Temas e Épicos vai ficar por responsabilidade de cada um.
Mas a idéia de integração entre WBS e Cartão de Historia é bem simples. O WBS nos traz uma visão de quais produtos / serviços o nosso escopo de projeto esta gerando. Uma entrega pode ser quebrada em entregas menores, com esta operação de quebra nos temos o desenho de WBS com uma estrutura hierárquica, onde os itens maiores possuem itens menores.
Veja a imagem
A entrega de todos os itens menores faz com que o item superior seja considerado entregue, isto é, terminado.
Cada produto / serviço do WBS pode ser considerado um Cartão de Historia de grandeza igual a um Tema ou Épico.
Mas se eu tiver um Cartão de Historia que sozinho me gere um produto, este também pode fazer parte do WBS.
Estas definições de grandezas dos nossos cartões vão muito de projeto para projeto, não tendo uma regra única e verdadeira.
Mas existe uma pegadinha, da mesma maneira que não se usa a inclusão de atividades no WBS, também não usamos as tarefas que um Cartão de Historia possui no WBS.
Outro ponto importante é que do momento que realizamos esta comparação entre WBS e Cartões de Historia podemos utilizar a tecnica de "EVA" para acompanhar a execução do projeto, mas este item vai ser um proximo post.
Abraços a todos,
Abu
Postagens
3 comentários:
Tomando como referência o Guia PMBOK, WBS é a tradução livre de Work Breakdown Structure. Conhecida também como EAP - Estrutura Analítica do Projeto ela organiza e define o escopo total do projeto, sem exceção, ou seja, deve respresentar todo o escopo e o trabalho envolvido. Além dos produtos ou serviços, itens como treinamento para a equipe, reuniões de trabalho também são comuns aparecerem nesta estrutura hierárquica.
A técnica mapeada para se criar a WBS chama-se decomposicao, presente no Guia PMBOK. Como comentou o Abu, vamos quebrando o projeto em várias entregas menores e mais fáceis de serem gerenciadas. Para cada entrega quebrada, quebramos novamente e aí vem a pergunta: mas até que nível de granularidade nós vamos? Sugerimos aplicar uma regra geral chamada "regra do 8 x 40". Esta regra funcion assim: se o esforço para criar a entrega for maior que 40 horas significa que devemos quebrá-la em entregas menores. Se a entrega for demandar menos do que 8 horas para ser produzida, significa que 'quebramos' demais. Neste último caso, melhor agregar com outro 'pedaço' menor para que fique com um número de horas maior, entre 8h e 40h.
A EAP dentre outras vantagens nos auxilia a aumentar a exatidão das estimativas e nos facilita a definir claramente responsabilidades entre os membros de equipe.
Criar uma EAP ou WBS não é tão simples e rápido, requer atenção e muita conversa com os envolvidos ou interessados do projeto (Stakeholders). O mais interessante é que o mesmo escopo de um projeto, sob as mesmas condições, pode ser representado diferentemente em uma EAP por 10 diferentes equipes de projeto ou, pela mesma equipe de projeto, em 10 diferentes ocasiões.
Esta estrutura tão importante em projetos tradicionais como de engehnaria, marketing, infraestrutura de TI e Telecom, por exemplo, muitas vezes não apresenta-se de forma tão eficiente quanto deveria em Projetos de Software. Alguém arriscaria um palpite do porquê?
[]s
Dimitri
http://dimitricampana.blogspot.com
Por conta da intangibilidade do escopo do projeto?
Ah, parabéns pelo post! Fico na expectativa pelo post do EVA, para fechar a linha de pensamento. :)
Postar um comentário