Como relatar o andamento do meu projeto (Agile) ao meu empregador (que não é um programador)?

Tenho um problema ao relatar o progresso ao meu empregador. Sou programador em meio período, lidando com um projeto de software para o departamento (não técnico) da minha escola.

Pessoa de contato:
1. A equipe que realmente usa o software e gera solicitações de recursos,
2. Meu chefe (não programador) e ela não é o usuário do software.

A natureza do projeto:
é um software pronto, adquirido de terceiros. Preciso modificar ou adicionar recursos / funções a este software para atender às necessidades do departamento. Este é um software que você precisa usar ao longo do semestre. Nem todos os recursos precisam ser usados ​​no início.

Por isso, estamos usando o modelo Agile: quando a equipe precisa de um determinado recurso, ele gera uma solicitação e eu faço as alterações. Até o final do semestre, suponho que todos os recursos necessários serão aprimorados e implementados.

O problema: toda
vez que meu chefe me perguntava como está o progresso, não posso responder, porque não sei como responder. Não tenho uma lista completa de todos os recursos necessários. Mesmo tendo completado os recursos levantados na semana passada, ainda não sei dizer ao meu chefe que "concluí", porque novos recursos também estão chegando e não sei quanto. Não sei dizer "Temos quantos% de conclusão" nem "Vamos concluir por xxx". Em algum momento de três solicitações, consigo concluir 2, diria ao meu chefe "concluí 2, mas há um recurso ainda não concluído". Após um longo período de tempo, soa como "sempre tenho algo que não termina, depois de tanto tempo".

Ser incapaz de relatar o progresso me faz parecer muito ruim. Não é sobre o quanto eu fiz, é sobre como deixar as pessoas saberem. Se eu fosse o gerente, e minha equipe continuasse falhando em me comunicar o progresso por meses, sentirei que esse cara também é incapaz.

Vocês têm alguma idéia de como relatar ou responder a perguntas tão simples quanto "qual é o status / progresso da modificação do software"?

ATUALIZAÇÃO Minha chefe não envolve tarefas de desenvolvimento diretamente, portanto, ela não tem idéia do que estou fazendo ou de como o programa funciona. Não nos encontramos regularmente, pois ela está ocupada, e acho que será perda de tempo porque ela não é a principal usuária, ela não conhece os detalhes do programa.

Encontro-me regularmente com a equipe que utiliza e conhece melhor o software.

Sinto-me difícil de explicar o progresso ao meu chefe.

Esse é um problema comum quando você é um programador que trabalha de forma independente e se reporta a alguém que não é técnico.

Chefes como esse geralmente querem ser capazes de descobrir algumas coisas:

• Quão felizes são os usuários?
• As coisas que os usuários querem que sejam feitas?
• O que você está fazendo vale o dinheiro que está sendo pago?

Uma queima do Agile ou qualquer outra coisa assim seria uma péssima idéia! Como você disse, seu chefe está muito ocupado, para que eles não tenham tempo de aprender e provavelmente não estejam interessados.

Então, se eu fosse você, enviaria um relatório por e-mail uma vez por semana, contendo:

• Um "resumo executivo" no início: "Concluiu 3 recursos nesta semana e recebeu 2 solicitações de novos recursos. No início desta semana, havia 11 solicitações de recursos inacabadas e no final havia 10".
• Uma lista de status do recurso, com uma breve frase cada, em três grupos:
  1. Os recursos que você fez durante a semana
  2. Os pedidos de funcionalidades recebidos durante a semana
  3. Os outros recursos do "backlog"
• Uma breve discussão sobre qualquer coisa que seja complicada ou incomum, de preferência usando linguagem não técnica.

Se eu fosse seu chefe e não estivesse recebendo nenhum relatório, ficaria muito feliz em recebê-lo toda semana. E se eu quisesse algo diferente, eu pediria.

Parece que você não tem como saber se está completo ou até que ponto está completo. Está tudo bem.

Mantenha uma lista dos recursos solicitados, quais são concluídos, em andamento ou não iniciados. Acompanhe-os como gráfico semanal para semana do total em cada categoria. Isso fornecerá um conjunto de pontos que você pode extrapolar para a data final. Ou seja (observando apenas as contagens de recursos "concluídos")

• Semana 1 - 2 concluída
• Semana 2 - 5 concluída (2 da semana 1, 3 da semana 2)
• Semana 3-8
• Semana 4-12

Se você tiver 16 semanas, poderá concluir cerca de 48 recursos (não se preocupe muito com o fato de alguns serem maiores / menores do que outros, depois de 4-5 semanas, a média geral é a média). Você pode informar a todos que só pode lidar com um número X de recursos. No final do projeto, o que é absolutamente o mais importante é que você entregou os recursos necessários e não se matou nas últimas duas semanas. Ao reportar dessa maneira, você pode retirar os principais requisitos o mais rápido possível.

A outra coisa que você deseja informar é quanta capacidade você possui. "Eu só recebi 2 solicitações de recursos, mas poderia ter lidado com 3 ... você pode pedir à equipe para aumentar mais recursos mais cedo?"

não tenho certeza de que respondi completamente à sua pergunta, sinta-se à vontade para fazer perguntas de acompanhamento ...

Três palavras ... queimar gráfico.

