Como você apresentaria seu progresso no desenvolvimento de software a seus stakeholders?

Usamos o bugzilla para rastrear bugs e solicitações de recursos, e também exigimos que os desenvolvedores escrevam em notas de versão separadas, caso terminem de codificar um recurso. Moda antiga, eu sei.

Um problema que temos com o arranjo acima é que, embora funcione muito bem para o software que já estamos vendendo, é completamente inútil acompanhar o progresso de um novo projeto de desenvolvimento de software. O motivo é que, no momento de desenvolver um novo software, não usamos, ou melhor, não podemos, usar o bugzilla para rastrear os recursos simplesmente porque o bugzilla não é adequado para representar a complexidade complicada da dependência de recursos (para concluir uma nova aplicação de software, existem muitos recursos para codificar e não temos vontade de colocá-los no bugzilla, e mesmo se o fizéssemos, não tínhamos como saber quais recursos dependem de qual, e não poderemos obter uma previsão precisa da data de envio de qualquer maneira).

Então, nossas partes interessadas ficarão preocupadas com nosso progresso de desenvolvimento (ou falta de) e começarão a bater na porta do líder da equipe (a sua verdadeiramente) nas estimativas, as quais não posso responder porque, tragicamente, também sinceramente não entendo direito. saber a que distância está o novo aplicativo da conclusão.

Como você apresentaria seu progresso no desenvolvimento de software a seus stakeholders?

Faça da maneira ágil: faça uma demonstração antecipada e faça uma demonstração com frequência.

Nada supera a sensação visceral de realmente usá-lo para dar uma sensação de progresso.

Isenção de responsabilidade: nunca usei o Bugzilla antes, por isso não tenho certeza de seus recursos de gerenciamento de projetos (embora o Bugzilla: Gerenciamento de Projetos com Bugzilla pareça estar bom).

Esse problema parece o resultado de uma falta de disciplina. Você deve usar o software de gerenciamento de projetos para planejar e prestar contas pelo tempo e esforço gastos. Qualquer software de gerenciamento de projetos (fiquei impressionado com Jira e Redmine ) tem funcionalidade para dividir tarefas em um nível, para que você possa fornecer uma estimativa precisa (~ horas) de cada tarefa.

A partir daí, é um caso de ser disciplinado e preencher os detalhes da tarefa. Isso fornecerá uma visão geral na forma de um gráfico de Gantt (Redmine) ou um gráfico de burndown do projeto (Jira), que fornece avaliação instantânea do progresso do seu projeto.

No final do dia, é simplesmente fornecer uma estimativa de tempo (que é feita dividindo as tarefas para maximizar a precisão) e, em seguida, quando o desenvolvimento começa, comparando o progresso com as estimativas iniciais (ou revisadas).

O gerenciamento de projetos não precisa ser incrivelmente sofisticado ou requer ferramentas sofisticadas, e o KISS não é um mantra ruim se você não tiver gerentes de projetos dedicados. Se você estiver desenvolvendo um novo software, deve ter pelo menos algum tipo de especificação ou lista de recursos. Itemize e despeje-os em uma planilha, talvez com uma estimativa de tempo, uma data prevista de início, uma data prevista de entrega, horas trabalhadas e um indicador de status (concluído, em andamento, não iniciado). Em seguida, você pode fabricar gerar quaisquer métricas que julgar apropriadas para indicar o progresso do projeto (como uma% de conclusão com base no número de horas estimadas para itens concluídos vs. total estimado de horas). Gere alguns gráficos com cores vivas e todos estarão felizes.

Um monte de software PPM pode ser um exagero para equipes pequenas, rastreando vários projetos, atribuição de recursos, itens de CQ, etc. etc. Se tudo o que você realmente precisa é criar um relatório de status, uma planilha funciona. "Concluímos 92 dos 127 recursos e estimamos que concluiremos a codificação e os testes duas semanas antes do previsto". Todo mundo bate palmas.