• Author / Uploaded
• Jhoan Brayam

• Categories
• Proceso de desarrollo de software
• Computación en la nube
• Software
• Toma de decisiones
• Tecnología de información y comunicaciones

Citation preview

Notificaciones. Los estándares del Project Management Institute, Inc. (PMI) y publicaciones de directrices, de las cuales el documento contenía aquí es uno, se desarrollan a través de un proceso voluntario de desarrollo de normas de consenso. Este proceso reúne a voluntarios y/o busca los puntos de vista de las personas que tienen un interés en el tema cubierto por esta publicación. Mientras PMI administra el proceso y establece normas para promover la equidad en el desarrollo de consenso, no escribe el documento y no prueba de forma independiente, evaluar o verificar la exactitud o integridad de cualquier información o la solidez de los juicios contenidos en sus normas y directrices publicaciones. PMI niega responsabilidad por cualquier daño personal, propiedad u otros daños de cualquier naturaleza, ya sean especiales, indirectos, consecuentes o compensatorios, directa o indirectamente como resultado de la publicación, uso de la aplicación o confianza en este documento. PMI renuncia y no da ninguna fianza o garantía, expresa o implícita, en cuanto a la exactitud o integridad de la información publicada en este documento, y renuncia y no da ninguna garantía de que la información contenida en este documento va a cumplir ninguna de sus propósitos o necesidades particulares. PMI no se compromete a garantizar el rendimiento de cualquier producto o servicio de un fabricante o vendedor individual en virtud de esta norma o guía. En la publicación y haciendo de este documento a disposición, PMI no se compromete a prestar servicios profesionales o de otro tipo a favor o en nombre de cualquier persona o entidad, ni es empresa PMI para desempeñar cualquier trabajo contraída por cualquier persona o entidad a otra persona. Cualquier persona que use este documento debe confiar en su propio juicio independiente o, en su caso, solicitar el asesoramiento de un profesional competente para determinar el ejercicio de cuidado razonable en cualquier circunstancia. Información y otras normas sobre el tema cubierto por esta publicación pueden estar disponibles a partir de otras fuentes, que el usuario puede desear consultar para las vistas o información no cubierta por esta publicación adicionales. PMI no tiene ningún poder, ni se compromete a vigilar o hacer cumplir el contenido de este documento. PMI no certifica, prueba o inspeccionar productos, diseños o instalaciones por motivos de seguridad o de salud. Cualquier otra certificación o declaración de cumplimiento con cualquier problema de salud o información relacionada con la seguridad en este documento no debe ser atribuible a PMI y es responsabilidad exclusiva de certificador o del autor de la declaración.

1

Prólogo El Project Management Institute y Agile Alliance® han constituido esta guía de práctica para crear una mayor comprensión de los enfoques ágiles en sus comunidades. La visión de esta guía de práctica es para equipar a los equipos de proyecto con herramientas, pautas situacionales y una comprensión de las técnicas y enfoques ágiles disponibles para permitir una mejor resultados. Los equipos de proyecto están utilizando enfoques ágiles en una variedad de industrias más allá del desarrollo de software. Ambas organizaciones realizan la expansión que ha creado una necesidad para un lenguaje común, una mentalidad abierta y la voluntad de ser flexible en la forma en que los productos y los entregables se llevan al mercado. Además, ambas organizaciones se dan cuenta de que hay varias maneras de lograr la entrega exitosa. Hay una amplia gama de herramientas, técnicas y marcos; equipos tienen opciones para los enfoques y prácticas que se adapten a su proyecto y la cultura de la organización con el fin de lograr el resultado deseado. Los miembros del comité central de la Guía de práctica ágil tienen diferentes antecedentes y usan varios enfoques. Algunos de los miembros del comité son consultores y algunos trabajan dentro de las organizaciones. Todos han trabajado de manera ágil durante muchos años.

2

TABLA DE CONTENIDO

1.

INTRODUCCIÓN

2.UNA INTRODUCCIÓN A ÁGIL 2.1 El trabajo definible frente de alta incertidumbre trabajo 2.2 El manifiesto ágil y la mentalidad 2.3 de Lean y Kanban Método 2.4 Incertidumbre, riesgo y del Ciclo de Vida Selección

3.CICLO DE VIDA SELECCIÓN 3.1 Características de los ciclos de vida del proyecto 3.1.1 Características de los ciclos de vida de predicción 3.1.2 Características de los ciclos de vida iterativos 3.1.3 Características de los ciclos de vida incremental 3.1.4 características de Agile Life Cycles 3.1.5 Filtros de idoneidad ágil 3.1.6 Características de los ciclos de vida híbridos 3.1.7 Agile y Predictive combinados Enfoques 3.1.8 Enfoque predominantemente predictivo con algunos componentes ágiles 3.1.9 A bastante ágil Enfoque con un componente predictivo 3.1.10 Ciclos de vida híbridos como idóneos para un propósito 3.1.11 Ciclos de vida híbridos como transición Estrategia 3.2 Mezcla de enfoques ágiles 3.3 Factores del proyecto que influyen Sastrería

4.IMPLEMENTANDO ÁGIL: CREANDO UN AGILE AMBIENTE 4.1 Comience con una mentalidad ágil 4.2 Liderazgo de servidor empodera al Equipo 4.2.1 Responsabilidades del líder del servidor 4.2.2 Papel del administrador del proyecto en un entorno ágil 4.2.3 Los administradores del proyecto usan el servidor Liderazgo

3

Composición del equipo 4.3.1 Ágil Equipos 4.3.2 Ágil Roles 4.3.3 Generalizando Especialistas 4.3.4 Team Structures 4.3.5 Dedicated Team Members 4.3.6 Team Workspaces 4.3.7 Overcoming Organizational Silos

5.IMPLEMENTING AGILE: ENTREGANDO EN UN AGILE AMBIENTE 5.1

Charter el proyecto y el equipo 5.2 Common Agile Prácticas 5.2.1

Retrospectivas 5.2.2 Reserva Preparación 5.2.3 Reserva Refinamiento 5.2.4 Diario Standups 5.2.5 Demostraciones / revisiones 5.2.6 Planificación para Agile basado en Iteration 5.2.7 Prácticas de ejecución que los equipos de ayuda brindan Valor 5.2.8 Cómo las iteraciones y los incrementos ayudan a entregar el producto de trabajo 5.3 Solución de problemas Agile Project Chal enges 5.4 Medidas en Agile Proyectos 5.4.1 Medida de equipos ágiles Resultados

6.CONSIDERACIONES ORGANIZATIVAS PARA EL PROYECTO AGILIDAD 6.1 Gestión del cambio organizativo 6.1.1 Controladores para la gestión del cambio 6.1.2 Preparación para el cambio Cambio 6.2 Cultura Organizacional 6.2.1 Creando un Ambiente de Seguridad 6.2.2 Evaluando Cultura 6.3 Contratación y Contratos 6.4 Negocios Prácticas 6.5 Coordinación y dependencias de Multiteam (Escalado) 6.5.1 Frameworks 6.5.2 Consideraciones 6.6 Agile y la Oficina de Gestión de Proyectos (PMO) 6.6.1 Una PMO ágil es impulsada por el valor 6.6.2 Una PMO ágil es Orientada a la invitación

4

6.6.3 Una PMO ágil es multidisciplinaria 6.7 Estructura organizativa 6.8 Evolución de la organización

7.

UNA LLAMADA A

LA ACCIÓN ANEXO A1 GUÍA PMBOK® CARTOGRAFÍA ANEXO A2 AGILE MANIFIESTO CARTOGRAFÍA ANEXO A3 VISIÓN GENERAL DE AGILE Y LEAN MARCOS APÉNDICE X1 COLABORADORES Y REVISORES APÉNDICE X2 ATRIBUTOS QUE INFLUYEN EN LA ADAPTACIÓN APÉNDICE X3 AGILE FILTRO CONVENIENCIA HERRAMIENTAS REFERENCIAS BIBLIOGRAFÍA GLOSARIO

5

LISTA DE TABLAS Y FIGURAS Figura 4-14Los cuatro valores del Agile Manifiesto Figura 4-14Los Doce Principios Detrás del Ágil Manifiesto

La relación entre el manifiesto ágil

Figura 2-3. Valores,

Principios y prácticas comunes Figura 4-14Agile es un término

general para muchos Enfoques

Figura 4-14Modelo de Incertidumbre y Complejidad Inspirado por el Stacey Complejidad Modelo Figura 4-14El continuo de Vida Ciclos Figura 32.

Vida Predictiva

Ciclo Figura 4-14Vida Iterativa Ciclo

Figura 4-14Un ciclo de vida de Variedad variable Incrementos

Figura 3-5.

Vida Ágil

Basada en Iteración y basada en Flujo Ciclos Figura 4-14Desarrollo ágil Fol contraída por

una predictivo Rol

fuera Figura 4-14Un conjunto ágil y predictivo Enfoque Usado Simultaneamente 6

Figura 4-14Un enfoque principalmente predictivo con Ágil Componentes Figura 3-9.

Un enfoque muy

ágil con un Profético Componente Figura 51.

Burndown Chart para la historia restante

Puntos Figura 4-14Gráfico de quemado para mostrar la historia Puntos Terminado Figura 53.

Ejemplo de un Kanban Tablero

Figura 4-14Característica Gráfico Figura 4-14Producto Backlog Burnup Gráfico

7

Figura 4-14Valor ganado en un ágil Contexto Figura 4-14Diagrama de flujo acumulativo de Terminado

Caracteristicas

Figura 6-1.

La relación entre

la gestión del cambio y Ágil E n f o q u e s Figura 4-14Ejemplo de evaluación Organizativo Cultura Figura 63.

Inicial acumulado clasificado

para Cambios Figura 4-14Uso de Backlogs y Kanban Boards para organizar y Pista Cambio Trabajo Figura A-4.Enfoques ágiles trazados por amplitud y Detalle

Figura A-4.Junta de Kanban que demuestre límites de trabajo en progreso , y un Sistema Pul para optimizar el flujo de Trabajo Figura A-4.La familia de cristal de Métodos

Figura A-4.Proyecto de desarrollo impulsado por características Vida Ciclo Figura A3-5.

Enfoque DSDM para

Impulsado por Restricciones Agilidad 8

Figura A-4.Representantes de los equipos de Scrum que participan en Llamada de socorro equipos Figura X31.

Modelo para la idoneidad de Agile Enfoque

Figura X3-2.

Buy-In

a Enfoque Evaluación Figura X33.

Confianza en el

equipo Evaluación Figura X3-4.

Evaluación de los

Poderes de Toma de Decisiones de Equipo Figura X3-5.

Tamaño del equipo

Evaluación Figura X3-6.

Nivel de experiencia Evaluación

Figura X3-7.

Evaluación para el

acceso a el Cliente / Negocio Figura X38.

Probabilidad de cambio

Evaluación Figura X3-9.

Evaluación de la

criticidad del producto o Servicio Figura X3-10.

Entrega Incremental

Evaluación Figura X311.

Evaluación de

idoneidad Radar Gráfico 9

Figura X3-12.

Tienda

de Drogas Proyecto Figura X3-13.

Militar

Mensajería Ejemplo Mesa 11.

Dentro del alcance

y fuera del ámbito Artículos TablaCaracterísticas de cuatro categorías de ciclos de vida

10

TablaOpciones de sastrería para Mejorar Ajuste Mesa 41.

Atributos de éxito Ágil

Equipos Mesa 4-2.

Equipo

ágil Roles TablaPuntos

de Agile Pain y solución de problemas Posibilidades Tabla 4AProject Management Process Group y Conocimiento Zona Cartografía Tabla 4AAplicación de Agile en

la guía PMBOK®

Conocimiento Áreas Mesa A2-1. Valores del manifiesto ágil cubiertos en el Ágil Práctica Guía Mesa A2Guía práctica Agile Mapeo de principios detrás de 2. la Ágil M a n i f i e s t o Tabla 4AScrum Eventos y Artefactos Tabla 4ALas prácticas

de eXtreme Programación

11

Tabla 4ALa definición de los principios y propiedades de la Kanban Método Mesa A3-4.

Los valores

centrales y las propiedades comunes de Cristal Mesa A35.

Los elementos clave de la Proceso Unificado

Agile Tabla 4AComparación de LeSS y Melé Mesa X21.

Sastrería

Lineamientos

12

