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 3-
2. 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 5-
1. Burndown Chart para la historia restante
Puntos
Figura 4-14Gráfico de quemado para mostrar la
historia Puntos Terminado Figura 5-
3. 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 La relación entre
Figura 6-1.
la gestión del cambio y Ágil
E
n
f
o
q
u
e
s
Figura 4-14Ejemplo de evaluación
Organizativo Cultura Figura 6-
3. 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 X3-
1. Modelo para la idoneidad de Agile Enfoque
Figura X3-2. Buy-In
a Enfoque Evaluación
Figura X3-
3. 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 X3-
8. 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 X3-
11. Evaluación de
idoneidad Radar Gráfico
9
Figura X3-12. Tienda
de Drogas Proyecto
Figura X3-13. Militar
Mensajería Ejemplo Mesa 1-
1. 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 4-
1. Atributos de éxito Ágil
Equipos Mesa 4-2. Equipo
ágil Roles
TablaPuntosde 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 A2-
Guí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 A3-
5. Los elementos clave de la Proceso Unificado
Agile
Tabla 4AComparación de LeSS
y Melé Mesa X2-
1. 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-change-
education /

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 una

elegir un enfoque y/o práctica ágil enfoque/práctica particular

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. Nuestra más alta prioridad es la satisfacción del cliente, a través de una

temprana y continua entra de valores del software.
2. Los cambios en los requerimientos son bienvenido, aún tarde en el
desarrollo. Los procesos ágiles implementa cambio para la ventaja
competitiva del cliente.
3. Entrega frecuente del software trabajando, desde un par de semanas hasta
un par de meses, con una preferencia en una escala corta de tiempo.
4. Las personas del negocio y los desarrolladores deben trabajan juntos
diariamente a lo largo del proyecto.
5. Construcción de proyectos alrededor de individuos motivados. Denle el
entorno y soporte que ellos necesitan, y confié que obtendrá el trabajo
realizado.
6. El método más eficiente y efectivo de transmitir información desde y hacia
el equipo de desarrollo son conversaciones face-to-face.
7. El software trabajando en la medida principal de progreso.
8. Los procesos agiles promocionan un desarrollo sustentable. Los sponsors,
desarrolladores, y usuarios deberían poder mantener un ritmo constante
indefinidamente.
9. Atención continua a la excelencia técnica y el buen diseño acentúa la
agilidad
10. Simplicidad – El arte de maximizar el monto de trabajo no hecho – es
esencial.
11. Las mejores arquitecturas, requisitos, y diseños emergen desde los equipos
de auto-organización
12. 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, XP-

50
 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 Opciones
de de
proyecto sastrería
Muchos equipos encuentran que
el uso de una cadencia (en la
Patrón de demanda: constante o esporádico 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.
Tasa de mejora del proceso requerida por el nivel
Revisa más a menudo y selecciona
de experiencia del equipo
mejoras.

51
 Considere la posibilidad de
El flujo de trabajo a menudo se ve interrumpido por
hacer visible el trabajo
varios retrasos o impedimentos
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
La calidad de los incrementos del producto es pobre 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
Se necesita más de un equipo para construir un producto
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
Los miembros del equipo del proyecto no tienen
equipo sobre los fundamentos de
experiencia en el uso de enfoques ágiles
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 auto-
organizació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.Mini-
cascadas 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 4-
1 muestra cómo los miembros del equipo colaborativo aumentan la
productividad y facilitan el problema innovador resolviendo

TablaAtributos de Temáticas Ágiles Exitosas

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

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

Mejor
comunica
Colocación o
ción
capacidad para
Dinámica
gestionar
mejorada
cualquier
del
desafío de
equipo
ubicación
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
Equipo proporcionan flexibilidad de quién hace qué
mixto de El equipo aporta sus capacidades especializadas y, a menudo, se
generalista convierten en especialistas generalizadores , con una especialidad
sy de enfoque y una amplitud de experiencia en múltiples habilidades
especialist
as
Dependen el uno
del otro para
Ambiente de ofrecer un
trabajo estable
enfoque acordado
para el trabajo
Cálculos simplificados del costo
del equipo (tasa de ejecución)
Preservación y expansión del
capital intelectual

4.3.2 Á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 D
o e
l 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
Equipo multifuncional
interfuncionales generalmente están compuestos por
miembro
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.

72
 El propietario del producto es responsable de guiar la dirección
del producto.Los propietarios de productos clasifican el trabajo
Propietario del producto. 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.
El tercer rol típicamente visto en equipos ágiles es el de un
Equipo facilitador 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 2-
semanas 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 para
terminar 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