
Agile proporciona respuestas reales y efectivas a una pregunta que mantiene a los ejecutivos despiertos: "¿Cómo mantenerse exitoso en un mundo que cambia rápidamente e impredecible?" Esta metodología ya ha conquistado el mercado, lo que demuestra que es uno de los mejores enfoques para crear y entregar software. Agile for All está dirigido a profesionales, a partir de este libro aprenderá cómo organizaciones enteras, desde gerentes de productos y desarrolladores hasta especialistas en marketing y ejecutivos, pueden utilizar un enfoque "flexible".
Matt LeMay simplemente y sin jerga explica qué es Agile y ofrece pasos concretos y efectivos que permiten a cualquier equipo realizar sus tareas de la manera más eficiente posible. Encontrará muchos ejemplos que son adecuados para cualquier tipo y tamaño de organización, desde nuevas empresas hasta grandes empresas, que le permiten implementar el enfoque ágil en diversos campos de actividad.
Sumérgete en la práctica ágil: "whoopee!"
Cuando trabajaba como gerente de producto, tenía muchas prácticas y marcos ágiles listos para usar que podía usar como equipo. Estos marcos se relacionan exclusivamente con las necesidades de los equipos de desarrollo de software y han sido probados en la práctica por miles de expertos, muchos de los cuales han compartido amablemente sus experiencias en forma de publicaciones accesibles y publicaciones en blogs.
Sin embargo, cuando comencé a trabajar como consultor, no pude entender de inmediato cómo usar estos métodos con respecto a objetivos completamente diferentes de los nuevos equipos. Los resultados de nuestro trabajo - informes analíticos obtenidos después de meses de largas consultas, seminarios sobre la formación de la imagen del cliente - fueron significativamente diferentes de los productos de software, ya que ya no teníamos una forma clara y objetiva de verificar el desempeño de estos resultados. Además, en nuestros roles, todos los límites se han borrado en comparación con los roles en el equipo de desarrollo, ya que ahora todos hicimos algo común, sin escondernos bajo los títulos de "diseñador visual" o "desarrollador front-end".
Atrapados en este desorden procesal, intentamos hacer frente a un conjunto estándar de problemas que surgen para los equipos que producen resultados no técnicos. El tema de estos resultados se expande imperceptible e inevitablemente a medida que trabajamos, especialmente cuando cambiamos de estados intermedios (bocetos) a documentos y presentaciones completos. El propósito orientado al cliente de cada resultado a veces no estaba claro para nosotros, por lo tanto, en tales casos, ampliamos el tema de la investigación para no "perder" nada. A pesar de que nos gustaba trabajar juntos, no siempre entendíamos quién, para qué, cuándo y por qué era responsable.
Vale la pena señalar que los métodos ágiles “legales” no siempre encajaron perfectamente en la estructura de nuestro equipo o los resultados, sin embargo, entendimos que los principios ágiles fundamentales podrían mantenernos en la dirección correcta. Por lo tanto, comenzamos a hacernos preguntas que formaron la base de este libro: ¿con qué claridad entendemos las necesidades de nuestro cliente? ¿Podemos eliminar todos los malentendidos laborales a través de la cooperación oportuna? ¿Nos aseguramos de que la introducción de nueva información en el flujo de trabajo no se convierta en un procesamiento completo del material?
Comenzamos a hacer estas preguntas regularmente en reuniones de planificación y retrospectivas, cambiando el flujo de trabajo para reflejar nuestras ideas y respuestas. Después de experimentar durante aproximadamente un año, convertimos nuestro enfoque en una práctica de WHPI (leída como "woooops" o "¿Por qué, cómo, prototipo, iteración")? WHPI consta de cuatro pasos, que se dan en la tabla. 6.3. Para empezar, usted decide colectivamente por qué pone el resultado en primer lugar, qué impacto espera y qué valor recibirá su cliente. Luego, usted decide cómo proporcionará este valor, cómo se verá el resultado final. Finalmente, le indica a uno de los miembros del equipo que cree un prototipo en un tiempo limitado que refleje la experiencia que desea crear para el cliente, luego repita este prototipo y verifique si fue capaz de lograr los objetivos que estableció en el primer paso.

