¿Cómo informar el progreso de mi proyecto (Agile) a mi empleador (que no es un programador)?

Tengo un problema para informar el progreso a mi empleador. Soy programador a tiempo parcial y manejo un proyecto de software para el departamento (no técnico) de mi escuela.

Persona de contacto:
1. El personal que realmente utiliza el software y plantea solicitudes de funciones,
2. Mi jefe (no programador) y ella no es la usuaria del software.

La naturaleza del proyecto:
es un software listo para usar, que se ha comprado a terceros. Tengo que modificar o agregar características / funciones a este software para satisfacer las necesidades del departamento. Este es un software que se necesita usar durante todo el semestre. No todas las funciones deben usarse al principio.

Por lo tanto, estamos utilizando el modelo Agile: cuando el personal necesita una determinada característica, plantea una solicitud y yo hago los cambios. Al final del semestre, supongo que todas las características requeridas serán planteadas e implementadas.

El problema: cada
vez que mi jefe me pregunta cómo va el progreso, no puedo responder, porque no sé cómo responder. No tengo una lista completa de todas las características requeridas. A pesar de que he completado funciones que surgieron la semana pasada, todavía no puedo decirle a mi jefe que he "completado", porque también están llegando nuevas funciones y no sé cuánto. No puedo decir "Tenemos cuántos% de finalización" ni "Vamos a completarlo en xxx". En algún momento de 3 solicitudes, logro completar 2, le diría a mi jefe "He completado 2, pero hay una característica que aún no está completa". Después de un largo período de tiempo, suena como "Siempre tengo algo que no termina, después de tanto tiempo".

No poder informar sobre el progreso me hace ver realmente mal. No se trata de cuánto he hecho, sino de cómo hacer que la gente sepa. Si yo fuera el gerente, y mi personal sigue sin informarme sobre el progreso durante meses, sentiré que este tipo también es incapaz.

¿Tienen alguna idea de cómo informar o responder preguntas tan simples como "cuál es el estado / progreso de la modificación del software"?

ACTUALIZACIÓN Mi jefe no participa directamente en la tarea de desarrollo, por lo que no tiene idea de lo que estoy haciendo o de cómo funciona el programa. No nos reunimos regularmente porque está ocupada, y creo que será una pérdida de tiempo porque ella no es la usuaria principal, no conoce los detalles del programa.

Me reúno regularmente con el personal que usa y conoce mejor el software.

Me cuesta explicarle el progreso a mi jefe.

Este es un problema común cuando eres un programador que trabaja de manera independiente y le reportas a alguien que no es técnico.

Los jefes así en su mayoría quieren poder resolver algunas cosas:

• ¿Qué tan felices están los usuarios?
• ¿Se están haciendo las cosas que los usuarios quieren hacer?
• ¿Lo que estás haciendo vale el dinero que te pagan?

¡Una quema ágil o cualquier otra cosa como esa sería una idea terrible! Como dijiste, tu jefe está muy ocupado, por lo que no tendrían tiempo para aprender al respecto, y probablemente no le interese de todos modos.

Entonces, si fuera usted, les enviaría un informe por correo electrónico una vez por semana que contiene:

• Un "resumen ejecutivo" al comienzo: "Terminé 3 funciones esta semana y obtuve 2 nuevas solicitudes de funciones. Al comienzo de esta semana, había 11 solicitudes de funciones sin terminar, y al final hubo 10".
• Una lista de estado de funciones, con una breve oración cada una, en tres grupos:
  1. Las funciones que realizó durante la semana
  2. Las solicitudes de funciones que llegaron durante la semana
  3. Las otras características en el "backlog"
• Una breve discusión sobre cualquier cosa que fuera complicada o inusual, preferiblemente utilizando un lenguaje no técnico.

Si yo fuera tu jefe, y no hubiera recibido ningún informe, estaría muy feliz de recibirlo todas las semanas. Y si quisiera algo diferente, te lo pediría.

Parece que no tienes forma de saber si estás completo o qué tan avanzado estás para completarlo. Eso está bien.

Mantenga una lista de las características solicitadas, cuáles están hechas, en progreso o no iniciadas. Haga un seguimiento de estos como gráfico semanal del total en cada categoría. Esto le dará un conjunto de puntos que puede extrapolar a la fecha de finalización. Es decir (mirando solo los recuentos de funciones "completadas")

• Semana 1 - 2 completa
• Semana 2 - 5 completa (2 de la semana 1, 3 de la semana 2)
• Semana 3 - 8
• Semana 4 - 12

Si tiene 16 semanas, puede completar unas 48 funciones (no se preocupe demasiado por el hecho de que algunas funciones sean más grandes / más pequeñas que otras, después de 4-5 semanas generalmente se promediará). Luego puede informar a todos que solo puede manejar X número de funciones. Al final del proyecto, lo más importante es que ha entregado las funciones necesarias y no se ha suicidado en las últimas dos semanas. Al informar de esta manera, puede extraer los requisitos clave lo antes posible.

La otra cosa que querrá informar es cuánta capacidad tiene. "Solo recibí 2 solicitudes de funciones, pero podría haber manejado 3 ... ¿puede pedirle al personal que presente más funciones antes?"

No estoy seguro de haber respondido completamente a su pregunta, así que siéntase libre de hacer preguntas de seguimiento ...

