Pregunta:
Cómo celebrar los objetivos no alcanzados por completo
Philipp
2015-06-03 14:49:59 UTC
view on stackexchange narkive permalink

Nuestro pequeño equipo de software está desarrollando una aplicación web. Todos los desarrolladores son muy dedicados y trabajan duro para cumplir con la fecha límite. No obstante, cuando se implementa la versión, no es realmente perfecta. Toda la funcionalidad principal está funcionando (las pruebas pasan, etc.), pero faltan algunos ajustes: por ejemplo. algunos botones en la interfaz de usuario no están alineados, algunos textos que usan plantillas no funcionan bien en algunos idiomas, etc.

Estos detalles no son bloqueadores y serán corregidos en la próxima versión de Sprint & (la funcionalidad es a tiempo llave).

Entonces, la aplicación se implementa, pero en realidad no se ve muy bien y esa es la retroalimentación que recibe de la gente no tecnológica de la empresa. "Trabajo a medio hacer". ¿Cómo seguir celebrando el arduo trabajo y la dedicación que se incluyó en el lanzamiento, si el producto final no convence realmente a las personas que no son tecnológicas (incluso los desarrolladores están de acuerdo en que se necesita más trabajo, pero se han concentrado en la funcionalidad)?

En general, cuando se usa una metodología iterativa (pequeños cambios, lanzamientos a menudo), no hay un big-bang después del cual realmente tiene sentido celebrar. ¿Cómo seguir celebrando los lanzamientos? ¿Cómo generar orgullo por el trabajo realizado?

Sí, pero en ese momento solo un desarrollador todavía está haciendo el ajuste fino. Los demás ya están trabajando en las próximas funciones. Entonces se pierde el gran efecto.
Cada minuto que dedica a celebrar algo que aún no ha terminado es un minuto que le resta a la finalización del proyecto. Estás pidiendo algo prematuro. No es genial. Como solía decir Yogi Berra: "no se acaba hasta que se acaba" Celebre cuando sepa que ha terminado. ¿No te gustan las celebraciones retrasadas? Esta bien. Aprende a gustarles de todos modos.
@Philipp Aun así, cuando surja ese punto, presumiblemente * pueden * ser invitados a la celebración resultante, ¿no?
@VietnhiPhuvan: "Celebre su celebración cuando sepa que ha terminado". ¡Esa es la belleza de lo ágil! ¡Nunca termina! ¡Es solo una serie eterna de sprints quincenales!
@PaulD.Waite: no es exclusivo de Agile. Hace 20 años, todos escuchamos la frase: "El software nunca se termina. Solo se abandona".
Cuatro respuestas:
#1
+25
Joe Strazzere
2015-06-03 16:09:08 UTC
view on stackexchange narkive permalink

En general, cuando se usa una metodología iterativa (pequeños cambios, lanzamientos a menudo), no hay big-bang después del cual realmente tiene sentido celebrar. ¿Cómo seguir celebrando los lanzamientos? ¿Cómo generar orgullo por el trabajo realizado?

Cuando regatea lanzamientos, tiene razón en que no hay un punto definitivo ("big bang") donde tenga sentido celebrar.

Por lo tanto, busque eventos significativos relacionados con su trabajo fuera de su calendario de lanzamientos y celebre esas ocasiones.

El primer cliente o la primera descarga son eventos importantes en algunas tiendas. Algunas empresas. El objetivo de ventas alcanzado podría funcionar en otros lugares.

Algunas tiendas celebran cada iteración de una manera más pequeña, sin grandes explosiones. Un almuerzo de pizza, bagels para el desayuno, etc.

No siempre es necesario tener una gran celebración. Los enfoques iterativos sin duda borran la línea entre "en curso" y "completo". A veces no puede lograr un "gran efecto" y debe aprender a disfrutar de muchos "pequeños efectos" en su lugar. Un excelente escritor que conozco solía referirse a "guijarros de una pulgada" versus "hitos".

#2
+8
Edwin Lambregts
2015-06-03 15:22:22 UTC
view on stackexchange narkive permalink

Para evitar que se centre por completo en la funcionalidad, asigne a alguien que se centre en la interfaz de usuario cuando finalice aproximadamente el 80% de la funcionalidad. Si esa persona puede poner todo su esfuerzo en la interfaz de usuario, es menos probable que las personas sin conocimientos técnicos critiquen su trabajo como "trabajo a medio hacer" porque alguien se encargó de la interfaz de usuario.

Como para la celebración, ¿por qué no hacerlo después de cada sprint? Siempre solía sentir un poco de alivio cuando terminamos un sprint, y si todos están contentos con el trabajo entregado en ese sprint, vale la pena celebrarlo. Podrías hacer esto relajándote con un par de cervezas o un pastel. O lo que sea que remos en su bote :) Sin embargo, recomendaría que sea simple.

Sí, una caja de donas o algo al final de un sprint suele ser suficiente. Si la gente quiere hacer algo un poco más de celebración, coma o lo que sea en el momento en que pase de esa aplicación a otra cosa, o inicie una nueva fase o algo.
#3
+4
Eric
2015-06-03 19:04:45 UTC
view on stackexchange narkive permalink

Si publica suficientes lanzamientos que los clientes no reciben de inmediato con los brazos abiertos, comenzarán a temer las actualizaciones y tendrán una mala opinión de la capacidad del equipo para cumplir. Esto también comenzará a afectar la moral del equipo.

Es bueno que reconozca que el equipo está haciendo todo lo posible y que las circunstancias externas (por ejemplo, plazos poco realistas) son la causa principal de la mala retroalimentación inicial. Es importante reconocer que tiene un problema estratégico (cómo entregar un lanzamiento realmente exitoso a tiempo) y un problema táctico (cómo mantener motivado al equipo trabajador frente a las presiones externas).

Algunos Las recompensas a corto plazo que pueden ayudar son tener una cena en equipo, agradecer públicamente sus esfuerzos, hacer que los clientes reconozcan la rapidez con la que se realizan las mejoras en función de sus comentarios, etc.

El problema estratégico es dónde debe aunque concentre sus esfuerzos. Quieres llegar a un lugar en el que no tengas que celebrar las metas parcialmente alcanzadas. Dos formas posibles de abordar esto son obtener cronogramas más realistas para el alcance requerido o reducir el alcance de los cronogramas dados para que se pueda entregar con éxito.

#4
  0
JasonWilczak
2015-06-03 21:58:30 UTC
view on stackexchange narkive permalink

Leí algunas de las respuestas y tocan mis pensamientos, pero no dan la definición ni la claridad, así que voy a dar mi respuesta.

Hicimos el primer lanzamiento ágil del área y duró unos dos años. Fue bien recibido y ha causado un efecto mariposa en otras partes del área. Dicho esto, hicimos algo llamado: Retrospectivas de Sprint

Publiqué un enlace oficial de MSDN de Microsoft, pero, como con cualquier equipo ágil, las reglas están destinadas a ser flexibles. Usamos las retrospectivas como una forma sencilla de determinar qué deberíamos empezar a hacer, las cosas que no salieron bien y las cosas que deberíamos celebrar.

Normalmente, el director del proyecto compraba algo de comida y nosotros comíamos y discute. Nunca fuimos a un restaurante y creo que eso fue clave porque nos ayudó a mantener la concentración en el Sprint y lograr algo de la retrospectiva, al tiempo que nos permitió celebrar lo que a todos nos gustó del Sprint.



Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...