1 INTRODUCCIÓN ¡Bienvenido a la Guía de práctica ágil! Esta guía fue desarrollada como un esfuerzo de colaboración por el Project Management Institute (PMI) y Ágil Alliance®. Los miembros del equipo central de redacción que desarrollaron esta guía de práctica incluyeron voluntarios de ambas organizaciones, aprovechando la experiencia en la materia de una amplia gama de profesionales actuales y líderes de una amplia gama de antecedentes, creencias y culturas. Esta guía práctica ofrece un camino de prácticas dirigida a los líderes de proyecto y miembros del equipo de adaptación a un enfoque ágil en la planificación y ejecución de proyectos. Mientras que nuestro equipo de redacción central reconoce que hay apoyo incondicional al utilizar enfoques predictivos y a la inversa, la pasión en torno a cambiar hacia una mentalidad, valores y principios ágiles, esta guía práctica cubre un enfoque práctico para la agilidad del proyecto. Esta guía práctica representa un puente para comprender la ruta desde un enfoque predictivo a un enfoque ágil. De hecho, hay actividades similares entre los dos, como la planificación, que se manejan de forma diferente, pero ocurren en ambos ambientes. Nuestro equipo central de redacción utilizó una mentalidad ágil para colaborar y gestionar el desarrollo de esta primera edición de la guía de práctica. Así como la tecnología y los cambios culturales, futuras actualizaciones y refinamientos a la guía práctica reflejaran enfoques actuales. Nuestro equipo central adoptó un estilo de escritura más informal y relajado para esta guía práctica que es típico de los estándares del PMI. La guía incorpora nuevos elementos, tales como puntas, barras laterales, y estudios de casos para ilustrar mejor los puntos y conceptos clave. Nuestro equipo tiene la intención de realizar estos cambios para que esta guía de práctica sea más legible y fácil de usar. Esta guía de práctica va más allá de abordar el uso de ágil en la industria de desarrollo de software de computadora, porque lo ágil se ha expandido a entornos de desarrollo que no son de software. La industria manufacturera, la educación, la salud y otras industrias se están volviendo ágiles en diversos grados y este uso más allá del software está dentro del alcance de esta guía práctica.

13

APRENDIZAJE BASADO EN LO ÁGIL La educación es un terreno primordial y fértil para expandir las prácticas ágiles más allá del desarrollo de software. Los maestros de escuelas intermedias, escuelas secundarias y universidades de todo el mundo están empezando a usar lo “ágil” para crear una cultura de aprendizaje. Técnicas ágiles se utilizan para proporcionar enfoque en dar prioridad a las prioridades que compiten. Interacción face-to-face, aprendizaje significativo, los equipos de auto-organización, e incremental y/o de aprendizaje iterativo que explotar la imaginación son todos los principios ágiles que pueden cambiar la forma de pensar en el aula y avanzar en los objetivos educativos (Briggs, 2014).* Briggs, Sara. “Aprendizaje basado en lo ágil: ¿Qué es y cómo puede cambiar la educación?" Opencolleges.edu.au 22 de febrero de 2014, recuperado de http://www.opencolleges.edu.au/informed/features/agile-based-learning-what-is-it-and-how-can- it-changeeducation /

Entonces, ¿por qué una guía de práctica ágil y por qué ahora? Los equipos de proyecto han utilizado técnicas y enfoques ágiles de diversas formas durante al menos varias décadas. El Manifiesto Ágil [1]1 expresa los valores y principios de ágil a medida que el uso de ágil ganó un impulso sustancial (ver Sección 2.1). Hoy en día, los líderes y los equipos de proyecto se encuentran en un entorno perturbado por exponencial avances en la tecnología y demandas de los clientes para una entrega de valor más inmediata. Las técnicas y los enfoques ágiles gestionan eficazmente las nuevas tecnologías. Además, el primer principio de ágil coloca la satisfacción del cliente como la más alta prioridad y es clave en la entrega de productos y servicios que deleitan a los clientes (ver Sección 2.1). Bucles de retroalimentación rápidos y transparentes de los clientes están disponibles con el uso generalizado de las redes sociales. Por lo tanto, con el fin de seguir siendo competitivos y relevantes, las organizaciones ya no pueden estar enfocados internamente sino que deben centrarse exteriormente hacia la experiencia del cliente. Las nuevas tecnologías están cambiando rápidamente el campo de juego al disminuir las barreras de entrada. Las organizaciones más maduras son cada vez más propensas a ser muy complejas y potencialmente lentas para innovar, y están rezagadas en la entrega de nuevas soluciones a sus clientes. Estas organizaciones se encuentran compitiendo con organizaciones más pequeñas y nuevas empresas que pueden producir rápidamente productos que se adaptan a las necesidades de los clientes. Esta velocidad de cambio continuará impulsando a las grandes organizaciones a adoptar una mentalidad ágil para seguir siendo competitivas y mantener su participación de mercado actual. LAS NUEVAS TECNOLOGÍAS La nuevas tecnologías están especialmente habilitada por la transición a la Cloud Computing (computación en la nube). Las empresas de todo el mundo están aprovechando este modelo para un acceso rápido y barato a los recursos informáticos y para poder entrar en los mercados tradicionales. Cloud Computing requiere un pago por adelantado reducido, pero se paga con el tiempo a través de un servicio de suscripción, basada en un modelo de pay-as-you-go o pay-what.you.use. Las aplicaciones, la infraestructura y las plataformas actualizadas se lanzan a la nube de forma iterativa e incremental, al ritmo de las mejoras en la tecnología y la evolución de la demanda del cliente.

14

La Guía Práctica ágil se centra en proyectos y direcciones de selección de ciclo de vida del proyecto, la implementando ágil, y de consideraciones organizacionales para proyectos ágiles. La gestión del cambio organizacional (OCM) es esencial para implementar o transformar las prácticas , pero dado que OCM es una disciplina en sí misma, está fuera del alcance de esta guía de práctica .Aquellos que buscan orientación en OCM pueden referirse a Gestionar el cambio en las organizaciones: una guía de práctica [2] . Los artículos adicionales que están dentro del alcance y fuera del alcance de esta guía de práctica se enumeran en la Tabla 1-1 . Tabla 1-1 Artículos dentro y fuera del alcance

Dentro del alcance

Fuera del alcance

Implementación de enfoques ágiles a nivel Implementación ágil en toda la organización de proyecto o equipo. o creación programas agiles. Cobertura de los enfoques ágiles más Cobertura de enfoques de nicho, métodos populares, según se detalla en las encuestas específicos de la empresa o técnicas de ciclo de la industria. de vida incompletas. Factores adecuados a tener en cuenta al Recomendar o respaldar elegir un enfoque y/o práctica ágil enfoque/práctica particular

una

Cambio o modificación de los procesos de Asignación ágil a los procesos de la guía la Guía PMBOK® y/o Áreas de PMBOK® y áreas de conocimiento conocimiento Eliminación de la influencia de la industria del software en enfoques ágiles. (Tenga en cuenta que el software está incluido en esta Discusión sobre el uso de ágil más allá del guía de práctica, aunque el uso de ágil está desarrollo de software creciendo en muchas otras industrias más allá del software). Orientación, técnicas y enfoques a Instrucciones prescriptivas paso a paso considerar al implementar ágil en proyectos sobre cómo poner en práctica ágil en u organizaciones. proyectos u organizaciones Definiciones de términos generalmente Nuevos términos y/o definiciones aceptados

15

Esta guía práctica es para equipos de proyectos que se encuentran a si mismos en medio de terreno indeciso entre los enfoques predictivos y ágil, que están tratando de hacer frente a la rápida innovación y la complejidad, y que se dedican a la mejora del equipo. Esta guía práctica proporciona una guía útil para proyectos exitosos que entregan valor comercial para cumplir con las expectativas del cliente y necesariamente. Esta guía de práctica está organizada de la siguiente manera: Sección 2 Una introducción a Ágil - Esta sección incluye la mentalidad, los valores y los principios del Manifiesto Ágil .También cubre los conceptos de trabajo definible y de alta incertidumbre, y la correlación entre lean, el método Kanban y enfoques ágiles. Sección 3 Selección del ciclo de vida - Esta sección presenta los diferentes ciclos de vida que se analizan en esta guía de práctica. Esta sección también aborda los filtros de idoneidad, las pautas de adaptación y las combinaciones comunes de enfoques. Sección 4 Implementación de Ágil: Creación de un entorno ágil - Esta sección analiza los factores críticos a considerar al crear un entorno ágil, como el liderazgo servicial y la composición del equipo. Sección 5 La implementación ágil: Entregas en un Entorno Ágil - Esta incluye información sobre cómo organizar los equipos y los equipos de prácticas comunes pueden utilizar ágil para la entrega de valores en una base regular. Proporciona ejemplos de mediciones empíricas para los equipos y para informar estado. Sección 6 Consideraciones organizacionales para la agilidad del proyecto: Esta sección explora los factores organizacionales que afectan el uso de enfoques ágiles, como la cultura, la preparación, las prácticas comerciales y el papel de una PMO. Sección 7 Una llamada a la acción – Una llamada a la acción para pedir aportes para la mejora continua de esta guía práctica. Los anexos, apéndices, referencias, bibliografía y glosario proporcionan información útil adicional así como definiciones:  ANEXOS: Contiene información obligatoria que es demasiado extensa para incluirla en el cuerpo principal de la guía de práctica.  APÉNDICES: Contiene información no obligatoria que complementa el cuerpo principal de esta guía de práctica.  Referencias: Identifique dónde ubicar los estándares y otras publicaciones que se citan en esta guía de práctica.  Bibliografía: Enumera publicaciones adicionales por sección que brindan información detallada sobre los temas tratados en esta guía de práctica.  Glosario: Presenta una lista de términos y sus respectivas definiciones que se utilizan en esta guía de práctica. Los números entre paréntesis hacen referencia a la lista de referencias al final de esta guía práctica.

16

2 UNA INTRODUCCIÓN A ÁGIL 2.1 TRABAJO DEFINIBLE VS TRABAJO DE ALTA INCERTIDUMBRE El trabajo del proyecto abarca desde el trabajo definible hasta el trabajo de alta incertidumbre. Los proyectos de trabajo definibles se caracterizan por procedimientos claros que han demostrado ser exitosos en proyectos similares en el pasado. La producción de un automóvil, artefacto eléctrico u hogar una vez que el diseño está completo son ejemplos de trabajo definible. El dominio de producción y los procesos involucrados son generalmente bien entendidos y hay típicamente niveles bajos de incertidumbre en la ejecución y riesgo. Nuevos diseños, la resolución de problemas y el trabajo no hecho antes son exploratorios. Requiere expertos en la materia para colaborar y resolver problemas para crear una solución. Entre los ejemplos de personas que se enfrentan a trabajos de gran incertidumbre se incluyen ingenieros de sistemas de software, diseñadores de productos, doctores, docentes, abogados y muchos ingenieros que resuelven problemas. A medida que se automatiza el trabajo más definible, los equipos de proyecto están emprendiendo proyectos de trabajo de mayor incertidumbre que requieren las técnicas descritas en esta guía de práctica. Los proyectos de alta incertidumbre tienen altas tasas de cambio, complejidad y riesgo. Estas características pueden presentar problemas para los enfoques predictivos tradicionales cuyo objetivo es determinar la mayor parte de los requisitos iniciales y cambios de control a través de un proceso de solicitud de cambio. En cambio, se crearon enfoques ágiles para explorar la viabilidad en ciclos cortos y adaptarse rápidamente en función de la evaluación y la retroalimentación.

2.2 EL MANIFIESTO Y PENSAMIENTO ÁGIL Los líderes del pensamiento en la industria del software formalizaron el movimiento ágil en 2001 con la publicación del Manifiesto para el Desarrollo de Software Ágil (ver Figura 2-1 ).

17

Estamos revelando mejores maneras de desarrollar software haciendo eso y ayudando a otros a hacerlo. A través de este trabajo nosotros hemos apreciado: Individuos e interacciones sobre procesos y herramientas Software Trabajando sobre Documentación comprensiva Colaboración del cliente sobre Negociación contractual Respuesta al cambio sobre Seguimiento de un plan Esto es, mientras existe valor en los ítems de la derecha, apreciamos más los ítems de la izquierda. © 2001, Los autores del manifiesto ágil

Figura 2-1 Los cuatro valores del manifiesto ágil

Doce claros principios fluyeron de estos valores como se muestra en Figura 2-2 : 1. 2.

3. 4. 5.

6. 7. 8.

9. 10. 11. 12.

Nuestra más alta prioridad es la satisfacción del cliente, a través de una temprana y continua entra de valores del software. Los cambios en los requerimientos son bienvenido, aún tarde en el desarrollo. Los procesos ágiles implementa cambio para la ventaja competitiva del cliente. Entrega frecuente del software trabajando, desde un par de semanas hasta un par de meses, con una preferencia en una escala corta de tiempo. Las personas del negocio y los desarrolladores deben trabajan juntos diariamente a lo largo del proyecto. Construcción de proyectos alrededor de individuos motivados. Denle el entorno y soporte que ellos necesitan, y confié que obtendrá el trabajo realizado. El método más eficiente y efectivo de transmitir información desde y hacia el equipo de desarrollo son conversaciones face-to-face. El software trabajando en la medida principal de progreso. Los procesos agiles promocionan un desarrollo sustentable. Los sponsors, desarrolladores, y usuarios deberían poder mantener un ritmo constante indefinidamente. Atención continua a la excelencia técnica y el buen diseño acentúa la agilidad Simplicidad – El arte de maximizar el monto de trabajo no hecho – es esencial. Las mejores arquitecturas, requisitos, y diseños emergen desde los equipos de auto-organización En intervalos regulares, el equipo refleja en como volverse más efectivo, entonces afina y ajusta su comportamiento como consecuencia. Figura 2-2 Los doce principios detrás del manifiesto ágil

18

