quarta-feira, 29 de abril de 2009

Redmine e Personalização – Eu amo software livre


Oi pessoal,

Nada como um sistema de código aberto e com algoritmos bem escritos.

Mais uma personalização realizada no sistema e sem complicações. Esta personalização foi de apenas CSS e Imagens.

A minha amiga Fernanda Matos ate me presenteou com uma estrelinha de papel colante pelo trabalho realizado.

Abraços a todos,

 

Abu

 

quinta-feira, 23 de abril de 2009

Grandezas de Tamanho de Cartão de Historia

Oi pessoal,

Este post é um comentário das observações realizadas EM ALGUNS projetos utilizando Scrum e contagem de pontos dos Cartões de Historia.

Apos vários projetos utilizando Scrum e a ferramenta de contagem de pontos de cartão de Historia foi identificada uma diferença em tamanho de pontos por tipo de grandeza de Cartão de História.

Nos meus projetos passei a observar que a primeira estimativa de tamanho era realizado com Cartões de Historia que possui uma quantidade de responsabilidade muito grande, estes Cartões estão na grandeza de um Tema ou Épico.

Quando o Cartão esta como Tema ele é um risco maior na estimativa e nos temos que transformar o seu tamanho de grandeza equivalente a um Épico.

Os épicos possuem mais de um Cartão de Historia adicionados a ele e o interessante é que quando quebramos o épico em Cartões de Historia com responsabilidade única ele passa a ter a somatória dos pontos dos Cartões de Historia de responsabilidade única diferente do valor do Cartão de Historia no tamanho de um Épico.

Isto nos mostrou que não podemos utilizar os dois graus de grandeza juntos.

Nos passamos a utilizar a visibilidade do tamanho do projeto baseado em Cartões de Historia com status de Épico e o controle de quantos pontos o projeto possui e quantos foram executados neste tipo de Cartão.

Foi identificado também que a quantidade de pontos possíveis de execução na Sprint era baseada em tamanho de Épico.

Mas quando pegávamos um Épico para o planejamento da Sprint o nosso PO vinha com os Cartões de Historia de responsabilidade única e a equipe conseguia dimensionar a quantidade de Cartões que poderiam ser executados na Sprint.

Também passamos a realizar uma recontagem dos pontos no decorrer dos projetos, para refinar a quantidade de pontos que o nosso projeto possuía. Sendo esta recontagem sempre a nível de Épicos.

Isso fez com que o projeto estivesse sempre alinhado ao tamanho do escopo e o prazo que ele tinha.

Não fiquem preocupados se vocês estão passando por algo parecido, no final tudo vai dar certo.

Abraços a todos,

Abu

Vale a pena gerenciar formalmente as solicitações de mudanças em projetos ágeis?

Oi pessoal,

O Everton Alves fez a sugestão deste assunto: Vale a pena gerenciar formalmente as solicitações de mudanças em projetos ágeis?

A resposta é sim. Mas não quer dizer que temos que fazer um processo de gerenciamento de mudança de escopo que promova a NÃO MUDANÇA DE ESCOPO.

Pode ser algo simples como um e-mail solicitando a mudança de Escopo ao Scrum Master e o Scrum Master dando um replay que o escopo vai ser alterado. É importante ter esta rastreabilidade de mudança de escopo e aprovação do mesmo.

Mas podemos alterar o escopo antes da solicitação do Product Owner?

Sim, podemos. Não é para usar o processo para deixar o fluxo de execução burocrático e sim deixar o processo como uma forma de registro, para eventuais necessidades futuras.

Abraço a todos,

Abu

Como motivar a equipe para trabalhar com Scrum. Como vencer o preconceito?

Oi pessoal,

Uma sugestão de post do Everton Alves.


Everton eu tive problemas em colocar Scrum numa empresa que eu trabalhei. Não pela equipe e sim pelas pessoas que definiam o processo da empresa. A empresa buscava CMMI nível 2 e utilizava uma adaptação de RUP para estar aderente aos requisitos do CMMI.

Nesta empresa não teve jeito, não entrou Scrum de maneira nenhuma.

Nos últimos dias que eu estava nesta empresa nos passamos a utilizar algumas boas praticas do Scrum, como reuniões diárias e quadro de Kanban.

Já na empresa IEA / Knowtec não tive em momento nenhum problemas para implantar o Scrum nas equipes de TI. Estamos ainda tentando colocar nas equipes de PO, mas esta é uma longa jornada.

