Un desarrollador está trabajando en un proyecto de investigación que implica trabajar con nuevas tecnologías. Los conceptos también son nuevos para el desarrollador, y el desarrollador está trabajando en la creación de un producto sobre las nuevas API.
Como la tecnología es nueva y no está documentada, el desarrollador dedica mucho tiempo a desarmar demostraciones y analizar datos para comprender la tecnología.
Dado que muchas metodologías ágiles implican actualizaciones diarias o frecuentes del equipo, como Scrum y la reunión diaria, ¿cómo deberían los desarrolladores brindar actualizaciones a las partes interesadas tanto técnicas como no técnicas sin que parezca que no lograron nada? Tenga en cuenta que la reunión que tenemos actualmente no tiene nombre.
Cuando el trabajo implica un grado considerable de aprendizaje o adquisición de conocimientos, como PM, ¿cómo puedo aconsejar a estos desarrolladores que den sus actualizaciones sin hacerles sentir que no están progresando, ya que es posible que no haya nada que mostrar? dias/semanas?
¿Debería reducirse la frecuencia de las reuniones de estado, o debería permanecer igual con un enfoque diferente?
Para tener una investigación valiosa, generalmente se necesita definir su propósito y meta. Entonces, en otras palabras, el desarrollador sabe lo que quiere hacer, cuál es su progreso y cuáles son los problemas que enfrenta actualmente. La pregunta es cómo compartir ese conocimiento de manera significativa.
Si la reunión involucra solo un informe de estado, entonces solo hay una preocupación por describirlo de una manera compacta pero valiosa.
Por ejemplo , ya he comprobado cinco de los doce criterios de compatibilidad conocidos de la API. Por ahora no hay pruebas de una posible incompatibilidad, pero ayer me dieron cuenta de dos nuevos criterios.
Si la reunión también trata sobre el trabajo en equipo y revela el riesgo y el impacto general del trabajo de uno, entonces surgen muchos temas nuevos. ¿Alguno tiene bloqueadores? ¿Uno necesita ayuda? ¿Debería informar a alguien sobre descubrimientos importantes?
Una de las principales razones por las que investigamos es para reducir la incertidumbre. Mientras lo reducimos, a menudo necesitamos cambiar la dirección en la que vamos. Por lo tanto, cada vez que su investigación logra un progreso, existe una probabilidad creciente de que el estado de otra persona también deba ser influenciado . Anticiparlo y dar una actualización es probablemente una de las razones por las que existe tal reunión.
Dado que muchas metodologías ágiles implican actualizaciones de equipo diarias o frecuentes... ¿cómo deberían los desarrolladores proporcionar actualizaciones a las partes interesadas tanto técnicas como no técnicas sin que parezca que no lograron nada?
Si estuviera siguiendo Scrum, señalaría que las reuniones diarias son para el equipo y no para las partes interesadas. Los resultados de la iteración generalmente se proporcionan a las partes interesadas durante la Revisión del sprint al final de cada iteración con límite de tiempo.
Incluso si no está siguiendo Scrum, afirmo que pedirles a los desarrolladores que proporcionen actualizaciones centradas en las partes interesadas con demasiada frecuencia huele mucho a "responsabilizar a los desarrolladores" y conducirá a que los desarrolladores informen a CYA y, finalmente, reducirá la transparencia dentro del proyecto.
Considere la fábula de la gallina y el cerdo . El sitio enlazado dice:
En los proyectos Agile, el término Pig ha llegado a describir a todos los desarrolladores, diseñadores y evaluadores que se comprometen con el trabajo real. El término Chicken se aplica a todos los demás que hacen contribuciones intelectuales pero no se comprometen con ningún trabajo.
Es posible que desee considerar algunas opciones aquí, según su cultura y entorno corporativos.
Considere limitar las reuniones frecuentes a los cerdos (por ejemplo, el equipo de desarrollo) en lugar de incluir a las partes interesadas en reuniones que son de procedimiento.
Proporcione visibilidad a las partes interesadas a través de un tablero o alguna otra métrica de rendimiento clave que no implique una "responsabilidad personal" por parte de los desarrolladores individuales.
Haga que el gerente del proyecto sea responsable de las actualizaciones de estado de rutina para las partes interesadas, en lugar de los miembros del equipo. Esto permite que el PM eduque a las partes interesadas sobre lo que es (o no es) un progreso razonable y puede evitar que los desarrolladores informen a CYA.
Cree una reunión separada a intervalos definidos para preguntas y respuestas entre las partes interesadas y el equipo. En Scrum, esto sería una revisión de Sprint, pero el punto principal es brindar a las partes interesadas acceso directo al proyecto sin secuestrar el proceso interno del equipo.
Reúnase a intervalos apropiados para el tamaño de su lote. Descomponga el trabajo en partes de un día o menos, o aumente el intervalo entre reuniones. La idea aquí es cambiar los informes de "Terminé un 29,36 % con foo" a una actualización de estado de terminado/no terminado. Esto es más amigable para los desarrolladores y también más fácil de rastrear desde la perspectiva de un PM.
Cuando el trabajo implica un grado considerable de aprendizaje o adquisición de conocimientos, como PM, ¿cómo puedo aconsejar a estos desarrolladores que den sus actualizaciones sin hacerles sentir que no están progresando, ya que es posible que no haya nada que mostrar? dias/semanas?
La gestión de proyectos a menudo implica establecer expectativas y comunicarlas claramente dentro del equipo del proyecto y a varias partes interesadas. Independientemente de su metodología o sus intervalos de informes, debe educar a su organización sobre el proceso y establecer sus expectativas de manera adecuada.
Establecer las expectativas de las partes interesadas.
Si su proceso involucra entregas explosivas, asegúrese de que sus partes interesadas esperen informes apropiados. Estos pueden ser informes regulares que incluyen un nivel variable de entregables completados durante un período de tiempo, o informes irregulares cuando algo se completa y vale la pena llamar su atención.
Establezca las expectativas del desarrollador.
Asegúrese de que los desarrolladores sepan cómo serán medidos dentro de su metodología. Obtienes lo que mides y las personas optimizan las métricas que los impactan directamente. Si decide mantener los informes diarios, deje muy claro qué información espera rastrear, cómo se usará esa información y cómo afectará esa información tanto al proyecto como a cada desarrollador individual.
Explique las expectativas.
[T]o puede que no haya nada que mostrar durante días/semanas[.]
Asegúrese de que esta expectativa sea explícita y de que continuamente reeduque y tranquilice a todos sobre este punto. Pedir a los desarrolladores actualizaciones de estado diarias cuando la respuesta esperada es "Todavía no he terminado" hace que esto sea muy desafiante, en parte por razones psicológicas y en parte porque la forma en que está midiendo (actualizaciones diarias) está intrínsecamente en desacuerdo con la expectativa de ráfagas de su proyecto. resultados. Puede compensar esa disonancia hasta cierto punto manteniendo las expectativas reales al frente y al centro.
Una de las cosas buenas de un informe diario es que tienes que desglosar la tarea en partes, cada una en un día. Quiero decir que tienes que saber en qué estás trabajando hoy. Claro, tiene que investigar la API, pero ¿está investigando toda la API al mismo tiempo y escribe el código después de haber aprendido todos los métodos? ¿O está comenzando poco a poco y agregando nuevas funciones y, por supuesto, refactorizando mucho mientras aprende la API, para que sepa exactamente en qué está trabajando cada día? Si informa 2 semanas "Todavía estoy investigando", no le está diciendo nada al equipo y es mejor si no participa en la reunión en absoluto; sin embargo, si ahora mismo estoy trabajando con esta [parte de la API], o ayer tuve que volver a escribir toda la [parte de la API], tiene una actualización de estado. Y si 3 días seguidos estás diciendo "
Una respuesta tardía que solo puede ser relevante si divide los proyectos en Historias de usuario o equivalente.
el desarrollador está trabajando en la creación de un producto sobre las nuevas API.
Primero permítanme resumir mi comprensión de la situación. Hay un proyecto. Quiero decir que hay un software real que debe desarrollarse, el desarrollador debe implementar una lista de funciones en el software, es posible que las funciones ya se hayan dividido en historias, etc. El problema es que implementar estas funciones requiere que el desarrollador aprenda un nueva tecnología. Como consecuencia, es bastante imposible programar el trabajo o estimar el tiempo de finalización del proyecto. Además, no hay visibilidad para las partes interesadas en la parte de investigación actual.
En esta situación, recomendaría usar picos . Los picos son un tipo particular de historia introducido en XP. Están destinados a reducir el riesgo y la incertidumbre en una parte del proyecto mientras son estimables y programables. Deben estar enmarcados en el tiempo. En resumen, generalmente hay dos tipos de picos: picos funcionales y picos técnicos.
Los picos funcionales están diseñados para resolver problemas funcionales. Por ejemplo, no sabemos cuál es la mejor interacción del usuario para una historia, creamos un pico para prototipar varias posibilidades antes de implementar la historia real.
Los clavos técnicos son el tipo de clavos que podría necesitar. Úselos cuando necesite más información técnica antes de implementar una historia, una función o un proyecto. Esta entrada puede ser aprender una nueva tecnología, elegir entre varias implementaciones, elegir entre construir una solución o comprarla, etc.
Cuando un producto debe construirse sobre una nueva tecnología que no conocemos en absoluto, recomendaría usar tres niveles de historias:
Matías Jouan
jmort253