Seu empregador, independentemente de serem ou não viciados em agilidade ou apenas uma pessoa encarregada de desenvolvedores, apreciará um gráfico de detalhamento .

Todo mundo gosta de entender quando um projeto será concluído e aproveitar o clima de ontem fornecerá a maneira mais precisa e realista de prever a conclusão de um projeto.

Suponho que você faça uma aula individualmente pelo menos uma vez por semana e possa discutir suas prioridades com o gerente naquele momento - o que é importante do ponto de vista dele (o tal e qual precisa dele antes) outra pessoa, etc.) - e, portanto, pode relatar quanto do material que faz com que seu gerente pareça bom é feito versus a quantidade de material que você tem no total para fazer.

Seu gerente provavelmente não está procurando um detalhamento minuto a minuto; Ele está apenas tentando ver se o trabalho está sendo realizado, se as coisas importantes estão recebendo mais atenção e se você não está se afogando sob a carga ou ocioso porque está impedido de prosseguir.

Observe que, em um verdadeiro processo ágil, você realmente tem novidades o tempo todo, mas você e seu gerente concordam com o que é mais importante / mais necessário e quanto disso caberá no período de trabalho atual (seja uma semana, duas semanas, um mês ...), dividindo os trabalhos em pedaços menores, se necessário, para que eles se ajustem ao período.

Uma grande revisão do banco de dados que leva várias semanas pode ser dividida em algo como: estabelecer backups, verificar se os backups são bons, projetar o novo layout do banco de dados, escrever o software de conversão e testá-lo, configurar a reversão e testá-lo, tentar a conversão em a máquina de preparo, tentando a reversão no mesmo local e, finalmente, fazendo a conversão. Cada uma delas provavelmente pode ser dividida em partes de 1 semana (ou menos). Se algumas etapas levarem 2 ou 3 semanas, você informa quanto tempo esteve na próxima reunião (segmentando 50% por duas semanas, 33% por três semanas etc.).

Idealmente, você teria um gráfico com o que precisa fazer versus o que vai fazer agora e marcaria os itens "fazer agora" à medida que avança. Isso permite que seu gerente passe por aqui e veja quantas coisas estão marcadas versus as que estão na lista a serem feitas.

Uma vez por semana (presumo que a duração da iteração / sprint em seu processo ágil seja de uma semana por exemplo), faça o seguinte :

• demo o novo trabalho para a equipe, para garantir que seus pedidos foram concluídos
• relate ao chefe o número de solicitações concluídas durante a semana e identifique / descreva essas solicitações. Faça um breve resumo
• relate ao chefe o número de novas solicitações adicionadas à sua lista de pendências / fila durante a semana e o número total de solicitações
• diga ao chefe em que (quais solicitações) você planeja trabalhar na próxima semana; em outras palavras, as prioridades atuais. Aqui está a oportunidade para ela confirmá-las ou alterá-las e para vocês dois serem claros sobre isso
• diga ao chefe qual é o plano para 1-2 semanas depois disso.

Sinto que seu chefe não é técnico o suficiente para cuidar ou entender termos ágeis , como velocidade , proprietário do produto ou gráfico de burndown . O modelo acima evita esse jargão, usa palavras mais simples como "lista de pendências" e "fila" em seu senso comum e, portanto, deve facilitar a comunicação com seu chefe.

Eu usaria minha velocidade como a principal estatística para ele / ela. Isso mostrará quantas tarefas / recursos eu "concordei" em conversar por uma semana específica (ou outro período de tempo) e quantas concluí. A partir disso, eu mencionaria alguns dos implementos de recursos mais importantes e por que isso mudou em relação às iterações anteriores. Você também pode mencionar quaisquer impedimentos que você encontrou e superou e como isso afetou sua velocidade.

Outras estatísticas que seu chefe talvez queira conhecer podem incluir o número de novos relatórios de erros gerados, relatórios de erros fechados e solicitações de novos recursos enviadas. Você terá que perguntar diretamente ou usar seu melhor julgamento para determinar quais são as mais importantes. No final, eu daria um esboço básico do progresso e perguntaria se há mais alguma coisa que ele ou ela gostaria de saber. Tudo o que o chefe quer saber é que você está progredindo e há algo que precisa para dar o seu melhor.

Sugira que você envie um relatório semanal: liste os recursos solicitados. Registre os recursos alterados. Relate o que você fez.

Eu tentaria fazer isso de uma maneira que os gerentes entendessem.

Total Recieved Feature Requests:
Requests Completed:
Requests since last Update:
Estimated Time to required to complete remaining Requests:

Só porque seu gerente não é um programador, não pense que isso significa que ele espera que você saiba uma data exata de conclusão. Apresente os números que você possui. Depois que o gerente vê o número de solicitações recebidas e concluídas, subindo, o gerente vê progresso. Se os números de suas solicitações ficarem fora de controle, o gerente poderá intervir e ajudá-lo, priorizando antes que você fique sobrecarregado. E se o seu trabalho estiver acabando, eles poderão encontrar algum projeto secundário pequeno. Afinal, é sempre bom ter uma pausa em um projeto quando parece que não há fim à vista e os dias de trabalho passam mais rápido e são mais gratificantes quando você está ocupado.