project-management - máster - posgrado en project management eneb

¿Cómo adaptarse ágilmente a diferentes empresas? Una tesis de MBA (9)

Mi tesis de maestría es ver cómo aplicar ágil.

Hay una gran cantidad de ventas corporativas de Agile, muchos consultores de gestión que venden su marca como "la mejor".

No me interesa si es mejor XP , Scrum , Crystal Clear , Agile-CMMI , Six Sigma o cualquier otra marca / variante. Estoy interesado en lo que los desarrolladores reales y activos (es decir, ustedes) realmente aplican como ágil.

Lo que he investigado es cómo adaptar ágil a diferentes requisitos organizativos.

Desde la investigación sobre cómo las diferentes organizaciones aplican ágil, he desarrollado las siguientes pautas: una receta para determinar qué variaciones ágiles se deben aplicar en qué situaciones:

Los equipos más grandes y más distribuidos o más flexibles necesitan estándares más estrictos de codificación y prueba, los equipos pequeños pueden (y deberían) usar menos.
La documentación del proceso debe ser mínima, en tiempo real y actual.
Los indicadores de control estadístico detallados son un gasto innecesario: la publicación temprana de software incompleto es una mejor indicación del progreso.
Idealmente, los desarrolladores deberían estar cerca del cliente sin roles intermedios especializados. Las funciones adicionales solo deben usarse si los clientes están especializados de una manera que impida que los desarrolladores también sean usuarios.
Las iteraciones deben ser flexibles a menos que beneficie la coordinación de las publicaciones con otros departamentos u otros procesos.
Los desarrolladores deben poder comunicarse fácilmente y con regularidad, pero las reuniones deben ser poco frecuentes (mensuales y semanales, en lugar de diarias).
La programación en parejas solo debe usarse para tareas de capacitación e investigación.
Estas pautas son solo un punto de partida: se debe utilizar la mejora continua para adaptar aún más la variante ágil a las circunstancias exactas.

Estos factores cambian cuando se aplican en una organización con modelos tradicionales existentes (es decir, BDUF o waterfall ), donde los equipos ágiles deben coexistir con los equipos o ser adaptados de ellos utilizando métodos no ágiles:

La documentación del proceso con pasos de inicio de sesión y estructurados ayudará a otros equipos a realizar un seguimiento del proyecto.
Los indicadores estadísticos (como la velocidad) pueden ayudar a asegurar a los equipos no ágiles que el proceso está bajo control.
Las iteraciones fijas ayudarán a la coordinación entre equipos.

Estas pautas adicionales ayudarán a que Agile coexista con los modelos tradicionales, pero brindan sobrecarga y restricciones adicionales.

Lo que quiero saber es lo que ustedes, las personas que escriben software, no los consultores ágiles, piensan en este marco.

¿Qué crees que es exacto? ¿Qué crees que está mal? ¿Qué cambiarías? ¿Qué me he perdido?

Lo más importante: ¿por qué?

He agregado una recompensa a esto para ofrecer un incentivo adicional para responder a una pregunta bastante larga. La recompensa se destinará a quien obtenga la mayor cantidad de votos de la comunidad SO. Me doy cuenta de que no hay una única respuesta correcta, pero estoy interesado en lo que está más cerca del consenso de la comunidad.

Los equipos más grandes y más distribuidos o más flexibles necesitan estándares más estrictos de codificación y prueba, los equipos pequeños pueden (y deberían) usar menos.

Las pruebas continuas son invaluables sin importar el tamaño del equipo. Lo que debería variar es la cantidad de pruebas basadas en la madurez del proyecto y la criticidad de los componentes.

Para los nuevos productos, las demostraciones periódicas son excelentes para la moral y son adecuadas para brindar una sensación de progreso a la gerencia.

Para productos maduros y de envío con una aceptación periódica mínima, las pruebas de las características principales rastrearán la preparación de un producto para su lanzamiento.

Para las principales interfaces del sistema, las pruebas unitarias son ilustrativas y ayudan a evitar sorpresas. Cuando se trabaja con subproyectos contratados, las pruebas unitarias son mejores que la documentación y son críticas para evitar demoras en señalar con el dedo.

El desarrollo de prueba en primer lugar es un experimento digno para las piezas de código de trabajo pesado. Si su activo más valioso es su tecnología, entonces debe ser extremadamente probado.