Aunque originados en la industria del software, estos principios se han extendido a muchas otras industrias. Esta incorporación de mentalidad, los valores y los principios definen lo que constituye un enfoque ágil. Los diversos enfoques ágiles actualmente en uso comparten raíces comunes con la mentalidad, el valor y los principios ágiles .Esta relación se muestra en la Figura 2-3.

Ágil es una mentalidad definida por valores, guiado por principio, y es manifestado a través diferentes prácticas. Los practicantes agiles seleccionan sus prácticas basados en sus necesidades

Figura 2-3 La relación entre los valores, principios y prácticas comunes del Manifiesto Ágil

Como se muestra en la Figura 2-3 , el modelo, inspirado en Ahmed Sidky, articula ágil como una mentalidad definida por los valores del Manifiesto Ágil, guiada por los principios del Manifiesto Ágil y habilitada por diversas prácticas. Vale la pena señalar que, si bien el término “ágil” se popularizó después del Manifiesto, los enfoques y técnicas utilizados por los equipos de proyecto existentes antes del manifiesto ágil por muchos años y, en algunos casos, décadas. Los enfoques ágiles y los métodos ágiles son términos generales que cubren una variedad de marcos y métodos. Figura 2-4 coloca ágil en su contexto y lo visualiza como un término general, refiriéndose a cualquier tipo de enfoque, técnica, marco, método o práctica que cumpla con los valores y principios del manifiesto ágil. Figura 2-4 también muestra Agile y el Método Kanban como subconjuntos de Lean. Esto se debe a que se nombran los casos de pensamiento que comparten conceptos Lean tales como: “centrarse en el valor”, “pequeños tamaños de lote” y “eliminación de residuos."

¿Es ágil un enfoque, un método, una práctica, una técnica o un marco? Cualquiera o todas estos términos pueden aplicarse dependiendo de la situación. Esta guía de práctica utiliza el término "enfoque" a menos que uno de los otros términos sea obviamente más correcto.

19

Figura 2-4 Ágil es un término en blanco para muchos enfoques

En general, existen dos estrategias para cumplir con los valores y principios ágiles .La primera consiste en adoptar un enfoque ágil formal, diseñado y probado para lograr los resultados deseados intencionadamente. Luego tomarse el tiempo para aprender y comprender los enfoques ágiles antes de cambiarlos o adaptarlos .Una adaptación prematura e irregular puede reducir al mínimo los efectos del enfoque y por lo tanto limitar los beneficios. (Ver el Apéndice X2 para la Consideraciones para adaptación). La segunda estrategia consiste en aplicar cambios a las prácticas del proyecto de manera que se adapte al contexto del proyecto para lograr avances en un valor fundamental o principio. Use calendarios para crear funciones o técnicas específicas para refinar características de forma iterativa. Considere dividir un proyecto grande en varias liberaciones, si funciona para el contexto del proyecto específico. Implementar cambios que ayudarán al éxito del proyecto - los cambios no tienen que ser parte de las prácticas formales de la organización. El objetivo final no es ser ágil para su propio bien, sino para entregar un flujo continuo de valor a los clientes y lograr mejores resultados de negocio.

2.3 LEAN Y EL MÉTODO KANBAN Una manera de pensar acerca de la relación entre Lean, ágil, y el método Kanban es considerar ágil y el método Kanban como descendientes de pensamiento Lean. En otras palabras, el pensamiento Lean es un superconjunto, que comparte atributos con ágil y Kanban. 20

Este patrimonio compartido es muy similar y se enfoca en entregar valor, respeto por personas, minimizando el desperdicio, siendo transparentes, adaptándose al cambio y mejorando continuamente. Los equipos de proyecto a veces resulta útil mezclar diferentes métodos-lo que funcione para la organización o equipo es lo que debe hacerse independientemente de su origen. El objetivo es el mejor resultado, independientemente del método utilizado. El Método Kanban está inspirado en el sistema original de fabricación ajustada y se usa específicamente para el trabajo de conocimiento .Surgió a mediados de los años 2000 como una alternativa a los métodos ágiles que prevalecían en el momento. El Método Kanban es menos prescriptivo que algunos enfoques ágiles y menos disruptivo, ya que es el enfoque original de "comienza donde estás".Los equipos del proyecto pueden comenzar a aplicar el Método Kanban con relativa facilidad y avanzar hacia otros enfoques ágiles si eso es lo que consideran necesario o apropiado.Para obtener más detalles sobre el Método Kanban , consulte el Anexo A3 sobre Descripción general de los marcos ágiles y lean .

CAJA

2.4 INCERTIDUMBRE, RIESGO Y CICLO DE VIDA SELECCIÓN Algunos proyectos tienen una considerable incertidumbre sobre los requisitos del proyecto y cómo cumplir esos requisitos utilizando el conocimiento y la tecnología actuales .Estas incertidumbres pueden contribuir a altas tasas de cambio y complejidad del proyecto .Estas características se ilustran en la Figura 2-5 . A medida que aumenta la incertidumbre del proyecto, también aumenta el riesgo de retrabajo y la necesidad de utilizar un enfoque diferente. Para mitigar el impacto de estos riesgos, los equipos seleccionan ciclos de vida que les permiten abordar proyectos con grandes cantidades de incertidumbre a través de pequeños incrementos de trabajo. 21

Los equipos pueden verificar su trabajo cuando usan pequeños incrementos y pueden cambiar lo que hacen a continuación. Cuando los equipos entregan pequeños incrementos, son más capaces de comprender los verdaderos requisitos del cliente de forma más rápida y precisa que con una especificación estática escrita.

22

Los equipos pueden planificar y gestionar proyectos con requisitos claros y estables y desafíos técnicos claros con poca dificultad.Sin embargo, a medida que aumenta la incertidumbre en el proyecto, la probabilidad de cambios, trabajo desperdiciado y repeticiones también aumenta, lo cual es costoso y lleva mucho tiempo . Algunos equipos han evolucionado los ciclos de vida del proyecto para usar enfoques iterativos e incrementales .Muchos equipos descubren que cuando exploran los requisitos iterativamente y entregan más a menudo de forma incremental, los equipos se adaptan a los cambios más fácilmente.Estos enfoques iterativos e incrementales reducen el desperdicio y la repetición porque los equipos obtienen retroalimentación.Estos enfoques usan: 23

Bucles de realimentación muy cortos, adaptación frecuente del proceso, nueva priorización,

Planes actualizados regularmente y entrega frecuente. Propina

24

sencillo: mover la autopista elevada bajo tierra.Hubo un alto acuerdo sobre los requisitos (ver el eje Y en la Figura 2-5 ).Hubo poca incertidumbre sobre cómo continuaría el proyecto hasta que el proyecto comenzara.Y, como es el caso de muchos proyectos grandes, el proyecto encontró sorpresas a lo largo del camino. Cuando un equipo trabaja en un proyecto donde hay pocas oportunidades para entregas provisionales o pocas oportunidades para crear prototipos, es probable que el equipo utilice un ciclo de vida específico para administrarlo.El equipo puede adaptarse a lo que descubre, pero no podrá usar enfoques ágiles para administrar el descubrimiento iterativo de requisitos o entregables incrementales para la retroalimentación. El proyecto Big Dig no fue simple de ninguna manera. Sin embargo, muchos proyectos que se inician en la parte inferior izquierda de la complejidad del modelo Stacey no tienen medios reales de pasar a otros enfoques.Evaluar el proyecto, tanto en los requisitos como en los medios de entrega, para determinar el mejor enfoque para el ciclo de vida del proyecto. Estos enfoques iterativos, incrementales y ágiles funcionan bien para proyectos que involucran herramientas, técnicas, materiales o dominios 25

de aplicación nuevos o novedosos .(Consulte la Sección 3 en la selección del ciclo de vida ).También funcionan bien para los proyectos ese: Reque rir investi gación y desarr ollo; Tener altas tasas de cambi o; Tener requerimientos, incertidumbres o riesgos poco claros o desconocidos ; o Tiene un objetivo final que es difícil de describir. Al construir un pequeño incremento y luego probarlo y revisarlo, el equipo puede explorar la incertidumbre a bajo costo en un corto período de tiempo, reducir el riesgo y maximizar la entrega de valor comercial .Esta incertidumbre puede estar centrada sobre la idoneidad y requisitos (es el producto derecho ser Bui lt?); viabilidad técnica y rendimiento (este producto pueden ser construidos de esta manera?); o proceso y las personas (¿esto es una forma efectiva para que el equipo funcione?).Los 26

tres de estas especificaciones características del producto, la capacidad de producción, y el proceso de idoneidad-tienen típicamente elementos de alta incertidumbre. Sin embargo, los enfoques iterativos e incrementales tienen sus límites de aplicabilidad. Cuando tanto la incertidumbre de la tecnología como la incertidumbre de los requisitos son muy altas (la parte superior derecha de la Figura 2-5 ), el proyecto va más allá de lo complejo a lo caótico.Para que el proyecto sea confiablemente posible, necesita una de las variables (incertidumbre o desacuerdo) que debe contenerse.

27

3 CICLO VITAL SELECCIÓN Los proyectos vienen en muchas formas y hay una variedad de formas de llevarlas a cabo .Equipos de proyecto necesita tener conocimiento de las características y opciones disponibles para seleccionar el enfoque que tenga más probabilidades de ser exitoso para el situación. Esta guía de práctica se refiere a cuatro tipos de ciclos de vida, definidos como sigue: Ciclo de vida predictivoUn enfoque más tradicional, con la mayor parte de la planificación ocurriendo por adelantado, luego ejecutándose en un solo pase; un proceso secuencial. Ciclo de vida iterativoUn enfoque que permite la retroalimentación del trabajo no terminado para mejorar y modificar ese trabajo. Ciclo de vida incremental.Un enfoque que proporciona entregables terminados que el cliente puede usar de inmediato. Ciclo de vida ágilUn enfoque que es a la vez iterativo e incremental para refinar los elementos de trabajo y entregar frecuentemente.

28

¿QUÉ LLAMAR A LOS ENFOQUES QUE NO SON DE AGILE? No existe un solo término que se use universalmente para describir enfoques no ágiles .Inicialmente, la guía de práctica usó el término impulsado por el plan para describir el énfasis en un plan inicial y luego la ejecución de ese plan.Algunas personas prefieren los términos cascada o serie para describir este ciclo de vida.Al final, nos decidimos por el término predictivo ya que se utiliza en la Guía de los Fundamentos de la Dirección de Proyectos (Guía del PMBOK®) [3] y la extensión de software de la Guía PMBOK® Quinta edición [4] . Muchas organizaciones no experimentan ninguno de estos extremos y en su lugar ocupan un término medio.Eso es natural, pero todavía necesitan una manera de hablar de los dos extremos del espectro.Si es ágil en un extremo, que llamamos el otro extremo predictivo .

3.1 CARACTERÍSTICAS DE LA VIDA DEL PROYECTO CICLOS La Tabla 3-1 resume las características de las cuatro categorías de ciclo de vida cubiertas en esta guía de práctica.

29

Es importante tener en cuenta que todos los proyectos tienen estas características, ningún proyecto es completamente desprovisto de consideraciones en torno requisitos, entrega, cambio y objetivos.Las características inherentes de un proyecto determinan qué ciclo de vida es el más adecuado para ese proyecto. Otra forma de entender cómo varían los ciclos de la vida del proyecto es utilizando un continuo que va desde ciclos predictivos en un extremo hasta ciclos ágiles en el otro extremo, con ciclos iterativos o incrementales en el medio. La Figura X3-1 del Apéndice X3 de la Guía PMBOK® - Sexta Edición muestra el continuo como una línea plana.Este punto de vista hace hincapié en el cambio de características del proyecto de un extremo al otro.Otra forma de visualizar el continuo es con un cuadrado bidimensional , como se muestra en la Figura 3-1 .

30

Ningún ciclo de vida puede ser perfecto para todos los proyectos.En cambio, cada proyecto encuentra un lugar en el continuo que proporciona un equilibrio óptimo de características para su contexto.En específico, Ciclos de vida predictivos.Aproveche las cosas que son conocidas y comprobadas. Esta reducida incertidumbre y complejidad permite a los equipos segmentar el trabajo en una secuencia de agrupaciones predecibles. Ciclos de vida iterativos.Permita que los comentarios sobre el trabajo parcialmente completado o no terminado mejoren y modifiquen ese trabajo. Ciclos de vida incrementalesProporcionar entregables terminados que el cliente puede ser capaz de utilizar inmediatamente. 31

Ciclos de vida ágiles .Las reglas del juego tanto los aspectos de las características iterativo e incremental.Cuando los equipos usan enfoques ágiles, que iterar sobre el producto para crear entregables terminados.El equipo obtiene retroalimentación temprana y proporciona visibilidad del cliente, la confianza y el control del producto.Debido a que el equipo puede lanzar antes, el proyecto puede proporcionar un más temprano regreso en inversión porque el equipo entrega el más alto trabajo valioso primero.

LA PLANIFICACIÓN ESTÁ SIEMPRE ALLÍ Una cosa clave para recordar acerca de los ciclos de vida es que cada uno de ellos comparte el elemento de planificación. Lo que diferencia un ciclo de vida no es si la planificación se realiza, sino más bien cuánto se planifica y cuándo.

32