Eu vejo que implantar Scrum em equipes de TI é muito mais fácil, pois a linguagem do Scrum é um vocabulário de fácil entendimento das equipes técnicas.

Eu já tenho um post no blog falando dos primeiros passos necessários para se implantar Scrum (http://blogdoabu.blogspot.com/2009/01/como-implantar-scrum.html)

Mas quando existe barreiras eu gosto muito da musica do desenho “Procurando Nemo”. A música que a Dory canta para incentivar marlin


"Para achar a solução...
Nadar
Nadar
Nadar
Para achar a solução...."

“continuem a nadar...
continuem a nadar...
continuem a nadar...
continuem a nadar...”


Abraços a todos,

Abu

Palavra código: Profissional

Ao mencionar a insegurança do gerente como a causa da padronização arbitraria, os participantes de um seminário interno mal puderam se controlar. Todos tinham estórias para contar. Uma das mais idiotas era a da reação da companhia ao uso do microondas da área de café para arrebentar um pouco de pipoca durante o intervalo da tarde.

Obviamente, quando se faz pipoca fica um cheiro inconfundível. Alguém nas alturas rarefeitas do gerenciamento superior sentiu o cheiro e reagiu. Ele declarou em um memorando, “A pipoca não é profissional”, e dessa forma seria proibida.

O termo não profissional é freqüentemente usado para caracterizar o comportamento surpreendente e ameaçador. Tudo o que aborrece o gerente fraco é quase que não profissional, por definição. Dessa forma a pipoca é não profissional. O cabelo longo é não profissional se cresce em uma cabeça masculina, porem é perfeitamente adequado se cresce em uma cabeça feminina.

Os pôsteres de qualquer tipo são não profissionais. Os sapatos confortáveis são não profissionais. Dançar em volta de sua mesa quando algo de bom acontece é não profissional.

Rir e gargalhar são não profissionais. (Tudo bem sorrir, desde que não seja com muita freqüência).

Livro Peopleware / Tom Demarco

Contratando um Malabarista

Gerente de Circo: Há quanto tempo você é malabarista?
Contratado: Há cerca de seis anos
Gerente: Você pode segurar três bolas, quatro bolas e cinco bolas?
Candidato: sim, sim, sim
Gerente: Você trabalha com objetos em chamas?
Candidato: Certamente
Gerente: ...facas, machados, caixas abertas e charutos, chapéus-coco?
Candidato: Eu posso fazer malabarismo com tudo
Gerente: Você faz algum monólogo engraçado junto com o malabarismo?
Candidato: Faço e é hilariante
Gerente: Bem, parece interessante. Eu acho que você esta empregado
Candidato: humm.... Você não quer me ver fazendo malabarismo?
Gerente: Puxa, eu não pensei nisso.



Seria ridículo contratar um malabarismo sem vê-lo atuar antes.
Parece haver uma regra não escrita que diz que está tudo bem em perguntar ao candidato sobre o trabalho passado, mas não em pedir para ver esse trabalho. Entretanto quando você pede, os candidatos quase sempre têm prazer em trazer uma amostra.


Teste de aptidão

Se é tão importante que o novo contratado seja bom nas varias habilidades utilizadas no trabalho, por que não projetar um teste de aptidão para medir essas habilidades? Nossa industria vem mantendo um flerte longo e irregular com a idéia do teste de aptidão. Nos anos 60, a idéia estava positivamente na moda. Agora, porém, você e sua organização provavelmente já desistiram do conceito. Caso você não tenha desistido, oferecemos uma boa razão para que você o faça: os testes medem a coisa errada.

Os testes de aptidão quase sempre são orientados para as tarefas que a pessoa executará logo após a sua admissão. Eles testam se a pessoa é ou não é boa para fazer análise estatística, ou programação, ou o que quer que seja exigido na posição.

Um novo funcionário de sucesso pode fazer essas tarefas por alguns poucos anos e depois se mudar para ser o líder da equipe ou um gerente de produtos ou um chefe de projetos. A pessoa pode acabar fazendo as tarefas avaliadas pelo teste por dois anos e depois fazer outras coisas durante vinte anos.

Fazendo uma apresentação

O nosso negócio sendo mais sociológico do que tecnológico depende mais das habilidades do funcionário em se comunicar com os outros do que das suas habilidades em se comunicar com as máquinas.

A idéia é bem simples. Você pede que o candidato prepare uma apresentação de dez ou quinze minutos sobre algum aspectos do seu trabalho anterior. Pode ser sobre uma tecnologia nova e experiência de tentá-la pela primeira vez, ou sobre uma lição de gerenciamento duramente aprendida, ou ainda sobre um projeto particularmente interessante, o candidato escolhe o tema, Marca-se a data e você junta uma pequena audiência formada por aqueles que serão os colegas do novo candidato.

Razão para fazer: Ver as habilidades de comunicação de todos os candidatos e dar aos futuros colegas oportunidade de participar do processo de contratação.

No final da apresentação e após o candidato ter se retirado, você faz uma reunião com os presentes. Cada um deve comentar sobre a adaptabilidade da pessoa ao emprego e se ele ou ela parecem se adaptar bem à equipe. Embora a responsabilidade definida sobre contratar ou não seja sua, esse feedback dos futuros colegas pode ser inestimável. O que é mais importante, qualquer pessoa nova contratada provavelmente será mais fácil aceito pelo grupo, já que os outros membros do grupo tiveram participação na escolha do candidato.

Uma advertência sobre as apresentações: certifique-se de que o candidato fale sobre algo pertinente ao trabalho feito por sua organização

Livro Peopleware / Tom Demarco

CSM em Floripa

Oi pessoal,

Segue as informações do treinamento de CSM em Floripa.

É com o Alexandre Magno, o cara é fera. Os meus colegas do IEA fizeram com ele.

Mais infomações sobre o treinamento estão disponíveis em www.adaptworks.com.br ou www.scrumalliance.org.

Abraço a todos,

Abu

Curso Certified ScrumMaster em Manaus

Bom dia pessoal,

Eu recomento este treinamento de CSM. É com a Martine Devos, ela é muito boa, vale a pena, eu fiz o meu treinamento com ela.

Pessoal de Manaus que for fazer o treinamento, manda um "Beijo" para a Martina.

Abraços a todos,

Abu
----------------[Dados do Curso de CSM]----------------

Em Julho de 2009 estaremos oferecendo a Certificação CSM (Certified ScrumMaster), com Martine Devos, CST com mais de 20 anos de experiência em Gerenciamento Ágil Projetos e uma das precursoras do Scrum!

Quando? 18 e 19 de Julho de 2009
Onde? Salões do Novotel Manaus
Quanto? R$1.800 pagos em até 4X sem juros (até 01 junho)

Para uma descrição detalhada dos tópicos abordados no curso visite o site da ScrumAlliance em http://www.scrumalliance.org/courses/4775-certified-scrummaster

Quais os benefícios e diferenciais do curso? Após o término do curso com sucesso, cada participante será certificado como ScrumMaster. A certificação inclui o status de membro da Scrum Alliance por um ano, onde material adicional apenas para Scrum Masters está disponível.

Mais importante: os participantes sairão do curso com experiência prática e exercícios para compartilhar com os colegas, além de terem aprendido técnicas precisas de ajudar o time a executar o Scrum eficientemente e de forma produtiva, pois a CST traz estudos de caso e experiência prática desde seu primeiro projeto aplicando Scrum, em 1998! Baseada na sua experiência de mais de 20 anos na comunidade Ágil, a instrutora estará dando ao participante insights e abordagens profundas e maduras que são únicas nesse curso.

O curso será apresentado em inglês, com tradução simultânea para o português já incluída no valor.

Membros do PMI podem obter até 14 PDUs após o curso.

Os participantes irão receber cópias digitais e proprietárias do material do curso, além dos slides. Coffee breaks estão incluídos.

Incrições já disponíveis em http://www.massimus.com/portugues/training.php

quarta-feira, 22 de abril de 2009

Requisitos de Sistemas e Casos de Uso

Oi pessoal,

Segue algumas imagens de um curso de Requisitos e Caso de Uso que eu ministrava. Este curso é do ano de 2005/2006.








Abraço a todos,

Abu

EVA - Análise de Valor Agregado em Projetos














Referencia Bibliográfica

1) Material do Sr. Andre Barcaui