Los indicadores de control estadístico detallados son un gasto innecesario: la publicación temprana de software incompleto es una mejor indicación del progreso.

Los indicadores de control estadístico son vitales para la identificación temprana del proyecto, pero es mejor dejarlos en manos del "Entrenador ágil" o "Scrum Master" ya sea permanentemente o hasta que todo el equipo sea disciplinado para producir un informe preciso de los avances y retrasos.

Cuando se aplican de manera efectiva, las prácticas de desarrollo ágil deben producir historias y tareas que sean lo suficientemente pequeñas como para que se completen en horas o días. La administración efectiva del "juego de planificación" y la retroalimentación que resulta en el rebasamiento de tareas individuales pueden minimizar la sobrecarga de estimación y la recopilación de datos de progreso.

Finalmente, un registro histórico de las decisiones de los clientes (y / o de la administración) y una contabilidad de dónde se gastó realmente el tiempo (días) en respuesta a estas decisiones marcará el camino para mejorar los procesos de ingeniería y de negocios. Un diagrama de "carril de nado" o "gantt" con el desarrollo bloqueado y el tiempo empleado mostrará cómo "pero somos ágiles" no es una excusa para tomar decisiones comerciales precipitadas.

Idealmente, los desarrolladores deberían estar cerca del cliente sin roles intermedios especializados. Las funciones adicionales solo deben usarse si los clientes están especializados de una manera que impida que los desarrolladores también sean usuarios.

Por una vez estoy de acuerdo! Las reuniones separadas de desarrollo y gestión funcionan bien para separar las preocupaciones.

Las iteraciones deben ser flexibles a menos que beneficie la coordinación de las publicaciones con otros departamentos u otros procesos.

Las iteraciones ágiles son un ritmo de desarrollo valioso para establecer un producto que se libera continuamente. Los fines de las iteraciones son cuando se pueden implementar decisiones de características y se pueden hacer cambios en el control de origen para bifurcar las características que no serán el objetivo.

Sin embargo, esta práctica puede ser difícil de implementar para los equipos cuando las iteraciones no satisfacen las necesidades del negocio. Las iteraciones deben programarse en función de las necesidades comerciales, como demostraciones y promociones.

Los desarrolladores deben poder comunicarse fácilmente y con regularidad, pero las reuniones deben ser poco frecuentes (mensuales y semanales, en lugar de diarias).

Lunes / jueves las reuniones de pie son una gran idea. Sin embargo, necesita una tapa dura de 15-30 minutos. Divida la reunión según sea necesario para reducir el tiempo. Preocupaciones separadas para evitar perder tiempo de desarrollador.

Un perro de oficina puede ayudar a mantener a la gente atenta durante las reuniones. Unos cuantos ladridos son mejores que las personas que se quedan dormidas o enviando mensajes de texto.

La programación en parejas solo debe usarse para tareas de capacitación e investigación.

La programación en parejas, las pruebas unitarias, la refactorización sin piedad y las prácticas basadas en pruebas son algunas de las habilidades ágiles más difíciles para los equipos que adoptan. Los beneficios de la programación en pares son aumentar la conciencia y el conocimiento y evitar que el trabajo se realice de forma aislada, donde las malas decisiones y suposiciones pueden persistir y caer en cascada.

Los equipos más grandes y más distribuidos o más flexibles necesitan estándares más estrictos de codificación y prueba, los equipos pequeños pueden (y deberían) usar menos.

Los estándares de codificación y prueba deben existir independientemente del tamaño del equipo. Mejoran la capacidad de mantenimiento del código y facilitan la actualización de los nuevos recursos.

La documentación del proceso debe ser mínima, en tiempo real y actual.

Convenido.

Los indicadores de control estadístico detallados son un gasto innecesario: la publicación temprana de software incompleto es una mejor indicación del progreso.

No hay muchos indicadores de control estadístico para el desarrollo de software que sean consistentemente valiosos. Buscaría la variación en el tiempo y el presupuesto, la tasa de defectos en la prueba y en la producción, y la variación en las estimaciones.

Idealmente, los desarrolladores deberían estar cerca del cliente sin roles intermedios especializados. Las funciones adicionales solo deben usarse si los clientes están especializados de una manera que impida que los desarrolladores también sean usuarios.