Descubrimos que WHPI es una poderosa herramienta ágil que puede integrarse en cualquier equipo, independientemente de sus tareas y objetivos. A continuación se muestra una breve descripción de cada paso de WHPI, y algunos consejos para implementar y utilizar estos métodos como parte de su equipo.
PASO 1: ¿Por qué?
Para este paso, reunimos a varios participantes clave del proyecto (2–4) y discutimos rápidamente un conjunto de objetivos o resultados del proyecto. Si es posible, nos reunimos en un solo espacio físico (o virtual) y elaboramos todas las ideas registradas en las etiquetas adhesivas durante el proceso de trabajo. Por lo general, estas reuniones duran de 15 a 30 minutos. Aunque estos plazos pueden parecer difíciles e inconvenientes para reuniones tan importantes, reflejan una verdad importante: si no puede determinar los objetivos principales en 15-30 minutos, necesita obtener más información antes de seguir adelante. Varias veces en esta etapa, nos dimos cuenta de que era necesario realizar una investigación básica para confirmar nuestras suposiciones o hacerles a nuestros clientes algunas preguntas aclaratorias. Después de haber creado un único conjunto inicial de objetivos "por qué", los colocamos en el centro de atención para que dirijan el resto del proceso de trabajo.
Por ejemplo, cuando desarrollamos un informe analítico después de una reunión, a menudo escribimos tres "por qué" principales en las etiquetas:
- Transmitir una comprensión de la fuerza impulsora del proyecto a la alta gerencia.
- Recuerde a los asistentes las ideas clave de la reunión.
- Despertar el interés entre los empleados que no asistieron a la reunión.
Tenga en cuenta que ninguno de estos puntos indica directamente cómo vamos a lograr nuestros objetivos, ¡más sobre eso más adelante!
PASO 2: Cómo
Una vez establecidos los objetivos del proyecto, pasamos a la difícil tarea de determinar cómo alcanzarlos. A menudo llamamos a este paso "definición de herramientas", es decir, cuando sabemos lo que haremos, debemos pensar en herramientas y enfoques. Recomiendo pasar de "por qué" a "cómo" con los mismos participantes de la reunión. A menudo, al definir un "cómo", usted comprende por qué al menos un objetivo principal del equipo de "por qué" es en realidad un paso de "cómo" a nivel ejecutivo.
En la sección anterior, identificamos el siguiente "por qué": "despertó interés entre los empleados que no asistieron a la reunión". Antes de utilizar este método, definimos un objetivo similar de la siguiente manera: "Explicar a los participantes el lenguaje y los marcos para que puedan compartir información con sus colegas". Pero después de que comenzamos a separar el "por qué" del "cómo", nos dimos cuenta de que nos habíamos perdido dos preguntas clave: ¿por qué es importante que las personas compartan estas tareas con sus colegas y cómo podemos simplificar el proceso para lograr los objetivos? ¿Es el lenguaje y los marcos lo que la gente realmente necesita? Como logramos analizar en este libro, la atención prioritaria a los clientes y sus necesidades a menudo ayuda a reducir la cantidad de trabajo que esperábamos o a comprender que el resultado deseado es significativamente diferente de lo que planeamos lograr.
Dado el "por qué" de la última sección, podemos identificar el siguiente "cómo" para dirigir el flujo de trabajo:
- Cree un breve informe de análisis de dos páginas que pueda entenderse y difundirse fácilmente.
- Utilice citas memorables de los participantes para transmitir la comprensión de la fuerza impulsora a la alta gerencia.
- Use las fotos de la reunión para recordarles a los participantes momentos interesantes.
- Promueva resultados positivos y limite la cantidad de detalles para mantener el resultado enfocado y generar un interés generalizado.
Como puede ver, "cómo" proporciona un plan de acción o plan para crear todas las condiciones necesarias para lograr los objetivos previstos. Este paso determina la forma de nuestro resultado, aborda directamente nuestro "por qué" y proporciona límites claros y móviles para evitar la pérdida de control sobre los resultados deseados. Un plan tan claro le permite delegar tareas para lograr resultados mucho más rápido, independientemente del enfoque que utilice en los próximos pasos.
PASO 3: prototipo
Al definir "por qué" y "cómo", estamos listos para crear un prototipo de tiempo limitado. La palabra "prototipo" puede significar muchas cosas en diferentes contextos. En el contexto de este método, definimos un prototipo de la siguiente manera:
- Un prototipo no es un modelo o un documento de planificación; se crea en el mismo formato que el resultado o resultado deseado. Por ejemplo, el "prototipo" de una presentación con diapositivas es una presentación con diapositivas. El "prototipo" de un folleto impreso es un folleto impreso.
- Un prototipo se crea en un período de tiempo limitado y predeterminado. (Creado como parte del time-boxing).
En otras palabras, "creamos las condiciones para lograr el número máximo de objetivos del proyecto (" por qué ") utilizando enfoques y herramientas aprobados (" cómo "), en el mismo formato y con el mismo marco de tiempo que el resultado deseado. En el caso de proyectos pequeños, como carteles, el prototipo inicial puede parecer un resultado final. En el caso de proyectos grandes, como un informe de cuarenta páginas, el prototipo inicial puede ser 20 páginas completas dobladas por la mitad, engrapadas y rellenadas a mano (con páginas numeradas, encabezados, resultados breves y lugares para imágenes).
Como discutimos en el Capítulo 3, nuestro objetivo aquí es acercarnos lo más posible a la experiencia del cliente al crear nuestra propia versión de "software de trabajo". Las cosas que se ven geniales en modelos y documentos de planificación no funcionan en presentaciones, informes y reuniones. La verificación de los resultados iniciales utilizando el método prototipo nos ayudó a penetrar en la experiencia del cliente, reducir el número de mejoras y analizar los supuestos iniciales con más detalle.
Como regla general, designamos a un miembro del equipo para que se encargue de crear el prototipo principal. A menudo esto se convierte en una cuestión de tiempo libre: ¿quién puede reservar varias horas en los próximos días para hacer el primer intento? Descubrimos que dos horas de trabajo es la limitación estándar para crear un prototipo, lo que le permite crear una base para la comparación con los objetivos del proyecto y deja espacio para el desarrollo y la iteración.
PASO 4: iteración
Después de crear el primer prototipo de tiempo limitado, el equipo original de participantes (o parte del equipo) se reúne para analizar el prototipo y discutir la próxima iteración. Nuestras primeras discusiones se llevaron a cabo en el formato más / sugerir, en el que cada miembro del equipo habla sobre aspectos exitosos y sobre elementos que necesitan mejoras. (Utilizamos el mismo formato exacto en nuestras retrospectivas, por lo que volvimos rápidamente a él). Poco a poco volvimos a convertir este formato en el llamado debate "proteger, excluir, mejorar". Después de presentar el prototipo, los participantes comparten tres tipos de revisiones:
- Lo que debe quedar para las próximas iteraciones, ya que es más consistente con todo el "por qué".
- Lo que se puede excluir de las siguientes iteraciones, ya que no corresponde a todos los "por qué".
- Lo que debería mejorarse para las próximas iteraciones, ya que todavía puede ayudar a lograr el "por qué" necesario.
La diferencia clave entre este enfoque y el formato tradicional más / oferta es una discusión abierta de lo que debe excluirse de las siguientes iteraciones. Comenzamos a usar este enfoque después de descubrir que los cambios más exitosos para las iteraciones ocurren después de la exclusión, no de la adición, incluso en los proyectos más grandes. Una "excepción" abierta durante las discusiones permite a los participantes realizar un seguimiento de los aspectos que se pueden eliminar, lo que proporciona resultados más precisos y centrados. Al alinear los tres tipos de revisiones con el "por qué" previamente acordado, resolvemos todos los conflictos potenciales, evitamos momentos incómodos y mantenemos el proyecto en la dirección correcta.
Después de recopilar comentarios, uno de los miembros del equipo transforma estas revisiones en otro prototipo de iteración de tiempo limitado. En algunos casos, esto lleva a una revisión completa del último prototipo (por ejemplo, una revisión de la presentación). En otros casos, esto lleva a la creación de un nuevo prototipo basado en prototipos antiguos (por ejemplo, un informe sobre los resultados en Word basado en prototipos escritos a mano). Estas rondas de iteración consecutivas pueden ser controladas por una persona que creó el prototipo inicial o por cualquier otro miembro del equipo. En la segunda o tercera iteración, el prototipo a menudo está en manos de la persona que tiene la responsabilidad principal de presentar el producto modificado. Además, en la segunda o tercera iteración, el prototipo parece casi completo y listo para la revisión final.
»Se puede encontrar más información sobre el libro en
el sitio web del editor»
Contenidos»
ExtractoCupón de 25% de descuento para vendedores ambulantes -
AgileTras el pago de la versión en papel del libro, se envía un libro electrónico por correo electrónico.