2) PMBOK

Abraço a todos,
Abu

terça-feira, 21 de abril de 2009

Gerenciamento






















Eventos DSOFT

Acompanhe as próximas turmas por área de formação

Área: Gerenciamento de Projetos

1) Análise de Viabilidade Econômica e Financeira de Investimentos e Projetos  
De 28/04/2009 a 30/04/2009 - Terça a quinta - vespertino- 14:00 às 18:00 – ACATE, Trindade, Florianópolis/SC
Abordagem de conceitos e  ferramentas essenciais para análise de viabilidade econômica de projetos fornecendo condições para que, os gestores de projetos e/ou seus membros de equipe designados para tal função, tomem decisões de investir neste ou naquele projeto, ou mesmo de não investir em projeto nenhum. Em tempos de crise e turbulência econômica mundial esta análise torna-se crucial para Gestores e tomadores de decisão. mais informações

2) Gerenciamento Ágil de Projetos de Software com SCRUM 
Dias 12, 13, 19 e 20/05/2009 - Terças e quartas - noite - 18:30 às 22:30 – ACATE, Trindade, Florianópolis/SC
Conheça a forma de gerenciar de projetos de software que está revolucionando o mercado! Esteja preparado para aplicar Scrum na sua empresa, e entenda como e por que gigantes como Yahoo, Microsoft e Google vêm obtendo excelentes resultados com o uso desta abordagem. mais informações