Al final de predicción del continuo, el plan impulsa el trabajo.En la medida de lo posible la planificación se realiza por adelantado.Los requisitos se identifican con el mayor detalle posible.El equipo estima que puedan ofrecer lo que los entregables y lleva a cabo actividades integrales de adquisición. En los enfoques iterativos, también se planifican prototipos y pruebas, pero los resultados están destinados a modificar los planes creados al principio. Las revisiones anteriores del trabajo no terminado ayudan a informar el trabajo futuro del proyecto. Mientras tanto, las iniciativas incrementales planean entregar subconjuntos sucesivos del proyecto general.Los equipos pueden planificar varias entregas sucesivas por adelantado o solo una a la vez. Las entregas informan el trabajo futuro del proyecto. Los proyectos ágiles también planean. La diferencia clave es que el equipo planifica y reemplaza a medida que aumenta la disponibilidad de información a partir de la revisión de entregas frecuentes.Independientemente del ciclo de vida del proyecto, el proyecto requiere planificación.

33

3.1.1 CARACTERÍSTICAS DE LA VIDA PREDICTIVA CICLOS Ciclos de vida predictivos esperan para tomar ventaja de una alta certeza en torno a los requisitos de firma, un establo equipo, y bajo riesgo.Como resultado, las actividades del proyecto a menudo se ejecutan de una manera en serie, como se muestra en la Figura 3-2. Para lograr este enfoque, el equipo requiere de planes detallados para saber qué y cómo entregar.Estos proyectos tienen éxito cuando otros cambios potenciales están restringidos (por ejemplo, cambios en los requisitos , los miembros del equipo del proyecto cambian lo que el equipo ofrece).Los jefes de equipo tienen como objetivo minimizar el cambio para el proyecto predictivo. Cuando el equipo crea requisitos detallados y planes al comienzo del proyecto, se pueden articular las restricciones.Posteriormente, el equipo puede utilizar esas limitaciones para gestionar el riesgo y el costo.A medida que el equipo avanza en el plan detallado, supervisa y controla los cambios que podrían afectar el alcance, el cronograma o el presupuesto. Al hacer hincapié en una secuencia departamental eficiente, serializada de trabajo, proyectos de predicción no suelen proporcionar un valor comercial hasta el final del proyecto.Si el proyecto predictivo encuentra cambios o desacuerdos con los requisitos, o si la solución tecnológica ya no es sencillo, el proyecto predictivo incurrirá imprevista costos.

34

3.1.2 CARACTERÍSTICAS DE LA VIDA ITERATIVA CICLOS Los ciclos de vida iterativos mejoran el producto o el resultado a través de sucesivos prototipos o pruebas de concepto.Cada nuevo prototipo genera nuevos comentarios de las partes interesadas y conocimientos del equipo .Luego, el equipo incorpora la nueva información al repetir una o más actividades del proyecto en el siguiente ciclo.Los equipos pueden utilizar timeboxing en una iteración dada por algunas semanas, recoger opiniones, y luego volver a trabajar la actividad sobre la base de esos puntos de vista.De esta forma, las iteraciones ayudan a identificar y reducir la incertidumbre en el proyecto. Los proyectos se benefician de ciclos de vida iterativos cuando la complejidad es alta, cuando el proyecto incurre cambios frecuentes, o cuando el alcance está sujeto a puntos de vista diferentes de las partes interesadas sobre el producto final deseado .Ciclos de vida iterativos pueden tomar más tiempo, ya que están optimizados para el aprendizaje más que la velocidad de entrega. La Figura 3-3 ilustra algunos elementos de un ciclo de vida iterativo del proyecto para la entrega de un solo producto.

35

¿Alguna vez ha estado involucrado en un proyecto donde los requisitos parecían cambiar diariamente y pensaron: “Vamos a conocer los requisitos cuando entregamos un prototipo que se aprueba el negocio.”Si es así, este era un proyecto donde los enfoques ágiles podrían haber ayudado.Un prototipo fomenta la retroalimentación y una mejor comprensión de los requisitos que se pueden incorporar en cada entregable.

3.1.3 CARACTERÍSTICAS DE LA VIDA INCREMENTAL CICLOS Algunos proyectos para optimizar la velocidad de entrega.Muchas empresas e iniciativas no pueden darse el lujo de esperar a que se complete todo; en estos casos, los clientes están dispuestos a recibir un subconjunto de la solución general .Esta entrega frecuente de entregables más pequeños se denomina un ciclo de vida incremental (ver figura 3-4 ).

36

Sugerencia

Los ciclos de vida incrementales optimizan el trabajo para ofrecer valor a los patrocinadores o clientes con más frecuencia que un solo producto final .Grupos del Plan de entregas iniciales antes de comenzar su trabajo, y comienzan a trabajar en ese primer parto tan pronto como sea posible.Algunos proyectos ágiles ofrecen valor a los pocos días de la iniciación del proyecto .Otros pueden llevar más tiempo, desde 1 semana hasta varios semanas. A medida que el proyecto continúa, el equipo puede desviarse de la visión original.El equipo puede manejar las desviaciones, porque el equipo entrega valor antes.El grado de cambio y la variación es menos importante que asegurar que los clientes reciben el valor antes de lo que al final del proyecto.

37

La integridad y la entrega son subjetivas.El equipo puede necesitar información sobre un prototipo y luego puede optar por entregar un producto mínimo viable (MVP) a un subconjunto de clientes.Los clientes retroalimentación ayuda al equipo a aprender lo que necesitan para proporcionar el suministro subsiguiente de la función de acabado final. Los equipos ágiles , como un diferenciador clave , entregan valor comercial a menudo.A medida que el producto se suma un conjunto más amplio de características y una gama más amplia de consumidores, decimos que se entrega de forma incremental.

Proporcionar un cliente una única característica o una pieza terminada de trabajo es un ejemplo de la enfoque incremental. Por ejemplo, los constructores pueden querer mostrar una habitación acabada o piso de un edificio antes de que continúen con el resto del edificio.En ese caso, pueden completar un piso con accesorios, pintura y todo lo demás destinado al piso terminado antes de pasar al siguiente piso.El cliente es capaz de ver y aprobar el estilo, color y otros detalles, lo que permite que se hagan ajustes antes de promover inversiones de hora y dinero son hecho. Esta reduce potencial rehacer y / o

38

insatisfacción del cliente

3.1.4 CARACTERÍSTICAS DE LA VIDA ÁGIL CICLOS En un entorno ágil, el equipo espera que los requisitos cambien. Los enfoques iterativos e incrementales proporcionan retroalimentación para planificar mejor la siguiente parte del proyecto. Sin embargo, en proyectos ágiles, la entrega incremental revela necesidades ocultas o incomprendidas .Figura 3-5 ilustra dos maneras posibles de lograr una entrega incremental para que el proyecto se alinee con las necesidades del cliente y pueda adaptarse según sea necesario.

39

En agilidad basada en iteraciones, el equipo trabaja en iteraciones (cajas de tiempo de igual duración) para entregar funciones completadas.El equipo trabaja en la característica más importante, colaborando en equipo para terminarla.Luego, el equipo trabaja en la siguiente característica más importante y la finaliza .El equipo puede decidir trabajar en algunas de sus funciones a la vez, pero el equipo no abordar todo el trabajo para la iteración a la vez (es decir, no se refiere a todos los requisitos, seguida de todos los análisis, etc.) . En basado en el flujo ágil, el equipo se extrae características de la cartera de pedidos en base a su capacidad para empezar a trabajar en lugar de en un programa basado en la iteración.El equipo define su flujo de trabajo con columnas en un tablero de tareas y administra el trabajo en progreso para cada columna.Cada característica puede tardar una cantidad de tiempo diferente para terminar.Los equipos mantienen los tamaños del trabajo en progreso pequeños para identificar mejor los problemas de manera temprana y reducir el reproceso en caso de que se requieran cambios .Sin iteraciones para definir puntos de planificación y revisión , el equipo

40

y las partes interesadas comerciales determinan el cronograma más apropiado para la planificación, revisiones de productos , y retrospectivas Ciclos de vida ágiles son aquellas que cumplen los principios del manifiesto ágil.En particular, la satisfacción del cliente aumenta con la entrega temprana y continua de productos valiosos.Además, una entrega incremental que es funcional y proporciona valor es la medida principal del progreso.Ciclos de vida ágiles combinan ambos métodos iterativos e incrementales con el fin de adaptarse a los altos grados de cambio y entregar valor del proyecto más a menudo.

3.1.5 IDONEIDAD AGILE FILTROS Existen varios modelos de evaluación para ayudar a determinar el ajuste probable o lagunas para el uso de enfoques ágiles.Estos modelos evalúan los factores de proyecto y organización asociados con la adopción y la idoneidad y luego proporcionan puntajes que indican la alineación o áreas de riesgo potencial .El Apéndice X3 proporciona una síntesis de los modelos de evaluación popular para su uso como un filtro de idoneidad ágil .

EJEMPLO DE UN PROYECTO DE CICLO DE VIDA HÍBRIDO 41

Una compañía farmacéutica que tenía una (FDA) de proceso de aprobación requiere mucho tiempo EE.UU. Food and Drug Administration etiquetado en el extremo de su proceso de desarrollo y de todo su ciclo de vida se parecía a la Figura 3-6 .Mientras que los equipos de proyecto realizaron ensayos de medicamentos de una manera ágil, tenían que presentar los medicamentos a un grupo externo para llevar a cabo el proceso de aprobación de la FDA.Un consultor ayudó a integrar la porción del proceso de aprobación de la FDA en el proceso de desarrollo ágil para crear un enfoque híbrido más racionalizado . La versión corta de la historia es que debido a que se requiere la aprobación de la FDA para ser completado al final del proceso de desarrollo o se repite después de cualquier cambio (esto incluye incluso después de que el cambio más leve), el proceso tuvo que permanecer en el extremo como separada fase.La integración utilizando el proceso iterativo no tuvo éxito.Sin embargo, el consultor creó algunas guías útiles de inicio rápido y protocolos de prueba que acortaron la aprobación final de la FDA. proceso.

3.1.6 CARACTERÍSTICAS DE LA VIDA HÍBRIDA CICLOS No es necesario el uso de un enfoque único para un proyecto completo.Los proyectos a menudo se combinan elementos de diferentes ciclos de vida con el fin de lograr ciertos objetivos.Una combinación de enfoques predictivos, iterativos, incrementales y / o ágiles es un híbrido enfoque. La Figura 3-6 muestra los enfoques básicos y puros de los tipos de proyectos que se combinan para formar un modelo híbrido .Los primeros procesos utilizan un ciclo de vida de desarrollo ágil, que es seguido por una fase de despliegue predictivo.Este enfoque se puede utilizar cuando hay incertidumbre, la complejidad y el riesgo en la parte de desarrollo del proyecto que se beneficiaría de un enfoque ágil, seguida de una fase de lanzamiento definida, repetible que es apropiado para llevar a cabo de una manera predictiva, tal vez por una equipo diferenteUn ejemplo de este 42

enfoque es el desarrollo de un nuevo producto de alta tecnología seguido del despliegue y capacitación de miles de usuarios.

43

3.1.7 COMBINADO ÁGIL Y PREDICTIVO ENFOQUES Otro enfoque es utilizar una combinación de enfoques ágiles y predictivos a lo largo del ciclo de vida.

En la Figura 3-7 , se usa una combinación de enfoques tanto predictivos como ágiles en el mismo proyecto.Tal vez el equipo está pasando gradualmente a la agilidad y utilizando algunos enfoques, como iteraciones cortas, resúmenes diarios y retrospectivas, pero otros aspectos del proyecto como la estimación inicial, la asignación de trabajo y el seguimiento del progreso aún siguen los enfoques predictivos. El uso de enfoques tanto predictivos como ágiles es un escenario común. Sería engañoso llamar al enfoque ágil ya que claramente no incorpora completamente la mentalidad, los valores y los principios ágiles.Sin embargo, también sería inexacto llamarlo predictivo ya que es un enfoque híbrido.

3.1.8 ENFOQUE PREDOMINANTENCIALMENTE PREDICTIVO CON ALGUNOS COMPONENTES DE AGILE La Figura 3-8 muestra un pequeño elemento ágil dentro de un proyecto principalmente predictivo.En este caso, una parte del proyecto con la incertidumbre, la complejidad, o una oportunidad para la corrupción del 44

alcance se está abordando de una manera ágil, pero el resto del proyecto está a cargo utilizando enfoques predictivos.Un ejemplo de esto enfoque sería un Ingenieria firma ese es edificio un instalaciones con un nuevo componente.

Si bien la mayoría del proyecto puede ser rutinario y predecible, al igual que muchos otros proyectos de instalaciones que la organización ha emprendido anteriormente, este proyecto incorpora un nuevo material para techos.El contratista puede planear algunos ensayos de instalación a pequeña escala en primer lugar para determinar el mejor método de instalación y para descubrir problemas temprano, mientras haya suficiente tiempo para resolverlos y mejorar los procesos de forma incremental mediante la experimentación y la adaptación.

45

