Início Gerenciamento de projetos no InfoQ Brasil
Notícias
Feed RSS-
Representando testes ágeis
Vários membros da comunidade Agile têm explorado estilos para a representação e registro de testes, usando desde listas simples e tabelas, a estruturas lógicas e mapas mentais.
-
Como dividir User Stories
Muitas das novas equipes Agile têm dificuldades em quebrar suas user stories em partes suficientemente pequenas para trabalhar com técnicas de Agile. Em vários artigos, membros da comunidade fornecem orientações sobre como dividir de forma eficaz as histórias de usuários.
-
Estimativa de tempo e custo realmente funcionam?
Sempre houve um grande dilema entre a estimativa de prazo e de dinheiro que envolve um projeto de TI, reclamações por ambas as partes cliente/desenvolvedores justificando que tal análise ou estimativa não era exata(bem, uma estimativa já não é exata por definição) também é algo frequente. Porém será que métodos como APF não podem ajudar quando o assunto é gerar uma estimativa?
-
Será que os Casos de Uso tem lugar no SCRUM ?
No Scrum, os requisitos são normalmente chamados de user stories. Mas seria CERTO utilizar casos de uso com Scrum? E, em caso afirmativo, sob que circunstância você deveria fazer esse uso?
-
Quais métricas ágeis devemos reportar?
Boas medições apoiam bons gerentes. Sendo assim quais métricas devem ser enviadas até a gerência para melhor apoiar os processos de desenvolvimento ágil de software?
-
Quem quer esta User Story?
Em algumas user stories podemos definir facilmente que são os beneficiados. Mas como cumprir o modelo padrão "Como ... Eu quero ..." se não podemos expressar quem quer aquela tarefa pronta?
-
Sprint Burndowns - Nós estamos medindo as coisas erradas?
Um gráfico tradicional de Burndown do Sprint ajuda o time? Alguns times de Scrum acham que controlar as horas de uma tarefa esconde o verdadeiro estado do sprint e preferem outras ferramentas.
-
Como o Product Owner deveria participar das sessões de Planning Poker?
Em uma discussão recente na lista do Scrum Development, Tri Nguyen perguntou se os products owners devem participar da reunião de planning poker. Existe um consenso geral sobre isso?
-
Histórias não feitas são frequentes ao fim dos seus seus Sprints?
O que acontece se o seu time falha constantemente no fator "Definição de Pronto"(DoD) em algumas ou todas as histórias. Eles devem aumentar os prazos do sprint? Como o product owner deve lidar com essa situação? No caso particular a pessoa que fez essas perguntas estava em um time que utilizava sprints de 4 semanas.
-
O que deveria conter um Plano de Projeto Ágil?
O que faz um plano de projeto ser "bom o suficiente"? Projetos ágeis tem uma forte ênfase nas pessoas sobre os processos e a comunicação verbal sobre a comunicação via papel. Em contraste, muitas metodologias formalizadas exigem documentos muito complicados em relação a contratação/inicialização que tem ser completados a fim de ganhar credibilidade e aprovação para proseguir com o trabalho.
-
A comunidade Agile está se tornando irracional?
Uma recente discussão na lista do Yahoo! pm-agile abordou algumas frustações madiante as recomendações Ágeis, recomendações essas que foram consideradas ingênuas.
-
O que são os "Story Points"? Eles são necessários?
Michael de la Maza se perguntou sobre o que exatamente é um Story Point. Ele estava procurando por uma resposta e encontrou muitas: "Story Points representam unidades de tempo obscuras." ou "Story Point é uma unidade relativa de medida usada por times Scrum. Isso e usado para mensurar a quantidade de esforço necessário para implementar uma história."
-
Estimando Valor de Negócio
A abordagem ágil para priorização é que as histórias de usuário de mais alto valor de negócio devem ser implementadas antes daquelas de menor valor de negócio. O conceito é simples, mas sua implementação depende de se ter um mecanismo para avaliar o valor de negócio.
-
User Manifesto - Uma extensão do manifesto ágil
Em seu site, Alistair Cockburn propôs a criação de uma extensão para o Manifesto Ágil, voltada para o usuário / cliente, a partir de um discussão na cidade de Salt Lake junto com Jeff Patton, que em conjunto com outras pessoas iniciaram este trabalho. O trabalho é ainda preliminar, mas já foram criadas quatro opções, que são basicamente as mesmas, mas dispostas de maneira diferente.
-
Um case para o Google Wave
Ultimamente, muitas pessoas têm comentado sobre o Google Wave. Ben Kepes questionou em seu site, novas possibilidades de integração com o Wave, e citou em um post em seu blog, o case de integração entre a ferramenta de gerenciamento de projetos Mingle, desenvolvido e mantido pela ThoughWorks Studios e o Google Wave, apresentado no evento Enterprise 2.0 em São Francisco.