Área: Desenvolvimento de Sistemas

3) Medição de Sistemas utilizando Análise por Pontos de Função 
De 04/05/2009 a 07/05/2009 - Segunda a quinta - noite - 18:30 às 22:30 – ACATE, Trindade, Florianópolis/SC
A Análise por Pontos de Função é considerada a principal ferramenta para a medição funcional de sistemas, sendo empregada largamente na indústria de software. Baseada na visão do usuário final para mensurar o tamanho funcional de aplicativos de software, provê uma abordagem quantitativa nas fases iniciais dos projetos servindo como base fudamental para o planejamento do projeto. mais informações

4) Desenvolvendo aplicações web com Ruby on Rails 
Dias 26, 27/05/2009 e 02, 03/06/2009 - Terças e quartas - noite - 18:30 às 22:30 – ACATE, Trindade, Florianópolis/SC
Faça parte do time de desenvolvedores que mais cresce no mercado brasileiro e aprenda a criar aplicações web com alta produtividade e qualidade usando Ruby on Rails. Voltado para programadores que desejam aprender esta nova plataforma de desenvolvimento Web o Ruby on Rails torna fácil e simples o processo de construir aplicações Web. Mesmo para quem nunca programou, o Rails derrubou os obstáculos que impediam as pessoas de entrar no universo da programação de aplicações para a web, permitindo produzir em dias o que levaria meses para ser feito em linguagens de programação tradicionais. Combinando rapidez no desenvolvimento com recursos poderosos, esse framework para criação de aplicativos online já se tornou um dos pilares da web 2.0! mais informações

Entre em contato com nossos consultores e solicite sua proposta. 
cursos@dsoftsistemas.com.br / (48) 3028.6119

* Desconto especial para estudantes, profissionais vinculados ao CREA/SC, CRA/SC, empresas associadas a ACATE e SUCESU-SC.
* Cadastre-se no site da DSOFT indicando sobre quais assuntos gostaria de se manter informado por email e garanta 10% de desconto em sua inscrição!

segunda-feira, 20 de abril de 2009

Nascido versus Fabricado

Os pais certamente têm a capacidade de moldar suas crianças ao longo dos anos, e os indivíduos obviamente podem mudar muito. Os gerentes são incapazes de mudar o seu pessoal de modo significativo. As pessoas não ficam no mesmo lugar o suficiente, e o gerente não têm influência para modificar suas naturezas. Assim, as pessoas que trabalham para você, não importando por quanto tempo, serão mais ou menos as mesmas que eram no início. Se elas não são adequadas ao trabalho desde o começo, nunca o serão .

Tudo isso quer dizer que conseguir as pessoas certas em primeiro lugar é mais importante.

Livro Peopleware / Tom Demarco

Scrum e PMBOK – Qualidade

Oi pessoal, segue um texto escrito em duas mãos, eu e meu grande irmão Patrick Padilha. O Patrick fez o treinamento de scrum master na mesma turma que eu e tivemos a oportunidade de trabalharmos juntos na empresa Knowtec e IEA.

Mas ele seguiu outro caminho, o de funcionário publico e desta maneira nos apenas temos a oportunidade de escrever textos juntos.