Muy a menudo esto es poco práctico o imposible. Los clientes tienen tanto que hacer en sus propios trabajos que rara vez tienen el tiempo de ser extremadamente prácticos con el personal de desarrollo. Los analistas de negocios tienen las habilidades necesarias para consolidar preguntas de negocios y obtener respuestas claras mucho más tiempo de manera efectiva. Si sus ciclos de lanzamiento son lo suficientemente cortos, los clientes tendrán muchas oportunidades de retroalimentación.

Las iteraciones deben ser flexibles a menos que beneficie la coordinación de las publicaciones con otros departamentos u otros procesos.

Debería haber cierta flexibilidad, pero no mucha. Uno de los beneficios de un enfoque ágil es que obliga al equipo a limitar el alcance a los requisitos más valiosos. Agregar flexibilidad al tiempo de iteración introduce un mayor riesgo de desplazamiento del alcance.

Los desarrolladores deben poder comunicarse fácilmente y con regularidad, pero las reuniones deben ser poco frecuentes (mensuales y semanales, en lugar de diarias).

Las reuniones diarias son efectivas con equipos más grandes. Mantienen a las personas en el camino y aumentan la colaboración. Ayudan a evitar que los miembros del equipo se atasquen en un problema sin pedir ayuda. También ayudan a mantener el control alrededor de la iteración, lo cual es muy útil si se tiene en cuenta la falta de otros controles disponibles.

La programación en parejas solo debe usarse para tareas de capacitación e investigación.

No tengo mucho que decir sobre esto.

Estas pautas son solo un punto de partida: se debe utilizar la mejora continua para adaptar aún más la variante ágil a las circunstancias exactas. **

¡EXACTAMENTE! Agile está destinado a flexionarse a las necesidades de la organización. El ajuste constante es esencial para perfeccionar el proceso.

Buena suerte a ti en tu tesis.

Los equipos más grandes y más distribuidos o más flexibles necesitan estándares más estrictos de codificación y prueba, los equipos pequeños pueden (y deberían) usar menos.
La documentación del proceso debe ser mínima, en tiempo real y actual.
Los indicadores de control estadístico detallados son un gasto innecesario: la publicación temprana de software incompleto es una mejor indicación del progreso.
Idealmente, los desarrolladores deberían estar cerca del cliente sin roles intermedios especializados. Las funciones adicionales solo deben usarse si los clientes están especializados de una manera que impida que los desarrolladores también sean usuarios.
Las iteraciones deben ser flexibles a menos que beneficie la coordinación de las publicaciones con otros departamentos u otros procesos.
Los desarrolladores deben poder comunicarse fácilmente y con regularidad, pero las reuniones deben ser poco frecuentes (mensuales y semanales, en lugar de diarias).
La programación en parejas solo debe usarse para tareas de capacitación e investigación.
Estas pautas son solo un punto de partida: se debe utilizar la mejora continua para adaptar aún más la variante ágil a las circunstancias exactas.

Los estándares de codificación / prueba IMO deben implementarse independientemente del tamaño y la distribución del equipo. Tener estándares de codificación / prueba lleva a un código más manejable / estable.

Estoy de acuerdo con la documentación. Al utilizar algunas prácticas de código limpio, como comentarios significativos y la intención de revelar las convenciones de nomenclatura en su código, elimina parte de la necesidad de documentación del código en sí. La documentación debe estar a nivel de negocios y prefiero que sea en forma de Pruebas de Aceptación.

Si bien los desarrolladores cercanos al cliente mejoran con el proceso de iteración, debe proteger al desarrollador de la empresa mediante el proceso que viene directamente al desarrollador para realizar adiciones / cambios / cambios de alcance. La empresa aún debe seguir el proceso a través de la preparación / priorización de la cartera de pedidos, etc.

Al usar las iteraciones de lanzamiento junto con las iteraciones de desarrollo, puede mantener un horario flexible de sus iteraciones que funcione para el equipo. Actualmente trabajamos en iteraciones de sprint de 1 semana con un sprint de lanzamiento cada 3 a 4 semanas.

El tipo de reunión debe dictar la frecuencia de la reunión. Standup diarios deben ser diarios. Proporcionan responsabilidad y transparencia al equipo, que es vital para tener un equipo exitoso. Las retrospectivas deben ocurrir al final de cada iteración y esa frecuencia está determinada por el tamaño de su iteración. Otras reuniones, como las revisiones de códigos, las demostraciones nunca deben dictarse a tiempo, sino en función de la necesidad y la finalización.