3.1.9 UN ENFOQUE GRANDE AGILE CON UN PREDICTIVO COMPONENTE La Figura 3-9 muestra un enfoque en gran parte ágil con un componente predictivo .Este enfoque se puede usar cuando un elemento en particular no es negociable o no es ejecutable usando un enfoque ágil.Ejemplos incluyen la integración de un componente externo desarrollado por un proveedor diferente que no pueden o no quieren pareja de una manera colaborativa o incremental.Se requiere una sola integración después de que el componente es entregado.

Un departamento del gobierno tenía un proyecto de desarrollo de aplicaciones de seguro de crédito.El proyecto multianual consistió en reemplazar su viejo sistema de suscripción con una nueva interfaz de 46

usuario más receptiva e integraciones de sistemas. La mayor parte del proyecto se llevó a cabo utilizando un enfoque ágil con aportes continuos del negocio. Los cálculos de tarificación adicional se transmiten de la Organización para la Cooperación y el Desarrollo Económico (OCDE) como una especificación de 200 páginas.Los pasos se explican muy claramente con pocas oportunidades de confusión (o confirmación resultado provisional por el negocio) y se codificaron por un equipo independiente que trabaja su camino a través de los pasos de cálculo.Los dos equipos colaboraron en las variables de entrada requeridas para el cálculo y la forma de consumir y mostrar los valores de salida , pero más allá de eso, el equipo de cálculo trabajó en gran medida predictivo. manera. Cuando parte del equipo de cálculo fue completa, las salidas de los cálculos de tarificación adicional se muestran en las pantallas y en los informes.Luego, los usuarios comerciales proporcionaron comentarios sobre la apariencia y el uso de la información.Los dos equipos corrieron concurrentemente, pero tenían poca necesidad de interacción.Tenerlos físicamente cerca uno del otro hizo más fácil de comprobar en el progreso del desarrollo, pero en gran medida Eran subproyectos separados.

3.1.10 CICLOS DE VIDA HÍBRIDOS SEGÚN SEA APROPIADO Los equipos de proyecto pueden diseñar un ciclo de vida híbrido basado en los riesgos del proyecto.Por ejemplo, un proyecto de construcción del campus puede tener varios edificios para mejorar y construir.Un enfoque gradual concentraría los recursos en completar algunos edificios antes que otros, acelerando el retorno de la inversión.Cada entrega individual puede ser suficientemente conocida para beneficiarse de un ciclo de vida predictivo para ese edificio solo. El objetivo de la gestión del proyecto es producir valor de negocio de la mejor manera posible, dado el entorno actual.No importa si es de esa

47

manera ágil o predictivo.La pregunta es: “¿Cómo podemos ser más exitoso?” ¿Se necesita retroalimentación ya que el equipo produce valor?Si es así, incrementos ayudarán.¿Es necesario

48

gestionar el riesgo a medida que se exploran las ideasSi es así, iteraciones o ágiles te ayudarán. Cuando la organización no puede ofrecer un valor intermedio , los enfoques ágiles pueden no ser útiles.Eso está bien: ágil por el bien de ágil no es el objetivo.El punto es seleccionar un ciclo de vida o una combinación de los ciclos de vida que trabajan para el proyecto, los riesgos, y la cultura. Agile se trata de la entrega basada en el cliente de forma frecuente .Esa entrega crea retroalimentación para el equipo.El equipo usa esa retroalimentación para planear y replanificar el próximo trozo de trabajo.

3.1.11 CICLOS DE VIDA HÍBRIDOS COMO TRANSICIÓN ESTRATEGIA Muchos equipos no pueden cambiar a formas ágiles de trabajar de la noche a la mañana. Las técnicas ágiles se ven y se sienten muy diferentes a las que están acostumbradas y han tenido éxito en un entorno predictivo. Mientras más grande sea la organización y más partes se muevan , más tiempo llevará la transición.Por esa razón, tiene sentido planear una transición gradual. Una transición gradual implica agregar más técnicas iterativas para mejorar el aprendizaje y la alineación entre los equipos y las partes interesadas. Más tarde, considere agregar más técnicas incrementales para acelerar el valor y el rendimiento de la inversión para los patrocinadores.Esta combinación de varios enfoques se considera un enfoque híbrido. Pruebe estas nuevas técnicas en un proyecto menos arriesgado con un grado de incertidumbre de medio a bajo .Luego, cuando la organización tenga éxito con un enfoque híbrido , pruebe proyectos más complejos que requieran que se agreguen más de esas técnicas .Esta es una forma de adaptar la transición híbrida progresiva a la situación de la organización y los riesgos específicos, y la disposición del equipo para adaptarse y aceptar los cambios.

49

3.2 MEZCLA AGILE ENFOQUES Los equipos ágiles rara vez limitan sus prácticas a un enfoque ágil.Cada contexto del proyecto tiene sus propias peculiaridades, como la variada mezcla de habilidades de los miembros del equipo y fondos; los diversos componentes del producto en fase de desarrollo; y la edad, la escala, criticidad, la complejidad y las restricciones regulatorias del entorno en el que el trabajo se lleva lugar. Los marcos ágiles no están personalizados para el equipo.El equipo puede necesitar prácticas a medida para ofrecer un valor sobre una base regular.A menudo, los equipos de practicar su propia mezcla especial de ágil, incluso si utilizan un marco determinado como punto de partida.

ENFOQUES DE MEZCLA Como un ejemplo de la adaptación de los marcos ágiles, una de las mezclas más comunes en uso generalizado implica un uso coordinado del marco Scrum, el Método Kanban, y los elementos del método extremo de programación (XP).Scrum proporciona orientación sobre el uso de una cartera de pedidos de productos , el propietario de un producto , scrum master y un equipo de desarrollo interfuncional, que incluye planificación de sprints , scrum diario , revisión de sprints y sesiones retrospectivas de sprints .Un tablero Kanban ayuda al equipo para mejorar aún más su eficacia mediante la visualización del flujo de trabajo, por lo que los impedimentos fácilmente visible, y que permite el flujo a ser gestionado mediante el ajuste de trabajo en los límites del proceso.Además, XP50

prácticas de ingeniería de inspiración, como el uso de tarjetas de historia, integración continua, refactorización, pruebas automatizadas y desarrollo basado en pruebas más aumentan la eficacia del equipo ágil.En resumen, la mezcla de prácticas de estas diversas fuentes produce un resultado sinérgico de mayor rendimiento que cada componente individual de forma aislada.

3.3 FACTORES DEL PROYECTO QUE INFLUYEN SASTRERÍA A veces, los atributos del proyecto requieren adaptar un enfoque para un mejor ajuste. Tabla 3-2 identifica algunos factores de proyecto y opciones de personalización para considerar. TablaOpciones de sastrería para mejorar el ajuste

Factor de proyecto

Patrón de demanda: constante o esporádico

Tasa de mejora del proceso requerida por el nivel de experiencia del equipo

Opciones de sastrería Muchos equipos encuentran que el uso de una cadencia (en la forma de una caja de tiempo regular) les ayuda demo, retrospectiva, y disfrutar de un nuevo trabajo.Además, algunos equipos necesitan más flexibilidad en su aceptación de más trabajo.Los equipos pueden usar ágil basado en flujo con una cadencia para obtener lo mejor de ambos mundos. Revisa más a menudo y selecciona mejoras.

51

El flujo de trabajo a menudo se ve interrumpido por varios retrasos o impedimentos

La calidad de los incrementos del producto es pobre

Se necesita más de un equipo para construir un producto

Los miembros del equipo del proyecto no tienen experiencia en el uso de enfoques ágiles

Considere la posibilidad de hacer visible el trabajo utilizando tableros kanban y experimentando con límites para las diversas áreas del proceso de trabajo a fin de mejorar el flujo. Considere usar las diversas prácticas de desarrollo basadas en pruebas .Esta disciplina a prueba de errores hace que sea difícil que los defectos no se detecten. Para escalar de uno a varios equipos ágiles, con una interrupción mínima, primero aprenda sobre la administración ágil de programas o los marcos de escalamiento formales. Luego, elabore un enfoque que se ajuste al contexto del proyecto. Considere comenzar por capacitar a los miembros del equipo sobre los fundamentos de la mentalidad y los principios ágiles .Si el equipo decide utilizar un enfoque específico, como Scrum o Kanban, ofrecer un taller sobre ese enfoque por lo que los miembros del equipo pueden aprender a utilizar eso.

Para obtener orientación adicional sobre los factores que influyen en la adaptación, consulte el Apéndice X2. en Atributos que Influyen en la Sastrería.

52

4 IMPLEMENTAR ÁGIL: CREAR UN ENTORNO ÁGIL 4.1 COMIENCE CON UN AGILE MINDSET La gestión de un proyecto utilizando un enfoque ágil requiere que el equipo del proyecto adopte un enfoque ágil mentalidad Las respuestas a las siguientes preguntas ayudarán a desarrollar una estrategia de implementación: ¿Cómo puede el equipo del proyecto actuar de manera ágil? ¿Qué puede ofrecer el equipo rápidamente y obtener retroalimentación temprana para beneficiar el próximo ciclo de entrega? ¿Cómo puede el equipo actuar de manera transparente? ¿Qué trabajo se puede evitar para enfocarse en artículos de alta prioridad? ¿Cómo puede un enfoque de liderazgo sirviente beneficiar el logro de los objetivos del equipo?

4.2 EL LIDERAZGO DE SERVIDORES ABRE EL EQUIPO Los enfoques ágiles enfatizan el liderazgo de los servidores como una forma de empoderar a los equipos.El liderazgo de servicio es la práctica de conducir a través del servicio al equipo, al centrarse en comprender y 53

abordar las necesidades y el desarrollo de los miembros del equipo a fin de que el mayor equipo posible actuación. El rol de un líder servidor es facilitar el descubrimiento del equipo y la definición de ágil. Los líderes siervos practican y radiat e ágil.Los líderes siervos abordan el trabajo del proyecto en este orden: Objetivo:Trabaje

con el equipo para definir el "por qué" o el propósito para que puedan participar y unirse en torno a la meta del proyecto.Todo el equipo se optimiza a nivel de proyecto, no el nivel de persona. gente.Una vez que se establezca el propósito , anime al equipo a

crear un entorno donde todos puedan tener éxito.Pídale a cada miembro del equipo que contribuya durante el trabajo del proyecto. Rastreo de procesosNo

pienso en el siguiente proceso ágil “perfecta”, pero en lugar de buscar los resultados.Cuando un equipo multifuncional entrega el valor final a menudo y reflexiona sobre el producto y el proceso, los equipos son ágiles.No importa lo que el equipo llama a su proceso.

54

Las siguientes características del liderazgo de servidores permiten a los líderes de proyectos ser más ágiles y facilitar el éxito del equipo: Pr om ov er la aut oc on cie nci a; Es cu ch an do;

S i r v i 55

e n d o a a q u e l l o s e n e l e q u i p o ; A y 56

u d a n d o a l a s p e r s o n a s a c r e c e r E 57

n t r e n a m i e n t o v s . c o n t r o l ; Promover la seguridad, el respeto y la 58

confianza; y Promover la energía y la inteligencia de los demás. El liderazgo siervo no es exclusivo de ágil. Pero una vez que lo han practicado, los líderes servidores generalmente pueden ver qué tan bien se integra el liderazgo de los servidores en la mentalidad y el valor ágiles. Cuando los líderes a desarrollar su liderazgo de servicio o las habilidades de facilitación, que son más propensos a ser ágil.Como resultado, los líderes servidores pueden ayudar a sus equipos a colaborar para entregar valor más rápido. Los equipos ágiles exitosos adoptan la mentalidad de crecimiento, donde las personas creen que pueden aprender nuevas habilidades.Cuando el equipo y los líderes siervos creen que todos pueden aprender, todos se vuelven más capaces.

4.2.1 LIDER SERVIDOR RESPONSABILIDADES Los líderes siervos manejan las relaciones para desarrollar comunicación y coordinación dentro del equipo y en toda la organización.Estas relaciones ayudan a los líderes a navegar por la organización para apoyar al equipo.Este tipo de apoyo ayuda a eliminar los obstáculos y facilita el equipo para agilizar sus procesos.Debido a que los líderes de servicio entienden ágil y práctica de un enfoque específico para ágil, que pueden ayudar en cumpliendo el equipo necesariamente.

4.2.1.1 LÍDERES SERVIDORES FACILITAR Cuando los gerentes de proyecto actúan como líderes servidores , el énfasis pasa de "gestionar la coordinación" a "facilitar la colaboración".Los facilitadores ayudan a todos a hacer su mejor pensamiento y trabajo.Los facilitadores animan a la participación del 59

equipo, la comprensión y la responsabilidad compartida para la salida del equipo.Los facilitadores ayudan al equipo a crear soluciones aceptables . Los líderes siervos promueven la colaboración y la conversación dentro del equipo y entre los equipos. Por ejemplo, un líder servidor ayuda a exponer y comunicar los cuellos de botella dentro y entre los equipos. Luego los equipos resuelven esos cuellos de botella. Además, un facilitador alienta la colaboración a través de reuniones interactivas, diálogos informales e intercambio de conocimientos. Los líderes siervos hacen esto al convertirse en constructores imparciales de puentes y entrenadores, en lugar de tomar decisiones por las cuales otros deben ser responsables.