Tres palabras ... quemar tabla.

Su empleador, sean o no adictos ágiles o simplemente una persona a cargo de los desarrolladores, apreciarán un cuadro de consumo .

A todos les encanta entender cuándo se completará un proyecto y aprovechar el clima de ayer proporcionará la forma más precisa y realista de predecir la finalización de un proyecto.

Supongo que haces un uno a uno al menos una vez a la semana, y puedes discutir tus prioridades con tu gerente en ese momento: lo que es importante desde su punto de vista (tal y tal necesita su función antes otra persona, etc.) y, por lo tanto, puede informar cuánto de lo que hace que su gerente se vea bien frente a la cantidad de cosas que tiene que hacer en total.

Su gerente probablemente no esté buscando un desglose minuto por minuto; él / ella solo está tratando de ver si el trabajo se está haciendo, si las cosas importantes están recibiendo más atención, y que no se está ahogando bajo la carga o inactivo porque está bloqueado para continuar.

Tenga en cuenta que en un verdadero proceso ágil, de hecho tiene cosas que llegan todo el tiempo, pero usted y su gerente acuerdan qué es lo más importante / más necesario y cuánto encajará en el período de trabajo actual (ya sea una semana, dos semanas, un mes ...), dividiendo los trabajos en partes más pequeñas si es necesario para que las piezas encajen en el período.

Una revisión importante de la base de datos que tome varias semanas podría desglosarse de la siguiente manera: establecer copias de seguridad, verificar que las copias de seguridad sean buenas, diseñar el nuevo diseño de la base de datos, escribir el software de conversión y probarlo, configurar la reversión y probarlo, probar la conversión en la máquina de ensayo, probando la reversión en el mismo lugar, y finalmente haciendo la conversión. Cada uno de ellos probablemente se puede dividir en trozos de 1 semana (o menos). Si algunos pasos pueden demorar 2 o 3 semanas, informaría qué tan avanzado estuvo en la próxima reunión (con un objetivo del 50% para 2 semanas, 33% para 3 semanas, etc.).

Idealmente, tendría una tabla que contiene las cosas que necesita hacer frente a las cosas que va a hacer ahora, y marcaría los elementos "hacer ahora" a medida que avanza. Esto le permite a su gerente simplemente pasar y ver cuántas cosas están marcadas frente a las cosas que hay que hacer en la lista.

Una vez por semana (supongo que la duración de la iteración / sprint en su proceso ágil es de una semana por el bien de ejemplo), haga lo siguiente :

• Demostrar el nuevo trabajo al personal, para asegurarse de que sus solicitudes se hayan completado
• informe al jefe la cantidad de solicitudes que completó durante la semana e identifique / describa esas solicitudes. Hacer un breve resumen
• informe al jefe la cantidad de solicitudes nuevas agregadas a su cartera / cola durante la semana y la cantidad total de solicitudes
• dígale al jefe en qué (qué solicitudes) planea trabajar la próxima semana; en otras palabras, las prioridades actuales. Esta es la oportunidad para que ella los confirme o los cambie y para que ustedes dos tengan claro eso
• dígale al jefe cuál es el plan para 1-2 semanas después de eso.

Tengo la sensación de que su jefe no es lo suficientemente técnico como para cuidar o comprender términos ágiles como velocidad , propietario del producto o gráfico de consumo . La plantilla anterior evita dicha jerga, utiliza palabras más simples como "trabajo atrasado" y "cola" en su sentido común y, por lo tanto, debería facilitar la comunicación con su jefe.

Usaría mi velocidad como la estadística principal para él / ella. Esto mostrará cuántas tareas / características "acordé" hablar durante una semana en particular (u otro intervalo de tiempo) y cuántas completé. A partir de esto, mencionaría algunas de las herramientas más importantes implementadas, y por qué esto ha cambiado desde las iteraciones pasadas. También puede mencionar los impedimentos que encontró y superó y cómo eso afectó su velocidad.

Otras estadísticas que su jefe puede desear conocer podrían incluir la cantidad de nuevos informes de errores generados, informes de errores cerrados y nuevas solicitudes de funciones enviadas. Tendrá que preguntar directamente o usar su mejor criterio para determinar cuáles son los más importantes. Al final, daría un resumen básico del progreso y preguntaría si hay algo más que a él o ella le gustaría saber. Todo lo que el jefe quiere saber es que estás progresando y hay algo que necesites para trabajar lo mejor posible.

Le sugerimos que confirme el informe semanal: enumere las características solicitadas. Grabe las características modificadas. Reporte lo que ha hecho.

Trataría de resumirlo de una manera que los gerentes entiendan.

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

El hecho de que su gerente no sea un programador no cree que eso signifique que espera que usted sepa una fecha exacta de finalización. Presenta los números que tienes. Una vez que el administrador ve el número de solicitudes recibidas y completadas, el administrador ve el progreso. Si los números de sus solicitudes se salen de control, el gerente puede intervenir y ayudarlo priorizando antes de que se sobrecargue. Y si se está quedando sin trabajo, pueden encontrarle un pequeño proyecto paralelo. Después de todo, siempre es bueno descansar un poco en un proyecto cuando parece que no hay un final a la vista y los días de trabajo pasan más rápido y son más gratificantes cuando estás ocupado.