La programación de pares nunca debe ser clavada a tipos específicos. Hacemos programación en parejas con nuestros QA Testers, nuestro equipo de licenciatura, para que ambas partes tengan una mejor comprensión de las UAT y las Historias. También realizamos programación de pares para compartir conocimientos, creación de prototipos, tareas de investigación, etc. En nuestro entorno, la programación de pares se ha convertido en una segunda naturaleza.

La mejora continua en Agile se convertirá en una naturaleza de segunda mano a medida que aprenda a modificar las prácticas de Agile según sus necesidades comerciales. Mientras no te apartes del Manifiesto, tu Ágil debería tener éxito.

"La documentación del proceso debe ser mínima, en tiempo real y actual".

¿Qué quieres decir con "mínimo"? Es en el sentido de decir suma del número de páginas o en el sentido de cobertura (v.gr. documento de normas, manual de administración de configuración, documento de diseño).

Cuando asume un proyecto en el que no hay rotación de personal en el equipo, y en proyectos largos no es una suposición razonable, necesita un mecanismo eficiente para la transferencia de conocimientos, y el mecanismo más eficiente para la transferencia de conocimientos es la documentación.

He visto proyectos en los que la documentación se mantiene mínima (en el sentido de la cantidad de páginas) porque es demasiado engorroso desarrollar la documentación. Pero si puede reutilizar la documentación de un proyecto a otro sin cambios o cambios mínimos (y esto es razonable para documentos como los estándares de programación, el manual de administración de la configuración) no hay una carga de desarrollo de documentación.

La documentación del proceso debe abarcar todo el proceso de desarrollo del software o se arriesgará a tener procesos con pasos que se ejecuten de manera inconsistente. Los equipos ágiles tienen procesos de software ágiles. Y por procesos de desarrollo de software me refiero a mecanismos claros para administrar códigos, controlar versiones, controlar revisiones, verificar códigos, corregir errores, etc.

Como parte de su tesis doctoral, también debe considerar cómo se utiliza Agile en los equipos que se ubican en diferentes partes del mundo. Por lo tanto, si tiene un equipo de productos en la costa este, equipos de desarrollo en India y Rusia, equipo de control de calidad en Singapur y así sucesivamente. Esto para mí es un juego de pelota completamente diferente y necesita patrones completamente diferentes.

Por ejemplo, algunos de los patrones son:

En función de la zona horaria, empareje los madrugadores de una parte del mundo con los nocturnos nocturnos de la otra parte o viceversa. Esto no es exactamente una programación de pares, pero puede llamar a este el patrón que desee.
El énfasis debe ser hacer que el código sea lo más legible posible en lugar de escribirlo. Lo que esto significa es que es posible que tengamos que poner énfasis en los patrones de diseño uniformes y con fluidez, como los nombres.
Crea equipos de tal manera que tengas uno de ellos y uno de nosotros. Lo que significa que se empareja el desarrollador ruso con el desarrollador indio y trabajan juntos en un módulo.

Inventar tus propios patrones a lo largo del tiempo que hacen que el trabajo ágil sea realmente divertido y requiere mucha paciencia y trabajo duro.

Espero que este nuevo ángulo te ayude de alguna manera.

Los dos últimos puntos con los que tengo un pequeño problema. Las reuniones diarias de pie son muy beneficiosas. Nos permite repasar lo que trabajamos el día anterior y lo que intentamos trabajar hasta la próxima reunión (mañana). Es importante tener en cuenta que las reuniones de pie diarias deben ser cortas y al punto. Nos metimos en una situación en la que algunas personas disfrutaron planteando todo tipo de preguntas sobre el proyecto, por lo que decidimos que no se pueden hacer preguntas, solo declaraciones de productividad. Si hay preguntas, se programa otra reunión con la persona a cargo de ese componente.

Además, la programación de pares no debe utilizarse SOLO para tareas de capacitación e investigación. La programación en pares tiene muchos beneficios, como el intercambio / transferencia de conocimientos y la propiedad del código. Dos mentes sobre un problema pueden mostrar muchos puntos de vista interesantes y pueden ayudar a aislar posibles fallas de diseño. En mi opinión, la programación de pares está subestimada y la mayoría de los programadores egoístas no les gusta la programación de pares. Es un beneficio para el proyecto y para el equipo, no para uno mismo. El buen software está escrito por equipos de colaboración, no por un nerd.

Oh chico. Buena suerte.