Para um projeto de sucesso, é esperado que os resultados do projeto tenham qualidade, assim como que os processos de construção dos resultados também tenham qualidade!

Garantir a qualidade do produto do projeto que será entregue ao cliente deve ser um dos objetivos de qualquer projeto, portanto não devemos nos esquecer de introduzir qualidade nos processos utilizados durante o andamento do projeto.

No PMBOK o processo “Realizar o Controle da Qualidade”, do grupo de processos de Monitoramento e Controle, é responsável por monitorar a qualidade dos resultados do projeto e garantir que esses estejam em conformidade com os requisitos esperados pelo cliente e de acordo com os padrões relevantes de qualidade.

No SCRUM a qualidade dos resultados dos projetos é verificada pelo Product Owner (PO) ao final de cada Sprint, durante a Sprint Review, quando a equipe apresenta para o PO o que foi construído durante essa iteração. Durante a Sprint Review o PO pode aceitar as entregas feitas pela equipe ou pode negar, caso as entregas realizadas não sejam as esperadas. O PO pode ainda solicitar que sejam feitas alterações, as quais serão realizadas de acordo com a prioridade dada pelo próprio PO. Quando executadas, as alterações passarão novamente pela aceitação do PO em uma Sprint Review.

A qualidade dos processos é tratada no PMBOK pelo processo “Realizar Garantia da Qualidade”, do grupo de processos de Execução, onde são aplicadas as atividades de qualidade planejadas para garantir que o projeto empregue todos os processos necessários para atender aos requisitos, assim como fornece uma base para a melhoria contínua dos processos.

No SCRUM, ao final de cada Sprint, a equipe tem duas cerimônias a serem realizadas: A Sprint Review, onde são realizadas as entregas para o PO e a Sprint Retrospective, que tem como objetivo principal a melhoria do processo de cada Sprint; é onde a equipe avalia a sua forma de trabalhar e verifica que práticas deixarão de fazer, o quê deverá ser mantido e práticas a equipe deverá passar a realizar.

Como um dos principais objetivos do SCRUM é entregar software funcional e de alto valor agregado para o cliente o mais rápido possível, outras práticas para garantir a qualidade são usualmente utilizadas em um projeto SCRUM, como o TDD (Test Driven Development) onde se tenta realizar uma cobertura de testes para todo código gerado, minimizando a ocorrência de bugs futuros e mantendo um controle maior sobre os impactos de cada alteração realizada no código.

 

Abraços a todos,

 

Abu e Patrick

sexta-feira, 17 de abril de 2009

Scrum e PMBOK – Planejamento

O planejamento continuo deve ser utilizado em casos em que não é possível planejar de outra forma.

Retirado do livro: Use a Cabeça PMP

Scrum e PMBOK – EVA

Analise de Valor Agregado?

Tem como foco a relação entre os custos reais consumidos e o produto físico obtido no projeto através de uma quantidade especifica de trabalho, ou seja: o que foi obtido pelo projeto em relação à quantidade de capital consumida para atingir esse resultado.

Ganhos Reais na Gestão?

O Valor Agregado funciona como um tipo de “alarme”, permitindo ao gerente de projeto avaliar se está consumindo mais dinheiro para realizar uma determinada tarefa ou se está apenas gastando mais naquele momento porque o desenrolar do projeto está sendo acelerado, permitindo que sejam tomadas ações corretivas e preventivas com a devida antecedência.

O que é um projeto bem SUCEDIDO?

É AQUELE QUE É REALIZADO CONFORME O PLANEJADO

Mas como podemos adaptar esta técnica para acompanhar o desenvolvimento do projeto utilizando pontos de historia?

Para facilitar o entendimento vamos nos prender que o custo do produto a ser entregue é apenas horas de trabalho.

Vamos pegar um Cartão de Historia de grandeza igual a um Tema, este cartão possui vários Cartões de Historia correlacionados e de responsabilidade única, sendo estes cartões estimados em pontos. A soma de todos os pontos dos Cartões de Historia nos da o tamanho do Cartão de Historia de grandeza igual a um Tema.

Exemplo:

Cartão de Historia: Controlar Estoque

Total de Pontos: 100 pts

A Execução dos 100 pts nos leva a 100% do produto construído.

No caso do EVA o que ele vai buscar é a qtd de pontos executados e o quando de produto ele gerou.