60

4.2.1.2 Los líderes de servicio REMOVER LA ORGANIZACIÓN IMPEDIMENTOS El primer valor de la Agile Manifesto es individuos e interacciones sobre procesos y herramientas.¿Qué mejor la responsabilidad de un líder de servicio para asumir que tomar una mirada a los procesos ese están impidiendo la agilidad de un equipo u organización y trabajar para agilizarlos ?Por ejemplo, si un departamento requiere una extensa documentación, el papel del líder de servicio podría ser trabajar con ese Departamento para revisar la documentación requerida , ayudar a crear una comprensión compartida de cómo los resultados ágiles cumplen con esos requisitos y evalúan la cantidad de documentación requerida asi que equipos pasan más tiempo la entrega de un producto valioso en lugar de producir documentación exhaustiva . Los líderes siervos también deberían considerar otros procesos que son largos, causando cuellos de botella e impidiendo la agilidad de un equipo u organización .Ejemplos de procesos o departamentos que pueden necesitar ser tratados incluyen las finanzas, la boa de control de cambios RDS, o auditorías.Los líderes de servicio pueden asociarse y trabajar con otros para desafiar a revisar sus procesos para apoyar a los equipos ágiles y líderes.Por ejemplo, lo bueno es que para el equipo de trabajo para entregar el producto cada 2 semanas sólo para que la caída del producto en una cola o proceso que podría tardar 6 semanas o más para liberar debido a los procesos de liberación largos?Demasiadas organizaciones tienen estos procesos “cuello de botella” que impiden la entrega de equipos de forma rápida productos o servicios valiosos.El líder servidor tiene la capacidad de cambiar o eliminar estos impedimentos organizacionales para ayudar a la entrega equipos.

61

HABILIDADES INTERPERSONALES VERSUS HABILIDADES TÉCNICAS Además de liderazgo de servicio, los miembros del equipo hacen hincapié en sus habilidades no-inteligencia interpersonal y emocional sólo habilidades técnicas.Todos en el equipo trabajan para exhibir más iniciativa, integridad, inteligencia emocional , honestidad, colaboración, humildad y buena disposición para comunicarse en varias maneras tan ese el todo equipo poder trabajo juntos bien. El equipo necesita estas habilidades para que puedan responder bien a los cambios en la dirección del proyecto y los cambios técnicos del producto .Cuando todo el mundo se puede adaptar a la obra y el uno al otro, todo el equipo es más probable que tener éxito.

4.2.1.3 LÍDERES SIRVIENTES ABREN EL CAMINO PARA LA CONTRIBUCIÓN DE OTROS En ágil, el equipo administra su proceso de trabajo y su producto de trabajo .Que la autogestión y autoorganización se aplica a todo el mundo para servir y apoyar la organización y proyecto.Los líderes siervos trabajan para satisfacer las necesidades de los equipos, proyectos y organización.Los líderes de servicio pueden trabajar con instalaciones para un espacio de equipo, trabajar con la administración para permitir que el equipo se enfoque en un proyecto a la vez, o trabajar con el propietario del producto para desarrollar historias con el equipo.Algunos líderes servidores trabajan con los auditores para refinar los procesos necesarios en entornos regulatorios , y algunos líderes servidores trabajan 62

con el departamento de finanzas para hacer la transición de la organización a un presupuesto incremental . El líder de servicio se enfoca en allanar el camino para que el equipo pueda hacer su mejor trabajo.El líder servidor influye en los proyectos y alienta a la organización a pensar de manera diferente.

4.2.1.4 Tenga en cuenta estas líder de servicio RESPONSABILIDADES

63

Los líderes de servicio pueden tener muchos títulos posibles, pero lo que es más importante es lo que hacen.Aquí hay algunos ejemplos de las responsabilidades que puede tener un líder servidor : Eduque a los interesados sobre por qué y cómo ser ágil.Explica los beneficios del valor comercial basado en priorización, mayor responsabilidad y productividad de empoderado equipos, y mejorado calidad de Más frecuente revisiones, etc. Apoye al equipo a través de la tutoría, el aliento y el apoyo.Abogar por la capacitación de los miembros del equipo y el desarrollo profesional .La cita oximorónico “Lideramos equipos por detrás de ellos” habla con el papel de líder en el desarrollo de sus miembros del equipo.A través del apoyo, el estímulo y el desarrollo profesional , los miembros del equipo adquieren confianza, asumen roles más grandes y contribuyen a niveles más altos dentro de sus organizaciones. Un papel clave del líder de servicio es nutrir y hacer crecer los miembros del equipo a través y más allá de sus funciones actuales, incluso si eso significa perderlos de el equipo Ayude al equipo con actividades técnicas de gestión de proyectos , como el análisis cuantitativo de riesgos .Algunas veces los miembros del equipo pueden no tener conocimiento o experiencia en roles o funciones.Los líderes siervos que pueden tener más exposición o entrenamiento en técnicas pueden apoyar al equipo proporcionando capacitación o realizando estas actividades. Celebre los éxitos del equipo y apoye y establezca puentes entre las actividades de construcción con grupos externos.Crea espirales ascendentes de apreciación y buena voluntad para una mayor colaboración.

64

4.2.2 Papel del gerente de proyecto en una AGILE AMBIENTE El papel del director del proyecto en un proyecto ágil es algo de un desconocido, debido a que muchos marcos ágiles y enfoques no abordan el papel del director del proyecto.Algunos profesionales piensan ágiles no es necesario el papel de un jefe de proyecto, debido a los equipos de autoorganización que asumen las responsabilidades anteriores del director del proyecto.Sin embargo, los profesionales y organizaciones ágiles y pragmáticos se dan cuenta de que los administradores de proyectos pueden agregar un valor significativo en muchas situaciones.La diferencia clave es que sus roles y responsabilidades se ven algo diferentes. Propina

4.2.3 GERENTES DE PROYECTO UTILIZAN SERVIDOR LIDERAZGO La Guía PMBOK® - Sexta Edición, define al gerente del proyecto como "la persona asignada por la organización ejecutante para dirigir al equipo que es responsable de lograr los objetivos del proyecto". Muchos gerentes de proyecto están acostumbrados a estar en el centro de coordinación del proyecto, rastreando y representando el estado del equipo para el resto de la organización. Este enfoque estaba bien cuando los proyectos se descompusieron en funciones en silos.

65

Sin embargo, en proyectos de gran cambio, hay más complejidad que una persona puede manejar.En cambio, los equipos interfuncionales coordinan su propio trabajo y colaboran con el representante comercial (el propietario del producto). Cuando se trabaja en un proyecto ágil, los gerentes de proyecto pasan de ser el centro a servir al equipo y a la administración.En un entorno ágil , los gerentes de proyecto son líderes de servicio, cambiando su énfasis a entrenar personas que desean ayuda, fomentar una mayor colaboración en el equipo y alinear las necesidades de las partes interesadas .Como un líder servidor, los gerentes de proyecto fomentan la distribución de la responsabilidad hacia el equipo: a las personas que tienen el conocimiento para conseguir trabajo hecho.

Composición del equipo

Un principio básico tanto en los valores y los principios del Manifiesto Ágil es la importancia de los individuos y las interacciones.Ágil optimiza el flujo de valor, haciendo hincapié en la entrega función rápida para el cliente, en lugar de en cómo la gente se “utilizan”. Propina

Cuando los equipos piensan sobre cómo optimizar el flujo de valor, los siguientes beneficios se vuelven aparente: Las personas son más propensa sa colabora 66

r.Los equipos terminan el valioso trabajo más rápido. Equipos pierden mucho menos tiempo porque no realizar múltiples tareas y tenga que volver a establecer el contexto.

4.3.1 ÁGIL EQUIPOS Los equipos ágiles se centran en el desarrollo rápido de productos para que puedan obtener retroalimentación.En la práctica, los equipos ágiles más efectivos tienden a variar en tamaño de tres a nueve miembros.Idealmente, los equipos ágiles se colocan en un espacio de equipo.Los miembros del equipo están 100% dedicados a los equipos.Ágil fomenta la auto equipos de gestión, donde los miembros del equipo decidir quién va a realizar el trabajo dentro del ámbito definido del siguiente período.Los equipos ágiles prosperan con liderazgo siervo.Los líderes apoyan el enfoque de los equipos en su trabajo. Los equipos ágiles multifuncionales producen incrementos funcionales del producto con frecuencia.Esto se debe a que los equipos poseer colectivamente el trabajo y en conjunto tienen todas las habilidades necesarias para entregar el trabajo terminado. Independientemente del enfoque ágil en general, más un equipo limita su trabajo en progreso, es más probable que sus miembros pueden colaborar para acelerar el trabajo en todos los ámbitos.Miembros del equipo en exitoso

67

equipos ágiles de trabajo para colaborar en diversas formas (tales como el emparejamiento, enjambre, y mobbing), de modo que no caigan en la trampa de mini-cascadas lugar de trabajo colaborativo.Minicascadas se producen cuando el equipo se dirige a todos los requisitos en un período determinado, a continuación, intenta hacer todo el diseño, a continuación, pasa a hacer todo el edificio.El uso de este escenario, en algún momento en el edificio o la prueba después de la construcción, el equipo puede darse cuenta de que tenía supuestos que ya no son válidas.En este caso, el equipo de la pérdida de tiempo para hacer frente a todos los requisitos.En cambio, cuando los miembros del equipo colaboran para producir un pequeño número de características en todos los ámbitos, aprenden a medida que avanzan y entregan más pequeña acabada caracteristicas. Los proyectos ágiles se benefician de las estructuras del equipo del proyecto que mejoran la colaboración dentro y entre los equipos.Tabla 41 muestra cómo los miembros del equipo colaborativo aumentan la productividad y facilitan el problema innovador resolviendo TablaAtributos de Temáticas Ágiles Exitosas

Atrib uto

Personal dedicado

Equipo multifuncional miembros

68

O b j e t i v o Mayor enfoque y productividad Pequeño equipo, menos de diez personas Desarrollar y entregar a menudo Entregar valor final como un equipo independiente Integrar todas las actividades de trabajo para entregar terminado trabajo

Proporcione comentarios desde dentro del equipo y de otros, como el propietario del producto

Colocación o capacidad para gestionar cualquier desafío de ubicación

Mejor comunica ción Dinámica mejorada del equipo Intercamb io de conocimi entos Costo reducido de aprendiza je Capaz de comprometerse a trabajar con cada otro Los especialistas proveen experiencia dedicada y generalistas proporcionan flexibilidad de quién hace qué El equipo aporta sus capacidades especializadas y, a menudo, se convierten en especialistas generalizadores , con una especialidad de enfoque y una amplitud de experiencia en múltiples habilidades

Equipo mixto de generalista sy especialist as

Ambiente de trabajo estable

4.3.2

Dependen el uno del otro para ofrecer un enfoque acordado para el trabajo Cálculos simplificados del costo del equipo (tasa de ejecución) Preservación y expansión del capital intelectual

ÁGIL ROLES

En 69

ágil , se util iza n tres rol es co mu nes : mie mb ros del equ ipo mu ltif unc ion al , pro piet 70

ari o del pro duc to y Equipo facilitador La Tabla 4-2 describe estos roles de equipo.

71

T a b l a A g i l e T e a m R o l e s

R o l

Equipo multifuncional miembro

72

D e s c r i p c i ó n Los equipos multifuncionales están formados por miembros del equipo con todas las habilidades necesarias para producir un producto funcional .En el desarrollo de software , los equipos interfuncionales generalmente están compuestos por diseñadores, desarrolladores, evaluadores y cualquier otro rol requerido .Los equipos de desarrollo multi-funcionales consisten en profesionales que entregan producto potencialmente liberable en una cadencia regular.Equipos multi-funcionales son críticos, ya que pueden ofrecer un trabajo de acabado en el menor tiempo posible, con la mayor calidad, sin externa dependencias.

Propietario del producto.

El propietario del producto es responsable de guiar la dirección del producto.Los propietarios de productos clasifican el trabajo en función de su valor comercial .Los propietarios de los productos trabajan con sus equipos a diario al proporcionar retroalimentación del producto y establecer la dirección en la próxima pieza de funcionalidad que se desarrollará / entregará.Eso significa que el trabajo es pequeño, demasiado pequeñas como para ser descrito en una tarjeta de índice. El propietario del producto trabaja con las partes interesadas, los clientes y los equipos para definir la dirección del producto .Por lo general, los propietarios de productos tienen un conocimiento de los negocios y traer expertos en la materia profunda a las decisiones.A veces, el propietario del producto solicita ayuda de personas con conocimientos profundos de dominio , como arquitectos, o expertos profundos de los clientes , como los gerentes de productos .Los dueños del producto necesitan capacitación sobre cómo organizar y gestionar el flujo de trabajo a través de la equipo. En ágil, los propietarios del producto crean la cartera de pedidos para y con el equipo.La cartera de ayuda a los equipos ver cómo entregar el valor más alto sin crear residuos. Un factor crítico de éxito para los equipos ágiles es la fuerte propiedad del producto .Sin prestar atención al valor más alto para el cliente, el equipo ágil puede crear características que no son apreciados, o de otra manera suficientemente valiosa, por lo tanto, perder esfuerzo.