Me gusta su enfoque, especialmente obteniendo comentarios de nosotros en lugar del set de powerpoint de Gold Watch.

Yo diría que cualquier enfoque de este tipo debe ser adaptable a las circunstancias específicas. Nadie debería hacer algo solo porque alguien más dijo que debería hacerlo. Pensar por uno mismo siempre debe estar a la vanguardia, en mi humilde opinión.

Ha pasado un tiempo desde que trabajé con los MBA de Sloan School, pero tuve la clara idea de que les habían enseñado que los programadores debían ser "administrados", en lugar de "cultivados". Que éramos una especie de producto desagradable, en lugar de miembros de todo el equipo. Espero que tengas una experiencia mejor que esa.

Practicamos ágil en una gran empresa con software altamente integrado y ventanas predeterminadas cuando el software puede implementarse en producción en entornos de hardware compartido.

Desarrollamos un conjunto de prácticas ágiles compuestas de prácticas SCRUM (gestión de proyectos) y prácticas XP (ingeniería). Muchos de los sistemas que implementamos utilizan procesos tradicionales de cascada.

Respecto a tu marco te responderé a cada elemento:

"Los equipos más grandes y más distribuidos o más flexibles necesitan estándares más estrictos de codificación y prueba, los equipos pequeños pueden (y deberían) usar menos".

Si al codificar y probar estándares se refiere a las prácticas de ingeniería (XP) como la integración continua, la programación en pares, el desarrollo basado en pruebas, las pruebas funcionales y de rendimiento, etc., empleamos todas las mismas prácticas independientemente del tamaño del equipo o proyecto. Como resultado, a menudo lanzamos software con cero defectos encontrados durante la Prueba de aceptación del usuario. El lanzamiento de software de alta calidad (defectos bajos) que sigue siendo maleable para permitir el desarrollo continuo a un ritmo sostenible impulsa la necesidad de prácticas de ingeniería, no el tamaño de la organización.

"La documentación del proceso debe ser mínima, en tiempo real y actual".

Si por documentación de proceso se refiere a la documentación de proceso ágil, todos nuestros ajustes en una pared. Mostramos el manifiesto, el mapeo de los 12 principios y finalmente las 21 prácticas que empleamos. El hecho de que encajen en la pared y sean altamente visibles permite al equipo comprenderlos y, lo que es más importante, ponerlos en práctica.

"Los indicadores de control estadístico detallados son una sobrecarga innecesaria: la publicación temprana de software incompleto es una mejor indicación del progreso".

El porcentaje completado en el trabajo tradicional, los artefactos de trabajo tienen poco valor. El mejor indicador de progreso es hacer una demostración del software de trabajo a nuestro socio / dueño de producto cada dos semanas. El seguimiento de la velocidad real (unidades de tarjetas de historia completadas) y las tasas de defectos y la visualización de los datos en grandes gráficos visibles es muy útil. Cuando se introducen ciertas prácticas en un equipo, es útil mostrar el progreso. Por ejemplo, la cantidad de prueba de unidad escrita antes del código al aprender TDD.

"Idealmente, los desarrolladores deberían estar cerca del cliente sin roles intermedios especializados. Los roles adicionales solo deben usarse si los clientes están especializados de una manera que evite que los desarrolladores también sean usuarios".

Los usuarios, si es posible, deben trabajar con el equipo en el espacio de trabajo abierto. Si no es posible que el usuario esté con el equipo, un proxy de usuario es la mejor persona para estar en la línea. Nadie puede dar mejores comentarios que las personas que realmente usarán el software para hacer su trabajo.

"Las iteraciones deben ser flexibles a menos que beneficien la coordinación de las publicaciones con otros departamentos u otros procesos".

Más importante aún, las fechas de lanzamiento deben estar alineadas entre los equipos. Las iteraciones son mejores si se mantienen consistentes en duración (usamos cada 2 semanas). La duración constante de la iteración es consistente con el boxeo en el tiempo y el cálculo de la velocidad utilizada para comprometerse con las tarjetas de la historia para la siguiente iteración.

"Los desarrolladores deben poder comunicarse de manera fácil y regular, pero las reuniones deben ser poco frecuentes (mensuales y semanales, en lugar de diarias)".

El equipo debe participar en la reunión diaria de pie, y en cada iteración, la reunión de planificación de iteraciones, la reunión de mostrar y contar, la reunión de planificación de póquer y la reunión retrospectiva. Cada lanzamiento el equipo participa en la reunión de planificación de lanzamiento. Dado que el usuario / socio comercial trabaja con la línea, puede ocurrir una conversación diaria sobre el trabajo que se está realizando.

