Início Gerenciamento de projetos no InfoQ Brasil
Notícias
Feed RSS-
O talento está supervalorizado? Consistência e foco podem valer mais.
Em uma análise do livro "Talent is Overrated", o coach de Agile Steven List defende a "prática deliberada". Para ele, o mais importante para o desenvolvimento profissional é a consistência e o foco em melhoria. A busca da excelência e os desafios são os verdadeiros motivadores que resultam em sucesso, tanto do ponto de vista pessoal, quanto no das equipes e empresas.
-
O problema da perfeição: quando o ideal destrói resultados
Um artigo na HBR discutiu o "problema da perfeição" enfrentado pelos gerentes e o seu impacto sobre a produtividade das equipes e a entrega de resultados. O desejo de encontrar o ponto de equilíbrio exato ou a solução ideal acaba resultando no outro extremo: paralisia, falta de ação e ausência de soluções. Veja práticas para evitar o problema.
-
Pessoas são Recursos?
A necessidade de controle de orçamentos dentro das organizações cria uma tendência natural de se tratar custos com pessoal de forma desumanizada, semelhante aos custos com materiais e equipamentos. A situação chega ao ponto das pessoas serem tratadas como "recursos". Seria este um obstáculo ao sucesso dos projetos de software nas organizações?
-
Precisamos mesmo da iteração zero?
É comum que diversas atividades precisem ser realizadas antes do início de um projeto, e só depois se passe a atividades que agregam valor de negócio para os clientes. Com esse objetivo, equipes ágeis muitas vezes utilizam uma iteração inicial, conhecida como iteração ou sprint zero. Mas seria esta a maneira mais adequada?
-
Dominando os Requisitos Não-funcionais
É comum em equipes ágeis que haja dificuldades em estimar e especificar requisitos não-funcionais, como escalabilidade, interoperabilidade, facilidade de manutenção, desempenho, portabilidade e segurança. Em posts e artigos recentes, especialistas apresentam recomendações e boas práticas para lidar com esses requisitos em projetos ágeis.
-
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.