En otra pregunta , pregunté por qué a los desarrolladores no les gusta el scrum diario . Hablamos con los desarrolladores y decidimos no mantener el scrum diario por un tiempo (para probarlo y scrum personalizado en nuestro primer intento). Este es el resultado de consultar directamente con los desarrolladores.
Por otro lado, no queremos perder buenas partes del scrum diario, como tener la oportunidad de coordinar a los desarrolladores todos los días, o ver el progreso del trabajo como un Indicador clave de rendimiento, para tomar medidas temprano.
Como alternativa al scrum diario, estamos pensando en pedirles a los desarrolladores que proporcionen informes diarios con las siguientes condiciones:
- No es necesario seguir ningún formato específico. Todos y cada uno de los formatos son aceptados.
- Incluso si el trabajo no está hecho, queremos escuchar la cantidad de progreso.
- No es necesario mencionar el tiempo dedicado a cada tarea.
- Deben mencionarse los obstáculos al desarrollo y los requisitos de coordinación.
- No hay necesidad de obsesionarse con los informes diarios. No se toma tan estricto.
¿Crees que esto puede disminuir su productividad? ¿Has tenido alguna experiencia en informes diarios? ¿Tiene alguna sugerencia para nosotros, para que podamos asegurarnos de que no estamos microgestionando ?
fuente
Respuestas:
Que idea tan terrible.
Si.
¿Por qué? Una presentación verbal en una reunión combina escritura y n personas "que leen" el informe en una actividad concurrente. Hablar más escuchar. Terminado y terminado. Preguntas respondidas de inmediato.
Escribir un informe es una pérdida de tiempo porque habrá preguntas y tendrá que revisar el informe con personas que (a) tienen preguntas y (b) realmente no lo leyeron.
Informes diarios, no serán leídos. Rápidamente se convierten en ruido de caja.
"No hay necesidad de estar obsesionado con los informes diarios". En cuyo caso, ¿por qué hacerlo?
Si. Tener un stand-up diario. Tarda unos minutos y ya está.
Si su stand-up diario toma más de unos pocos (15?) Minutos, está compartiendo demasiados detalles y necesita programar reuniones separadas para esos detalles. Las paradas diarias son fáciles de hacer. Después de un resumen de 2 minutos, todo lo demás probablemente sean detalles, no para todo el equipo, y debe ser llevado a una reunión de seguimiento. La reunión pasa al enfoque de la siguiente persona para el día.
fuente
He hecho esto en el pasado, pero en la mañana en lugar del final del día. En general, tardó menos de cinco minutos en completarse, así que no, no puedo ver cómo habría una disminución en la productividad de un desarrollador. Lo bueno de hacerlo por la mañana fue que te hizo pensar en lo que harás el resto del día.
Habiendo dicho eso ...
Descubrimos que era más de las veces, no era el método más efectivo de comunicar lo que habíamos hecho el día anterior y lo que íbamos a trabajar ese día. ¿Por qué? La gente generalmente no los leía. Era una tarea programada de Outlook, por lo que todos los enviaban todos los días, pero o se los pasaba por alto o simplemente se los perdían por completo (aparte de los clientes potenciales o la administración).
Descubrimos que tener los stand-ups diarios era mucho más valioso ya que las personas tendían a escucharse mutuamente. Además, si hubiera un malentendido, se eliminaría en ese momento, lo que es más probable que ocurra que alguien que responde a un correo electrónico de estado diario para hacer más preguntas.
fuente
Honestamente, permitir que cualquiera se presente sin restricciones parece un poco demasiado lejos para el lado liberal de la ecuación. Donde trabajo, vamos en círculo y cada desarrollador da lo siguiente:
Configurar un esquema general para que todos lo sigan puede facilitar la revisión de un informe determinado. Puede configurar fácilmente algún método para que todos reciban un correo electrónico con los informes diarios, y así permitir que cualquiera descubra lo que está sucediendo.
fuente
OMI, cualquier tipo de reunión / informe diario disminuye la productividad porque, para ser sincero, apesta a microgestión. Sí, estoy al tanto de Scrum y similares, y esos no son tan malos siempre que sean actualizaciones de estado breves ("Oye, ¿cómo va el Proyecto X?"), Pero creo firmemente que es insultante para los desarrolladores profesionales vigilar nosotros a ese nivel bajo; es similar a usar tarjetas de tiempo para asegurarse de que estamos en la oficina 8 horas al día, o asegurarse de que no haya paredes para que pueda espiar las computadoras de las personas para ver qué ventanas tienen abiertas en un momento dado.
Si tiene que vigilar a todos para asegurarse de que funcionan, significa que no confía en ellos. Si no confías en ellos, hay un problema mayor en el trabajo que el que te preocupa.
fuente
Mi equipo ha estado haciendo scrum durante aproximadamente un año. Antes de eso, teníamos dos reuniones por semana, durante las cuales cada miembro del equipo informaba sobre su actividad en los 2, 3 días anteriores. Cada reunión duró entre 30 minutos y 1 hora. En caso de que necesitáramos intercambiar información y coordinar nuestro trabajo, solíamos acercarnos a nuestros colegas y hablar con ellos (lo que todavía hacemos, por supuesto).
Ahora que estamos haciendo scrum, a menudo tenemos la impresión de que una reunión al día (aunque solo dura 15 minutos) es demasiado. A menudo, los informes de algunos miembros se reducen a: "Nada nuevo desde ayer". A menudo hemos tenido la impresión de que el esquema de 2 reuniones por semana era más efectivo.
Otro inconveniente es que la reunión diaria es una interrupción planificada (ver, por ejemplo, el artículo de Paul Graham , punto 1. Evite distracciones): como sabe que la interrupción va a llegar, no comenzará nada difícil antes de la reunión (las reuniones diarias pueden tener lugar una a una hora y media después de que uno haya comenzado a trabajar).
Por último, aunque no menos importante, si bien los comentarios iniciales tienen ventajas ("¡Oh, estás trabajando en ese problema, deberíamos discutirlo!"), A veces es más efectivo comenzar una discusión solo cuando ya has organizado tus ideas en tu mente , tiene preguntas específicas y se siente listo para la discusión. En cambio, los informes diarios pueden causar rápidamente una lluvia de ideas innecesaria y no estructurada. Por lo tanto, tenga cuidado con los comentarios demasiado tempranos : puede confundirlo y retrasarlo.
Entonces: en algunos casos, los informes diarios disminuyeron nuestra productividad. En promedio, no tengo la sensación de que hicieron nuestro trabajo más efectivo.
ACTUALIZAR
Escribí mi respuesta original hace un par de años, y mientras tanto he cambiado de equipo. En mi equipo actual, estamos haciendo reuniones diarias a pedido, es decir, cuando sentimos que necesitamos una breve actualización de estado. Entonces, todos los días existe la posibilidad de tener una reunión de este tipo, pero no lo hacemos si nadie lo solicita. Tenemos una reunión retrospectiva semanal. Esto es básicamente muy similar al enfoque que estábamos usando originalmente en mi equipo anterior, no ágil: reuniones semanales fijas más reuniones a pedido adicionales durante el resto de la semana.
fuente
Si lo que realmente desea es un estado aproximado y tomar nota de cualquier obstáculo, la mejor manera es pedirles un breve "correo electrónico de estado diario". Si le pone demasiado énfasis o hace una lista de lo que debería / no debería contener, al menos algunos de sus desarrolladores dedicarán más tiempo a elaborarlo para cumplir con los requisitos. En lugar de eso, solo pide un correo electrónico simple. Cuando surjan cosas durante el día, diga cosas como "oh, póngalo en su correo electrónico al final del día" y si recibe un correo electrónico realmente largo al final del día, mencione casualmente "no necesita ser tan detallado todos los días".
fuente
Es muy útil tener claro el propósito de cualquier reunión o informe, especialmente uno realizado por todos los días. Dices que la razón es:
¿Qué quieres decir con desarrolladores de coordenadas ? ¿Qué tipo de trabajo necesita coordinación y no ha sido coordinado ad-hoc por los desarrolladores y sus gerentes cuando es necesario? ¿Hay alguna forma de identificar tareas que necesiten coordinación y comunicarse solo en esos casos?
Muchos KPI buenos (como el tiempo de respuesta del sitio o la cantidad de errores críticos) serán medibles mecánicamente, y no es necesario imponer un costo a los desarrolladores para hacerlo.
fuente
He tenido que hacer informes diarios en varios formatos diferentes en el lugar de trabajo. En términos generales, creo que los informes diarios tienden a agregar solo valor para los gerentes, no para los propios desarrolladores. Si bien los gerentes se benefician de los informes diarios al poder determinar el estado general de cada proyecto y la carga de tareas de cada empleado en un corto período de tiempo, en mi experiencia, la mayoría de los desarrolladores no se molestan en leer los informes de estado de los demás.
Sin embargo, parece que al no aplicar un formato para sus informes diarios, hace que los informes sean más difíciles de leer y procesar tanto para gerentes como para otros desarrolladores, lo que exacerba el problema del tiempo perdido del desarrollador.
Si decide avanzar con informes diarios para sus desarrolladores, ¿podría sugerirle que use un wiki interno en lugar de informes por correo electrónico? De esa manera, no envía spam a las bandejas de entrada de las personas, mientras mantiene el historial de los estados diarios de todos.
fuente
Es una gran idea personalizar sus métodos ágiles para que se adapten a usted, así que felicitaciones por eso.
Entonces, en lugar de informes diarios, diría que esto no es mucho mejor que una reunión diaria, sigue siendo el mismo enfoque de "dime qué estás haciendo", simplemente has hecho que todos lo escriban en lugar de hablarlo.
Aquí hay un enfoque alternativo: en lugar de usar estas técnicas de 'sondeo' en las que le pregunta a cada desarrollador por su estado, usa una técnica de 'empuje' en su lugar. Sin embargo, si el desarrollador no tiene mucho que informar, no debe informar de todos y cada uno de los problemas y progresos a medida que ocurren. Entonces, cuando completan un módulo, deben enviar un correo electrónico a todo el equipo que está terminado, que está en SCM, donde se puede encontrar la documentación y un breve resumen de lo que es, cómo funciona y / o cómo usar eso. Si tienen un problema, deben enviar un correo electrónico al equipo pidiendo consejo, ayuda o algún consejo. (sí, al igual que en los viejos tiempos donde los equipos se comunicaban bien sin la microgestión que sufrimos hoy)
encontrará que esto es mucho más productivo y constructivo. No obtendrá informes sin sentido por el bien de ellos y obtendrá un equipo más motivado ya que a todos les gusta informar a sus compañeros de su trabajo.
fuente
También estoy de acuerdo en que es una mala idea reemplazar los stand-ups diarios con un informe. Un stand-up diario es un gran lugar para vocalizar ideas y problemas. Esta es una de las razones por las que me gusta la buena pizarra blanca (que utilizamos junto con Jira + Greenhopper). La pizarra es un lugar donde el grupo se 'acurruca' y comparte información, todo está allí, todo es visible, todos se mueven y cambian las notas adhesivas en las que trabajaron, también es muy divertido.
fuente
¿No puede extraer esta información de sus otras herramientas?
Cuando tenga preguntas más específicas para responder, vería la necesidad de informes específicos, pero sin eso sus informes se parecen un poco a sí mismos.
fuente