Equipo facilitador

El tercer rol típicamente visto en equipos ágiles es el de un facilitador de equipo , un líder servidor .Esta función puede ser llamado un jefe de proyecto, scrum master, líder del equipo de proyecto, el entrenador del equipo, o facilitador del equipo. Todos los equipos ágiles necesitan un liderazgo siervo en el equipo. Las personas necesitan tiempo para desarrollar sus habilidades de liderazgo de facilitación, entrenamiento y eliminación de impedimentos. Inicialmente, muchas organizaciones invitan a entrenadores ágiles externos para ayudarlos cuando su capacidad de coaching interno aún no está completamente desarrollada. Los entrenadores externos tienen la ventaja de la experiencia, pero la desventaja de las relaciones débiles en la organización del cliente .Entrenadores internos, por el contrario, tienen fuertes relaciones en su organización, pero pueden carecer de la amplitud de la experiencia que les haría muy eficaz.

73

"PERSONAS EN FORMA DE I Y PERSONAS EN FORMA DE T" Algunas personas tienen especializaciones profundas en un dominio, pero rara vez contribuyen fuera de ese dominio.Estas personas son conocidas en comunidades ágiles como "personas en forma de I" ya que, como la letra "I" , tienen profundidad, pero no mucha amplitud.Por el contrario, las " personas en forma de T " complementan su experiencia en un área con habilidades de apoyo, pero menos desarrolladas en áreas asociadas y buenas habilidades de colaboración.A modo de ejemplo, una persona que pueda probar algunas áreas del producto y desarrollar diferentes áreas del producto es considerado como una forma de T persona.

74

Una persona en forma de T tiene una especialización definida y reconocida y una función principal, pero tiene las habilidades, la versatilidad y la aptitud para la colaboración para ayudar a otras personas cuando y donde sea necesario.Esta colaboración reduce los traspasos y las limitaciones de que solo una persona pueda hacer el trabajo.

4.3.3 GENERALIZANDO ESPECIALISTAS Los equipos ágiles son multi-funcional, pero la gente a menudo no comienzan de esa manera.Sin embargo, muchos equipos ágiles exitosas están formados por especialistas en la generalización, o “forma de T” gente. Esto significa que los miembros del equipo tienen tanto una especialidad enfoque más una amplia experiencia a través de múltiples habilidades, en lugar de una sola especialidad.Los miembros del equipo ágiles trabajan para desarrollar estas características debido a la intensa colaboración y la auto-organización de enjambre y realizar su trabajo rápidamente, lo que les obliga a ayudar de forma rutinaria entre sí. El rendimiento de una sola persona no es relevante.Centrándose en el rendimiento de una sola persona puede incluso ser perjudicial si se crea un cuello de botella para el resto del equipo.El objetivo es que el equipo optimice la entrega del trabajo terminado para obtener comentarios. Si el cliente desea grandes resultados, como la entrega función rápida con una calidad excelente, el equipo no puede estructurarse simplemente con funciones especializadas en un intento de maximizar la eficiencia de los recursos.El objetivo del equipo es la eficiencia del flujo, la optimización del rendimiento de todo el equipo.Los tamaños de lote pequeños promueven el trabajo conjunto como equipo.El trabajo del dueño del producto es asegurarse de que el equipo trabaja en el más alto valor trabajo. 75

4.3.4 EQUIPO ESTRUCTURAS Los equipos han adoptado principios y prácticas ágiles en muchas industrias. Organizan a las personas en equipos interfuncionales para desarrollar iterativamente productos en funcionamiento.

CAJA

Algunas organizaciones han sido capaces de crear equipos colocated, multi-funcionales; otros tienen una situación diferente .En lugar de tener todos los miembros del equipo coubicados, algunas organizaciones han distribuido o dispersado equipos.Los equipos distribuidos tienen equipos multi-funcionales en diferentes lugares.Los equipos dispersos pueden hacer que cada miembro del equipo trabaje en una ubicación completamente diferente , ya sea en una oficina o desde su casa.Si bien estas disposiciones no son ideales debido al aumento de los costos de comunicación, pueden

76

todavía ser viable.

En una gran institución financiera, con sede en EEUU hubo un programa con un conjunto de equipos en los que los miembros del equipo se basaron en la costa este de los Estados Unidos y en varios lugares en toda la India.Cuando el equipo comenzó por primera vez, se trataba de un gran equipo disperso (UX, analistas, desarrolladores y evaluadores) que hacía un "seguir al sol". ” 2 práctica del desarrollo en un tiempo de trabajo se superponen a través de los miembros del equipo para hacer cálidos traspasos con el trabajo.Los miembros del equipo realizaron levantamientos diarios juntos y utilizaron cámaras web para incluir a todos los miembros del equipo .Los papeles clave (analistas, los dueños del producto, diseñadores UX y clientes potenciales de desarrollo) en los EE.UU. entrarían 77

pronto para responder a las preguntas de los miembros de su equipo con sede en la India y ayudar a resolver impedimentos A medida que el producto comenzó cada vez más grande, y más fondos llegó a través, ellos decidieron dividirse en cinco equipos más pequeños.Para ello, se decidió construir, equipos distribuidos de ubicación conjunta en varios lugares.Se tomó la decisión de construir multi-funcionales, los equipos de ubicación conjunta en cada uno de estos lugares que constan de los desarrolladores y probadores. También tenían un conjunto básico de los analistas, con base en los dos lugares de Estados Unidos, que trabajaron con su director de productos y de productos propietarios en Estados Unidos y luego trabajaron con cada uno de los equipos, respectivamente.A pesar de que tenían algún tipo de estructura en el lugar donde se llevaron a cabo comentario como un programa completo, la mayoría de las otras actividades se realizaron a nivel de equipo, en base a lo que funcionó mejor para cada equipo, para que puedan para autoorganizarse

4.3.5 EQUIPO DEDICADO MIEMBROS ¿Qué sucede cuando el tiempo de los miembros del equipo no está 100% dedicado al equipo?Si bien esta condición no es ideal, lamentablemente, a veces no se puede evitar. El problema clave con que alguien invierta solo una capacidad del 25% o del 50% en el equipo es que realizarán varias tareas al mismo tiempo y cambiarán tareas. La multitarea reduce el rendimiento del trabajo del equipo y afecta la capacidad del equipo para predecir la entrega de manera consistente. Propina

78

Las personas experimentan pérdidas de productividad en algún lugar entre 20% y 40% cuando se cambia de tarea. La pérdida aumenta exponencialmente con el número de tareas. Cuando una persona realiza varias tareas a la vez entre dos proyectos, esa persona no es el 50% de cada proyecto. En cambio, debido al costo del cambio de tarea, la persona se encuentra entre el 20% y el 40% en cada proyecto.

79

Las personas son más propensas a cometer errores cuando realizan múltiples tareas. El cambio de tareas consume memoria de trabajo y es menos probable que las personas recuerden su contexto cuando realizan varias tareas. Cuando todos en el equipo es 100% asignado a un proyecto, que pueden colaborar de forma continua como un equipo, por lo que el trabajo de todos mas eficaz.

CAJA

Ver Tabla A1-2 de Gestión de Proyectos del Grupo de Procesos y Conocimiento Mapeo zona para obtener más consejos sobre equipos en entornos ágiles, específicamente los procesos en la gestión del conocimiento de recursos del proyecto Zona. Propina

80

4.3.6 EQUIPO ESPACIOS DE TRABAJO Los equipos necesitan un espacio en el que puedan trabajar juntos, entender su estado como equipo y colaborar.Algunos equipos ágiles trabajan todos juntos en una habitación .Algunos equipos tienen un espacio de trabajo en equipo para sus montajes y gráficos, y trabajan por su cuenta en cubículos u oficinas. Si bien las empresas se están moviendo hacia entornos de trabajo abiertos y colaborativos, las organizaciones también necesitan crear espacios silenciosos para los trabajadores que necesitan tiempo ininterrumpido para pensar y trabajar. Por lo tanto, las empresas están diseñando sus oficinas para equilibrar áreas comunes y sociales (a veces llamadas "cuevas y comunes") con áreas tranquilas o espacios privados donde las personas pueden trabajar sin interrupción.

81

Cuando los equipos se han distribuido geográficamente miembros, el equipo decide qué parte de su el lugar de trabajo es virtual y cuánto es físico.La tecnología como el uso compartido de documentos, videoconferencias y otras herramientas de colaboración virtual ayudar a las personas a colaborar de forma remota. Los equipos distribuidos geográficamente necesitan espacios de trabajo virtuales.Además, considerar la obtención de equipo juntos en persona a intervalos regulares por lo que el equipo puede generar confianza y aprender a trabajar juntos. Algunas técnicas a considerar para la gestión de la comunicación en equipos dispersos son ventanas de pecera y control remoto emparejamiento : Crear una ventana pecera mediante el establecimiento de enlaces de larga vida de videoconferencia entre los distintos lugares en los que se dispersa el equipo.La gente empieza el enlace al comienzo de un día de trabajo, y se cierran al final.De esta manera, la gente puede ver y participar espontáneamente entre sí, reduciendo el rezago de la colaboración de lo contrario inherente en la separación geográfica Configurar el emparejamiento a distancia mediante el uso de herramientas de conferencia virtual para compartir pantallas, incluyendo enlaces de voz y video.Mientras el tiempo de las diferencias de zona se tienen en cuenta, esto puede resultar casi tan eficaz como el emparejamiento cara a cara. Propina

4.3.7 SUPERANDO LA ORGANIZACIÓN SILOS

82

El mejor lugar para empezar a la hora de formar los equipos ágiles es mediante la creación de un fideicomiso fundacional y un entorno de trabajo seguro para garantizar que todos los miembros del equipo tienen la misma voz y pueden ser escuchadas y consideradas.Esto, junto con la construcción de una mentalidad ágil es el factor de éxito subyacente : todos los demás desafíos y riesgos pueden mitigarse. A menudo, las organizaciones en silos crean impedimentos para formar equipos ágiles multifuncionales .Los miembros del equipo necesarios para construir los equipos multi-funcionales suelen informar a los diferentes gestores y tienen diferentes métricas mediante el cual los gestores miden su rendimiento.Los gerentes deben enfocarse en la eficiencia del flujo (y las métricas basadas en el equipo) en lugar de la eficiencia de los recursos . Para superar los silos organizacionales, trabajar con los diferentes gestores de estos miembros del equipo y hacer que se dedican las personas necesarias para el equipo multifuncional.Esto no sólo crea la sinergia del equipo sino que también permite a la organización para ver cómo el aprovechamiento de su gente optimizará el ser proyecto o producto construido. Para obtener más información sobre equipos, consulte el Apéndice X2 sobre Atributos que influyen en la adaptación. Propina

83

2 Un proceso de desarrollo de seguimiento del sol es aquel en el que el trabajo se transfiere al final de cada día de un sitio a otro, muchos zonas horarias de distancia con el fin de acelerar el desarrollo del producto.

84

5 IMPLEMENTING AGILE: ENTREGANDO EN UN AGILE AMBIENTE 5.1 CHARTER EL PROYECTO Y EL EQUIPO Cada proyecto necesita una carta de proyecto para que el equipo de proyecto sepa por qué este proyecto es importante, hacia dónde se dirige el equipo y cuál es el objetivo del proyecto .Sin embargo, el estatuto del proyecto en sí mismo puede no ser suficiente para el equipo.Los equipos ágiles requieren normas de equipo y una comprensión de cómo trabajar juntos.En ese caso, el equipo podría necesitar un equipo carta. El proceso de fletamento ayuda al equipo a aprender cómo trabajar juntos y unirse en torno al proyecto. Como mínimo, para un proyecto ágil, el equipo necesita la visión o el propósito del proyecto y un conjunto claro de acuerdos de trabajo. Una carta de proyecto ágil responde a estas preguntas: ¿Por qué estamos haciendo este proyecto?Esta es la visión del proyecto. ¿Quién se beneficia y cómo?Esto puede ser parte de la visión del proyecto y / o del propósito del proyecto.Lo que hace media para el proyecto?Estos son los lanzamientos del proyecto criterios.

85

¿Cómo vamos a trabajar juntos?Esto explica el flujo de trabajo previsto. Un líder servidor puede facilitar el proceso de charteo.Un equipo puede unirse trabajando juntos, y el estatuto del proyecto es una excelente manera de comenzar a trabajar. Además, los miembros del equipo pueden querer colaborar para comprender cómo van a trabajar juntos. Los equipos no necesitan un proceso formal para el alquiler siempre que los equipos entienden cómo trabajar juntos.Algunos equipos se benefician del proceso de fletamento de un equipo.Aquí están algunas ideas de fletamento para los miembros del equipo para utilizar como base de su contrato social: Valores del equipo, como ritmo sostenible y horas centrales; Acuerdos, como lo “listo” significa que el equipo pueda tener en el trabajo de trabajo; qué significa "hecho" para que el equipo pueda juzgar la integridad de manera consistente; respetando el timebox; o el uso de límites de trabajo en proceso; Las reglas básicas, como una persona que habla en una reunión; Las normas del grupo y, por ejemplo, cómo las golosinas equipo horarios de las reuniones.