"La programación de pares solo se debe utilizar para tareas de capacitación e investigación".

La primera razón para usar la programación por pares es eliminar los defectos. He escrito una serie de respuestas con respecto a la programación de pares. En resumen, las parejas con menor probabilidad de ser bloqueadas, menos propensas a tomar correos electrónicos o vacaciones en la web, proporcionan un mecanismo para transferir el dominio de negocios, el dominio de aplicaciones y las habilidades de práctica de ingeniería, eliminan silos de conocimiento (claves en organizaciones más grandes), etc.

"Estas pautas son solo un punto de partida: se debe utilizar la mejora continua para adaptar la variante ágil a las circunstancias exactas".

Retrospectivas, planificadas en cada iteración o cuando ocurre un evento que exige una llamada retrospectiva, y una mentalidad de cero defectos impulsa la mejora continua. Para los empleados, las prácticas de ingeniería de XP permiten al equipo mantener el código en buen estado, lo que permite que las nuevas funciones se agreguen fácilmente por tiempo indefinido. Tratamos los entregables de proyectos en cascada como restricciones. Para gestionar las restricciones, solicitamos el trabajo a estos equipos con mucha antelación y utilizamos técnicas de ingeniería como simulacros para probar las tarjetas de historia que se integrarán con estos entregables.

"Estos factores cambian cuando se aplican en una organización con modelos tradicionales existentes (es decir, BDUF o cascada de agua), donde los equipos ágiles deben coexistir o adaptarse de los equipos que utilizan métodos no ágiles:"

Tenemos equipos ágiles que viven en un mundo de cascada. Invitamos a los proyectos de cascada a nuestras reuniones de planificación de lanzamiento e iteración (y retrospectivas). El éxito que tenemos y lo que continuamos teniendo continúa brindando nuevos conversos a las prácticas ágiles dentro de la compañía.

"La documentación del proceso con pasos de inicio de sesión y estructurados ayudará a otros equipos a realizar un seguimiento del proyecto".

Discrepar. La pared de la tarjeta de la historia, el plan de iteración y el plan de lanzamiento son todo lo que necesitan los miembros del equipo o externos al equipo.

"Los indicadores estadísticos (como la velocidad) pueden ayudar a asegurar a los equipos no ágiles que el proceso está bajo control".

De acuerdo. Los equipos ágiles harán visibles las velocidades y las tasas de defectos. Los presupuestos estarán dentro del 1 o 2 por ciento y los lanzamientos estarán programados, ya que están encerrados en el tiempo.

"Las iteraciones fijas ayudarán a la coordinación entre equipos".

Necesario en entornos muy integrados y de gran tamaño. También ayuda al equipo a construir iteraciones y planes de lanzamiento basados en la velocidad.

Una causa noble, la mejor de las suertes. Todos los puntos buenos arriba también. Sólo añadiría:

Agile se trata de los principios, no del proceso.

Ver el Manifiesto Ágil .

Cambiar el comportamiento corporativo es el objetivo, no alterar un proceso comprobado para "trabajar con" una organización rota, así que enfatice los principios detrás de cada práctica. Y luego no cambies las prácticas . Si los principios no se aplican, entonces abandone la (s) práctica (s) que reflejan el principio. Cambiar la práctica compromete el principio y anula su propósito. El resultado final de tales "adaptaciones" es probablemente el mismo proceso defectuoso que ya se está utilizando , ahora envuelto en una terminología ágil pero sin los principios que lo hacen funcionar.

La documentación del proceso es anti-ágil.

"Process documentation with sign off and structured steps will help other teams track the project"

Tendría que decir un gran NO gordo a esto. La documentación eliminará el proceso de forma ágil (sin mencionar la vida y la energía de los desarrolladores). Si desea ayudar a otros equipos a rastrear el proyecto, publique el programa de iteraciones y la velocidad en la intranet. No desperdicie el tiempo de los desarrolladores ni la documentación del proceso de escritura del dinero de los clientes, especialmente para el supuesto beneficio de otras personas que no son partes interesadas y no tienen ningún riesgo .

Y, por supuesto, ningún candidato a MBA puede escapar de un subproceso de programador sin al menos una referencia de Dilbert:
_{(fuente: dilbert.com )}