O que faz o relatório de status aparência perfeita de? [fechadas]

Question

Eu trabalho com um monte de desenvolvedores offsite e empreiteiros. Peço-lhes diariamente para me enviar um rápido status de cinco minutos de seu trabalho para o dia. Eu tenho que consolidar algumas vezes o status dos indivíduos em equipes e, por vezes, consolidar o status de uma semana, para relatórios de final de período para os meus clientes.

Eu quero aprender:

• Os feito e quanto tempo foi gasto em cada
• Problemas encontrados e quanto tempo foi gasto em cada
• Os produtos que serão trabalhadas próximos, suas estimativas (em horas-homem) e suas datas-alvo
• As perguntas que têm sobre o trabalho

Estou à procura de um formato que irá fornecer esta informação quando:

• Ser rápido para os desenvolvedores para completar (5-10 minutos, sem pensar muito)
• Fácil para eu ler e navegar rapidamente
• é uniforme para cada desenvolvedor

O que você sugere?

Answer 1

Use Scrum . Criar o sprint backlog, tem uma planilha com as tarefas e uma coluna para cada dia do sprint. Peça às pessoas para preencher as horas trabalhadas em cada tarefa a cada dia. Enviar relatório diário começando com o gráfico de burndown para o sprint e, em seguida, curtas dois forros um para cada membro - trabalhou por último e no próximo trabalhando. Enviar relatório semanal com o gráfico de burndown, status vermelho / amarelo / verde para cada característica importante (e problemas de bloqueio e notas se não é verde) e os itens restantes na sprint backlog.

Eu não tenho um link para amostras, mas aqui estão alguns rascunhos:

10/02/2008 - Product A daily status

<Burndown chart>

Team member A
Last 24: feature A
Next 24: feature A unit tests

Team member B
Last 24: bug jail
Next 24: feature B

Team member C
Last 24: feature C
Next 24: feature C
Blocked on: Dependency D - still waiting on the redist from team D

10/02/2008 - Product A weekly status

<Burndown chart>

**Feature A** - Green
[note: red/yellow/green represents status; use background color as well for better visualisation]
On track

**Feature B** - Yellow
[note: red/yellow/green represents status; use background color as well for better visualisation]
Slipping a day due to bug jail
Mitigation: will load balance unit tests on team member A

**Feature C** - Red
[note: red/yellow/green represents status; use background color as well for better visualisation]
Feature is blocked on external dependency from team D. No ETA on unblock.
Mitigation: consider cutting the feature for this sprint

**Milestone schedule:**
Planning complete - 9/15 (two weeks of planning)
Code complete - 10/15 (four weeks of coding)
RC - 10/30 (two weeks stabilization and testing)

Answer 2

você provavelmente não quer ouvir isso, mas aqui é assim mesmo -

i ter sido nesta situação em ambos os lados do balcão, e chegaram à conclusão de que estes tipos de relatórios de status laminados-up são um completo desperdício de tempo para você e os desenvolvedores. Eis o porquê:

• os desenvolvedores devem estar trabalhando em recursos / entregas com prazos especificados
• os desenvolvedores devem fazer perguntas quando eles ocorrem
• comunicação deve fluir em ambas as direções, conforme necessário

Se estas coisas não estão acontecendo, nenhuma quantidade de relatórios de status passivo vai resolver os problemas que inevitavelmente surgirão

no lado do desenvolvedor da cerca - uma "rápida status de cinco minutos" [eu odeio essa frase, cinco minutos não é rápido!] Interrompe o fluxo do colaborador, causando uma perda de quinze minutos (ou mais) de produtividade (joel mesmo blog sobre isso eu acho). Mas, mesmo se ele realmente está a apenas cinco minutos, se você tem uma dúzia de desenvolvedores, então você está desperdiçando cinco horas-homem por semana em administrivia (e é provavelmente mais como 20)

no lado do gerente da cerca - enrolando os relatórios de status dos indivíduos em equipes de projeto etc. é busywork não produtiva que desperdiça o seu tempo também. As chances são de que ninguém nem lê os relatórios.

mas aqui está o problema real: este tipo de relatórios e roll-up pode indicar a gestão reativa em vez de gerenciamento pró-ativo. Em outras palavras, não importa o que a metodologia está sendo usado - scrum, xp, ágil, racional, cachoeira, home-grown, ou o que quer - se o projeto for bem planejada e executada em seguida, você já deve saber o que todo mundo é fazendo , pois foi planejado com antecedência. E não importa se ele foi planejado naquela manhã ou seis meses atrás.

ignorando os requisitos do cliente por um momento, se você realmente precisa esta informação em uma base diária para gerenciar os projetos, em seguida, provavelmente há alguns problemas sérios com os projectos - pedindo o desenvolvedor todos os dias o que eles estão indo para o trabalho na próxima e quanto tempo vai demorar, por exemplo, pistas de que nenhum planejamento real era feito com antecedência ...

como para os requisitos do cliente, se eles absolutamente insistir neste tipo de minúcia [e eu sei que, por exemplo, algumas agências governamentais fazem], então a melhor opção é fornecer uma interface web ou outro aplicativo para automatizar o tédio que vai fazer o roll-up para você. Você ainda estará desperdiçando o tempo dos desenvolvedores, mas pelo menos você não estará desperdiçando seu tempo; -)

oh, e responder à sua pergunta literalmente: o relatório de status perfeito diz "no alvo com o plano do projeto", e nada mais; -)

Answer 3

Basta dar-lhes um modelo apresentado em um formato que você espera ver os dados retornados. Você também pode considerar aumentar o tempo que eles vão dedicar a este e remover a cláusula de "não pensar demais" se você estiver exigindo estimativas para o trabalho futuro. Eu não confiaria uma estimativa de que alguém veio com em 5 minutos. sem pensar.

Se você está usando qualquer software de gerenciamento de projeto, deve ser trivial para os desenvolvedores para gravar e revisão (ou mesmo apenas lembre-se) o que eles fizeram compilá-lo para você. Idealmente eles estariam gravando questões ou perguntas durante todo o dia e não a tentar chegar com eles apenas para preencher o relatório.

Parece que o seu "eu quero aprender" a lista é um excelente ponto de partida para gerar um modelo. Só você vai saber o que o formato perfeito para você é.

Answer 4

Geralmente acabo invocada e-mail como um meio de fornecer relatórios de status, ele fornece a simplicidade e rapidez de conclusão, mas não impõe qualquer tipo de uniformidade.

Há uma série de opções para conseguir isso, mas eles todos os riscos tornando o processo mais complexo e demorado. Alguns destes poderiam ser:

Um formulário on-line com seções para cada ou uma folha de planilha multi, com cada folha ser uma seção.

Todos estes exigem algum esforço por si mesmo criá-los, você precisa a uniformidade para algum propósito? por exemplo. para automatizar os relatórios de síntese.

Uma alternativa para isso seria usar alguma ferramenta de gerenciamento de projeto que os empreiteiros preenchido enquanto eles estavam trabalhando e que você poderia informar sobre a qualquer momento. Eu recomendaria Thoughtworks Estúdio Mingle, mas se baseia em um processo ágil-like.

Answer 5

Parece que você quer fazer Extreme Programming levantar reuniões.

http://www.extremeprogramming.org/rules/standupmeeting.html

Você pode conversar com fora do local membros da equipe usando o telefone com laudspeaker, ou algum VOIP.