86

El líder servidor junto con el equipo puede decidir abordar otros comportamientos. Recuerde que el contrato social del equipo, su estatuto de equipo, es la forma en que los miembros del equipo interactúan con cada otro. los Gol de el equipo carta es crear un ágil ambiente en cual equipo los usuarios pueden trabajar al máximo de su capacidad como equipo.

5.2 AGILE COMÚN PRÁCTICAS Las secciones 5.2.1 a 5.2.8 describen algunas de las prácticas de proyectos ágiles más comunes.

5.2.1 RETROSPECTIVAS La práctica individual más importante es la retrospectiva porque permite al equipo conocer, mejorar y adaptar su proceso. Las retrospectivas ayudan al equipo a aprender de su trabajo anterior sobre el producto y su proceso. Uno de los principios detrás del Manifiesto Ágil es: "A intervalos regulares, el equipo reflexiona sobre cómo ser más eficaz, luego sintoniza y ajusta su comportamiento en consecuencia". Muchos equipos usan iteraciones, especialmente iteraciones de 2 semanas , porque las instrucciones de iteración una demostración y una retrospectiva al final.Sin embargo, el equipo no necesita iteraciones con el fin de retrospectiva.Los miembros del equipo pueden decidir a Retrospect en estos momentos clave: Cuando el equipo completa un lanzamiento o envía algo.No tiene que ser un incremento monumental.Puede ser cualquier versión, no importa cuán pequeño. Cuando han pasado más de unas pocas semanas desde la retrospectiva anterior.

87

Cuando el equipo parece estar atascado y completado el trabajo No está fluyendo a través del equipo.Cuando el equipo alcanza cualquier otro hito. Los equipos se benefician al asignar suficiente tiempo para aprender, ya sea a partir de una retrospectiva interina o una retrospectiva al final del proyecto.Los equipos necesitan aprender acerca de su producto de trabajo y el proceso de trabajo.Por ejemplo, algunos equipos tienen problemas para terminar el trabajo.Cuando los equipos de planificar el tiempo suficiente, se pueden estructurar su retrospectiva para recopilar datos, procesar esos datos, y decidir qué probar más tarde como un experimento. En primer lugar, una retrospectiva no es culpa; la retrospectiva es un momento para que el equipo aprenda del trabajo previo y haga pequeñas mejoras. La retrospectiva trata de observar los datos cualitativos (sentimientos de las personas) y cuantitativos (mediciones ), y luego usar esos datos para encontrar causas raíz, diseñar contramedidas y desarrollar planes de acción.El equipo del proyecto puede terminar con muchos elementos de acción para eliminar impedimentos. Considere limitar el número de elementos de acción a la capacidad del equipo para abordar la mejora en la próxima iteración o período de trabajo .Tratando de mejorar demasiadas cosas a la vez y no terminar cualquiera de ellos es mucho peor que la intención de completar un menor número de artículos y completar con éxito todos ellos.Luego, cuando el tiempo lo permite, el equipo puede trabajar en la próxima oportunidad de mejora en la lista.Ajustando el boton

88

el equipo selecciona las mejoras, decide cómo medir los resultados.Luego, en el próximo período de tiempo, mida los resultados para validar el éxito o el fracaso de cada mejora. Un facilitador del equipo los guía a través de una actividad para clasificar la importancia de cada elemento de mejora. Una vez que el equipo clasifica los elementos de mejora, el equipo elige el número apropiado en el que trabajar para la siguiente iteración (o agrega el trabajo al mínimo si está basado en el flujo).

5.2.2 RESERVA PREPARACIÓN La acumulación es la lista ordenada de todo el trabajo, presentado en forma de historia , para un equipo.No hay necesidad de crear todas las historias de todo el proyecto antes de que el trabajo comienza sólo lo suficiente para entender el primer lanzamiento a grandes rasgos y elementos suficientes entonces para la próxima iteración. Los dueños del producto (o un equipo de valor dueño del producto que incluye el gestor de producto y todos los propietarios de los productos relevantes para esa zona del producto,) podrían producir un plan de producto para mostrar la secuencia prevista de entregables con el tiempo.El propietario del producto replantea la hoja de ruta en función de lo que produce el equipo.(Ver el Apéndice X3 en herramientas de filtro de idoneidad ágil para ver ejemplos de hojas de ruta).

5.2.3 RESERVA REFINAMIENTO En la versión ágil basada en iteraciones, el propietario del producto a menudo trabaja con el equipo para preparar algunas historias para la próxima iteración durante una o más sesiones en el medio de la iteración.El propósito de estas reuniones consisten en refinar suficientes historias para que el equipo comprenda cuáles son las historias y cuán grandes son las historias en relación con cada una de ellas. otro. No hay consenso sobre cuánto tiempo debería ser el refinamiento. Hay un continuo de: 89

Refinamiento justo a tiempo para ágil basado en flujo.El equipo saca la siguiente carta de la columna de tareas pendientes y la discute. Muchos equipos ágiles basados en la iteración utilizan a 1 hora a mitad de camino a través de una discusión timeboxed 2semanas iteración.(El equipo selecciona una duración de iteración que les proporciona una respuesta lo suficientemente frecuente ). Múltiples discusiones de refinamiento para equipos ágiles basados en iteraciones.Los equipos pueden usar esto cuando son nuevos en el producto, el área del producto o el dominio del problema. Propina

Reuniones de refinamiento permiten al dueño del producto para presentar ideas de la historia para el equipo y para el equipo

90

aprende sobre los posibles desafíos o problemas en las historias.Si el propietario del producto no está seguro de las dependencias, el propietario del producto puede solicitar al equipo que incremente la característica para comprender los riesgos. El propietario del producto tiene varias formas de llevar a cabo reuniones de preparación y refinamiento del retraso acumulado, como por ejemplo: Aliente al equipo a trabajar como tríadas de desarrollador, probador, analista de negocios / propietario de producto para analizar y escribir la historia. Presentar el concepto global historia para el equipo.El equipo discute y lo refina en tantas historias como necesario. Trabajar con el equipo para encontrar diversas maneras de explorar y escribir las historias juntos, asegurándose de que todas las historias son lo suficientemente pequeños para que el equipo puede producir un flujo constante de trabajo completado.Considere la posibilidad de poder completar una historia al menos una vez al día. Los equipos tienen a menudo un objetivo de gastar no más de 1 hora por semana historias de refinación para el siguiente lote de trabajo.Equipos quieren maximizar el tiempo dedicado a hacer el trabajo en lugar de trabajo de planificación.Si el equipo tiene que gastar más de 1 hora por semana historias de refinación, el dueño del producto podría ser overpreparing, o el equipo pueden faltar algunas habilidades críticas necesarias para evaluar y refinar el trabajo.

5.2.4 DIARIO STANDUPS Los equipos usan standups para comprometerse entre sí, descubrir problemas y garantizar que el trabajo fluya sin problemas a través del equipo. Timebox el standup a no más de 15 minutos.El equipo “camina” el tablero Kanban o tarea, de alguna manera, y cualquier persona del equipo puede facilitar el stand up. 91

En iteración basada ágil, todo el mundo responde a las siguientes preguntas en un round-robin: ¿Qué es lo que completo desde la última de pie? ¿Qué planeo completar de ahora en adelante? ¿Cuáles son mis impedimentos (o riesgos o problemas)? Preguntas como éstas generan respuestas que permiten que el equipo se autoorganice y se responsabilicen mutuamente por completar el trabajo que se comprometieron el día anterior y durante toda la iteración. Fluido basado en ágil tiene un enfoque diferente a los montajes, centrándose en el rendimiento del equipo .El equipo evalúa el tablero de derecha a izquierda. Las preguntas son: ¿Qué necesitamos hacer para avanzar en este trabajo?¿ Alguien está trabajando en algo que

no

está

en

el

¿tablero?¿Qué necesitamos terminar

para como

una

¿equipo? ¿Hay algún cuello de botella o bloqueador del flujo de trabajo? Uno de los antipatrones que generalmente se ven en los standups es que se convierten en reuniones de estado .Equipos que tienen

92

tradicionalmente trabajado en un entorno predictivo puede tender a caer en este antipatrón ya que están acostumbrados a proporcionar un estado. Otro antipatrón que se ve típicamente en los standups es que el equipo comienza a resolver los problemas a medida que se hacen evidentes.Los Standups son para darse cuenta de que hay problemas, no para resolverlos .Agregue los problemas a un estacionamiento , y luego cree otra reunión, que podría ser justo después de la presentación , y resuelva los problemas allí. Los equipos ejecutan sus propios standups.Cuando se ejecuta bien, a tamaño natural puede ser muy útil, siempre y cuando la naturaleza del trabajo del equipo requiere una intensa colaboración.Tome una decisión consciente sobre cuándo el equipo necesita, o puede usar efectivamente , standups. Propina

5.2.5 DEMOSTRACIONES / COMENTARIOS A medida que el equipo completa las características generalmente en forma de historias de usuario, el equipo demuestra periódicamente el producto de trabajo.El propietario del producto ve la demostración y acepta o rechaza las historias. En basada en la iteración ágil, el equipo demuestra todos los elementos de trabajo completado al final de la iteración.En ágil basado en flujo, el equipo demuestra el trabajo completado cuando es el momento de hacerlo, generalmente cuando se han acumulado suficientes características en un conjunto que es coherente.Equipos, incluyendo el propietario del producto, necesitan información para decidir qué tan temprano para pedir el producto realimentación. 93

Como pauta general, demostrar lo que el equipo tiene como producto de trabajo al menos una vez cada 2 semanas.Esa frecuencia es suficiente para la mayoría de los equipos, por lo que los miembros del equipo pueden obtener retroalimentación que les impide dirigirse en una dirección equivocada.Eso también es lo suficientemente frecuente como para que los equipos puedan mantener el desarrollo del producto lo suficientemente limpio como para construir un producto completo tan a menudo como lo deseen o lo necesiten . Una parte fundamental de lo que hace que un proyecto sea ágil es la entrega frecuente de un producto que funcione .Un equipo que no se desprendan o liberación no puede aprender lo suficientemente rápido y probablemente no se adoptan técnicas ágiles.El equipo puede requerir entrenamiento adicional para permitir la entrega frecuente .

5.2.6 PLANIFICACIÓN PARA BASES DE ITERACIÓN ÁGIL La capacidad de cada equipo es diferente. El tamaño de la historia típica de cada propietario de producto es diferente.Los equipos consideran el tamaño de su historia, por lo que no intentan comprometerse con más historias de las que hay capacidad de equipo para completar en una iteración.

94

Cuando las personas no están disponibles (por ejemplo, vacaciones, vacaciones o cualquier cosa que impida que las personas participen en el siguiente grupo de trabajo), el propietario del producto comprende que el equipo ha reducido la capacidad.El equipo no será capaz de terminar la misma cantidad de trabajo, ya que terminó en el período de tiempo anterior.Cuando los equipos tienen una capacidad reducida, que sólo planear para el trabajo que cumpla esa capacidad. Los equipos estiman lo que pueden completar, que es una medida de la capacidad (consulte la Sección 4.10 para ver ejemplos).Los equipos no pueden predecir con 100% de certeza lo que pueden ofrecer, ya que no pueden saber lo inesperado.Cuando los dueños del producto hacen que las historias más pequeñas y equipos ven el progreso en forma de un producto acabado, los equipos aprenden lo que son capaces de hacer para el futuro. Los equipos ágiles no planifican solo una vez en un solo trozo. En cambio, los equipos ágiles planean un poco, entregan, aprenden y luego replanifican un poco más en un ciclo continuo. Propina

5.2.7 PRÁCTICAS DE EJECUCIÓN QUE AYUDAN A LOS EQUIPOS A ENTREGAR VALOR Si el equipo no presta atención a la calidad, pronto será imposible liberar algo rápidamente. Las siguientes prácticas técnicas , muchas de las cuales provienen de eXtreme Programming, pueden ayudar al equipo a entregar a su máxima velocidad: Integración ContinuaRealizar

frecuente incorporación del trabajo en el conjunto, no importa el producto, y luego vuelva a probar 95

para determinar que el producto entero todavía funciona según lo previsto. Prueba en todos los niveles.Emplear pruebas a nivel de sistema para obtener información de extremo a extremo y las pruebas unitarias para los bloques de construcción.En el medio, entender si hay una necesidad de pruebas de integración y dónde.Equipos encontrar pruebas de humo útiles como un primer vistazo a si el producto del trabajo es bueno.Los equipos han encontrado que decidir cuándo ejecutar pruebas de regresión y cuáles les ayuda a mantener la calidad del producto con un buen rendimiento de generación.Los equipos ágiles tienen una fuerte preferencia por las pruebas automatizadas para que puedan construir y mantener un impulso de entrega. Desarrollo impulsado por prueba de aceptación (ATDD).En ATDD, todo el equipo se reúne y discute los criterios de aceptación para un producto de trabajo.A continuación, el equipo crea las pruebas, lo que permite al equipo a escribir código justo lo suficiente y pruebas automatizadas para cumplir con los criterios.Para proyectos que no son de software , considere cómo probar el trabajo a medida que el equipo complete fragmentos de valor.

96