Para obtermos estes dados existe a necessidade da medição dos cartões já desenvolvidos e que estão com o status de “Done”. Também temos a necessidade da informação de quanto tempo foi gasto da equipe para construir estes cartões. Assim podemos pegar as horas trabalhadas e chegar ao custo monetário que foi despendido para construir os Cartões de Historia.

Com a informação quanto foi gasto, quanto de produto foi gerado e qual o custo orçado para desenvolver o produto podemos aplicar as formulas de calculo de EVA.

Abraços a todos, 

Abu

Scrum e PMBOK – Tabela de Nome e Funções

Oi pessoal,

É muito comum estarmos no meio do projeto e ter problemas e também é muito comum não termos o colega de trabalho que sabe resolver o problema disponível no momento. A solução é simples, vamos ligar para ele. Mas para viabilidade desta solução necessitamos do numero de telefone do nosso colega de equipe.

É ai que entra mais um instrumento do PMBOK na parte de recursos humanos, ter uma tabela de nomes e funções de todos os envolvidos no projeto.

Solução simples, mas que nem sempre é realizado pelo gestor de projeto e no caso do Scrum, pelo Scrum Master.

Esta tabela com estes dados pode e deve ficar em local disponível a todos os interessados.

Segue a imagem com um modelo.


Podemos completar esta tabela com mais informações, como data de nascimento, endereço e o que for necessário.

Abraços a todos,

Abu

quarta-feira, 15 de abril de 2009

Scrum e PMBOK – Matriz de Responsabilidade

Oi pessoal,

Este item eu acho muito importante. Nem todos os projetos possuem uma estrutura projetizada de gestão, podemos estar trabalhando em empresas que possuem uma estrutura matricial de organização de projetos.

Porque a matriz de responsabilidade é importante? Simples, ela que determina quem é responsável por cada tarefa que tem que ser executada no projeto.

Dentro da estrutura do Scrum nos sabemos muito bem qual a responsabilidade da equipe, do Scrum Master e do PO.

Mas nem todos os envolvidos no projeto sabem como funciona o processo de trabalho do Scrum e podemos ter a qualquer momento recursos humanos de departamentos funcionais da empresa que estamos executando o projeto alocado de maneira parcial em nosso projeto.

Para que a responsabilidade fique clara, isto é, nada de “implícito”, nos criamos uma matriz de responsabilidade.


Na figura com o exemplo de matriz de responsabilidade não tem nome de pessoas, mas a matriz pode ter o nome do responsável. Neste caso no cruzamento de linhas e colunas onde a imagem mostra um “X” deveria estar presente o nome do responsável pela atividade.

Esta técnica evita uma seria de problemas de visibilidade de quem é responsável por executar as tarefas. Evita problemas de tarefas não ter donos, ajuda a deixar claro quem é responsável por alocar recursos ao projeto (no caso de departamentos), de saber com quem devemos entrar em contata para saber se a tarefa esta sendo executada e qual o status da tarefa, entre outras coisas mais.

Lembrando... Nem todos os projetos possuem apenas os papeis do Scrum e nem sempre todos os envolvidos no projeto estão reunidos na mesma estrutura física e pertos um do outro.

Esta ferramenta vai ajudar e muito o Scrum Master ter um bom relacionamento com outros envolvidos no projeto.

Abraços a todos,

Abu

 

Scrum e PMBOK – WBS e Cartões de Historia



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

Scrum e PMBOK – Riscos de Projeto

Oi pessoal,

Eu gosto muito de fazer a pergunta a todos os envolvidos no projeto: “O que vocês estão enxergando que eu não estou?”

Esta pergunta tem o objetivo de buscar riscos de projetos e que todos os envolvidos no projeto podem e devem participar.

Trabalhar com riscos não quer dizer que necessariamente ele, “O Risco”, não vai ocorrer, mas sim realizar uma ação preventiva para amenizar os impactos no projeto caso “O Risco” ocorra.

Em Scrum podemos buscar Riscos em Daily Meeting, Scrum de Scrum, Planejamento da Sprint, Retrospectiva, Review, etc.

Não importa o momento, alguém esta “enxergando algum problema no futuro” com o projeto, este perigo eminente deve ser catalogado e gerenciado.

Segue um template de auxilio na hora de escrever um Risco.


Este são alguns exemplos cadastrados utilizando o template.


 

Um abraço a todos,

 

Abu