Pergunta

O "agendamento baseado em evidências" no FogBugz é interessante, mas como utilizá-lo com uma metodologia Ágil?

Foi útil?

Solução

Como eed3si9n disse, se você for consistente em suas estimativas para EBS, o FogBugz cuidará disso para você.

Quanto ao aspecto mais geral, como o FogBugz se encaixa na metodologia Agile, sua melhor aposta é fazer sprints como mini-lançamentos.Crie um sprint e adicione os casos que você deseja alcançar para esse sprint a esse release (ou marco).Defina uma data de término, digamos daqui a uma semana, se você fizer sprints de uma semana.Então o EBS pode rastreá-lo e informar se você está dentro do cronograma.

Os gráficos na seção Relatórios também mostrarão um gráfico de burndown.A terminologia é um pouco diferente porque o FogBugz não é apenas Agile, mas a informação está lá.

Você quer ver se o tempo esperado para terminar seu sprint permanece estável ou avança.Se estiver estável, você está no caminho certo e sua taxa de esgotamento está dentro da meta.Se estiver aumentando, você está perdendo terreno e seu sprint está atrasado.É hora de passar para o próximo sprint ou descobrir por que você estragou suas estimativas :)

Basicamente, suponho que este seja um gráfico burn-up em vez de um gráfico burndown, mas fornece a mesma resposta para a mesma pergunta.Vou terminar na hora certa?O que me resta fazer?

da Atalasoft Lou Franco escreveu um excelente post sobre isso também. Patrick Altman também tem um artigo.

Atualizar: link fixo para o artigo de Altman

Outras dicas

Perguntei a mesma coisa ao pessoal do FogBugz porque no XP, por exemplo, você forneceria a estimativa em IET (tempo ideal de engenharia).A resposta deles foi ser consistente na maneira como você fornece a estimativa.

Começamos a usar o FogBugz para praticamente tudo dentro da nossa equipe técnica:Documentação, relatório de bugs, gerenciamento de tarefas.Progressivamente, adquirimos mais Agile com o passar do tempo.

O que fiz foi criar um lançamento chamado Backlog do Produto, que recebe uma data de lançamento arbitrária no futuro.Alterei o campo "Versão" do FogBugz para "Prioridade" para que possamos classificar por prioridade.Para gerenciar o backlog do produto, uso fortemente Áreas para categorizar as histórias de usuários.As áreas podem ser Temas ou Épicos.Cada Iteração é um Release no FogBugz.

Agora, uma coisa que começamos a usar recentemente são Story Points em oposição aos Dias de Tarefa Ideal para estimar nosso Backlog de Produto.O FogBugz não entende uma unidade de medida de Story Points, então, de forma bastante confusa, 1 SP em nosso Backlog de Produto é relatado como 1 Dia no FogBugz.Isso pode ser perigoso se houver alguma confusão.Mas nossa equipe é pequena.Eu não uso as ferramentas de relatórios integradas no FogBugz, mas seria ótimo se pudesse.

Portanto, todos os meus cálculos de Story Point e Velocidade são feitos fora do FogBugz no Excel.Isso parece estar bem por enquanto.Estamos rastreando tarefas usando fichas para histórias de usuários e post-its como tarefas em nossos quadros no escritório.Dê uma olhada no livro "Scrum e XP das Trincheiras" de Kniberg que influenciou minha decisão.Na verdade, ter um quadro grande com tudo o que estamos vendo em nosso Scrums matinal realmente ajuda.

Eu realmente acho que o histórico de estimativas e relatórios no FogBugz são excelentes.Isso funciona com o mundo do pôquer de planejamento?Suponho que sim, pelo menos pelo histórico de estimativas de uma equipe.

Como as histórias de usuários no backlog do produto geralmente evoluem à medida que há sessões de planejamento iterativas (Planejamento Ágil), seria ótimo se houvesse uma edição de casos no estilo wiki, em vez de um encadeamento de descrições.

Fala-se que a próxima versão principal dará mais suporte aos processos Agile, então estou muito muito ansioso para ver o que isso oferece.

Editar:O FogBugz 7 foi lançado com um gerenciamento muito melhor de Backlogs de "Projetos" de Produtos.Dê uma olhada!

http://www.fogcreek.com/FogBugz/blog/post/Scrum-Friendly-Features.aspx

Aqui estão algumas sugestões para incluir Story Points em seu planejamento:

Ao inserir sua Story no FB7 você pode fazê-lo como um Case e incluir o número de Story Points do Planning Poker em um novo campo personalizado que você cria chamado "Story Points" (como fazer isso abaixo).Então, quando você começar a trabalhar nessa história, poderá dividi-la ainda mais em subcasos, se necessário, e também inserir o tempo estimado para concluir cada subcaso (os tempos estimados serão somados na história (parte superior). ) Campo "Estimativa" do caso, bem como feed de agendamento baseado em evidências/gráficos de Burndown)

Aqui estão duas coisas que você deve considerar modificar na instalação do FogBugz para refletir sua nomenclatura Agile.

(1) fora da caixa, a categoria FB "Recurso" é mais parecida com a sua "história". Mas você pode alterar seus nomes de categoria e adicionar novos no Admin> Workflow> Personalizar categorias.Aqui estão informações adicionais sobre isso:

http://www.fogcreek.com/FogBugz/docs/70/topics/plugins/CustomWorkflow.html?isl=174457

(2) Para capturar Story Points, você provavelmente desejará criar um campo personalizado na caixa de diálogo Caso.Isso é feito com o plug-in de campos personalizados incluído.Informações adicionais sobre isso estão disponíveis em isl=174461

Observe que, com os campos personalizados, você também pode adicionar uma caixa de edição de texto para a história, que sempre aparecerá no cabeçalho da caixa de diálogo do caso (não importa quão extenso seja o histórico de atividades do caso abaixo dele).

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top