Agile Project Management by Nicolas Benjamin Cruz Carpio

AgileProject

Gestión 2da edición

por Mark C. Layton y Steven J Ostermiller

Gestión ágil de proyectos para principiantes ®, 2da edición Publicado por: John Wiley & Sons, Inc., 111 River Street, Hoboken, Nueva Jersey 07030-5774, www.wiley.com

Copyright © 2017 de John Wiley & Sons, Inc., Hoboken, Nueva Jersey Publicado simultáneamente en Canadá Ninguna parte de esta publicación puede ser reproducida, almacenada en un sistema de recuperación o transmitida en cualquier forma o por cualquier medio, electrónico, mecánico, fotocopiado, grabación, escaneo o de otro tipo, excepto según lo permitido por las Secciones 107 o 108 de los Derechos de Autor de los Estados Unidos de 1976. Actuar, sin el permiso previo por escrito del Editor. Las solicitudes de permiso al Editor deben dirigirse al Departamento de Permisos, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, o en línea al http://www.wiley.com/go/ permisos. Marcas comerciales: Wiley, For Dummies, el logotipo de Dummies Man, Dummies.com, Making Everything Easier y la imagen comercial relacionada son marcas comerciales o marcas comerciales registradas de John Wiley & Sons, Inc. y no pueden usarse sin permiso por escrito. SAFe y Scaled Agile Framework son marcas registradas de Scaled Agile, Inc. Certified Scrum Developer, Certified Scrum Product Owner, Certified Scrum Professional, Certified Scrum Trainer y Certified ScrumMaster son marcas registradas de Scrum Alliance. PMI Agile Certified Practitioner y PMI-ACP son marcas comerciales registradas de Project Management Institute, Inc. Todas las demás marcas comerciales son propiedad de sus respectivos dueños. John Wiley & Sons, Inc. no está asociado con ningún producto o proveedor mencionado en este libro.

LÍMITE DE RESPONSABILIDAD / RENUNCIA DE GARANTÍA: EL EDITOR Y EL AUTOR NO HACEN REPRESENTACIONES NI GARANTÍAS CON RESPECTO A LA EXACTITUD O INTEGRIDAD DEL CONTENIDO DE ESTE DOCUMENTO Y ESPECÍFICAMENTE RENUNCIA DE GARANTÍAS, INCLUYENDO SIN LIMITACIÓN DE GARANTÍA. NINGUNA GARANTÍA PUEDE SER CREADA O AMPLIADA POR VENTAS O MATERIALES PROMOCIONALES. LOS CONSEJOS Y ESTRATEGIAS CONTENIDOS EN ESTE DOCUMENTO PUEDEN NO SER ADECUADOS PARA CADA SITUACIÓN. ESTA OBRA SE VENDE CON EL ENTENDIMIENTO DE QUE EL EDITOR NO ESTÁ ENCARGADO DE PRESTAR SERVICIOS LEGALES, CONTABLES U OTROS SERVICIOS PROFESIONALES. SI SE REQUIERE ASISTENCIA PROFESIONAL, SE DEBERÁN SOLICITAR LOS SERVICIOS DE UNA PERSONA PROFESIONAL COMPETENTE. NI EL EDITOR NI EL AUTOR SERÁN RESPONSABLES DE LOS DAÑOS QUE SURJAN AQUÍ. EL HECHO DE QUE UNA ORGANIZACIÓN O SITIO WEB SE REFIERA EN ESTE TRABAJO COMO UNA CITA Y / O UNA FUENTE POTENCIAL DE INFORMACIÓN ADICIONAL NO SIGNIFICA QUE EL AUTOR O EL EDITOR APRUEBA LA INFORMACIÓN QUE LA ORGANIZACIÓN O EL SITIO WEB PUEDE PROPORCIONAR O RECOMENDARSE. ADEMÁS, LOS LECTORES DEBEN TENER EN CUENTA QUE LOS SITIOS WEB DE INTERNET INCLUIDOS EN ESTE TRABAJO PUEDEN HABER CAMBIADO O DESAPARECER ENTRE CUANDO ESTE TRABAJO FUE ESCRITO Y CUANDO SE LEE.

Para obtener información general sobre nuestros otros productos y servicios, comuníquese con nuestro Departamento de Atención al Cliente dentro de los EE. UU. Al 877-762-2974, fuera de los EE. UU. Al 317-572-3993, o envíe un fax al 317-572-4002. Para obtener soporte técnico, visite

https://hub.wiley.com/community/support/dummies. Wiley publica en una variedad de formatos impresos y electrónicos y por impresión bajo demanda. Es posible que parte del material incluido con las versiones impresas estándar de este libro no se incluya en los libros electrónicos o en la impresión bajo demanda. Si este libro hace referencia a medios como un CD o DVD que no está incluido en la versión que compró, puede descargar este material en

http://booksupport.wiley.com. Para obtener más información sobre los productos Wiley, visite www.wiley.com. Número de control de la Biblioteca del Congreso: 2017948508

ISBN 978-1-119-40569-6 (pbk); ISBN 978-1-119-40574-0 (ebk); ISBN 978-1-119-40573-3 (ebk) Fabricado en los Estados Unidos de América 10 9 8 7 6 5 4 3 2 1

Contenido de un vistazo . . . . . . . . . . . . . . . . . . . . . . .. 1

Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Parte 1: Comprensión de Agile. . . . . . . . . . . . . CAPÍTULO 1:

Modernización de la gestión de proyectos. . . . . . . .

CAPITULO 2:

Aplicación del Manifiesto ágil y los principios Por

CAPÍTULO 3:

qué ser ágil funciona mejor. . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .. 5 . . . . . . . . . . . . . . . . . . . . . . .. 7 . . . . . . . . . . . . . . . . . . . . . . .17 . . . . . . . . . . . . . . . . . . . . . . .43

Parte 2: Ser ágil. . . . . . . . . . . . . . . . . . . . . . . . . CAPÍTULO 4:

Enfoques ágiles. . . . . . . . . . . . . . . . . . . . . . . Entornos

CAPÍTULO 5:

ágiles en acción. . . . . . . . . . . . . Comportamientos

CAPÍTULO 6:

ágiles en acción. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .63 . . . . . . . . . . . . . . . . . . . . . . .sesenta y cinco . . . . . . . . . . . . . . . . . . . . . . .81 . . . . . . . . . . . . . . . . . . . . . . .93

Parte 3: Planificación y ejecución ágiles. . . . . . . . . . . . . . . . . . . . . . . . . 115 CAPÍTULO 7: Definición

de la visión del producto y la hoja de ruta del producto.

CAPÍTULO 8: Planificación

de lanzamientos y sprints. . . . . . . . . . . . . . . . . . .

CAPÍTULO 9: Trabajando CAPÍTULO 10: Exhibiendo

durante todo el día. . . . . . . . . . . . . . . . . . . .

el trabajo, inspeccionando y adaptando. . . . . . .

CAPÍTULO 11: Preparándose

para el lanzamiento. . . . . . . . . . . . . . . . . . . . . . . . . . .

Parte 4: Gestión ágil. . . . . . . . . . . . . . .

.......

CAPITULO 12: Gestión

.......

del alcance y las adquisiciones. . . . . . . .

CAPITULO 13: Gestión

de tiempo y coste. . . . . . . . . . . . . . . . .

CAPITULO 14: Gestión

de la dinámica de equipo y la comunicación

CAPITULO 15: Gestión

de la calidad y el riesgo. . . . . . . . . . . . . . . . . .

Parte 5: Garantizar el éxito ágil

..............

CAPITULO 16: Construyendo

una Fundación. . . . . . . .

..............

a través de equipos ágiles. . . .

..............

CAPITULO 17: Escalando

Ser un agente de cambio. . . . . . . .

..............

Parte 6: La parte de los diez. . . . . . . .

..............

CAPITULO 18:

CAPITULO 19: Diez CAPITULO 20: Diez

beneficios clave de Agile Project

.......

Gestión .

factores clave para el éxito de un proyecto. . . . . . . . . .

CAPITULO 21: Diez

métricas para organizaciones ágiles. . . . . . . . . . .

CAPITULO 22: Diez

recursos valiosos para profesionales ágiles

Índice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

...

. . . . . . . . . . . . . .. 117 . . . . . . . . . . . . . .. 139 . . . . . . . . . . . . . .. 163 . . . . . . . . . . . . . .. 181 . . . . . . . . . . . . . .. 193 . . . . . . . . . . . . . .. 203 . . . . . . . . . . . . . .. 205 . . . . . . . . . . . . . .. 225 . . . . . . . . . . . . . .. 245

.. . . . . . . . . . . . . . . . .. 269 .. . . . . . . . . . . . . . . . .. 295 .. . . . . . . . . . . . . . . . .. 297 .. . . . . . . . . . . . . . . . .. 311 .. . . . . . . . . . . . . . . . .. 343 .. . . . . . . . . . . . . . . . .. 367 .. . . .. . . .. . . .. . .

. . . . . . . . . . . . . .. 369 . . . . . . . . . . . . . .. 377 . . . . . . . . . . . . . .. 383 . . . . . . . . . . . . . .. 395

.. . . . . . . . . . . . . . . . .. 401

Tabla de contenido INTRODUCCIÓN . . . . . . . . . . . . . . Sobre este libro . . . . . . . . . . . Supuestos tontos. . . . . . . Iconos utilizados en este libro. . . . Más allá del libro. . . . . . . . . . A dónde ir desde aquí . . . .

.. . . . . . . . . . . . . . . . . . . . . . . . .

. .. . . . . . . . . 1

.. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .

. .. . . . . . . . . 1 . .. . . . . . . . . 1 . .. . . . . . . . . 2 . .. . . . . . . . . 2 . .. . . . . . . . . 3

PARTE 1: ENTENDIENDO ÁGIL . . . . . . . . . . . . . . . . . . . CAPÍTULO 1:

. .. . . . . . . . . 5

Modernización de la gestión de proyectos. . . . . . . . . . . . . . . . . . . . 7 La gestión de proyectos necesitaba un cambio de imagen. . . . . . . . . . . . . . . . . . . . . . . . 7 Los orígenes de la gestión de proyectos moderna. . . . . . . . . . . . . . . . . . . 8 El problema del statu quo. . . . . . . . . . . . . . . . . . . . . . . . . . . .10 Introducción a la gestión ágil de proyectos. . . . . . . . . . . . . . . . . . . . . . . . . .11 Cómo funcionan los proyectos ágiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13 Por qué los proyectos ágiles funcionan mejor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

CAPITULO 2:

Aplicación del Manifiesto Agile y los Principios. . . . . . . 17 Comprensión del Manifiesto Ágil. . . . . . . . . . . . . . . . . . . . . . . Resumiendo los cuatro valores del Manifiesto Ágil. . . . . . . . . . . . Valor 1: Individuos e interacciones sobre procesos

y herramientas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . .. 17 . . . . .. 20 . . . . .. 20

Valor 2: software de trabajo sobre documentación completa. .................................... . . . . .. 22

. . . . .. 24 . . . . .. 25 Definición de los 12 principios ágiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 26 Principios ágiles de satisfacción del cliente. . . . . . . . . . . . . . . . . . . . .. 27 Principios ágiles de calidad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 30 Principios ágiles del trabajo en equipo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 31 . Principios ágiles de gestión de proyectos. . . . . . . . . . . . . . . . . . . . .. 33 Adición de los principios de platino. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 37 Resistir la formalidad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 37 Pensar y actuar en equipo. . . . . . . . . . . . . . . . . . . . . . . . . Visualizar . . . . .. 38 en lugar de escribir. . . . . . . . . . . . . . . . . . . . . . . . . Cambios como . . . . .. 38 resultado de valores ágiles. . . . . . . . . . . . . . . . . . . . . . . La prueba . . . . .. 41 ágil del tornasol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 41 Valor 3: Colaboración con el cliente sobre la negociación del contrato

Valor 4: Responder al cambio en lugar de seguir un plan. . . . .

Tabla de contenido

CAPÍTULO 3:

Por qué ser AgileWorks mejor. . . . . . . . . . . . . .

.. . . . . . . . . 43

. . . . . . .. . . . . . . . . 43 Cómo los enfoques ágiles superan a los históricos Enfoques . . . . . . .. . . . . . . . . 48 Mayor flexibilidad y estabilidad. . . . Reducción . . . . . . . . . . . . . . . . . .. . . . . . . . . 49 de tareas improductivas. . . . Mayor calidad, ........... . . . . . . .. . . . . . . . . 51 entregado más rápido. . . Mejor rendimiento ........... . . . . . . .. . . . . . . . . 53 del equipo. . . . Control más estricto del ........... . . . . . . .. . . . . . . . . 54 proyecto. . . . . . . . . . Fallo más rápido y menos . . . . . . . . . . . . . . . . . .. . . . . . . . . 56 costoso. . . . . Por qué a la gente le gusta ser ........... . . . . . . .. . . . . . . . . 57 ágil. . . . . . . . ........... . . . . . . .. . . . . . . . . 57 Ejecutivos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 58 Desarrollo de productos y clientes. . . . . . . . . . . . . . .. . . . . . . . . 59 Gestión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Equipos . . . . . . .. . . . . . . . . 60 de desarrollo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 61

Evaluación de los beneficios ágiles. . . . . . . . . . .

PARTE 2: SER ÁGIL . . . . . . . . . CAPÍTULO 4:

Enfoques ágiles. . . . .

...........

.....................

. . . . .. . . . . . . . . 63

.....................

. . . . .. . . . . . . .cinco . sesenta y

Bucear bajo el paraguas de los enfoques ágiles. . . . Revisión de los tres grandes: Lean, Scrum y Programación extrema . . . . . . . . . . . . . . . . . . . . . . . . . . Una descripción general de lean. . . . . . . . . . . . . . . . . . . . . . . . . . Una descripción general de scrum. . . . . . . . . . . . . . . . . . . . . . . . Una descripción general de la programación extrema. . . . . . . . . Poniendolo todo junto . . . . . . . . . . . . . . . . . . . . . . . . . . . CAPÍTULO 5:

Entornos ágiles en acción. . . . . . . . . . . .

. . . . .. . . . . . . .cinco . sesenta y . . . . .. . . . . . . . . 69 . . . . .. . . . . . . . . 69 . . . . .. . . . . . . . . 73 . . . . .. . . . . . . . . 76 . . . . .. . . . . . . . . 80 . . . . .. . . . . . . . . 81

. . . . . . . . . . . . . . . . . . . .. . . . . . . . . 82 Colocando el equipo. . . . . . . . . . Configuración . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 82 de un área dedicada. . . . Eliminando . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 83 distracciones. . . . . . . . Pasando al móvil. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 84 . . . . . . Comunicación de baja tecnología. . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 85 Comunicación de alta tecnología. . . . . . . . Elección . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 86 de herramientas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 88 . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 90 El propósito de la herramienta. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 90 Restricciones organizativas y de compatibilidad . . . . . . . . .. . . . . . . . . 90

Creación del entorno físico.

CAPÍTULO 6:

Comportamientos ágiles en acción. . . . . . . . . . . . . . . . .

. . . . .. . . . . . . . . 93

. . . . .. . . . . . . . . 93 Dueño del producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 94 Miembro del equipo de desarrollo. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 97 Scrummaster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Partes . . . . .. . . . . . . . . 98 interesadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . 100 Mentor ágil. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . 102

Establecimiento de roles ágiles. . . . . . . . . . . . . . . . . . . . . . . . .

Gestión ágil de proyectos para principiantes

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 102 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 103 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 103 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 104 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 105 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 106 Cambiando la filosofía del equipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 107 Equipo dedicado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 107 Funcionalidad cruzada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 108 . Autoorganización. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 110 Autogestión . . . . . Equipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 111 de tamaño limitado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 112 Propiedad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 113

Estableciendo nuevos valores.

Compromiso . . . . . . . Coraje . . . . . . . . . . . . Enfocar . . . . . . . . . . . . . . Apertura. . . . . . . . . . Respeto . . . . . . . . . . . .

PARTE 3: PLANIFICACIÓN Y EJECUCIÓN ÁGIL . . . . . . . . . . . . . . . 115 CAPÍTULO 7:

Definición de la visión del producto y Hoja de ruta del producto. . . . . . . . . . . . . . . . . . . . . . . .

.. . . . . . . . 117

Planificación ágil. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.. . . . . . . . 118 .. . . . . . . . 120 .. . . . . . . . 120 .. . . . . . . . 121 .. . . . . . . . 122 .. . . . . . . . 123 .. . . . . . . . 125 .. . . . . . . . 126 .. . . . . . . . 126 .. . . . . . . . 127 .. . . . . . . . 128 .. . . . . . . . 130 .. . . . . . . . 131 .. . . . . . . . 135 .. . . . . . . . 135 .. . . . . . . . 135

Elaboración progresiva . . . . . . . . . . . . . . . . . . . . . . . . . . Inspeccione y adapte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Definición de la visión del producto. . . . . . . . . . . . . . . . . . . . . . . . . .

Paso 1: desarrollo del objetivo del producto. . . . . . . . . . . Paso 2: Crear un borrador de declaración de visión. . . . . . . . . . . . Paso 3: Validar y revisar la declaración de visión. . Paso 4: Finalización de la declaración de visión. . . . . . . . . . . . . . Creación de una hoja de ruta de productos. . . . . . . . . . . . . . . . . . . . . . . . Paso 1: identificación de las partes interesadas. . . . . . . . . . . . . . . . . . . Paso 2: establecer los requisitos del producto. . . . . . . . . . Paso 3: Organización de las características del producto. . . . . . . . . . . . . . . . Paso 4: Estimación de los esfuerzos y requisitos de pedido Paso 5: Determinación de los plazos de alto nivel. . . . . . . . . Guardando tu trabajo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Completar el Backlog del producto. . . . . . . . . . . . . . . . . . . . . . CAPÍTULO 8:

Planificación de lanzamientos y sprints. . . . . . . . . . . . . . . . . . . . . . . 139 Requisitos y estimaciones de refinamiento. . . . . . . . . . . . . . . . . . . . . . . . . .139 ¿Qué es una historia de usuario? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140 Pasos para crear una historia de usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142 Desglose de requisitos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146 Póquer de estimación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148 Estimación de afinidad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .150

Tabla de contenido

vii

. . . . . . . . . . .. . 152 . . . . . . . . . . .. . 155 La acumulación de sprints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 156 La reunión de planificación del sprint. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 157

Planificación de lanzamiento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Planificación de Sprint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CAPÍTULO 9:

Trabajando durante todo el día. . . . . . . . . . . .

. . . . . . . . . . .. . 163

. . . . . . . . . . . . . . . . . . . . . . . . .. . 163 . . . . . . . . . . . . . . . . . . . . . . . . . .. . 166 La acumulación de sprints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 166 . El tablero de tareas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 170 Roles ágiles en el Sprint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 172 Creación de funcionalidad de envío. . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 174 Elaborando. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 174 Desarrollando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 175 Verificando. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 176 Identificación de obstáculos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 178 El final del dia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 179

Planificación de su día: el progreso de

seguimiento diario de Scrum. . . . . . . . . . . . . . .

CAPÍTULO 10:

Exhibición del trabajo, inspección y adaptación. . . . . . 181 . . . . . . . . . . . .. 181 . . . . . . . . . . . .. 182 reunión de revisión del sprint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 183 Recopilación de comentarios en la reunión de revisión del . . . . . . . . . . . .. 186 sprint. La retrospectiva del Sprint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 187 Planificación de retrospectivas de sprint. . . . . . . . . . . . . . . . . . . . . . . . .. 189 . La reunión retrospectiva de sprint. . . . . . . . . . . . . . . . . . . . . . . . . .. 189 Inspeccionando y adaptando. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 191

La revisión de Sprint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Preparándose para demostrar. . . . . . . . . . . . . . . . . . . . La

CAPÍTULO 11:

Preparándose para el lanzamiento. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .. . 193

Preparación del producto para la implementación: el Sprint de lanzamiento. Preparación para el apoyo operativo. . . . . . . . . . . . . . . . . . . . . . Preparación de la organización para la implementación de productos. . . . . . Preparación del mercado para la implementación de productos. . . . . . .

PARTE 4: GESTIÓN ÁGIL . . . . . . . . . . . . . . . . . . . . . . . . . CAPITULO 12:

. . . . .. . 193 . . . . .. . 197 . . . . .. . 199 . . . . .. . 200 . . . . .. . 203

Gestión del alcance y las adquisiciones. . . . . . . . . . . . . . . . . . 205 . . . . . . . . . . . . . .. 206 . . . . . . . . . . . . . .. 208 Comprensión del alcance a lo largo del proyecto. . . . . . . . . . . . . . .. 208 Introduciendo cambios de alcance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 211 Gestión de cambios de alcance. . . . . . . . . . . . . . . . . . . Uso . . . . . . . . . . . . . .. 211 de artefactos ágiles para la gestión del alcance. . . ¿En . . . . . . . . . . . . . .. 213 qué se diferencian las adquisiciones ágiles? . . . . . . . . . . . . . . . . . . . .. 214

¿Qué tiene de diferente la gestión ágil del alcance? Gestión de Ágil Ámbito. . . . . . . . . . . . . . . . . . . . . . . . .

viii

Gestión ágil de proyectos para principiantes

. . .. 216 . . .. 216 . Comprender los enfoques de costos y los contratos para servicios. . . .. 218 las consideraciones organizativas para las adquisiciones. . . . . . . . . . . . .. 221 Trabajando con un proveedor. . . . . . . . . . . . . . . . . . . . . . . . ........ . . .. 223 Cerrar un contrato. . . . . . . . . . . . . . . . . . . . . . . . . . . . ........ . . .. 224

Gestión de adquisiciones ágiles. . . . . . . . . . . . . . . . . . . . .

........

Determinar la necesidad y seleccionar un proveedor. . . . . . . . . . . . . . .

CAPITULO 13:

Gestión de tiempo y coste. . . . . . . . . . . . . . . . .

.. . . . . . . .

. .. . 225

.. . . . . . . . .. . . . . . . . .. . . . . . . . Introduciendo la velocidad. . . . . . . . . . . . . . . . . . . . . . . . . . Monitoreo y ajuste de velocidad. . . . . . . . . . . . . . Gestión de .. . . . . . . .

. .. . 225 . .. . 227 . .. . 228 . .. . 229 . .. . 234 . .. . 235 . .. . 236 . .. . 237 . .. . 238 . .. . 239 . .. . 240 . .. . 242 . .. . 244

¿Qué tiene de diferente la gestión ágil del tiempo? . . . Gestión de horarios ágiles. . . . . . . . . . . . . . . . . . . . . . .

cambios de alcance desde una perspectiva temporal Gestión . . . . . . . . del tiempo mediante el uso de varios equipos. . . . . . . .

.. . . . . . . .

Utilizando artefactos ágiles para la gestión del tiempo. . . . . . .. . . . . . . . ¿Qué tiene de diferente la gestión ágil de costes? . . . . Gestión de presupuestos ágiles. . . . . . . . . . . . . . . . . . . . . . . . . Elaboración de un presupuesto inicial. . . . . . . . . . . . . . . . . . . . . Creación de un proyecto autofinanciado. . . . . . . . . . . . . . . . Usar la velocidad para determinar los costos a largo plazo. . . . Utilizando artefactos ágiles para la gestión de costes. . . . . . CAPITULO 14:

.. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . .

Gestión de TeamDynamics y comunicación . . . . . . . . . . . . . . . . . . . . . . . . . .

. .. . . . . . . 245

. .. . . . . . . 245 Gestión de la dinámica de equipo ágil. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 247 Convertirse en autogestionario y autoorganizado. . . . . . . . . .. . . . . . . 248 Apoyando al equipo: El líder-servidor. . . . . . . . . . . Trabajando . .. . . . . . . 252 con un equipo dedicado. . . . . . . . . . . . . . . . . . . . Trabajando . .. . . . . . . 254 con un equipo multifuncional. . . . . . . . . . . . . . Reforzando la . .. . . . . . . 255 . .. . . . . . . 257 apertura. . . . . . . . . . . . . . . . . . . . . . . . . . . . Limitar el tamaño del equipo de desarrollo. . . . . . . . . . . . . . . . . . . Gestión de . .. . . . . . . 258 proyectos con equipos dislocados. . . . . . . . . . . ¿Qué tiene de . .. . . . . . . 259 diferente la comunicación ágil? . . . . . . . . . . Gestión de la . .. . . . . . . 262 comunicación ágil. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 263 Comprender los métodos de comunicación ágiles. . . . . . . .. . . . . . . 263 Informes de estado y progreso. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 266 ¿Qué tiene de diferente la dinámica de equipo ágil? . . . . . . . . . .

CAPITULO 15:

Gestión de la calidad y el riesgo. . . . . . . . . . . . . . ¿Qué tiene de diferente la calidad ágil? . . . . . . . . . . . . . . Gestión de la calidad ágil. . . . . . . . . . . . . . . . . . . . . . . . . . Calidad y sprint. . . . . . . . . . . . . . . . . . . . . . . . Calidad proactiva. . . . . . . . . . . . . . . . . . . . . . . . . . . . Calidad mediante inspecciones y adaptaciones periódicas. Pruebas automatizadas. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . .. . . . . . . 269 . . . . . .. . . . . . . 269 . . . . . .. . . . . . . 272 . . . . . .. . . . . . . 273 . . . . . .. . . . . . . 275 . . . . . .. . . . . . . 280 . . . . . .. . . . . . . 281

Tabla de contenido

Identificar, priorizar y responder a los riesgos de manera temprana.

. . . . . . .. . 283 . . . . . . .. . 286 . . . . . . .. . 286 . . . . . . .. . 291

PARTE 5: GARANTIZAR EL ÉXITO ÁGIL . . . . . . . . . . . . . . . . .

. . . . . . .. . 295

¿Qué tiene de diferente la gestión ágil de riesgos? . . . . . . . . Gestión de riesgos ágiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reducir el riesgo de forma inherente. . . . . . . . . . . . . . . . . . . . . . . . . .

CAPITULO 16:

Construyendo una Fundación. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . .. . 297

Compromiso organizacional e individual. . . . . . . . . . . .

. . . . . . .. . 297 . . . . . . .. . 298 . . . . . . .. . 299 . . . . . . .. . 299 . . . . . . .. . 300 . . . . . . .. . 302 . . . . . . .. . 302 . . . . . . .. . 302 . . . . . . .. . 303 . . . . . . .. . 304 . . . . . . .. . 305 . . . . . . .. . 305 . . . . . . .. . 306 . . . . . . .. . 307 . . . . . . .. . 307 . . . . . . .. . 310

Compromiso organizacional . . . . . . . . . . . . . . . . . . . . . . Compromiso individual. . . . . . . . . . . . . . . . . . . . . . . . . . Conseguir compromiso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . ¿Puedes hacer la transición? . . . . . . . . . . . . . . . . . . . . . Programando la transición. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Elección de los miembros del equipo piloto adecuados. . . . . . . . . . . . . . El campeón ágil. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . El ágil equipo de transición. . . . . . . . . . . . . . . . . . . . . . . . . El propietario del producto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . El equipo de desarrollo. . . . . . . . . . . . . . . . . . . . . . . . . . El scrummaster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Los interesados del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . El mentor ágil. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creación de un entorno que posibilite la agilidad. . . . . . . . . . Apoye la agilidad inicialmente y a lo largo del tiempo. . . . . . . . . . . . . . . . .

CAPITULO 17:

Escalando a través de equipos ágiles. . . . . . . . . . . . . . .

. . . . . . . . . . .. . 311

. . . . . . . . . . . . . . .. . 312 Hacer que el trabajo sea digerible mediante el corte vertical . . . . . . . . . . . . . . .. . 314 Scrum de scrums. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 315 Alineación a través de roles con Scrum a escala. . . . . . . . . . . . . . . . . . .. . 318 Escalando el scrummaster. . . . . . . . . . . . . . . . . Escalando el . . . . . . . . . . . . . . .. . 319 propietario del producto. . . . . . . . . . . . . . . . Sincronizando en . . . . . . . . . . . . . . .. . 320 una hora al día. . . . . . . . . . . Coordinación de equipos múltiples . . . . . . . . . . . . . . .. . 322 con LeSS. . . . . . . . . . . . . . . . . . . . . . . . . .. . 323 LeSS, el marco más pequeño. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 323 Menos marco enorme. . . . . . . . . . . . . . . . . . . . Bazar . . . . . . . . . . . . . . .. . 324 de revisión de Sprint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 325 . . . . . . . . . . . . . . .. . 326 Observadores en el scrum diario. . . . . . . . . . . . . . Comunidades componentes y mentores. . . . . . . . . . . . . . . . . . . .. . 326 Reuniones de varios equipos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 327 . . Viajeros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 327 Reducir las dependencias con Nexus. . . . . . . . . . . . . . . . . . . . . . . . .. . 327 Rol de Nexus: equipo de integración de Nexus. . . . . . . . . . . . . . . . . .. . 328 . . . Artefactos Nexus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 330 Eventos Nexus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 330 Proyectos ágiles de equipos múltiples. . . . . . . . . . . . . . . . . . . .

Gestión ágil de proyectos para principiantes

Planificación de programas conjuntos con SAFe. . . . . . . . Comprensión de los cuatro niveles de SAFe. . . Planificación del incremento del programa conjunto. . . . Claridad para los gerentes. . . . . . . . . . . . . . . . Estructuras modulares con Enterprise Scrum

ES Generalizaciones de elementos scrum. . . ES actividades clave. . . . . . . . . . . . . . . . . . . . CAPITULO 18:

. . . . . . . . . . . . . . . . . . . . .. 332 . . . . . . . . . . . . . . . . . . . . .. 333 . . . . . . . . . . . . . . . . . . . . .. 336 . . . . . . . . . . . . . . . . . . . . .. 337 . . . . . . . . . . . . . . . . . . . . .. 337 . . . . . . . . . . . . . . . . . . . . .. 337 . . . . . . . . . . . . . . . . . . . . .. 338

Ser un agente de cambio. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .. . 343

Ser ágil requiere cambios. . . . . . . . . . . . . . . . . Por qué el . . . . . . . . . . .. . 343 cambio no ocurre por sí solo. . . . . . . . . . Enfoques . . . . . . . . . . .. . 344 estratégicos para la implementación y la gestión Cambio . . .. . 345 Lewin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Los cinco

.......

pasos de ADKAR para cambiar. . . . . . . . . . . . . . . . . . . Los ocho

.......

pasos de Kotter para liderar el cambio. . . . . . . . . . Hoja de

.......

ruta del cambio de Platinum Edge. . . . . . . . . . . . . . . . .

.......

Paso 1: Lleve a cabo una estrategia de implementación con métricas de éxito. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.......

Paso 2: generar conciencia y entusiasmo. . . . . . . . .

.......

Paso 3: Forme un equipo de transformación y identificar un proyecto piloto. . . . . . . . . . . . . . . . . . . . . . . . .

.......

Paso 4: Construya un entorno para el éxito. . . . . . . . Paso 5:

.......

capacite lo suficiente y reclute según sea necesario. . . Paso

.......

6: Comience el piloto con entrenamiento activo. . . . . Paso

.......

7: ejecutar la hoja de ruta para generar valor. . . . . . . . . .

.......

Paso 8: recopile comentarios y mejore. . . . . . . . . . . Paso 9:

.......

Madure y solidifique las mejoras. . . . . . .

.......

Paso 10: Expandirse progresivamente dentro de la organización. . . . Evitando trampas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Señales de que sus cambios se están desvaneciendo. . . . . . . . . . . . . . . . . . . . . . . . . .

PARTE 6: LA PARTE DE DIEZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CAPITULO 19:

. . .. . 345 . . .. . 346 . . .. . 348 . . .. . 349 . . .. . 349 . . .. . 352

. . .. . 353 . . .. . 355 . . .. . 355 . . .. . 356 . . .. . 357 . . .. . 357 . . .. . 358 . . .. . 359 . . .. . 360 . . .. . 363 . .. . 367

Diez beneficios clave de la gestión ágil de proyectos. . . 369 Mejor calidad de producto. . . . . . . . . . . . . . . Mayor satisfacción del cliente. . . . . . . . . Riesgo reducido. . . . . . . . . . . . . . . . . . . . . . . Mayor colaboración y propiedad Métricas más relevantes. . . . . . . . . . . . . . . Visibilidad de rendimiento mejorada. . . . . . . Mayor control de proyectos. . . . . . . . . . . . . Previsibilidad mejorada del proyecto. . . . . . . . Estructuras de equipo personalizadas. . . . . . . . . Equipo superiorMorale. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .. 369 . . . . . . . . . . . . . . . . . . . . . . .. 370 . . . . . . . . . . . . . . . . . . . . . . .. 371 . . . . . . . . . . . . . . . . . . . . . . .. 371 . . . . . . . . . . . . . . . . . . . . . . .. 372 . . . . . . . . . . . . . . . . . . . . . . .. 373 . . . . . . . . . . . . . . . . . . . . . . .. 374 . . . . . . . . . . . . . . . . . . . . . . .. 374 . . . . . . . . . . . . . . . . . . . . . . .. 375 . . . . . . . . . . . . . . . . . . . . . . .. 376

Tabla de contenido

CAPITULO 20:

Diez factores clave para el éxito de un proyecto. . . . . . . . . . . . . . . . . 377 Miembros de equipo dedicados. . . . . . . . Colocación. . . . . . . . . . . . . . . . . . . . . Pruebas automatizadas. . . . . . . . . . . . . . Definición obligatoria de terminado. . . . . . Visión clara del producto y empoderamiento del propietario del producto. . . . Versatilidad del desarrollador. . . . . . . . . . . . . ScrumMaster Clout. . . . . . . . . . . . . Soporte de gestión para el soporte de transición del aprendizaje. . . . . . . . . . . . . .

CAPITULO 21:

. . . . . . . . . . . . . . . . . . . . . . . . . . .. 377 . . . . . . . . . . . . . . . . . . . . . . . . . . .. 378 . . . . . . . . . . . . . . . . . . . . . . . . . . .. 378 . . . . . . . . . . . . . . . . . . . . . . . . . . .. 378 . . . . . . . . . . . . . . . . . . . . . . . . . . .. 379 . . . . . . . . . . . . . . . . . . . . . . . . . . .. 380 . . . . . . . . . . . . . . . . . . . . . . . . . . .. 380 . . . . . . . . . . . . . . . . . . . . . . . . . . .. 380 . . . . . . . . . . . . . . . . . . . . . . . . . . .. 381 . . . . . . . . . . . . . . . . . . . . . . . . . . .. 381

TenMetrics para organizaciones ágiles. . . . . . . . . . . . . . . . . 383 Retorno de la inversión . . . . . . . . . . Nuevas solicitudes en los presupuestos de ROI Redistribución de capital. . . . . . . Encuestas de satisfacción. . . . . . . . . . . Defectos en la producción. . . . . . . . . . Tasas de éxito de las metas de Sprint. . . . . . Hora de comprar . . . . . . . . . . . . . . . . Tiempos de ciclo y plomo. . . . . . . . . . Costo del cambio. . . . . . . . . . . . . . . . Rotación de miembros del equipo. . . . . . . Versatilidad de habilidades. . . . . . . . . . . . . . . . Proporción de administrador a creador. . . . . .

CAPITULO 22:

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 383 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 386 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 386 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 387 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 388 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 389 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 389 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 390 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 391 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 391 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 392 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 392

Diez recursos valiosos para profesionales ágiles. . . 395 Gestión ágil de proyectos para tontos Hoja de trucos en línea Scrum para tontos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . La Alianza Scrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . La Alianza Ágil. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Project Management Institute Agile Community. . . . . . . Consorcio Internacional para Agile (ICAgile). . . . . . . . . . . . . . . InfoQ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Instituto Lean Enterprise. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Programación extrema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Platinum Edge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ÍNDICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xii

Gestión ágil de proyectos para principiantes

. . .. . . .

. . . . .. 395 . . . . .. 396 . . . . .. 396 . . . . .. 396 . . . . .. 397 . . . . .. 397 . . . . .. 397 . . . . .. 398 . . . . .. 398 . . . . .. 398 . . . .. . 401

Introducción

El ment ha crecido hasta ser tan común como cualquier técnica de gestión en los negocios de hoy. Durante la última década y media, hemos capacitado y bienvenido a Gestión ágil de proyectos para principiantes. Gestión ágil de proyectos

entrenado a empresas grandes y pequeñas, de todo el mundo, sobre cómo ejecutar proyectos ágiles. A través de este trabajo, descubrimos que era necesario escribir una guía digerible que la persona promedio pudiera comprender y usar. En este libro, aclararemos algunos de los mitos sobre qué es y qué no es la gestión ágil de

proyectos. La información de este libro le dará la confianza para saber que puede tener éxito utilizando técnicas ágiles.

Sobre este libro Gestión ágil de proyectos para principiantes, La segunda edición es más que una simple introducción a prácticas y metodologías ágiles; también descubre los pasos para ejecutar técnicas ágiles en un proyecto. El material aquí va más allá de la teoría y está destinado a ser un manual de campo, accesible para la persona común, que le brinda las herramientas y la información que necesita para tener éxito con procesos ágiles en las trincheras de la gestión de proyectos.

Supuestos tontos Como está leyendo este libro, es posible que tenga una familiaridad pasajera con la gestión de proyectos. Quizás sea un director de proyecto, un miembro de un equipo de proyecto o un interesado en un proyecto. O tal vez no tenga experiencia con enfoques formales de gestión de proyectos, pero está buscando una solución ahora. Es posible que incluso hayas escuchado el término ágil Y quieres saber mas. O puede que ya sea parte de un equipo de proyecto que intenta ser más ágil. Independientemente de su experiencia o nivel de familiaridad, este libro proporciona información que puede resultarle interesante. Por lo menos, esperamos que aclare cualquier confusión o mito con respecto a la gestión ágil de proyectos que pueda haber encontrado.

Introducción

Iconos utilizados en este libro A lo largo de este libro, encontrará los siguientes íconos. Los consejos son puntos que le ayudarán en su viaje ágil de gestión de proyectos. Las sugerencias pueden ahorrarle tiempo y ayudarlo a comprender rápidamente un tema en particular, así que cuando las vea, ¡eche un vistazo!

El icono Recordar es un recordatorio de algo que puede haber visto en capítulos anteriores. También puede ser un recordatorio de un principio de sentido común que se olvida fácilmente. Estos íconos pueden ayudar a refrescar su memoria cuando aparece un término o concepto importante. El icono de advertencia indica que desea estar atento a una determinada acción o comportamiento. ¡Asegúrese de leer estos para evitar grandes problemas!

El icono de Material técnico indica información que es interesante pero no esencial para el texto. Si ve un ícono de Material técnico, no es necesario que lo lea para comprender la gestión ágil de proyectos, pero la información allí puede despertar su interés.

En la Web significa que puede encontrar más información en el sitio web del libro en

www.dummies.com/go/agileprojectmanagementfd2e.

Más allá del libro Aunque este libro cubre ampliamente el espectro de la gestión ágil de proyectos, ¡solo podemos cubrir una parte determinada en un número determinado de páginas! Si al final de este libro se encuentra pensando: “¡Este fue un libro increíble! ¿Dónde puedo aprender más sobre cómo hacer avanzar mis proyectos bajo un enfoque ágil? " consulte el Capítulo 22 o diríjase a www.dummies.com para obtener más recursos. Proporcionamos una hoja de trucos para obtener consejos sobre cómo evaluar sus proyectos actuales en relación con los principios ágiles y las herramientas gratuitas para gestionar proyectos utilizando técnicas ágiles. Para acceder a la hoja de referencia, vaya a www.dummies.com, y luego escribe Hoja de referencia

de gestión ágil de proyectos para principiantes en el cuadro de búsqueda. Aquí también encontrará las actualizaciones o cambios importantes que se produzcan entre las ediciones de este libro.

Gestión ágil de proyectos para principiantes

A dónde ir desde aquí Escribimos este libro para que puedas leerlo en casi cualquier orden. Dependiendo de su función, es posible que desee prestar más atención a las secciones correspondientes del libro. Por ejemplo:

» Si recién está comenzando a aprender sobre gestión de proyectos y agile enfoques, comience con el Capítulo 1 y lea el libro directamente hasta el final.

» Si es miembro de un equipo de proyecto y desea conocer los conceptos básicos de cómo para trabajar en un proyecto ágil, consulte la información en la Parte 3 (Capítulos 7

al 11).

» Si es un director de proyecto y se pregunta cómo afectan los enfoques ágiles su trabajo, revise la Parte 4 (Capítulos 12 al 15).

» Si conoce los conceptos básicos de la gestión ágil de proyectos y está considerando llevar prácticas ágiles a su empresa o escalar prácticas ágiles en

su organización, la Parte 5 (Capítulos 16 al 18) le proporciona información útil.

Introducción

Comprensión

Ágil

EN ESTA PARTE . . .

Comprender por qué la gestión de proyectos debe modernizarse debido a las fallas y debilidades en los enfoques históricos de la gestión de proyectos.

Descubra por qué los métodos ágiles están creciendo como una alternativa a la gestión de proyectos tradicional y familiarícese con la base de la gestión ágil de proyectos: el Manifiesto Ágil y los 12 Principios Ágiles.

Descubra las ventajas que sus productos, proyectos, equipos, clientes y organización pueden obtener al adoptar técnicas y procesos de gestión de proyectos ágiles.

EN ESTE CAPÍTULO

» Entender por qué proyectar la gerencia necesita cambiar » Descubriendo proyectos ágiles administración

Capítulo

Proyecto de Modernización

Gestión

entrega temprana de valor comercial, mejora continua del producto y los procesos del proyecto, aportes del equipo y entregaque biense centra en gestión deflexibilidad proyectos del ágilalcance, es un estilo de gestión de proyectos

productos probados que reflejan las necesidades del cliente.

En este capítulo, descubrirá por qué los procesos ágiles surgieron como un enfoque para la gestión de proyectos de desarrollo de software a mediados de la década de 1990 y por qué las metodologías ágiles han llamado la atención de los gerentes de proyectos, los clientes que invierten en el desarrollo de nuevo software y los ejecutivos cuyas empresas financiar los departamentos de desarrollo de software. Este capítulo también explica las ventajas de las metodologías ágiles sobre los enfoques tradicionales de la gestión de proyectos.

La gestión del proyecto necesita un cambio de imagen A proyecto es un programa de trabajo planificado que requiere una cantidad definitiva de tiempo, esfuerzo y planificación para completarse. Los proyectos tienen metas y objetivos y, a menudo, deben completarse en un período de tiempo fijo y dentro de un presupuesto determinado.

CAPÍTULO 1 Modernización de la gestión de proyectos

Debido a que está leyendo este libro, es probable que sea un gerente de proyecto o alguien que inicia proyectos, trabaja en proyectos o se ve afectado por proyectos de alguna manera.

Los enfoques ágiles son una respuesta a la necesidad de modernizar la gestión de proyectos. Para comprender cómo los enfoques ágiles están revolucionando los proyectos, es útil saber un poco sobre la historia y el propósito de la gestión de proyectos y los problemas que enfrentan los proyectos en la actualidad.

Los orígenes de la gestión de proyectos moderna Los proyectos han existido desde la antigüedad. Desde la Gran Muralla China hasta las pirámides mayas en Tikal, desde la invención de la imprenta hasta la invención de Internet, la gente ha logrado grandes y pequeños esfuerzos en proyectos. Como disciplina formal, la gestión de proyectos tal como la conocemos solo existe desde mediados del siglo XX. Alrededor de la época de la Segunda Guerra Mundial, los investigadores de todo el mundo estaban logrando importantes avances en la construcción y programación de computadoras, principalmente para el ejército de los Estados Unidos. Para completar esos proyectos, comenzaron a crear procesos formales de gestión de proyectos. Los primeros procesos se basaron en modelos de fabricación paso a paso que el ejército de los Estados Unidos utilizó durante la Segunda Guerra Mundial. La gente en el campo de la computación adoptó estos procesos de fabricación basados en pasos porque los primeros proyectos relacionados con la computadora dependían en gran medida del hardware, con computadoras que llenaban salas enteras. El software, por el contrario, era una parte más pequeña de los proyectos informáticos. En las décadas de 1940 y 1950, las computadoras podían tener miles de tubos de vacío físicos pero menos de 30 líneas de código de programación. El proceso de fabricación de la década de 1940 utilizado en estas computadoras iniciales es la base de la metodología de gestión de proyectos conocida como cascada.

En 1970, un científico informático llamado Winston Royce escribió "Gestión del desarrollo de grandes sistemas de software", un artículo para el IEEE que describía las fases de la metodología en cascada. El termino cascada fue acuñado más tarde, pero las fases, incluso si a veces se titulan de manera diferente, son esencialmente las mismas que las definió originalmente Royce:

PARTE 1 Entendiendo Agile

1. Requisitos 2. Diseño 3. Desarrollo 4. Integración 5. Prueba 6. Despliegue En los proyectos de cascada, pasa a la siguiente fase solo cuando la anterior está completa, de ahí el nombre cascada. La gestión de proyectos en cascada pura, completar cada paso en su totalidad antes de pasar al siguiente paso, es en realidad una mala interpretación de las sugerencias de Royce. Royce identificó que este enfoque era intrínsecamente riesgoso y recomendó desarrollar y probar en iteraciones para crear productos, sugerencias que fueron pasadas por alto por muchas organizaciones que adoptaron la metodología en cascada.

ÉXITO Y FRACASO DEL PROYECTO DE SOFTWARE Desafortunadamente, el estancamiento de los enfoques tradicionales de gestión de proyectos se está poniendo al día con la industria del software. En 2015, una empresa de estadísticas de software llamada Standish Group realizó un estudio sobre las tasas de éxito y fracaso de 10.000 proyectos en los EE. UU. Los resultados del estudio mostraron que

•

El 29 por ciento de los proyectos tradicionales fracasaron rotundamente. Los proyectos se cancelaron antes de que finalizaran y no dieron lugar a lanzamientos de productos. Estos proyectos entregaron

sin valor alguno.

•

El 60 por ciento de los proyectos tradicionales fueron desafiados. Los proyectos se completaron, pero tenían brechas entre el costo esperado y real, el tiempo, la calidad o una combinación de estos elementos. La diferencia promedio entre los resultados esperados y reales del proyecto, considerando el tiempo, el costo y las características no entregadas, fue muy superior al 100 por ciento.

•

El 11 por ciento de los proyectos tuvo éxito. Los proyectos se completaron y entregaron el producto esperado en el tiempo y presupuesto previstos originalmente.

De los cientos de miles de millones de dólares gastados en proyectos de desarrollo de aplicaciones solo en los Estados Unidos, miles de millones de dólares se desperdiciaron en proyectos que nunca implementaron una sola pieza de funcionalidad.

CAPÍTULO 1 Modernización de la gestión de proyectos

La metodología en cascada fue el enfoque de gestión de proyectos más común en el desarrollo de software hasta que fue superado por enfoques mejorados basados en técnicas ágiles alrededor de 2008.

El problema con el status quo La tecnología informática, por supuesto, ha cambiado mucho desde el siglo pasado. Muchas personas tienen una computadora en la muñeca con más potencia, memoria y capacidades que la máquina más grande y cara que existía cuando la gente comenzó a usar las metodologías en cascada. Al mismo tiempo, las personas que usan computadoras también han cambiado. En lugar de crear máquinas gigantes con programas mínimos para unos pocos investigadores y militares, la gente crea hardware y software para el público en general. En muchos países, casi todo el mundo usa una computadora, directa o indirectamente, todos los días. El software ejecuta nuestros automóviles, nuestros electrodomésticos, nuestros hogares; proporciona nuestra información diaria y entretenimiento diario. Incluso los niños pequeños usan computadoras: una niña de 2 años es casi más hábil con el iPhone que sus padres. La demanda de productos de software mejores y más nuevos es constante. De alguna manera, durante todo este crecimiento de la tecnología, los procesos no se quedaron atrás. Los desarrolladores de software todavía están utilizando metodologías de gestión de proyectos de la década de 1950, y todos estos enfoques se derivaron de procesos de fabricación destinados a las computadoras con hardware pesado de mediados del siglo XX. Hoy en día, los proyectos tradicionales que tienen éxito a menudo adolecen de un problema: hinchazón del

alcance, la introducción de características de producto innecesarias en un proyecto.

Piense en los productos de software que utiliza todos los días. Por ejemplo, el programa de procesamiento de texto en el que estamos escribiendo ahora tiene muchas funciones y herramientas. Aunque escribimos con este programa todos los días, usamos solo algunas de las funciones todo el tiempo. Usamos otros elementos con menos frecuencia. Y nunca hemos usado bastantes herramientas, y ahora que lo pienso, tampoco conocemos a nadie más que las haya usado. Las características que pocas personas usan son el resultado de la hinchazón del alcance. La hinchazón del alcance aparece en todo tipo de software, desde aplicaciones empresariales complejas hasta sitios web que todo el mundo usa. La Figura 1-1 muestra datos de un estudio de Standish Group que ilustra cuán común es la hinchazón del alcance. En la figura, puede ver que el 64 por ciento de las funciones solicitadas rara vez o nunca se utilizan. Los números de la Figura 1-1 ilustran una enorme pérdida de tiempo y dinero. Ese desperdicio es un resultado directo de los procesos tradicionales de gestión de proyectos que no pueden adaptarse al cambio. Los gerentes de proyecto y las partes interesadas saben que el cambio no es bienvenido a mitad del proyecto, por lo que su mejor oportunidad de obtener una característica potencialmente deseable es al comienzo de un proyecto. Por tanto, piden

PARTE 1 Entendiendo Agile

FIGURA 1-1: Uso real de solicitado software características.

» Todo lo que necesitan » Todo lo que creen que pueden necesitar » Todo lo que ellos quieren

» Todo lo que creen que pueden querer El resultado es la hinchazón en las características que resulta en las estadísticas de la Figura 1-1.

Los problemas asociados con el uso de enfoques de gestión y desarrollo obsoletos no son triviales. Estos problemas desperdician miles de millones de dólares al año. Los miles de millones de dólares perdidos en proyectos fallidos en 2015 (consulte el recuadro “Éxito y fracaso de proyectos de software”) podrían equivaler a millones de puestos de trabajo en todo el mundo.

Durante las últimas dos décadas, las personas que trabajan en proyectos han reconocido los crecientes problemas con la gestión de proyectos tradicional y han estado trabajando para crear un modelo mejor: la gestión ágil de proyectos.

Introducción a la gestión ágil de proyectos Las semillas de las técnicas ágiles existen desde hace mucho tiempo. De hecho, los valores, principios y prácticas ágiles son simplemente una codificación del sentido común. La Figura 1-2 muestra una historia rápida de la gestión ágil de proyectos, que data de la década de 1930 con el enfoque Planificar-Hacer-Estudiar-Actuar (PDSA) de Walter Sherwart para la calidad del proyecto.

CAPÍTULO 1 Modernización de la gestión de proyectos

FIGURA 1-2: Cronograma de gestión ágil de proyectos.

PARTE 1 Entendiendo Agile

En 1986, Hirotaka Takeuchi e Ikujiro Nonaka publicaron un artículo titulado "Nuevo juego de desarrollo de nuevos productos" en el Harvard Business Review. El artículo de Takeuchi y Nonaka describió una estrategia de desarrollo rápida y flexible para satisfacer las demandas de productos de ritmo rápido. Este artículo primero emparejó el término melé con el desarrollo de productos. ( Melé originalmente se refería a la formación de un jugador en rugby.) Scrume eventualmente se convirtió en uno de los marcos de gestión de proyectos ágiles más populares.

En 2001, un grupo de expertos en software y proyectos se reunió para hablar sobre lo que tenían en común sus proyectos exitosos. Este grupo creó el Manifiesto ágil, una declaración de valores para el desarrollo de software exitoso: Manifiesto para el desarrollo ágil de software * Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a otros a hacerlo. A través de este trabajo hemos llegado a valorar:

Individuos e interacciones sobre procesos y herramientas

Software de trabajo sobre documentación completa Colaboración con el cliente sobre la negociación del contrato

Respondiendo al cambio sobre seguir un plan Es decir, si bien hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda. * Manifiesto ágil Copyright © 2001: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas. Esta declaración se puede copiar libremente en cualquier forma, pero solo en su totalidad a través de este aviso.

Estos expertos también crearon el Principios detrás del Manifiesto Agile, 12 prácticas que ayudan a respaldar los valores del Manifiesto Ágil. Enumeramos los Principios Ágiles y describimos el Manifiesto Ágil con más detalle en el Capítulo 2. Agile, en términos de desarrollo de productos, es un descriptor de los enfoques de gestión de proyectos que se centran en las personas, las comunicaciones, el producto y la flexibilidad. Si estas buscando la metodología ágil, no la encontrarás. Sin embargo, todas las metodologías ágiles (por ejemplo, cristal), marcos (por ejemplo, scrum), técnicas (por ejemplo, requisitos de historias de usuario) y herramientas (por ejemplo, estimación relativa) tienen una cosa en común: adherencia al Manifiesto Ágil. y los 12 principios ágiles.

Cómo funcionan los proyectos ágiles Los enfoques ágiles se basan en método de control empírico - un proceso de toma de decisiones basado en las realidades observadas en el proyecto. En el contexto de las metodologías de desarrollo de software, un enfoque empírico puede ser eficaz tanto en nuevas

CAPÍTULO 1 Modernización de la gestión de proyectos

desarrollo de productos y proyectos de mejora y actualización. Mediante la inspección frecuente y de primera mano del trabajo hasta la fecha, puede realizar ajustes inmediatos, si es necesario. El control empírico requiere

» Transparencia sin límites: Todos los involucrados en un proyecto ágil saben qué está sucediendo y cómo avanza el proyecto.

» Inspección frecuente: Las personas que invierten en el producto y proceso evalúa con mayor regularidad el producto y el proceso.

» Adaptación inmediata: Los ajustes se realizan rápidamente para minimizar los problemas;

si una inspección muestra que algo debería cambiar, se cambia inmediatamente.

Para dar cabida a la inspección frecuente y la adaptación inmediata, los proyectos ágiles funcionan en iteraciones segmentos más pequeños del proyecto en general). Un proyecto ágil implica el mismo tipo de trabajo que en un proyecto en cascada tradicional: usted crea requisitos y diseños, desarrolla el producto, lo documenta y, si es necesario, integra el producto con otros productos. Prueba el producto, soluciona cualquier problema y lo implementa para su uso. Sin embargo, en lugar de completar estos pasos para todas las características del producto a la vez, como en un proyecto en cascada, divide el proyecto en iteraciones, también llamadas sprints. La Figura 1-3 muestra la diferencia entre un proyecto de cascada lineal y un proyecto ágil.

Combinar métodos tradicionales de gestión de proyectos con enfoques ágiles es como decir: “Tengo un Porsche 911 Turbo. Sin embargo, estoy usando una rueda de carro en el lado delantero izquierdo. ¿Cómo puedo hacer que mi coche sea tan rápido como los otros Porsche? " La respuesta, por supuesto, es que no puedes. Si se compromete plenamente con un enfoque ágil, tendrá más posibilidades de éxito en el proyecto.

Por qué los proyectos ágiles funcionan mejor A lo largo de este libro, verá cómo los proyectos ágiles funcionan mejor que los proyectos tradicionales. Los enfoques ágiles de gestión de proyectos pueden producir proyectos más exitosos. El estudio de Standish Group, mencionado en la barra lateral "Éxito y fracaso de proyectos de software", encontró que mientras el 29 por ciento de los proyectos tradicionales fracasaron rotundamente, ese número se redujo a sólo el 9 por ciento en proyectos ágiles. La disminución de fallas para proyectos ágiles es el resultado de equipos de proyectos ágiles que realizan adaptaciones inmediatas basadas en inspecciones frecuentes del progreso y la satisfacción del cliente.

PARTE 1 Entendiendo Agile

FIGURA 1-3: Cascada versus proyecto ágil.

CAPÍTULO 1 Modernización de la gestión de proyectos

Estas son algunas áreas clave en las que los enfoques ágiles son superiores a los métodos tradicionales de gestión de proyectos:

» Tasas de éxito del proyecto: En el capítulo 15, descubrirá cómo el riesgo de cataEl fracaso de un proyecto estrófico se reduce a casi nada en proyectos ágiles. Ágil Los enfoques de priorización por valor comercial y riesgo aseguran el éxito o el fracaso temprano. Los enfoques ágiles para las pruebas a lo largo del proyecto ayudan a garantizar que encuentre los problemas temprano, no después de gastar una gran cantidad de tiempo y dinero.

» Fluencia del alcance: En los capítulos 7, 8 y 12, verá cómo se adaptan los enfoques ágiles modifique los cambios a lo largo de un proyecto, minimizando la filtración del alcance. En ágil

proyectos, puede agregar nuevos requisitos al comienzo de cada sprint sin interrumpir el flujo de desarrollo. Al desarrollar primero las funciones priorizadas por completo, se evita que el avance del alcance amenace la funcionalidad crítica.

» Inspección y adaptación: En los capítulos 10 y 14, encontrará detalles de cómo inspecciones periódicas y trabajos de adecuación en proyectos ágiles. Proyecto ágil

Los equipos, armados con comentarios frecuentes de los ciclos de desarrollo completos y la funcionalidad operativa y disponible, pueden mejorar sus procesos y sus productos con cada sprint. A lo largo de muchos capítulos de este libro, descubrirá cómo obtiene el control de los resultados de los proyectos ágiles. Las pruebas tempranas y frecuentes, el ajuste de prioridades según sea necesario, el uso de mejores técnicas de comunicación y la demostración y publicación periódica de la funcionalidad del producto le permiten ajustar su control sobre una amplia variedad de factores en proyectos ágiles.

dieciséis PARTE

1 Entendiendo Agile

EN ESTE CAPÍTULO

» Definición de AgileManifesto y el 12 principios ágiles

» Descripción de los principios de platino

» Entender lo que ha cambiado en gestión de proyectos » Tomando la ágil prueba de fuego

Capítulo

Aplicando el Agile

Manifiesto y principios

Manifiesto, con sus cuatro valores, y los 12 principios ágiles detrás del Manifiesto Ágil.

También ampliamos conceptosbásicos básicosde con adicionales este capítulo describeestos los conceptos lo tres que Platinum significa ser ágil: el ágil Principios, que Platinum Edge (propiedad de Mark) elaboró después de años de experiencia. ence apoyo a las transiciones ágiles de las organizaciones.

Esta base proporciona a los equipos de desarrollo de productos la información necesaria para evaluar si el equipo del proyecto está siguiendo los principios ágiles, así como si sus acciones y comportamientos son consistentes con los valores ágiles. Cuando comprenda estos valores y principios, podrá preguntar: "¿Es esto ágil?" y confíe en su respuesta.

Comprensión del Manifiesto Agile A mediados de la década de 1990, Internet estaba cambiando el mundo ante nuestros ojos. Las personas que trabajaban en la floreciente industria de las puntocom estaban sometidas a una presión constante para ser los primeros en comercializar tecnologías que cambiaban rápidamente. Los equipos de desarrollo trabajaron día y noche, luchando por entregar nuevas versiones de software antes

CAPITULO 2 Aplicación del Manifiesto Agile y los principios

los competidores hicieron obsoletas sus empresas. La industria de la tecnología de la información (TI) se reinventó por completo en unos pocos años. Dado el ritmo del cambio en ese momento, inevitablemente aparecieron grietas en las prácticas convencionales de gestión de proyectos. El uso de metodologías tradicionales como la cascada, que se analiza en el Capítulo 1, no permitió a los desarrolladores responder lo suficiente a la naturaleza dinámica del mercado y a los nuevos enfoques comerciales emergentes. Los equipos de desarrollo comenzaron a explorar alternativas a estos enfoques obsoletos de la gestión de proyectos. Al hacerlo, notaron algunos temas comunes que produjeron mejores resultados. En febrero de 2001, 17 de estos pioneros de la nueva metodología se reunieron en Snowbird, Utah, para compartir sus experiencias, ideas y prácticas; discutir la mejor manera de expresarlos; y sugerir formas de mejorar el mundo del desarrollo de software. No podrían haber imaginado el efecto que tendría su reunión en el futuro de la gestión de proyectos. La simplicidad y claridad del manifiesto que produjeron y los principios posteriores que desarrollaron transformaron el mundo de la tecnología de la información y continúan revolucionando la gestión de proyectos en todas las industrias, no solo en el desarrollo de software. Durante los siguientes meses, estos líderes construyeron lo siguiente:

» El Manifiesto Ágil: Una expresión intencionalmente optimizada de core valores de desarrollo

» Los principios ágiles: Un conjunto de 12 conceptos rectores que respaldan el proyecto ágil equipos para implementar técnicas ágiles y mantenerse en el camino

» La alianza ágil: Una organización de desarrollo comunitario centrada en

Apoyar a individuos y organizaciones que están aplicando principios ágiles y practicas

El trabajo del grupo estaba destinado a hacer que la industria del software fuera más productiva, más humana y más sostenible. El Manifiesto Ágil es una declaración poderosa, cuidadosamente elaborada con menos de 75 palabras: Manifiesto para el desarrollo de software ágil Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a otros a hacerlo. A través de este trabajo hemos llegado a valorar:

PARTE 1 Entendiendo Agile

Individuos e interacciones sobre procesos y herramientas

Software de trabajo sobre documentación completa Colaboración con el cliente sobre la negociación del contrato

Respondiendo al cambio sobre seguir un plan Es decir, si bien hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda. * Manifiesto ágil Copyright © 2001: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas Esta declaración se puede copiar libremente en cualquier forma, pero solo en su totalidad a través de este aviso.

Nadie puede negar que el Manifiesto Ágil es una declaración concisa y autorizada. Mientras que los enfoques tradicionales enfatizan un plan rígido, evitan el cambio, documentan todo y fomentan el control jerárquico, el manifiesto se centra en

» Personas

» Comunicaciones » El producto » Flexibilidad El Manifiesto Ágil representa un gran cambio de enfoque en la forma en que se conciben, conducen y gestionan los proyectos. Si leemos solo los ítems de la izquierda, entendemos el nuevo paradigma que vislumbraban los firmantes del manifiesto. Descubrieron que al centrar más la atención en las personas y las interacciones, los equipos producirían software de trabajo de manera más eficaz a través de la valiosa colaboración del cliente y respondiendo bien al cambio. Por el contrario, el enfoque primario tradicional en los procesos y herramientas a menudo produce documentación completa o excesiva para cumplir con las negociaciones del contrato y seguir un plan que no cambia. La investigación y la experiencia ilustran por qué los valores ágiles son tan importantes:

» Individuos e interacciones sobre procesos y herramientas: ¿Por qué? Porque La investigación muestra un aumento de 50 veces en el rendimiento cuando conseguimos que las personas y las interacciones sean correctas. Una de las formas en que lo hacemos bien es colocando un equipo de desarrollo con un propietario de producto capacitado.

» Software de trabajo sobre documentación completa: ¿Por qué? Porque

no probar y corregir los defectos durante el sprint puede requerir hasta 24 veces más esfuerzo y costo en el siguiente sprint. Y una vez implementada la funcionalidad en el mercado, si un equipo de soporte de producción que no participó en el desarrollo del producto realiza las pruebas y la reparación, el costo es hasta 100 veces mayor.

CAPITULO 2 Aplicación del Manifiesto Agile y los principios

» Colaboración con el cliente sobre la negociación del contrato: ¿Por qué? Porque un El propietario de producto dedicado y accesible puede generar un aumento de cuatro veces en la productividad al proporcionar una aclaración en el momento al equipo de desarrollo, alineando las prioridades del cliente con el trabajo que se está realizando.

» Responde al cambio sobre el siguiente plan: ¿Por qué? Porque el 64 por ciento de las características desarrolladas bajo un modelo en cascada rara vez o nunca se usan (como se discutió en el Capítulo 1). Comenzar con un plan es vital, pero es cuando menos sabemos. Los equipos ágiles no planean menos que los equipos en cascada, planean tanto o más. Sin embargo, los equipos ágiles adoptan un enfoque justo a tiempo y planifican lo suficiente cuando es necesario. La adaptación del plan a las realidades a lo largo del camino es cómo los equipos ágiles entregan productos que deleitan a los clientes.

Los creadores del Manifiesto Ágil se centraron originalmente en el desarrollo de software porque trabajaban en la industria de TI. Sin embargo, las técnicas ágiles de gestión de proyectos se han extendido más allá del desarrollo de software e incluso fuera de los productos relacionados con la computadora. Hoy en día, las personas utilizan enfoques ágiles para crear productos en una variedad de industrias, que incluyen biotecnología, manufactura, aeroespacial, ingeniería, marketing, trabajo sin fines de lucro e incluso construcción de edificios. Si desea obtener una retroalimentación empírica temprana sobre el producto o servicio que está brindando, puede beneficiarse de los métodos ágiles.

El Manifiesto Ágil y los 12 Principios Ágiles se refieren directamente al software; dejamos intactas estas referencias al citar el manifiesto y los principios a lo largo del libro. Si crea productos que no son de software, intente sustituir su producto a medida que sigue leyendo.

Descripción de los cuatro valores del Manifiesto Agile El Manifiesto Ágil se generó a partir de la experiencia, no de la teoría. Al revisar los valores descritos en las siguientes secciones, considere lo que significarían si los pusiera en práctica. ¿Cómo estos valores apoyan el cumplimiento de los objetivos de tiempo de comercialización, el manejo del cambio y la valoración de la innovación humana?

Valor 1: Individuos e interacciones sobre procesos y herramientas Cuando permite que cada persona contribuya con su valor único a un proyecto, el resultado puede ser poderoso. Cuando estas interacciones humanas se centran en resolver

PARTE 1 Entendiendo Agile

problemas, puede surgir un propósito unificado. Además, los acuerdos se concretan a través de procesos y herramientas mucho más sencillos que los convencionales. Una simple conversación en la que se habla de un problema del proyecto puede resolver muchos problemas en un tiempo relativamente corto. Intentar emular el poder de una conversación directa con correo electrónico, hojas de cálculo y documentos genera importantes costos generales y retrasos. En lugar de agregar claridad, estos tipos de comunicaciones administradas y controladas a menudo son ambiguas y requieren mucho tiempo y distraen al equipo de desarrollo del trabajo de creación de un producto. Considere lo que significa si valora mucho a las personas y las interacciones. La Tabla 2-1 muestra algunas diferencias entre valorar a las personas y valorar las interacciones y valorar los procesos y herramientas.

TABLA 2-1

Pros

Individuos e interacciones versus procesos y herramientas Los individuos y las interacciones tienen un gran valor

Los procesos y las herramientas tienen un gran valor

La comunicación es clara y eficaz. La

Los procesos son claros y fáciles de seguir.

comunicación es rápida y eficaz.

Existen registros escritos de comunicación.

El trabajo en equipo se fortalece a medida que las personas trabajan juntas.

Los equipos de desarrollo pueden autoorganizarse.

Los equipos de desarrollo tienen más oportunidades de innovar. Los equipos de desarrollo pueden personalizar los procesos según sea necesario.

Los miembros del equipo de desarrollo pueden apropiarse personalmente del proyecto. Los miembros del equipo de desarrollo pueden tener una mayor satisfacción laboral. Contras

Los miembros del equipo de desarrollo deben

Las personas pueden depender demasiado de los procesos en lugar de encontrar las

tener la capacidad estar involucrado,

mejores formas de crear buenos productos.

responsable e innovador.

Un proceso no se ajusta a todos los equipos: diferentes personas tienen

Es posible que las personas necesiten dejar de lado el ego para trabajar bien como miembros de un equipo.

diferentes estilos de trabajo. Un proceso no se adapta a todos los proyectos.

La comunicación puede ser ambigua y requerir mucho tiempo.

CAPITULO 2 Aplicación del Manifiesto Agile y los principios

Puede encontrar una plantilla en blanco de la Tabla 2-1 en el sitio web complementario del libro en

www.dummies.com/go/agileprojectmanagementfd2e - apunte los pros y los contras de cada enfoque que se aplican a usted y a sus proyectos.

Si los procesos y las herramientas se ven como la forma de gestionar el desarrollo de productos y todo lo relacionado con ellos, las personas y la forma en que abordan el trabajo deben ajustarse a los procesos y herramientas. La conformidad dificulta la adaptación de nuevas ideas, nuevos requisitos y nuevas formas de pensar. Los enfoques ágiles, sin embargo, valoran a las personas por encima del proceso. Este énfasis en las personas y los equipos se centra en su energía, innovación y capacidad para resolver problemas. Utiliza procesos y herramientas en la gestión ágil de proyectos, pero se optimizan intencionalmente y apoyan directamente la creación de productos. Cuanto más robusto es un proceso o una herramienta, más gasta en su cuidado y alimentación y más lo dedica. Sin embargo, con las personas al frente y al centro, el resultado es un salto en la productividad.

Valor 2: software de trabajo sobre documentación completa El enfoque de un equipo de desarrollo debe estar en producir funcionalidad de trabajo. En proyectos ágiles, la única forma de medir si realmente ha terminado con un requisito del producto es producir la funcionalidad de trabajo asociada con ese requisito. Para los productos de software, el software que funciona significa que el software cumple con lo que llamamos el definición

de hecho: como mínimo, desarrollado, probado, integrado y documentado. Después de todo, el producto funcional es la razón del proyecto. ¿Alguna vez ha estado en una reunión de estado en la que informó que había terminado, digamos, en un 75 por ciento con su proyecto? ¿Qué pasaría si su cliente le dijera: “Nos quedamos sin dinero. ¿Podemos tener nuestro 75 por ciento ahora? " En un proyecto tradicional, no tendría ningún software en funcionamiento para entregar al cliente - “75 por ciento terminado” tradicionalmente significa que está 75 por ciento en progreso y 0 por ciento terminado. Sin embargo, en un proyecto ágil, al utilizar la definición de terminado, tendría una funcionalidad operativa y potencialmente disponible para el 75 por ciento de los requisitos de su proyecto, el 75 por ciento de los requisitos de mayor prioridad. Aunque los enfoques ágiles tienen sus raíces en el desarrollo de software, puede utilizarlos para otros tipos de productos. Este segundo valor ágil puede leerse fácilmente, "Funcionalidad de trabajo sobre documentación completa". Las tareas que distraen la producción de una funcionalidad valiosa deben evaluarse para ver si respaldan o socavan el trabajo de crear un producto funcional. La Tabla 2-2 muestra algunos ejemplos de documentos de proyectos tradicionales y su utilidad. Piense en los documentos producidos en un proyecto reciente en el que participó.

PARTE 1 Entendiendo Agile

TABLA 2-2

Identificación de documentación útil ¿El documento

Documento Cronograma del proyecto

creado con proyecto caro administración

software, completo con diagrama de Gantt.

Producto de soporte

¿Desarrollo?

¿Es el documento apenas suficiente o está bañado en oro?

No.

Chapado en oro.

Horarios de principio a fin

Aunque los gerentes de proyecto pueden dedicar mucho tiempo

con tareas y fechas detalladas

a crear y actualizar los cronogramas del proyecto, los miembros

tienden a proporcionar más de lo

del equipo del proyecto tienden a querer saber solo las fechas

necesario para el desarrollo de

clave de entrega. La gerencia a menudo solo quiere saber si el

productos. También,

proyecto está a tiempo, adelantado o retrasado.

muchos de estos detalles cambiar antes de desarrollar funciones futuras.

Requisitos documentación.

Si.

Posiblemente bañado en oro; debería ser apenas suficiente.

Todos los proyectos tienen

Los documentos de requisitos pueden crecer fácilmente para incluir

requisitos —detalles

detalles innecesarios. Los enfoques ágiles proporcionan formas

sobre las características y necesidades

sencillas de describir los requisitos del producto.

del producto. Equipos de desarrollo Necesito conocer esas necesidades para crear un producto.

Técnico del producto especificaciones.

Si.

Posiblemente bañado en oro; debería ser apenas suficiente.

Documentando como tu

La documentación ágil incluye justo lo que necesita: los equipos de

creado un producto puede

desarrollo a menudo no tienen tiempo para florituras adicionales y

hacer futuro

están dispuestos a minimizar la documentación.

cambios más fáciles.

Semanal informe de estado.

No.

Chapado en oro.

Los informes de estado semanales

Conocer el estado del proyecto es útil, pero los informes de

son para fines de gestión.

estado tradicionales contienen información desactualizada y

pero no ayudan a la

son mucho más gravosos de lo necesario.

creación de productos.

Proyecto detallado

Plan de comunicación.

No.

Chapado en oro.

Aunque una lista de contactos

Los planes de comunicación a menudo terminan siendo

puede ser útil, los detalles de

documentos sobre documentación, un ejemplo atroz de trabajo

muchos planes de comunicación

ajetreado.

son inútiles para los equipos de desarrollo de productos.

Con una gestión ágil de proyectos, el término apenas suficiente es una descripción positiva, lo que significa que una tarea, documento, reunión o casi cualquier cosa en un proyecto incluye solo lo que necesita para lograr el objetivo. Ser apenas suficiente es práctico y eficiente; es suficiente, solo suficiente. Lo contrario de apenas suficiente es oro platino, agregar frivolidad y esfuerzo innecesarios a una función, tarea, documento, reunión o cualquier otra cosa.

CAPITULO 2 Aplicación del Manifiesto Agile y los principios

Todos los proyectos requieren cierta documentación. En proyectos ágiles, los documentos son útiles solo si apoyan el desarrollo de productos y apenas son suficientes para servir al diseño, entrega e implementación de un producto funcional de la manera más directa y sin ceremonias. Los enfoques ágiles simplifican drásticamente el papeleo administrativo relacionado con el tiempo, el control de costos, el control del alcance o los informes. Puede encontrar una plantilla en blanco de la Tabla 2-2 en www.dummies.com/go/agile

projectmanagementfd2e. Utilice ese formulario para evaluar qué tan bien contribuyó su documentación directamente al producto y si fue apenas suficiente. A menudo dejamos de producir un documento y vemos quién se queja. Una vez que conocemos al solicitante del documento, nos esforzamos por comprender mejor por qué es necesario el documento. La cinco porqués funciona muy bien en esta situación - pregunte "por qué" después de cada respuesta sucesiva para llegar a la raíz del documento. Una vez que conozca la razón principal del documento, vea cómo puede satisfacer esa necesidad con un artefacto ágil o un proceso simplificado. Los equipos de proyectos ágiles producen menos documentos y más simplificados que requieren menos tiempo para mantener y brindan una mejor visibilidad de los problemas potenciales. En los próximos capítulos, aprenderá a crear y utilizar herramientas simples (como una cartera de productos, una lista de tareas pendientes y un tablero de tareas) que permiten a los equipos de proyectos comprender los requisitos y evaluar el estado diariamente. Con enfoques ágiles, los equipos de proyectos dedican más tiempo al desarrollo y menos tiempo a la documentación, lo que resulta en una entrega más eficiente de un producto funcional.

Valor 3: colaboración del cliente sobre la negociación del contrato El cliente no es el enemigo. En realidad. Los enfoques de gestión de proyectos históricos generalmente involucran a los clientes en tres puntos clave:

» Inicio de un proyecto: Cuando el cliente y el director del proyecto, o otro representante del equipo del proyecto: negocia los detalles del contrato.

» Cada vez que el alcance cambia durante el proyecto: Cuando el cliente y el director del proyecto negocia cambios en el contrato.

» Fin de un proyecto: Cuando el equipo del proyecto entrega un producto completo al cliente. Si el producto no cumple con las expectativas del cliente, el

el gerente de proyecto y el cliente negocian cambios adicionales al contrato.

PARTE 1 Entendiendo Agile

Este enfoque histórico en la negociación desalienta las aportaciones potencialmente valiosas de los clientes e incluso puede crear una relación de confrontación entre los clientes y los equipos del proyecto.

Nunca sabrá menos sobre un producto que al inicio del proyecto. Bloquear los detalles del producto en un contrato al comienzo de su proyecto significa que debe tomar decisiones basadas en conocimientos incompletos. Si tiene flexibilidad para cambiar a medida que aprende más sobre un producto, finalmente creará mejores productos. Los pioneros ágiles entendieron que la colaboración, en lugar de la confrontación, producía productos mejores, más eficientes y más útiles. Como resultado de esta comprensión, los métodos ágiles hacen que el cliente forme parte del proyecto de forma continua. Al utilizar un enfoque ágil en la práctica, experimentará una asociación entre el cliente y el equipo de desarrollo en la que el descubrimiento, el cuestionamiento, el aprendizaje y los ajustes durante el transcurso del proyecto son rutinarios, aceptables y sistemáticos.

Valor 4: Responder al cambio en lugar de seguir un plan El cambio es una herramienta valiosa para crear excelentes productos. Los equipos de proyectos que pueden responder rápidamente a los clientes, los usuarios de productos y el mercado pueden desarrollar productos relevantes y útiles que la gente quiere usar. Desafortunadamente, los enfoques tradicionales de gestión de proyectos intentan luchar contra el monstruo del cambio y clavarlo en el suelo para que salga a la luz. Los rigurosos procedimientos de gestión de cambios y las estructuras presupuestarias que no pueden adaptarse a los requisitos de los nuevos productos dificultan los cambios. Los equipos de proyectos tradicionales a menudo se encuentran siguiendo ciegamente un plan, perdiendo oportunidades para crear productos más valiosos.

La figura 2-1 muestra la relación entre el tiempo, la oportunidad de cambio y el costo del cambio en un proyecto tradicional. A medida que aumenta el tiempo y el conocimiento sobre su producto, la capacidad de realizar cambios disminuye y cuesta más. Por el contrario, los proyectos ágiles se adaptan al cambio de forma sistemática. La flexibilidad de los enfoques ágiles aumenta la estabilidad del proyecto porque el cambio en un proyecto ágil es predecible y manejable. En capítulos posteriores, descubrirá cómo los enfoques ágiles para la planificación, el trabajo y la priorización permiten que los equipos de proyectos respondan rápidamente al cambio.

CAPITULO 2 Aplicación del Manifiesto Agile y los principios

FIGURA 2-1: Tradicional proyecto

oportunidad Para cambiar.

A medida que se desarrollan nuevos eventos, el equipo del proyecto incorpora esas realidades en el trabajo en curso. Cualquier artículo nuevo se convierte en una oportunidad para proporcionar un valor adicional en lugar de un obstáculo a evitar, lo que brinda a los equipos de desarrollo una mayor oportunidad de éxito.

Definición de los 12 principios ágiles En los meses posteriores a la publicación del Manifiesto Ágil, los firmantes originales continuaron comunicándose. Para apoyar a los equipos que realizan transiciones ágiles, aumentaron los cuatro valores del manifiesto con 12 principios detrás del Manifiesto Ágil.

Estos principios, junto con los Principios Platino (que se explican más adelante en la sección "Adición de los Principios Platino") se pueden utilizar como prueba de fuego para ver si las prácticas específicas de su equipo de proyecto son fieles a la intención del movimiento ágil.

A continuación se muestra el texto de los 12 principios originales, publicados en 2001 por Agile Alliance:

1. Nuestra máxima prioridad es satisfacer al cliente a través de un proceso temprano y continuo. entrega de software valioso.

2. Bienvenidos los requisitos cambiantes, incluso al final del desarrollo. Procesos ágiles aprovechar el cambio para la ventaja competitiva del cliente.

PARTE 1 Entendiendo Agile

3. Entregue software que funcione con frecuencia, desde un par de semanas hasta un par de meses, con preferencia a la escala de tiempo más corta.

4. Los empresarios y los desarrolladores deben trabajar juntos a diario durante todo el proyecto.

5. Construya proyectos en torno a personas motivadas. Dales el medio ambiente y el apoyo que necesitan y confíe en ellos para hacer el trabajo.

6. El método más eficiente y eficaz de transmitir información ay dentro de un equipo de desarrollo es una conversación cara a cara.

7. El software que funciona es la principal medida de progreso. 8. Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores, y los usuarios deben poder mantener un ritmo constante de forma indefinida.

9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad. 10. La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial. 11. Las mejores arquitecturas, requisitos y diseños surgen de la autoorganización equipos.

12. A intervalos regulares, el equipo reflexiona sobre cómo volverse más eficaz, luego sintoniza y ajusta su comportamiento en consecuencia.

Estos principios ágiles proporcionan una guía práctica para los equipos de desarrollo.

Otra forma de organizar los 12 principios es considerarlos en los siguientes cuatro grupos distintos:

» La satisfacción del cliente

» Calidad » Trabajo en equipo

» Gestión de proyectos Las siguientes secciones discuten los principios según estos grupos.

Principios ágiles de satisfacción del cliente Los enfoques ágiles se centran en la satisfacción del cliente, lo cual tiene sentido. Después de todo, el cliente es la razón para desarrollar el producto en primer lugar.

CAPITULO 2 Aplicación del Manifiesto Agile y los principios

Si bien los 12 principios respaldan el objetivo de satisfacer a los clientes, los principios 1, 2, 3 y 4 se destacan para nosotros:

Nuestra máxima prioridad es satisfacer al cliente mediante la entrega temprana y continua de software valioso.

Bienvenidos los requisitos cambiantes, incluso al final del desarrollo. Los procesos ágiles aprovechan el cambio para la ventaja competitiva del cliente.

Entregue software que funcione con frecuencia, desde un par de semanas hasta un par de meses, con preferencia a la escala de tiempo más corta.

Los empresarios y los desarrolladores deben trabajar juntos a diario durante todo el proyecto.

Puede definir al cliente en un proyecto de varias formas:

» En términos de gestión de proyectos, el cliente es la persona o grupo que paga el proyecto.

» En algunas organizaciones, el cliente puede ser un cliente, externo al organización.

» En otras organizaciones, el cliente puede ser una parte interesada del proyecto o una parte interesada titulares en la organización.

» La persona que termina usando el producto también es un cliente. Para mayor claridad y Para ser coherentes con los 12 principios ágiles originales, en este libro lo llamamos persona el usuario.

¿Cómo promulga estos principios? Simplemente haz lo siguiente:

» Los equipos de proyectos ágiles incluyen un dueño del producto, una persona que es responsable de garantizar la traducción de lo que el cliente desea en requisitos del producto.

» El propietario del producto prioriza las características del producto en orden de valor comercial o riesgo y comunica las prioridades al equipo de desarrollo. El desarrollo

equipo ofrece las funciones más valiosas de la lista en ciclos cortos de desarrollo, conocidos como iteraciones o sprints.

» El propietario del producto tiene una participación profunda y continua a lo largo de cada día. para aclarar prioridades y requisitos, tomar decisiones, proporcionar retroalimentación y Responda rápidamente las muchas preguntas que surgen durante un proyecto.

» La entrega frecuente de funciones de trabajo permite al propietario del producto y al cliente para tener una idea completa de cómo se está desarrollando el producto.

PARTE 1 Entendiendo Agile

» A medida que el equipo de desarrollo continúa entregando productos completos, funcionales y potencialmente funcionalidad de envío cada cuatro a ocho semanas o menos, el valor del total producto crece de forma incremental, al igual que sus capacidades funcionales.

» El cliente acumula valor por su inversión regularmente al

recibir nuevas funciones listas para usar en todo el proyecto, en lugar de esperando hasta el final de lo que podría ser un proyecto largo para la primera, y tal vez única, entrega de características de producto liberables.

En la Tabla 2-3, enumeramos algunos problemas de satisfacción del cliente que surgen comúnmente en los proyectos. Utilice la Tabla 2-3 y recopile algunos ejemplos de insatisfacción del cliente que haya encontrado. ¿Crees que una gestión de proyectos ágil marcaría la diferencia? ¿Por qué o por qué no?

TABLA 2-3

Insatisfacción del cliente y cómo puede ayudar AgileMight

Ejemplos de cliente

Insatisfacción con los proyectos

Cómo los enfoques ágiles pueden aumentar la satisfacción del cliente

Los requisitos del producto fueron mal entendidos por el Equipo de desarrollo.

Los propietarios de productos trabajan en estrecha colaboración con el cliente para definir y perfeccionar los requisitos del producto y proporcionar claridad al equipo de desarrollo.

Los equipos de proyectos ágiles demuestran y brindan funcionalidad de trabajo a intervalos regulares. Si un producto no funciona de la forma en que el cliente cree que debería funcionar, el cliente puede proporcionar comentarios al final del sprint, no antes de que sea demasiado tarde al final del proyecto.

El producto no se entregó cuando el cliente lo necesitaba.

Trabajar en sprints permite que los equipos de proyectos ágiles entreguen una funcionalidad de alta prioridad de manera temprana y frecuente.

El cliente no puede solicitar cambios sin adicionales

Los procesos ágiles están diseñados para el cambio. Los equipos de desarrollo

costo y tiempo.

cambiantes con cada sprint, compensando el costo de estos cambios al eliminar

pueden adaptarse a nuevos requisitos, actualizaciones de requisitos y prioridades los requisitos de menor prioridad, una funcionalidad que probablemente nunca o rara vez se utilizará.

Puede encontrar una plantilla en blanco del formulario en www.dummies.com/go/agile

projectmanagementfd2e. Las estrategias ágiles para la satisfacción del cliente incluyen las siguientes:

» Producir, en cada iteración, las características de mayor prioridad primero

» Idealmente, localizar al propietario del producto y a los demás miembros del proyecto. equipo en el mismo lugar para eliminar las barreras de comunicación

» Dividir los requisitos en grupos de funciones que se pueden entregar en cuatro a ocho semanas o menos

CAPITULO 2 Aplicación del Manifiesto Agile y los principios

» Mantener los requisitos escritos escasos, forzando más robustos y efectivos comunicación cara a cara

» Obtener la aprobación del propietario del producto a medida que se completa la funcionalidad

» Revisar la lista de funciones con regularidad para asegurarse de que los requisitos más valiosos los mentos continúan teniendo la más alta prioridad

Principios ágiles de calidad Un equipo de proyecto ágil se compromete a producir calidad en cada producto que crea, desde el desarrollo a través de la documentación hasta la integración y los resultados de las pruebas, todos los días. Cada miembro del equipo del proyecto aporta su mejor trabajo todo el tiempo. Aunque los 12 principios respaldan el objetivo de la prestación de servicios de calidad, los principios 1, 3, 4, 6–9 y 12 se destacan para nosotros:

1. Nuestra máxima prioridad es satisfacer al cliente a través de un proceso temprano y continuo. entrega de software valioso.

3. Entregue software que funcione con frecuencia, desde un par de semanas hasta un par de meses, con preferencia a la escala de tiempo más corta.

4. Los empresarios y los desarrolladores deben trabajar juntos a diario durante todo el proyecto.

6. El método más eficiente y eficaz de transmitir información ay dentro de un equipo de desarrollo es una conversación cara a cara.

9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad. 12. A intervalos regulares, el equipo reflexiona sobre cómo volverse más eficaz, luego sintoniza y ajusta su comportamiento en consecuencia.

Estos principios, en la práctica en el día a día, se pueden describir de la siguiente manera:

» Los miembros del equipo de desarrollo deben tener plena propiedad y estar empoderados. ered para resolver problemas. Tienen la responsabilidad de determinar cómo crear el producto, asignar tareas y organizar el desarrollo del producto. La gente que no hace el trabajo no les dice cómo hacerlo.

» Con proyectos de desarrollo de software, un enfoque ágil requiere arquitecturas que hacen que la codificación y el producto sean modulares, flexibles y extensibles. La El diseño debe abordar los problemas actuales y hacer que los cambios inevitables sean lo más simples posible.

PARTE 1 Entendiendo Agile

» Un conjunto de diseños en papel nunca puede decirle que algo funcionará. Cuándo

la calidad del producto es tal que puede demostrarse y, en última instancia, enviarse

en intervalos cortos, todo el mundo sabe que el producto funciona, al final de cada sprint.

» A medida que el equipo de desarrollo completa las funciones, el equipo muestra el producto propietario de la funcionalidad del producto para obtener la validación de que cumple con la aceptación

Criterios. Las revisiones del propietario del producto deben realizarse durante toda la iteración, idealmente el mismo día en que se completó el desarrollo del requisito.

» Al final de cada iteración (que dura de una a cuatro semanas o menos), el código de trabajo se demuestra al cliente. El progreso es claro y fácil de medir.

» Las pruebas son una parte integral y continua del desarrollo y se llevan a cabo durante todo el proceso. el día, no al final de la iteración.

» En proyectos de software, comprobar que el nuevo código se prueba y se integra con versiones anteriores ocurre en pequeños incrementos e incluso pueden ocurrir varias

veces al día (o miles de veces al día en algunas organizaciones, como Google, Amazon y Facebook). Este proceso, llamado integración continua (CI), ayuda a garantizar que toda la solución siga funcionando cuando se agrega nuevo código a la base de código existente.

» En proyectos de software, ejemplos de excelencia técnica incluyen el establecimiento estándares de codificación, uso de arquitectura orientada a servicios, implementación de pruebas acopladas y construcción para cambios futuros.

Los enfoques ágiles proporcionan las siguientes estrategias para la gestión de la calidad:

» Definiendo que hecho significa al comienzo del proyecto y luego usando ese definición como referente de calidad

» Pruebas agresivas y diarias a través de medios automatizados. » Construyendo solo la funcionalidad que se necesita cuando se necesita » Revisión del código del software y simplificación (refactorización) » Mostrar a las partes interesadas y a los clientes solo la funcionalidad que tiene ha sido aceptado por el propietario del producto

» Tener múltiples puntos de retroalimentación a lo largo del día, iteración y proyecto. Principios ágiles del trabajo en equipo El trabajo en equipo es fundamental para proyectos ágiles. La creación de buenos productos requiere la cooperación de todos los miembros del equipo del proyecto, incluidos los clientes y las partes interesadas. Los enfoques ágiles apoyan la formación de equipos y el trabajo en equipo, y enfatizan la confianza

CAPITULO 2 Aplicación del Manifiesto Agile y los principios

en equipos de desarrollo autogestionados. Un equipo de proyecto capacitado, motivado, unificado y empoderado es un equipo exitoso. Aunque los 12 principios respaldan el objetivo del trabajo en equipo, los principios 4 a 6, 8, 11 y 12 se destacan para nosotros como apoyo al empoderamiento, la eficiencia y la excelencia del equipo:

4. Los empresarios y los desarrolladores deben trabajar juntos a diario durante todo el proyecto.

5. Construya proyectos en torno a personas motivadas. Dales el medio ambiente y el apoyo que necesitan y confíe en ellos para hacer el trabajo.

6. El método más eficiente y eficaz de transmitir información ay dentro de un equipo de desarrollo es una conversación cara a cara.

8. Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores, y los usuarios deben poder mantener un ritmo constante de forma indefinida.

11. Las mejores arquitecturas, requisitos y diseños surgen de la autoorganización equipos.

12. A intervalos regulares, el equipo reflexiona sobre cómo volverse más eficaz, luego sintoniza y ajusta su comportamiento en consecuencia.

Los enfoques ágiles se centran en el desarrollo sostenible; como trabajadores del conocimiento, nuestro cerebro es el valor que aportamos a un proyecto. Aunque solo sea por razones egoístas, las organizaciones deberían querer tener cerebros frescos y descansados que trabajen para ellas. Mantener un ritmo de trabajo regular, en lugar de tener períodos de exceso de trabajo intenso, ayuda a mantener la mente aguda y la calidad de los miembros del equipo. Aquí hay algunas prácticas que puede adoptar para hacer realidad esta visión del trabajo en equipo:

» Asegúrese de que los miembros de su equipo de desarrollo tengan las habilidades y motivación.

» Brinde capacitación suficiente para la tarea.

» Apoyar las decisiones del equipo de desarrollo autoorganizado sobre qué hacer. Y, cómo hacerlo; que los gerentes no le digan al equipo qué hacer.

» Haga que los miembros del equipo del proyecto sean responsables como un solo equipo, no como individuos.

» Utilice la comunicación cara a cara para transmitir información de manera rápida y eficiente. Suponga que normalmente se comunica por correo electrónico con Sharon. Te tomas el tiempo para elaborar tu mensaje y luego enviarlo. El mensaje se encuentra en la bandeja de entrada de Sharon y finalmente lo lee. Si Sharon tiene alguna pregunta, escribe un correo electrónico en respuesta y la envía. Ese mensaje permanece en su bandeja de entrada hasta que finalmente lo lee. Etcétera. Este tipo de comunicación del tenis de mesa es demasiado ineficaz para usar en medio de una iteración rápida.

PARTE 1 Entendiendo Agile

» Tenga conversaciones espontáneas a lo largo del día para desarrollar conocimientos, comprensión y eficiencia.

» Coloque a los compañeros de equipo en las proximidades para aumentar la claridad y la eficiencia. comunicación. Si la colocación no es posible, use el chat de video en lugar del correo electrónico.

» Asegúrate de eso lecciones aprendidas es un circuito de retroalimentación continuo. Retrospectivas debe realizarse al final de cada iteración, cuando la reflexión y la adaptación puede mejorar la productividad del equipo de desarrollo en el futuro, creando niveles de eficiencia cada vez más altos. Una reunión de lecciones aprendidas al final de un proyecto tiene un valor mínimo.

La primera retrospectiva suele ser la más valiosa porque, en ese momento, el equipo del proyecto tiene la oportunidad de realizar cambios que beneficien al resto del proyecto en el futuro. Las siguientes estrategias promueven el trabajo en equipo eficaz:

» Coloque al equipo de desarrollo en la misma ubicación; esto se llama colocación.

» Cree un entorno físico propicio para la colaboración: un equipo

sala con pizarras, bolígrafos de colores y otras herramientas táctiles para desarrollar y transmitir ideas para asegurar un entendimiento compartido.

» Crear un entorno en el que se aliente a los miembros del equipo del proyecto a decir lo que piensan.

» Reúnase cara a cara siempre que sea posible. No envíe un correo electrónico si una conversación puede manejar el problema.

» Obtenga aclaraciones a lo largo del día según sea necesario.

» Anime al equipo de desarrollo a resolver problemas en lugar de tener los gerentes resuelven problemas para el equipo de desarrollo.

Principios ágiles de gestión de proyectos La agilidad en la gestión de proyectos abarca tres áreas clave:

» Asegurarse de que el equipo de desarrollo pueda ser productivo y sostenible aumentar la productividad durante largos períodos de tiempo

» Asegurar que la información sobre el progreso del proyecto esté disponible para las partes interesadas. titulares sin interrumpir el flujo de actividades de desarrollo pidiendo a los equipo de desarrollo para actualizaciones

» Manejar solicitudes de nuevas funciones a medida que ocurren e integrarlas en el ciclo de desarrollo del producto

CAPITULO 2 Aplicación del Manifiesto Agile y los principios

Un enfoque ágil se centra en planificar y ejecutar el trabajo para producir el mejor producto que se pueda lanzar. El enfoque se apoya en la comunicación abierta, evitando distracciones y actividades inútiles, y asegurando que el progreso del proyecto sea claro para todos.

Los 12 principios respaldan la gestión de proyectos, pero los principios 2, 8 y 10 se destacan para nosotros:

2. Bienvenidos los requisitos cambiantes, incluso al final del desarrollo. Procesos ágiles aprovechar el cambio para la ventaja competitiva del cliente.

8. Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores, y los usuarios deben poder mantener un ritmo constante de forma indefinida.

10. La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial. A continuación, se muestran algunas ventajas de adoptar una gestión de proyectos ágil:

» Los equipos de proyectos ágiles logran un tiempo de comercialización más rápido y, en consecuencia, cuestan ahorros. Comienzan el desarrollo antes que en los enfoques tradicionales porque los enfoques ágiles minimizan la exhaustiva planificación y documentación inicial que, convencionalmente, forma parte de las primeras etapas de un proyecto en cascada.

» Los equipos de desarrollo ágiles son autoorganizados y autogestionados. La gestión El esfuerzo real que normalmente se dedica a decirles a los desarrolladores cómo hacer su trabajo puede ser

aplicado para eliminar impedimentos y distracciones organizacionales que ralentizan al equipo de desarrollo.

» Los equipos de desarrollo ágiles determinan cuánto trabajo pueden realizar en una iteración y comprometerse a lograr esos objetivos. La propiedad es fundamentalmente

diferente porque el equipo de desarrollo está estableciendo el compromiso, no cumpliendo con un compromiso desarrollado externamente.

» Un enfoque ágil pregunta: "¿Qué es lo mínimo que podemos hacer para lograr el objetivo?" en lugar de centrarse en incluir todas las funciones y mejoras adicionales que

posiblemente podría ser necesario. Un enfoque ágil generalmente significa simplificar: documentación escasa, eliminación de reuniones innecesarias, evitar comunicaciones ineficientes (como el correo electrónico) y menos codificación (lo suficiente para que funcione).

Crear documentos complicados que no son útiles para el desarrollo de productos es una pérdida de esfuerzo. Está bien documentar una decisión, pero no necesita varias páginas sobre el historial y los matices de cómo se tomó la decisión. Mantenga la documentación apenas suficiente y tendrá más tiempo para concentrarse en apoyar al equipo de desarrollo.

PARTE 1 Entendiendo Agile

» Al encapsular el desarrollo en sprints cortos que duran de una a cuatro semanas o menos, puede adherirse a los objetivos de la iteración actual mientras se adapta

cambio de datación en iteraciones posteriores. La duración de cada sprint sigue siendo la misma durante todo el proyecto para proporcionar un ritmo de desarrollo predecible para el equipo a largo plazo.

» Planificación, elaboración de requisitos, desarrollo, prueba y demostración La funcionalidad de ing ocurre dentro de una iteración, reduciendo el riesgo de rumbo en el

dirección incorrecta durante períodos prolongados de tiempo o desarrollar algo que el cliente no quiere.

» Las prácticas ágiles fomentan un ritmo constante de desarrollo que es productivo

y saludable. Por ejemplo, en el popular conjunto de prácticas de desarrollo ágil llamada programación extrema (XP), la semana laboral máxima es de 40 horas y la semana laboral preferida es de 35 horas. Los proyectos ágiles son sostenibles y más productivos, especialmente a largo plazo. Los enfoques tradicionales presentan habitualmente una marcha de la muerte, en el que el proyecto se demora en horas extremadamente largas durante días e incluso semanas al final de un proyecto para cumplir con una fecha límite previamente no identificada y poco realista. A medida que avanza la marcha de la muerte, la productividad tiende a caer drásticamente. Se introducen más defectos y, debido a que los defectos deben corregirse de una manera que no rompa una parte diferente de la funcionalidad, corregir los defectos es el trabajo más costoso que se puede realizar. Los defectos suelen ser el resultado de la sobrecarga de un sistema, lo que exige específicamente un ritmo de trabajo insostenible. Consulte nuestra presentación sobre los efectos negativos de "Racing in

Contrarrestar" ( https://platinumedge.com/overtime).

» Prioridades, experiencia en el proyecto existente y, eventualmente, la velocidad en qué desarrollo probablemente ocurrirá dentro de cada sprint son claros, lo que hace que

buenas decisiones sobre cuánto se puede o se debe lograr en un período de tiempo determinado.

Si ha trabajado en un proyecto anteriormente, es posible que tenga un conocimiento básico de las actividades de gestión de proyectos. En la Tabla 2-4, enumeramos algunas tareas tradicionales de administración de proyectos, junto con cómo cumpliría esas necesidades con enfoques ágiles. Utilice la Tabla 2-4 para capturar sus pensamientos sobre sus experiencias y cómo los enfoques ágiles se ven diferentes de la gestión de proyectos tradicional. Una plantilla en blanco de la Tabla 2-4 está disponible en www.dummies.com/go/agile

projectmanagementfd2e.

CAPITULO 2 Aplicación del Manifiesto Agile y los principios

TABLA 2-4

Contrastando la gestión histórica de proyectos con la gestión ágil de proyectos

Tareas tradicionales de gestión de proyectos

Enfoque ágil de la tarea de gestión de proyectos

Cree un documento de requisitos del proyecto

Cree una cartera de productos: una lista simple de requisitos por prioridad.

completamente detallado al comienzo del

Actualice rápidamente la acumulación de productos a medida que cambian los

proyecto. Intente controlar los cambios de

requisitos y las prioridades a lo largo del proyecto.

requisitos a lo largo del proyecto. Lleve a cabo reuniones de estado semanales con todas las partes interesadas y desarrolladores del proyecto. Envíe notas detalladas de la reunión e informes de estado después de cada reunión.

El equipo de desarrollo se reúne rápidamente, durante no más de 15 minutos, al comienzo de cada día para coordinar y sincronizar el trabajo de ese día y cualquier obstáculo. Pueden actualizar el gráfico de evolución central visible en menos de un minuto al final de cada día.

Cree un cronograma detallado del proyecto con

Trabaje dentro de los sprints e identifique solo tareas específicas para el

todas las tareas al comienzo del proyecto. Trate de

sprint activo.

mantener las tareas del proyecto a tiempo. Actualice el horario de forma regular.

Asignar tareas al equipo de desarrollo.

Apoye al equipo de desarrollo ayudando a eliminar impedimentos y distracciones. En proyectos ágiles, los equipos de desarrollo definen y tiran (en lugar de impulsar) sus propias tareas.

La gestión de proyectos se ve facilitada por los siguientes enfoques ágiles:

» Apoyando al equipo de desarrollo » Producir documentos apenas suficientes » Optimización de los informes de estado para que la información sea enviada equipo de desarrollo en segundos en lugar de ser retirado por un gerente de proyecto durante un período de tiempo más largo

» Minimizar las tareas ajenas al desarrollo

» Establecer expectativas de que el cambio es normal y beneficioso, no algo que ser temido o evadido

» Adopción de un refinamiento de requisitos justo a tiempo para minimizar el cambio interrupción y esfuerzo inútil

» Colaborar con el equipo de desarrollo para crear horarios realistas, objetivos y metas

» Proteger al equipo de desarrollo de las interrupciones organizativas que socavar los objetivos del proyecto al introducir trabajo que no es relevante para el proyecto

objetivos

» Entender que un equilibrio adecuado entre el trabajo y la vida es una componente de desarrollo eficiente

PARTE 1 Entendiendo Agile

Adición de los principios de platino A través de la experiencia en las trincheras trabajando con equipos en transición a una gestión de proyectos ágil, y pruebas de campo en organizaciones grandes, medianas y pequeñas en todo el mundo, desarrollamos tres principios adicionales de desarrollo de software ágil que llamamos Principios Platino. Ellos son

» Resiste la formalidad.

» Piense y actúe en equipo. » Visualice en lugar de escribir. Puede explorar cada principio con más detalle en las siguientes secciones.

Resistir la formalidad Incluso los equipos de proyectos más ágiles pueden derivar hacia una formalización excesiva. Por ejemplo, no es raro que encontremos miembros del equipo del proyecto esperando hasta una reunión programada para discutir problemas simples que podrían resolverse en segundos. Estas reuniones a menudo tienen una agenda y actas de reuniones y requieren un cierto nivel de movilización y desmovilización solo para asistir. En un enfoque ágil, no se requiere este nivel de formalización. Siempre debe cuestionar la formalización y las exhibiciones llamativas e innecesarias. Por ejemplo, ¿existe una manera más fácil de obtener lo que necesita? ¿Cómo apoya la actividad actual el desarrollo de un producto de calidad lo más rápido posible? Responder estas preguntas lo ayuda a concentrarse en el trabajo productivo y evitar tareas innecesarias. En un sistema ágil, las discusiones y el entorno de trabajo físico son abiertos y fluidos; la documentación se mantiene en el nivel más bajo de cantidad y complejidad de manera que aporte valor al proyecto, no lo obstaculice; Se evitan las exhibiciones llamativas, como las presentaciones bien decoradas. Las comunicaciones profesionales y francas son las mejores para el equipo del proyecto, y todo el entorno tiene que hacer que esa franqueza esté disponible y sea cómoda. Las estrategias para tener éxito con resistir la formalidad incluyen las siguientes:

» Reducir la jerarquía organizativa siempre que sea posible mediante la eliminación de títulos en el equipo del proyecto

» Evitar inversiones estéticas como elaboradas presentaciones de PowerPoint. o extensos formularios de actas de reuniones, especialmente cuando se demuestra que se pueden enviar

funcionalidad al final de un sprint

CAPITULO 2 Aplicación del Manifiesto Agile y los principios

» Identificar y educar a las partes interesadas que pueden solicitar exhibiciones complicadas del trabajo sobre los costos de tales pantallas

Pensar y actuar en equipo Los miembros del equipo del proyecto deben centrarse en cómo el equipo en su conjunto puede ser más productivo. Este enfoque puede significar dejar de lado los nichos individuales y las métricas de rendimiento. En un entorno ágil, todo el equipo del proyecto debe estar alineado en su compromiso con la meta, su propiedad del alcance del trabajo y su reconocimiento del tiempo disponible para lograr ese compromiso. A continuación se presentan algunas estrategias para pensar y actuar en equipo:

» Desarrolle en parejas y cambie de pareja con frecuencia. Programación de ambos pares (ambos los socios tienen conocimiento en el área) y seguimiento (solo un socio es

conocedores de la zona) elevar la calidad del producto. Puede obtener más información sobre la programación por pares en el Capítulo 15.

» Reemplace los títulos de trabajos individuales con un título de desarrollador de producto uniforme. Las actividades de desarrollo incluyen todas las tareas necesarias para cumplir con los requisitos.

hasta la funcionalidad, incluido el diseño, la implementación (codificación), las pruebas y la documentación, no solo escribir código o girar un destornillador.

» Informe solo al nivel del equipo del proyecto, en lugar de crear una dirección especial. informes de ment que subdividen el equipo.

» Reemplace las métricas de desempeño individuales con métricas de desempeño del equipo del proyecto.

Visualizar en lugar de escribir Un equipo de proyecto ágil debe utilizar la visualización tanto como sea posible, ya sea a través de diagramas simples o herramientas de modelado computarizadas. Las imágenes son mucho más poderosas que las palabras. Cuando usa un diagrama o maqueta en lugar de un documento, su cliente puede relacionarse mejor con el concepto y el contenido. Nuestra capacidad para definir las características de un sistema aumenta exponencialmente cuando intensificamos nuestra interacción con la solución propuesta: una representación gráfica es casi siempre mejor que una textual, y lo mejor es experimentar la funcionalidad de forma práctica.

Incluso un boceto en una hoja de papel puede ser una herramienta de comunicación más eficaz que un documento formal basado en texto. Una imagen vale mas que mil palabras. Una descripción textual es la forma más débil de comunicación si está tratando de garantizar un entendimiento común, especialmente cuando se envía por correo electrónico con la solicitud de "avíseme si tiene alguna pregunta".

PARTE 1 Entendiendo Agile

CAMBIOS POR VENIR Las empresas están aprovechando técnicas ágiles a gran escala para resolver problemas comerciales. Aunque las metodologías de los grupos ágiles de TI, así como de los grupos que no lo son, han experimentado una transformación radical, las organizaciones en torno a estos grupos a menudo han continuado utilizando metodologías y conceptos históricos. Por ejemplo, los ciclos de financiación y gasto corporativos todavía están orientados a lo siguiente:

• • • •

Largos esfuerzos de desarrollo que entregan software funcional al final del proyecto. Presupuesto anual Una suposición de que la certeza es posible al comienzo de un proyecto. Paquetes de incentivos corporativos enfocados en el desempeño individual más que en el de equipo

La tensión resultante impide que las organizaciones aprovechen al máximo la eficiencia y los ahorros significativos que prometen las técnicas ágiles. Un enfoque ágil verdaderamente integrado alienta a las organizaciones a alejarse de las tradiciones del pasado y desarrollar una estructura en todos los niveles que continuamente pregunta qué es lo mejor para el cliente, el producto y el equipo del proyecto. Un equipo de proyecto ágil solo puede ser tan ágil como la organización a la que sirve. A medida que el movimiento continúa evolucionando, los valores articulados en el Manifiesto Agile y sus principios proporcionan una base sólida para los cambios necesarios para hacer que los proyectos individuales y organizaciones enteras sean más productivos y rentables. Esta evolución será impulsada por profesionales apasionados que continúan explorando y aplicando principios y prácticas ágiles.

Entre los ejemplos de estrategias de visualización se incluyen los siguientes:

» Abastecer el ambiente de trabajo con muchas pizarras blancas, papel de póster, bolígrafos y papel para que las herramientas de dibujo estén fácilmente disponibles

» Usar modelos en lugar de texto para comunicar conceptos » Informar el estado del proyecto a través de cuadros, gráficos y paneles, como los de la Figura 2-2.

CAPITULO 2 Aplicación del Manifiesto Agile y los principios

FIGURA 2-2: Cuadros, gráficos, y cuadros de mando

para informar estado del proyecto.

PARTE 1 Entendiendo Agile

Cambios como resultado de valores ágiles La publicación del Manifiesto Ágil y los 12 Principios Ágiles legitimó y enfocó el movimiento ágil de las siguientes maneras:

» Los enfoques ágiles cambiaron las actitudes hacia la gestión de proyectos Procesos. Al tratar de mejorar los procesos, los metodólogos en el pasado trabajaron para desarrollar un proceso universal que pudiera usarse en todas las condiciones, asumiendo que más procesos y mayor formalidad producirían mejores resultados. Sin embargo, este enfoque requería más tiempo, gastos generales y costos y, a menudo, una calidad disminuida. El manifiesto y los 12 principios reconocían que demasiado proceso es un problema, no una solución, y que el proceso correcto en la cantidad correcta difiere en cada situación.

» Los enfoques ágiles cambiaron las actitudes hacia los trabajadores del conocimiento. ESO Los grupos empezaron a recordar que los miembros del equipo de desarrollo no son recursos disponibles, sino personas cuyas habilidades, talentos e innovación marcan la diferencia en cada proyecto. El mismo producto creado por diferentes miembros del equipo será un producto diferente.

» Los enfoques ágiles cambiaron la relación entre la empresa y la TI

grupos. La gestión ágil de proyectos abordó los problemas asociados con la separación histórica entre el negocio y la TI al reunir a estos colaboradores en el mismo equipo de proyecto, en niveles iguales de participación y con objetivos compartidos.

» Los enfoques ágiles corrigieron las actitudes hacia el cambio. Histórico Los enfoques consideraban el cambio como un problema que debía evitarse o minimizarse. El Manifiesto Ágil y sus principios ayudaron a identificar el cambio como una oportunidad para garantizar que se implementaran las ideas más informadas.

La prueba ágil de tornasol Para ser ágil, debe poder preguntar: "¿Esto es ágil?" Si alguna vez tiene dudas sobre si un proceso, práctica, herramienta o enfoque en particular se adhiere al Manifiesto Ágil o los 12 principios, consulte la siguiente lista de preguntas:

1. ¿Lo que estamos haciendo en este momento respalda las primeras y continuas entrega de software valioso?

2. ¿Nuestro proceso da la bienvenida y aprovecha el cambio?

CAPITULO 2 Aplicación del Manifiesto Agile y los principios

3. ¿Nuestro proceso conduce y respalda la entrega de funcionalidad de trabajo? 4. ¿Los desarrolladores y el propietario del producto trabajan juntos a diario? Están clientes y partes interesadas del negocio que trabajan en estrecha colaboración con el equipo del proyecto?

5. ¿Nuestro entorno brinda al equipo de desarrollo el apoyo que necesita para obtener el trabajo hecho?

6. ¿Nos comunicamos cara a cara más que por teléfono y correo electrónico? 7. ¿Estamos midiendo el progreso por la cantidad de funcionalidad de trabajo producida? 8. ¿Podemos mantener este ritmo indefinidamente?

9. ¿Apoyamos la excelencia técnica y el buen diseño que permita el futuro? ¿cambios?

10. ¿Estamos maximizando la cantidad de trabajo no realizado, es decir, haciendo tan poco como necesario para cumplir el objetivo del proyecto?

11. ¿Este equipo de desarrollo es autoorganizado y autogestionado? ¿Tiene el libertad para triunfar?

12. ¿Estamos reflexionando a intervalos regulares y ajustando nuestro comportamiento en consecuencia? Si respondió “sí” a todas estas preguntas, felicitaciones; realmente está trabajando en un proyecto ágil. Si respondió “no” a cualquiera de estas preguntas, ¿qué puede hacer para cambiar esa respuesta a “sí”? Puede volver a este ejercicio en cualquier momento y utilizar la prueba de fuego ágil con su equipo de proyecto y la organización en general.

PARTE 1 Entendiendo Agile

EN ESTE CAPÍTULO » Descubriendo los beneficios de ágil

gestión de proyectos

» Comparación de enfoques ágiles para

enfoques históricos

» Descubrir por qué a la gente le gusta Agile

tecnicas

Capítulo

Por qué ser ágil FuncionaMejor

examina la mecánica de cómo los procesos ágiles mejoran la forma en que las personas trabajan y cómo evitan los gastos generalesbien onerosos. Comparaciones conqué su es esto? En este capítulo, Los enfoques ágiles funcionan en el mundo real. ¿Por

Los métodos tóricos destacan las mejoras que aportan las técnicas ágiles. Cuando se habla de las ventajas de la gestión ágil de proyectos, el resultado final es doble: el éxito del proyecto y la satisfacción de las partes interesadas.

Evaluación de los beneficios ágiles El concepto ágil de gestión de proyectos es diferente a las metodologías anteriores. Como se mencionó en el Capítulo 1, los enfoques ágiles abordan los desafíos clave de los métodos históricos de gestión de proyectos, como la cascada, pero también son mucho más profundos. Los procesos ágiles proporcionan un marco de cómo querer trabajar: cómo funcionamos naturalmente cuando resolvemos problemas y completamos tareas. Los métodos históricos de gestión de proyectos no se desarrollaron para los ciclos de vida de desarrollo contemporáneos, como el desarrollo de software, sino para sistemas menos complejos. También fueron adaptados de otros ámbitos, como la construcción, la manufactura y el militar. No es de extrañar que estos métodos de gestión de proyectos

CAPÍTULO 3 Por qué ser AgileWorks mejor

no encajan cuando se intenta construir productos más complejos y modernos, como aplicaciones móviles o aplicaciones centradas en la web y orientadas a objetos, que requieren una innovación constante para mantenerse competitivos. Incluso con tecnologías más antiguas, la trayectoria de las metodologías tradicionales es abismal, especialmente cuando se aplica a proyectos de software. Para obtener más detalles sobre las altas tasas de fracaso de los proyectos que se ejecutan tradicionalmente, consulte los estudios del Grupo Standish que se muestran en el Capítulo 1.

Puede utilizar técnicas ágiles de gestión de proyectos en muchas industrias además del desarrollo de software. Si está creando un producto y desea comentarios tempranos durante todo el proceso, puede beneficiarse de procesos ágiles. Cuando tiene una fecha límite inminente crítica, su instinto es ir ágil. La formalidad desaparece cuando te arremangas y te concentras en lo que tienes que hacer. Resuelve problemas de manera rápida, práctica y en orden descendente de necesidad, asegurándose de completar las tareas más críticas. Más que ser ágil, se trata de ser ágil. Cuando se vuelve ágil, no establece plazos irrazonables para forzar un mayor enfoque. En cambio, te das cuenta de que las personas funcionan bien como solucionadores prácticos de problemas, incluso bajo estrés. Por ejemplo, un popular ejercicio de formación de equipos titulado desafío de malvavisco involucra a grupos de cuatro personas que construyen la estructura independiente más alta posible con 20 palos de espagueti, una yarda de cinta y una yarda de cuerda, y luego colocan un malvavisco en la parte superior, en 18 minutos. Ver www.marshmallowchallenge.com para obtener información básica sobre el concepto. En ese sitio, también puede ver la charla TED asociada de Tom Wujec.

Wujec señala que los niños pequeños generalmente construyen estructuras más altas e interesantes que la mayoría de los adultos porque los niños construyen gradualmente sobre una serie de estructuras exitosas en el tiempo asignado. Los adultos dedican mucho tiempo a planificar, producen una versión final y luego se les acaba el tiempo para corregir los errores. Los jóvenes brindan una valiosa lección que desarrollo del big bang - es decir, planificación excesiva y luego una oportunidad de creación de producto - no funciona. La formalidad, el tiempo excesivo en el que se detallan los pasos futuros desinformados y un plan único a menudo perjudican el éxito. El desafío del malvavisco establece condiciones de apertura que imitan las de la vida real. Construye una estructura (que equivale a un producto de software en la industria de TI) utilizando recursos fijos (cuatro personas, espaguetis, etc.) y un tiempo fijo (18 minutos). Lo que terminas es una incógnita, pero una suposición subyacente en los enfoques históricos de gestión de proyectos es que puedes determinar el destino preciso (las características o requisitos) al principio y luego estimar las personas, los recursos y el tiempo necesarios.

Esta suposición está al revés de cómo es realmente la vida. Como puede ver en la Figura 3-1, las teorías de los métodos históricos son el reverso de los enfoques ágiles.

PARTE 1 Entendiendo Agile

Pretendemos que vivimos en el mundo de la izquierda, pero en realidad vivimos en el mundo de la derecha.

FIGURA 3-1: Una comparación de

proyecto historico administración y conceptos ágiles.

En el enfoque histórico, que bloquea los requisitos y entrega el producto de una vez, el resultado es todo o nada. O tenemos éxito por completo o fallamos absolutamente. Hay mucho en juego porque todo depende del trabajo que ocurre al final (es decir, poner el malvavisco en la parte superior) de la fase final del ciclo, que incluye la integración y las pruebas del cliente.

En la Figura 3-2, puede ver cómo cada fase de un proyecto en cascada depende de la anterior. Los equipos diseñan y desarrollan todas las funciones en conjunto, lo que significa que no obtendrá la función de mayor prioridad hasta que haya terminado de desarrollar la función de menor prioridad. El cliente tiene que esperar hasta el final del proyecto para obtener la entrega final de cualquier elemento del producto.

FIGURA 3-2: La cascada ciclo del proyecto

es un lineal

metodología.

CAPÍTULO 3 Por qué ser AgileWorks mejor

En la fase de prueba de un proyecto en cascada, los clientes pueden ver su producto tan esperado. En ese momento, la inversión y el esfuerzo han sido enormes y el riesgo de fallas es alto. Encontrar defectos entre todos los requisitos de productos terminados es como buscar una maleza en un campo de maíz. La gestión ágil de proyectos da la vuelta al concepto de cómo se debe realizar el desarrollo de software. Usando métodos ágiles, usted desarrolla, prueba y lanza pequeños grupos de requisitos de productos en ciclos iterativos cortos, conocidos como iteraciones, o sprints, como se ilustra en la Figura 3-3. Las pruebas se realizan durante cada iteración. Para encontrar defectos, el equipo de desarrollo busca una maleza en una maceta, en lugar de en un maizal.

FIGURA 3-3: Enfoques ágiles tener un iterativo ciclo del proyecto.

Propietario del producto, scrummaster, y pique son términos de melé, un marco ágil popular para organizar el trabajo y exponer el progreso del proyecto. Melé se refiere a un grupo de rugby, en el que un equipo de rugby se encierra sobre la pelota. Scrum como enfoque, como el rugby, anima al equipo del proyecto a trabajar en estrecha colaboración y asumir la responsabilidad del resultado. (Encontrará más información sobre scrum y otras técnicas ágiles en el Capítulo 4.)

PARTE 1 Entendiendo Agile

DONDE LA CASCADA CAE CORTO Como mencionamos en el Capítulo 1, antes de 2008, la cascada era la metodología tradicional de gestión de proyectos más utilizada. La siguiente lista resume los aspectos principales del enfoque en cascada para la gestión de proyectos:

•

El equipo debe conocer todos los requisitos por adelantado para estimar el tiempo, los presupuestos, los miembros del equipo y los recursos. Conocer todos los requisitos al inicio del proyecto significa

tiene una gran inversión en la recopilación de requisitos detallados antes de que comience cualquier desarrollo.

•

La estimación es compleja y requiere un alto grado de competencia y experiencia y mucho esfuerzo para completar.

•

Es posible que el cliente y las partes interesadas no estén disponibles para responder preguntas durante el período de desarrollo, porque pueden asumir que proporcionaron toda la información.

mación necesaria durante las fases de recopilación de requisitos y diseño.

•

El equipo debe resistir la adición de nuevos requisitos o documentarlos como órdenes de cambio, lo que agrega más trabajo al proyecto y extiende el cronograma y presupuesto.

•

El equipo debe crear y mantener volúmenes de documentación de procesos para administrar y controlar el proyecto.

•

Aunque se pueden realizar algunas pruebas sobre la marcha, las pruebas finales no se pueden completar hasta el final del proyecto, cuando se han desarrollado e integrado todas las funciones.

•

La retroalimentación completa y completa del cliente no es posible hasta el final del proyecto, cuando todas las funciones están completas.

•

La financiación está en curso, pero el valor aparece solo al final del proyecto, lo que genera un alto nivel de riesgo.

•

El proyecto debe estar completamente completo para que se logre valor. Si la financiación se agota antes del final del proyecto, el proyecto ofrece un valor cero.

Además, en un proyecto ágil, los clientes pueden ver su producto al final de cada ciclo corto. Puede crear primero las características de mayor prioridad, lo que le brinda la oportunidad de garantizar el máximo valor desde el principio, cuando se ha invertido menos dinero del cliente.

Este concepto ágil es atractivo, especialmente para organizaciones con aversión al riesgo. Además, si su producto tiene valor de mercado, los ingresos pueden llegar incluso durante el desarrollo. ¡Ahora tienes un proyecto autofinanciado!

CAPÍTULO 3 Por qué ser AgileWorks mejor

HowAgile Approaches Beat Enfoques históricos Los marcos ágiles prometen ventajas significativas sobre los métodos históricos, que incluyen mayor flexibilidad y estabilidad, menos trabajo improductivo, entrega más rápida con mayor calidad, rendimiento mejorado del equipo de desarrollo, control más estricto del proyecto y detección de fallas más rápida. Describimos todos estos resultados en esta sección. Sin embargo, estos resultados no se pueden lograr sin un equipo de desarrollo funcional y altamente competente. El equipo de desarrollo es fundamental para el éxito del proyecto. Los métodos ágiles enfatizan la importancia del apoyo brindado al equipo de desarrollo, así como la importancia de las acciones e interacciones de los miembros del equipo del proyecto.

El primer valor fundamental del Manifiesto Ágil es "Individuos e interacciones sobre procesos y herramientas". Nutrir al equipo de desarrollo es fundamental para la gestión ágil de proyectos y la razón por la que puede tener tanto éxito con enfoques ágiles. Los equipos de proyectos ágiles se centran en equipos de desarrollo (que incluyen desarrolladores, probadores, diseñadores y cualquier otra persona que realice el trabajo real de crear el producto), y también incluyen a las partes interesadas del proyecto, así como a los siguientes dos miembros importantes del equipo, sin los cuales el el equipo de desarrollo no pudo funcionar:

» Dueño del producto: La dueño del producto es un miembro del equipo del proyecto que es un experto en el producto y las necesidades comerciales del cliente. El propietario del producto

trabaja con la comunidad empresarial y prioriza los requisitos del producto, y apoya al equipo de desarrollo que está disponible para proporcionar aclaraciones diarias y aceptación final al equipo de desarrollo. (El Capítulo 2 tiene más información sobre el propietario del producto).

» Scrummaster o coach ágil: La scrummaster o entrenador ágil actúa como un amortiguador entre el equipo de desarrollo y las distracciones que podrían ralentizar el esfuerzo de desarrollo. El scrummaster también proporciona experiencia en procesos ágiles y ayuda a eliminar los obstáculos que impiden que el equipo de desarrollo avance. El scrummaster o entrenador ágil facilita la creación de consenso y la comunicación con las partes interesadas.

Puede encontrar descripciones completas del propietario del producto, el equipo de desarrollo y el scrummaster en el Capítulo 6. Más adelante en este capítulo, verá cómo la prioridad más alta del propietario del producto y del scrum master es apoyar y optimizar el desempeño del equipo de desarrollo.

PARTE 1 Entendiendo Agile

Mayor flexibilidad y estabilidad A modo de comparación, los proyectos ágiles ofrecen mayor flexibilidad y estabilidad que los proyectos tradicionales. Primero, averigua cómo los proyectos ágiles ofrecen flexibilidad y luego hablamos de estabilidad. Un equipo de proyecto, independientemente de su enfoque de gestión de proyectos, se enfrenta a dos desafíos importantes al comienzo de un proyecto:

» El equipo del proyecto tiene un conocimiento limitado del estado final del producto.

» El equipo del proyecto no puede predecir el futuro. Este conocimiento limitado del producto y de las necesidades comerciales futuras casi garantiza cambios en el proyecto. El cuarto valor fundamental del Manifiesto Ágil es "Responder al cambio en lugar de seguir un plan". El marco ágil se creó pensando en la flexibilidad. Con enfoques ágiles, los equipos de proyectos pueden adaptarse a los nuevos conocimientos y requisitos que surgen a medida que avanza el proyecto. Proporcionamos muchos detalles sobre los procesos ágiles que permiten la flexibilidad a lo largo de este libro. Aquí hay una descripción simple de algunos procesos que ayudan a los equipos de proyectos ágiles a administrar el cambio:

» Al comienzo de un proyecto ágil, el propietario del producto reúne productos de alto nivel

requisitos de las partes interesadas del proyecto y les da prioridad. El producto El propietario no necesita todos los requisitos, solo los suficientes para comprender bien lo que debe lograr el producto.

» El equipo de desarrollo y el propietario del producto trabajan juntos para desglosar los requisitos iniciales de máxima prioridad en requisitos más detallados. La

El resultado son pequeñas porciones de trabajo que el equipo de desarrollo puede comenzar a desarrollar de inmediato.

» Te enfocas en las principales prioridades en cada sprint sin importar qué tan pronto antes el sprint se establecieron esas prioridades. Las iteraciones, o sprints, en proyectos ágiles son breves: duran hasta cuatro semanas y, a menudo, una o dos semanas. Puede encontrar detalles sobre los sprints en los capítulos 8-10.

» El equipo de desarrollo trabaja en grupos de requisitos dentro de sprints y aprende más sobre el producto con cada sprint sucesivo.

» El desarrollo en equipo se ejecuta un sprint a la vez y profundiza en requisitos al comienzo de cada sprint. El equipo de desarrollo generalmente funciona solo en los requisitos de mayor prioridad.

CAPÍTULO 3 Por qué ser AgileWorks mejor

» Concentrarse en un sprint a la vez y en los requisitos de máxima prioridad: permite que el equipo del proyecto se adapte a los nuevos requisitos de alta prioridad

mentos al comienzo de cada sprint.

» Cuando surgen cambios, el propietario del producto actualiza una lista de requisitos que

queda por tratar en futuros sprints. El propietario del producto vuelve a priorizar lista con regularidad.

» El propietario del producto puede invertir financieramente en funciones de alta prioridad primero y puede elija qué características financiar a lo largo del proyecto.

» El propietario del producto y el equipo de desarrollo recopilan los comentarios de los clientes al final de cada sprint y actuar en base a esa retroalimentación. Los comentarios de los clientes a menudo conducen a cambios en

funcionalidad existente o para requisitos nuevos y valiosos. La retroalimentación también puede llevar a eliminar o cambiar las prioridades de los requisitos que no son realmente necesarios.

» El propietario del producto puede detener el proyecto una vez que considere que El producto tiene la funcionalidad suficiente para cumplir con los objetivos del proyecto.

La Figura 3-4 ilustra cómo realizar cambios en proyectos ágiles puede ser más estable que realizar cambios en cascada. Piense en las dos imágenes de la figura como barras de acero. En la imagen superior, la barra representa un proyecto de dos años. La longitud de la barra hace que sea mucho más fácil de distorsionar, doblar y romper. Los cambios de proyecto se pueden pensar de la misma manera: los proyectos largos son estructuralmente vulnerables a la inestabilidad porque la etapa de planificación de un proyecto es diferente a la ejecución, cuando la realidad se establece, y no hay un punto natural de ceder en un proyecto largo.

FIGURA 3-4: Estabilidad en

flexibilidad en proyectos ágiles.

Ahora mire la imagen inferior en la Figura 3-4. Las pequeñas barras de acero representan iteraciones de dos semanas dentro de un proyecto. Es mucho más fácil para esas barras pequeñas ser estables e inmutables que para la barra más grande. De la misma manera, es más fácil tener la estabilidad del proyecto en incrementos más pequeños con puntos de flexibilidad conocidos.

PARTE 1 Entendiendo Agile

Decirle a una empresa que no puede haber cambios durante dos semanas es mucho más fácil y más realista que decir que no puede haber cambios durante dos años. Los proyectos ágiles son tácticamente flexibles porque son estratégicamente estables. Son excelentes para adaptarse al cambio porque los medios para el cambio regular están integrados en los procesos cotidianos. Al mismo tiempo, las iteraciones en proyectos ágiles ofrecen áreas distintas para la estabilidad del proyecto. Los equipos de proyectos ágiles se adaptan a los cambios en la acumulación de productos en cualquier momento, pero generalmente no se adaptan a los cambios externos al alcance durante el sprint. La acumulación de productos puede cambiar constantemente, pero, excepto en emergencias, el sprint es generalmente estable.

Al comienzo de la iteración, el equipo de desarrollo planifica el trabajo que completará para ese sprint. Una vez que comienza el sprint, el equipo de desarrollo trabaja solo en los requisitos planificados. Pueden ocurrir un par de excepciones a este plan: si el equipo de desarrollo termina antes, puede solicitar más trabajo; si surge una emergencia, el propietario del producto puede cancelar el sprint. En general, sin embargo, el sprint es un momento de gran estabilidad para el equipo de desarrollo. Esta estabilidad puede conducir a la innovación. Cuando los miembros del equipo de desarrollo tienen estabilidad, es decir, saben en qué estarán trabajando en un período de tiempo determinado, pensarán en sus tareas conscientemente en el trabajo. También pueden pensar inconscientemente en tareas ajenas al trabajo y tienden a encontrar soluciones en un momento dado. Los proyectos ágiles proporcionan un ciclo constante de desarrollo, retroalimentación y cambio, lo que permite a los equipos de proyecto la flexibilidad de crear productos con solo las características adecuadas y la estabilidad para ser creativos.

Reducción de tareas no productivas Cuando está creando un producto, en cualquier momento de su jornada laboral, puede trabajar en el desarrollo del producto o en los procesos periféricos que se supone deben administrar y controlar la creación del producto. Claramente, hay más valor en el primero, que debe intentar maximizar, que en el segundo, que desea minimizar.

Para terminar un proyecto, debes trabajar en la solución. Por más obvio que suene esta afirmación, habitualmente se descuida en los proyectos en cascada. Los programadores de algunos proyectos de software dedican solo el 20 por ciento de su tiempo a generar funcionalidad, y el resto del tiempo a reuniones, redacción de correos electrónicos o creación de presentaciones y documentación innecesarias. El desarrollo de productos puede ser una actividad intensa que requiere períodos prolongados de concentración. Muchos desarrolladores no pueden obtener suficiente tiempo de desarrollo durante su

CAPÍTULO 3 Por qué ser AgileWorks mejor

jornada laboral para mantenerse al día con el cronograma de un proyecto porque están haciendo otro tipo de tareas. La siguiente cadena causal es el resultado: Jornada de trabajo larga = desarrolladores cansados = defectos innecesarios = más corrección de defectos = liberación retrasada = más tiempo para generar valor

Para maximizar el trabajo productivo, el objetivo es eliminar las horas extraordinarias y hacer que los desarrolladores creen funcionalidades durante la jornada laboral. Para aumentar el trabajo productivo, tienes que reducir las tareas improductivas, punto.

Reuniones Las reuniones pueden ser una gran pérdida de tiempo valioso. En proyectos tradicionales, los miembros del equipo de desarrollo pueden encontrarse en reuniones largas que brindan poco o ningún beneficio a los desarrolladores. Los siguientes enfoques ágiles pueden ayudar a garantizar que los equipos de desarrollo dediquen tiempo solo a reuniones productivas y significativas:

» Los procesos ágiles incluyen solo unas pocas reuniones formales. Estas reuniones son enfocado, con temas específicos y tiempo limitado. En proyectos ágiles, generalmente no es necesario asistir a reuniones no ágiles.

» Parte del trabajo del scrummaster es prevenir interrupciones en el desarrollo el tiempo de trabajo del equipo, incluidas las solicitudes de reuniones no ágiles. Cuando hay una demanda para alejar a los desarrolladores del trabajo de desarrollo, el scrummaster pregunta "por qué" para comprender la verdadera necesidad. El scrummaster entonces puede descubrir cómo satisfacer esa necesidad sin interrumpir al equipo de desarrollo.

» En proyectos ágiles, el estado actual del proyecto suele estar disponible visualmente para el toda la organización, eliminando la necesidad de reuniones de estado. Puedes encontrar formas para simplificar los informes de estado en el Capítulo 14.

Correo electrónico El correo electrónico no es un modo de comunicación eficaz; Los equipos de proyectos ágiles tienen como objetivo utilizar el correo electrónico solo con moderación. El proceso de correo electrónico es asincrónico y lento: envía un correo electrónico, espera una respuesta; tiene otra pregunta, envía otro correo electrónico. Este proceso consume tiempo que podría emplearse de manera más productiva. En lugar de enviar correos electrónicos, los equipos de proyectos ágiles utilizan discusiones cara a cara para resolver preguntas y problemas en el momento.

Presentaciones Al prepararse para una presentación de la funcionalidad al cliente, los equipos de proyectos ágiles suelen utilizar las siguientes técnicas:

PARTE 1 Entendiendo Agile

» Demuestre, no presente. En otras palabras, muestre al cliente lo que que ha creado, en lugar de describir lo que ha creado.

» Muestre cómo la funcionalidad cumple con los requisitos y cumple los

criterios de aceptación. En otras palabras, diga: “Este era el requisito. Estos son los criterios necesarios para indicar que la función estaba completa. Aquí está la funcionalidad resultante que cumple con esos criterios ".

» Evite las presentaciones formales de diapositivas y toda la preparación que implican. Cuando demuestre la funcionalidad de trabajo, hablará por sí mismo. Mantenga las demostraciones crudas y reales.

Documentación del proceso La documentación ha sido la carga de los directores de proyectos y desarrolladores durante mucho tiempo. Los equipos de proyectos ágiles pueden minimizar la documentación con los siguientes enfoques:

» Utilice el desarrollo iterativo. Se crea mucha documentación para hacer referencia

decisiones tomadas hace meses o años. El desarrollo iterativo acorta el tiempo entre la decisión y el producto desarrollado desde meses o años hasta días. El producto y las pruebas automatizadas asociadas, en lugar de un papeleo extenso, documentan las decisiones tomadas.

» Recuerde que una talla no sirve para todos. No tienes que crear lo mismo documentos para cada proyecto. Elija lo que necesita para adaptarse al proyecto en particular.

» Utilice herramientas de documentación informales y flexibles. Pizarrones, notas adhesivas, gráficos y otras representaciones visuales del plan de trabajo son excelentes herramientas.

» Incluya herramientas sencillas que brinden información adecuada para la gestión mención sobre el progreso del proyecto. No cree informes especiales de progreso del proyecto, como informes de estado extensos, por el simple hecho de generar informes. Los equipos ágiles utilizan gráficos visuales, como gráficos de evolución, para transmitir fácilmente el estado del proyecto.

Mayor calidad, entregado más rápido En los proyectos tradicionales, el período desde la finalización de la recopilación de requisitos hasta el comienzo de las pruebas del cliente puede ser dolorosamente largo. Durante este tiempo, el cliente está esperando ver algún tipo de resultado y el equipo de desarrollo está envuelto en el desarrollo. El gerente del proyecto se asegura de que el equipo del proyecto esté siguiendo el plan, manteniendo a raya los cambios y actualizando a todos los interesados en el resultado al proporcionar informes frecuentes y detallados.

CAPÍTULO 3 Por qué ser AgileWorks mejor

Cuando comienzan las pruebas, cerca del final del proyecto, los defectos pueden causar aumentos de presupuesto, crear retrasos en la programación e incluso acabar con un proyecto. La prueba es la mayor incógnita de un proyecto y, en los proyectos tradicionales, es una incógnita que se lleva hasta el final.

La gestión ágil de proyectos está diseñada para ofrecer una funcionalidad de envío rápido y de alta calidad. Los proyectos ágiles logran una mejor calidad y una entrega rápida con lo siguiente:

» El cliente revisa la funcionalidad de trabajo al final de cada sprint y proporciona

retroalimentación inmediata al equipo para su inspección y adaptación tan pronto como siguiente sprint.

» Las iteraciones de desarrollo cortas (sprints) limitan el número y la complejidad de características en desarrollo en un momento dado, lo que hace que el trabajo terminado sea más fácil

prueba en cada sprint. Solo se puede crear mucho en cada sprint. Los equipos de desarrollo desglosan características demasiado complejas para un sprint.

» El equipo de desarrollo crea y prueba a diario y mantiene un producto en todo el proyecto.

» El propietario del producto participa durante todo el día para responder preguntas y aclarar los malentendidos rápidamente.

» El equipo de desarrollo está empoderado y motivado y tiene un jornada laboral. Debido a que el equipo de desarrollo no está agotado, ocurren menos defectos.

» Los errores se detectan rápidamente porque los desarrolladores prueban su trabajo plegado. Se realizan pruebas exhaustivas automatizadas con frecuencia, al menos todas las noches.

» Las herramientas de desarrollo de software modernas permiten escribir muchos requisitos como scripts de prueba, sin necesidad de programación, lo que automatiza prueba más rápido.

Rendimiento del equipo mejorado La experiencia de los miembros del equipo del proyecto es fundamental para la gestión ágil de proyectos. En comparación con los enfoques tradicionales como la cascada, los equipos de proyectos ágiles obtienen más apoyo ambiental y organizacional, pueden dedicar más tiempo a concentrarse en su trabajo y pueden contribuir a la mejora continua del proceso. Para descubrir qué significan estas características en la práctica, continúe leyendo.

Soporte para el equipo La capacidad del equipo de desarrollo para ofrecer una funcionalidad potencialmente disponible es fundamental para obtener resultados con enfoques ágiles y se logra con los siguientes mecanismos de soporte:

PARTE 1 Entendiendo Agile

» Una práctica ágil común es colocación - mantener el equipo de desarrollo e, idealmente, el propietario del producto juntos en un solo lugar y físicamente cerca del

cliente. La coubicación fomenta la colaboración y hace que la comunicación sea más rápida, clara y sencilla. Puede levantarse de su asiento, tener una conversación directa y eliminar cualquier vaguedad o incertidumbre de inmediato.

» El propietario del producto puede responder a las preguntas del equipo de desarrollo y

solicitudes de aclaración sin demora, eliminando confusiones y permitiendo trabajar para proceder sin problemas.

» El scrummaster elimina los impedimentos y asegura que el desarrollo equipo tiene todo lo que necesita para concentrarse y lograr la máxima productividad.

Enfocar Mediante procesos ágiles, el equipo de desarrollo puede concentrar la mayor parte de su tiempo de trabajo en el desarrollo del producto. Los siguientes enfoques ayudan a los equipos de desarrollo ágiles a concentrarse:

» Los miembros del equipo de desarrollo se asignan al 100 por ciento a un proyecto, eliminando perder el tiempo y el enfoque al cambiar de contexto entre diferentes proyectos.

» Los miembros del equipo de desarrollo saben que sus compañeros de equipo estarán completamente disponible.

» Los desarrolladores se centran en pequeñas unidades de funcionalidad que son tan independientes como posible desde otra funcionalidad. Cada mañana, el equipo de desarrollo sabe lo que significa tener éxito ese día.

» El scrummaster tiene la responsabilidad explícita de ayudar a proteger el desarrollo equipo de mentir de las distracciones organizacionales.

» El tiempo que el equipo de desarrollo dedica a la codificación y la productividad relacionada las actividades aumentan porque el trabajo no productivo disminuye.

Mejora continua Un proceso ágil no es un enfoque de marcar casillas sin sentido. Los diferentes tipos de proyectos y los diferentes equipos de proyectos pueden adaptarse a su situación específica, como puede ver en la discusión de las retrospectivas de sprint en el Capítulo 10. Aquí hay algunas formas en que los equipos de proyectos ágiles pueden mejorar continuamente:

» El desarrollo iterativo hace posible la mejora continua porque cada la nueva iteración implica un nuevo comienzo.

» Debido a que los sprints ocurren solo en unas pocas semanas, los equipos de proyecto pueden incorporar el proceso cambia rápidamente.

CAPÍTULO 3 Por qué ser AgileWorks mejor

» Un proceso de revisión llamado retrospectivo tiene lugar al final de cada iteración y brinda a todos los miembros ágiles del equipo un foro específico para identificar

y planificación de acciones de mejora.

» Todo el equipo de scrum: propietario del producto, miembros del equipo de desarrollo, y scrummaster: revisa aspectos del trabajo que cree que podría necesitar

mejora.

» El equipo de scrum aplica las lecciones que aprende de la retrospectiva al sprints que siguen, que así se vuelven más productivos.

Control más estricto del proyecto El trabajo avanza más rápido en proyectos ágiles que en condiciones de cascada. La productividad elevada ayuda a aumentar el control del proyecto con lo siguiente:

» Los procesos ágiles proporcionan un flujo constante de información. Equipos de desarrollo planean su trabajo juntos todas las mañanas en scrummeetings diarios, y ellos actualizar el estado de la tarea a lo largo de cada día.

» Para cada sprint, el cliente tiene la oportunidad de volver a priorizar el producto requisitos basados en las necesidades comerciales.

» Después de entregar la funcionalidad de trabajo al final de cada sprint, finaliza la carga de trabajo para el próximo sprint de acuerdo con las prioridades actuales. No hace

diferencia si las prioridades se establecieron semanas o minutos antes del próximo sprint.

» Cuando el propietario del producto establece prioridades para el próximo sprint, esta acción no tiene efecto en el sprint actual. En un proyecto ágil, un cambio de requisitos

no agrega costos administrativos ni tiempo y no interrumpe el trabajo actual.

» Las técnicas ágiles facilitan la finalización del proyecto. Al final de cada iteración, puede determinar si las características del producto ahora son adecuadas. Es posible que nunca se desarrollen elementos de baja prioridad.

En cascada, las métricas del proyecto pueden estar desactualizadas por semanas y la funcionalidad demostrable puede tardar meses. En un contexto ágil, las métricas son nuevas y relevantes todos los días, el trabajo completado a menudo se compila e integra a diario, y el software en funcionamiento se demuestra cada pocas semanas. Desde el primer sprint hasta el cierre del proyecto, cada miembro del equipo del proyecto sabe si el equipo del proyecto está cumpliendo. El conocimiento actualizado del proyecto y la capacidad de priorizar rápidamente hacen posible altos niveles de control del proyecto.

PARTE 1 Entendiendo Agile

Fallas más rápidas y menos costosas En un proyecto en cascada, las oportunidades para la detección de fallas son teóricas hasta cerca del final del cronograma del proyecto, cuando todo el trabajo completado se junta y cuando la mayor parte de la inversión se ha agotado. Esperar hasta las últimas semanas o días del proyecto para descubrir que el producto tiene problemas graves es riesgoso para todos los interesados. La figura 3-5 compara el perfil de riesgo e inversión de la cascada con el de los enfoques ágiles.

FIGURA 3-5: Un riesgo y

inversión comparando gráfico

cascada y ágil metodologías.

Junto con oportunidades para un control más estricto del proyecto, el marco ágil le ofrece

» Oportunidades más tempranas y frecuentes para detectar fallas » Una oportunidad de evaluación y acción cada pocas semanas » Reducción de costos por fallas ¿Qué tipo de fallas ha visto en los proyectos? ¿Habrían ayudado los enfoques ágiles? Puede obtener más información sobre el riesgo en proyectos ágiles en el Capítulo 15.

Por qué a la gente le gusta ser ágil Ha visto cómo una organización puede beneficiarse de una gestión de proyectos ágil con una entrega de productos más rápida y menores costos. En las siguientes secciones, descubrirá cómo las personas involucradas en un proyecto también pueden beneficiarse, ya sea directa o indirectamente.

CAPÍTULO 3 Por qué ser AgileWorks mejor

Ejecutivos La gestión ágil de proyectos proporciona dos beneficios que resultan especialmente atractivos para los ejecutivos: eficiencia y un retorno de la inversión más alto y más rápido.

Eficiencia Las prácticas ágiles permiten una eficiencia mucho mayor en el proceso de desarrollo de las siguientes maneras:

» Los equipos de desarrollo ágiles son muy productivos. Organizan el trabajo

se centran en actividades de desarrollo y están protegidos de las distracciones ciones por el scrummaster.

» Se minimizan los esfuerzos improductivos. El enfoque ágil elimina infructuosos trabaja; la atención se centra en el desarrollo.

» Mediante el uso de ayudas visuales simples, oportunas y a pedido, como gráficos y

diagramas: para mostrar lo que se ha hecho, lo que está en progreso y lo que Vamos, el progreso del proyecto es más fácil de entender de un vistazo.

» A través de pruebas continuas, los defectos se detectan y corrigen temprano. » Un proyecto ágil se puede detener cuando tiene suficiente funcionalidad. Mayor oportunidad de ROI El ROI se mejora significativamente con enfoques ágiles por las siguientes razones:

» La funcionalidad se entrega al mercado antes. Las características son completamente

completado y luego lanzado en grupos, en lugar de esperar hasta el final de todo el desarrollo y lanzar el 100 por ciento de las funciones a la vez.

» La calidad del producto es mayor. El alcance del desarrollo se desglosa en fragmentos manejables que se prueban y verifican de forma continua.

» La oportunidad de ingresos se puede acelerar. Los incrementos del producto son lanzado al mercado antes que con los enfoques tradicionales de gestión de proyectos.

» Los proyectos pueden autofinanciarse. Un lanzamiento de funcionalidad podría generar ingresos mientras que el desarrollo de otras funciones está en curso.

PARTE 1 Entendiendo Agile

Desarrollo de producto y clientes A los clientes les gustan los proyectos ágiles porque pueden adaptarse a los requisitos cambiantes y generar productos de mayor valor.

Adaptación mejorada al cambio Los cambios en los requisitos, las prioridades, los plazos y los presupuestos del producto pueden alterar enormemente los proyectos tradicionales. Por el contrario, los procesos ágiles manejan los cambios de proyectos y productos de manera beneficiosa. Por ejemplo:

» Los proyectos ágiles crean una oportunidad para aumentar la satisfacción del cliente y retorno de la inversión al manejar el cambio de manera efectiva.

» Los cambios se pueden incorporar en iteraciones posteriores de forma rutinaria y suavemente.

» Debido a que los miembros del equipo y la duración del sprint permanecen constantes, proyecte los cambios plantean menos problemas que con los enfoques tradicionales. Necesario los cambios se colocan en la lista de funciones según la prioridad, empujando los elementos de menor prioridad hacia abajo en la lista. En última instancia, el propietario del producto elige cuándo finalizará el proyecto, en el punto en el que la inversión futura no proporcionará suficiente valor.

» Porque el equipo de desarrollo desarrolla primero los elementos de mayor valor y El propietario del producto controla la priorización, el propietario del producto puede estar seguro que las prioridades comerciales estén alineadas con la actividad del desarrollador.

Mayor valor Con el desarrollo iterativo, las características del producto se pueden lanzar a medida que el equipo de desarrollo las completa. El desarrollo iterativo y las versiones proporcionan un mayor valor de las siguientes formas:

» Los equipos de proyectos entregan antes las características de los productos de mayor prioridad.

» Los equipos de proyecto pueden entregar productos valiosos antes. » Los equipos de proyecto pueden ajustar los requisitos en función de los cambios del mercado y comentarios de los clientes.

CAPÍTULO 3 Por qué ser AgileWorks mejor

Gestión A los directivos les suelen gustar los proyectos ágiles por la mayor calidad del producto, la disminución de la pérdida de tiempo y esfuerzo y el énfasis en el valor del producto sobre la verificación de listas de características de dudosa utilidad.

Mejor calidad Con el desarrollo de software, a través de técnicas como el desarrollo basado en pruebas, la integración continua y los comentarios frecuentes de los clientes sobre el software en funcionamiento, puede incorporar una mayor calidad en el producto desde el principio. Con los proyectos de desarrollo que no son de software, ¿de qué maneras puede pensar para desarrollar la calidad por adelantado?

Menos desperdicio de producto y proceso En proyectos ágiles, el tiempo perdido y las funciones se reducen mediante una serie de estrategias, que incluyen las siguientes:

» Elaboración justo a tiempo (JIT): Amplificación de solo los valores más altos actualmente requisitos de prioridad significa que no se dedica tiempo a trabajar en los detalles de características que tal vez nunca se desarrollen.

» Participación de clientes y grupos de interés: Clientes y otras partes interesadas Los usuarios pueden proporcionar retroalimentación en cada sprint y el equipo de desarrollo incorpora esa retroalimentación en el proyecto. A medida que continúan el proyecto y los comentarios, aumenta el valor para el cliente.

» Un sesgo para la conversación cara a cara: Una comunicación más rápida y clara ahorra tiempo y confusión.

» Explotación incorporada del cambio: Solo las características y funciones de alta prioridad desarrollado.

» Énfasis en la evidencia de funcionalidad de trabajo: Si una característica no

funciona o no funciona de manera valiosa, se descubre temprano a un costo menor.

Énfasis en el valor El principio ágil de simplicidad apoya la eliminación de procesos y herramientas que no respaldan el desarrollo de manera directa y eficiente, y la exclusión de características que agregan poco valor tangible. Este principio se aplica tanto a la administración y documentación como al desarrollo de las siguientes formas:

PARTE 1 Entendiendo Agile

» Menos reuniones, más breves y más enfocadas

» Reducción del boato » Documentación apenas suficiente » Responsabilidad conjunta entre el cliente y el equipo del proyecto por la calidad y valor del producto

Equipos de desarrollo Los enfoques ágiles permiten a los equipos de desarrollo producir su mejor trabajo en condiciones razonables. Los métodos ágiles dan a los equipos de desarrollo

» Una definición clara de éxito a través de la creación e identificación conjunta de objetivos de sprint. ción de los criterios de aceptación durante el desarrollo de requisitos

» El poder y el respeto para organizar el desarrollo como mejor les parezca. » Los comentarios de los clientes que necesitan para aportar valor

» La protección de un scrummaster dedicado para eliminar impedimentos y prevenir interrupciones

» Un ritmo de trabajo humano y sostenible » Una cultura de aprendizaje que apoya tanto el desarrollo personal como el proyecto. mejora

» Una estructura que minimiza el tiempo de no desarrollo. En las condiciones anteriores, el equipo de desarrollo prospera y ofrece resultados más rápido y con mayor calidad. En Broadway y en Hollywood, los artistas que están en el escenario y en la pantalla para conectarse con la audiencia a menudo se denominan "el talento". Son la razón por la que muchos clientes de entretenimiento vienen a un programa, y los escritores, directores y productores de apoyo se aseguran de que brillen. En un entorno ágil, el equipo de desarrollo es "el talento". Cuando el talento tiene éxito, todos triunfan.

CAPÍTULO 3 Por qué ser AgileWorks mejor

2 Ser ágil

EN ESTA PARTE . . .

Comprenda lo que significa ser ágil y cómo poner en práctica las prácticas ágiles. Obtenga una descripción general de los tres enfoques ágiles más populares y descubra cómo crear el entorno adecuado de espacio físico, comunicación y herramientas para facilitar interacciones ágiles. Examine el cambio de comportamiento en valores, filosofía, roles y habilidades necesarias para operar en un equipo ágil.

EN ESTE CAPÍTULO » Aplicando prácticas ágiles

» Comprensión de lean, scrum y Programación extrema » Conectando técnicas ágiles

Capítulo

Enfoques ágiles

Es posible que incluso haya oído hablar de técnicas y marcos ágiles comunes. ¿Se pregunta cómo ven realmente los marcos, métodos y técnicas En lossecapítulos anteriores, leíste sobre la historia de laágiles? gestión ágil de proyectos.

En este capítulo, obtendrá una descripción general de tres de los enfoques más comunes utilizados

hoy para implementar un proyecto ágil.

Bucear bajo el paraguas de enfoques ágiles El Manifiesto Ágil y los principios ágiles por sí solos no serían suficientes para lanzarlo a un proyecto ágil, por más ansioso que esté por hacerlo. La razón es que los principios y las prácticas son diferentes. Sin embargo, los enfoques descritos en este libro le brindan las prácticas necesarias para tener éxito en un proyecto ágil.

Ágil es un término descriptivo para una serie de técnicas y métodos que tienen las siguientes similitudes:

» Desarrollo dentro de múltiples iteraciones, llamado desarrollo iterativo » Énfasis en la simplicidad, la transparencia y las estrategias específicas de la situación.

CAPÍTULO 4 Enfoques ágiles

sesenta y cinco

» Equipos multifuncionales y autoorganizados » Funcionalidad de trabajo como medida del progreso La gestión ágil de proyectos es un enfoque de gestión de proyectos empírico. En otras palabras, haces algo en la práctica y ajustas tu enfoque basándose en la experiencia más que en la teoría.

Con respecto al desarrollo de productos, el enfoque empírico se sustenta en los siguientes pilares:

» Transparencia sin límites: Todos los involucrados en el proceso entienden y puede contribuir al desarrollo del proceso.

» Inspección frecuente: El inspector debe inspeccionar el producto con regularidad y Poseer las habilidades para identificar variaciones de los criterios de aceptación.

» Adaptación inmediata: El equipo de desarrollo debe poder adaptarse rápidamente para minimizar más desviaciones de productos.

Una gran cantidad de enfoques tienen características ágiles. Sin embargo, tres son comunes a muchos proyectos ágiles: desarrollo de productos ajustados, scrum y programación extrema (XP). Estos tres enfoques funcionan perfectamente juntos y comparten muchos elementos en común, aunque utilizan una terminología diferente o tienen un enfoque ligeramente diferente. En términos generales, lean y scrum se centran en la estructura. La programación extrema también hace eso, pero es más prescriptiva sobre las prácticas de desarrollo, centrándose más en el diseño técnico, la codificación, las pruebas y la integración. (De un enfoque llamado

Programación extrema, es de esperar este tipo de enfoque). Cuando las organizaciones con las que trabajamos afirman que utilizan un enfoque ágil para la gestión de proyectos, normalmente trabajan en un entorno esbelto, con una atención constante para limitar el trabajo en curso, las prácticas derrochadoras y los pasos del proceso; usar scrum para organizar su trabajo y exponer el progreso del proyecto; y el uso de prácticas de programación extremas para incorporar la calidad desde el principio. Cada uno de estos enfoques se explica con más detalle más adelante en este capítulo. Como cualquier enfoque sistemático, las técnicas ágiles no surgieron de la nada. Los conceptos tienen precedentes históricos, algunos de los cuales tienen orígenes fuera del desarrollo de software, lo cual no es sorprendente, dado que el desarrollo de software no ha existido durante tanto tiempo en la historia de los eventos humanos. La base de los enfoques ágiles no es la misma que la de las metodologías tradicionales de gestión de proyectos, como la cascada, que se basaba en un método de control definido utilizado para la adquisición de materiales de la Segunda Guerra Mundial. Los primeros pioneros del hardware informático utilizaron el proceso en cascada para gestionar la complejidad del primer

PARTE 2 Ser ágil

sistemas informáticos, que en su mayoría eran hardware: 1.600 tubos de vacío, pero sólo unas 30 líneas de software codificado a mano. (Consulte la Figura 4-1.) Un proceso inflexible es eficaz cuando los problemas son simples y el mercado es estático, pero el entorno de desarrollo de productos actual es demasiado complejo para un modelo tan obsoleto.

FIGURA 4-1: Hardware temprano

y software.

Ingresa el Dr. Winston Royce. En su artículo, "Gestión del desarrollo de grandes sistemas", publicado en 1970, el Dr. Royce codificó el proceso de desarrollo de software paso a paso conocido como cascada. Cuando miras su diagrama original en la Figura 4-2, puedes ver de dónde vino ese nombre. Sin embargo, con el tiempo, la situación del desarrollo informático se revirtió. El hardware se volvió repetible a través de la producción masiva y el software se convirtió en el aspecto más complejo y diverso de una solución completa. La ironía aquí es que, aunque el diagrama implica que completa las tareas paso a paso, el propio Dr. Royce agregó la nota de advertencia de que necesita iteración. Así es como lo dijo:

"Si el programa informático en cuestión se está desarrollando por primera vez, organice los asuntos de modo que la versión que se entregue al cliente para la implementación operativa sea en realidad la segunda versión en lo que respecta a las áreas críticas de diseño / operaciones".

Royce incluso incluyó el diagrama que se muestra en la Figura 4-3 para ilustrar esa iteración.

CAPÍTULO 4 Enfoques ágiles

FIGURA 4-2: Los orígenes de

cascada.

FIGURA 4-3: Iteración en cascada.

PARTE 2 Ser ágil

Ahora, no estamos seguros de si el diagrama se atascó con goma de mascar en otras páginas, pero la comunidad de desarrollo de software en general perdió esta parte de la historia. Después de permitir la idea de que es posible que no sepa todo cuando comienza a desarrollar un componente de software y es posible que tenga que revisar el código para asegurarse de que sea apropiado, tiene el rayo de luz que deja entrar conceptos ágiles. ¡Agile podría haber cobrado importancia 40 años antes si la gente hubiera tomado en serio el consejo del Dr. Royce!

Revisión de los tres grandes: programación ajustada, Scrum y extrema Ahora que tiene una breve historia del enfoque en cascada para la gestión de proyectos, está listo para obtener más información sobre tres enfoques ágiles populares: programación ajustada, scrum y extrema.

Una descripción general de lean Lean tiene sus orígenes en la fabricación. Los métodos de producción en masa, que han existido durante más de 100 años, fueron diseñados para simplificar los procesos de ensamblaje (por ejemplo, armar un Ford Modelo-T). Estos procesos utilizan maquinaria compleja y cara y trabajadores poco cualificados para producir de forma económica un artículo de valor. La idea es que si mantiene las máquinas y las personas trabajando y almacena el inventario, genere mucha eficiencia. La sencillez es engañosa. Tradicionalmente, la producción en masa requiere sistemas de apoyo derrochadores y grandes cantidades de mano de obra indirecta para garantizar que la fabricación continúe sin pausa. Genera un enorme inventario de piezas, trabajadores adicionales, espacio adicional y procesos complejos que no agregan valor directo al producto. ¿Suena familiar?

Cortar la grasa a medida que surge la magra en la fabricación En la década de 1940 en Japón, una pequeña empresa llamada Toyota quería producir automóviles para el mercado japonés, pero no podía permitirse la enorme inversión que requiere la producción en masa. La compañía estudió los supermercados y observó cómo los consumidores compran justo lo que necesitan porque saben que siempre habrá un suministro y cómo las tiendas reabastecen los estantes solo cuando se vacían. A partir de esta observación, Toyota creó un proceso justo a tiempo que podría traducirse en la fábrica. El resultado fue una reducción significativa en el inventario de piezas y productos terminados y una menor inversión en máquinas, personas y espacio.

CAPÍTULO 4 Enfoques ágiles

Un gran costo de los procesos de producción en masa en ese momento era que los humanos en la línea de producción eran tratados como máquinas: las personas no tenían autonomía y no podían resolver problemas, tomar decisiones o mejorar los procesos. El trabajo era aburrido y dejaba de lado el potencial humano. Por el contrario, el proceso justo a tiempo brinda a los trabajadores la capacidad de tomar decisiones sobre lo que es más importante hacer a continuación, en tiempo real, en la fábrica. Los trabajadores asumen la responsabilidad de los resultados. El éxito de Toyota con los procesos justo a tiempo ha ayudado a cambiar los enfoques de fabricación en masa a nivel mundial.

Comprender el desarrollo de software y lean El termino inclinarse fue acuñado en la década de 1990 en La máquina que cambió el mundo: la

historia de la producción ajustada ( Free Press) de James P. Womack, Daniel T. Jones y Daniel Roos. eBay fue uno de los primeros en adoptar los principios lean para el desarrollo de software. La compañía abrió el camino con un enfoque que respondía diariamente a las solicitudes de los clientes de cambios en el sitio web, desarrollando funciones de alto valor en poco tiempo.

El enfoque de lean es el valor comercial y la minimización de actividades fuera del desarrollo de productos. Mary y Tom Poppendieck discuten un grupo de principios lean en su blog y en sus libros sobre desarrollo de software lean. Los siguientes son los principios lean de su libro de 2003, Desarrollo de software ajustado ( Addison-Wesley Professional):

» Eliminar residuos. Hacer cualquier cosa que sea más que suficiente (proceso pasos, artefactos, reuniones) ralentiza el flujo del progreso. Los residuos incluyen

no aprender del trabajo, construir algo incorrecto y luchar (cambio de contexto entre tareas o proyectos), lo que da como resultado la creación parcial de muchas características del producto, pero no la creación completa de ninguna.

» Amplíe el aprendizaje. El aprendizaje impulsa la previsibilidad. Permitir la mejora a través de una mentalidad de transparencia, inspección y

adaptación. Fomente una cultura en toda la organización que permita el fracaso por el simple hecho de aprender de él.

» Entregue lo más tarde posible. Permita una adaptación tardía. No entregue tarde, pero Deje sus opciones abiertas el tiempo suficiente para tomar decisiones en la última respuesta.

Momento sible basado en hechos en lugar de incertidumbre, cuando usted sabe más. Aprenda del fracaso. Desafiar los estándares. Utilice el método científico: experimente con hipótesis para encontrar soluciones.

» Entregue lo más rápido posible. Velocidad, costo y calidad son compatibles. Lo más pronto entregue, antes recibirá comentarios. Trabaja en menos cosas a la vez

limitar el trabajo en curso y optimizar el flujo. Administre el flujo de trabajo, en lugar de los horarios. Utilice la planificación justo a tiempo para acortar los ciclos de desarrollo y lanzamiento.

PARTE 2 Ser ágil

» Empoderar al equipo. Trabajar de forma autónoma, dominar habilidades y creer en el propósito del trabajo puede motivar a los equipos de desarrollo. Los gerentes no Dígales a los desarrolladores cómo hacer su trabajo, pero en su lugar ayúdelos a organizarse por sí mismos en torno al trabajo que deben realizar y elimine sus impedimentos. Asegúrese de que los equipos y las personas tengan el entorno y las herramientas que necesitan para hacer bien su trabajo.

» Construya la calidad en. Establecer mecanismos para detectar y corregir defectos cuando suceden y antes de la verificación final. La calidad se construye desde el principio ning, no al final. Rompe las dependencias, para que puedas desarrollar e integrar la funcionalidad en cualquier momento sin regresiones.

» Ver el conjunto. Todo un sistema es tan fuerte como su eslabón más débil. Resolver problemas, no solo síntomas. Presta atención continua a los cuellos de botella

a lo largo del flujo de trabajo y eliminarlos. Piense a largo plazo al crear soluciones. Más allá de los principios lean, uno de los enfoques lean más comunes utilizados por los equipos ágiles es kanban, a veces denominado lean-kanban. Adaptado del enfoque del sistema de producción de Toyota, Kanban es esencialmente un método para eliminar desechos para mejorar el flujo y el rendimiento en un sistema. Las prácticas de Kanban se pueden aplicar en casi cualquier situación porque están diseñadas para comenzar desde donde usted se encuentra; no tiene que cambiar nada en su flujo de trabajo existente para comenzar. Las prácticas Kanban incluyen lo siguiente:

» Visualizar. » Limite el trabajo en curso (WIP). » Gestionar el flujo. » Haga explícitas las políticas del proceso. » Implemente ciclos de retroalimentación.

» Mejorar colaborativamente, evolucionar experimentalmente. Las últimas tres prácticas se encuentran comúnmente en otros marcos ágiles, como scrum y XP (ambos discutidos más adelante en este capítulo). Los tres primeros mejoran la eficacia de los equipos ágiles:

» Visualizar: Visualizar el flujo de trabajo de un equipo es el primer paso para identificar el potencial desperdicio. Los procesos tradicionales hinchados existen en muchas organizaciones, pero no

reflejar la realidad, incluso si se visualiza. A medida que los equipos ágiles visualizan el flujo de su trabajo (en una pizarra, en una pared o en un dibujo) e identifican dónde se rompe la productividad, pueden analizar fácilmente la causa raíz y ver cómo eliminar la restricción. Y luego hazlo una y otra vez, y otra vez.

CAPÍTULO 4 Enfoques ágiles

Kanban es japonés para señal visual. Colgado en la pared de la fábrica o en la pared del espacio de trabajo de desarrollo, donde todos pueden verlo, el tablero kanban muestra los elementos que los equipos deben producir a continuación. En el tablero hay tarjetas que representan unidades de producción. A medida que avanza la producción, los trabajadores retiran, agregan y mueven tarjetas. A medida que las tarjetas se mueven, actúan como una señal para los trabajadores cuando se necesita trabajo o reabastecimiento de inventario. Los equipos ágiles usan tableros kanban o tableros de tareas para exponer su progreso y administrar su flujo de trabajo (descrito con más detalle en los Capítulos 5 y 9).

» Limitar el trabajo en curso (WIP): Cuando los equipos siguen empezando a trabajar pero no terminan él, su trabajo en progreso continúa creciendo. Ser ágil se trata de llegar a

hecho, por lo que el objetivo es comenzar las cosas solo cuando se completen otras. Trabajar en varias cosas a la vez no significa que las complete todas más rápido; en realidad, las completará más lentamente que si hubiera trabajado en ellas una a la vez. Cuando los equipos ágiles limitan su trabajo en progreso, los elementos se completan más rápido, lo que acelera el ritmo de completar cada elemento en su cola.

» Administrar flujo: Todos hemos experimentado lo que sucede en una calle concurrida durante hora pico. Cuando hay más automóviles de los que los carriles de tráfico pueden manejar, todos

los coches se mueven más lentamente. Todos quieren llegar a algún lugar al mismo tiempo, por lo que todos tienen que esperar más para llegar allí. Para gestionar mejor el flujo, necesitamos regular la entrada de vehículos en el flujo de tráfico o aumentar el número de carriles de tráfico donde la congestión es mayor. Al igual que los automóviles en el tráfico, los elementos de trabajo de desarrollo se mueven más lentamente si los desarrolladores intentan abordarlos todos a la vez. Trabajar en una cosa a la vez e identificar y eliminar restricciones aumenta el flujo de todos los elementos a través del sistema. La medición de los tiempos de ciclo y plomo ayuda a los equipos ágiles a monitorear su gestión del flujo. Un equipo determina el tiempo de espera mediante el seguimiento de la cantidad de tiempo que tarda una solicitud para que la funcionalidad vaya desde que llega a la cola hasta que se completa. Conocen el tiempo del ciclo mediante el seguimiento del tiempo desde que comienza el trabajo hasta que se completa. Y el equipo ágil optimiza el flujo al identificar y eliminar los cuellos de botella que evitan que disminuyan los tiempos de ciclo y de plomo.

Para respaldar las buenas prácticas de desarrollo de productos, recuerde lo siguiente:

» No desarrolle funciones que es poco probable que utilice.

» Haga que el equipo de desarrollo sea central para el proyecto porque agrega el mayor valor.

» Haga que los clientes prioricen las funciones: saben qué es lo más importante para ellos. Aborde primero los elementos de alta prioridad para ofrecer valor.

» Utilice herramientas que respalden una excelente comunicación entre todas las partes. Hoy en día, los principios lean continúan influyendo en el desarrollo de técnicas ágiles y siendo influenciados por ellas. Cualquier enfoque debe ser ágil y adaptarse con el tiempo.

PARTE 2 Ser ágil

Una descripción general de scrum Scrum, el marco ágil más popular en el desarrollo de software, es un enfoque iterativo que tiene en su núcleo el pique ( el término scrum para iteración). Para respaldar este proceso, los equipos de scrum utilizan roles, artefactos y eventos específicos. Para asegurarse de que cumplen los objetivos de cada parte del proceso, los equipos de scrum utilizan la inspección y la adaptación a lo largo del proyecto. El enfoque de scrum se muestra en la Figura 4-4.

FIGURA 4-4: El scrum Acercarse.

Recorriendo la distancia con el sprint Dentro de cada sprint, el equipo de desarrollo desarrolla y prueba una parte funcional del producto hasta que el propietario del producto lo acepta, a menudo a diario, y la funcionalidad se convierte en un incremento potencialmente entregable del producto general. Cuando termina un sprint, comienza otro sprint. El lanzamiento de la funcionalidad al mercado a menudo ocurre al final de múltiples sprints, cuando el propietario del producto determina que existe suficiente valor. Sin embargo, el propietario del producto puede decidir lanzar la funcionalidad después de cada sprint, o incluso tantas veces como sea necesario durante un sprint.

Un principio fundamental del sprint es su naturaleza cíclica: el sprint, así como los procesos dentro de él, se repiten una y otra vez, como se muestra en la Figura 4-5. Usas los principios de inspección y adaptación a diario como parte de un proyecto scrum:

» Durante un sprint, realizas inspecciones constantes para evaluar el progreso hacia el objetivo del sprint y, en consecuencia, hacia el objetivo de lanzamiento.

» Tienes un scrum diario reunión para organizar el día revisando lo que equipo completado ayer y coordinando en qué trabajará hoy.

Esencialmente, el equipo de scrum inspecciona su progreso hacia la meta del sprint.

» Al final del sprint, usa un Sprint retrospectiva reunión para evaluar rendimiento y planificar las adaptaciones necesarias.

CAPÍTULO 4 Enfoques ágiles

FIGURA 4-5: Los sprints son

periódico Procesos.

Estas inspecciones y adaptaciones pueden parecer formales y cargadas de procesos, pero no lo son. Utilice la inspección y la adaptación para resolver problemas y no piense demasiado en este proceso. El problema que está tratando de resolver hoy cambiará a menudo en el futuro de todos modos.

Comprender los roles, los artefactos y los eventos de scrum El marco de scrum define roles, artefactos y eventos específicos para proyectos. Scrum's tres roles - personas en el proyecto - son las siguientes:

» Dueño del producto: Representa y habla por las necesidades comerciales del proyecto.

» Equipo de desarrollo: Realiza el trabajo del día a día. El equipo de desarrollo es dedicado al proyecto y cada miembro del equipo es varios expertos - es decir,

aunque los miembros del equipo pueden tener ciertas fortalezas, cada miembro es capaz de realizar múltiples trabajos en el proyecto.

» Scrummaster: Protege al equipo de distracciones organizacionales, aclara

obstáculos, asegura que el scrum se juegue correctamente y mejora continuamente

el entorno del equipo.

PARTE 2 Ser ágil

Además, los equipos de scrum descubren que son más efectivos y eficientes cuando trabajan en estrecha colaboración con dos roles no específicos de scrum:

» Partes interesadas: Cualquiera que se vea afectado por el proyecto o participe en él. Aunque las partes interesadas no son roles oficiales de scrum, es esencial para scrum equipos y partes interesadas para trabajar en estrecha colaboración a lo largo de un proyecto.

» Agilementor: Una autoridad experimentada en técnicas ágiles y scrum. marco de referencia. A menudo, esta persona es externa al departamento del proyecto o

organización, para que él o ella pueda apoyar al equipo de scrum objetivamente con el punto de vista externo. De la misma manera que scrum tiene roles específicos, scrum también tiene tres entregables tangibles, llamados artefactos:

» Pila de Producto: La lista completa de requisitos que define el producto, a menudo

documentado en términos de valor comercial desde la perspectiva del usuario final. La acumulación de productos puede ser fluida durante todo el proyecto. Todos los elementos del alcance, independientemente del nivel de detalle, se encuentran en la cartera de productos. El propietario del producto es dueño de la cartera de productos, determinando qué incluye y en qué prioridad.

» Cartera de Sprint: La lista de requisitos y tareas en un sprint determinado. La El propietario del producto y el equipo de desarrollo seleccionan los requisitos para el

Sprint en la planificación de Sprint, con el equipo de desarrollo dividiendo estos requisitos en tareas. A diferencia del backlog del producto, el backlog del sprint solo puede ser cambiado por el equipo de desarrollo.

» Incremento de producto: La funcionalidad utilizable y potencialmente enviable. Ya sea el producto es un sitio web o una casa nueva, el incremento del producto debe ser lo suficientemente completo para demostrar su funcionalidad de trabajo. Un scrumproject se completa después de que un producto contiene suficiente funcionalidad de envío para cumplir con los objetivos comerciales del cliente para el proyecto.

Finalmente, scrum también tiene cinco eventos:

» Pique: Término de Scrum para la iteración. La pique es el contenedor para cada uno de los otros eventos de scrum, en los que el equipo de scrum crea

funcionalidad. Los sprints son ciclos cortos, no más de un mes, típicamente entre una y dos semanas, y en algunos casos tan cortos como un día. La duración constante del sprint reduce la varianza; un equipo de scrum puede extrapolar con confianza lo que puede hacer en cada sprint basándose en lo que ha logrado en sprints anteriores. Los Sprints brindan a los equipos de scrum la oportunidad de realizar ajustes para la mejora continua de inmediato, en lugar de al final del proyecto.

CAPÍTULO 4 Enfoques ágiles

» Planificación de Sprint: Tiene lugar al comienzo de cada sprint. En planificación de sprints reuniones, los equipos de scrum deciden qué objetivo, alcance y tareas de apoyo serán parte de la acumulación de Sprint.

» Scrum diario: Tiene lugar todos los días durante no más de 15 minutos. Durante el diario scrum, los miembros del equipo de desarrollo hacen tres declaraciones:

• • •

Lo que el miembro del equipo completó ayer En qué trabajará el miembro del equipo hoy Una lista de elementos que impiden al miembro del equipo.

El scrummaster también participa en el contexto de los impedimentos que está trabajando para eliminar para los desarrolladores.

» Revisión de Sprint: Tiene lugar al final de cada sprint. En esta reunión, el

El equipo de desarrollo demuestra a las partes interesadas y a toda la organización. ción de las partes aceptadas del producto que el equipo completó durante el sprint. La clave para la revisión del sprint es recopilar comentarios de las partes interesadas, lo que informa al propietario del producto cómo actualizar la cartera de pedidos del producto y considerar el próximo objetivo del sprint.

» Retrospectiva de Sprint: Tiene lugar al final de cada sprint. El sprint retro Spective es una reunión de equipo interna en la que los miembros del equipo scrum (producto

propietario, equipo de desarrollo y scrummaster) discuten qué salió bien durante el sprint, qué no funcionó bien y cómo pueden hacer mejoras para el siguiente sprint. Esta reunión está orientada a la acción (las frustraciones deben desahogarse en otra parte) y termina con planes de mejora tangibles para el próximo sprint.

Scrum es simple: tres roles, tres artefactos y cinco eventos. Cada uno juega un papel para asegurar que el equipo de scrum tenga transparencia, inspección y adaptación continuas a lo largo del proyecto. Como marco, scrum se adapta a muchas otras técnicas, métodos y herramientas ágiles para ejecutar los aspectos técnicos de la funcionalidad de construcción.

Una descripción general de la programación extrema Un enfoque popular para el desarrollo de productos, específico para software, es la programación extrema (XP). La programación extrema lleva las mejores prácticas de desarrollo de software a un nivel extremo. Creado en 1996 por Kent Beck, con la ayuda de Ward Cunningham y Ron Jeffries, los principios de XP se describieron originalmente en el libro de Beck de 1999, Explicación de la programación extrema ( Addison-Wesley Professional), que desde entonces se ha actualizado.

PARTE 2 Ser ágil

CREDENCIALES ESENCIALES Si es, o quiere ser, un profesional ágil, puede considerar obtener una o más certificaciones ágiles. La capacitación de certificación por sí sola puede proporcionar información valiosa y la oportunidad de practicar procesos ágiles, lecciones que puede utilizar en su trabajo diario. Muchas organizaciones desean contratar personas con conocimientos ágiles comprobados, por lo que la certificación también puede impulsar su carrera.

Puede elegir entre varias certificaciones de nivel de entrada bien reconocidas, incluidas las siguientes:

•

ScrumMaster certificado (CSM): ScrumAlliance, una organización profesional que promueve la comprensión y el uso de scrum, ofrece una certificación para scrum Maestros. El CSM requiere una clase de capacitación de dos días, proporcionada por un Entrenador de Scrum Certificado (CST) y completando una evaluación de CSM. La capacitación de CSM proporciona una visión general de scrum y es un buen punto de partida para las personas que comienzan su viaje ágil.

Ver http://scrumalliance.org.

•

Propietario certificado del producto Scrum (CSPO): ScrumAlliance también proporciona una certificación para los propietarios de productos. Al igual que el CSM, el CSPO requiere dos días de capacitación. de un CST. La capacitación de CSPO proporciona una inmersión profunda en el rol del propietario del producto. Ver

http://scrumalliance.org.

•

Desarrollador Scrum Certificado (CSD): Para los miembros del equipo de desarrollo, Scrum Alliance ofrece el CSD. El CSD es una certificación de seguimiento técnico que requiere cinco días. de formación a partir de un CST y superación de un examen en técnicas de ingeniería ágil. La capacitación de CSM o CSPO puede contar para un CSD; los tres días restantes son técnicos

curso de habilidades. Ver http://scrumalliance.org.

•

Practicante certificado de PMI Agile (PMI-ACP): El Project Management Institute (PMI) es la organización profesional de directores de proyectos más grande del mundo. En 2012, PMI introdujo la certificación PMI-ACP. El PMI-ACP requiere capacitación, experiencia general en gestión de proyectos, experiencia trabajando en proyectos ágiles y aprobar un examen sobre sus conocimientos de los fundamentos ágiles. Ver http://pmi.org.

El enfoque de la programación extrema es la satisfacción del cliente. Los equipos de XP logran una alta satisfacción del cliente al desarrollar funciones cuando el cliente las necesita. Las nuevas solicitudes son parte de la rutina diaria del equipo de desarrollo, y el equipo está facultado para lidiar con estas solicitudes cada vez que surgen. El equipo se organiza en torno a cualquier problema que surja y lo resuelve de la manera más eficiente posible.

CAPÍTULO 4 Enfoques ágiles

A medida que XP ha crecido como práctica, los roles de XP se han difuminado. Un proyecto típico ahora consta de personas en los grupos de soporte de proyectos, técnicos, de gestión y de clientes. Cada persona puede desempeñar un papel diferente en diferentes momentos.

Descubriendo principios de programación extremos Los enfoques básicos en la programación extrema se basan en principios ágiles. Estos enfoques son los siguientes:

» La codificación es la actividad principal. El código de software no solo ofrece la solución, sino también se puede utilizar para explorar problemas. Por ejemplo, un programador puede explicar un problema utilizando código.

» Los equipos de XP hacen muchas pruebas. Si hacer solo una pequeña prueba le ayuda a identificar algunos defectos, muchas pruebas le ayudarán a encontrar más. De hecho, los desarrolladores no

comience a codificar hasta que hayan resuelto los criterios de éxito para el requisito y hayan diseñado las pruebas unitarias. Un defecto no es una falla de código; es un fracaso para definir la prueba correcta.

» La comunicación entre el cliente y el programador es directa. La

El programador debe comprender los requisitos comerciales para diseñar una solución técnica.

» Para sistemas complejos, algún nivel de diseño general, más allá de cualquier

función, es necesaria. En los proyectos XP, el diseño general se considera durante refactorización A saber, utilizar el proceso de mejora sistemática del código para mejorar la legibilidad, reducir la complejidad, mejorar la capacidad de mantenimiento y garantizar la extensibilidad en toda la base del código.

Puede encontrar una programación extrema combinada con lean o scrum porque los elementos del proceso son tan similares que combinan bien.

Conociendo algunas prácticas extremas de programación En XP, algunas prácticas son similares a otros enfoques ágiles, pero otras no lo son. La Tabla 4-1 enumera algunas prácticas clave de XP, la mayoría de las cuales son prácticas de sentido común y muchas de las cuales se reflejan en principios ágiles.

La programación extrema empuja intencionalmente los límites de las costumbres del desarrollo al aumentar drásticamente la intensidad de los rituales de mejores prácticas, lo que ha resultado en un sólido historial de XP que mejora la eficiencia y el éxito del desarrollo.

PARTE 2 Ser ágil

TABLA 4-1

Prácticas clave de la programación extrema

Práctica XP

Supuesto subyacente

Juego de planificación

Todos los miembros del equipo deben participar en la planificación. No existe desconexión entre el personal técnico y el empresarial.

Todo el equipo

El cliente debe estar ubicado (ubicado físicamente junto) con el equipo de desarrollo y estar disponible. Esta accesibilidad permite al equipo hacer más preguntas menores, obtener respuestas rápidamente y, en última instancia, entregar un producto más alineado con las expectativas del cliente.

Estándares de codificación

Utilice estándares de codificación para capacitar a los desarrolladores para que tomen decisiones y mantengan la coherencia en todo el producto; no reinvente constantemente los conceptos básicos de cómo desarrollar productos en su organización. Los identificadores de código estándar y las convenciones de nomenclatura son dos ejemplos de estándares de codificación.

Metáfora del sistema

Cuando describa cómo funciona el sistema, utilice una comparación implícita, una historia simple que se entienda fácilmente (por ejemplo, "el sistema es como cocinar una comida"). Esto proporciona un contexto adicional al que el equipo puede recurrir en todas las actividades y discusiones de descubrimiento de productos.

Colectivo

Todo el equipo es responsable de la calidad del código. La propiedad compartida y la

propiedad del código

responsabilidad generan los mejores diseños y la más alta calidad. Cualquier ingeniero puede modificar el código de otro ingeniero para permitir que el progreso continúe.

Marcha sostenible

Las personas con exceso de trabajo no son efectivas. Demasiado trabajo conduce a errores, lo que conduce a más trabajo, lo que conduce a más errores. Evite trabajar más de 40 horas a la semana durante un período de tiempo prolongado.

Programación en pareja

Dos personas trabajan juntas en una tarea de programación. Una persona es estratégica (el conductor) y una persona es táctica (el navegador). Explican su enfoque el uno al otro. Ningún fragmento de código es entendido por una sola persona. Los defectos se pueden encontrar y corregir más fácilmente antes de fusionar e integrar el código con el sistema.

Mejora de diseño

Mejore continuamente el diseño refactorizando el código, eliminando duplicaciones e ineficiencias dentro del código. Una base de código ajustada es más simple de mantener y funciona de manera más eficiente.

Diseño simple

Cuanto más simple sea el diseño, menor será el costo de cambiar el código del software.

Impulsado por pruebas

Escriba pruebas unitarias y de aceptación del cliente automatizadas antes de codificar cualquier cosa. Escriba una

desarrollo (TDD)

prueba, ejecútela y observe cómo falla. Luego, escriba el código suficiente para que la prueba pase, refactorizando hasta que lo haga (rojo-verde-limpio). Pon a prueba tu éxito antes de afirmar que has progresado.

Continuo

Los miembros del equipo deberían trabajar con el código más reciente. Integre componentes de código

integración

en todo el equipo de desarrollo con la mayor frecuencia posible para identificar problemas y tomar medidas correctivas antes de que los problemas se acumulen entre sí.

Pequeños lanzamientos

Libera valor al cliente con la mayor frecuencia posible. Algunas organizaciones lanzan diariamente. Evite acumular grandes almacenes de código inédito que requieran esfuerzos extensos de regresión e integración riesgosos. Obtenga comentarios de su cliente lo antes posible, con la mayor frecuencia posible.

CAPÍTULO 4 Enfoques ágiles

Poniendolo todo junto Los tres enfoques ágiles, esbelto, scrum y programación extrema (XP), tienen hilos en común. Lo más importante que tienen estos enfoques en común es la adherencia al Manifiesto Ágil y los 12 Principios Ágiles. La Tabla 4-2 muestra algunas similitudes más entre los tres enfoques.

TABLA 4-2

Similitudes entre la programación Lean, Scrum y Extreme

Inclinarse

Melé

Programación extrema

Involucrar a todos

Equipo de desarrollo multifuncional

Todo el equipo

Propiedad colectiva Optimizando el conjunto

Incremento de producto

Desarrollo impulsado por pruebas

Integración continua Entrega rápida

Sprints de cuatro semanas o menos

Pequeño lanzamiento

Además de marcos y prácticas ágiles más extensos, scrum también se adapta a una variedad de pertrechos que aumentan constantemente el éxito con proyectos ágiles. Al igual que una casa física está enmarcada para soportar las características de plomería, electricidad, ventilación y conveniencia interna, scrum proporciona el marco para muchas otras herramientas y técnicas ágiles para hacer bien el trabajo. Aquí hay una muestra, la mayoría de la cual aprenderá más en los siguientes capítulos:

» Declaración de visión del producto (discurso de ascensor, clara declaración de dirección para alcanzando el límite exterior del proyecto)

» Hoja de ruta del producto (una representación de las características necesarias para lograr el visión del producto)

» Velocity (una herramienta para que los equipos de scrum planifiquen la carga de trabajo para cada sprint y predecir empíricamente la entrega de funcionalidad a largo plazo)

» Planificación de lanzamientos (establecimiento de un objetivo de rango medio específico, el lanzando funcionalidad al mercado)

» Historias de usuario (estructurar los requisitos desde el punto de vista del usuario final para aclarar el valor comercial)

» Estimación relativa (utilizando la complejidad y el esfuerzo relativos autocorregibles en lugar de que medidas absolutas inexactas, que dan una falsa sensación de precisión)

» Enjambre (equipos multifuncionales que trabajan juntos en un requisito a tiempo hasta la finalización para hacer el trabajo más rápido)

PARTE 2 Ser ágil

EN ESTE CAPÍTULO » Creando su espacio de trabajo ágil » Redescubriendo la baja tecnología

comunicación y uso del derecho comunicación de alta tecnología » Encontrar y utilizar las herramientas que necesita

Capítulo

Entornos ágiles en acción

parece la siguiente configuración. El equipo de TI se encuentra en una ciudad cúbica en

un área departamental con elde gerente de proyecto en algún a poca distancia. Obtenga una imagen mental su entorno de trabajo actual.lugar Quizás Trabaja con un equipo de desarrollo offshore a ocho zonas horarias de distancia. El negocio el cliente está al otro lado del edificio. Su gerente tiene una pequeña oficina escondida en algún lugar. Las salas de conferencias suelen estar completamente reservadas, e incluso si entraras en una, alguien te perseguiría en una hora. Los documentos de su proyecto se almacenan en carpetas en una unidad compartida. El equipo de desarrollo

recibe al menos 100 correos electrónicos al día. El director del proyecto lleva a cabo una reunión de equipo cada semana y, refiriéndose al plan del proyecto, les dice a los desarrolladores en qué deben trabajar. El director del proyecto también crea un informe de estado semanal y lo publica en la unidad compartida. El gerente de producto generalmente está demasiado ocupado para hablar con el gerente de proyecto para revisar el progreso, pero periódicamente envía correos electrónicos con algunas ideas nuevas sobre la aplicación.

Aunque es posible que la descripción de los párrafos anteriores no describa su situación particular, puede ver algo parecido en cualquier entorno corporativo dado. Los equipos ágiles, sin embargo, ejecutan proyectos en ciclos iterativos cortos y enfocados, confiando en la retroalimentación oportuna de los miembros del equipo del proyecto. Para operar y ser más ágil, su entorno de trabajo tendrá que cambiar.

CAPÍTULO 5 Entornos ágiles en acción

Este capítulo le muestra cómo crear un espacio de trabajo que facilite la comunicación, uno que lo ayudará a ser más ágil.

Creando el entorno físico Los equipos de proyectos ágiles prosperan cuando los miembros del equipo scrum trabajan en estrecha colaboración en un entorno que respalda el proceso. Como se señaló en otros capítulos, los miembros del equipo de desarrollo son fundamentales para el éxito de los proyectos ágiles. Crear el entorno adecuado para que operen es un gran avance para respaldar su éxito. Incluso puede contratar personas que se especialicen en diseñar entornos de trabajo óptimos y ágiles.

Colocando el equipo Si es posible, el equipo de scrum debe ser colocado —Es decir, ubicados físicamente juntos. Cuando se coloca un equipo de scrum, las siguientes prácticas son posibles y aumentan significativamente la eficiencia y la eficacia:

» Comunicarse cara a cara » De pie físicamente, en lugar de sentarse, como grupo para el scrum diario. reunión (esto hace que las reuniones sean breves y centradas en el tema)

» Uso de herramientas de comunicación sencillas y de baja tecnología

» Obtener aclaraciones en tiempo real de los miembros del equipo scrum

» Ser consciente de lo que otros están haciendo.

» Pedir ayuda con una tarea » Apoyar a otros con sus tareas

Todas estas prácticas sustentan procesos ágiles. Cuando todos residen en la misma área, es mucho más fácil para una persona inclinarse, hacer una pregunta y obtener una respuesta inmediata. Si la pregunta es compleja, una conversación cara a cara, con toda la sinergia que crea, es mucho más productiva que un intercambio de correo electrónico. Esta mejora en la efectividad de la comunicación se debe a fidelidad en la comunicación - el grado de exactitud entre el significado pretendido y el significado interpretado. Albert Mehrabian, Ph.D., profesor de UCLA, ha demostrado que para la comunicación compleja e incongruente, el 55 por ciento del significado es transmitido por el cuerpo físico.

PARTE 2 Ser ágil

idioma, el 38 por ciento se transmite a través de la interpretación de la tonalidad de voz específica de la cultura, y solo el 7 por ciento se transmite mediante palabras. Eso es algo que debe tener en cuenta durante su próxima conferencia telefónica de voz sobre IP o teléfono inteligente para discutir los matices del diseño de un sistema que no existe.

Alistair Cockburn, uno de los signatarios del Manifiesto Ágil, creó el gráfico de la Figura 5-1. Este gráfico muestra la efectividad de diferentes formas de comunicación. Observe la diferencia de efectividad entre la comunicación en papel y dos personas en una pizarra: con la colocación, obtiene el beneficio de una mejor comunicación.

FIGURA 5-1: Mejor comunicación mediante

colocación.

Configurar un área dedicada Si los miembros del equipo de scrum se encuentran en el mismo lugar físico, desea crear un entorno de trabajo lo más ideal posible para ellos. El primer paso es crear un área dedicada.

Establezca un entorno en el que el equipo de scrum pueda trabajar en estrecha proximidad física. Si es posible, el equipo de scrum debe tener su propia sala, a veces llamada sala de proyectos o un sala de scrum. Los miembros del equipo de scrum crean la configuración que necesitan en esta sala de proyectos, colocan pizarrones y tableros de anuncios en las paredes y mueven los muebles. Al organizar el espacio para la productividad, se convierte en parte de su funcionamiento. Si no es posible una habitación separada, vaina —Con espacios de trabajo alrededor de los bordes y una mesa o centro de colaboración en el medio — funciona bien.

CAPÍTULO 5 Entornos ágiles en acción

Si estás atrapado en la ciudad de los cubos y no puedes derribar muros, pide algunos cubos vacíos en un grupo y quita los paneles divisorios. Cree un espacio que pueda tratar como su sala de proyectos. El espacio adecuado permite que el equipo de scrum esté completamente inmerso en la resolución de problemas y la elaboración de soluciones.

La situación en la que se encuentra puede estar lejos de ser perfecta, pero vale la pena el esfuerzo para ver qué tan cerca puede llegar al ideal. Antes de iniciar una transición ágil en su organización, solicite a la gerencia los recursos necesarios para crear una condición óptima. Los recursos variarán de un proyecto a otro, pero como mínimo, pueden incluir pizarras, tableros de anuncios, marcadores, chinchetas y notas adhesivas. Se sorprenderá de lo rápido que las ganancias de eficiencia pagan la inversión y más. Por ejemplo, con una empresa cliente, dedicar una sala de proyectos y realizar una inversión de $ 6,000 en múltiples monitores para desarrolladores aumentó la productividad, lo que le ahorró a la empresa casi dos meses y $ 60,000 durante la vida del proyecto. Eso es un retorno bastante bueno de una simple inversión. Le mostramos cómo cuantificar estos ahorros al principio del proyecto en el Capítulo 13.

Eliminando distracciones El equipo de desarrollo necesita enfocarse, enfocarse, enfocarse. Los métodos ágiles están diseñados para crear estructura para un trabajo altamente productivo realizado de una manera específica. La mayor amenaza para esta productividad es la distracción, como. . . espera un minuto, necesito atender una llamada.

Bien estoy de vuelta. La buena noticia es que un equipo ágil tiene a alguien dedicado a desviar o eliminar distracciones: el scrum master. Ya sea que vaya a asumir un rol de scrum master o algún otro rol, debe comprender qué tipo de distracciones pueden desviar al equipo de desarrollo y cómo manejarlas. La Tabla 5-1 es una lista de distracciones comunes y lo que se debe y no se debe hacer para lidiar con las distracciones.

Las distracciones minan el enfoque, la energía y el rendimiento del equipo de desarrollo. El scrum master necesita fuerza y coraje para gestionar y desviar las interrupciones. Cada distracción evitada es un paso hacia el éxito.

PARTE 2 Ser ágil

TABLA 5-1

Distracciones comunes Hacer

Múltiples proyectos

Asegúrese de que el equipo de desarrollo esté dedicado al 100 por ciento a un solo proyecto a la vez.

No fragmente el equipo de desarrollo entre varios proyectos, soporte de operaciones y tareas especiales.

Multitarea

Mantenga al equipo de desarrollo enfocado en una sola

No permita que el equipo de desarrollo cambie

tarea, idealmente desarrollando una pieza de

entre requisitos. El cambio de tareas crea una

funcionalidad a la vez. Un tablero de tareas puede

enorme sobrecarga (un mínimo del 30 por

ayudar a realizar un seguimiento de las tareas en curso

ciento) en la pérdida de productividad.

Distracción

e identificar rápidamente si alguien está trabajando en varias tareas a la vez.

pueden organizarse ellos mismos. Observe cómo se

No interfiera con el equipo de desarrollo ni permita que otros lo hagan. El scrummeeting diario ofrece una amplia

dispara su productividad.

oportunidad de evaluar el progreso.

Fuera de

Redirija los distractores. Si surge una nueva tarea fuera

No se meta con los miembros del equipo de

influencias

del objetivo del sprint, pídale al propietario del producto

desarrollo y su trabajo. Están persiguiendo el

que decida si vale la pena sacrificar el sprint por la

objetivo del sprint, que es la máxima prioridad

prioridad de la tarea.

durante un sprint activo. Incluso una tarea

funcionalidad.

aparentemente rápida puede interrumpir el trabajo

Encima-

Deje tranquilos a los miembros del equipo de desarrollo

supervisando

después de colaborar en los objetivos de iteración;

durante todo un día.

Gestión

Proteja al equipo de desarrollo de las solicitudes

No permita que la administración afecte

directas de la gerencia (a menos que la gerencia

negativamente la productividad del equipo de

quiera darles a los miembros del equipo una

desarrollo. Hacer de la interrupción del equipo de

bonificación por su excelente desempeño).

desarrollo el camino de mayor resistencia.

Goingmobile A juzgar por el encabezado "Pasando a la tecnología móvil", es posible que haya pensado que esta sección trataba sobre teleconferencias con teléfonos inteligentes, pero no lo es. Los equipos de proyectos ágiles adoptan un enfoque receptivo y los miembros del equipo scrum requieren un entorno que les ayude a responder a las necesidades del proyecto del día. Un entorno de equipo ágil debe ser móvil, literalmente:

» Utilice escritorios y sillas móviles para que las personas puedan moverse y reconfigurarse. Ure el espacio.

» Obtenga computadoras portátiles conectadas de forma inalámbrica para que los miembros del equipo de scrum puedan elegirlas y muévalos fácilmente.

» Tenga una pizarra móvil grande. Consulte también la siguiente sección sobre tecnología baja. comunicación.

CAPÍTULO 5 Entornos ágiles en acción

Con este entorno móvil, los miembros del equipo scrum pueden configurar y reconfigurar su disposición según sea necesario. Dado que los miembros del equipo scrum trabajarán con diferentes miembros día a día, la movilidad es importante. El mobiliario fijo tiende a dictar las comunicaciones que se producen. Ser móvil permite una colaboración más libre y más libertad en general.

Comunicación de baja tecnología Cuando se coloca un equipo de scrum, los miembros pueden comunicarse en persona con facilidad y fluidez. Particularmente cuando comienza su transición ágil, desea mantener las herramientas de comunicación de baja tecnología. Confíe en las conversaciones cara a cara y en papel y bolígrafo a la antigua. La baja tecnología promueve la informalidad, lo que permite que los miembros del equipo scrum sientan que pueden cambiar los procesos de trabajo y ser innovadores a medida que aprenden sobre el producto.

La principal herramienta de comunicación debe ser la conversación cara a cara. Abordar los problemas en persona es la mejor manera de acelerar la producción:

» Tenga reuniones cortas diarias en persona. Algunos equipos de scrum se paran durante una reunión para disuadirla de que dure más de 15 minutos.

» Haga preguntas al propietario del producto. Además, asegúrese de que esté involucrado en discusiones sobre las características del producto para proporcionar claridad cuando sea necesario. La la conversación no debe terminar cuando termina la planificación.

» Comuníquese con sus compañeros de trabajo. Si tiene preguntas sobre las funciones, el progreso del proyecto, o la integración, comunicarse con los compañeros de trabajo. La

Todo el equipo de desarrollo es responsable de crear el producto y los miembros del equipo deben hablar durante todo el día.

Siempre que el equipo de scrum esté cerca, puede usar enfoques físicos y visuales para mantener a todos en la misma página. Las herramientas deben permitir que todos vean

» El objetivo del sprint » La funcionalidad necesaria para lograr el objetivo del sprint.

» Qué se ha logrado en el sprint » ¿Qué viene después en el sprint?

PARTE 2 Ser ágil

» Quién está trabajando en qué tarea

» Lo que queda por hacer Solo se necesitan algunas herramientas para respaldar esta comunicación de baja tecnología:

» Una pizarra o dos (idealmente, móviles, con ruedas o livianas). Nada supera a una pizarra para la colaboración. El equipo de scrum puede usar uno para lluvia de ideas sobre soluciones o intercambio de ideas.

» Una gran cantidad de notas adhesivas en diferentes colores (incluidas las del tamaño de un póster para comunicar información crítica que desea que sea fácilmente visible, como arquitectura, estándares de codificación y definición del proyecto de hecho). Un favorito personal es darle a cada desarrollador al menos una combinación de almohadilla de base de borrado en seco / nota adhesiva de mesa, con un caballete liviano. Estas herramientas de bajo costo facilitan la comunicación de manera fantástica.

» Muchos bolígrafos de colores.

» Una tarea específica de sprint o un tablero kanban (descrito en los Capítulos 4 y 9) para seguimiento de la tactilidad del progreso.

Si decide tener un tablero kanban específico para sprints, use notas adhesivas para representar unidades de trabajo características desglosadas en tareas). Para su plan de trabajo, puede colocar notas adhesivas en una superficie grande (una pared o su segunda pizarra), o puede usar una pizarra kanban con tarjetas. Puede personalizar un tablero kanban de muchas maneras, como usar notas adhesivas de diferentes colores para diferentes tipos de tareas, etiquetas adhesivas de bandera roja para funciones que tienen un impedimento y etiquetas adhesivas de miembros del equipo para ver fácilmente quién está trabajando en qué tarea.

Un radiador de información es una herramienta que muestra información físicamente al equipo scrum y a cualquier otra persona en el área de trabajo del equipo scrum. Los radiadores de información incluyen pizarras kanban, pizarras blancas, tablones de anuncios, gráficos de quemado, que muestran el estado de la iteración y cualquier otro signo con detalles sobre el proyecto, el producto o el equipo de scrum.

Básicamente, mueve notas adhesivas o tarjetas por el tablero para mostrar el estado (consulte la Figura 5-2). Todo el mundo sabe cómo leer la pizarra y cómo actuar en función de lo que muestra. En el Capítulo 9, encontrará los detalles de qué poner en las tablas. Independientemente de las herramientas que utilice, evite perder tiempo haciendo que las cosas se vean perfectamente ordenadas y bonitas. Formalidad en el diseño y la presentación (lo que podría llamar pompa)

Puede dar la impresión de que el trabajo está ordenado y elegante. Sin embargo, el trabajo es lo que importa, así que concentre su energía en actividades que apoyen el trabajo.

CAPÍTULO 5 Entornos ágiles en acción

FIGURA 5-2: Una tarea de scrum

tablero en una pared

o pizarra.

Comunicación de alta tecnología Aunque la colocación mejora casi universalmente la efectividad, muchos equipos de scrum no se pueden colocar. Algunos proyectos tienen compañeros de equipo dispersos en varias oficinas; otros tienen equipos de desarrollo offshore en todo el mundo. Si tiene varios equipos de scrum geográficamente dispersos, intente primero reasignar el talento existente para formar equipos de scrum ubicados dentro de cada ubicación geográfica. Si este movimiento no es posible, no renuncie a una transición ágil. En su lugar, simule la colocación tanto como sea posible. Cuando los miembros del equipo scrum trabajan en diferentes lugares, debe hacer un mayor esfuerzo para establecer un entorno que cree una sensación de conexión. Para abarcar distancias y zonas horarias, necesita mecanismos de comunicación más sofisticados.

PARTE 2 Ser ágil

¡NO REINVENTES LA RUEDA! En el pasado, los procesos de fabricación a menudo implicaban el envío de artículos parcialmente terminados a otra ubicación para su finalización. En estas situaciones, el tablero kanban en la pared de una fábrica en la primera ubicación necesitaba ser visto por la gerencia de la planta en la segunda ubicación. El software de tablero electrónico kanban se desarrolló para resolver este problema, pero, curiosamente, el software se veía literalmente como un tablero kanban en la pared y se usaba de la misma manera. No arregle lo que ya está funcionando.

Al determinar qué tipos de herramientas de comunicación de alta tecnología apoyar, primero considere la pérdida de discusiones cara a cara. Algunas herramientas que puede utilizar son las siguientes:

» Videoconferencias y cámaras web: Estas herramientas pueden crear una sensación de ser juntos. Si tiene que comunicarse de forma remota, al menos asegúrese de

pueden verse y escucharse claramente. El lenguaje corporal proporciona la mayor parte del mensaje.

» Mensajería instantánea: Aunque la mensajería instantánea no transmite mensajes no verbales

comunicación, es en tiempo real, accesible y fácil de usar. Varias personas pueden también comparte una sesión y comparte archivos.

» Uso compartido de escritorio basado en web: Especialmente para el equipo de desarrollo, compartiendo su escritorio le permite resaltar problemas y actualizaciones visualmente en tiempo real.

Siempre es mejor ver el problema que simplemente hablarlo por teléfono.

» Sitios web de colaboración: Estos sitios le permiten hacer de todo, desde compartir

documentación simple para que todos tengan la información más reciente para usar un

pizarra virtual para lluvia de ideas. El uso de un sitio de colaboración (como SharePoint, Confluence y Google Drive) le permite publicar documentos que muestran el estado del sprint. Cuando los gerentes solicitan actualizaciones de estado, simplemente puede dirigirlos al sitio de colaboración para obtener la información que necesitan, a pedido. Al actualizar estos documentos a diario, usted proporciona a los gerentes mejor información que la que tendrían con los procedimientos de informes de estado formalizados bajo un ciclo tradicional de administración de proyectos. Evite crear informes de estado separados para la administración; Estos informes duplican la información de los sprint burndowns y no respaldan la producción.

CAPÍTULO 5 Entornos ágiles en acción

Cuando tenga un sitio de colaboración con documentación compartida, no asuma que todos comprenden automáticamente todo en la documentación. Utilice un sitio de colaboración para asegurarse de que todo esté publicado, sea accesible y transparente, pero no permita que le dé a su equipo una falsa sensación de comprensión compartida.

Elegir herramientas Como se señaló a lo largo del capítulo, las herramientas de baja tecnología son las más adecuadas para proyectos ágiles, especialmente al principio, mientras que el equipo de scrum se acostumbra al proceso. En esta sección se analizan algunos puntos a considerar al elegir herramientas ágiles: el propósito de la herramienta y las limitaciones organizativas y de compatibilidad.

El propósito de la herramienta Al elegir herramientas, la pregunta principal que debe hacerse es: "¿Cuál es el propósito de la herramienta?" Las herramientas deben resolver un problema específico y apoyar procesos ágiles, cuyo enfoque es impulsar el trabajo. Sobre todo, no elijas nada más complicado de lo que necesitas. Algunas herramientas son sofisticadas y requiere tiempo para aprenderlas antes de poder usarlas para ser productivo. Si está trabajando con un equipo de scrum compartido, la capacitación y la adopción de prácticas ágiles pueden ser un desafío suficiente sin agregar un conjunto de herramientas complicadas a la combinación. Si está trabajando con un equipo de scrum dislocado, la introducción de nuevas herramientas puede ser aún más difícil.

Puede encontrar muchos sitios web, software y otras herramientas ágiles en el mercado. Muchos son útiles, pero no debe invertir en costosas herramientas ágiles en sus primeros días de implementación ágil. Esta inversión es innecesaria y agrega otro nivel de complejidad a la adopción. A medida que avanza en las primeras iteraciones y modifica su enfoque, el equipo de scrum comenzará a identificar los procedimientos que pueden mejorarse o deben cambiarse. Una de estas mejoras podría ser la necesidad de herramientas adicionales o de reemplazo. Cuando surge una necesidad de forma natural, del equipo scrum, encontrar apoyo organizacional para comprar las herramientas necesarias suele ser más fácil porque la necesidad puede estar vinculada a un problema del proyecto.

Organizacional y compatibilidad limitaciones

Más allá de las consideraciones iniciales señaladas en la sección anterior, las herramientas que elija deben operar en su organización. A menos que esté usando únicamente

PARTE 2 Ser ágil

herramientas no electrónicas, es probable que deba tener en cuenta las políticas de la organización con respecto al hardware, software y servicios, así como a la computación en la nube, la seguridad y los sistemas de telefonía.

Si forma parte de una organización distribuida, es posible que algunos equipos scrum no puedan admitir soluciones complejas, mantener las últimas versiones del software de escritorio o tener el ancho de banda de Internet sólido que da por sentado. La clave para crear un entorno ágil para equipos ágiles es hacerlo a nivel organizativo estratégico. Los equipos ágiles impulsan proyectos ágiles, por lo que debe contar con el liderazgo de su organización desde el principio para proporcionar herramientas que permitan a sus equipos tener éxito.

CAPÍTULO 5 Entornos ágiles en acción

EN ESTE CAPÍTULO

» Configurar roles ágiles

» Creando valores ágiles en tu organización » Transformando la filosofía de su equipo » Afilar habilidades importantes

Capítulo

Comportamientos ágiles en acción

organización para beneficiarse de las ventajas de rendimiento que permiten las técnicas ágiles. Conoces losanaliza diferentes roles en un ágil y vesque cómo En este capítulo, las dinámicas deproyecto comportamiento deben cambiar para su

Puede cambiar los valores y la filosofía de un equipo de proyecto sobre la gestión de proyectos. ment. Finalmente, discutimos algunas formas para que un equipo de proyecto perfeccione las habilidades clave para el éxito de un proyecto ágil.

Establecimiento de roles ágiles En el Capítulo 4, describimos scrum, uno de los frameworks ágiles más populares en uso en la actualidad. El marco de scrum define los roles ágiles comunes de una manera especialmente sucinta. Usamos términos de scrum para describir roles ágiles a lo largo de este libro. Estos roles son

» Dueño del producto

» Miembro del equipo de desarrollo

» Scrummaster El propietario del producto, el equipo de desarrollo y el scrum master juntos forman el

equipo de scrum. Cada rol es un par de los demás: nadie es el jefe de nadie más en el equipo.

CAPÍTULO 6 Comportamientos ágiles en acción

Los siguientes roles no forman parte del marco de scrum, pero siguen siendo de vital importancia para los proyectos ágiles:

» Partes interesadas

» Mentor ágil El equipo scrum junto con las partes interesadas conforman el ágil Grupo de proyecto. En el centro de todo está el equipo de desarrollo. El propietario del producto y el scrummaster cumplen roles que aseguran el éxito del equipo de desarrollo. La figura 6-1 muestra cómo encajan estos roles y equipos. Esta sección analiza estos roles en detalle.

FIGURA 6-1: Proyecto ágil equipo, scrum

equipo, y desarrollo equipo.

Dueño del producto El propietario del producto, a veces llamado el representante del cliente en entornos sin scrum, es responsable de cerrar las brechas entre el cliente, las partes interesadas del negocio y el equipo de desarrollo. El propietario del producto es un experto en el producto y en las necesidades y prioridades del cliente. El propietario del producto, que es un miembro del equipo de scrum, protege al equipo de desarrollo de las distracciones comerciales, trabaja con el equipo de desarrollo a diario para ayudar a aclarar los requisitos y acepta el trabajo completado durante el sprint en preparación para la revisión del sprint. Los propietarios de productos toman las decisiones sobre lo que incluye y no incluye el producto. Agregue a eso la responsabilidad de decidir qué lanzar al mercado y cuándo hacerlo, y verá que necesita una persona inteligente y experta para desempeñar este papel.

PARTE 2 Ser ágil

En un proyecto ágil, el propietario del producto

» Desarrollar la estrategia y la dirección del proyecto y establecer a largo y corto plazo metas a término.

» Proporcionar o tener acceso a experiencia en productos.

» Comprender y transmitir a los clientes y a otras partes interesadas del negocio necesidades del equipo de desarrollo.

» Reúna, priorice y gestione los requisitos del producto. » Asumir la responsabilidad del presupuesto y la rentabilidad del producto.

» Decida cuándo lanzar la funcionalidad completa. » Trabajar con el equipo de desarrollo a diario para responder preguntas y tomar decisiones.

» Acepte o rechace el trabajo completado, a medida que se completa, durante el sprint.

» Presente los logros del equipo scrum al final de cada sprint, antes el equipo de desarrollo demuestra estos logros.

¿Qué hace a un buen propietario de producto? Decisividad. Los buenos propietarios de productos comprenden al cliente a fondo y la organización los faculta para tomar decisiones comerciales difíciles todos los días. Aunque pueden recopilar los requisitos de las partes interesadas, los propietarios de productos conocen el producto por derecho propio. Pueden priorizar con confianza. Los buenos propietarios de productos interactúan bien con la comunidad de partes interesadas del negocio, el equipo de desarrollo y el scrum master. Son pragmáticos y pueden hacer concesiones basadas en la realidad. Son accesibles para el equipo de desarrollo y también solicitan lo que necesitan. Son pacientes, especialmente con las preguntas del equipo de desarrollo. La Tabla 6-1 describe las responsabilidades y las características coincidentes de un propietario de producto.

TABLA 6-1

Características de un buen propietario de producto

Responsabilidad

Un buen propietario de producto. . .

Estrategia del proyecto de suministros

Visualiza el producto terminado Entiende

y dirección Proporciona experiencia en productos

firmemente la estrategia de la empresa Ha trabajado con productos similares en el pasado. Comprende las necesidades de las personas que utilizarán el producto.

(continuado) CAPÍTULO 6 Comportamientos ágiles en acción

TABLA 6-1 ( continuado)

Responsabilidad

Un buen propietario de producto. . .

Entiende al cliente y

Comprende los procesos comerciales relevantes

otras necesidades de las partes interesadas

Crea un canal sólido de comentarios y aportes de los clientes Funciona bien con las partes interesadas del negocio

Gestiona y prioriza

Es decisivo

requisitos del producto

Se centra en la eficiencia Permanece flexible Convierte los comentarios de las partes interesadas en una valiosa funcionalidad centrada en el cliente

Es práctico para priorizar funciones valiosas desde el punto de vista financiero, funciones de alto riesgo y mejoras estratégicas del sistema. Protege al equipo de desarrollo de las distracciones comerciales (solicitudes de partes interesadas en competencia) Es responsable del presupuesto

Comprende qué características del producto pueden ofrecer el mejor retorno de la

y la rentabilidad.

inversión. Gestiona los presupuestos de forma eficaz

Decide las fechas de lanzamiento

Comprende las necesidades comerciales con respecto a los

Funciona con

plazos Es accesible para la aclaración diaria de los requisitos

Equipo de desarrollo

Trabaja con el equipo de desarrollo para comprender las capacidades Funciona bien con los desarrolladores Describe hábilmente las características del producto

Acepta o rechaza el trabajo

Comprende los requisitos y garantiza que las funciones completadas funcionen correctamente

Presenta obra completada

al final de cada sprint

Introduce claramente los logros del sprint antes de que el equipo de desarrollo demuestre la funcionalidad de trabajo del sprint.

El propietario del producto asume una gran cantidad de responsabilidades relacionadas con el negocio durante el proyecto. Aunque el patrocinador del proyecto financia y es dueño del presupuesto, el propietario del producto administra cómo se gasta el presupuesto.

Con un propietario de producto dedicado y decidido, el equipo de desarrollo tiene todo el soporte comercial que necesita para convertir los requisitos en funcionalidad de trabajo. La siguiente sección explica cómo el propietario del producto ayuda a garantizar que el equipo de desarrollo comprenda el producto que creará.

PARTE 2 Ser ágil

Miembro del equipo de desarrollo Los miembros del equipo de desarrollo son las personas que crean el producto. En el desarrollo de software, los programadores, probadores, diseñadores, escritores, ingenieros de datos y cualquier otra persona con un rol práctico en el desarrollo de productos son miembros del equipo de desarrollo. Con otros tipos de productos, los miembros del equipo de desarrollo pueden tener diferentes habilidades.

En un proyecto ágil, el equipo de desarrollo está

» Responsable directo de la creación de entregables del proyecto.

» Autoorganizado y autogestionado. Los miembros del equipo de desarrollo determinan minar sus propias tareas y cómo quieren completar esas tareas.

» Multifuncional. Colectivamente, el equipo de desarrollo imparte todas las habilidades necesarios para elaborar, diseñar, desarrollar, probar, integrar y documentar los requisitos mentos en la funcionalidad de trabajo.

» Varios expertos. Los miembros del equipo de desarrollo son versátiles, no están atados a un conjunto de habilidades únicas. Tienen habilidades existentes para contribuir de inmediato en el

comienzo del proyecto, pero también están dispuestos a aprender nuevas habilidades y a enseñar lo que saben a otros miembros del equipo de desarrollo.

» Idealmente dedicado a un proyecto durante la duración del proyecto.

» Idealmente colocado. El equipo debe trabajar en conjunto en la misma área de la misma oficina.

¿Qué hace a un buen miembro del equipo de desarrollo? Observe las responsabilidades del equipo y las características coincidentes en la Tabla 6-2.

TABLA 6-2

Características de un buen miembro del equipo de desarrollo

Responsabilidad

Un buen miembro del equipo de desarrollo. . .

Crea el producto

Disfruta creando productos

Está capacitado en más de uno de los trabajos necesarios para crear el Es autoorganizado y autogestionado.

producto Exuda iniciativa e independencia

Entiende cómo superar los impedimentos para alcanzar las metas Coordina el trabajo a realizar con el resto del equipo (continuado)

CAPÍTULO 6 Comportamientos ágiles en acción

TABLA 6-2 ( continuado)

Responsabilidad

Un buen miembro del equipo de desarrollo. . .

Es multifuncional

Tiene curiosidad Contribuye voluntariamente a áreas fuera de su dominio Disfruta aprendiendo nuevas habilidades Comparte conocimientos con entusiasmo

Está dedicado y colocado

Es parte de una organización que comprende las ganancias en eficiencia y efectividad asociadas con equipos enfocados y colocados.

Los otros dos miembros del equipo de scrum, el propietario del producto y el maestro de scrum, ayudan a respaldar los esfuerzos del equipo de desarrollo en la creación del producto. Mientras que el propietario del producto se asegura de que el equipo de desarrollo sea eficaz (trabajando en las cosas correctas), el scrum master ayuda a despejar el camino para que el equipo de desarrollo trabaje de la manera más eficiente posible.

Scrummaster Un scrummaster, a veces llamado facilitador de proyectos en entornos ágiles que no son scrum, es responsable de apoyar al equipo de desarrollo, eliminar los obstáculos organizacionales y mantener los procesos fieles a los principios ágiles. Un scrummaster es diferente a un gerente de proyecto. Los equipos que utilizan enfoques de proyectos tradicionales trabajan para un director de proyecto. Un scrummaster, por otro lado, es un compañero líder-servidor que apoya al equipo para que sea completamente funcional y productivo. El rol de scrum master es un rol habilitador, más que un rol de responsabilidad. Puede encontrar más información sobre el liderazgo de servicio en el Capítulo 14.

En un proyecto ágil, el scrum master

» Actuar como entrenador de procesos, ayudando al equipo del proyecto y a la organización a seguir valores y prácticas de scrum.

» Ayude a eliminar los impedimentos del proyecto, tanto de forma reactiva como proactiva, y proteger al equipo de desarrollo de interferencias externas.

» Fomente una estrecha cooperación entre las partes interesadas y el equipo scrum. » Facilitar la construcción de consenso dentro del equipo de scrum.

» Proteja al equipo de scrum de las distracciones organizativas.

PARTE 2 Ser ágil

Comparamos el scrummaster con el ingeniero aeronáutico cuyo trabajo consiste en reducir la resistencia del avión. La resistencia siempre está ahí, pero se puede reducir mediante una ingeniería innovadora y proactiva. Del mismo modo, todos los proyectos tienen impedimentos organizativos que dificultan la eficiencia del equipo, y siempre hay otra restricción que se puede identificar y eliminar. Una de las partes más importantes del papel de un scrum master es eliminar los obstáculos y evitar distracciones en el trabajo del equipo de desarrollo. Un scrum master que sea bueno en estas tareas no tiene precio para el proyecto y el equipo. Si un equipo de desarrollo tiene siete personas, el efecto de un buen scrum master es siete veces mayor.

Es posible que el propietario del producto nunca haya participado en un proyecto ágil, pero es probable que el scrum master lo haya hecho. Como tal, un scrum master puede entrenar a nuevos propietarios de productos y equipos de desarrollo y hace todo lo posible para ayudarlos a tener éxito.

¿Qué hace a un buen scrummaster? Un scrummaster no necesita experiencia en gestión de proyectos. Un scrum master es un experto en procesos ágiles y puede entrenar a otros. El scrummaster también debe trabajar en colaboración con el propietario del producto y la comunidad de partes interesadas. Las habilidades de facilitación eliminan el ruido de las reuniones grupales y garantizan que todos en el equipo de scrum se centren en la prioridad correcta en el momento adecuado. Los Scrum Masters tienen fuertes habilidades de comunicación, con suficiente influencia organizacional para asegurar las condiciones para el éxito al negociar en el entorno adecuado, proteger al equipo de distracciones y eliminar impedimentos. Los Scrum masters son grandes facilitadores y grandes oyentes. Pueden negociar su camino a través de opiniones contradictorias y ayudar al equipo a ayudarse a sí mismo. Revise las responsabilidades del scrum master y las características de coincidencia en la Tabla 6-3.

TABLA 6-3

Características de un buen ScrumMaster

Responsabilidad

Un buen ScrumMaster. . .

Defiende los valores y las prácticas de scrum

Es un experto en procesos de scrum.

Es un apasionado de las técnicas ágiles.

Elimina obstáculos y evita interrupciones

Tiene influencia organizacional y puede resolver problemas rápidamente Es articulado, diplomático y profesional

Es un buen comunicador y un buen oyente. Es firme sobre la necesidad del equipo de desarrollo de centrarse solo en el proyecto y el sprint actual

(continuado)

CAPÍTULO 6 Comportamientos ágiles en acción

TABLA 6-3 ( continuado)

Responsabilidad

Un buen ScrumMaster. . .

Fomenta una estrecha cooperación entre las partes

Considera las necesidades del proyecto como un todo Evita las

interesadas externas y el equipo scrum.

camarillas y ayuda a romper los silos grupales Comprende

Facilita la construcción de consenso

técnicas para ayudar a los grupos a llegar a acuerdos No

Es un líder-servidor

necesita ni quiere estar a cargo o ser el jefe Garantiza que todos los miembros del equipo de desarrollo tengan la información que necesitan para hacer el trabajo, utilizar sus herramientas y realizar un seguimiento del progreso.

Realmente desea ayudar al equipo scrum

La influencia no es lo mismo que la autoridad. Las organizaciones necesitan empoderar a sus scrummasters para que puedan influir en el cambio en el equipo y la organización del proyecto, pero la influencia implica respeto ganado, a menudo a través del éxito y la experiencia. Algunos tipos de influencia que empoderan a los scrummasters surgen a través de la experiencia (generalmente un conocimiento de nicho), la longevidad ("he estado en la empresa durante mucho tiempo y conozco su historia de primera mano"), el carisma ("la gente generalmente me agrada"), o asociaciones (“conozco gente importante”). No subestimes el valor de un scrum master con influencia.

Los miembros del equipo scrum (el propietario del producto, el equipo de desarrollo y el scrum master) trabajan juntos en el proyecto todos los días. Como mencionamos anteriormente en el capítulo, el equipo de scrum más las partes interesadas conforman el equipo del proyecto. A veces, las partes interesadas tienen una participación menos activa que los miembros del equipo scrum, pero aún pueden tener un efecto considerable y proporcionar un gran valor a un proyecto.

Partes interesadas Las partes interesadas son cualquier persona interesada en el proyecto. En última instancia, no son responsables de ejecutar el producto, pero brindan información y se ven afectados por el resultado del proyecto. El grupo de partes interesadas es diverso y puede incluir personas de diferentes departamentos o incluso de diferentes empresas. En un proyecto ágil, las partes interesadas

» Incluir al cliente » Puede incluir personal técnico, como arquitectos de infraestructura o sistemas administradores

100

PARTE 2 Ser ágil

CONSEGUIR EL CONSENSO: EL PUÑO DE CINCO Parte de trabajar en equipo significa estar de acuerdo con las decisiones en equipo. Una parte importante de ser un scrummaster es ayudar al equipo a construir consenso. Todos hemos trabajado con grupos en los que era difícil llegar a un consenso, desde cuánto tiempo llevaría una tarea hasta dónde ir a almorzar. Una forma rápida e informal de averiguar si un grupo está de acuerdo con una idea es utilizar la puño de cinco, que parece similar a piedra-papel-tijera.

A la cuenta de tres, cada persona levanta varios dedos, lo que refleja el grado de comodidad con la idea en cuestión: 5: Me encanta la idea.

4: Creo que es una buena idea.

3: Puedo apoyar la idea. 2: Tengo reservas, así que hablemos. 1: Me opuse a la idea. Si algunas personas tienen tres, cuatro o cinco dedos hacia arriba, y algunas solo tienen uno o dos, discuta la idea. Descubra por qué las personas que apoyan la idea piensan que funcionará y qué reservas tienen las personas que se oponen a la idea. Desea que todos los miembros del grupo muestren al menos tres dedos; no es necesario que les guste la idea, pero deben apoyarla. Las habilidades de creación de consenso del scrummaster son esenciales para esta tarea. También puede obtener rápidamente una idea del consenso sobre una decisión pidiendo un simple pulgar hacia arriba (apoyo), pulgar hacia abajo (no apoyo) o pulgar hacia un lado (indeciso). Es más rápido que un puño de cinco y es excelente para responder preguntas de sí o no.

» Puede incluir el departamento legal, gerentes de cuentas, vendedores, marketing expertos y representantes de servicio al cliente

» Puede incluir expertos en productos o en la materia además del propietario del producto. Las partes interesadas pueden ayudar a proporcionar información clave sobre el producto y su uso. Las partes interesadas pueden trabajar en estrecha colaboración con el propietario del producto durante el sprint y darán comentarios sobre el producto durante la revisión del sprint al final de cada sprint.

Las partes interesadas y el papel que desempeñan varían entre proyectos y organizaciones. Casi todos los proyectos ágiles tienen partes interesadas fuera del equipo scrum.

CAPÍTULO 6 Comportamientos ágiles en acción

101

Algunos proyectos también tienen mentores ágiles, especialmente proyectos con equipos de proyectos que son nuevos en los procesos ágiles.

Agilementor Un mentor es una gran idea para cualquier área en la que desee desarrollar nuevos conocimientos. La mentor

ágil, a veces llamado un entrenador ágil, es alguien que tiene experiencia en la implementación de proyectos ágiles y puede compartir esa experiencia con un equipo de proyecto. El mentor ágil puede proporcionar comentarios y consejos valiosos a los nuevos equipos de proyectos y a los equipos de proyectos que desean desempeñarse en un nivel superior.

En un proyecto ágil, el mentor ágil

» Sirve solo como mentor y no es parte del equipo de scrum. » Suele ser una persona ajena a la organización y puede proporcionar objetivos orientación, sin consideraciones personales o políticas

» Es un experto ágil con gran experiencia en la implementación de técnicas ágiles. y ejecutar proyectos ágiles de diferentes tamaños

Es posible que desee pensar en un mentor ágil como piensa en un entrenador de golf. La mayoría de las personas utilizan un entrenador de golf no porque no sepan cómo jugar al golf, sino porque un entrenador de golf observa objetivamente cosas que un jugador involucrado en el juego nunca nota. El golf, al igual que la implementación de técnicas ágiles, es un ejercicio donde los pequeños matices marcan una gran diferencia en el rendimiento.

Establecimiento de nuevos valores Muchas organizaciones publican sus valores fundamentales en la pared. En esta sección, sin embargo, estamos hablando de valores que representan una forma de trabajar juntos todos los días, apoyarse mutuamente y hacer lo que sea necesario para lograr los compromisos del equipo scrum. Además de los valores del Manifiesto Ágil, los cinco valores fundamentales para los equipos scrum son

» Compromiso » Coraje » Enfocar

102

PARTE 2 Ser ágil

» Franqueza » Respeto Las siguientes secciones proporcionan detalles sobre cada uno de estos valores.

Compromiso El compromiso implica compromiso e implicación. En proyectos ágiles, el equipo scrum se compromete a lograr objetivos específicos. Con la confianza de que el equipo de scrum cumplirá lo que promete, la organización se moviliza en torno al compromiso para cumplir con cada objetivo. Los procesos ágiles, incluida la idea de autoorganización, brindan a las personas toda la autoridad que necesitan para cumplir con los compromisos. Sin embargo, el compromiso requiere un esfuerzo consciente. Considere los siguientes puntos:

» Los equipos Scrum deben ser realistas al hacer compromisos, especialmente para sprints cortos. Es más fácil, tanto desde el punto de vista logístico como psicológico, aportar nuevos

características en un sprint que eliminar características inalcanzables de un sprint.

» Los equipos de Scrum deben comprometerse completamente con los objetivos. Esto incluye tener consenso entre el equipo que el objetivo es alcanzable. Después de que el equipo de scrum acuerda un gol, el equipo hace lo que sea necesario para alcanzar ese objetivo.

» El equipo de scrum es pragmático pero se asegura de que cada sprint tenga un valor. Lograr un objetivo de sprint y completar todos los elementos del alcance del objetivo son diferentes. Por ejemplo, el objetivo de un sprint de demostrar que un producto puede realizar una acción específica es mucho mejor que un objetivo que indica que se completarán exactamente siete requisitos durante el sprint. Los equipos de scrum efectivos se enfocan en el objetivo y permanecen flexibles en los detalles de cómo alcanzar ese objetivo.

» Los equipos Scrum están dispuestos a ser responsables de los resultados. El equipo de scrum tiene el poder de estar a cargo del proyecto. Como miembro del equipo scrum, puedes

Sea responsable de cómo organiza su día a día, el trabajo diario y el resultado.

El cumplimiento constante de los compromisos es fundamental para utilizar enfoques ágiles para la planificación a largo plazo. En el Capítulo 13, leyó sobre cómo usar el desempeño para determinar con precisión los cronogramas y presupuestos del proyecto.

Coraje Todos experimentamos miedo. Todos tenemos ciertas cosas que no queremos hacer, ya sea pedirle a un miembro del equipo que explique algo que no entendemos o confrontar

CAPÍTULO 6 Comportamientos ágiles en acción

103

el jefe. Adoptar técnicas ágiles es un cambio para muchas organizaciones. Hacer cambios con éxito requiere valentía frente a la resistencia. A continuación se presentan algunos consejos que fomentan el coraje:

» Tenga en cuenta que los procesos que funcionaron en el pasado no necesariamente

trabaja ahora. A veces es necesario recordarle a la gente este hecho. Si desea tener éxito con técnicas ágiles, sus procesos de trabajo diarios deben cambiar para mejorar.

» Esté preparado para romper el status quo. El status quo retrocederá. Algunos

la gente tiene intereses creados y no querrá cambiar su forma de trabajar.

» Desafío de temperamento con respeto. Los miembros superiores de la organización podrían ser especialmente resistente al cambio; a menudo creaban las viejas reglas sobre cómo

se hicieron las cosas. Ahora estás desafiando esas reglas. Recuérdeles respetuosamente a estas personas que puede lograr los beneficios de las técnicas ágiles solo si sigue fielmente los 12 principios ágiles. Pídales que prueben el cambio.

» Abraza los otros valores. Tenga el coraje de asumir compromisos y

respaldar esos compromisos. Ten el coraje de concentrarte y contar distractores "no". Tenga el coraje de estar abierto y reconocer que siempre hay una oportunidad para mejorar. Y tenga el coraje de ser respetuoso y tolerante con los puntos de vista de otras personas, incluso cuando desafíen sus puntos de vista.

A medida que reemplace los procesos anticuados de su organización con enfoques más modernos, espere ser desafiado. Acepta ese desafío; las recompensas pueden valer la pena al final.

Enfocar La vida laboral está llena de distracciones. A muchas personas de su organización les encantaría utilizar su tiempo para facilitarles el día. Sin embargo, las interrupciones son costosas. Jonathan Spira, de la consultora Basex, publicó un informe titulado "El costo de no prestar atención: cómo las interrupciones afectan la productividad del trabajador del conocimiento". Su informe detalla cómo las empresas en Estados Unidos pierden cerca de $ 600 mil millones un año a través de distracciones en el lugar de trabajo. Los miembros del equipo Scrum pueden ayudar a cambiar esas disfunciones insistiendo en un entorno que les permita concentrarse. Para reducir las distracciones y aumentar la productividad, los miembros del equipo scrum pueden

» Separarse físicamente de los distractores de la empresa. Uno de nosotros Las técnicas favoritas para garantizar una alta productividad es encontrar un anexo alejado de las oficinas centrales de la empresa y hacer que esa sea el área de trabajo del equipo scrum. A veces, la mejor defensa es la distancia.

104

PARTE 2 Ser ágil

» Asegúrese de no dedicar tiempo a actividades no relacionadas con el

meta de sprint. Si alguien trata de distraerlo de la meta del sprint con algo que “debe hacerse”, explique sus prioridades. Pregunte: "¿Cómo hará avanzar esta solicitud el objetivo del sprint?" Esta simple pregunta puede eliminar muchas actividades de la lista de tareas pendientes.

» Averigüe qué se debe hacer y haga solo eso. El desarrollo

equipo determina las tareas necesarias para lograr el objetivo del sprint. Si es miembro del equipo de desarrollo, utilice esta propiedad para centrarse en las tareas prioritarias en cuestión.

» Equilibre el tiempo concentrado con la accesibilidad al resto del equipo scrum. La técnica Pomodoro de Francesco Cirillo, dividiendo el trabajo en bloques de tiempo de 25 minutos, con descansos intermedios, ayuda a lograr el equilibrio entre el enfoque y la accesibilidad. A menudo recomendamos dar a los miembros del equipo de desarrollo auriculares con cancelación de ruido, cuyo uso es una señal de "no molestar". Sin embargo, también sugerimos un acuerdo de equipo en el que todos los miembros del equipo scrum tengan un conjunto mínimo de horas de oficina en las que estén disponibles para colaborar.

» Compruebe que está manteniendo su enfoque. Si no está seguro de si

están manteniendo el enfoque - puede ser difícil saberlo - vuelva a la pregunta básica, "¿Mis acciones son consistentes con el logro del objetivo general y el objetivo a corto plazo (como completar la tarea actual)?"

Como puede ver, el enfoque de la tarea no es una prioridad menor. Amplíe el esfuerzo por adelantado para crear un entorno sin distracciones que ayude a su equipo a tener éxito.

Franqueza Los secretos no tienen cabida en un equipo ágil. Si el equipo es responsable del resultado del proyecto, solo tiene sentido que tenga todos los hechos a su disposición. La información es poder y garantizar que todos tengan acceso a la información necesaria para tomar las decisiones correctas requiere la voluntad de ser transparentes. Para aprovechar el poder de la apertura, puede

» Asegúrese de que todos los miembros del equipo tengan acceso a la misma información. Todo, desde la visión del proyecto hasta el más mínimo detalle sobre el estado de las tareas, debe ser de dominio público en lo que respecta al equipo. Utilice un repositorio centralizado como fuente única de información y luego evite la distracción de los “informes de estado” colocando todo el estado (quemaduras, lista de impedimentos, etc.) e información en este único lugar. A menudo enviamos un enlace a este repositorio a las partes interesadas del proyecto y les decimos: “Toda la información que tenemos está a un clic de distancia. No hay una forma más rápida de actualizarse ".

CAPÍTULO 6 Comportamientos ágiles en acción

105

» Sea abierto y fomente la apertura en los demás. Los miembros del equipo deben sentirse libres para hablar abiertamente sobre problemas y oportunidades para mejorar, ya sea que los problemas sean algo que ellos mismos enfrentan o que ven en otra parte del equipo. La apertura requiere confianza dentro del equipo y la confianza requiere tiempo para desarrollarse.

» Calma la política interna desalentando los chismes. Si alguien empieza a hablar con

sobre lo que hizo o no hizo otro miembro del equipo, pídale que le lleve el problema a la persona que pueda resolverlo. No cuentes chismes. Siempre.

» Sea siempre respetuoso. La apertura nunca es una excusa para ser destructivo o significar. El respeto es fundamental para un entorno de equipo abierto.

Los pequeños problemas que no se abordan a menudo se convierten en crisis. Utilice un entorno abierto para beneficiarse de las aportaciones de todo el equipo y asegúrese de que sus esfuerzos de desarrollo se centren en las verdaderas prioridades del proyecto.

Respeto Cada individuo del equipo tiene algo importante que aportar. Su formación, educación y experiencias tienen una influencia distintiva en el equipo. Comparte tu singularidad y busca, y aprecia, lo mismo en los demás. Fomentas el respeto cuando

» Fomenta la apertura. El respeto y la franqueza van de la mano. Apertura sin el respeto causa resentimiento; la apertura con respeto genera confianza.

» Fomente un ambiente de trabajo positivo. La gente feliz tiende a tratar a uno otro mejor. Fomente la positividad y el respeto seguirá.

» Busque diferencias. No se limite a tolerar las diferencias; trata de encontrarlos. La Las mejores soluciones provienen de diversas opiniones que se han considerado y apropiadamente desafiado.

» Trate a todos los miembros del equipo con el mismo grado de respeto. Todo el equipo

los miembros deben recibir el mismo respeto, independientemente de su función, nivel de experiencia o contribución inmediata. Anime a todos a dar lo mejor de sí mismos.

El respeto es la red de seguridad que permite que la innovación prospere. Cuando las personas se sienten cómodas planteando una gama más amplia de ideas, la solución final puede mejorar de formas que nunca se considerarían sin un entorno de equipo respetuoso. Utilice el respeto en beneficio de su equipo.

106

PARTE 2 Ser ágil

Cambio de filosofía de equipo Un equipo de desarrollo ágil opera de manera diferente a un equipo que utiliza un enfoque en cascada. Los miembros del equipo de desarrollo deben cambiar sus roles en función de las prioridades de cada día, organizarse y pensar en los proyectos de una manera completamente nueva para lograr sus compromisos.

Para ser parte de un proyecto ágil exitoso, los equipos de desarrollo deben adoptar los siguientes atributos:

» Equipo dedicado: Cada miembro del equipo scrum trabaja solo en el proyecto

asignados al equipo scrum, y no a equipos o proyectos externos. Proyectos puede terminar y pueden comenzar nuevos proyectos, pero el equipo sigue siendo el mismo.

» Funcionalidad cruzada: La voluntad y la capacidad de trabajar en diferentes tipos de tareas para crear el producto.

» Autoorganización: La capacidad y la responsabilidad de determinar cómo ir. sobre el trabajo de desarrollo de productos.

» Autogestión: La capacidad y la responsabilidad de mantener el trabajo encaminado. » Equipos de tamaño limitado: Equipos de desarrollo del tamaño adecuado para garantizar la eficacia comunicación. Cuanto más pequeño, mejor; el equipo de desarrollo nunca debería ser

más de nueve personas.

» Propiedad: Tomar la iniciativa del trabajo y la responsabilidad de los resultados. Las siguientes secciones analizan cada una de estas ideas con más detalle.

Equipo dedicado Un enfoque tradicional para la asignación de recursos (preferimos el término asignación de talento)

consiste en distribuir porciones del tiempo de los miembros del equipo en varios equipos y proyectos para lograr una utilización total del 100 por ciento para justificar el gasto de emplear a los miembros del equipo. Para la gerencia, es gratificante saber que todas las horas de la semana están contabilizadas y justificadas. Sin embargo, el resultado es una menor productividad debido a la continua cambio de contexto - el costo asociado con la desmovilización cognitiva y la removilización para cambiar de una tarea a otra. Otras prácticas comunes de asignación de talentos incluyen mover a un miembro del equipo de un equipo a otro para llenar temporalmente un vacío de habilidades o un vacío de mano de obra, y asignarle a un equipo varios proyectos a la vez. Estas tácticas se emplean a menudo para intentar hacer más con menos, pero todas las variaciones de entrada hacen que sea casi imposible predecir los resultados.

CAPÍTULO 6 Comportamientos ágiles en acción

107

Estos enfoques tienen resultados similares: una disminución significativa de la productividad y una incapacidad para extrapolar el rendimiento. Los estudios muestran claramente un aumento mínimo del 30 por ciento en el tiempo necesario para completar los proyectos que se ejecutan en paralelo en lugar de en serie.

Paliza es otro término para el cambio de contexto entre tareas. Evite las palizas dedicando a los miembros del equipo a un solo proyecto a la vez. Los siguientes resultados ocurren cuando dedica equipos de scrum a trabajar en un solo proyecto a la vez:

» Proyecciones de lanzamiento más precisas: Porque las mismas personas son consistentes Al realizar con atención las mismas tareas en cada sprint con la misma cantidad de tiempo asignado al proyecto desde el sprint hasta el sprint, los equipos de scrum pueden extrapolar de manera precisa y empírica cuánto tiempo tomarán completar los elementos restantes de la cartera de pedidos con más certeza que los enfoques divididos tradicionales.

» Iteraciones breves y efectivas: Los sprints son cortos porque cuanto más cortos son los bucle de retroalimentación, más rápidamente los equipos de scrum pueden responder a la retroalimentación y

necesidades cambiantes. Simplemente no hay tiempo suficiente para aplastar a los miembros del equipo entre proyectos.

» Menos defectos y menos costosos: El cambio de contexto da como resultado más defectos porque los desarrolladores distraídos producen una funcionalidad de menor calidad. Cuesta menos para arreglar algo mientras todavía está fresco en tu mente (durante el sprint) que más tarde, cuando tienes que tratar de recordar el contexto en lo que estabas trabajando. Los estudios muestran que los defectos cuestan 6,5 veces más para corregirlos después de que finaliza el sprint y usted ha pasado a otros requisitos, 24 veces más para corregirlos cuando se prepara para el lanzamiento y 100 veces más para corregirlos después de que el producto está en producción.

Si desea más previsibilidad, mayor productividad y menos defectos, dedique a los miembros de su equipo scrum. Descubrimos que este es uno de los factores más importantes del éxito de una transición ágil.

Funcionalidad cruzada En los proyectos tradicionales, los miembros experimentados del equipo a menudo son encasillados por tener una sola habilidad. Por ejemplo, un programador de .NET siempre puede realizar trabajos de .NET y un evaluador siempre puede realizar trabajos de control de calidad. Los miembros del equipo con habilidades complementarias a menudo se consideran parte de grupos separados, como el grupo de programación o el grupo de prueba.

Los enfoques ágiles unen a las personas que crean productos en un grupo cohesionado: el equipo de desarrollo. Las personas de los equipos de desarrollo ágiles intentan evitar

108

PARTE 2 Ser ágil

títulos y roles limitados. Los miembros del equipo de desarrollo pueden comenzar un proyecto con una habilidad, pero aprenden a realizar muchos trabajos diferentes a lo largo del proyecto para ayudar a crear el producto.

La funcionalidad cruzada hace que los equipos de desarrollo sean más eficientes. Por ejemplo, suponga que una reunión de scrum diaria descubre las pruebas como la tarea de mayor prioridad para completar el requisito. Un programador puede ayudar a probar para terminar la tarea rápidamente. Cuando el equipo de desarrollo es multifuncional, puede enjambre en las características del producto, con tantas personas trabajando en un solo requisito como sea posible, para completar rápidamente la característica. La funcionalidad cruzada también ayuda a eliminar puntos únicos de falla. Considere los proyectos tradicionales, donde cada persona sabe cómo hacer un trabajo. Cuando un miembro del equipo se enferma, se va de vacaciones o deja la empresa, es posible que nadie más sea capaz de hacer su trabajo. Las tareas que estaba haciendo esa persona se retrasan. Por el contrario, los miembros del equipo de desarrollo ágil multifuncional son capaces de realizar muchos trabajos. Cuando una persona no está disponible, otra puede intervenir.

La funcionalidad cruzada anima a cada miembro del equipo a

» Deje a un lado la etiqueta estrecha de lo que puede hacer. Los títulos no tienen lugar en un equipo ágil. Las habilidades y la capacidad de contribuir son lo que importa. Empiece a pensar en sí mismo como un comando de las Fuerzas Especiales, lo suficientemente informado en diferentes áreas para que pueda enfrentar cualquier situación.

» Trabaja para expandir tus habilidades. No trabaje solo en áreas que ya conoce. Intentar aprende algo nuevo en cada sprint. Técnicas como programación en pareja -

donde dos desarrolladores trabajan juntos para codificar un elemento, o seguir a otros desarrolladores puede ayudarlo a aprender nuevas habilidades rápidamente y aumentar la calidad general del producto.

» Da un paso adelante para ayudar a alguien que se ha topado con un obstáculo. Ayudando a alguien con un problema del mundo real es una excelente manera de aprender una nueva habilidad.

» Se Flexible. La voluntad de ser flexible ayuda a equilibrar las cargas de trabajo y hace el equipo tiene más probabilidades de alcanzar su objetivo de sprint.

Con la funcionalidad cruzada implementada, evita esperar a que las personas clave trabajen en las tareas. En cambio, un miembro del equipo de desarrollo motivado, aunque algo menos informado, puede trabajar hoy en una parte de la funcionalidad. Ese miembro del equipo de desarrollo aprende y mejora, y el flujo de trabajo continúa equilibrado. Una gran recompensa de la funcionalidad cruzada es que el equipo de desarrollo completa el trabajo rápidamente. Las tardes de repaso posteriores al sprint suelen ser momentos de celebración. Vayan juntos al cine. Dirígete a la playa o a la bolera. Ir a casa temprano.

CAPÍTULO 6 Comportamientos ágiles en acción

109

Autoorganización Las técnicas ágiles enfatizan los equipos de desarrollo autoorganizados para aprovechar los variados conocimientos y experiencia de los miembros del equipo de desarrollo. Si ha leído el Capítulo 2, puede recordar el principio ágil n. ° 11: las mejores arquitecturas, requisitos y diseños surgen de equipos autoorganizados. La autoorganización es una parte importante de ser ágil. ¿Por qué? En una palabra: propiedad. Los equipos autoorganizados no están cumpliendo con las órdenes de otros; son dueños de la solución desarrollada y eso marca una gran diferencia en el compromiso de los miembros del equipo y la calidad de la solución. Para los equipos de desarrollo acostumbrados a un modelo tradicional de gestión de proyectos de comando y control, la autoorganización puede requerir un esfuerzo adicional al principio. Los proyectos ágiles no tienen un gerente de proyecto que le diga al equipo de desarrollo qué hacer. En cambio, equipos de desarrollo autoorganizados

» Comprometerse con sus propios objetivos de sprint. Al comienzo de cada sprint, el El equipo de desarrollo trabaja con el propietario del producto para identificar un objetivo que puede alcanzar, en función de las prioridades del proyecto.

» Identifica sus tareas. Los miembros del equipo de desarrollo determinan las tareas necesario para alcanzar cada objetivo de sprint. El equipo de desarrollo trabaja en conjunto para

averigüe quién asume qué tarea, cómo hacer el trabajo y cómo abordar los riesgos y problemas.

» Estime el esfuerzo necesario para los requisitos y las tareas relacionadas. La El equipo de desarrollo es el que más sabe acerca de cuánto esfuerzo se necesitará para crear características específicas del producto.

» Enfócate en la comunicación. Los equipos de desarrollo ágil exitosos perfeccionan sus habilidades de comunicación siendo transparente, comunicándose cara a cara, siendo consciente de la comunicación no verbal, la participación y la escucha. La clave de la comunicación es la claridad. Con temas complejos, evite los modos de comunicación unidireccionales y potencialmente ambiguos, como el correo electrónico. La comunicación cara a cara evita malentendidos y frustraciones. Siempre puede resumir la conversación en un correo electrónico rápido más tarde si es necesario conservar los detalles.

» Colaborar. Obtener la opinión de un equipo de scrum diverso casi siempre mejora el producto pero requiere sólidas habilidades de colaboración. La colaboración es

la base de un equipo ágil eficaz.

110

PARTE 2 Ser ágil

Ningún proyecto exitoso es una isla. Las habilidades de colaboración ayudan a los miembros del equipo scrum a asumir riesgos con ideas y a aportar soluciones innovadoras a los problemas del proyecto. Un entorno seguro y confortable es la piedra angular de un proyecto ágil exitoso.

» Decide con consenso. Para máxima productividad, todo el desarrollo El equipo debe estar en la misma página y comprometido con el objetivo en cuestión. La scrummaster a menudo juega un papel activo en la construcción de consenso, pero el equipo de desarrollo finalmente asume la responsabilidad de llegar a un acuerdo sobre las decisiones, y todos son dueños de las decisiones.

» Participar activamente. La autoorganización puede ser un desafío para los tímidos. Todas los miembros del equipo de desarrollo deben participar activamente. Nadie se lo va a decir

el equipo de desarrollo qué hacer para crear el producto. Los miembros del equipo de desarrollo se dicen a sí mismos qué hacer. Y cuando. Y cómo. En nuestra experiencia de coaching ágil, hemos escuchado a nuevos miembros del equipo de desarrollo ágil hacer preguntas como, "Entonces, ¿qué debo hacer ahora?" Un buen scrummaster responde preguntando al desarrollador qué necesita hacer para lograr el objetivo del sprint, o preguntando al resto del equipo de desarrollo qué sugieren. Responder preguntas con preguntas puede ser una forma útil de guiar a un equipo de desarrollo hacia la autoorganización. Formar parte de un equipo de desarrollo autoorganizado implica responsabilidad, pero también tiene sus recompensas. La autoorganización brinda a los equipos de desarrollo la libertad de tener éxito. La autoorganización aumenta la propiedad, lo que puede resultar en mejores productos, lo que puede ayudar a los miembros del equipo de desarrollo a encontrar más satisfacción en su trabajo.

Autogestión La autogestión está estrechamente relacionada con la autoorganización. Los equipos de desarrollo ágiles tienen mucho control sobre cómo trabajan; ese control viene con la responsabilidad de asegurar que el proyecto sea exitoso. Para tener éxito con la autogestión, los equipos de desarrollo

» Permita que el liderazgo fluya y refluya. En proyectos ágiles, cada persona del El equipo de desarrollo tiene la oportunidad de liderar. Para diferentes tareas, diferentes los líderes surgirán naturalmente; el liderazgo cambiará en todo el equipo en función de la experiencia en habilidades y experiencias anteriores.

» Confíe en procesos y herramientas ágiles para gestionar el trabajo. Los métodos ágiles son adaptado para facilitar la autogestión. Con un enfoque ágil, las reuniones tienen propósitos y límites de tiempo claros, y los artefactos exponen información pero dependen de un esfuerzo mínimo para crear y mantener. Aprovechar estos procesos permite a los equipos de desarrollo dedicar la mayor parte de su tiempo a crear el producto.

CAPÍTULO 6 Comportamientos ágiles en acción

111

» Informar el progreso de forma periódica y transparente. Cada equipo de desarrollo El miembro es responsable de actualizar con precisión el estado del trabajo a diario. Afortunadamente, los informes de progreso son una tarea rápida en proyectos ágiles. En el Capítulo 9, encontrará información sobre los gráficos de evolución, que proporcionan el estado, pero solo requieren unos minutos cada día para actualizarse. Mantener el estado actualizado y veraz facilita la planificación y la gestión de problemas.

» Gestionar problemas dentro del equipo de desarrollo. Pueden surgir muchos obstáculos en un proyecto: los desafíos del desarrollo y los problemas interpersonales son un par de ejemplos. El primer punto de escalada del equipo de desarrollo para la mayoría de los problemas es el propio equipo de desarrollo.

» Cree un acuerdo de equipo. Los equipos de desarrollo a veces forman un equipo acuerdo, un documento que describe las expectativas de cada miembro del equipo

se comprometerá a reunirse. Los acuerdos de trabajo brindan una comprensión compartida de las expectativas de comportamiento y empoderan al facilitador para mantener al equipo en marcha de acuerdo con lo que ya acordaron juntos.

» Inspeccione y adapte. Descubra qué funciona para su equipo. Las mejores prácticas difieren de equipo en equipo. Algunos equipos funcionan mejor si llegan temprano; otros trabajan

mejor llegando tarde. El equipo de desarrollo es responsable de revisar su propio desempeño e identificar técnicas para continuar y técnicas para cambiar.

» Participar activamente. Al igual que con la autoorganización, la autogestión solo funciona cuando los miembros del equipo de desarrollo se unen y se comprometen a guiar el proyecto

dirección. El equipo de desarrollo es el principal responsable de la autoorganización y la autogestión. Sin embargo, el scrum master puede ayudar al equipo de desarrollo de varias formas. Cuando los miembros del equipo de desarrollo buscan instrucciones específicas, el scrummaster puede recordarles que tienen el poder de decidir qué hacer y cómo hacerlo. Si alguien fuera del equipo de desarrollo intenta dar órdenes, insistir en las tareas o dictar cómo crear el producto, el scrum master puede intervenir. El scrum master puede ser un poderoso aliado en la autoorganización y autogestión del equipo de desarrollo.

Equipos de tamaño limitado Los equipos de desarrollo ágiles son intencionalmente pequeños. Un pequeño equipo de desarrollo es un equipo ágil. A medida que aumenta el tamaño del equipo de desarrollo, también lo hace la sobrecarga asociada con la organización del flujo de tareas y el flujo de comunicación.

Idealmente, los equipos de desarrollo ágiles tienen la menor cantidad de personas necesarias para autoencapsularse (pueden hacer todo lo necesario para producir el producto) y no

112

PARTE 2 Ser ágil

tienen puntos únicos de falla. Para tener cobertura de habilidades, los equipos generalmente no serán menores de tres personas. Estadísticamente, los equipos de scrum son más rápidos con seis desarrolladores y más baratos con cuatro o cinco desarrolladores. Mantener el tamaño del equipo de desarrollo entre tres y nueve personas ayuda a los equipos a actuar como equipos cohesionados y evita la creación de subgrupos, o silos. Limitar el tamaño del equipo de desarrollo

» Fomenta el desarrollo de diversas habilidades » Facilita una buena comunicación en equipo » Mantiene al equipo en una sola unidad » Promueve la propiedad conjunta del código, la funcionalidad cruzada y cara a cara comunicación

Cuando tiene un equipo de desarrollo pequeño, sigue un alcance de proyecto igualmente limitado y enfocado. Los miembros del equipo de desarrollo están en estrecho contacto durante todo el día a medida que las tareas, las preguntas y las revisiones de pares fluyen entre los compañeros de equipo. Esta cohesión asegura un compromiso constante, aumenta la comunicación y reduce el riesgo del proyecto. Cuando tenga un proyecto grande y un equipo de desarrollo correspondientemente grande, divida el trabajo entre varios equipos de scrum. Para obtener más información sobre cómo escalar proyectos ágiles en toda la empresa, consulte el Capítulo 17.

Propiedad Formar parte de un equipo de desarrollo multifuncional, autoorganizado y autogestionario requiere responsabilidad y propiedad. Los enfoques de gestión de arriba hacia abajo en los proyectos tradicionales no siempre fomentan la madurez de propiedad necesaria para asumir la responsabilidad de los proyectos y los resultados. Incluso los miembros experimentados del equipo de desarrollo pueden necesitar ajustar su comportamiento para acostumbrarse a tomar decisiones en proyectos ágiles. Los equipos de desarrollo pueden adaptar el comportamiento y aumentar su nivel de propiedad haciendo lo siguiente:

» Toma la iniciativa. En lugar de esperar a que alguien más le diga qué trabajar encendido, actuar. Haga lo que sea necesario para ayudar a cumplir los compromisos y metas.

» Triunfa y fracasa como equipo. Sobre proyectos ágiles, logros y fracasos Pertenecen por igual al equipo del proyecto. Si surgen problemas, rindan cuentas como grupo,

CAPÍTULO 6 Comportamientos ágiles en acción

113

en lugar de encontrar la culpa. Cuando tenga éxito, reconozca el esfuerzo grupal necesario para lograrlo.

» Confíe en la capacidad de tomar buenas decisiones. Los equipos de desarrollo pueden hacer Decisiones maduras, responsables y sólidas sobre el desarrollo de productos. Esto requiere cierto grado de confianza a medida que los miembros del equipo se acostumbran a tener más control en un proyecto.

La madurez del comportamiento y la propiedad no significan que los equipos de desarrollo ágiles sean perfectos. Más bien, se apropian del alcance al que se comprometen y asumen la responsabilidad de cumplir esos compromisos. Los errores ocurren. Si no es así, no te estás esforzando por salir de tu zona de confort. Un equipo de desarrollo maduro identifica los errores con honestidad, acepta la responsabilidad por los errores abiertamente y aprende y mejora de sus errores de manera constante.

114

PARTE 2 Ser ágil

Planificación ágil

y ejecución

EN ESTA PARTE . . .

Siga la hoja de ruta hacia el valor, desde la visión hasta la ejecución. Definir y estimar requisitos. Cree una funcionalidad de trabajo y muéstrela en iteraciones.

Inspecciona tu trabajo y adapta tus procesos para la mejora continua.

EN ESTE CAPÍTULO » Planificación de proyectos ágiles

» Estableciendo la visión del producto » Creando características y un producto

mapa vial

Capítulo

Definición del producto

VisionandProduct Mapa vial

Incluya la planificación, descarte ese pensamiento ahora mismo. No solo planificará el proyecto general, sino también cada lanzamiento, cada sprintque y todos los días. Planificación Empecemos, disipemos un mito común. Si ha escuchado los proyectos ágiles no

es fundamental para el éxito de un proyecto ágil.

Si usted es un gerente de proyecto, probablemente haga la mayor parte de su planificación al comienzo de un proyecto. Es posible que haya escuchado la frase "Planifique el trabajo, luego trabaje el plan", que resume los enfoques de gestión de proyectos no ágiles. Los proyectos ágiles, por el contrario, implican una planificación inicial y durante todo el proyecto. Al planificar en el último momento responsable, justo antes de que comience una actividad, sabes más sobre esa actividad. Este tipo de planificación, llamado planificación justo a

tiempo o un estrategia informada situacionalmente, es la clave para el éxito de un proyecto ágil. Los equipos ágiles planifican tanto, si no más, que los equipos de proyectos tradicionales. Sin embargo, la planificación ágil se distribuye de manera más uniforme a lo largo del proyecto y la realiza todo el equipo que trabajará en el proyecto.

CAPÍTULO 7 Definición de la visión del producto y la hoja de ruta del producto

117

Helmuth von Moltke, un mariscal de campo y estratega militar alemán del siglo XIX, dijo una vez: "Ningún plan sobrevive al contacto con el enemigo". Es decir, en el fragor de una batalla, como en el fragor de un proyecto, los planes siempre cambian. El enfoque ágil en la planificación justo a tiempo le permite adaptarse a situaciones reales y estar bien informado al planificar tareas específicas. Este capítulo describe cómo funciona la planificación justo a tiempo con proyectos ágiles. También pasa por los dos primeros pasos de la planificación de un proyecto ágil: crear la visión del producto y la hoja de ruta del producto.

Planificación ágil La planificación ocurre en varios puntos de un proyecto ágil. Una excelente manera de ver las actividades de planificación en proyectos ágiles es con Roadmap to Value. La Figura 7-1 muestra la hoja de ruta en su totalidad.

FIGURA 7-1: Etapas de ágil planificación y ejecución con la hoja de ruta valorar.

118

PARTE 3 Planificación y ejecución ágiles

La hoja de ruta hacia el valor tiene siete etapas:

» En la etapa 1, el propietario del producto identifica el visión del producto. La visión del producto es el destino o el objetivo final de su proyecto. La visión del producto incluye el exterior

Límite de cuál será su producto, en qué se diferencia el producto de la competencia, cómo el producto apoyará la estrategia de su empresa u organización, quién usará el producto y por qué la gente usará el producto. En proyectos más largos, revise la visión del producto al menos una vez al año.

» En la etapa 2, el propietario del producto crea un hoja de ruta del producto. La hoja de ruta del producto es una vista de alto nivel de los requisitos del producto, con un marco de tiempo general para

cuándo desarrollará esos requisitos. También da contexto a la visión al mostrar las características tangibles que se producirán durante el proyecto. Identificar los requisitos del producto y luego priorizar y estimar aproximadamente el esfuerzo para esos requisitos le permite establecer temas de requisitos e identificar las brechas de requisitos. El propietario del producto, con el apoyo del equipo de desarrollo, debe revisar la hoja de ruta del producto al menos cada dos años.

» En la etapa 3, el propietario del producto crea un plan de lanzamiento. La plan de lanzamiento identifica un cronograma de alto nivel para el lanzamiento de la funcionalidad de trabajo al cliente. El lanzamiento sirve como un límite intermedio contra el cual el equipo de scrum puede movilizarse. Un proyecto ágil tendrá muchas versiones, y las características de mayor prioridad aparecerán primero. Crea un plan de lanzamiento al comienzo de cada lanzamiento, que suele ser al menos trimestral. Obtenga más información sobre la planificación de lanzamientos en el Capítulo 8.

» En la etapa 4, el propietario del producto, el equipo de desarrollo y el scrummaster Planificará iteraciones, también llamadas sprints, y comenzará a crear la función del producto.

Alidad en esos sprints. Planificación de Sprint las sesiones tienen lugar al comienzo de cada sprint. Durante la planificación del sprint, el equipo de scrum determina un objetivo de sprint, que establece el límite inmediato del trabajo que el equipo prevé lograr durante el sprint, con requisitos que respaldan el objetivo y se pueden completar en el sprint. El equipo de scrum también describe cómo completar esos requisitos. Obtenga más información sobre la planificación de sprints en el Capítulo 8.

» En la etapa 5, el equipo de desarrollo ha scrum diario reuniones durante cada sprint

para coordinar las prioridades del día. En el scrummeeting diario, discute lo que que completó ayer, en qué trabajará hoy y cualquier obstáculo que tenga, para que pueda abordar los problemas de inmediato. Lea sobre scrums diarios en el Capítulo 9.

» En la etapa 6, el equipo scrum tiene un revisión de sprint al final de cada sprint. En la revisión del sprint, demuestra la funcionalidad de trabajo al producto partes interesadas. Descubra cómo realizar revisiones de sprint en el Capítulo 10.

CAPÍTULO 7 Definición de la visión del producto y la hoja de ruta del producto

119

» En la etapa 7, el equipo scrum tiene un Sprint retrospectiva. La retrospectiva del sprint es una reunión donde el equipo de scrum discute el sprint completado con

con respecto a sus procesos y entorno, y hace planes para mejorar los procesos en el próximo sprint. Al igual que la revisión de sprint para inspeccionar y adaptar el producto, se lleva a cabo una retrospectiva de sprint al final de cada sprint para inspeccionar y adaptar sus procesos y entorno. Descubra cómo realizar retrospectivas de sprint en el Capítulo 10. Cada etapa de la Hoja de ruta hacia el valor es repetible y cada etapa contiene actividades de planificación. La planificación ágil, como el desarrollo ágil, es iterativa.

Elaboración progresiva Durante cada etapa de un proyecto ágil, planifica solo lo que necesita planificar. En las primeras etapas de su proyecto, planifica de manera amplia y holística para crear un esquema general de cómo se formará el producto con el tiempo. En etapas posteriores, reduce su planificación y agrega más detalles para garantizar el éxito en el esfuerzo de desarrollo inmediato. Este proceso se llama elaboración progresiva de requisitos. Planificar de forma amplia al principio y en detalle más adelante, cuando sea necesario, evita que pierda el tiempo planificando requisitos de productos de menor prioridad que es posible que nunca se implementen. Este modelo también le permite agregar requisitos de alto valor durante el proyecto sin interrumpir el flujo de desarrollo. Cuanto más puntual sea su planificación detallada, más eficiente será su proceso de planificación. Algunos estudios muestran que los clientes rara vez o nunca usan el 64 por ciento de las funciones de una aplicación. En los primeros ciclos de desarrollo de un proyecto ágil, completa las funciones que tienen la máxima prioridad y que las personas voluntad usar. Por lo general, lanza esos grupos de funciones lo antes posible para ganar participación de mercado a través de la ventaja de ser el primero en moverse; recibir comentarios de los clientes sobre la viabilidad; monetizar la funcionalidad desde el principio para optimizar el retorno de la inversión (ROI); y evitar la obsolescencia interna y externa.

Inspeccionar y adaptar La planificación justo a tiempo pone en juego dos principios fundamentales de las técnicas ágiles: inspeccionar y adaptar. En cada etapa de un proyecto, debe observar el producto y el proceso (inspeccionar) y realizar los cambios necesarios (adaptar).

120

PARTE 3 Planificación y ejecución ágiles

La planificación ágil es un ciclo rítmico de inspección y adaptación. Considera lo siguiente:

» Todos los días durante el sprint, el propietario del producto proporciona comentarios para ayudar mejorar el producto a medida que el equipo de desarrollo crea el producto.

» Al final de cada sprint, en la revisión del sprint, las partes interesadas brindan comentarios para mejorar aún más el producto.

» También al final de cada sprint, en la retrospectiva del sprint, el equipo scrum

analiza las lecciones que aprendió durante el último sprint para mejorar el desarrollo proceso de ment.

» Después de un lanzamiento, los clientes pueden proporcionar comentarios para mejorar. Realimentación puede ser directo, cuando un cliente contacta a la empresa sobre el producto, o indirecto, cuando los clientes potenciales compran o no el producto. Inspeccionar y adaptar, juntos, son herramientas fantásticas para entregar el producto correcto de la manera más eficiente. Al comienzo de un proyecto, sabe lo mínimo sobre el producto que está creando, por lo que tratar de planificar los detalles finos en ese momento simplemente no funciona. Ser ágil significa realizar la planificación detallada cuando la necesita y desarrollar de inmediato los requisitos específicos que definió con esa planificación. Ahora que sabe un poco más sobre cómo funciona la planificación ágil, es hora de completar el primer paso en un proyecto ágil: definir la visión del producto.

Definición de la visión del producto La primera etapa de un proyecto ágil es definir la visión de su producto. La declaración de visión

del producto es un discurso de ascensor, o un resumen rápido, para comunicar cómo su producto respalda las estrategias de la empresa u organización. La declaración de visión debe articular el estado final del producto. El producto puede ser un producto comercial para su lanzamiento al mercado o una solución interna que respaldará las funciones diarias de su organización. Por ejemplo, supongamos que su empresa es XYZ Bank y su producto es una aplicación de banca móvil. ¿Qué estrategias de la empresa admite una aplicación de banca móvil? ¿Cómo apoya la aplicación las estrategias de la empresa? Su declaración de visión vincula de manera clara y concisa el producto con su estrategia comercial. La Figura 7-2 muestra cómo la declaración de visión, etapa 1 de la Hoja de ruta hacia el valor, encaja con el resto de las etapas y actividades de un proyecto ágil.

CAPÍTULO 7 Definición de la visión del producto y la hoja de ruta del producto

121

FIGURA 7-2: El producto declaración de la visión

como parte de la Hoja de ruta hacia

Valor.

El propietario del producto es responsable de conocer el producto, sus objetivos y sus requisitos durante todo el proyecto. Por esas razones, el propietario del producto crea la declaración de visión, aunque otras personas pueden participar. Una vez que se completa la declaración de visión, se convierte en una luz guía, la declaración de "lo que estamos tratando de lograr" a la que el equipo de desarrollo, el scrum master y las partes interesadas se refieren a lo largo del proyecto. Al crear una declaración de visión de producto, siga estos cuatro pasos:

1. Desarrollar el objetivo del producto. 2. Crea un borrador de declaración de visión.

3. Validar la declaración de visión con las partes interesadas del producto y del proyecto y revíselo en función de los comentarios.

4. Finalice la declaración de visión. El aspecto de una declaración de visión no sigue reglas estrictas. Sin embargo, cualquier persona involucrada en el proyecto, desde el equipo de desarrollo hasta el director ejecutivo, debería poder comprender la declaración. La declaración de visión debe tener un enfoque interno, ser clara, no técnica y lo más breve posible. La declaración de la visión también debe ser explícita y evitar tonterías de marketing.

Paso 1: desarrollo del objetivo del producto Para escribir su declaración de visión, debe comprender y poder comunicar el objetivo del producto. Necesita identificar lo siguiente:

» Cliente: ¿Quién usará el producto? Esta pregunta puede tener más de Una respuesta.

» Objetivos clave del producto: ¿Cómo beneficiará el producto a la empresa que está creando ¿eso? Los objetivos pueden incluir beneficios para un departamento específico de su empresa,

como el servicio al cliente o el departamento de marketing, así como la empresa en su conjunto. ¿Qué estrategias específicas de la empresa admite el producto?

122

PARTE 3 Planificación y ejecución ágiles

» Necesitar: ¿Por qué el cliente necesita el producto? ¿Qué características son críticas para ¿el cliente?

» Competencia: ¿Cómo se compara el producto con productos similares? » Diferenciación primaria: ¿Qué hace que este producto sea diferente del estado? quo o la competencia o ambos?

Paso 2: creación de un borrador de declaración de visión Una vez que haya comprendido bien el objetivo del producto, cree un primer borrador de su declaración de visión. Puede encontrar muchas plantillas para una declaración de visión de producto. Para obtener una guía excelente para definir la visión general del producto, consulte Cruzando el abismo, por Geoffrey Moore (publicado por HarperCollins), que se centra en cómo cerrar la brecha (abismo) entre los primeros en adoptar nuevas tecnologías y la mayoría de los que siguen.

La adopción de cualquier producto nuevo es una apuesta. ¿A los usuarios les gustará el producto? ¿Tomará el mercado el producto? ¿Habrá un retorno de la inversión adecuado para desarrollar el producto? En Cruzando el abismo, Moore describe cómo los primeros adoptantes son impulsados por la visión, mientras que la mayoría son escépticos con los visionarios e interesados en cuestiones prácticas de calidad, mantenimiento del producto y longevidad.

Retorno de la inversión, o ROI, es el beneficio o valor que obtiene una empresa al pagar por algo. El ROI puede ser cuantitativo, como el dinero adicional que ABC Products gana vendiendo widgets en línea después de invertir en un nuevo sitio web. El ROI también puede ser algo intangible, como una mejor satisfacción del cliente para los clientes de XYZ Bank que utilizan la nueva aplicación de banca móvil del banco. Al crear su declaración de visión, ayuda a transmitir la calidad, las necesidades de mantenimiento y la longevidad de su producto. El enfoque de la visión del producto de Moore es pragmático. En la Figura 7-3, construimos una plantilla basada en el enfoque de Moore para conectar más explícitamente el producto con las estrategias de la empresa. Si utiliza esta plantilla para la declaración de visión de su producto, resistirá la prueba del tiempo a medida que su producto pasa de la adopción temprana al uso generalizado.

Una forma de hacer que la declaración de su visión del producto sea más convincente es escribirla en tiempo presente, como si el producto ya existiera. El uso del tiempo presente ayuda a los lectores a imaginar el producto en uso.

CAPÍTULO 7 Definición de la visión del producto y la hoja de ruta del producto

123

FIGURA 7-3: Expansión de Plantilla de Moore por una visión

declaración.

Usando nuestra expansión de la plantilla de Moore, una declaración de visión para una aplicación de banca móvil podría tener el siguiente aspecto: Para Clientes de XYZ Bank OMS quieren acceso a la capacidad bancaria mientras se desplazan,

la MyXYZ es un aplicación movil que permite realizar operaciones bancarias seguras y bajo demanda las 24 horas del día.

a diferencia de banca en línea desde la computadora de su hogar u oficina, nuestro producto permite a los usuarios acceso inmediato,

que apoya nuestra estrategia para proporcionar servicios bancarios rápidos y convenientes, en cualquier momento, en cualquier lugar. ( Adición PlatinumEdge)

Como puede ver, una declaración de visión identifica un estado futuro para el producto cuando el producto se completa. La visión se centra en las condiciones que deberían existir cuando el producto esté completo. Evite generalizaciones en su declaración de visión, como "hacer felices a los clientes" o "vender más productos". También tenga cuidado con demasiada especificidad tecnológica, como “usando la versión 9.x de Java, cree un programa con cuatro módulos que. . . " En esta etapa inicial, la definición de tecnologías específicas podría limitarlo más adelante. Aquí hay algunos extractos de declaraciones de visión que deberían hacer sonar campanas de advertencia:

» Asegure clientes adicionales para la aplicación MyXYZ. » Satisfacer a nuestros clientes antes de diciembre.

» Elimina todos los defectos y mejora la calidad. 124

PARTE 3 Planificación y ejecución ágiles

» Cree una nueva aplicación en Java. » Batir el mercado de Widget Company por seis meses.

Paso 3: Validación y revisión de la declaración de visión. Después de redactar su declaración de visión, revísela con la siguiente lista de verificación de calidad:

» ¿Es esta declaración de visión clara, enfocada y escrita para una audiencia interna? » ¿La declaración proporciona una descripción convincente de cómo el producto satisface las necesidades del cliente?

» ¿La visión describe el mejor resultado posible? » ¿Es el objetivo empresarial lo suficientemente específico como para que la meta sea alcanzable?

» ¿Ofrece la declaración un valor coherente con las estrategias corporativas? y metas?

» ¿Es convincente la declaración de la visión del producto?

» ¿Es la visión concisa? Estas preguntas de sí o no lo ayudarán a determinar si su declaración de visión es completa y clara. Si alguna respuesta es negativa, revise la declaración de visión. Cuando todas las respuestas sean afirmativas, continúe revisando la declaración con los demás, incluidos los siguientes:

» Actores del proyecto: Los interesados

podrán identificar que la visión La declaración incluye todo lo que debe lograr el producto.

» Tu equipo de desarrollo: El equipo, porque creará el producto, debe comprender lo que el producto necesita lograr.

» Scrummaster: Una sólida comprensión del producto ayudará al scrum

eliminar obstáculos y asegurarse de que el equipo de desarrollo esté en el camino correcto más adelante en el proyecto.

» Agilementor: Comparta la declaración de visión con su mentor ágil, si tiene

uno. El mentor ágil es independiente de la organización y puede proporcionar una perspectiva externa, cualidades que pueden dar lugar a una gran voz objetiva.

CAPÍTULO 7 Definición de la visión del producto y la hoja de ruta del producto

125

Vea si otros piensan que la declaración de visión es clara y transmite el mensaje que desea transmitir. Revise y revise la declaración de visión hasta que las partes interesadas del proyecto, el equipo de desarrollo y el scrum master comprendan completamente la declaración.

En esta etapa de su proyecto, es posible que no tenga un equipo de desarrollo o un scrum master. Después de formar un equipo de scrum, asegúrese de revisar la declaración de visión con él.

Paso 4: Finalización de la declaración de visión Una vez que termine de revisar la declaración de visión, asegúrese de que su equipo de desarrollo, scrummaster y las partes interesadas tengan la copia final. Incluso puede poner una copia en la pared del área de trabajo del equipo de scrum, donde puede verla todos los días. Hará referencia a la declaración de visión a lo largo de la vida del proyecto. Si su proyecto dura más de un año, es posible que desee volver a visitar la declaración de visión. Nos gusta revisar la declaración de visión del producto al menos una vez al año para asegurarnos de que el producto refleje el mercado y respalde cualquier cambio en las necesidades de la empresa. Debido a que la declaración de la visión es el límite a largo plazo del proyecto, el proyecto debe finalizar cuando la visión ya no sea viable. El propietario del producto es el propietario de la declaración de visión del producto y es responsable de su preparación y comunicación en toda la organización. La visión del producto establece expectativas para las partes interesadas y ayuda al equipo de desarrollo a mantenerse enfocado en el objetivo.

Felicidades. Acaba de completar la primera etapa de su proyecto ágil. Ahora es el momento de crear una hoja de ruta del producto.

Creación de una hoja de ruta de productos La hoja de ruta del producto, etapa 2 en la Hoja de ruta hacia el valor (consulte la Figura 7-4), es una vista general de los requisitos del producto y una herramienta valiosa para planificar y organizar el viaje del desarrollo del producto. Utilice la hoja de ruta del producto para categorizar los requisitos, priorizarlos, identificar brechas y dependencias y determinar un cronograma para entregar al cliente. Al igual que lo hace con la declaración de visión del producto, el propietario del producto crea la hoja de ruta del producto, con la ayuda del equipo de desarrollo y las partes interesadas. El equipo de desarrollo participa en mayor medida que durante la creación de la declaración de visión.

126

PARTE 3 Planificación y ejecución ágiles

FIGURA 7-4: El producto hoja de ruta como parte

de la hoja de ruta valorar.

Tenga en cuenta que refinará los requisitos y las estimaciones de esfuerzo a lo largo del proyecto. En la fase de la hoja de ruta del producto, está bien que sus requisitos, estimaciones y plazos estén en un nivel muy alto. Para crear la hoja de ruta de su producto, haga lo siguiente:

1. 2. 3. 4. 5.

Identificar a las partes interesadas.

Establezca los requisitos del producto y agréguelos a la hoja de ruta. Organice los requisitos del producto en función de los valores, los riesgos y las dependencias.

Estime el esfuerzo de desarrollo a un alto nivel y priorice los requisitos del producto. Determine los períodos de tiempo de alto nivel para entregar grupos de funciones al cliente.

Debido a que las prioridades pueden cambiar, espere actualizar la hoja de ruta de su producto a lo largo del proyecto. Nos gusta actualizar la hoja de ruta del producto al menos dos veces al año.

La hoja de ruta de su producto puede ser tan simple como notas adhesivas dispuestas en una pizarra, lo que hace que las actualizaciones sean tan fáciles como mover una nota adhesiva de una sección de la pizarra a otra. Utiliza la hoja de ruta del producto para planificar lanzamientos: etapa 3 en la hoja de ruta hacia el valor.

Lanzamientos son grupos de funcionalidades de productos utilizables que usted ofrece a los clientes para recopilar comentarios del mundo real y generar un retorno de la inversión. La siguiente sección detalla los pasos para crear una hoja de ruta del producto.

Paso 1: identificación de las partes interesadas Al establecer inicialmente la visión del producto, es probable que haya identificado solo algunas partes interesadas clave que están disponibles para brindar comentarios de alto nivel. En la etapa de la hoja de ruta del producto, usted pone más contexto a la visión del producto e identifica cómo logra la visión, lo que brinda más información sobre quiénes estarán interesados en su proyecto.

CAPÍTULO 7 Definición de la visión del producto y la hoja de ruta del producto

127

Este es el momento de comprometerse con las partes interesadas existentes y recientemente identificadas para recopilar comentarios sobre la funcionalidad que desea implementar para lograr la visión. La hoja de ruta del producto es su primer corte en una acumulación de productos de alto nivel, que se analiza más adelante en este capítulo. Con esta primera ronda de detalles identificada, querrá involucrar más que solo el equipo de scrum, el patrocinador del proyecto y los usuarios obvios. Considere incluir a las siguientes personas:

» Departamento de Marketing: Sus clientes necesitan conocer su producto,

y eso es lo que ofrece el departamento de marketing. Ellos necesitan entender sus planes y pueden influir en el orden en el que lanza la funcionalidad al mercado, según su experiencia e investigación.

» Departamento de servicio al cliente: Una vez que su producto esté en el mercado, ¿cómo ser apoyado? Los elementos específicos de la hoja de ruta pueden identificar a la persona que necesitará

para prepararse para el apoyo. Por ejemplo, es posible que el propietario de un producto no vea mucho valor en conectar una función de chat en línea en vivo, pero un gerente de servicio al cliente puede verlo de manera diferente porque sus representantes pueden manejar simultáneamente solo una llamada telefónica, pero hasta seis sesiones de chat.

» Departamento de ventas: Asegúrese de que los miembros del equipo de ventas vean el producto para que empiecen a vender lo mismo que estás construyendo. Como el marketing

departamento, el departamento comercial conocerá de primera mano lo que buscan sus clientes.

» Departamento legal: Especialmente si se encuentra en una industria altamente regulada, revise

su hoja de ruta con un asesor legal lo antes posible para asegurarse de que no omitió cualquier cosa que pudiera poner en riesgo su proyecto si se descubre más adelante en el proyecto.

» Clientes adicionales: Mientras identifica características en su hoja de ruta, puede descubra personas adicionales que encontrarán valor en lo que creará. Dar ellos tienen la oportunidad de revisar su hoja de ruta para validar sus suposiciones.

Paso 2: establecer los requisitos del producto El segundo paso para crear una hoja de ruta del producto es identificar o definir los diferentes requisitos para su producto. Cuando crea por primera vez la hoja de ruta de su producto, generalmente comienza con requisitos grandes y de alto nivel. Los requisitos en la hoja de ruta de su producto probablemente estarán en dos niveles diferentes: temas y características. Temas son grupos lógicos de características y requisitos en sus niveles más altos. Características son partes del producto a un nivel muy alto y describen una nueva capacidad que el cliente tendrá una vez que la función esté completa.

128

PARTE 3 Planificación y ejecución ágiles

REQUISITOS DE DESCOMPOSICIÓN A lo largo del proyecto, dividirá los requisitos en partes más pequeñas y manejables mediante un proceso llamado descomposición, o elaboración progresiva. Puede dividir los requisitos en los siguientes tamaños, enumerados de mayor a menor: Temas: A tema es un grupo lógico de características y también es un requisito en su nivel más alto. Puede agrupar funciones en temas en la hoja de ruta de su producto. Características: Características son partes de productos de muy alto nivel. Las funciones describen una nueva capacidad que los clientes tendrán una vez que la función esté completa. Utiliza funciones en la hoja de ruta de su producto.

Historias de usuarios épicas: Épicas son requisitos de tamaño mediano que se descomponen de una característica y, a menudo, contienen múltiples acciones o canales de valor. Debes desglosar tus epopeyas antes de poder comenzar a crear funciones a partir de ellas. Puede averiguar cómo usa las epopeyas para la planificación de lanzamientos en el Capítulo 8. Historias de usuarios: Historias de usuarios son requisitos que contienen una sola acción o integración y son lo suficientemente pequeños como para comenzar a implementarse en la funcionalidad. Puede ver cómo define las historias de usuario y las usa en el nivel de lanzamiento y sprint en el Capítulo 8. Tareas: Tareas son los pasos de ejecución necesarios para convertir un requisito en una funcionalidad de trabajo. Las historias de usuarios se dividen en diferentes tareas durante la planificación del sprint. Puede obtener más información sobre las tareas y la planificación de sprints en el Capítulo 8.

Tenga en cuenta que es posible que no todos los requisitos pasen por todos estos tamaños. Por ejemplo, puede crear un requisito particular a nivel de historia de usuario y nunca pensar en él en el tema o en la escala épica. Puede crear un requisito a nivel de historia de usuario épica, pero puede ser un requisito de menor prioridad. Debido a la planificación justo a tiempo, es posible que no se tome el tiempo para descomponer esa historia de usuario épica de menor prioridad hasta que complete el desarrollo de todos los requisitos de mayor prioridad.

Para identificar temas y características del producto, el propietario del producto puede trabajar con las partes interesadas y el equipo de desarrollo. Puede ser útil tener una sesión de requisitos, en la que las partes interesadas y el equipo de desarrollo se reúnan y escriban todos los requisitos que se les ocurran. Cuando comienza a crear requisitos a nivel de tema y función, puede ser útil escribir esos requisitos en tarjetas de índice o notas adhesivas grandes. El uso de una tarjeta física que puede pasar de una categoría a otra y viceversa puede facilitar la organización y la priorización de esos requisitos.

CAPÍTULO 7 Definición de la visión del producto y la hoja de ruta del producto

129

Mientras crea la hoja de ruta del producto, las características que identifica comienzan a conformar su Pila de

Producto - la lista completa de lo que está dentro del alcance de un producto, independientemente del nivel de detalle. Una vez que haya identificado las características de su primer producto, habrá comenzado su cartera de productos.

Paso 3: organización de las características del producto Después de identificar las características de su producto, trabaja con las partes interesadas para agruparlas en temas - grupos lógicos de características comunes. Una reunión de partes interesadas funciona bien para agrupar características, al igual que funciona para crear requisitos. Puede agrupar características por flujo de uso, similitud técnica o necesidad comercial.

La visualización de temas y características en su hoja de ruta le permite asignar valor comercial y riesgos asociados con cada característica en relación con otras. El propietario del producto, junto con el equipo de desarrollo y las partes interesadas, también puede identificar las dependencias entre las funciones, localizar cualquier brecha y priorizar el orden en el que se debe desarrollar cada función en función de cada uno de estos factores. A continuación, se incluyen preguntas que debe considerar al agrupar y ordenar sus requisitos:

» ¿Cómo utilizarían los clientes nuestro producto?

» Si ofreciéramos esta función propuesta, ¿qué más tendrían que hacer los clientes? ¿Qué más podrían querer hacer?

» ¿Puede el equipo de desarrollo identificar afinidades o dependencias técnicas? Utilice las respuestas a estas preguntas para identificar sus temas. Luego, agrupe las características por estos temas. Por ejemplo, en la aplicación de banca móvil, los temas pueden ser

» Información de la cuenta

» Actas » Funciones de servicio al cliente » Funciones móviles La Figura 7-5 muestra características agrupadas por temas.

130

PARTE 3 Planificación y ejecución ágiles

FIGURA 7-5: Funciones agrupadas

por temas.

Paso 4: Estimación de esfuerzos y requisitos de pedido Ha identificado los requisitos de su producto y los ha organizado en grupos lógicos. A continuación, estima y prioriza los requisitos. Aquí hay algunos términos con los que debe estar familiarizado:

» Esfuerzo es la facilidad o dificultad de crear una funcionalidad a partir de un requisito.

» Un estimar, como sustantivo, puede ser el número o la descripción que usa para expresar el esfuerzo estimado de un requisito.

» Estimación un requisito, como verbo, significa llegar a una aproximación idea de lo fácil o difícil (cuánto esfuerzo) será crear ese requisito.

CAPÍTULO 7 Definición de la visión del producto y la hoja de ruta del producto

131

» Ordenar, o priorizar, un requisito significa determinar el

valor y riesgo en relación con otros requisitos, y en qué orden implementarlos.

» Valor Significa cuán beneficioso puede ser un requisito de producto para la organización. creación de ese producto.

» Riesgo se refiere al efecto negativo que puede tener un requisito en el proyecto. Puede estimar y priorizar los requisitos en cualquier nivel, desde temas y funciones hasta historias de usuarios individuales. Dar prioridad a los requisitos se trata realmente de ordenarlos. Puede encontrar varios métodos, muchos de ellos complicados, para determinar la prioridad de los elementos de la cartera de productos. Mantenemos las cosas simples al crear una lista ordenada de tareas pendientes de elementos de la cartera de productos, basada en el valor comercial, el riesgo y el esfuerzo, enumerados en el orden en que los implementará. Forzar un pedido requiere tomar una decisión prioritaria para cada requisito en relación con todos los demás requisitos. Un equipo de scrum puede trabajar en una cosa a la vez, por lo que es importante formatear la hoja de ruta de su producto en consecuencia.

Para calificar sus requisitos, trabaja con dos grupos diferentes de personas:

» El equipo de desarrollo determina el esfuerzo para implementar la funcionalidad. para cada requisito.

» El propietario del producto, con el apoyo de las partes interesadas, determina el valor y riesgo del requerimiento para el cliente y el negocio.

Estimación del esfuerzo Para solicitar requisitos, el equipo de desarrollo debe primero estimar el esfuerzo para cada requisito en relación con todos los demás requisitos. En el Capítulo 8, le mostramos técnicas de estimación relativa que los equipos ágiles utilizan para estimar con precisión el esfuerzo. Los métodos de estimación tradicionales apuntan a la precisión mediante el uso de estimaciones de tiempo absoluto en todos los niveles del cronograma del proyecto, ya sea que el equipo esté trabajando en los elementos de trabajo hoy o dentro de dos años. Esta práctica da a los equipos no ágiles una falsa sensación de precisión y no es precisa en la realidad (como lo demuestran miles de proyectos fallidos). ¿Cómo podría saber en qué estará trabajando cada miembro del equipo dentro de seis meses y cuánto tiempo llevará hacer ese trabajo, cuando recién está comenzando a aprender sobre el proyecto al principio?

Estimación relativa es un mecanismo de autocorrección que permite que los equipos ágiles sean más precisos porque es mucho más fácil acertar al comparar uno

132

PARTE 3 Planificación y ejecución ágiles

requisito contra otro y determinar si uno es más grande que otro, y aproximadamente en cuánto. Para ordenar sus requisitos, también desea conocer las dependencias. Las dependencias significan que un requisito es un antecesor de otro requisito. Por ejemplo, si tuviera una aplicación que necesita que alguien inicie sesión con un nombre de usuario y contraseña, el requisito para crear el nombre de usuario sería una dependencia del requisito para crear la contraseña, porque generalmente necesita un nombre de usuario para configurar un contraseña.

Evaluar el valor y el riesgo empresarial Junto con las partes interesadas, el propietario del producto identifica los elementos de mayor valor comercial (ya sea un ROI de alto potencial u otro valor percibido para el cliente final), así como aquellos elementos con un alto impacto negativo en el proyecto si no se resuelven.

De manera similar a las estimaciones de esfuerzo, se pueden asignar valores o riesgos a cada elemento de la hoja de ruta del producto. Por ejemplo, puede asignar valor usando cantidades de ROI monetarias o, para un producto usado internamente, asignar valor o riesgo usando alto, medio o bajo. Las estimaciones de esfuerzo, valor comercial y riesgo informan las decisiones de priorización del propietario del producto para cada requisito. Los elementos de mayor valor y riesgo deben estar en la parte superior de la hoja de ruta del producto. Los elementos de alto riesgo deben explorarse e implementarse primero para evitar la carga trasera del riesgo del proyecto. Si un elemento de alto riesgo hará que un proyecto falle (un problema que no se puede resolver), los equipos ágiles lo aprenden temprano. Si un proyecto va a fallar, querrá fallar temprano, fallar barato y pasar a un nuevo proyecto que tenga valor. En ese sentido, el fracaso es una forma de éxito para un equipo ágil.

Una vez que tenga sus estimaciones de valor, riesgo y esfuerzo, puede determinar la prioridad relativa, u orden, de cada requisito.

» Un requisito con alto valor o alto riesgo (o ambos) y bajo esfuerzo tendrá un prioridad relativa alta. El propietario del producto puede pedir este artículo en la parte superior de

la hoja de ruta.

» Un requisito con un valor bajo o un riesgo bajo (o ambos) y un esfuerzo elevado tendrá una prioridad relativa más baja. Es probable que este elemento termine en la parte inferior de la

mapa vial. La prioridad relativa es solo una herramienta para ayudar al propietario del producto a tomar decisiones y priorizar los requisitos. No es un universal matemático que debes seguir. Asegúrese de que sus herramientas ayuden en lugar de obstaculizar.

CAPÍTULO 7 Definición de la visión del producto y la hoja de ruta del producto

133

Priorizar requisitos Para determinar la prioridad general de sus requisitos, responda las siguientes preguntas:

» ¿Cuál es la prioridad relativa del requisito? » ¿Cuáles son los requisitos previos para cualquier requisito?

» ¿Qué conjunto de requisitos van juntos y constituirán un conjunto sólido de funcionalidad que puede entregar al cliente?

Con las respuestas a estas preguntas, puede colocar los requisitos de mayor prioridad en primer lugar en la hoja de ruta del producto. Cuando haya terminado de priorizar sus requisitos, tendrá algo que se parece a la Figura 7-6.

FIGURA 7-6: Hoja de ruta del producto

con ordenado requisitos.

Su lista priorizada de requisitos se llama Pila de Producto. Su cartera de productos es un documento ágil importante, o artefacto. Utiliza esta acumulación de trabajo en todo su proyecto. Con una cartera de productos en la mano, puede comenzar a agregar lanzamientos de destino a la hoja de ruta de su producto.

134

PARTE 3 Planificación y ejecución ágiles

Paso 5: Determinación de los períodos de tiempo de alto nivel Cuando crea la hoja de ruta de su producto, los plazos para publicar los requisitos del producto se encuentran en un nivel muy alto. Para la hoja de ruta inicial, elija un incremento de tiempo lógico para su proyecto, como una cierta cantidad de días, semanas, meses, trimestres (períodos de tres meses) o incluso incrementos mayores. Usando tanto el requisito como la prioridad, puede agregar requisitos a cada incremento de tiempo.

Crear una hoja de ruta de producto puede parecer mucho trabajo, pero una vez que lo domine, puede crear una en poco tiempo. Algunos equipos de scrum pueden crear una visión del producto, una hoja de ruta del producto y un plan de lanzamiento, ¡y estar listos para comenzar su sprint en tan solo un día! Para comenzar a desarrollar el producto, solo necesita requisitos suficientes para su primer sprint. Puede determinar el resto a medida que avanza el proyecto.

Guardando tu trabajo Hasta ahora, podía hacer toda la planificación de su hoja de ruta con pizarras blancas y notas adhesivas. Sin embargo, una vez finalizado el primer borrador completo, guarde la hoja de ruta del producto, especialmente si necesita compartir la hoja de ruta con partes interesadas remotas o miembros del equipo de desarrollo. Puede tomar una foto de sus notas adhesivas y pizarra, o puede escribir la información en un documento y guardarlo electrónicamente. Actualiza la hoja de ruta del producto a lo largo del proyecto, a medida que cambian las prioridades. Por ahora, el contenido de la primera versión debería ser claro, y eso es todo de lo que debe preocuparse en esta etapa.

Completar la lista de trabajos pendientes del producto La hoja de ruta del producto contiene características de alto nivel y algunos plazos de lanzamiento tentativos. Los requisitos de la hoja de ruta de su producto son la primera versión de su

Pila de Producto. La cartera de productos es la lista de todos los requisitos asociados con el proyecto. El propietario del producto es responsable de crear y mantener la acumulación de productos agregando y priorizando requisitos. El equipo de scrum utiliza la cartera de productos priorizada a lo largo del proyecto para planificar su trabajo, como un plan de proyecto simplificado.

CAPÍTULO 7 Definición de la visión del producto y la hoja de ruta del producto

135

La Figura 7-7 muestra una muestra de la cartera de productos. Como mínimo, cuando cree su cartera de productos, asegúrese de hacer lo siguiente:

» Incluya una descripción de cada requisito. » Ordene los requisitos según la prioridad. » Sume la estimación de esfuerzo.

FIGURA 7-7: Pila de Producto muestra de artículos.

También nos gusta incluir el tipo de elemento de la cartera de pedidos, así como el estado. Los equipos de Scrum trabajarán principalmente en el desarrollo de funciones como se describe en las palabras del usuario (historias de usuario). Pero puede haber necesidad de otros tipos de elementos de la cartera de productos, como elementos generales (cosas que el equipo de scrum determina que son necesarias pero que no contribuyen a la funcionalidad), elementos de mantenimiento (mejoras de diseño que deben realizarse en el producto o sistema). pero no aumentan directamente el valor para el cliente) o elementos de mejora (elementos de acción para mejoras de proceso identificadas en la retrospectiva del sprint). Puede ver ejemplos de cada uno de estos en la Figura 7-7.

En el Capítulo 2, explicamos cómo los documentos para proyectos ágiles deberían ser apenas suficientes, con solo la información que es absolutamente necesaria para crear el producto. Si mantiene el formato de la lista de trabajos pendientes de su producto simple y apenas suficiente, ahorrará tiempo actualizándolo durante todo el proyecto. El equipo de scrum se refiere a la acumulación de productos como la fuente principal de los requisitos del proyecto. Si existe un requisito, está en la cartera de productos. Los requisitos en la cartera de pedidos de su producto cambiarán a lo largo del proyecto de varias maneras. Por ejemplo, a medida que el equipo completa los requisitos, usted marca esos requisitos como completos en la cartera de pedidos del producto. También registra los nuevos requisitos recopilados en función de los comentarios de las partes interesadas y los clientes. Algunos requisitos

136

PARTE 3 Planificación y ejecución ágiles

actualizarse con información nueva o aclarada, dividirse en historias de usuarios más pequeñas o perfeccionarse de otras formas. Además, actualiza las puntuaciones de prioridad y esfuerzo de los requisitos existentes según sea necesario. El número total de puntos de la historia en la cartera de pedidos del producto, todos los puntos de la historia del usuario sumados, es su estimación de la cartera de productos. Esta estimación cambia diariamente a medida que se completan las historias de usuarios y se agregan nuevas historias de usuarios. Descubra más sobre el uso de la estimación de la acumulación de productos para predecir la duración y el costo del proyecto en el Capítulo 13.

Mantenga actualizada la acumulación de productos para que siempre tenga estimaciones precisas de costos y cronogramas. Una cartera de productos actual también le brinda la flexibilidad de priorizar los requisitos de productos recientemente identificados, un beneficio ágil clave, frente a las características existentes. Una vez que tenga una acumulación de productos, puede comenzar a planificar lanzamientos y sprints, que le mostramos en el siguiente capítulo.

CAPÍTULO 7 Definición de la visión del producto y la hoja de ruta del producto

137

EN ESTE CAPÍTULO

» Requisitos de descomposición y creando historias de usuario » Creación de una cartera de productos, lanzamiento

plan y backlog de sprint » Planificación de sprints

Capítulo

Planificación Liberaciones y

Sprints

es hora de comenzar a elaborar los detalles de su producto. En este capítulo, descubrirá cómo sus a unsunivel máságil granular, Después de crear unadesglosar hoja de ruta delrequisitos producto para proyecto (consulte el Capítulo 7),

refinar su cartera de productos, crear un plan de lanzamiento y crear una lista de trabajos pendientes para

ejecución. Primero, verá cómo desglosar los requisitos más importantes de la hoja de ruta de su producto en requisitos más pequeños y manejables llamados historias de usuarios. El concepto de dividir los requisitos en partes más pequeñas se llama descomposición.

Requisitos y estimaciones de refinamiento Empiezas proyectos ágiles con requisitos muy grandes. A medida que avanza el proyecto y se acerca al desarrollo de esos requisitos, los dividirá en partes más pequeñas, lo suficientemente pequeñas como para comenzar a desarrollar. Un formato claro y eficaz para definir los requisitos del producto es la historia del usuario. La historia del usuario y su prima más grande, la historia del usuario épica, son requisitos de gran tamaño.

CAPÍTULO 8 Planificación de lanzamientos y sprints

139

para la planificación de lanzamientos y planificación de sprints. En esta sección, descubrirá cómo crear una historia de usuario, priorizar historias de usuario y estimar el esfuerzo de la historia de usuario.

¿Qué es una historia de usuario? La historia del usuario es una descripción simple de un requisito de producto en términos de lo que ese requisito debe lograr para quién. Los requisitos tradicionales suelen leer algo como esto: "El sistema debe [insertar descripción técnica]". Este requisito se refiere únicamente a la naturaleza técnica de lo que se hará; el objetivo comercial general no está claro. Debido a que el equipo de desarrollo tiene el contexto para involucrarse más profundamente, claramente conoce el beneficio para el usuario (o el cliente o la empresa) de cada requisito y entrega lo que el cliente desea más rápido y con mayor calidad.

Su historia de usuario tendrá, como mínimo, las siguientes partes: Título (nombre reconocible para la historia de usuario) Como (tipo de usuario)

Quiero (tomar esta acción) para que (obtengo este beneficio)

La historia de usuario también incluye una lista de pasos de validación ( criterios de aceptación) tomar para que sepa que el requisito de trabajo para la historia de usuario es correcto: Cuando yo (tomo esta acción), (esto sucede) Las historias de usuario también pueden incluir lo siguiente:

» Un ID de historia de usuario: Un número para diferenciar esta historia de usuario de otra historias de usuarios.

» El valor de la historia de usuario y la estimación del esfuerzo: Valor es lo beneficioso que es un usuario La historia podría ser para la organización que crea ese producto. Esfuerzo es la facilidad o dificultad para crear esa historia de usuario. En el Capítulo 7 presentamos cómo calificar el valor comercial, el riesgo y el esfuerzo de una historia de usuario.

» El nombre de la persona que pensó en la historia del usuario: Cualquiera en el El equipo del proyecto puede crear una historia de usuario.

140

PARTE 3 Planificación y ejecución ágiles

Aunque los enfoques de gestión de proyectos ágiles fomentan las herramientas de baja tecnología, el equipo de scrum también debe averiguar qué funciona mejor en cada situación. Hay muchas herramientas electrónicas de historias de usuarios disponibles, algunas de las cuales son gratuitas. Algunos son simples y solo para historias de usuarios. Otros son complejos y se integrarán con otros documentos de productos. Nos encantan las fichas, pero es posible que esa solución no sea para todos. Utilice lo que funcione mejor para su equipo de scrum y su proyecto. La Figura 8-1 muestra una tarjeta de historia de usuario típica, anverso y reverso. El frente tiene la descripción principal de la historia del usuario. La parte posterior muestra cómo confirmará que el requisito funciona correctamente, después de que el equipo de desarrollo haya creado la funcionalidad.

FIGURA 8-1: Usuario basado en tarjeta

ejemplo de historia.

El propietario del producto recopila las historias de los usuarios y las gestiona (es decir, determina la prioridad e inicia las discusiones de descomposición). El equipo de desarrollo y otras partes interesadas también participan en la creación y descomposición de historias de usuarios. Tenga en cuenta que las historias de usuario no son la única forma de describir los requisitos del producto. Simplemente podría hacer una lista de requisitos sin una estructura determinada. Sin embargo, debido a que las historias de usuario incluyen mucha información útil en un formato simple y compacto, encontramos que son muy efectivas para transmitir exactamente lo que un requisito debe hacer para el cliente.

El gran beneficio del formato de historia de usuario es cuando el equipo de desarrollo comienza a crear y probar requisitos. Los miembros del equipo de desarrollo saben exactamente para quién están creando el requisito, qué debe hacer el requisito y cómo verificar que el requisito satisface la intención del requisito.

Usamos historias de usuarios como ejemplos de requisitos a lo largo del capítulo y del libro. Tenga en cuenta que cualquier cosa que describamos que puede hacer con las historias de usuario, también puede hacerlo con requisitos expresados de manera más genérica.

CAPÍTULO 8 Planificación de lanzamientos y sprints

141

Pasos para crear una historia de usuario Al crear una historia de usuario, siga estos pasos:

1. Identificar a las partes interesadas del proyecto.

2. Identifique quién utilizará el producto.

3. Trabajando con las partes interesadas, anote los requisitos que El producto necesitará y utilizará el formato descrito anteriormente para crear sus historias de usuario.

Descubra cómo seguir estos tres pasos en las siguientes secciones. Ser ágil y adaptable requiere iterar. No pierda mucho tiempo tratando de identificar todos y cada uno de los requisitos que pueda tener su producto. Siempre puede agregar requisitos más adelante en el proyecto. Los mejores cambios a menudo se producen al final de un proyecto, cuando más se sabe sobre el producto y los clientes.

Identificación de las partes interesadas del proyecto Probablemente tenga una buena idea acerca de quiénes son las partes interesadas de su proyecto: cualquier persona involucrada, afectada o que pueda afectar el producto y su creación.

También trabajará con las partes interesadas cuando cree la visión de su producto y la hoja de ruta de su producto. Asegúrese de que las partes interesadas estén disponibles para ayudarlo a crear requisitos. Las partes interesadas de la aplicación de banca móvil de muestra presentada en el Capítulo 7 podrían incluir las siguientes:

» Las personas que interactúan con los clientes de forma regular, como el cliente representantes de servicio o personal de sucursales bancarias.

» Expertos en negocios para las diferentes áreas donde los clientes de su producto interactuar. Por ejemplo, XYZ Bank podría tener un gerente a cargo de

cuentas corrientes, otro gerente a cargo de las cuentas de ahorro y un tercer gerente a cargo de los servicios de pago de facturas en línea. Si está creando una aplicación de banca móvil, todas estas personas serían partes interesadas del proyecto.

» Usuarios de su producto, si están disponibles. » Expertos en el tipo de producto que estás creando. Por ejemplo, un desarrollador que ha creado aplicaciones móviles, un director de marketing que sabe cómo

crear campañas móviles y un especialista en experiencia de usuario que se especialice en interfaces móviles, todo podría ser útil en el proyecto de banca móvil de muestra de XYZ Bank.

142

PARTE 3 Planificación y ejecución ágiles

» Actores técnicos. Estas son personas que trabajan con los sistemas que puede que necesite interactuar con su producto.

Identificación de usuarios Sus clientes y partes interesadas proporcionan requisitos para que el propietario del producto investigue para ubicarlo en su cartera de productos. Sus clientes pueden ser o no las mismas personas que utilizarán su producto. Saber quiénes son sus usuarios finales y cómo interactuarán con su producto impulsa la forma en que define e implementa cada requisito en la hoja de ruta de su producto. Con la hoja de ruta de su producto visualizada, puede identificar a cada tipo de usuario. Para la aplicación de banca móvil, tendría banqueros individuales y comerciales. La categoría individual incluiría jóvenes, adultos jóvenes, estudiantes y usuarios solteros, casados, jubilados y adinerados. Pueden estar representadas empresas de todos los tamaños. Los usuarios empleados incluirían cajeros, gerentes de sucursales, gerentes de cuentas y administradores de fondos. Cada tipo de usuario interactuará con su aplicación de diferentes formas y por diferentes motivos. Saber quiénes son estas personas le permite definir mejor el propósito y los beneficios deseados de cada una de sus interacciones. Nos gusta definir usuarios usando personas o una descripción escrita sobre un tipo de usuario representado por una persona ficticia. Por ejemplo, “Robert es un ingeniero jubilado de 65 años que pasa su jubilación viajando por el mundo. Su patrimonio neto es de $ 1,000,000 y tiene ingresos residuales de varias propiedades inmobiliarias de inversión ". “Robert” representa el 30 por ciento de los clientes de XYZ Bank y una buena parte de la hoja de ruta del producto incluye características que alguien como Robert usará. En lugar de repetir todos los detalles sobre Robert cada vez que el equipo de scrum analiza estas características, simplemente pueden referirse al tipo de usuario como "Robert". El propietario del producto puede identificar varios de estos, según sea necesario, e incluso imprimirá las descripciones con una foto de archivo de cómo se vería Robert y las publicará en la pared del área de trabajo del equipo para consultarlas durante todo el proyecto. Sepa quiénes son sus usuarios, para que pueda desarrollar funciones que realmente usarán.

Suponga que es el propietario del producto del proyecto de banca móvil de XYZ Bank. Eres responsable del departamento que llevará el producto al mercado, preferiblemente en los próximos seis meses. Tiene las siguientes ideas sobre los usuarios de la aplicación:

» Los clientes (los usuarios finales de la aplicación) probablemente quieran un acceso rápido a información actualizada sobre sus saldos y transacciones recientes.

» Tal vez los clientes estén a punto de comprar un artículo caro y quieran asegúrese de que puedan cargarlo.

CAPÍTULO 8 Planificación de lanzamientos y sprints

143

» Quizás las tarjetas de cajero automático de los clientes simplemente fueron rechazadas, pero no tienen idea por qué, y quieren comprobar las transacciones recientes en busca de posibles fraudulentos ocupaciones.

» Quizás los clientes se dieron cuenta de que se olvidaron de pagar la factura de su tarjeta de crédito. y tendrán cargos de penalización si no pagan la tarjeta hoy.

¿Quiénes son sus personajes para esta aplicación? Aquí están algunos ejemplos:

» Persona # 1: Jason es un joven ejecutivo experto en tecnología que viaja mucho. Cuando el tiene un momento libre, quiere ocuparse de sus asuntos personales rápidamente. Él invierte cuidadosamente su dinero en carteras de alto interés. Mantiene bajo su efectivo disponible.

» Persona # 2: Carol es propietaria de una pequeña empresa que organiza propiedades cuando

los clientes están intentando vender su casa. Compra en los centros de envío y a menudo encuentra muebles que quiere comprar para sus clientes.

» Persona # 3: Nick es un estudiante que vive de préstamos estudiantiles y de un trabajo a tiempo parcial. Él sabe que puede ser inestable con el dinero porque es inestable con todo lo demás. Acaba de perder su chequera.

Las partes interesadas de su producto pueden ayudarlo a crear personas. Encuentre personas que sean expertas en el negocio diario de su producto. Esas partes interesadas sabrán mucho sobre sus clientes potenciales.

Determinar los requisitos del producto y crear historias de usuarios Una vez que haya identificado a sus diferentes clientes, puede comenzar a determinar los requisitos del producto y crear historias de usuario para las personas. Una buena forma de crear historias de usuarios es reunir a las partes interesadas para una sesión de creación de historias de usuarios.

Haga que las partes interesadas escriban tantos requisitos como puedan pensar, utilizando el formato de historia de usuario. Una historia de usuario para el proyecto y las personas de las secciones anteriores podría ser la siguiente:

» Anverso de la tarjeta:

• • • • 144

Título Ver saldo de la cuenta bancaria Como Jason

yo quiero ver el saldo de mi cuenta corriente en mi teléfono inteligente

así que eso Puedo ver cuánto dinero tengo en mi cuenta corriente

PARTE 3 Planificación y ejecución ágiles

» Reverso de la tarjeta:

•

Cuando yo iniciar sesión en la aplicación móvil de XYZ Bank, el saldo de mi cuenta

•

Cuando yo iniciar sesión en la aplicación móvil de XYZ Bank después de realizar una

corriente aparece en la parte superior de la página.

compra o un depósito, el saldo de mi cuenta corriente refleja esa compra o depositar.

Puede ver ejemplos de historias de usuarios en formato de tarjeta en la Figura 8-2.

FIGURA 8-2: Usuario de muestra

cuentos.

Asegúrese de agregar y priorizar continuamente nuevas historias de usuarios a su cartera de productos. Mantener actualizada la acumulación de productos le ayudará a tener las historias de usuarios de mayor prioridad cuando sea el momento de planificar su sprint.

A lo largo de un proyecto ágil, creará nuevas historias de usuario. También tomará los grandes requisitos existentes y los descompondrá hasta que sean lo suficientemente manejables como para trabajar durante un sprint.

CAPÍTULO 8 Planificación de lanzamientos y sprints

145

Desglosando los requisitos Refina los requisitos muchas veces a lo largo de un proyecto ágil. Por ejemplo:

» Cuando crea la hoja de ruta del producto (consulte el Capítulo 7), crea características (capacidades que tendrán sus clientes después de que desarrolle las funciones), así como temas (grupos lógicos de características). Aunque las características son intencionalmente grandes, requerimos que las características en el nivel de la hoja de ruta del producto no superen los 144 puntos de historia en la escala de Fibonacci.

» Cuando planifica lanzamientos, desglosa las funciones en un usuario más conciso cuentos. Las historias de usuario en el nivel del plan de lanzamiento pueden ser epopeyas usuario muy grande

historias con varias acciones, o historias de usuarios individuales, que contienen una sola acción. Para nuestros clientes, las historias de usuario a nivel del plan de lanzamiento no deben superar los 34 puntos de la historia. Encontrará más información sobre las versiones más adelante en este capítulo.

» Cuando planifica sprints, puede desglosar aún más las historias de usuarios. Tú también identifique las tareas individuales asociadas con cada historia de usuario en el sprint. Para

Para nuestros clientes, las historias de usuario a nivel de sprint no deben tener más de ocho puntos de historia. Las tareas se estimarán en horas y no deberían ser mayores de lo que se puede realizar en un día.

Para descomponer los requisitos, querrá pensar en cómo dividir los requisitos en acciones individuales. La Tabla 8-1 muestra un requisito de la aplicación XYZ Bank presentada en el Capítulo 7 que se descompone desde el nivel de tema hasta el nivel de historia de usuario.

TABLA 8-1

Descomposición de un requisito

Nivel de requisito

Requisito

Tema

Ver datos de cuentas bancarias en un dispositivo móvil.

Características

Ver saldos de cuentas.

Vea una lista de retiros o compras recientes. Vea una lista de depósitos recientes. Vea mis próximos pagos automáticos de facturas. Ver las alertas de mi cuenta.

Historias de usuarios épicas: descompuestas de "ver saldos de cuentas"

Consulte el saldo de la cuenta corriente. Ver saldo de la cuenta de ahorros. Ver saldo del préstamo. Ver saldo de la cuenta de inversión. Consulte el saldo de la cuenta de jubilación.

146

PARTE 3 Planificación y ejecución ágiles

Nivel de requisito

Requisito

Historias de usuarios: descompuesto de "ver saldo de la

Ver una lista de mis cuentas una vez que haya iniciado sesión de

cuenta corriente"

forma segura. Seleccione y vea mi cuenta corriente. Vea los cambios en el saldo de la cuenta después de los retiros. Ver cambios en el saldo de la cuenta después de las compras. Ver el saldo de la cuenta al final del día.

Ver saldo de cuenta disponible. Consulte los elementos de navegación de aplicaciones móviles. Cambiar la vista de la cuenta.

Cierre la sesión de la aplicación móvil.

HISTORIAS DE USUARIOS Y EL ENFOQUE DE INVERSIÓN Es posible que se pregunte qué grado de descomposición debe tener una historia de usuario. Bill Wake, en su blog en XP123.com, describe el enfoque INVEST para garantizar la calidad en las historias de los usuarios. Nos gusta su método tanto que lo incluimos aquí.

Utilizando el enfoque INVEST, las historias de usuarios deben

•

I Independiente: En la medida de lo posible, una historia no debería necesitar otras historias para implementar la característica que describe la historia.

•

norte egotiable: No demasiado detallado. La historia del usuario tiene espacio para la discusión y una expansión de detalles.

•

V valioso: la historia demuestra el valor del producto para el cliente. La historia describe características, no tareas técnicas para implementarla. La historia está en el usuario.

idioma y es fácil de explicar. Las personas que utilizan el producto o sistema pueden comprender la historia.

•

mi stimable: la historia es descriptiva, precisa y concisa, por lo que los desarrolladores generalmente pueden estimar el trabajo necesario para crear la funcionalidad en la historia del usuario.

•

S mall: es más fácil planificar y estimar con precisión las pequeñas historias de usuarios. Una buena regla general es que el equipo de desarrollo puede completar de 6 a 10 historias de usuario en un sprint.

•

T estable: Puedes validar fácilmente la historia del usuario, y los resultados son definitivos.

CAPÍTULO 8 Planificación de lanzamientos y sprints

147

Póquer de estimación A medida que refina sus requisitos, también debe refinar sus estimaciones. ¡Es hora de divertirse! Una de las formas más populares de estimar las historias de los usuarios es jugando póquer de estimación, aveces llamado planificación de póquer, un juego para determinar el tamaño de la historia del usuario y generar consenso entre los miembros del equipo de desarrollo.

El scrum master puede ayudar a coordinar la estimación y el propietario del producto puede proporcionar información sobre las características, pero el equipo de desarrollo es responsable de estimar el nivel de esfuerzo requerido para las historias de usuario. Después de todo, el equipo de desarrollo tiene que hacer el trabajo para crear las características que describen esas historias.

Para jugar al póquer de estimación, necesita una baraja de cartas como la de la Figura 8-3. Puede obtener una versión digital en línea en nuestro sitio web ( www.platinumedge.com/imensionpoker), o puede hacer el suyo propio con fichas y marcadores. Los números de las tarjetas son de la secuencia de Fibonacci.

FIGURA 8-3: Una baraja de

póquer de estimación tarjetas.

La secuencia de Fibonacci sigue esta progresión: 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, etc. Cada número después de los dos primeros es la suma de los dos números anteriores. Cada historia de usuario recibe una estimación relativa a otras historias de usuario. Por ejemplo, una historia de usuario que es un 5 requiere más trabajo que un 3, un 2 y un 1. Es aproximadamente 5 veces más esfuerzo que un 1, más del doble del esfuerzo de un 2 y aproximadamente la cantidad de esfuerzo como un 3 y un 2 combinados. No es tanto esfuerzo como un 8, pero es un poco más de la mitad del esfuerzo de un 8. A medida que las historias de usuarios y las historias de usuarios épicas aumentan de tamaño, la diferencia entre los números de Fibonacci aumenta. Reconocer estas crecientes brechas de precisión para requisitos más grandes es la razón por la que la secuencia de Fibonacci funciona tan bien para la estimación relativa.

148

PARTE 3 Planificación y ejecución ágiles

Para jugar al poker de estimación, siga estos pasos:

1. Proporcione a cada miembro del equipo de desarrollo un paquete de estimaciones cartas de póquer.

2. De la lista de historias de usuario presentada por el propietario del producto, el equipo está de acuerdo en una historia de usuario que sería 5.

El equipo sigue dos reglas: (1) El equipo de desarrollo no debe permitir que una historia de un solo usuario mayor que un 8 se introduzca en un sprint, y (2) los equipos de scrum deben poder completar aproximadamente 6-10 historias de usuario en un sprint. . El scrummaster ayuda al equipo de desarrollo a llegar a un consenso utilizando el puño de cinco o el pulgar hacia arriba / hacia abajo (como se describe en el Capítulo 6). Esta historia de usuario se convierte en la historia de ancla.

3. El propietario del producto lee una historia de usuario de alta prioridad a los jugadores.

4. Cada jugador selecciona una tarjeta que representa su estimación del esfuerzo. participa en la historia del usuario y coloca la carta boca abajo sobre la mesa. Los jugadores deben comparar la historia del usuario con otras historias de usuario que hayan estimado. (La primera vez, los jugadores comparan la historia del usuario solo con la historia del ancla). Asegúrese de que ningún otro jugador pueda ver su tarjeta.

5. Todos los jugadores dan la vuelta a sus cartas simultáneamente.

6. Si los jugadores tienen diferentes puntos de historia: una. Es hora de discutir. Los jugadores con las puntuaciones más altas y más bajas hablan sobre sus suposiciones y por qué creen que la estimación de la historia del usuario debería ser más alta o más baja, respectivamente. Los jugadores comparan el esfuerzo de la historia del usuario con la historia del ancla. El propietario del producto proporciona más aclaraciones sobre la historia, según sea necesario. B. Una vez que todos están de acuerdo con las suposiciones y tienen las aclaraciones necesarias, los jugadores reevalúan sus estimaciones y colocan sus nuevas cartas seleccionadas sobre la mesa.

C. Si los puntos de la historia son diferentes, los jugadores repiten el proceso, generalmente hasta tres veces. D. Si los jugadores no pueden ponerse de acuerdo sobre el esfuerzo estimado, el scrummaster ayuda al equipo de desarrollo a determinar una puntuación que todos los jugadores puedan apoyar (él o ella pueden usar el puño de cinco o el pulgar hacia arriba / pulgar hacia abajo, como se describe en el Capítulo 6), o determinar que la historia del usuario requiere más detalles o debe desglosarse más.

7. Los jugadores repiten los pasos del 3 al 6 para cada historia de usuario.

CAPÍTULO 8 Planificación de lanzamientos y sprints

149

Considere cada parte de la definición de hecho - desarrollado, integrado, probado y documentado, cuando crea estimaciones. Puede jugar al póquer de estimación en cualquier momento, pero definitivamente juegue durante el desarrollo de la hoja de ruta del producto y a medida que desglosa progresivamente las historias de los usuarios para incluirlas en los lanzamientos y los sprints. Con la práctica, el equipo de desarrollo entrará en un ritmo de planificación y se volverá más experto en estimar rápidamente. En promedio, los equipos de desarrollo dedicarán alrededor del 10 por ciento de su tiempo a un proyecto a descomponer los requisitos, incluida la estimación y la reestimación. ¡Haga que sus juegos de póquer de estimación sean divertidos! Traiga bocadillos, tome descansos según sea necesario, use el humor y mantenga el estado de ánimo ligero.

Estimación de afinidad El póquer de estimación puede ser eficaz, pero ¿y si tienes muchas historias de usuarios? Jugar al póquer de estimación para, digamos, 500 historias de usuarios podría llevar mucho tiempo. Necesita una forma de centrarse solo en las historias de usuario que debe discutir para obtener un consenso.

Cuando tiene una gran cantidad de historias de usuario, muchas de ellas probablemente sean similares y requerirían un esfuerzo similar para completarlas. Una forma de determinar las historias adecuadas para la discusión es utilizar la estimación de afinidad. En estimación de afinidad,

categoriza rápidamente sus historias de usuario y luego aplica estimaciones a estas categorías de historias. Al realizar estimaciones por afinidad, escriba sus historias de usuario en tarjetas de índice o notas adhesivas. Estos tipos de tarjetas de historias de usuario funcionan bien al categorizar historias rápidamente.

La estimación de afinidad puede ser una actividad rápida y furiosa: el equipo de desarrollo puede optar por que el scrum master ayude a facilitar las sesiones de estimación de afinidad. Para estimar por afinidad, siga estos pasos:

1. Tomando no más de 60 segundos para cada categoría, el desarrollo se gradúa en una sola historia de usuario en cada una de las siguientes categorías:

• • • • • • • 150

Historia de usuario extra pequeña Pequeña historia de usuario

Historia de usuario medio Gran historia de usuario Historia de usuario extragrande

Historia de usuario épica que es demasiado grande para entrar en el sprint

Necesita aclaración antes de estimar

PARTE 3 Planificación y ejecución ágiles

2. Tomando no más de 60 segundos por historia de usuario, el equipo de desarrollo coloca todas las historias restantes en las categorías enumeradas en el Paso 1.

Si está utilizando fichas o notas adhesivas para sus historias de usuario, puede colocar físicamente esas tarjetas en categorías en una mesa o una pizarra, respectivamente. Si divide las historias de usuario entre los miembros del equipo de desarrollo, haciendo que cada miembro del equipo de desarrollo categorice un grupo de historias, ¡este paso puede ser rápido!

3. Tomando otros 30 minutos, máximo, por cada 100 historias, el desarrollo El equipo de mento revisa y ajusta la ubicación de las historias de usuario. Todo el equipo de desarrollo debe estar de acuerdo en la ubicación de las historias de usuario en categorías de tamaño.

4. El propietario del producto revisa la categorización. 5. Cuando la estimación esperada del propietario del producto y la real del equipo estiman difieren en más de un tamaño de historia, ellos discuten esa historia de usuario.

El equipo de desarrollo puede decidir o no ajustar el tamaño de la historia.

6. El desarrollo de juegos de póquer de estimación en las historias de usuario en ambos la épica y las categorías de aclaración de necesidades.

El número de historias de usuarios en estas categorías debe ser mínimo. Tenga en cuenta que después de que el propietario del producto y el equipo de desarrollo discuten las aclaraciones, el equipo de desarrollo tiene la última palabra sobre el tamaño de la historia del usuario.

Las historias de usuario en la misma categoría de tamaño tendrán la misma puntuación de historia de usuario. Puede jugar una ronda de póquer de estimación para verificar algunas, pero no tendrá que perder tiempo en discusiones innecesarias sobre cada historia de usuario. Los tamaños de las historias son como los tamaños de las camisetas y deben corresponder a los números de escala de Fibonacci, como se muestra en la Figura 8-4.

FIGURA 8-4: Tamaños de historia como

Tallas de camiseta y

su Fibonacci números.

CAPÍTULO 8 Planificación de lanzamientos y sprints

151

Puede utilizar las técnicas de estimación y priorización de este capítulo para los requisitos de cualquier nivel, desde temas y funciones hasta historias de usuarios individuales. Eso es. En unas pocas horas, se estimó toda la acumulación de productos. Además, su equipo de scrum tiene un entendimiento compartido de lo que significan los requisitos, habiéndolos discutido cara a cara en lugar de depender de interpretaciones de documentación extensa.

Planificación de lanzamiento A lanzamiento es un grupo de características de productos utilizables que se implementan en el mercado. No es necesario que una versión incluya todas las funciones descritas en la hoja de ruta del producto, pero debe incluir al menos la características mínimas comercializables, el grupo más pequeño de características de productos que puede implementar y promover de manera efectiva en el mercado. Sus primeras versiones excluirán muchos de los requisitos de prioridad media y baja que identificó durante la etapa de la hoja de ruta del producto. Al planificar un lanzamiento, usted establece el siguiente conjunto de características comerciales mínimas e identifica una fecha inminente de lanzamiento del producto en torno a la cual el equipo puede movilizarse. Al igual que al crear la declaración de visión y la hoja de ruta del producto, el propietario del producto es responsable de crear el objetivo de lanzamiento y establecer la fecha de lanzamiento. Sin embargo, las estimaciones del equipo de desarrollo, con la facilitación del scrum master, contribuyen al proceso. La planificación del lanzamiento es la etapa 3 de la Hoja de ruta hacia el valor (consulte el Capítulo 7 para ver la hoja de ruta en su totalidad). La Figura 8-5 muestra cómo la planificación de lanzamientos encaja en un proyecto ágil.

FIGURA 8-5: Planificación de lanzamientos

como parte de la Hoja de ruta hacia

Valor.

La planificación del lanzamiento implica completar dos actividades clave:

» Revisión de la cartera de productos: En el Capítulo 7, te contamos que el producto El backlog es una lista completa de todas las historias de usuarios que conoce actualmente.

152

PARTE 3 Planificación y ejecución ágiles

su proyecto, pertenezcan o no a la versión actual. Tenga en cuenta que su lista de historias de usuarios probablemente cambiará a lo largo del proyecto.

» Creando el plan de lanzamiento: Esta actividad consiste en el objetivo de lanzamiento, lanzamiento fecha objetivo y priorización de los elementos de la cartera de productos que respaldan la meta de lanzamiento. El plan de lanzamiento proporciona una meta de rango medio que el equipo puede lograr.

No cree una acumulación nueva e independiente durante la planificación de la versión. La tarea es innecesaria y reduce la flexibilidad del propietario del producto. Dar prioridad a la acumulación de productos existente en función del objetivo de lanzamiento es suficiente y permite al propietario del producto tener la información más reciente cuando se compromete con el alcance durante la planificación del sprint.

La cartera de pedidos del producto y el plan de lanzamiento son algunos de los canales de comunicación más importantes entre el propietario del producto y el equipo de desarrollo. En el Capítulo 7, encontrará información sobre cómo completar una cartera de productos. A continuación se describe cómo crear un plan de lanzamiento. El plan de lanzamiento contiene un calendario de lanzamiento para un conjunto específico de funciones. El propietario del producto crea un plan de lanzamiento al comienzo de cada lanzamiento. Para crear un plan de lanzamiento, siga estos pasos:

1. Establece el objetivo de lanzamiento. El objetivo de lanzamiento es un objetivo comercial general para las funciones del producto en su lanzamiento. El propietario del producto y el equipo de desarrollo colaboran para crear un objetivo de lanzamiento basado en las prioridades comerciales y la velocidad y las capacidades de desarrollo del equipo de desarrollo.

2. Identifica una fecha de lanzamiento objetivo. Algunos equipos de scrum determinan las fechas de lanzamiento en función de la finalización de la funcionalidad; otros pueden tener fechas difíciles, como el 31 de marzo o el 1 de septiembre.

3. Revise la acumulación de productos y la hoja de ruta del producto para determinar el historias de usuarios de mayor prioridad que respaldan su objetivo de lanzamiento (las características mínimas comercializables).

Estas historias de usuarios constituirán su primer lanzamiento. Nos gusta lograr lanzamientos con aproximadamente el 80 por ciento de las historias de usuarios, utilizando el 20 por ciento final para agregar funciones sólidas que cumplirán el objetivo de lanzamiento y al mismo tiempo aumentar el factor "sorpresa" del producto.

4. Refina las historias de usuario en tu objetivo de lanzamiento. Durante la planificación del lanzamiento, a menudo se identifican dependencias, brechas o nuevos detalles que afectan las estimaciones y la priorización. Este es el momento de asegurarse de que

CAPÍTULO 8 Planificación de lanzamientos y sprints

153

La parte de la acumulación de productos que respalda su lanzamiento tiene el tamaño adecuado. Nos gusta asegurarnos de que los requisitos que respaldan el objetivo de lanzamiento actual no tengan un tamaño mayor a 34. El equipo de desarrollo ayuda al propietario del producto actualizando las estimaciones para cualquier historia de usuario agregada o revisada, y se compromete con el objetivo y el alcance del lanzamiento con el propietario del producto.

5. Estime el número de sprints necesarios, en función de los resultados del equipo scrum. velocidad. Los equipos de Scrum usan la velocidad para planificar la cantidad de trabajo que pueden realizar en un lanzamiento y un sprint. Velocidad es la suma de todos los puntos de la historia de usuario completados en un sprint. Entonces, si un equipo de scrum completó seis historias de usuario durante su primer sprint con tamaños 8,

5, 5, 3, 2, 1, su velocidad para el primer sprint es 24. El equipo de scrum planificaría su segundo sprint teniendo en cuenta que completó 24 puntos de historia durante el primer sprint. Después de múltiples sprints, los equipos de scrum pueden usar su velocidad promedio de carrera como entrada para determinar cuánto trabajo pueden realizar en un sprint, así como para extrapolar su programa de lanzamiento dividiendo el número total de puntos de historia en el lanzamiento por su velocidad promedio. . Aprenderá más sobre la velocidad en el Capítulo 13.

6. Identificar el trabajo necesario para liberar que no se puede completar dentro de un pique. Planifique un sprint de lanzamiento, si es necesario, y determine cuánto tiempo debería ser. Algunos equipos de proyecto agregan un lanzamiento de sprint a algunos lanzamientos para realizar actividades que no están relacionadas con el desarrollo del producto, pero que son necesarias para entregar el producto a los clientes. Si necesita un sprint de lanzamiento, asegúrese de tenerlo en cuenta en la fecha que elija. Puede encontrar más información sobre los sprints de lanzamiento en el Capítulo 11.

Algunas tareas, como las pruebas de seguridad o las pruebas de carga de un proyecto de software, no se pueden completar dentro de un sprint, porque los entornos de pruebas de seguridad o de carga requieren tiempo para configurarse y solicitarse. Aunque los sprints de lanzamiento permiten a los equipos de scrum planificar este tipo de actividades, hacerlo es un anti-patrón, o lo opuesto a ser ágil. Su objetivo debe ser completar todo el trabajo requerido para que la funcionalidad se pueda enviar al final de cada sprint.

No todos los proyectos ágiles utilizan la planificación de versiones. Algunos equipos de scrum lanzan funciones para el uso del cliente con cada sprint o incluso todos los días. El equipo de desarrollo, el producto, la organización, los clientes, las partes interesadas y la complejidad tecnológica del proyecto pueden ayudar a determinar su enfoque para los lanzamientos de productos.

Los lanzamientos previstos ahora pasan de un plan tentativo a un objetivo más concreto. La figura 8-6 representa un plan de lanzamiento típico.

154

PARTE 3 Planificación y ejecución ágiles

FIGURA 8-6: Liberación de muestra

plan.

Tenga en cuenta la regla de lápiz y lápiz: puede comprometerse con (escribir con lápiz) el plan para el primer lanzamiento, pero cualquier cosa más allá del primer lanzamiento es provisional (escrito con lápiz). En otras palabras, utilice la planificación justo a tiempo (consulte el Capítulo 7) para cada versión. Después de todo, las cosas cambian, así que ¿por qué molestarse en volverse microscópico demasiado pronto?

Planificación de Sprint En proyectos ágiles, un pique es una repetición constante de tiempo en la que el equipo de desarrollo crea un grupo específico de capacidades de producto de principio a fin. Al final de cada sprint, la funcionalidad que ha creado el equipo de desarrollo debe estar funcionando, lista para demostrar y potencialmente enviarse al cliente. Los sprints deben tener la misma duración dentro de un proyecto. Mantener constantes las longitudes de los sprints ayuda al equipo de desarrollo a medir su rendimiento y planificar mejor en cada nuevo sprint. Los sprints generalmente duran de una a cuatro semanas. Cuatro semanas es la mayor cantidad de tiempo que debe durar un sprint; las iteraciones más largas hacen que los cambios sean más riesgosos, frustrando el propósito de ser ágiles. Rara vez vemos sprints que duran más de dos semanas, y más a menudo vemos sprints que duran una semana. Los sprints de una semana son un ciclo natural con la semana laboral de lunes a viernes que impide estructuralmente el trabajo de fin de semana. Algunos equipos de scrum trabajan en sprints de un día donde las prioridades cambian a diario. Las necesidades del mercado y de los clientes cambian cada vez más rápidamente, y la cantidad de tiempo que puede permitirse entre las oportunidades para recopilar comentarios de los clientes solo se acorta. Nuestra regla general es que su sprint no debe ser más largo de lo que sus partes interesadas pueden pasar constantemente sin cambios en la prioridad con respecto a lo que el equipo de scrum debería estar trabajando en el sprint.

CAPÍTULO 8 Planificación de lanzamientos y sprints

155

Cada sprint incluye lo siguiente:

» Planificación del sprint al comienzo del sprint » Scrummeetings diarios » Tiempo de desarrollo: la mayor parte del sprint » Una revisión del sprint y una retrospectiva del sprint al final del sprint Descubra más sobre scrums diarios, desarrollo de sprints, revisión de sprints y retrospectiva de sprints en los capítulos 9 y 10. En este capítulo, encontrará información sobre cómo planificar sprints.

La planificación de Sprint es la etapa 4 de la Hoja de ruta hacia el valor, como puede ver en la Figura 8-7. Todo el equipo de scrum (el propietario del producto, el scrummaster y el equipo de desarrollo) trabaja en conjunto para planificar los sprints.

FIGURA 8-7: Planificación de Sprint como

parte de Hoja de ruta hacia

Valor.

La acumulación de sprint La atrasos de sprint es una lista de historias de usuario asociadas con el sprint actual y las tareas relacionadas. Al planificar su sprint, haga lo siguiente:

» Establece metas para tu sprint. » Elija las historias de usuario que respalden esos objetivos. » Divida las historias de los usuarios en tareas de desarrollo específicas.

» Crear un atrasos de Sprint. El backlog del Sprint consta de lo siguiente:

• • • •

La lista de historias de usuarios dentro del sprint en orden de prioridad. La estimación del esfuerzo relativo para cada historia de usuario.

Las tareas necesarias para desarrollar cada historia de usuario.

El esfuerzo, en horas, para completar cada tarea. A nivel de tarea, calcula la cantidad de horas que le llevará completar cada tarea, en lugar de utilizar puntos de historia. Porque tu sprint tiene una especificidad

156

PARTE 3 Planificación y ejecución ágiles

duración y, por lo tanto, un número determinado de horas de trabajo disponibles, puede utilizar el tiempo que tarda cada tarea para determinar si las tareas encajarán en su sprint.

Cada tarea debe tomar un día o menos para que el equipo de desarrollo la complete. Es posible que algunos equipos de desarrollo maduros no necesiten estimar sus tareas a medida que se vuelven más consistentes al dividir sus historias de usuario en tareas ejecutables. La estimación de tareas es útil para los equipos de desarrollo más nuevos para asegurarse de que comprenden su capacidad y planifican cada sprint de manera adecuada.

•

A cuadro de incendio, que muestra el estado del trabajo que ha completado el equipo de desarrollo.

Las tareas en proyectos ágiles deberían tardar un día o menos en completarse por dos razones. La primera razón tiene que ver con la psicología básica: las personas están motivadas para llegar a la meta. Si tiene una tarea que sabe que puede completar rápidamente, es más probable que la termine a tiempo, solo para marcarla en su lista de tareas pendientes. La segunda razón es que las tareas de un día proporcionan buenas señales de alerta de que un proyecto podría estar desviándose de su curso. Si un miembro del equipo de desarrollo informa que está trabajando en la misma tarea durante más de uno o dos días, es probable que ese miembro del equipo tenga un obstáculo. El scrummaster debería aprovechar la oportunidad para investigar qué podría estar impidiendo que el miembro del equipo termine el trabajo. (Para obtener más información sobre la gestión de obstáculos, consulte el Capítulo 9.)

El equipo de desarrollo colabora para crear y mantener el backlog del sprint, y solo el equipo de desarrollo puede modificar el backlog del sprint. La acumulación de sprints debe reflejar una instantánea actualizada del progreso del sprint. La Figura 8-8 muestra una muestra de la acumulación de sprints al final de la reunión de planificación del sprint. Puede utilizar este ejemplo, buscar otras muestras o incluso utilizar una pizarra.

La reunión de planificación del sprint El primer día de cada sprint, a menudo un lunes por la mañana, el equipo de scrum celebra la reunión de planificación del sprint. Para una reunión de planificación de sprint exitosa, asegúrese de que todos los involucrados en la sesión (el propietario del producto, el equipo de desarrollo, el scrum master y cualquier otra persona que solicite el equipo de scrum) estén dedicados al esfuerzo durante toda la reunión.

Base la duración de su reunión de planificación de sprints en la duración de sus sprints: Reúnase durante no más de dos horas por cada semana de sus sprints. Esta caja de tiempo es una de las reglas del scrum y ayuda a garantizar que la reunión se mantenga enfocada y encaminada. La Figura 8-9 ilustra esto y es una buena referencia rápida para la duración de sus reuniones de planificación de sprints. CAPÍTULO 8 Planificación de lanzamientos y sprints

157

FIGURA 8-8: Cartera de Sprint

ejemplo.

FIGURA 8-9: Proporción de sprint reunión de planificación a la longitud del sprint.

En proyectos ágiles, la práctica de limitar el tiempo de sus reuniones a veces se denomina Timeboxing. Mantener el horario de sus reuniones asegura que el equipo de desarrollo tenga el tiempo que necesita para crear el producto. Dividirá sus reuniones de planificación de sprint en dos partes: una para establecer un objetivo de sprint (el "por qué") y elegir historias de usuario para el sprint (el "qué"), y otra para dividir sus historias de usuario en tareas individuales ( el "cómo" y "cuánto"). Los detalles de cada parte se discuten a continuación.

158

PARTE 3 Planificación y ejecución ágiles

Parte 1: Establecer objetivos y elegir historias de usuarios En la primera parte de su reunión de planificación de sprint, el propietario del producto y el equipo de desarrollo, con el apoyo del scrum master, hacen lo siguiente:

1. Discuta y establezca una meta de sprint.

2. Revise las historias de usuario de la acumulación de productos que respaldan el objetivo del sprint. y revise sus estimaciones relativas.

3. Si es necesario, cree historias de usuario para llenar los vacíos y lograr el objetivo del sprint.

4. Determine a qué puede comprometerse el equipo en el sprint actual. Al comienzo de la reunión de planificación del sprint, el propietario del producto debe proponer un objetivo del sprint y luego, junto con el equipo de desarrollo, debatir y acordar el objetivo del sprint. El objetivo del sprint debe ser una descripción general de la funcionalidad del cliente en funcionamiento que el equipo demostrará y posiblemente lanzará al final del sprint. El objetivo está respaldado por las historias de usuarios de mayor prioridad en la cartera de pedidos del producto. Un ejemplo de objetivo de sprint para la aplicación de banca móvil (consulte el Capítulo 7) podría ser el siguiente:

Demostrar la capacidad de un cliente de banca móvil para iniciar sesión y ver los saldos de las cuentas y las transacciones pendientes y anteriores.

Con el objetivo del sprint, determina las historias de usuario que pertenecen al sprint. También echa un vistazo a las estimaciones de esas historias y realiza cambios en las estimaciones si es necesario. Para la muestra de la aplicación de banca móvil, el grupo de historias de usuario para el sprint podría incluir lo siguiente:

» Inicie sesión y acceda a mis cuentas.

» Ver saldos de cuentas. » Ver transacciones pendientes. » Ver transacciones anteriores. Todas estas serían historias de usuarios de alta prioridad en la cartera de productos que respaldan el objetivo del sprint.

La segunda parte de la revisión de historias de usuarios es confirmar que las estimaciones de esfuerzo para cada historia de usuario se han revisado y ajustado si es necesario, y reflejan el conocimiento actual del equipo de desarrollo sobre la historia de usuario. Ajuste la estimación si es necesario. Con el propietario del producto en la reunión, resuelva cualquier pregunta pendiente. Al comienzo del sprint, el equipo de scrum tiene el conocimiento más actualizado sobre el sistema y las necesidades del cliente hasta este punto en el

CAPÍTULO 8 Planificación de lanzamientos y sprints

159

proyecto, así que asegúrese de que el equipo de desarrollo y el propietario del producto tengan una oportunidad más para aclarar y dimensionar las historias de usuario que entran en el sprint.

Finalmente, después de saber qué historias de usuario apoyan el objetivo del sprint, el equipo de desarrollo debe estar de acuerdo y confirmar que puede completar el objetivo planificado para el sprint. Si alguna de las historias de usuario que mencionó anteriormente no encaja en el sprint actual, elimínelas del sprint y agréguelas de nuevo a la lista de trabajos pendientes del producto. Siempre planifique y trabaje un sprint a la vez. Una trampa fácil en la que caer es colocar las historias de los usuarios en sprints futuros específicos. Por ejemplo, cuando todavía estás planeando un sprint

1, no decida que la historia de usuario X debería pasar al sprint 2 o 3. En su lugar, mantenga actualizada la lista ordenada de historias de usuario en la cartera de productos y concéntrese en desarrollar siempre las siguientes historias de mayor prioridad. Comprométete a planificar solo para el sprint actual. Después de tener un objetivo de sprint, historias de usuario para el sprint y un compromiso con el objetivo, pase a la segunda parte de la planificación del sprint.

Debido a que una reunión de planificación de sprints de más de una semana puede durar algunas horas, es posible que desee tomar un descanso entre las dos partes de la reunión.

Parte 2: desglosar las historias de los usuarios en tareas para la acumulación del sprint En la segunda parte de la reunión de planificación del sprint, el equipo de scrum hace lo siguiente:

El equipo de desarrollo crea las tareas pendientes de sprint asociadas con cada historia de usuario. Asegúrese de que las tareas abarquen cada parte de la definición de hecho: desarrollado, integrado, probado y documentado.

El equipo de desarrollo verifica dos veces que pueda completar las tareas en el tiempo disponible en el sprint.

Cada miembro del equipo de desarrollo debe elegir su primera tarea antes de salir de la reunión.

Los miembros del equipo de desarrollo deben trabajar en una sola tarea en una historia de usuario a la vez para habilitar pululando - la práctica de todo el equipo de desarrollo trabajando en una historia de usuario hasta su finalización. El enjambre puede ser una forma eficaz de completar el trabajo en poco tiempo. De esta manera, los equipos de scrum evitan llegar al final del sprint con todas las historias de usuario iniciadas pero pocas terminadas.

Al comienzo de la segunda parte de la reunión, divida las historias de los usuarios en tareas individuales y asigne una cantidad de horas a cada tarea. El objetivo del equipo de desarrollo

160

PARTE 3 Planificación y ejecución ágiles

debería estar completando una tarea en un día o menos. Por ejemplo, una historia de usuario para la aplicación móvil XYZ Bank podría ser la siguiente: Inicie sesión y acceda a mis cuentas.

El equipo descompone esta historia de usuario en tareas, como las siguientes:

» Escribe la prueba unitaria.

» Cree una pantalla de autenticación para un nombre de usuario y contraseña, con un Enviar botón.

» Cree una pantalla de error para que el usuario vuelva a ingresar las credenciales. » Cree una pantalla (una vez que haya iniciado sesión) que muestre una lista de cuentas.

» Usando el código de autenticación de la aplicación de banca en línea, vuelva a escribir el código para una aplicación de iPhone / iPad.

» Cree llamadas a la base de datos para verificar el nombre de usuario y la contraseña. » Refactorizar código para dispositivos móviles.

» Escribe la prueba de integración.

» Actualiza la documentación de la wiki. Una vez que sepa la cantidad de horas que tomará cada tarea, haga una verificación final para asegurarse de que la cantidad de horas disponibles para el equipo de desarrollo coincida razonablemente con el total de las estimaciones de las tareas. Si las tareas superan las horas disponibles, una o más historias de usuario deberán salir del sprint. Discuta con el propietario del producto qué tareas o historias de usuario son las mejores para eliminar. Si hay tiempo adicional disponible dentro del sprint, el equipo de desarrollo podría incluir otra historia de usuario. Solo tenga cuidado con comprometerse en exceso al comienzo de un sprint, especialmente en los primeros sprints del proyecto. Una vez que sepa qué tareas serán parte del sprint, elija en qué trabajará primero. Cada miembro del equipo de desarrollo debe seleccionar su tarea inicial a realizar para el sprint. Los miembros del equipo deben concentrarse en una tarea a la vez. Mientras los miembros del equipo de desarrollo piensan en lo que pueden completar en un sprint, use las siguientes pautas para asegurarse de que no asuman más trabajo del que pueden manejar mientras aprenden nuevos roles y técnicas:

» Sprint 1: 25 por ciento de lo que el equipo de desarrollo cree que puede lograr. Incluya gastos generales para aprender el nuevo proceso y comenzar un nuevo proyecto.

CAPÍTULO 8 Planificación de lanzamientos y sprints

161

» Sprint 2: 50 por ciento de lo que el equipo de desarrollo cree que puede lograr. » Sprint 3: 75 por ciento de lo que el equipo de desarrollo cree que puede lograr. » Sprint 4 en adelante: 100 por ciento. El equipo de desarrollo habrá desarrollado Abrió un ritmo y velocidad, adquirió una visión de los principios ágiles y la proyecto, y estará trabajando casi al máximo. El equipo de scrum debe evaluar constantemente la acumulación de sprints contra el progreso del equipo de desarrollo en las tareas. Al final del sprint, el equipo de scrum también puede evaluar las habilidades de estimación y la capacidad de trabajo durante la retrospectiva del sprint (ver Capítulo 10). Esta evaluación es especialmente importante para el primer sprint. Para el sprint, ¿cuántas horas de trabajo totales están disponibles? En una semana de 40 horas, podría asumir sabiamente, para un sprint de dos semanas, que hay nueve días hábiles disponibles para desarrollar historias de usuarios. Si asume que cada miembro del equipo de tiempo completo tiene 35 horas por semana (7 horas productivas por día) para concentrarse en el proyecto, la cantidad de horas de trabajo disponibles es Número de miembros del equipo × 7 horas × 9 días

¿Por qué nueve días? La mitad del día uno se dedica a la planificación, y la mitad del día diez se dedica a la revisión del sprint (cuando las partes interesadas revisan el trabajo completado) y la retrospectiva del sprint (cuando el equipo scrum identifica mejoras para futuros sprints). Eso deja nueve días de desarrollo. Una vez finalizada la planificación del sprint, el equipo de desarrollo puede comenzar a trabajar de inmediato en las tareas para crear el producto.

El scrum master debe asegurarse de que la hoja de ruta del producto, la acumulación de productos y la acumulación de sprints estén en un lugar destacado y accesible para todos. Esto permite a los gerentes y otras partes interesadas ver los artefactos y obtener el estado del progreso sin interrumpir al equipo de desarrollo.

162

PARTE 3 Planificación y ejecución ágiles

EN ESTE CAPÍTULO » Planificando cada día » Seguimiento del progreso diario

» Desarrollando y probando todos los días » Terminando el dia

Capítulo

Trabajando en todo El dia

El equipo de ment comenzó a trabajar. Durante el resto del sprint, estarás trabajando cíclicamente,

donde cada díaAyer, siguecompletó el mismolapatrón. martes, 9 am planificación del sprint y el desarrollo

En este capítulo, aprenderá a utilizar los principios ágiles a diario durante cada sprint. Verá el trabajo que hará todos los días como parte de un equipo scrum: planificar y coordinar su día, hacer un seguimiento del progreso, crear y verificar la funcionalidad utilizable e identificar y tratar los impedimentos para su trabajo. Verá cómo los diferentes miembros del equipo de scrum trabajan juntos todos los días durante el sprint para ayudar a crear el producto.

Planificación de su día: Scrum diario En proyectos ágiles, haces planes a lo largo de todo el proyecto y a diario. Los equipos de desarrollo ágiles comienzan cada día de trabajo con un scrum diario reunión para tomar nota de los elementos completados, para identificar impedimentos u obstáculos que requieran la participación de scrum master, y para sincronizar y planificar lo que hará cada miembro del equipo durante el día para lograr la meta del sprint.

CAPÍTULO 9 Trabajando durante todo el día

163

El scrum diario es la Etapa 5 de la Hoja de ruta hacia el valor. Puede ver cómo el sprint y el scrum diario encajan en un proyecto ágil en la Figura 9-1. Note cómo ambos se repiten.

FIGURA 9-1: El sprint y el scrum diario en la hoja de ruta valorar.

En el scrummeeting diario, cada miembro del equipo de desarrollo hace las siguientes tres declaraciones, que permiten la coordinación del equipo:

» Ayer completé ( indicar elementos completados). » Hoy, voy a asumir ( tarea estatal). » Mis impedimentos son ( impedimentos estatales, si los hay). Otros nombres que puede escuchar para el scrummeeting diario son los grupo diario o el

standup diario reunión. Scrum diario, reunión diaria y standup diario se refieren a lo mismo.

También hacemos que el scrum master aborde estas tres declaraciones con respecto a los impedimentos del equipo:

» Ayer, resolví ( impedimentos estatales completados). » Hoy, voy a trabajar para eliminar ( impedimento estatal). » Los impedimentos que voy a escalar son ( impedimentos estatales que necesita asistencia con, si corresponde).

Una de las reglas del scrum es que el scrummeeting diario dura 15 minutos o menos; las reuniones más largas comen en el día del equipo de desarrollo. La reunión también se conoce como la reunión diaria porque estar de pie fomenta las reuniones más breves. También puede utilizar accesorios para agilizar las reuniones diarias de scrum.

164

PARTE 3 Planificación y ejecución ágiles

Comenzamos las reuniones lanzando un juguete de perro chirriante con forma de hamburguesa, no se preocupe; está limpio, para un miembro del equipo de desarrollo aleatorio. Cada persona hace sus tres declaraciones y luego pasa el juguete chirriante a otra persona. Si las personas son prolijas, cambiamos el accesorio a una resma de papel de copia de 500 páginas, que pesa alrededor de cinco libras. Cada persona puede hablar mientras pueda sostener la resma a un lado. O bien las reuniones se acortarán rápidamente o los miembros del equipo de desarrollo desarrollarán rápidamente la fuerza de sus brazos; en nuestra experiencia, es lo primero.

Para que los scrums diarios sean breves y efectivos, el equipo de scrum puede seguir varias pautas:

» Cualquiera puede asistir a un scrum diario, pero solo el equipo de desarrollo, el scrummaster, y el propietario del producto puede hablar. El scrum diario es el

La oportunidad del equipo scrum para coordinar las actividades diarias, no asumir requisitos adicionales o cambios de las partes interesadas. Las partes interesadas pueden discutir preguntas con el scrummaster o el propietario del producto después, pero las partes interesadas no deben acercarse al equipo de desarrollo.

» La atención se centra en las prioridades inmediatas. El equipo de scrum debe revisar solo tareas completadas, tareas por hacer y obstáculos.

» Los scrummeetings diarios son para la coordinación, no para la resolución de problemas. La El equipo de desarrollo y el scrummaster son responsables de eliminar los obstáculos durante el día.

» Para evitar que las reuniones se conviertan en sesiones de resolución de problemas, scrum los equipos pueden

•

Cree una lista en una pizarra para realizar un seguimiento de los problemas que necesitan atención inmediata y luego aborde esos problemas directamente después de la reunión con

solo aquellos miembros del equipo que necesitan participar.

•

Celebre una reunión, llamada después de la fiesta, para resolver problemas una vez finalizado el scrum diario. Algunos equipos de scrum programan tiempo para una fiesta posterior diario; otros se reúnen solo cuando es necesario.

» El scrum diario es para la coordinación entre pares. No se utiliza para individuo para informar el estado a una persona, como el scrummaster o el propietario del producto. El estado se informa al final de cada día en la lista de trabajos pendientes del sprint.

» Una reunión tan corta debe comenzar a tiempo. No es inusual que el scrum

equipo para tener castigos creativos por tardanza (como hacer flexiones o agregar dinero de penalización a un fondo de celebración del equipo u otro inconveniente). Cualquiera que sea el método que se utilice, el equipo de scrum se pondrá de acuerdo; El método no se les dicta a alguien fuera del equipo, como un gerente.

» El equipo de scrum puede solicitar que los asistentes de scrum diarios se pongan de pie:

en lugar de sentarse, durante la reunión. Levantarse hace que la gente ansioso por terminar la reunión y seguir con el trabajo del día.

CAPÍTULO 9 Trabajando durante todo el día

165

Cuando solo tiene 15 minutos para hablar, cada minuto cuenta. Los equipos de scrum no deben tener miedo de hacer que llegar tarde al scrum diario sea lo suficientemente desagradable. Si a los miembros del equipo les encanta cantar, por ejemplo, interpretar una canción de karaoke probablemente no tendrá mucho efecto. Hemos ayudado a curar los problemas de tardanza perpetua de la noche a la mañana al sugerir que el equipo de scrum cambie su castigo de una contribución de $ 1 a una contribución de $ 20 al fondo de celebración del equipo.

Las reuniones de scrum diarias son efectivas para mantener al equipo de desarrollo enfocado en las tareas correctas para un día determinado. Debido a que los miembros del equipo de desarrollo son responsables de su trabajo frente a sus compañeros, es menos probable que se desvíen de sus compromisos diarios. Las reuniones diarias de scrum también ayudan a garantizar que el scrum master y el equipo de desarrollo puedan lidiar con los obstáculos de inmediato. Estas reuniones son tan útiles que incluso las organizaciones que no utilizan ninguna otra técnica ágil a veces adoptan scrums diarios. Nos gusta realizar scrummeetings diarios una hora después de la hora de inicio normal del equipo de desarrollo para permitir atascos de tráfico, correos electrónicos, café y otros rituales al comenzar el día. Tener una reunión de scrum posterior también le da tiempo al equipo de desarrollo para revisar los informes de defectos de las herramientas de prueba automatizadas que se ejecutaron la noche anterior.

El scrum diario es para discutir el progreso y planificar cada día siguiente. Como verá a continuación, también realiza un seguimiento del progreso, no solo lo comenta, todos los días.

Seguimiento del progreso También necesitas realizar un seguimiento del progreso de tu sprint a diario. Esta sección analiza las formas de realizar un seguimiento de las tareas en su sprint. Dos herramientas para realizar un seguimiento del progreso son la acumulación de sprints y un tablero de tareas. Tanto el backlog del sprint como el tablero de tareas permiten que el equipo de scrum muestre el progreso del sprint a cualquier persona en un momento dado.

El Manifiesto Ágil valora a las personas y las interacciones sobre los procesos y las herramientas. Asegúrese de que sus herramientas apoyen, en lugar de obstaculizar, a su equipo de scrum. Modifique o incluso reemplace las herramientas si es necesario. Lea más sobre el Manifiesto Ágil en el Capítulo 2.

La acumulación de sprint Durante la planificación del sprint, te concentras en agregar historias de usuarios y tareas a la acumulación de primavera. Durante el sprint en sí, actualiza el backlog del sprint diariamente, haciendo un seguimiento del progreso de las tareas del equipo de desarrollo para cada día de trabajo. Figura 9-2

166

PARTE 3 Planificación y ejecución ágiles

muestra la acumulación de sprints para la aplicación de muestra de este libro, la aplicación de banca móvil del XYZ Bank, como aparecería después del día 4 del primer sprint. (El Capítulo 8 trata los detalles de la acumulación de sprints).

FIGURA 9-2: Sprint de muestra

reserva.

Haga que la acumulación de sprints esté disponible para todo el equipo del proyecto todos los días. De esa manera, cualquier persona que necesite conocer el estado del sprint puede encontrarlo al instante.

Cerca de la parte superior izquierda de la Figura 9-2, observe la gráfico de quemado de sprint, que muestra el progreso que está haciendo el equipo de desarrollo. Puede ver que los miembros del equipo de desarrollo han completado tareas cercanas a la tasa de consumo uniforme de sus horas disponibles, y el propietario del producto ha aceptado varias historias de usuarios como completas.

Puede incluir gráficos de evolución en la cartera de pedidos de Sprint y en la cartera de productos. (Este capítulo se concentra en la acumulación de sprints). La Figura 9-3 muestra el gráfico de evolución en detalle. Un gráfico de evolución es una herramienta poderosa para visualizar el progreso y el trabajo restante. El gráfico muestra lo siguiente:

» El trabajo destacado (en horas) en el primer eje vertical » Tiempo, en días a lo largo del eje horizontal CAPÍTULO 9 Trabajando durante todo el día

167

FIGURA 9-3: Una quema gráfico.

Algunos gráficos de velocidad de avance, como el de la Figura 9-3, también muestran los puntos destacados de la historia en un segundo eje vertical que se traza contra el mismo eje de tiempo horizontal que las horas de trabajo restantes.

Un gráfico de evolución permite a cualquiera, de un vistazo, ver el estado del sprint. El progreso es claro. Al comparar el número realista de horas disponibles con el trabajo restante, puede averiguar a diario si el esfuerzo va según lo planeado, si está en mejor forma de lo esperado o si tiene problemas. Esta información lo ayuda a determinar si es probable que el equipo de desarrollo logre el número objetivo de historias de usuario y lo ayuda a tomar decisiones informadas al principio del sprint. Puede crear una acumulación de sprints utilizando una hoja de cálculo y un programa de gráficos como Microsoft Excel. También puede descargar nuestra plantilla de backlog de Sprint, que incluye un gráfico de evolución, desde el sitio web del libro en www.dummies.com/go/

agileprojectmanagementfd2e. La figura 9-4 muestra ejemplos de gráficos de evolución para sprints en diferentes situaciones. Al mirar estos gráficos, puede ver cómo avanza el trabajo:

» 1. Esperado: Este gráfico muestra un patrón de sprint normal. El trabajo restante las horas suben y bajan a medida que el equipo de desarrollo completa las tareas, busca

detalles e identifica el trabajo táctico que puede no haber considerado inicialmente. Aunque el trabajo aumenta ocasionalmente, es manejable y el equipo se moviliza para completar todas las historias de usuario al final del sprint.

» 2. Más complicado: En este sprint, el trabajo aumentó más allá del punto en que el equipo de desarrollo sintió que podía lograr todo. El equipo

identificó este problema temprano, trabajó con el propietario del producto para eliminar algunas historias de usuario y aún así logró el objetivo del sprint. La clave para los cambios de alcance dentro de un sprint es que siempre los inicia el equipo de desarrollo, nadie más.

168

PARTE 3 Planificación y ejecución ágiles

FIGURA 9-4: Perfiles de gráficos de quemado.

» 3. Menos complicado: En este sprint, el equipo de desarrollo completó algunos historias de usuario críticas más rápido de lo previsto y trabajaron con el producto propietario para identificar historias de usuarios adicionales que podría agregar al sprint.

» 4. No participar: Una lnea recta en un quemado significa que el equipo no actualizó el quemado o no hizo ningún progreso ese día. Cualquiera de los dos casos es un bandera roja para problemas futuros.

Al igual que en un gráfico de latidos, una línea recta horizontal en un gráfico de aceleración nunca es algo bueno.

» 5. Mentir (o conformarse): Este patrón de quema es común para un nuevo ágil equipo de desarrollo que puede estar acostumbrado a informar las horas que

la gerencia espera, en lugar del tiempo que realmente toma el trabajo y, en consecuencia, tiende a ajustar las estimaciones de trabajo del equipo al número exacto de horas restantes. Este patrón a menudo refleja un entorno basado en el miedo, donde los gerentes lideran mediante la intimidación.

» 6. Fallar rápido: Uno de los mayores beneficios de esta simple visualización de

el progreso es la prueba inmediata del progreso o la falta del mismo. Este patrón muestra un ejemplo de un equipo que no participaba ni progresaba. A la mitad del sprint, el propietario del producto decidió reducir las pérdidas eliminando el sprint y comenzando un nuevo sprint con un nuevo objetivo de sprint. Solo los propietarios de productos pueden finalizar un sprint antes de tiempo.

La acumulación de sprints te ayuda a realizar un seguimiento del progreso a lo largo de cada sprint. También puede consultar los trabajos pendientes de sprints anteriores para comparar el progreso de un sprint a otro. Realiza cambios en su proceso en cada sprint (lea más sobre el concepto de inspeccionar y adaptar en el Capítulo 10). Inspeccione constantemente su trabajo y adáptese para mejorarlo. Aférrate a esos viejos atrasos de sprints.

CAPÍTULO 9 Trabajando durante todo el día

169

Otra forma de realizar un seguimiento de su sprint es mediante el uso de un tablero de tareas. Siga leyendo para descubrir cómo crear y utilizar uno.

El tablero de tareas Aunque la acumulación de sprints es una excelente manera de rastrear y mostrar el progreso del proyecto, probablemente esté en formato electrónico, por lo que es posible que no sea accesible de inmediato para cualquiera que quiera verlo. Algunos equipos de desarrollo de scrum usan un tablero de tareas junto con su backlog de sprint. A tablero de tareas proporciona una vista rápida y sencilla de los elementos del sprint en el que el equipo de desarrollo está trabajando y ha completado. Nos gustan los tableros de tareas porque no se puede negar el estado que muestran. Al igual que la hoja de ruta del producto, el tablero de tareas puede estar formado por notas adhesivas en una pizarra. El tablero de tareas tendrá al menos las siguientes cuatro columnas, de izquierda a derecha:

» Que hacer: Las historias de usuario y las tareas que quedan por realizar se encuentran en el columna de la izquierda.

» En curso: Historias de usuario y tareas en las que el equipo de desarrollo está actualmente en las que está trabajando están en la columna En curso. Solo debe haber una historia de usuario en esta columna. Tener más historias de usuarios en progreso es una alerta de que los miembros del equipo de desarrollo no están trabajando de manera transversal y, en cambio, están acumulando tareas deseadas. Se arriesga a que varias historias de usuarios se completen parcialmente en lugar de que se completen más historias de usuarios al final del sprint.

» Aceptar: Una vez que el equipo de desarrollo completa una historia de usuario, la mueve a la Aceptar columna. Las historias de usuario en la columna Aceptar están listas para el producto

propietario para revisar y proporcionar comentarios o aceptar.

» Hecho: Cuando el propietario del producto ha revisado una historia de usuario y verifica que la historia de usuario está completa, el propietario del producto puede mover esa historia de usuario a la

Columna hecho.

¡Limita tu trabajo en progreso! Seleccione solo una tarea a la vez. Deje otras tareas disponibles en la columna Tareas pendientes. Idealmente, un equipo de desarrollo trabajará solo en una historia de usuario a la vez y se concentrará en las tareas de esa historia de usuario para completarla rápidamente. Debido a que el tablero de tareas es táctil (las personas mueven físicamente una tarjeta de historia de usuario hasta que se completa), puede involucrar al equipo de desarrollo más que un documento electrónico. El tablero de tareas fomenta el pensamiento y la acción simplemente existiendo en el área de trabajo del equipo de scrum, donde todos pueden ver el tablero. Permitir que solo el propietario del producto mueva las historias de usuario a la columna Listo evita malentendidos sobre el estado de las historias de usuario.

170

PARTE 3 Planificación y ejecución ágiles

La figura 9-5 muestra un tablero de tareas típico. Como puede ver, el tablero de tareas es una fuerte representación visual del trabajo en progreso.

FIGURA 9-5: Tarea de muestra

Junta.

El tablero de tareas se parece mucho a un tablero kanban. Kanban es un término japonés que significa

señal visual. ( Para obtener más información sobre los tableros kanban, consulte el Capítulo 4.) Toyota creó estos tableros como parte de su proceso de fabricación ajustada. En la Figura 9-5, el tablero de tareas muestra cuatro historias de usuario, cada una separada por una línea horizontal llamada carriles de natación. La primera historia de usuario está lista. Se completan todas las tareas y el propietario del producto ha aceptado el trabajo realizado. Para la segunda historia de usuario, el trabajo de desarrollo está completo pero está esperando la aceptación por parte del propietario del producto. La tercera historia de usuario está en curso y la cuarta historia de usuario aún no se ha iniciado. De un vistazo, el estado de cada historia de usuario es claro no solo para el equipo de scrum, lo que hace que la coordinación táctica sea más rápida y sencilla, sino también para las partes interesadas.

El trabajo diario en un proyecto ágil implica más que simplemente planificar y rastrear el progreso. En la siguiente sección, verá lo que incluirá la mayor parte del trabajo de su día, ya sea que sea miembro del equipo de desarrollo, propietario de un producto o un scrum master.

CAPÍTULO 9 Trabajando durante todo el día

171

Algunos equipos de desarrollo informan el estado solo con un tablero de tareas y le piden al Scrum Master que convierta el estado en el backlog del Sprint. Este proceso ayuda al scrum master a ver tendencias y problemas potenciales.

Roles ágiles en el Sprint Cada miembro de un equipo de scrum tiene roles y responsabilidades diarios específicos durante el sprint. El enfoque del día para el equipo de desarrollo es producir funcionalidad que se pueda enviar. Para el propietario del producto, la atención se centra en preparar la cartera de pedidos del producto para futuros sprints y, al mismo tiempo, respaldar la ejecución del equipo de desarrollo de la cartera de trabajos pendientes con aclaraciones en tiempo real. El scrum master es el entrenador ágil y maximiza la productividad del equipo de desarrollo al eliminar los obstáculos y proteger al equipo de desarrollo de las distracciones externas.

A continuación se describen las tareas que realiza cada miembro del equipo scrum durante el sprint. Si es miembro del equipo de desarrollo,

» Seleccione las tareas de mayor necesidad y complételas lo más rápido posible. » Solicite una aclaración al propietario del producto cuando no tenga claro un historia del usuario.

» Colaborar con otros miembros del equipo de desarrollo para diseñar el enfoque. a una historia de usuario específica, busque ayuda cuando la necesite y brinde ayuda cuando

otro miembro del equipo de desarrollo lo necesita.

» Realizar revisiones de pares sobre el trabajo de los demás.

» Asuma tareas más allá de su función normal según lo requiera el sprint. » Desarrollar completamente la funcionalidad según lo acordado en la definición de hecho (descrito en la siguiente sección, "Creación de funcionalidad de envío").

» Informe diariamente sobre su progreso al completar tareas en la lista de trabajos pendientes del Sprint.

» Avise al scrummaster sobre cualquier obstáculo que no pueda eliminar de manera efectiva tu propio.

» Logre el objetivo del sprint al que se comprometió durante la planificación del sprint. El propietario del producto tiene las siguientes tareas durante el sprint:

» Realice las inversiones necesarias para mantener alta la velocidad de desarrollo.

» Priorice la funcionalidad del producto.

172

PARTE 3 Planificación y ejecución ágiles

» Representar a las partes interesadas del producto en el equipo de desarrollo. » Informar sobre el costo y el estado del cronograma a las partes interesadas del proyecto.

» Elaborar historias de usuarios con el equipo de desarrollo para que el equipo claramente comprende lo que está creando.

» Proporcionar aclaraciones y decisiones inmediatas sobre los requisitos para mantener el desarrollo del equipo de desarrollo.

» Elimine los impedimentos comerciales que le hayan presentado otros miembros del equipo de scrum.

» Revise la funcionalidad completa de las historias de usuario y proporcione comentarios al Equipo de desarrollo.

» Agregue nuevas historias de usuario a la cartera de pedidos del producto según sea necesario y asegúrese de que Las nuevas historias de usuario respaldan la visión del producto, el objetivo de lanzamiento y la meta de sprint.

» Espere el próximo sprint y elabore historias de usuarios en preparación para el próxima reunión de planificación de sprint.

La comunicación no verbal dice mucho. Los scrum masters pueden beneficiarse de la comprensión del lenguaje corporal para identificar tensiones tácitas en el equipo de scrum. Si eres un scrum master, haz lo siguiente durante el sprint:

» Defienda los valores y las prácticas ágiles entrenando al propietario del producto, el equipo de desarrollo y la organización cuando sea necesario.

» Proteja al equipo de desarrollo de las distracciones externas. » Elimine los obstáculos, tanto tácticamente para problemas inmediatos como estratégicamente para posibles problemas a largo plazo. En el Capítulo 6, comparamos el scrummaster con

un ingeniero aeronáutico, eliminando y previniendo continuamente las dificultades organizativas en el equipo de desarrollo.

» Facilitar la construcción de consenso en el equipo de scrum. » Construir relaciones para fomentar una estrecha cooperación con las personas que trabajan con el equipo de scrum.

A menudo les decimos a los scrum masters: "Nunca almuerces solos. Siempre construye relaciones". Nunca se sabe cuándo necesitará pedir un favor en un proyecto. Como puede ver, cada miembro del equipo scrum tiene un trabajo específico en el sprint. En la siguiente sección, verá cómo el propietario del producto y el equipo de desarrollo trabajan juntos para crear el producto.

CAPÍTULO 9 Trabajando durante todo el día

173

Creación de funcionalidad de envío El objetivo del trabajo diario de un sprint es crear una funcionalidad de envío para el producto en una forma que pueda entregarse a un cliente o usuario. Dentro del contexto de un solo sprint, un incremento de producto o funcionalidad de envío significa que un producto de trabajo ha sido desarrollado, integrado, probado y documentado de acuerdo con la definición del proyecto de hecho y se considera listo para su lanzamiento. El equipo de desarrollo puede o no lanzar ese producto al final del sprint; el tiempo de lanzamiento depende del plan de lanzamiento. El proyecto puede requerir múltiples sprints antes de que el producto contenga el conjunto de características mínimas comercializables necesarias para justificar un lanzamiento al mercado. Es útil pensar en la funcionalidad de envío en términos de historias de usuario. Una historia de usuario comienza como un requisito escrito en una tarjeta. A medida que el equipo de desarrollo crea funcionalidad, cada historia de usuario se convierte en una acción que el usuario puede realizar. La funcionalidad de envío equivale a historias de usuario completadas.

Para crear una funcionalidad de envío, el equipo de desarrollo y el propietario del producto participan en tres actividades principales:

» Elaborando » Desarrollando » Verificando Durante el sprint, cualquiera o todas estas actividades pueden estar sucediendo en cualquier momento. Al revisarlos en detalle, recuerde que no siempre ocurren de manera lineal.

Elaborando En un proyecto ágil, elaboración es el proceso de determinar los detalles de una característica del producto. Siempre que el equipo de desarrollo aborda una nueva historia de usuario, la elaboración garantiza que se responda cualquier pregunta sin respuesta sobre una historia de usuario para que el proceso de desarrollo pueda continuar.

El propietario del producto trabaja con el equipo de desarrollo para elaborar historias de usuario, pero el equipo de desarrollo debe tener la última palabra en las decisiones de diseño. El propietario del producto debe estar disponible para consultas si el equipo de desarrollo necesita más aclaraciones sobre los requisitos a lo largo del día.

174

PARTE 3 Planificación y ejecución ágiles

El diseño colaborativo es un factor importante para proyectos exitosos. Recuerde estos principios ágiles: "Las mejores arquitecturas, requisitos y diseños surgen de equipos autoorganizados" y "Los empresarios y los desarrolladores deben trabajar juntos todos los días a lo largo de un proyecto". Tenga cuidado con los miembros del equipo de desarrollo que tienden a tratar de trabajar solos en la elaboración de historias de usuarios. Si un miembro del equipo de desarrollo se separa del equipo, quizás parte del trabajo del scrummaster debería ser entrenar a esa persona para que defienda los valores y prácticas ágiles.

Desarrollando Durante el desarrollo del producto, la mayor parte de la actividad, naturalmente, recae en el equipo de desarrollo. El propietario del producto continúa trabajando con el equipo de desarrollo según sea necesario para proporcionar aclaraciones y aprobar la funcionalidad desarrollada.

El equipo de desarrollo debe tener acceso inmediato al propietario del producto. Idealmente, el propietario del producto se sienta con el equipo de desarrollo cuando no está interactuando con los clientes y las partes interesadas. El scrummaster debe centrarse en proteger al equipo de desarrollo de las interrupciones externas y eliminar los impedimentos que encuentra el equipo de desarrollo. Para mantener prácticas ágiles durante el desarrollo, asegúrese de implementar el tipo de prácticas de desarrollo de programación extrema que le mostramos en el Capítulo 4, incluyendo lo siguiente:

» Empareje a los miembros del equipo de desarrollo para completar las tareas. Haciéndolo mejora la calidad del trabajo y fomenta el intercambio de habilidades.

» Siga los estándares de diseño acordados por el equipo de desarrollo. Si usted

no puede seguirlos por cualquier motivo, revise estos estándares y mejórelos.

» Inicie el desarrollo configurando pruebas automatizadas. Puedes encontrar más acerca de las pruebas automatizadas en la siguiente sección y en el Capítulo 15.

» Si durante el desarrollo aparecen características nuevas y agradables, agregue a la cartera de productos. Evite codificar nuevas funciones que estén fuera del objetivo del sprint.

» Integre los cambios que se codificaron durante el día, uno por uno. Prueba para una exactitud del 100 por ciento. Integre los cambios al menos una vez al día; algunos equipos se integran muchas veces al día.

CAPÍTULO 9 Trabajando durante todo el día

175

» Llevar a cabo revisiones de código para asegurarse de que el código sigue el desarrollo. normas. Identifique las áreas que necesitan revisión. Agregue las revisiones como tareas en el backlog del sprint.

» Cree documentación técnica mientras trabaja. No espere hasta el final de el sprint o, peor aún, el final del sprint antes de un lanzamiento.

Integración continua es el término utilizado en el desarrollo de software para integrar y realizar pruebas exhaustivas con cada compilación de código. La integración continua ayuda a identificar problemas antes de que se conviertan en crisis.

Verificando La verificación del trabajo realizado en un sprint consta de tres partes: pruebas automatizadas, revisión por pares y revisión del propietario del producto.

Es exponencialmente más barato prevenir un defecto que arrancarlo de un sistema implementado.

Pruebas automatizadas Pruebas automatizadas significa usar un programa de computadora para hacer la mayoría de las pruebas de código por usted. Con las pruebas automatizadas, el equipo de desarrollo puede desarrollar y probar código rápidamente, lo cual es un gran beneficio para los proyectos ágiles. A menudo, los equipos de proyectos ágiles codifican durante el día y dejan que las pruebas se ejecuten durante la noche. Por la mañana, el equipo del proyecto puede revisar el informe de defectos que generó el programa de pruebas, informar sobre cualquier problema durante el scrum diario y corregir esos problemas inmediatamente durante el día.

Las pruebas automatizadas pueden incluir lo siguiente:

» Examen de la unidad: Prueba del código fuente en sus partes más pequeñas: el nivel de componente

» Prueba del sistema: Probando el código con el resto del sistema » Prueba estática: Verificar que el código del producto cumpla con los estándares basados

reglas y mejores prácticas que el equipo de desarrollo ha acordado

Revisión por pares Revisión por pares simplemente significa que los miembros del equipo de desarrollo revisan el código de los demás. Si Sam escribe programA y Joan escribe programB, Sam podría revisar el código de Joan y viceversa. La revisión objetiva por pares ayuda a garantizar la calidad del código.

176

PARTE 3 Planificación y ejecución ágiles

Programación en pareja es otra forma de revisión por pares, pero la revisión se lleva a cabo durante el desarrollo. Mientras un desarrollador (el piloto) se sienta en el teclado y escribe el código, otro desarrollador (el navegador) piensa estratégicamente, mira hacia el futuro y escucha activamente y responde a las decisiones tomadas tácticamente por el piloto. La revisión no solo ocurre en el momento, detectando defectos y tomando decisiones más informadas, sino que hay dos desarrolladores, en lugar de uno solo, que están íntimamente familiarizados con la parte del sistema que se está desarrollando. La programación de pares es una excelente manera de desarrollar individuos multifuncionales para reducir los puntos únicos de falla.

El equipo de desarrollo puede realizar revisiones por pares durante el desarrollo. La colocación ayuda a que esto sea más fácil: puede dirigirse a la persona que está a su lado y pedirle que eche un vistazo rápido a lo que acaba de completar. El equipo de desarrollo también puede reservar tiempo durante el día específicamente para revisar el código. Los equipos autogestionados deben decidir qué funciona mejor para ellos.

Revisión del propietario del producto Cuando se ha desarrollado y probado una historia de usuario, el equipo de desarrollo mueve las historias a la columna Aceptar en el tablero de tareas. Luego, el propietario del producto revisa la funcionalidad y verifica que cumpla con los objetivos de la historia del usuario, según los criterios de aceptación de la historia del usuario. El propietario del producto verifica las historias de los usuarios a lo largo de cada día. Como se discutió en el Capítulo 8, la parte posterior de cada tarjeta de historia de usuario tiene pasos de verificación. Estos pasos permiten al propietario del producto revisar y confirmar que el código funciona y es compatible con la historia del usuario. La Figura 9-6 muestra los pasos de verificación de una tarjeta de historia de usuario de muestra.

FIGURA 9-6: Historia del usuario

verificación.

Por último, el propietario del producto debe realizar algunas comprobaciones para verificar que la historia del usuario en cuestión cumple con la definición de hecho. Cuando una historia de usuario cumple con la definición de terminado, el propietario del producto actualiza el tablero de tareas moviendo la historia de usuario de la columna Aceptar a la columna Listo.

CAPÍTULO 9 Trabajando durante todo el día

177

Mientras que el propietario del producto y el equipo de desarrollo trabajan juntos para crear una funcionalidad de envío para el producto, el scrum master ayuda al equipo de scrum a identificar y eliminar los obstáculos que aparecen en el camino.

Identificación de obstáculos Es una parte importante del rol del scrummaster administrar y ayudar a resolver los obstáculos que identifica el equipo de scrum. Los obstáculos son cualquier cosa que impida que un miembro del equipo trabaje a plena capacidad. Aunque el scrum diario es un buen lugar para que el equipo de desarrollo identifique los obstáculos, el equipo de desarrollo puede acudir al scrum master con problemas en cualquier momento del día. A continuación se muestran algunos ejemplos de obstáculos:

» Problemas locales, tácticos, como

•

Un gerente que intenta sacar a un miembro del equipo para que trabaje en un informe de ventas "prioritario".

•

El equipo de desarrollo necesita hardware o software adicional para

•

Un miembro del equipo de desarrollo que no comprende la historia de un usuario y dice que el

facilitar el progreso.

propietario del producto no está disponible para ayudar.

» Impedimentos organizativos, como • Una resistencia general a las técnicas ágiles, especialmente cuando la empresa estableció y mantuvo procesos previos a un costo significativo.

•

Gerentes que pueden no estar en contacto con el trabajo en el terreno. Tecnologías, prácticas de desarrollo y prácticas de gestión de proyectos siempre están progresando.

•

Departamentos externos que pueden no estar familiarizados con las necesidades de

•

Una organización que aplica políticas que no tienen sentido para equipos de proyectos

scrum y el ritmo de desarrollo al usar técnicas ágiles.

ágiles. Herramientas centralizadas, restricciones presupuestarias y estandarizadas los procesos que no se alinean con los procesos ágiles pueden causar problemas para los equipos ágiles.

El rasgo más importante que puede tener un scrummaster es la influencia o influencia organizacional. La influencia organizacional le da al scrummaster la capacidad de tener conversaciones difíciles y hacer los pequeños y grandes cambios necesarios para que el equipo de scrum tenga éxito. Proporcionamos ejemplos de diferentes tipos de influencia en el Capítulo 4.

178

PARTE 3 Planificación y ejecución ágiles

Más allá del enfoque principal de crear una funcionalidad que se pueda enviar, suceden otras cosas durante el día en un proyecto ágil. Muchas de estas tareas recaen en el scrum master. La Tabla 9-1 muestra posibles obstáculos y la acción que el scrum master puede tomar para eliminar los impedimentos.

TABLA 9-1

Soluciones y obstáculos comunes

Barricada

Acción

El equipo de desarrollo necesita un software de

usuario y el código.

Investigue un poco para estimar el costo del software, prepare un resumen para el propietario del producto y tenga una discusión sobre la financiación. Procese la compra a través de adquisiciones y entregue el software al equipo de desarrollo.

La gerencia quiere pedir prestado a un

Dígale al gerente solicitante que la persona no está disponible y probablemente

miembro del equipo de desarrollo para que

no lo estará mientras dure el proyecto. Recomiende que el solicitante discuta la

escriba un par de informes. Todo tu

necesidad con el propietario del producto para que pueda priorizarlo frente al

los miembros del equipo de desarrollo son

resto de la cartera de productos. Como probablemente sea un solucionador de

totalmente ocupada.

problemas, es posible que desee sugerir formas alternativas en las que el gerente

simulación para una variedad de dispositivos móviles para poder probar la interfaz de

podría obtener lo que necesita. Un miembro del equipo de desarrollo no puede

Trabaje con el miembro del equipo de desarrollo para determinar si se puede

avanzar en la historia de un usuario porque no

trabajar en torno a esta historia de usuario mientras espera una respuesta. Ayude

comprende completamente la historia. El

a localizar a otra persona que pueda responder la pregunta. De lo contrario,

propietario del producto está fuera de la

solicite al equipo de desarrollo que revise las próximas tareas (no relacionadas

oficina durante el día por una emergencia

con esta parada) y mueva las cosas para mantener la productividad alta.

personal. Una historia de usuario ha crecido en complejidad y

Haga que el equipo de desarrollo trabaje con el propietario del producto para desglosar

ahora parece ser demasiado grande para la

la historia del usuario de modo que se pueda completar algún valor demostrable en el

duración del sprint.

sprint actual y el resto se pueda volver a colocar en la cartera de pedidos del producto. El objetivo es garantizar que el sprint finalice con historias de usuario completadas, incluso historias más pequeñas, en lugar de historias de usuario incompletas.

Hasta ahora en este capítulo, has visto cómo el equipo scrum comienza su día y trabaja a lo largo del día. El equipo de scrum concluye cada día con algunas tareas también. La siguiente sección le muestra cómo terminar un día dentro de un sprint.

El final del dia Al final de cada día, el equipo de desarrollo informa sobre el progreso de la tarea actualizando el backlog del sprint con qué tareas se completaron y cuánto trabajo, en horas, queda por hacer en las nuevas tareas iniciadas. Dependiendo del software que utilice el equipo de scrum, los datos del backlog del sprint también pueden actualizar automáticamente el gráfico de evolución del sprint.

CAPÍTULO 9 Trabajando durante todo el día

179

Actualice la acumulación de sprints con la cantidad de trabajo restante, no la cantidad de tiempo que ya se ha dedicado, a las tareas abiertas. El punto importante es cuánto tiempo queda, lo que informa al equipo del proyecto si el equipo de scrum está en camino de alcanzar su objetivo de sprint. Si es posible, evite dedicar tiempo a rastrear cuántas horas se dedicaron a trabajar en tareas, lo cual es menos necesario con los modelos ágiles autocorregibles.

El propietario del producto también debe actualizar el tablero de tareas, al menos al final del día, y mover cualquier historia de usuario que haya pasado la revisión a la columna Listo. El scrummaster puede revisar el backlog del sprint o el tablero de tareas para detectar cualquier riesgo antes del scrum diario del día siguiente.

El equipo de scrum sigue este ciclo diario hasta el final del sprint, cuando será el momento de dar un paso atrás, inspeccionar y adaptarse en la revisión del sprint y las reuniones retrospectivas del sprint.

180

PARTE 3 Planificación y ejecución ágiles

EN ESTE CAPÍTULO » Exhibición de trabajos y coleccionismo realimentación

» Revisando el sprint y mejorando procesos

Capítulo

ShowcasingWork, Inspección y adaptación

su arduo trabajo se muestra en la revisión del sprint. La revisión del sprint es donde el propietario delsprint, producto y el equipo detiene desarrollo demuestran la los resultados de Al final de cada el equipo de scrum la oportunidad de poner

funcionalidad completada y potencialmente enviable a las partes interesadas. En el sprint En retrospectiva, el equipo de scrum (el propietario del producto, el equipo de desarrollo y el scrum master) revisan cómo fue el sprint y determinan si necesitan algún ajuste para el siguiente sprint. La base de estos dos eventos es el concepto ágil de inspeccionar y adaptar, que se explica en el Capítulo 7. En este capítulo, descubrirá cómo realizar una revisión del sprint y una retrospectiva del sprint.

La revisión del Sprint La revisión de sprint es una reunión para revisar y demostrar la funcionalidad creada a partir de las historias de usuario que el equipo de desarrollo completó durante el sprint, y para que el propietario del producto recopile comentarios y actualice la cartera de pedidos del producto

CAPÍTULO 10 Exhibiendo Trabajo, Inspección y Adaptación

181

respectivamente. La revisión del sprint está abierta a cualquier persona interesada en revisar los logros del sprint. Esto significa que todas las partes interesadas tienen la oportunidad de ver el progreso y la precisión del producto y proporcionar comentarios. La revisión del sprint es la etapa 6 de la Hoja de ruta hacia el valor. La figura 10-1 muestra cómo encaja la revisión del sprint en un proyecto ágil.

FIGURA 10-1: La revisión del sprint

en la hoja de ruta valorar.

Las siguientes secciones le muestran lo que debe hacer para prepararse para una revisión de sprint, cómo llevar a cabo una reunión de revisión de sprint y la importancia de recopilar comentarios.

Preparándose para demostrar La preparación para la reunión de revisión del sprint no debería tomar más de unos minutos como máximo. Aunque la revisión del sprint pueda parecer formal, la esencia de la exhibición para equipos ágiles es la informalidad. La reunión debe estar preparada y organizada, pero no requiere muchos materiales llamativos. En cambio, la revisión del sprint se centra en demostrar lo que ha hecho el equipo de desarrollo. Si su revisión de sprint es demasiado llamativa, pregúntese si se está encubriendo por no dedicar suficiente tiempo a desarrollar. Vuelva a trabajar en valor, creando un producto funcional. El boato es enemigo de la agilidad. La preparación para la reunión de revisión del sprint involucra al propietario del producto y al equipo de desarrollo, facilitado por el scrummaster según sea necesario. El propietario del producto necesita saber qué historias de usuario completó el equipo de desarrollo durante el sprint. El equipo de desarrollo debe estar preparado para demostrar la funcionalidad completa y que se puede enviar. El tiempo necesario para prepararse para una revisión de sprint no debe ser de más de 20 minutos, el tiempo suficiente para asegurarse de que todos sepan quién está haciendo qué y cuándo para que la demostración se desarrolle sin problemas.

182

PARTE 3 Planificación y ejecución ágiles

El trabajo no entregado no tiene valor comercial. Dentro del contexto de un solo sprint,

funcionalidad de envío significa que el equipo de desarrollo ha satisfecho su definición de hecho para cada requisito, y el propietario del producto ha verificado que el producto de trabajo cumple con todos los criterios de aceptación y podría lanzarse al mercado, o Enviado, si el valor y el momento son adecuados para el mercado. El lanzamiento real puede ser en un momento posterior, según el plan de lanzamiento comunicado. Obtenga más información sobre la funcionalidad de envío en el Capítulo 9. Para que el equipo de desarrollo demuestre el código en la revisión del sprint, debe estar completo de acuerdo con la definición de hecho. Esto significa que el código está completamente

» Desarrollado » Probado

» Integrado » Documentado A medida que las historias de usuario se mueven a un estado de terminado durante el sprint, el propietario del producto y el equipo de desarrollo deben verificar que la funcionalidad cumpla con estos estándares. Esta validación continua a lo largo del sprint reduce los riesgos al final de la impresión y ayuda al equipo de scrum a pasar el menor tiempo posible preparándose para la revisión del sprint. Conocer las historias de usuario completadas y estar listo para demostrar la funcionalidad de esas historias lo prepara para comenzar con confianza la reunión de revisión del sprint.

La reunión de revisión del sprint Las reuniones de revisión de Sprint tienen dos actividades: demostrar y mostrar el trabajo terminado del equipo scrum y permitir que las partes interesadas brinden comentarios sobre ese trabajo. La figura 10-2 muestra los diferentes ciclos de retroalimentación que recibe un equipo de scrum sobre un producto. Este ciclo de retroalimentación se repite a lo largo del proyecto de la siguiente manera:

» Cada día, los miembros del equipo de desarrollo trabajan juntos en una colaboración entorno que fomenta la retroalimentación a través de revisiones de pares e informales

comunicación.

» A lo largo de cada sprint, tan pronto como el equipo de desarrollo complete cada

requisito, el propietario del producto proporciona comentarios al revisar el trabajo funcionalidad para la aceptación. Luego, el equipo de desarrollo incorpora inmediatamente esa retroalimentación, si la hubiera, para satisfacer la aceptación de la historia del usuario.

CAPÍTULO 10 Exhibiendo Trabajo, Inspección y Adaptación

183

Criterios. Cuando la historia de usuario está completa, el propietario del producto da la aceptación final de la funcionalidad creada para la historia de usuario, de acuerdo con los criterios de aceptación de la historia de usuario.

» Al final de cada sprint, las partes interesadas del proyecto brindan comentarios sobre funcionalidad completada en la reunión de revisión del sprint.

» Con cada lanzamiento, los clientes que usan el producto brindan comentarios sobre nueva funcionalidad.

FIGURA 10-2: Proyecto ágil circuitos de retroalimentacion.

La revisión del sprint generalmente se lleva a cabo más tarde en el día del último día del sprint, a menudo un viernes. Una de las reglas del scrum es no pasar más de una hora en una reunión de revisión de sprint por cada semana del sprint; la figura 10-3 muestra una referencia rápida.

FIGURA 10-3: Proporción de sprint reunión de revisión para longitud del sprint.

Aquí hay algunas pautas para su reunión de revisión de sprint:

» ¡No hay diapositivas de PowerPoint! Muestre la funcionalidad de trabajo real. Consulte el sprint atrasos si necesita mostrar una lista de historias de usuarios completadas.

» Todo el equipo de scrum debe participar en la reunión.

184

PARTE 3 Planificación y ejecución ágiles

» Cualquiera que esté interesado en la reunión puede asistir. El grupo de interés del proyecto teóricos, los pasantes de verano y el director ejecutivo podrían estar en un sprint revisión. También se puede invitar a los clientes siempre que estén disponibles.

» El propietario del producto presenta el objetivo de lanzamiento, el objetivo del sprint y el nuevo capacidades incluidas.

» El equipo de desarrollo demuestra lo que terminado durante el sprint. Normalmente, el equipo de desarrollo muestra nuevas características o arquitectura.

» La demostración debe realizarse en un equipo lo más cerca posible del

entorno de producción planificado. Por ejemplo, si está creando un dispositivo móvil , presente las funciones en un teléfono inteligente, quizás conectado a un monitor, en lugar de en una computadora portátil.

» Las partes interesadas pueden hacer preguntas y proporcionar retroalimentación sobre la demostración producto estratificado.

» Ninguna funcionalidad manipulada no divulgada, como valores codificados y otros

atajos de programación que hacen que la aplicación parezca más madura de lo que es actualmente es. La funcionalidad mejorada crea más trabajo general para el equipo de scrum en futuros sprints para ponerse al día con lo que las partes interesadas creen que ya existe.

» El propietario del producto puede dirigir una discusión sobre lo que vendrá después en función de las funciones que se acaban de presentar y los nuevos elementos que se han agregado al

acumulación de productos durante el sprint actual.

Para cuando llega a la revisión del sprint, el propietario del producto ya ha visto la funcionalidad de cada una de las historias de usuario que se presentarán y ha aceptado que están completas. La reunión de revisión del sprint es valiosa para el equipo de desarrollo. La revisión del sprint brinda una oportunidad para que el equipo de desarrollo muestre su trabajo directamente. La reunión permite a las partes interesadas reconocer al equipo de desarrollo por sus esfuerzos. La reunión contribuye a la moral del equipo de desarrollo, manteniendo al equipo motivado para intentar producir volúmenes cada vez mayores de trabajo de calidad. La revisión del sprint incluso establece un cierto nivel de competencia comparativa amistosa entre equipos de scrum que mantiene a todos concentrados. A veces, una competencia sana puede hacer que los desarrolladores intenten crear las funciones más interesantes o superar los requisitos de una historia de usuario, un problema conocido como oro

platino. Un principio de agilidad es producir solo lo que una historia de usuario necesita para pasar la prueba de aceptación. Existe el riesgo de que los miembros del equipo de desarrollo vayan más allá de las necesidades de los requisitos en su entusiasmo, esencialmente perdiendo el tiempo que debería dedicarse a la funcionalidad útil del producto. El propietario del producto debe estar atento a esto. El chapado en oro se puede identificar y evitar a diario en el scrum diario o cuando el equipo de desarrollo busca una aclaración del propietario del producto.

CAPÍTULO 10 Exhibiendo Trabajo, Inspección y Adaptación

185

A continuación, verá cómo anotar y utilizar los comentarios de las partes interesadas durante la reunión de revisión del sprint.

Recopilación de comentarios en la reunión de revisión del sprint Reúna los comentarios de la revisión del sprint de manera informal. El propietario del producto o scrummaster puede tomar notas en nombre del equipo de desarrollo, ya que los miembros del equipo a menudo participarán en la presentación y la conversación resultante.

Tenga en cuenta el proyecto de ejemplo que usamos a lo largo del libro: una aplicación móvil para XYZ Bank. Las partes interesadas que responden a la funcionalidad que vieron para la aplicación móvil de XYZ Bank pueden tener comentarios como los siguientes:

» De una persona en ventas o marketing: "Es posible que desee considerar dejar que el los clientes guardan sus preferencias en función de los resultados que mostró. Va a

crear una experiencia más personalizada en el futuro ".

» De un director o gerente funcional: "Dado lo que he visto, es posible que

capaz de aprovechar algunos de los módulos de código que se desarrollaron para ABC proyecto el año pasado. Necesitaban hacer una manipulación de datos similar ".

» De alguien que trabaja con los profesionales de la calidad o la experiencia del usuario. en la empresa: “Me di cuenta de que sus inicios de sesión eran bastante sencillos; será el

la aplicación pueda manejar caracteres especiales? " Es posible que surjan nuevas historias de usuarios de la revisión del sprint. Estas nuevas historias de usuario pueden ser nuevas funciones o cambios en la funcionalidad existente.

En las primeras revisiones de sprint, es posible que el scrummaster deba recordar a las partes interesadas sobre las prácticas ágiles. Algunas personas escuchan la palabra "demostración" e inmediatamente esperan diapositivas e impresiones elegantes. El scrum master tiene la responsabilidad de gestionar estas expectativas y mantener valores y prácticas ágiles. El propietario del producto debe agregar nuevas historias de usuario a la cartera de pedidos del producto y ordenar esas historias por prioridad. El propietario del producto también vuelve a agregar a la cartera de pedidos del producto las historias que se programaron para el sprint actual pero que no se completaron, y reordena esas historias en función de las prioridades más recientes. El propietario del producto debe completar las actualizaciones de la cartera de productos a tiempo para la próxima reunión de planificación del sprint.

Cuando finaliza la revisión del sprint, es el momento de la retrospectiva del sprint.

186

PARTE 3 Planificación y ejecución ágiles

Es posible que desee tomar un breve descanso entre la revisión del sprint y la retrospectiva del sprint para que los miembros del equipo de scrum puedan llegar a la discusión retrospectiva frescos y relajados. Habiendo completado la revisión del sprint, el equipo de scrum entrará en la retrospectiva listo para inspeccionar sus procesos y tendrá ideas para la adaptación.

La retrospectiva del Sprint La Sprint retrospectiva es una reunión en la que el propietario del producto, el equipo de desarrollo y el scrum master discuten cómo fue el sprint y qué pueden hacer para mejorar el siguiente sprint. El equipo de scrum debe llevar a cabo esta reunión de forma autodirigida. Si los gerentes o supervisores asisten a las retrospectivas de sprint, los miembros del equipo scrum evitarán ser abiertos entre sí, lo que limita la efectividad del equipo al inspeccionar y adaptarse de manera autoorganizada. Si al equipo de scrum le gusta, los miembros pueden invitar a otras partes interesadas a que también asistan. Si el equipo scrum interactúa regularmente con las partes interesadas externas, la información de esas partes interesadas puede ser valiosa.

La retrospectiva del sprint es la etapa 7 de la Hoja de ruta hacia el valor. La figura 10-4 muestra cómo la retrospectiva del sprint encaja en un proyecto ágil.

FIGURA 10-4: El sprint retrospectiva en la hoja de ruta para

Valor.

El objetivo de la retrospectiva de Sprint es mejorar continuamente sus procesos. Mejorar y personalizar los procesos de acuerdo con las necesidades de cada equipo de scrum individual aumenta la moral del equipo de scrum, mejora la eficiencia y aumenta velocidad - rendimiento del trabajo. (Encuentre detalles sobre la velocidad en el Capítulo 13.) Sin embargo, lo que funciona para un equipo no necesariamente funcionará para otro equipo. Los gerentes fuera del equipo de scrum no deben dictar cómo todos los equipos de scrum deben superar sus desafíos y, en cambio, deben permitirles encontrar las mejores soluciones por sí mismos.

CAPÍTULO 10 Exhibición del trabajo, inspección y adaptación

187

Los resultados retrospectivos de tu sprint pueden ser únicos para tu equipo de scrum. Por ejemplo, los miembros de un equipo de scrum con el que trabajamos decidieron que les gustaría llegar temprano al trabajo y salir temprano, y pasar las tardes de verano con sus familias. Otro equipo de la misma organización consideró que trabajaba mejor a altas horas de la noche y decidió ir a la oficina por la tarde y trabajar por la noche. El resultado para ambos equipos fue un aumento de la moral y una mayor velocidad. Utilice la información que aprenda en la retrospectiva para revisar y revisar sus procesos de trabajo y mejorar su próximo sprint. Los enfoques ágiles, particularmente scrum, revelan rápidamente problemas en los proyectos. Scrum no soluciona problemas; simplemente los expone y proporciona un marco para inspeccionar y adaptar los problemas expuestos. Los datos del backlog del sprint muestran exactamente dónde se ha ralentizado el equipo de desarrollo. El equipo de desarrollo habla y colabora. Todas estas herramientas y prácticas ayudan a revelar ineficiencias y permiten que el equipo de scrum refine las prácticas para mejorar sprint tras sprint. Preste atención a lo que se expone. No lo ignore y no lo evite. En las siguientes secciones, descubrirá cómo planificar una retrospectiva, cómo realizar una reunión retrospectiva de sprint y cómo utilizar los resultados de cada retrospectiva de sprint para mejorar los sprints futuros.

DETENIENDO LA LÍNEA Taiichi Ohno, quien construyó el sistema de producción de Toyota en las décadas de 1950 y 1960, el comienzo de la manufactura esbelta, descentralizó la administración de la línea de ensamblaje para empoderar a los trabajadores de la línea a tomar decisiones. Los trabajadores de la línea en realidad tenían la responsabilidad de detener la línea presionando un botón rojo cuando encontraban un defecto o un problema en la línea de montaje. Tradicionalmente, los gerentes de planta veían detener la línea como una falla y se enfocaban en hacer funcionar la línea de ensamblaje a su capacidad tantas horas al día como fuera posible para maximizar el rendimiento. La filosofía de Ohno era que al eliminar las restricciones a medida que ocurren, se crea de manera proactiva un mejor sistema en lugar de intentar optimizar su proceso existente.

Cuando se introdujo por primera vez, la productividad de los gerentes que implementaron esta práctica sufrió una caída inicial porque dedicaron más tiempo a corregir defectos en el sistema que los equipos de gerentes que no adoptaron la práctica. Los viejos equipos declararon que esto era una victoria al principio. Sin embargo, no pasó mucho tiempo hasta que los nuevos equipos no solo se pusieron al día sino que también comenzaron a producir de manera más rápida, más barata y con menos defectos y variaciones que los equipos que no estaban haciendo mejoras continuas en su sistema. Este proceso de mejora regular y continua es lo que hizo que Toyota tuviera tanto éxito.

188

PARTE 3 Planificación y ejecución ágiles

Planificación de retrospectivas de sprint Para la primera retrospectiva del sprint, todos en el equipo de scrum deben pensar en algunas preguntas clave y estar listos para discutirlas. ¿Qué salió bien durante el sprint? ¿Qué cambiarías y cómo? Todos en el equipo de scrum pueden querer tomar algunas notas de antemano, o incluso tomar notas durante el sprint. El equipo de scrum podría tener en cuenta los obstáculos de las reuniones diarias de scrum del sprint. Para la retrospectiva del segundo sprint en adelante, también puede comenzar a comparar el sprint actual con los sprints anteriores y realizar un seguimiento del progreso en los esfuerzos de mejora de un sprint a otro. En el Capítulo 9, mencionamos cómo salvar los retrasos de sprints de sprints anteriores; aquí es donde pueden resultar útiles. Si el equipo de scrum ha pensado honesta y minuciosamente sobre lo que salió bien y lo que podría ser mejor, puede pasar a la retrospectiva del sprint listo para tener una conversación útil.

La retrospectiva de Sprint La reunión retrospectiva de sprint es una reunión orientada a la acción. El equipo de scrum aplica inmediatamente lo que aprendió en la retrospectiva al siguiente sprint. La reunión retrospectiva de sprint es una reunión orientada a la acción, no una reunión de justificación. Si está escuchando palabras como "porque", la conversación se aleja de la acción y se dirige hacia la lógica. Una de las reglas del scrum es no pasar más de 45 minutos en una reunión retrospectiva de sprint por cada semana del sprint. La figura 10-5 muestra una referencia rápida.

FIGURA 10-5: Proporción de sprint

retrospectivo reunión para correr

largo.

CAPÍTULO 10 Exhibición del trabajo, inspección y adaptación

189

La retrospectiva del sprint debe cubrir tres preguntas principales:

» ¿Qué salió bien durante el sprint? » ¿Qué nos gustaría cambiar? » ¿Cómo podemos implementar ese cambio? Las siguientes áreas también están abiertas a discusión:

» Resultados: Compare la cantidad de trabajo planificada con lo que el desarrollo equipo completado. Revise el gráfico de evolución del sprint (consulte el Capítulo 9) y qué

le dice al equipo de desarrollo cómo está funcionando.

» Personas: Discuta la composición y alineación del equipo.

» Relaciones: Hablar de comunicación, colaboración y trabajo. en pares.

» Procesos: Repase los procesos de soporte, desarrollo y revisión por pares. » Herramientas: ¿Cómo funcionan las diferentes herramientas para el equipo de scrum? Pensar en los artefactos, herramientas electrónicas, herramientas de comunicación y herramientas técnicas.

» Productividad: ¿Cómo puede el equipo mejorar la productividad y aprovechar al máximo el trabajo? hecho en el próximo sprint?

Ayuda tener estas discusiones en un formato estructurado. Esther Derby y Diana Larsen, autoras de Retrospectivas ágiles: hacer grandes equipos buenos ( Pragmatic Bookshelf, 2006), tienen una gran agenda para retrospectivas de sprint que mantiene al equipo enfocado en discusiones que conducirán a una mejora real:

1. Preparar el escenario. Establecer los objetivos para la retrospectiva por adelantado ayudará a mantener a su equipo de scrum enfocado en brindar el tipo correcto de retroalimentación más adelante en la reunión. A medida que avanza hacia los sprints posteriores, es posible que desee tener retrospectivas que se centren en una o dos áreas específicas de mejora.

2. Reunir datos. Discuta los hechos sobre lo que salió bien en el último sprint y lo que necesitaba mejorar. Crea una imagen general del sprint; considere usar una pizarra para anotar los comentarios de los asistentes a la reunión.

3. Genere conocimientos. Eche un vistazo a la información que acaba de recopilar y proponga ideas sobre cómo realizar mejoras para el próximo sprint.

190

PARTE 3 Planificación y ejecución ágiles

4. Decide qué hacer. Determine, en equipo, qué ideas pondrá en práctica. Decida las acciones específicas que puede tomar para hacer realidad las ideas.

5. Cierre la retrospectiva. Reitere su plan de acción para el próximo sprint. Agradezca a la gente por contribuir. ¡También encuentre formas de mejorar la próxima retrospectiva!

Para algunos equipos de scrum, puede ser difícil abrirse al principio. Es posible que el scrummaster deba hacer preguntas específicas para iniciar las discusiones. Participar en retrospectivas requiere práctica. Lo que importa es alentar al equipo de scrum a que asuma la responsabilidad del sprint, a que realmente acepte la autogestión. En otros equipos de scrum, se produce mucho debate y discusión durante la retrospectiva. El scrum master puede encontrar un desafío para administrar estas discusiones y mantener la reunión dentro del tiempo asignado, pero eso es lo que debe hacerse. Asegúrese de utilizar los resultados de sus retrospectivas de sprint para inspeccionar y adaptar a lo largo de su proyecto.

Inspeccionar y adaptar La retrospectiva del sprint es una de las mejores oportunidades que tiene para poner en práctica las ideas de inspeccionar y adaptarse. Se le ocurrieron desafíos y soluciones durante la retrospectiva. No deje esas soluciones atrás después de la reunión; haga que las mejoras formen parte de su trabajo todos los días. Puede registrar sus recomendaciones de mejora de manera informal. Algunos equipos de scrum publican las acciones identificadas durante la reunión retrospectiva en el área del equipo para garantizar la visibilidad y la acción sobre los elementos enumerados. Muchos equipos también agregan elementos de acción a la cartera de productos para garantizar que los implementen durante un próximo sprint.

Para ser más ágiles, los equipos de scrum se enfocan en pequeños cambios con gran valor. Nos gusta que los equipos realicen al menos una mejora en cada sprint, un proceso que a veces se denomina scrum el scrum. En las reuniones retrospectivas de sprints posteriores, es importante revisar las evaluaciones del sprint anterior y asegurarse de implementar las mejoras sugeridas.

CAPÍTULO 10 Exhibición del trabajo, inspección y adaptación

191

EN ESTE CAPÍTULO

» Preparando su producto para enviar » Organización para el apoyo operativo

» Preparando al resto de la organización para el lanzamiento

» Asegurándose de que el mercado esté listo para tu liberación

Capítulo

Preparándose para la liberación

El equipo de desarrollo tiene tareas específicas para el lanzamiento de un producto que difieren de clientes las tareas relacionadas con la depresenta funciones sprints Ofrecer a los nuevas características decreación productos undurante conjuntolos especial denormales. desafíos.

Es posible que la organización que patrocina el producto deba prepararse para respaldar la producto. Quiere que los clientes puedan utilizar correctamente el producto lanzado. Este capítulo cubre cómo administrar el sprint final, si es necesario, el sprint de lanzamiento, antes del lanzamiento del producto. También descubre cómo preparar su organización y el mercado para el lanzamiento del producto.

Preparación del producto para la implementación: el Sprint de lanzamiento El trabajo que se lleva a cabo durante los sprints de desarrollo regulares debe ser completo y completo, incluidas las pruebas y la documentación técnica, antes de demostrar su producto. El producto de un sprint de desarrollo es la funcionalidad de trabajo. Sin embargo, puede haber actividades, no relacionadas con la creación de características del producto, que el equipo de desarrollo no puede completar de manera realista dentro de los sprints de desarrollo y que incluso pueden introducir una sobrecarga inaceptable. Para acomodar la presentación

CAPÍTULO 11 Preparándose para el lanzamiento

193

actividades y ayudar a garantizar que el lanzamiento vaya bien, los equipos de scrum pueden programar un sprint de lanzamiento como el sprint final antes de entregar la funcionalidad a los clientes.

Si un equipo de scrum requiere un sprint de lanzamiento, probablemente significa que la organización en general no puede apoyarlo, lo cual es un anti-patrón para volverse ágil. Todo tipo de trabajo o actividad necesaria para lanzar la funcionalidad al mercado debe formar parte de la definición de hecho a nivel de sprint. Ese es el objetivo de los equipos ágiles. El sprint de lanzamiento contiene solo aquellas cosas necesarias para llevar la funcionalidad operativa al mercado. A continuación, se muestran ejemplos de elementos de la lista de trabajos pendientes de lanzamiento. Vea si puede pensar en posibles formas de cambiar cualquiera de estos al sprint de desarrollo:

» Creación de documentación de usuario para la versión más reciente del producto » Pruebas de rendimiento, pruebas de carga, pruebas de seguridad y cualquier otra verificación para Asegurarse de que el software de trabajo funcionará aceptablemente en producción.

» Integrar el producto con sistemas de toda la empresa, donde las pruebas pueden tomar días o semanas

» Completar los procedimientos organizativos o reglamentarios que son obligatorios antes liberar

» Preparación de notas de la versión: notas finales sobre cambios en el producto

» Preparando el paquete de implementación, habilitando todo el código del producto características para pasar a producción al mismo tiempo

» Implementar su código en el entorno de producción Algunos aspectos de un sprint de lanzamiento son diferentes de un sprint de desarrollo:

» No desarrolla nuevos requisitos de funcionalidad del producto.

reserva. Aunque tiene funcionalidad congelada, no tiene congelación de código porque el equipo de desarrollo necesitará hacer ajustes para responder a los comentarios de las actividades de lanzamiento, como las pruebas de rendimiento o los grupos focales.

» Según el trabajo que necesita hacer, su sprint de lanzamiento puede ser diferente longitud que sus sprints de desarrollo habituales. Además, no tendrá la

concepto de velocidad porque no estarás haciendo el mismo tipo de trabajo que haces en los sprints de desarrollo.

» La definición de terminado es diferente para el trabajo completado durante un sprint de lanzamiento. En un sprint de desarrollo, hecho significa la finalización de la funcionalidad de trabajo para una historia de usuario. En un sprint de lanzamiento, la definición es la finalización de todas las tareas necesarias para el lanzamiento.

194

PARTE 3 Planificación y ejecución ágiles

ENTENDIENDO EL PAPEL DE LA DOCUMENTACIÓN ¿Cuál es la diferencia entre la documentación técnica que crea durante un sprint y la documentación del usuario que puede crear en su sprint de lanzamiento? Tu documentación técnica debería ser apenas suficiente, sin lujos y con la información suficiente para decirle al equipo de desarrollo, y tal vez a los equipos de desarrollo futuros, cómo crear y actualizar el producto. Si, en el último día del sprint, el equipo de desarrollo ganó la lotería y se retiró a Costa Rica, un nuevo equipo de desarrollo debería poder revisar la documentación técnica y continuar fácilmente donde lo dejó el equipo anterior. Tu documentación del usuario les dice a sus clientes cómo usar su producto. Es posible que desee documentación de usuario elaborada específicamente para cada uno de sus clientes. Por ejemplo, una aplicación de banca móvil puede necesitar una sección de preguntas frecuentes (FAQ) para los clientes bancarios. La misma aplicación puede tener una función que permita a los gerentes de marketing cargar mensajes publicitarios en la aplicación; querrá asegurarse de que esos administradores también tengan instrucciones para la función de carga. Debido a que su producto tendrá cambios a lo largo de cada sprint del lanzamiento, podría ser más eficiente esperar hasta el último minuto responsable para crear su documentación de usuario, después de que las partes interesadas acuerden que la funcionalidad está lista para su lanzamiento.

» Un sprint de lanzamiento incluye pruebas y aprobaciones que pueden no ser prácticas de hacer en un sprint de desarrollo, como pruebas de rendimiento, pruebas de carga, seguridad

pruebas, grupos focales y revisión legal. Los equipos de desarrollo ágiles pueden crear dos definiciones de hecho: una para sprints y otra para lanzamientos. La Tabla 11-1 muestra una comparación entre las actividades de un sprint de desarrollo y un sprint de lanzamiento. Para obtener descripciones detalladas de los elementos clave de un sprint, consulte los Capítulos 8 a 10.

TABLA 11-1

Elementos de Sprint de desarrollo versus elementos de Sprint de lanzamiento

Elemento

Utilizado en el Sprint de desarrollo

Utilizado en Release Sprint

Planificación de Sprint

sí

Pila de Producto

sí

No (continuado)

CAPÍTULO 11 Preparándose para el lanzamiento

195

TABLA 11-1 ( continuado)

Elemento

Utilizado en el Sprint de desarrollo

Utilizado en Release Sprint

Cartera de Sprint

sí

Para un sprint de desarrollo, su backlog de

En un sprint de lanzamiento, ya no necesita poner sus

sprint contiene historias de usuario y las

requisitos en el formato de historia de usuario. En su lugar,

tareas necesarias para crear cada historia de

crea solo una lista de tareas necesarias para el lanzamiento.

usuario. Estima las historias de usuario de

Tampoco usas puntos de historia. En su lugar, agregue las

forma relativa, con puntos de historia.

horas estimadas que tomará cada tarea al planificar el

(Véanse los capítulos 7 y 8.)

sprint de lanzamiento, de la misma manera que desglosa y estima las tareas durante la planificación del sprint de desarrollo.

Cuadro de incendio

sí

Scrum diario

sí

sí Involucre a las partes interesadas externas al equipo de scrum que tienen tareas asociadas con el lanzamiento del producto, como los administradores de compilación empresarial u otros administradores de configuración.

Actividades diarias

Final de-

En un sprint de desarrollo, sus

En un sprint de lanzamiento, sus actividades diarias se

actividades diarias se centran en crear

centran en preparar su funcionalidad de trabajo para el

funcionalidad de envío.

lanzamiento externo.

sí

informes diarios Revisión de Sprint

Algunas organizaciones utilizan una revisión de sprint de lanzamiento como ir o no ir a la reunión para autorizar el lanzamiento de la funcionalidad.

pique retrospectivo

sí

sí Esta puede ser una oportunidad para inspeccionar todo el sprint y planificar la adaptación en la próxima versión.

Un sprint de lanzamiento no debería ser un estacionamiento para tareas que el equipo de desarrollo no terminó en los sprints de desarrollo. Es posible que no le sorprenda saber que los equipos de desarrollo a veces se ven tentados a retrasar las tareas hasta el sprint de lanzamiento. Puede evitar esto asegurándose de que el equipo de scrum haya creado una definición adecuada de terminado para los requisitos en los sprints de desarrollo, incluidas las pruebas, la integración y la documentación. Mientras ejecuta un sprint de lanzamiento, también debe preparar a su organización para el lanzamiento del producto. En las siguientes secciones se analiza cómo prepararse para admitir la nueva funcionalidad en el mercado y cómo preparar a las partes interesadas de su empresa u organización para la implementación del producto.

196

PARTE 3 Planificación y ejecución ágiles

Preparación para el apoyo operativo Después de que su producto sea entregado al cliente, alguien tendrá que respaldarlo. Respaldar su producto implica responder a las consultas de los clientes, mantener el sistema en un entorno de producción y mejorar la funcionalidad existente para llenar brechas menores. Aunque el trabajo de desarrollo nuevo y el trabajo de apoyo operativo son importantes, implican diferentes enfoques y cadencias. Separar el nuevo desarrollo y el trabajo de soporte asegura que los nuevos equipos de desarrollo puedan concentrarse en continuar brindando soluciones innovadoras a los clientes a un ritmo más rápido que si el equipo cambiara con frecuencia entre los dos tipos de trabajo. Un equipo de scrum que realiza un nuevo desarrollo puede planificar y desarrollar una nueva funcionalidad de trabajo en un sprint de una a dos semanas, pero es difícil planificar cuándo surgirán problemas operativos o de mantenimiento. El trabajo de mantenimiento generalmente requiere iteraciones de tiempo más breves, por lo general no más de un día, que generalmente es el tiempo más largo que puede pasar la organización sin cambiar las prioridades con cualquier problema en la producción.

Recomendamos un modelo que separe el nuevo desarrollo y el trabajo de mantenimiento, como se ilustra en la Figura 11-1.

FIGURA 11-1: Operacional apoyo scrum modelo de equipo.

Para un equipo scrum de nueve desarrolladores, por ejemplo, dividiríamos el equipo de desarrollo en dos equipos, uno con seis desarrolladores y el otro con tres. (Estos números son flexibles). El equipo de seis personas realiza el trabajo de un nuevo proyecto de desarrollo desde la acumulación de productos en sprints de una semana a dos semanas, como se describe en los Capítulos 7 al 10. El trabajo al que se compromete el equipo durante la reunión de planificación del sprint será el único trabajo que hagan.

CAPÍTULO 11 Preparándose para el lanzamiento

197

El equipo de tres son nuestros bomberos y realizan trabajos de mantenimiento y apoyo en sprints de un día o usando kanban. (Aprenderá sobre kanban en el Capítulo 4.) Los sprints de un solo día permiten al equipo de scrum clasificar todas las solicitudes entrantes del día anterior, planificar los elementos de mayor prioridad, implementar esos elementos como un equipo y revisar los resultados al final de el día (o incluso antes) para aprobar o no aprobar antes de impulsar los cambios a la producción. Para la continuidad, el propietario del producto y el scrum master son los mismos para cada equipo. Aunque el equipo de desarrollo del proyecto recientemente modificado es más pequeño que antes, todavía hay suficientes desarrolladores para que los nuevos esfuerzos de desarrollo sigan avanzando, sin que se interrumpa el trabajo de mantenimiento. Para cuando comience a lanzar la funcionalidad al mercado, su equipo de scrum estará trabajando bien en conjunto y los desarrolladores habrán aumentado su versatilidad al poder completar más tipos de tareas que cuando comenzó el proyecto. El equipo de desarrollo del proyecto tendrá lanzamientos periódicos a producción, como una vez cada 90 días. En cada lanzamiento, un desarrollador rotará al equipo de mantenimiento, armado con conocimiento de primera mano de la funcionalidad que se implementará en producción. Al mismo tiempo, un desarrollador del equipo de mantenimiento se rotará en el equipo de desarrollo del proyecto, equipado con conocimiento de primera mano de cómo es dar soporte al producto en el mundo real. Esta rotación continúa en cada lanzamiento.

Operaciones de desarrollo (DevOps) es la colaboración e integración entre los desarrolladores de software y las operaciones de TI (que incluye funciones como la administración de sistemas y el mantenimiento del servidor). Adoptar un enfoque de DevOps permite que los desarrolladores y las operaciones trabajen juntos para reducir los tiempos de ciclo de implementación.

Este modelo de DevOps garantiza que todos puedan realizar el desarrollo de nuevos productos, así como el trabajo de mantenimiento, y que el conocimiento del producto se comparta de manera continua y efectiva entre los dos equipos de desarrollo. Este enfoque mejora DevOps y facilita a los miembros del equipo multifuncionales. También minimiza cualquier interrupción que los equipos puedan experimentar al cambiar de miembro del equipo porque las rotaciones ocurren solo en cada lanzamiento en lugar de diariamente o semanalmente.

Al prepararse para el lanzamiento, establecer expectativas por adelantado de cómo se respaldará la funcionalidad en la producción permite que el equipo de scrum desarrolle el producto de una manera que le permita al equipo respaldar el producto de manera efectiva después de su implementación. Aumenta la propiedad en todo el equipo scrum y aumenta la conciencia y la dedicación del equipo al éxito a largo plazo.

198

PARTE 3 Planificación y ejecución ágiles

PRIMAVERAS DE UN DÍA Recomendamos ejecutar sprints de un día para los equipos de mantenimiento. Al enmarcar cada día en el ciclo de sprint, el equipo scrum opera en un circuito de retroalimentación sólido, asegurando una inspección y adaptación continuas, así como la participación regular de las partes interesadas.

Al usar las mismas fórmulas para los eventos de escrutinio de timeboxing, no pasará horas planificando o revisando como lo haría con los sprints de una a cuatro semanas. Dividir las casillas de tiempo de scrumevent de una semana por cinco días significa que dedicará aproximadamente 25 minutos a clasificar la acumulación de productos de mantenimiento y planificar el día, aproximadamente 12 a 15 minutos para la revisión del sprint para determinar si la producción está o no, y 10 minutos adicionales para inspeccionar y adaptar los procesos del equipo e identificar cualquier problema que deba continuarse o descontinuarse al día siguiente.

La clave para operar en sprints de un día es asegurarse de que los elementos de mantenimiento se desglosen lo suficientemente pequeños como para que los desarrolladores puedan completarlos en menos de un día. Este enfoque garantiza que los clientes obtengan algo todos los días en lugar de esperar semanas.

Preparación de la organización para la implementación de productos El lanzamiento de un producto a menudo afecta a varios departamentos de una empresa u organización. Para que la organización esté lista para el nuevo producto, el propietario del producto y el scrum master deben agregar elementos relevantes para la organización al liberar el retraso del

sprint. ( Vea cómo crear un backlog de sprint en el Capítulo 8.) La lista de trabajos pendientes del sprint de lanzamiento también debe cubrir las actividades del equipo de desarrollo. También debe abordar las actividades que deben realizar los grupos de la organización pero fuera del equipo de scrum para prepararse para la implementación del producto. Estos departamentos pueden incluir lo siguiente:

» Márketing: Las campañas de domarketing relacionadas con el nuevo producto deben ¿Lanzamiento al mismo tiempo que el producto?

» Ventas: ¿Hay clientes específicos que necesiten conocer el producto? Voluntad ¿El nuevo producto provoca un aumento en las ventas?

» Logística: ¿Es el producto un artículo físico que incluye embalaje o envío?

CAPÍTULO 11 Preparándose para el lanzamiento

199

» Soporte de producto: ¿Tiene el grupo de servicio al cliente la información que necesita?

necesita responder preguntas sobre el nuevo producto? ¿Este grupo tendrá suficientes personas disponibles en caso de que las preguntas de los clientes aumenten cuando se lanza el producto?

» Legal: ¿El producto cumple con los estándares legales, incluidos precios, licencias y verborrea correcta, para dar a conocer al público?

Los departamentos que deben estar preparados para el lanzamiento del producto y las tareas específicas que estos grupos deben realizar variarán, por supuesto, de una organización a otra. Sin embargo, una clave para el éxito del lanzamiento es que el propietario del producto y el scrummaster involucren a las personas adecuadas y se aseguren de que esas personas entiendan claramente lo que deben hacer para estar listos para el lanzamiento de la funcionalidad. Al igual que con los sprints de desarrollo, en su sprint de lanzamiento, puede utilizar de manera efectiva scrums diarios, reuniones de revisión de sprint y retrospectivas de sprint con colegas del departamento involucrados en la preparación para la implementación del producto. Incluso puede utilizar un tablero de tareas, como el que describimos en el Capítulo 9.

Durante su sprint de lanzamiento, también debe incluir un grupo más en su planificación: el cliente del producto. La siguiente sección trata sobre cómo preparar el mercado para su producto.

Preparando el mercado para Despliegue de productos El propietario del producto es responsable de trabajar con otros departamentos para garantizar que el mercado (clientes existentes y clientes potenciales) esté listo para lo que se avecina. Los equipos de marketing o ventas pueden liderar este esfuerzo; los miembros del equipo buscan al propietario del producto para mantenerlos informados sobre la fecha de lanzamiento y las características que serán parte del lanzamiento.

Algunos productos de software son solo para uso interno de los empleados. Ciertas cosas que está leyendo en esta sección pueden parecer excesivas para una aplicación interna, una aplicación lanzada solo dentro de su empresa. Sin embargo, muchos de estos pasos siguen siendo buenas pautas para promover aplicaciones internas. Preparar a los clientes, ya sean internos o externos, para nuevos productos puede ser una parte clave del éxito del producto.

200

PARTE 3 Planificación y ejecución ágiles

Para ayudar a preparar a los clientes para el lanzamiento del producto, es posible que el propietario del producto desee trabajar con diferentes equipos para garantizar lo siguiente:

» Soporte de mercadeo: Ya sea que se trate de un producto nuevo o nuevo características de un producto existente, el departamento de marketing debe aprovechar

la emoción de la funcionalidad del nuevo producto para ayudar a promover el producto y la organización.

» Prueba de cliente: Si es posible, trabaje con sus clientes (algunas personas usan grupos focales) para obtener comentarios del mundo real sobre el producto de un subconjunto de usuarios finales. Su equipo de marketing también puede utilizar estos comentarios para traducirlos en testimonios para promocionar el producto de inmediato.

» Elementos de marketing: El grupo de marketing de una organización también prepara

planes promocionales y publicitarios, así como embalajes para medios físicos. Los materiales de los medios, como los comunicados de prensa y la información para los analistas, deben estar listos, como materiales de marketing y ventas.

» Canales de soporte: Asegúrese de que los clientes comprendan el soporte disponible canales en caso de que tengan preguntas sobre el producto.

Revise las tareas en su lista de trabajos pendientes de lanzamiento desde el punto de vista del cliente. Piense en las personas que utilizó al crear sus historias de usuario. ¿Esas personas necesitan saber algo sobre el producto? Actualice su lista de verificación de lanzamiento con elementos que serían valiosos para los clientes representados por sus personajes. Puede encontrar más información sobre personas en el Capítulo 8. Finalmente, estás ahí: el día del lanzamiento. Cualquiera que sea el papel que desempeñó en el camino, este es el día que trabajó duro para lograrlo. ¡Es tiempo de celebrar!

CAPÍTULO 11 Preparándose para el lanzamiento

201

4 Ágil

Gestión

EN ESTA PARTE . . . Responder con eficacia a los cambios de alcance. Gestione proveedores y contratos para lograr el éxito. Monitorear y ajustar horarios y presupuesto. Autoorganización para comunicaciones óptimas. Inspeccionar y adaptar para aumentar la calidad y mitigar el riesgo.

EN ESTE CAPÍTULO

» Descubrir cómo la gestión del alcance es diferente en proyectos ágiles » Gestionar el alcance y los cambios de alcance

con procesos ágiles » Viendo el enfoque diferente ágil los procesos aportan a las adquisiciones

» Gestión de adquisiciones en ágil proyectos

Capítulo

Gestión del alcance y

Obtención

comprender los requisitos básicos del producto y el trabajo que se necesitará para cumplirlos. Necesita poder priorizar administrar el alcance La gestión de afrontamiento es partey de cada proyecto. Para crear un producto, debe

cambios a medida que surgen nuevos requisitos. Tiene que verificar que el producto terminado tenga turas satisfacen las necesidades de los clientes.

Las adquisiciones también forman parte de muchos proyectos. Si necesita buscar ayuda fuera de su organización para completar un proyecto, debe saber cómo realizar la adquisición de bienes y servicios. Querrá saber cómo colaborar con los equipos de proveedores durante el proyecto. También debe saber algo sobre la creación de contratos y diferentes estructuras de costos. En este capítulo, descubrirá cómo administrar el alcance en un proyecto ágil y aprovechar el enfoque acogedor de los métodos ágiles para el cambio informado. También averigua cómo gestionar la adquisición de bienes y servicios para entregar el alcance del producto en un proyecto ágil. Primero, revisamos la gestión de alcance tradicional.

CAPITULO 12 Gestión del alcance y las adquisiciones

205

¿Qué tiene de diferente la gestión ágil del alcance? Históricamente, una gran parte de la gestión de proyectos es la gestión del alcance. Definición del producto son todas las características y requisitos que incluye un producto. Alcance del proyecto es todo el trabajo que implica la creación de un producto. La gestión de proyectos tradicional trata los requisitos cambiantes como una señal de fracaso en la planificación inicial. Los proyectos ágiles, sin embargo, tienen un alcance variable para que los equipos de proyectos puedan incorporar de forma inmediata e incremental el aprendizaje y la retroalimentación y, en última instancia, crear mejores productos. Los firmantes del Manifiesto Ágil reconocieron que el cambio de alcance es natural y beneficioso. Los enfoques ágiles adoptan específicamente el cambio y lo utilizan para tomar decisiones mejor informadas y productos más útiles.

Si ejecuta un proyecto ágil y sus requisitos no cambian porque no aprendió nada en el camino, eso es un fracaso. Su cartera de productos debería cambiar a menudo a medida que aprende de los comentarios de las partes interesadas y los clientes. Es poco probable que supieras todo al comienzo del proyecto. El Capítulo 2 detalla el Manifiesto Ágil y los 12 Principios Ágiles. (Si aún no ha leído ese capítulo, vuelva a leerlo ahora. Esperaremos). El manifiesto y los principios responden a la pregunta: "¿Cuán ágiles somos?" El grado en el que el enfoque de su proyecto respalda el manifiesto y los principios ayuda a determinar qué tan ágiles son sus métodos.

Los principios ágiles que más se relacionan con la gestión del alcance son los siguientes:

1. Nuestra máxima prioridad es satisfacer al cliente a través de un proceso temprano y continuo. entrega de software valioso.

2. Bienvenidos los requisitos cambiantes, incluso al final del desarrollo. Procesos ágiles aprovechar el cambio para la ventaja competitiva del cliente.

3. Entregue software que funcione con frecuencia, desde un par de semanas hasta un par de meses, con preferencia a la escala de tiempo más corta.

10. La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial. Los enfoques ágiles para la gestión del alcance son fundamentalmente diferentes a los métodos tradicionales para la gestión del alcance. Considere las diferencias que ve en la Tabla 12-1.

206

PARTE 4 Gestión ágil

TABLA 12-1

Gestión de alcance tradicional versus ágil

Gestión del alcance con Enfoques tradicionales Los equipos de proyecto intentan identificar y documentar el alcance completo al comienzo del proyecto, cuando los equipos están menos informados sobre el producto.

Gestión del alcance con enfoques ágiles El propietario del producto reúne requisitos de alto nivel al comienzo del proyecto, desglosando y detallando los requisitos que se implementarán en el futuro inmediato. Los requisitos se recopilan y perfeccionan a lo largo del proyecto a medida que aumenta el conocimiento del equipo sobre las necesidades del cliente y las realidades del proyecto.

Las organizaciones ven como negativo

Las organizaciones ven el cambio como una forma positiva de mejorar un producto a

el cambio de alcance una vez finalizada

medida que avanza el proyecto.

la fase de requisitos.

Los cambios tardíos en el proyecto, cuando se sabe más sobre el producto, suelen ser los cambios más valiosos.

Los gerentes de proyecto controlan y desalientan rígidamente los cambios después de que las partes interesadas firman

requisitos.

La gestión del cambio es una parte inherente de los procesos ágiles.

Evalúa el alcance y tiene la oportunidad de incluir nuevos requisitos con cada sprint. El propietario del producto determina el valor y la prioridad de los nuevos requisitos y agrega esos requisitos a la cartera de pedidos del producto.

El costo del cambio aumenta con el tiempo, mientras que la capacidad de realizar cambios disminuye.

Usted arregla los recursos y la programación inicialmente.

Las nuevas funciones con alta prioridad no necesariamente causan un retraso en el presupuesto o la programación; simplemente eliminan las funciones de menor prioridad.

El desarrollo iterativo permite cambios con cada nuevo sprint. Los proyectos a menudo incluyen hinchazón del alcance,

El equipo de scrum determina el alcance al considerar qué características respaldan

características innecesarias del producto

directamente la visión del producto, el objetivo de lanzamiento y el objetivo del

incluido por temor al cambio a

sprint.

mitad del proyecto.

El equipo de desarrollo crea primero las características más valiosas para garantizar su inclusión y enviar esas características lo antes posible.

Es posible que nunca se creen características menos valiosas, que pueden ser aceptables para la empresa y el cliente después de que tengan las características de mayor valor.

En cualquier momento de un proyecto ágil, cualquier persona (el equipo de scrum, las partes interesadas o cualquier otra persona de la organización que tenga una buena idea) puede identificar los requisitos de un nuevo producto. El propietario del producto determina el valor y la prioridad de los nuevos requisitos y prioriza esos requisitos frente a otros requisitos en la cartera de pedidos del producto. La gestión de proyectos tradicional tiene un término para describir los requisitos que cambian después de la fase de definición inicial del proyecto: fluencia del alcance. Waterfall no tiene una forma positiva de incorporar cambios a mitad del proyecto, por lo que los cambios de alcance a menudo causan grandes problemas con el cronograma y el presupuesto de un proyecto en cascada. (Para más información sobre

CAPITULO 12 Gestión del alcance y las adquisiciones

207

metodología de cascada, consulte el Capítulo 1.) Mencione el "avance lento del alcance" a un gerente de proyecto experimentado, e incluso podría verlo estremecerse. Durante la planificación del sprint al comienzo de cada sprint, el equipo de scrum puede usar la prioridad del backlog del producto para ayudar a decidir si un nuevo requisito debe ser parte del sprint. Los requisitos de menor prioridad permanecen en la cartera de productos para su consideración en el futuro. Puede leer sobre la planificación de sprints en el Capítulo 8. La siguiente sección trata sobre cómo administrar el alcance en un proyecto ágil.

Gestión del alcance ágil Dar la bienvenida al cambio de alcance le ayuda a crear el mejor producto posible. Sin embargo, aceptar el cambio requiere que comprenda el alcance actual y sepa cómo lidiar con las actualizaciones a medida que surgen. Afortunadamente, los enfoques ágiles tienen formas sencillas de gestionar los requisitos nuevos y existentes:

» El propietario del producto se asegura de que el resto del equipo del proyecto, el scrum teamplus las partes interesadas del proyecto: comprende claramente el alcance existente para el proyecto, la visión del producto, el objetivo de lanzamiento actual y el objetivo de sprint actual.

» El propietario del producto determina el valor y la prioridad de los nuevos requisitos en relación con la visión del producto, el objetivo de lanzamiento, los objetivos del sprint y los

requisitos.

» El equipo de desarrollo crea los requisitos del producto en orden de prioridad para suelte primero las partes más importantes del producto.

En las siguientes secciones, descubrirá cómo comprender y transmitir el alcance en diferentes partes de un proyecto ágil. Verá cómo evaluar las prioridades a medida que surgen nuevos requisitos. También averigua cómo utilizar la acumulación de productos y otros artefactos ágiles para administrar el alcance.

Entender el alcance en todo el proyecto

En cada etapa de un proyecto ágil, el equipo de scrum administra el alcance de diferentes maneras. Una buena forma de ver la gestión del alcance a lo largo de un proyecto es utilizar la Hoja de ruta hacia el valor, que se presentó por primera vez en el Capítulo 7 y se muestra nuevamente en la Figura 12-1.

208

PARTE 4 Gestión ágil

FIGURA 12-1: La hoja de ruta para

Valor.

Considere cada parte de la Hoja de ruta hacia el valor:

» Etapa 1, visión del producto: La declaración de visión del producto establece el exterior límite de la funcionalidad que incluirá el producto, y es el primer paso

en el establecimiento del alcance del proyecto. El propietario del producto es responsable de garantizar que todos los miembros del equipo del proyecto conozcan la declaración de visión del producto y que todos los miembros del equipo del proyecto interpreten la declaración correctamente.

» Etapa 2, hoja de ruta del producto: Durante la creación de la hoja de ruta del producto, el producto El propietario se refiere a la declaración de visión y se asegura de que las características respalden la

declaración de la visión. A medida que se materializan las nuevas características, el propietario del producto debe comprenderlas y poder comunicar claramente al equipo de desarrollo y a las partes interesadas el alcance de estas características y cómo respaldan la visión del producto.

» Etapa 3, planificación del lanzamiento: Durante la planificación del lanzamiento, el propietario del producto necesita para determinar un objetivo de lanzamiento: el límite medio de la funcionalidad planeó salir al mercado en la próxima versión, y seleccione solo el alcance que admita ese objetivo de la versión.

» Etapa 4, planificación del sprint: Durante la planificación del sprint, el propietario del producto debe Asegurarse de que el equipo de scrum entienda el objetivo de lanzamiento y planifique cada

CAPITULO 12 Gestión del alcance y las adquisiciones

209

objetivo del sprint: el límite inmediato de la funcionalidad que se puede enviar potencialmente al final del sprint, en función de ese objetivo de lanzamiento. El propietario del producto y el equipo de desarrollo seleccionan solo el alcance que respalda el objetivo del sprint como parte del sprint. El propietario del producto también se asegurará de que el equipo de desarrollo comprenda el alcance de las historias de usuario individuales seleccionadas para el sprint.

» Etapa 5, scrum diario: El scrummeeting diario puede ser un punto de partida para cambio de alcance para sprints futuros. El scrummeeting diario es un

Reunión de 15 minutos para que el equipo de desarrollo indique tres cosas: el trabajo completado del día anterior, el alcance del trabajo para el día siguiente y cualquier obstáculo que pueda tener el equipo de desarrollo. Sin embargo, los tres temas del scrum diario a menudo revelan mayores oportunidades para cambios de alcance. Cuando surgen temas que justifican una discusión más amplia de lo que permite el tiempo y el formato del scrummeeting diario, un equipo de scrum puede decidir tener una reunión posterior a la fiesta. En la fiesta posterior, los miembros del equipo scrum hablan sobre los problemas que afectan su progreso hacia la meta del sprint. Si se identifican oportunidades para nuevas funcionalidades (nuevo alcance) durante el sprint, el propietario del producto las evalúa y puede agregarlas y priorizarlas en el backlog del producto para un sprint futuro.

» Etapa 6, revisión del sprint: El propietario del producto establece el tono de cada revisión de sprint reunión reiterando el alcance del sprint: el objetivo del sprint que el scrum

teampursued y lo que se completó. Especialmente durante la primera revisión del sprint, es importante que las partes interesadas en la reunión tengan las expectativas correctas sobre el alcance. Las revisiones de Sprint pueden ser inspiradoras. Cuando todo el equipo del proyecto está en una habitación, interactuando con el producto de trabajo, los miembros pueden mirar el producto de nuevas formas y proponer ideas para mejorarlo. El propietario del producto actualiza la cartera de pedidos del producto con un nuevo alcance en función de los comentarios recibidos en la revisión del sprint.

» Etapa 7, retrospectiva de sprint: En la retrospectiva del sprint, el equipo scrum Los miembros pueden discutir qué tan bien cumplieron con los compromisos de alcance que asumieron.

al comienzo del sprint. Si el equipo de desarrollo no pudo lograr el objetivo del sprint identificado durante la planificación del sprint, sus miembros deberán refinar la planificación y los procesos de trabajo para asegurarse de que pueden seleccionar la cantidad correcta de trabajo para cada sprint. Si el equipo de desarrollo alcanzó sus objetivos, puede utilizar la retrospectiva de sprints para encontrar formas de agregar más alcance a los sprints futuros. Los equipos de Scrum tienen como objetivo mejorar la productividad con cada sprint.

210

PARTE 4 Gestión ágil

Introduciendo cambios de alcance Muchas personas, incluso personas ajenas a la organización, pueden sugerir una nueva función de producto en un proyecto ágil. Es posible que vea nuevas ideas para funciones de las siguientes:

» Comentarios de la comunidad de usuarios, incluidos grupos o personas a las que se les ha dado una oportunidad de obtener una vista previa del producto

» Partes interesadas del negocio que ven una nueva oportunidad o amenaza de mercado

» Ejecutivos y altos directivos que tienen conocimiento de la organización a largo plazo. estrategias y cambios nacionales

» El equipo de desarrollo, que cada día aprende más sobre el producto, y está más cerca del producto de trabajo

» El scrummaster, que puede encontrar una oportunidad mientras trabaja con departamentos o eliminando obstáculos del equipo de desarrollo

» El propietario del producto, que a menudo sabe más sobre el producto y el necesidades de las partes interesadas

Debido a que recibirá sugerencias para cambios de productos a lo largo de un proyecto ágil, desea determinar qué cambios son válidos y administrar las actualizaciones. Siga leyendo para ver cómo.

Gestionar cambios de alcance Cuando obtenga nuevos requisitos, utilice los siguientes pasos para evaluar y priorizar los requisitos y actualizar la acumulación de productos. No agregue nuevos requisitos a los sprints que ya están en progreso, a menos que el equipo de desarrollo los solicite, generalmente debido a un aumento inesperado de la capacidad.

1. Evaluar si el nuevo requisito debe ser parte del producto. el lanzamiento o el sprint haciendo algunas preguntas clave sobre el requisito: una. ¿El nuevo requisito respalda la declaración de visión del producto?

• •

En caso afirmativo, agregue el requisito a la lista de trabajos pendientes del producto y la hoja de ruta del producto.

Si no, el requisito no debería ser parte del proyecto. Puede ser un buen candidato para un proyecto independiente.

CAPITULO 12 Gestión del alcance y las adquisiciones

211

B. Si el nuevo requisito respalda la visión del producto, ¿el nuevo requisito ¿Apoya el objetivo de lanzamiento actual?

• •

En caso afirmativo, el requisito es un candidato para el plan de lanzamiento actual. En caso negativo, deje el requisito en la lista de trabajos pendientes del producto para una versión futura.

C. Si el nuevo requisito es compatible con el objetivo de lanzamiento, ¿el nuevo requisito

¿Apoya el objetivo actual del sprint?

•

En caso afirmativo y si el sprint no ha comenzado, el requisito es un candidato para el

•

Si no, el sprint ya ha comenzado o ambos, deje el requisito en la cartera de

trabajo pendiente del sprint actual.

productos para un sprint futuro.

2. Estime el esfuerzo para el nuevo requisito. El desarrollo en equipo estima el esfuerzo. Descubra cómo calcular los requisitos en el Capítulo 7.

3. Priorizar el requisito frente a otros requisitos en el producto backlog y agregue el nuevo requisito al backlog del producto, en orden de prioridad. Considera lo siguiente:

•

El propietario del producto es el que más conoce las necesidades comerciales del producto y la importancia que puede tener el nuevo requisito en relación con otros requisitos. El propietario del producto también puede comunicarse con las partes interesadas del proyecto para obtener información adicional sobre la prioridad de un requisito.

•

El equipo de desarrollo también puede tener conocimientos técnicos sobre la prioridad de un nuevo requisito. Por ejemplo, si el Requisito A y el Requisito B tienen el mismo valor comercial, pero debe completar el Requisito B para que el Requisito A sea factible, el equipo de desarrollo deberá alertar al propietario del producto. Es posible que primero deba completar el requisito B.

•

Aunque el equipo de desarrollo y las partes interesadas del proyecto pueden proporcionar información para ayudar a priorizar un requisito, es importante determinar la prioridad. en última instancia, la decisión del propietario del producto.

•

Agregar nuevos requisitos a la cartera de pedidos del producto puede significar que otros requisitos bajen en la lista de la cartera de productos. Figura 12-2

muestra la adición de un nuevo requisito en la cartera de productos. La cartera de pedidos del producto es una lista completa de todos los alcances conocidos del producto y es su herramienta más importante para gestionar el cambio de alcance en un proyecto ágil.

212

PARTE 4 Gestión ágil

FIGURA 12-2: Añadiendo un nuevo

requisito de el producto reserva.

Mantener actualizada la acumulación de productos le permitirá priorizar rápidamente y agregar nuevos requisitos. Con una cartera de productos actual, siempre comprende el alcance que queda en un proyecto. El capítulo 7 contiene más información sobre la priorización de requisitos.

Uso de artefactos ágiles para la gestión del alcance Desde la declaración de la visión hasta el plan de sprint, todos los artefactos en la gestión ágil de proyectos lo respaldan en sus esfuerzos de gestión del alcance. Descomponga o descomponga progresivamente los requisitos a medida que las características ascienden a la parte superior de la lista de prioridades. Hablamos de descomposición y elaboración progresiva de requisitos en el Capítulo 7. La Tabla 12-2 revela cómo cada artefacto ágil, incluida la acumulación de productos, contribuye al perfeccionamiento continuo del alcance.

TABLA 12-2

Artefactos ágiles y roles de administración de alcance

Artefacto

Papel en el establecimiento del alcance

Papel en el cambio de alcance

Declaración de la visión: Una definición

Utilice la declaración de visión como punto de

del objetivo final del producto. El capítulo 7

referencia para juzgar si las características

Cuando alguien introduce nuevos requisitos, esos requisitos

tiene más información sobre la declaración

pertenecen al alcance del proyecto actual.

debe respaldar la declaración de visión del producto.

de la visión. Hoja de ruta del producto: Una visión

El alcance del producto es parte del

Actualice la hoja de ruta del producto a medida

holística de las características del producto que

hoja de ruta del producto. Los requisitos a

que surjan nuevos requisitos. La hoja de ruta

crean la visión del producto. El Capítulo 7 tiene

nivel de función son buenos para

del producto proporciona una comunicación

más información sobre la hoja de ruta del

conversaciones comerciales sobre lo que significa realizar la

visual de la inclusión de la nueva función en el

producto.

proyecto.

visión del producto.

(continuado)

CAPITULO 12 Gestión del alcance y las adquisiciones

213

TABLA 12-2 ( continuado) Artefacto

Papel en el establecimiento del alcance

Papel en el cambio de alcance

Plan de lanzamiento: Un objetivo

El plan de lanzamiento muestra el

Agregue nuevas funciones que pertenecen a la

digerible a medio plazo centrado

alcance del lanzamiento actual. Es

versión actual al plan de versiones. Si la nueva

en torno a un conjunto mínimo de

posible que desee planificar sus

historia de usuario no pertenece a la versión

características comercializables.

lanzamientos por temas: grupos lógicos

actual, déjela en la lista de trabajos pendientes

El capítulo 8 tiene más información sobre

de requisitos.

del producto durante un

versión futura.

el plan de lanzamiento.

Pila de Producto: Una lista completa

Si un requisito está en el alcance de la

La cartera de productos contiene todos los cambios

de todos los alcances conocidos del

visión del producto, es parte de la cartera

de alcance. Las nuevas funciones de alta prioridad

producto. Los capítulos 7 y 8 ofrecen

de pedidos del producto.

empujan a una prioridad más baja

características en la cartera de productos.

más información sobre

Pila de Producto. Cartera de Sprint: Las historias de

El backlog del Sprint contiene las historias

El backlog del Sprint establece lo que está

usuario y las tareas en el alcance

de usuario que están dentro del alcance

permitido en el Sprint. Una vez que el equipo

del sprint actual.

del Sprint actual.

de desarrollo se compromete con el objetivo

El Capítulo 8 tiene más información sobre la

del sprint en la reunión de planificación del

acumulación de sprints.

sprint, solo el equipo de desarrollo puede modificar el backlog del sprint.

¿En qué se diferencian las adquisiciones ágiles? Otra parte de la gestión de proyectos es obtención, gestionar la compra de servicios o bienes necesarios para entregar el alcance del producto. Al igual que el alcance, las adquisiciones son parte del lado de la inversión de un proyecto. El Capítulo 2 explica que el Manifiesto Ágil valora colaboración con el cliente sobre la

negociación del contrato. Esto establece un tono importante para las relaciones de compras en proyectos ágiles. Valorar la colaboración con el cliente más que la negociación de contratos no significa que los proyectos ágiles no tengan contratos: los contratos y la negociación son fundamentales para las relaciones comerciales. Sin embargo, el Manifiesto Ágil establece la idea de que un comprador y un vendedor deben trabajar juntos para crear productos, y que la relación entre los dos es más importante que discutir sobre detalles mal informados y marcar elementos del contrato que pueden o no ser en última instancia. valioso para los clientes. Los 12 principios ágiles se aplican a las adquisiciones en proyectos ágiles. Sin embargo, los siguientes parecen destacar más a la hora de asegurar bienes y servicios para un proyecto ágil:

2. Bienvenidos los requisitos cambiantes, incluso al final del desarrollo. Procesos ágiles aprovechar el cambio para la ventaja competitiva del cliente.

214

PARTE 4 Gestión ágil

3. Entregue software que funcione con frecuencia, desde un par de semanas hasta un par de meses, con preferencia a la escala de tiempo más corta.

4. Los empresarios y los desarrolladores deben trabajar juntos a diario durante todo el proyecto.

5. Construya proyectos en torno a personas motivadas. Dales el medio ambiente y el apoyo que necesitan y confíe en ellos para hacer el trabajo.

10. La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial.

11. Las mejores arquitecturas, requisitos y diseños surgen de la autoorganización equipos.

La Tabla 12-3 destaca las diferencias entre las adquisiciones en proyectos tradicionales y las adquisiciones en proyectos ágiles.

TABLA 12-3

Gestión de adquisiciones tradicional versus ágil

Gestión de adquisiciones con enfoques tradicionales

Gestión de adquisiciones con enfoques ágiles

El director del proyecto y la organización son responsables de las actividades de adquisición.

El equipo de desarrollo autogestionado juega un papel más importante en la identificación de los artículos que necesitan compra. El scrummaster facilita la adquisición de elementos necesarios para el equipo de desarrollo.

Los contratos con proveedores de servicios a menudo incluyen disposiciones para requisitos fijos, documentación extensa, un plan de proyecto integral y otros entregables tradicionales basados en un ciclo de vida en cascada.

Los contratos para proyectos ágiles se basan en la evaluación de la funcionalidad de trabajo al final de cada sprint, no en entregables fijos y documentación que puede o no contribuir a entregar productos de calidad.

La negociación de contratos entre compradores y vendedores a

Los equipos de proyectos ágiles se centran en mantener una

veces puede ser un desafío. Debido a que la negociación es a

relación positiva y de cooperación entre compradores y vendedores

menudo una actividad estresante, puede dañar la relación entre el

desde el inicio del proceso de adquisición.

comprador y el vendedor incluso antes de que comience el trabajo en un proyecto. Cambiar de proveedor después del inicio de un proyecto puede resultar

Los proveedores proporcionan una funcionalidad completa y funcional al

costoso y llevar mucho tiempo porque un proveedor nuevo debe intentar

final de cada sprint. Si los proveedores cambian a mitad del proyecto, el

comprender la enorme cantidad de trabajo en curso del proveedor

nuevo proveedor puede comenzar inmediatamente a desarrollar

anterior.

requisitos para el próximo sprint, evitando una transición larga y costosa.

Tanto los equipos de proyectos en cascada como los ágiles están interesados en el éxito del proveedor. Los enfoques de proyectos tradicionales eran firmes en su responsabilidad por el cumplimiento, definiendo el éxito como la verificación de documentos y entregables en una lista. Los enfoques ágiles de proyectos, por el contrario, son firmes en su responsabilidad por los resultados finales, definiendo el éxito con la funcionalidad de trabajo. La siguiente sección muestra cómo gestionar las adquisiciones en proyectos ágiles.

CAPITULO 12 Gestión del alcance y las adquisiciones

215

Gestión de adquisiciones ágiles Esta sección se centra en cómo los equipos de proyectos ágiles atraviesan el proceso de adquisición: desde determinar la necesidad, seleccionar un proveedor y crear un contrato hasta trabajar con un proveedor y cerrar el contrato al final de un proyecto de comprador-vendedor.

Determinar la necesidad y seleccionar un proveedor En proyectos ágiles, las adquisiciones comienzan cuando el equipo de desarrollo decide que necesita una herramienta o los servicios de un tercero para crear el producto.

Los equipos de desarrollo de proyectos ágiles se autogestionan y se autoorganizan, y pueden tomar las decisiones sobre lo que es mejor para maximizar los resultados del desarrollo. La autogestión se aplica a todas las áreas de gestión de proyectos, incluidas las adquisiciones. Obtenga más información sobre los equipos de autogestión en los capítulos 6 y 14. Los equipos de desarrollo tienen una serie de oportunidades para considerar bienes y servicios externos:

» Etapa de visión del producto: El equipo de desarrollo puede empezar a pensar en herramientas y habilidades necesarias para ayudar a alcanzar la visión del producto. En esta etapa, puede

Sea prudente al investigar las necesidades pero no comience el proceso de compra.

» Etapa de la hoja de ruta del producto: El equipo de desarrollo comienza a ver específicos características para crear y conocer algunos de los bienes o servicios necesarios para ayudar a crear el producto.

» Planificación de lanzamiento: El equipo de desarrollo sabe más sobre el producto y puede identificar bienes o servicios específicos que ayudarán a alcanzar el próximo objetivo de lanzamiento.

» Planificación de Sprint: El equipo de desarrollo está en las trincheras del desarrollo y pueden identificar necesidades urgentes para el sprint.

» Scrum diario: Los miembros del equipo de desarrollo declaran impedimentos. Proxenetismo los bienes o servicios pueden ayudar a eliminar estos impedimentos.

» Durante todo el día: Los miembros del equipo de desarrollo se comunican con uno otro y colaborar en las tareas. Pueden surgir necesidades específicas del desarrollo conversaciones del equipo de ment.

» Reunión de revisión de Sprint: Los interesados

en el proyecto pueden identificar nuevos requisitos

para sprints futuros que justifiquen la adquisición de bienes o servicios.

» Retrospectiva de Sprint: El equipo de desarrollo puede discutir cómo tener un herramienta o servicio específico podría haber ayudado al sprint anterior y sugerir un

compra para sprints futuros.

216

PARTE 4 Gestión ágil

A veces, puede encontrar los bienes o servicios que necesita para un proyecto en su organización. Antes de considerar comprar un artículo o trabajar con proveedores, el scrum master determina si la herramienta o la persona con las habilidades para cumplir con los servicios que necesita el equipo de desarrollo está disponible internamente. Si los recursos internos o las personas pueden satisfacer las necesidades del equipo de desarrollo, el equipo scrum ahorra dinero. Una vez que el equipo de desarrollo determina que necesita un bien o servicio, el equipo de desarrollo y el scrum master trabajan con el propietario del producto para obtener los fondos necesarios. El propietario del producto es responsable de administrar el alcance del proyecto contra el presupuesto del proyecto, por lo que el propietario del producto es el responsable final de cualquier compra del proyecto. El scrum master generalmente administra la relación con el proveedor en nombre del equipo de scrum después de que se inicia la adquisición con el proveedor.

Al adquirir bienes, es posible que el equipo de desarrollo deba comparar herramientas y proveedores antes de decidirse por una compra. Al adquirir bienes, después de elegir qué comprar y dónde conseguirlo, el proceso suele ser sencillo: realizar la compra y recibir la entrega. La contratación de servicios suele ser un proceso más largo y complejo que la compra de bienes. Algunas consideraciones específicas ágiles para seleccionar un proveedor de servicios incluyen las siguientes:

» Si el proveedor puede trabajar en un entorno de proyecto ágil y, de ser así, cómo Mucha experiencia que tiene el proveedor con proyectos ágiles.

» Si el proveedor puede trabajar in situ con el equipo de desarrollo. » Si es probable que la relación entre el proveedor y el equipo scrum ser positivo y colaborador

La organización o empresa para la que trabaja puede estar sujeta a leyes y reglamentos para elegir proveedores. Las empresas involucradas en el trabajo del gobierno, por ejemplo, a menudo necesitan recopilar múltiples propuestas y ofertas de empresas para trabajos que costarán más de una cierta cantidad de dinero. Aunque tu primo o tu amigo de la universidad puede ser la persona más calificada para completar el trabajo, es posible que tengas problemas si no sigues las leyes aplicables. Consulte con el departamento legal de su empresa si tiene dudas sobre cómo agilizar los procesos inflados.

Después de elegir un proveedor de servicios, debe crear un contrato para que el proveedor pueda comenzar a trabajar. La siguiente sección explica cómo funcionan los contratos en proyectos ágiles.

CAPITULO 12 Gestión del alcance y las adquisiciones

217

Comprender los enfoques de costos

y contratos de servicios

Una vez que el equipo de desarrollo y el propietario del producto han elegido un proveedor, necesitan un contrato para garantizar un acuerdo sobre los servicios y los precios. Para iniciar el proceso de contratación, debe conocer las diferentes estructuras de precios y cómo funcionan con proyectos ágiles. Una vez que comprenda estos enfoques, verá cómo crear un contrato.

Estructuras de costos Cuando contrata servicios para un proyecto ágil, es importante conocer la diferencia entre un Precio

fijo proyecto, un horario fijo proyecto, un tiempo y materiales proyecto, y un sin exceder proyecto. Cada enfoque tiene sus propias fortalezas en un entorno ágil:

» Proyecto de precio fijo: Empieza con un presupuesto fijo. En un proyecto de precio fijo, un El proveedor trabaja en el producto y crea lanzamientos hasta que ese proveedor ha gastado

todo el dinero del presupuesto o hasta que haya entregado suficientes funciones del producto, lo que ocurra primero. Por ejemplo, si tiene un presupuesto de $ 250,000 y los costos de su proveedor son de $ 10,000 por semana, la parte del proveedor del proyecto podrá durar 25 semanas. Dentro de esas 25 semanas, el proveedor crea y lanza la mayor cantidad posible de funciones que se pueden enviar.

» Proyecto de tiempo fijo: Tiene plazos específicos. Por ejemplo, es posible que deba lanzar un producto a tiempo para la próxima temporada navideña, para un evento específico, o

para coincidir con el lanzamiento de otro producto. Con los proyectos de tiempo fijo, usted determina los costos en función del costo del equipo del proveedor durante la duración del proyecto, junto con los costos de recursos adicionales, como hardware o software.

» Proyecto de tiempo y materiales: Es más abierto que de precio fijo o proyectos de tiempo fijo. En un proyecto de tiempo y materiales, su trabajo con el proveedor dura hasta que se completa la funcionalidad suficiente del producto, sin tener en cuenta el costo total del proyecto. Usted conoce el costo total del proyecto al final del proyecto, después de que sus partes interesadas hayan determinado que el producto tiene suficientes características para llamar al proyecto completo. Por ejemplo, suponga que su proyecto cuesta $ 10,000 a la semana. Después de 20 semanas, las partes interesadas sienten que tienen suficientes características valiosas del producto, por lo que el costo de su proyecto es de $ 200,000. Si, en cambio, las partes interesadas consideran que tienen suficiente valor al final de las 10 semanas, el costo del proyecto es la mitad de esa cantidad, $ 100,000.

» Proyecto sin exceder: Es un proyecto en el que el tiempo y los materiales tienen un límite de precio fijo.

218

PARTE 4 Gestión ágil

LA FALACIA DE BAJAR EL VENDEDOR Tratar de intimidar a los proveedores para que ofrezcan el precio más bajo posible siempre es una situación en la que todos pierden. Los contratistas en industrias donde los proyectos siempre van al mejor postor tienen un dicho: Haz

una oferta baja y observa cómo crece. Es común que los proveedores ofrezcan un precio bajo durante el proceso de propuesta de un proyecto y luego agreguen varias órdenes de cambio hasta que el comprador termine pagando tanto o más de lo que pagaría por ofertas de mayor precio.

La gestión de proyectos en cascada respalda esta práctica al fijar el alcance y el precio al inicio del proyecto, cuando no se sabe casi nada sobre el proyecto. Las órdenes de cambio, y los aumentos de costos que las acompañan, son inevitables. Un mejor modelo es que el proveedor y el comprador colaboren en la definición del alcance del proyecto, dentro de los costos fijos y las restricciones del cronograma, a medida que se desarrolla el proyecto. Ambas partes pueden cosechar los beneficios de lo que aprenden durante el proyecto, y usted termina con un mejor producto lleno de la funcionalidad de mayor valor entregada e identificada al final de cada sprint. En lugar de tratar de ser un negociador duro, sea un buen colaborador.

Independientemente del enfoque de costos, en proyectos ágiles, concéntrese en completar primero las características del producto de mayor valor.

Creación de contrato Una vez que conozca el enfoque de costos del proyecto, el scrummaster podría ayudar a crear un contrato. Los contratos son acuerdos legalmente vinculantes entre compradores y vendedores que establecen expectativas sobre el trabajo y el pago.

La persona responsable de crear contratos difiere según la organización. En algunos casos, una persona del departamento legal o de adquisiciones redacta un contrato y luego le pide al scrum master que lo revise. En otros casos, ocurre lo contrario: el scrummaster redacta el contrato y hace que un experto legal o de adquisiciones lo revise. Independientemente de quién crea el contrato, el scrummaster generalmente actúa en nombre del equipo de scrum para realizar cualquiera de las siguientes acciones: Iniciar la creación del contrato, negociar los detalles del contrato y encaminar el contrato a través de las aprobaciones internas necesarias.

El enfoque ágil de valorar la colaboración sobre la negociación es clave para mantener una relación positiva entre un comprador y un vendedor al crear y negociar un contrato. El scrummaster trabaja en estrecha colaboración con el proveedor y se comunica abiertamente y a menudo con el proveedor durante todo el proceso de creación del contrato.

CAPITULO 12 Gestión del alcance y las adquisiciones

219

El Manifiesto Ágil hace no afirmar que los contratos son innecesarios. Independientemente del tamaño de su empresa u organización, es una muy buena idea crear un contrato entre su empresa y su proveedor de servicios. Saltarse el contrato puede dejar a los compradores y vendedores abiertos a la confusión acerca de las expectativas, el trabajo sin terminar e incluso los problemas legales. Como mínimo, la mayoría de los contratos tienen un lenguaje legal que describe a las partes y el trabajo, el presupuesto, el enfoque de costos y las condiciones de pago. Un contrato para un proyecto ágil también puede incluir lo siguiente:

» Una descripción del trabajo que completará el proveedor: El vendedor puede tener su propia declaración de visión del producto, que puede ser un buen punto de partida para describir el trabajo del proveedor. Es posible que desee consultar la declaración de visión del producto en el Capítulo 7.

» Enfoques ágiles que el proveedor puede utilizar: Pueden incluir

• • •

Reuniones a las que asistirá el proveedor, como el scrum diario, la planificación del sprint, la revisión del sprint y las reuniones retrospectivas del sprint.

Entrega de funcionalidad de trabajo al final de cada sprint La definición de hecho (discutido en el Capítulo 9): trabajo que se desarrolla, prueba, integra y documenta, según un acuerdo entre los propietario del producto, el equipo de desarrollo y el scrummaster

•

Artefactos que proporcionará el proveedor, como una acumulación de sprint con un gráfico

•

Personas que el proveedor tendrá en el proyecto, como el equipo de

• • •

de evolución para el estado

desarrollo. Dónde trabajará el proveedor, como in situ en su empresa Si el proveedor trabajará con su propio scrummaster y propietario de producto, o si trabajará con su scrummaster y propietario de producto. Una definición de lo que puede constituir el final del compromiso: el final de un presupuesto fijo o un tiempo fijo, o una funcionalidad de trabajo suficientemente completa.

» Para un proveedor que no utiliza un enfoque ágil, una descripción de cómo El vendedor y el trabajo del vendedor se integrarán con el del comprador.

equipo de desarrollo y sprints. Esta no es una lista comprensible; Los elementos del contrato varían según el proyecto y la organización.

Es probable que el contrato pase por algunas rondas de revisiones y cambios antes de que se complete la versión final. Una forma de comunicar claramente los cambios y mantener una buena relación con un proveedor es hablar con el proveedor cada vez que

220

PARTE 4 Gestión ágil

proponer un cambio. Si envía por correo electrónico un contrato revisado, realice un seguimiento con una llamada para explicar qué cambió y por qué, para responder cualquier pregunta y discutir cualquier idea para una revisión adicional. La discusión abierta ayuda a que el proceso del contrato sea positivo.

Si algo sustancial sobre los servicios del proveedor cambia durante las discusiones del contrato, es una buena idea que el propietario del producto o el scrum master revise esos cambios con el equipo de desarrollo. Especialmente, el equipo de desarrollo necesita conocer y proporcionar información sobre los cambios en el servicio que proporcionará el proveedor, el enfoque del proveedor y las personas del equipo del proveedor. Es muy probable que su empresa y el proveedor requieran revisiones y aprobaciones por parte de personas ajenas a sus respectivos equipos de proyecto. Las personas que revisan los contratos pueden incluir gerentes o ejecutivos de alto nivel, especialistas en adquisiciones, personal de contabilidad y abogados de la empresa. Esto difiere según la organización; el scrummaster debe asegurarse de que cualquiera que necesite leer el contrato lo haga. Ahora que comprende un poco sobre cómo seleccionar un proveedor y crear un contrato, es hora de ver cómo las adquisiciones difieren entre empresas y organizaciones.

Consideraciones organizativas para adquisiciones La forma en que su empresa se acerque a las adquisiciones marcará la diferencia en la forma en que selecciona un proveedor y crea y negocia un contrato. Debido a que las adquisiciones implican dinero y contratos legales, los procedimientos de compra y las decisiones a veces están fuera del control del equipo del proyecto. Las consideraciones para las actividades de adquisición pueden incluir lo siguiente:

» Tamaño y experiencia de la empresa u organización: Compañías más pequeñas y más nuevas Las empresas pueden tener menos formalidad, lo que permite una mayor autonomía sobre las compras. Las empresas más grandes y establecidas tienden a tener más gastos generales con las compras. Algunas empresas tienen departamentos completos con personas que trabajan a tiempo completo en adquisiciones.

» Tipo de empresa u organización: Algunas organizaciones, como el gobierno agencias, tienen procesos y documentos de adquisiciones legalmente requeridos para completo. Las empresas privadas pueden tener menos restricciones en la contratación que las empresas que cotizan en bolsa debido a las diferencias en las leyes de las empresas públicas.

» Cultura de la empresa u organización: Muchas organizaciones involucran el proyecto equipo en las decisiones de adquisiciones. Sin embargo, este no es siempre el caso, y

Los equipos de proyecto a veces se encuentran trabajando con bienes o servicios.

CAPITULO 12 Gestión del alcance y las adquisiciones

221

proveedores en los que no participaron. Algunas empresas son bastante informales y no requieren mucha documentación o proceso para la adquisición. Otras empresas requieren documentos para justificar la necesidad de un bien o servicio, propuestas formales de los vendedores y múltiples aprobaciones en cada paso de la contratación.

Si está trabajando en un proyecto ágil en una organización con procesos de adquisiciones pesados y un departamento de adquisiciones separado, debe equilibrar esos procesos con procesos ágiles. Una buena forma de garantizar procesos ágiles durante las adquisiciones es que el scrum master trabaje en estrecha colaboración con el personal del departamento de adquisiciones. En el Capítulo 6, observamos que el scrum master se asegura de que la organización siga prácticas y principios ágiles. En esta función, el scrummaster ayuda a explicar los enfoques ágiles a los especialistas en adquisiciones. El scrummaster puede encontrar útil ayudar a ajustar los requisitos de la organización para respaldar los procesos ágiles. El scrum master se asegura de que el personal de adquisiciones comprenda por qué un contrato puede necesitar adaptarse a los requisitos e iteraciones cambiantes. El scrum master marca la pauta para que el proceso de creación del contrato sea colaborativo. Si un equipo de proyecto ágil cuenta con el apoyo de la alta dirección de una organización, generalmente será más fácil incorporar enfoques ágiles en los procesos de adquisiciones de una organización. Una buena forma de obtener apoyo para trasladar enfoques ágiles a los procesos de adquisiciones de su organización es asegurarse de que la alta dirección comprenda cómo los métodos ágiles permiten que los equipos y organizaciones ágiles ofrezcan un mayor valor al cliente con más frecuencia. Los beneficios como una mejor calidad del producto, un riesgo reducido y un mayor control y visibilidad del desempeño del proyecto ayudan a constituir un argumento sólido para usar procesos ágiles cuando se trabaja con proveedores. El Capítulo 19 proporciona una lista de los beneficios clave de la gestión ágil de proyectos.

Las organizaciones con procesos de adquisición livianos o nulos presentan diferentes desafíos para un proyecto ágil, o para cualquier proyecto, para el caso. Los Scrum masters pueden encontrarse comenzando las actividades de adquisición desde cero, con pocos precedentes o apoyo. Las personas que firman contratos deben tener la autorización para tomar decisiones financieras para una empresa y, a menudo, son personas a nivel ejecutivo. Los Scrum masters y los propietarios de productos no suelen tener este tipo de autorización. En caso de duda, pregunte a su alrededor. Encuentre el signatario adecuado.

222

PARTE 4 Gestión ágil

Después de elegir un proveedor y tener un contrato firmado, el proveedor puede comenzar a trabajar. En la siguiente sección, verá que, al igual que los procesos de adquisición iniciales, trabajar con proveedores tiene consideraciones especiales para proyectos ágiles.

Trabajando con un proveedor La forma en que trabaja con un proveedor en un proyecto ágil depende en parte de la estructura del equipo de proveedores. En una situación ideal, los equipos de proveedores están completamente integrados con la organización del comprador. Los miembros del equipo del proveedor se colocan junto con el equipo scrum del comprador. Los miembros del equipo de proveedores trabajan como parte del equipo de desarrollo del comprador durante el tiempo que sea necesario.

Algunos equipos de desarrollo incluyen miembros del equipo de proveedores en sus reuniones diarias de scrum. Esta puede ser una buena manera de tener una idea de lo que hace el equipo del proveedor todos los días y de ayudar al equipo de desarrollo a trabajar más de cerca con el proveedor. También puede invitar a los proveedores a sus revisiones de sprint para mantenerlos informados sobre su progreso.

Los equipos de proveedores también pueden integrarse pero dislocarse. Si el proveedor no puede trabajar in situ en la empresa del comprador, aún puede formar parte del equipo scrum del comprador. El capítulo 14 tiene más información sobre la dinámica de equipo en proyectos ágiles.

Si no se puede colocar un proveedor, o si el proveedor es responsable de una parte separada y discreta del producto, el proveedor puede tener un equipo de scrum separado. El equipo de scrum del proveedor trabaja con el mismo programa de sprint que el equipo de scrum del comprador. Consulte los capítulos 13 y 17 para averiguar cómo trabajar con más de un equipo de scrum en un proyecto.

Si un proveedor no utiliza procesos ágiles de gestión de proyectos, el equipo del proveedor trabaja por separado del equipo scrum del comprador, fuera de los sprints y en su propio cronograma. El gerente de proyecto tradicional del proveedor ayuda a garantizar que el proveedor pueda brindar sus servicios cuando el equipo de desarrollo los necesite. Es posible que el scrummaster del comprador deba intervenir si los procesos o el cronograma del proveedor se convierten en un obstáculo o una interrupción para el equipo de desarrollo. Consulte la sección "Gestión de proyectos con equipos dislocados" en el Capítulo 14 para obtener información sobre cómo trabajar con equipos no ágiles.

Los proveedores pueden proporcionar servicios durante un período de tiempo definido o durante la vida útil del proyecto. Una vez finalizado el trabajo del proveedor, se cierra el contrato.

CAPITULO 12 Gestión del alcance y las adquisiciones

223

Cerrar un contrato Después de que un proveedor completa el trabajo en un contrato, el scrum master del comprador generalmente tiene algunas tareas finales para cerrar el contrato.

Si el proyecto finaliza normalmente, de acuerdo con los términos del contrato, es posible que el scrummaster desee reconocer la finalización del contrato por escrito. Si el proyecto es un proyecto de tiempo y materiales, el scrum master definitivamente debe finalizarlo por escrito para asegurarse de que el proveedor no siga trabajando en requisitos de menor prioridad y facturándolos. Dependiendo de la estructura organizacional y la estructura de costos del contrato, el scrum master puede ser responsable de notificar al departamento de contabilidad de la empresa del comprador después de que se complete el trabajo para garantizar que el proveedor reciba el pago adecuado.

Si el proyecto finaliza antes de que el contrato dicte el final, el scrummaster debe notificar al proveedor por escrito y seguir las instrucciones de terminación anticipada del contrato.

Termine el compromiso con una nota positiva. Si el proveedor hizo un buen trabajo, es posible que el equipo de scrum desee reconocer a las personas del equipo del proveedor en las revisiones del sprint. Todos en el proyecto podrían potencialmente volver a trabajar juntos, y un simple y sincero "gracias" puede ayudar a mantener una buena relación para proyectos futuros.

224

PARTE 4 Gestión ágil

EN ESTE CAPÍTULO

» Entender lo que es único sobre

gestión del tiempo en proyectos ágiles

» Descubrir cómo administrar el tiempo proyectos ágiles

» Reconociendo cómo es la gestión de costos diferente en proyectos ágiles » Ver cómo gestionar los costes de forma ágil proyectos

Capítulo

Gestión de tiempo y costes METRO

gestionar un proyecto. En este capítulo, verá enfoques ágiles para la gestión del tiempo y los costos. Descubre cómo utilizar el desarrollo un equipo scrum. administrar el tiempo del proyecto y controlar los costos delde proyecto son aspectos clave de

velocidad para determinar el tiempo y el costo de un proyecto dado y cómo aumentar el desarrollo velocidad para reducir el tiempo y el costo de su proyecto.

¿Qué tiene de diferente Agile TimeManagement? En términos de gestión de proyectos, hora se refiere a los procesos que garantizan la finalización oportuna del proyecto. Para comprender la gestión ágil del tiempo, es útil revisar algunos de los principios ágiles que discutimos en el Capítulo 2:

1. Nuestra máxima prioridad es satisfacer al cliente a través de un proceso temprano y continuo. entrega de software valioso.

2. Bienvenidos los requisitos cambiantes, incluso al final del desarrollo. Procesos ágiles aprovechar el cambio para la ventaja competitiva del cliente.

CAPITULO 13 Gestión de tiempo y coste

225

3. Entregue software que funcione con frecuencia, desde un par de semanas hasta un par de meses, con preferencia a la escala de tiempo más corta.

8. Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores, y los usuarios deben poder mantener un ritmo constante de forma indefinida.

La Tabla 13-1 muestra algunas de las diferencias entre la gestión del tiempo en proyectos tradicionales y en proyectos ágiles.

TABLA 13-1

Gestión del tiempo tradicional versus ágil

Gestión del tiempo con enfoques tradicionales

Gestión del tiempo con enfoques ágiles

El alcance fijo impulsa directamente la programación.

El alcance no se fija en proyectos ágiles. El tiempo se puede fijar y los equipos de desarrollo pueden crear los requisitos que se ajusten a un marco de tiempo específico.

Los gerentes de proyecto determinan el tiempo en

Durante el proyecto, los equipos de scrum evalúan y reevalúan cuánto

función de los requisitos recopilados al comienzo del

trabajo pueden completar en un período de tiempo determinado.

proyecto. Los equipos trabajan al mismo tiempo por fases en todos los

Los equipos de Scrum trabajan en sprints y primero completan

requisitos del proyecto, como la recopilación, el diseño, el

todo el trabajo en los requisitos de mayor prioridad y mayor valor.

desarrollo, las pruebas y la implementación de los requisitos. No existe ninguna diferencia de programación entre los requisitos críticos y los requisitos opcionales. Los equipos no comienzan el desarrollo real del producto

Los equipos de Scrum comienzan el desarrollo de productos en el

hasta más adelante en el proyecto, después de que se

primer sprint.

completan las fases de recopilación de requisitos y diseño. El tiempo es más variable en proyectos tradicionales.

Los sprints de tiempo limitado en proyectos ágiles se mantienen estables, lo que permite la previsibilidad.

Los gerentes de proyecto intentan predecir los horarios

Los equipos de Scrum determinan programas de largo alcance sobre el

al inicio del proyecto, cuando saben poco sobre el

desempeño real del desarrollo en los sprints. Los equipos de Scrum

producto.

ajustan las estimaciones de tiempo a lo largo del proyecto a medida que aprenden más sobre el producto y la velocidad del equipo de desarrollo, o velocidad. Encontrará más información sobre la velocidad más adelante en este capítulo.

Los proyectos de cronograma fijo y precio fijo tienen un riesgo menor con técnicas ágiles porque los equipos de desarrollo ágiles siempre brindan la funcionalidad de mayor prioridad dentro de las limitaciones de tiempo o presupuesto. Un gran beneficio de las técnicas ágiles de gestión del tiempo es que los equipos de proyectos ágiles pueden entregar productos mucho antes que los equipos de proyectos tradicionales. Por ejemplo, comenzar el desarrollo antes y completar la funcionalidad en iteraciones a menudo permite que los equipos de proyectos ágiles que trabajan con nuestra empresa, Platinum Edge, aporten valor al mercado entre un 30% y un 40% más rápido.

226

PARTE 4 Gestión ágil

La razón por la que los proyectos ágiles terminan antes no es complicada; simplemente comienzan el desarrollo antes. En la siguiente sección, descubra cómo administrar el tiempo en un proyecto ágil.

Gestión de horarios ágiles Las prácticas ágiles respaldan los horarios estratégicos y tácticos y la gestión del tiempo:

» Su planificación temprana es de naturaleza estratégica. Los requisitos de alto nivel en el La hoja de ruta del producto y la cartera de pedidos del producto pueden ayudarlo a tener una idea temprana de

el horario general. Descubra cómo crear una hoja de ruta de productos y una cartera de productos en el Capítulo 7.

» Tu planificación detallada para cada lanzamiento y en cada sprint es táctica. Leer más sobre la planificación de lanzamientos y la planificación de sprints en el Capítulo 8.

•

En la planificación del lanzamiento, puede planificar su lanzamiento para que coincida con una fecha específica, con características mínimas comercializables.

•

También puede planificar su lanzamiento con tiempo suficiente para crear un conjunto específico de características.

•

Durante cada reunión de planificación del sprint, además de seleccionar el alcance del sprint, el equipo de desarrollo estima el tiempo, en horas, para completar tareas individuales para cada uno de los requisitos de ese sprint. Utilice el backlog del sprint para administrar las asignaciones de tiempo detalladas a lo largo del sprint.

» Una vez que su proyecto esté en marcha, use la velocidad del equipo scrum (desarrollo velocidad) para ajustar su programación. Hablamos de la velocidad en la siguiente sección.

En el Capítulo 8, describimos la planificación de lanzamientos para características mínimas comercializables, el grupo más pequeño de funcionalidad de producto que proporciona suficiente valor que puede implementar y promover de manera efectiva en el mercado.

Para determinar cuánta funcionalidad puede ofrecer un equipo de desarrollo ágil en un período de tiempo determinado, debe conocer la velocidad de su equipo de desarrollo. En la siguiente sección, verá cómo medir la velocidad, cómo usar la velocidad para la línea de tiempo de un proyecto y cómo aumentar la velocidad a lo largo del proyecto.

CAPITULO 13 Gestión de tiempo y coste

227

DETERMINANDO LA DURACIÓN DE UN PROYECTO ÁGIL Algunos factores determinan la duración de los proyectos ágiles:

Fecha límite asignada: Por motivos comerciales, es posible que los equipos de proyectos ágiles deseen establecer una fecha de finalización específica. Por ejemplo, es posible que desee obtener un producto en el mercado para una temporada de compras específica o para que coincida con el momento del lanzamiento del producto de un competidor. En ese caso, estableces una fecha de finalización específica y creas la mayor cantidad posible de funciones de envío desde el inicio del proyecto hasta la fecha de finalización.

Consideraciones presupuestarias: Los equipos de proyectos ágiles también pueden tener consideraciones presupuestarias que afectan la cantidad de tiempo que durará un proyecto. Por ejemplo, si tiene un presupuesto de $ 1,600,000 y su proyecto cuesta $ 20,000 por semana para ejecutarlo, su proyecto podrá durar 80 semanas. Tendrá 80 semanas para crear y lanzar la mayor cantidad posible de funciones que se pueden enviar.

Funcionalidad completada: Los proyectos ágiles también pueden durar solo hasta que se complete la funcionalidad suficiente. Los equipos de proyecto pueden ejecutar sprints hasta que se completen los requisitos con el valor más alto y luego determinar que los requisitos de valor más bajo, los que pocas personas usarán o que no generarán muchos ingresos, no son necesarios.

Introduciendo la velocidad Una de las cosas más importantes sobre la gestión del tiempo en proyectos ágiles es el uso de la velocidad, una poderosa herramienta para pronosticar cronogramas a largo plazo. Velocidad, en términos ágiles, es la velocidad de trabajo de un equipo de desarrollo. En el Capítulo 7, describimos la medición del esfuerzo por requisitos, o historias de usuarios, en puntos de historia. La velocidad se mide por la cantidad de puntos de historias de usuario que el equipo de desarrollo completa en cada sprint. A historia del usuario es una descripción simple de un requisito de producto, que identifica qué debe cumplir un requisito y para quién. Los puntos de historia de usuario son números relativos que describen la cantidad de esfuerzo necesario para desarrollar una historia de usuario. El capítulo 8 profundiza en los detalles de la creación de historias de usuarios y la estimación del esfuerzo utilizando puntos de la historia.

Cuando conozca la velocidad del equipo de desarrollo, puede usarlo como una herramienta de planificación a largo plazo. Velocity puede ayudarlo a pronosticar cuánto tiempo tardará el equipo de scrum en completar una cierta cantidad de requisitos y cuánto puede costar un proyecto.

228

PARTE 4 Gestión ágil

En la siguiente sección, se sumerge en la velocidad como una herramienta para la gestión del tiempo. Verá cómo los cambios de alcance afectan la línea de tiempo de un proyecto ágil. También averigua cómo trabajar con varios equipos de scrum y revisa los artefactos ágiles para la gestión del tiempo.

Monitoreo y ajuste de velocidad Después de que comienza un proyecto, el equipo de scrum comienza a monitorear su velocidad. Mides la velocidad de un sprint a otro. Utiliza la velocidad para la planificación del presupuesto y el cronograma a largo plazo, así como para la planificación del sprint.

En general, las personas son buenas para planificar y estimar a corto plazo, por lo que identificar las horas para las tareas en un próximo sprint funciona bien. Al mismo tiempo, las personas suelen ser terribles para estimar tareas distantes en términos absolutos, como horas. Herramientas como la estimación relativa y la velocidad, que se basan en el rendimiento, son medidas más precisas para la planificación a más largo plazo. La velocidad es una buena herramienta de tendencias. Puede usarlo para determinar líneas de tiempo futuras porque las actividades y el tiempo de desarrollo dentro de los sprints son los mismos de un sprint a otro. La velocidad es un hecho posterior al sprint, no un objetivo. Evite intentar adivinar o comprometerse con una cierta velocidad antes de que comience un proyecto o en medio de un sprint. Solo establecerá expectativas poco realistas sobre la cantidad de trabajo que puede completar el equipo. Si la velocidad se convierte en un objetivo en lugar de una medición pasada, los equipos de scrum pueden verse tentados a exagerar los puntos de historia estimados para alcanzar ese objetivo, haciendo que la velocidad no tenga sentido. En su lugar, use la velocidad real del equipo de scrum para pronosticar cuánto tiempo más tardará y costará el proyecto. También concéntrese en aumentar la velocidad eliminando las restricciones identificadas durante el sprint y en la retrospectiva del sprint.

En la siguiente sección, verá cómo calcular la velocidad, cómo usar la velocidad para predecir el cronograma de un proyecto y cómo aumentar la velocidad de su equipo de scrum.

Calcular la velocidad Al final de cada sprint, el equipo de scrum analiza los requisitos que ha terminado y suma la cantidad de puntos de historia asociados con esos requisitos. El número total de puntos de historia completados es la velocidad del equipo de scrum para ese sprint. Después de los primeros sprints, comenzará a ver una tendencia y podrá calcular la velocidad promedio.

Debido a que la velocidad es un número, los gerentes y ejecutivos pueden verse tentados a usar la velocidad como una métrica de desempeño para compensar y comparar equipos. La velocidad no es una métrica de rendimiento, es específica del equipo y no debe usarse fuera del equipo de scrum. No es más que una herramienta de planificación que los equipos de scrum pueden usar para pronosticar el trabajo restante.

CAPITULO 13 Gestión de tiempo y coste

229

La velocidad media es el número total de puntos de historia completados, dividido por el número total de sprints completados. Por ejemplo, si la velocidad del equipo de desarrollo fue

Sprint 1 = 15 puntos Sprint 2 = 13 puntos Sprint 3 = 16 puntos Sprint 4 = 20 puntos tu número total de puntos de historia completados será 64. Tu velocidad promedio será 16: 64 puntos de historia divididos entre 4 sprints. Una vez que haya ejecutado un sprint y conozca la velocidad del equipo de scrum, puede comenzar a pronosticar el tiempo restante de su proyecto.

Usar la velocidad para estimar el cronograma del proyecto Cuando conozca su velocidad, puede determinar cuánto durará su proyecto. Sigue estos pasos:

1. Sume la cantidad de puntos de historia para los requisitos restantes en el Pila de Producto.

2. Determina la cantidad de sprints que necesitarás dividiendo la cantidad de puntos de la historia que quedan en la cartera de productos por la velocidad:

•

Para obtener una estimación pesimista, utilice la velocidad más baja que haya logrado

•

Para obtener una estimación optimista, utilice la velocidad más alta que haya logrado el

•

Para obtener una estimación más probable, use la velocidad promedio que ha logrado el

el equipo de desarrollo.

equipo de desarrollo.

Al utilizar estos datos empíricos (velocidad de producción real), el propietario de un producto puede brindar a las partes interesadas una variedad de resultados de publicación, y pueden trabajar juntos para tomar decisiones de priorización de negocios al principio del proyecto. Estas decisiones pueden incluir si es necesario crear un equipo scrum adicional para desarrollar más elementos de alcance, ajustar las fechas de lanzamiento al mercado o solicitar el presupuesto del proyecto.

3. Determine cuánto tiempo llevará completar los puntos de la historia en el acumulación de productos multiplicando la duración del sprint por el número de sprints restantes.

230

PARTE 4 Gestión ágil

Por ejemplo, suponga que

• •

Su cartera de productos restante contiene 800 puntos de historia. La velocidad de su equipo de desarrollo promedia 20 puntos de historia por sprint.

¿Cuántos sprints más necesitará su cartera de productos? Divida el número de puntos de la historia por su velocidad y obtendrá los sprints restantes. En este caso, 800/20 = 40. Si está utilizando sprints de dos semanas en su proyecto, su proyecto durará 80 semanas.

Una vez que el equipo de scrum conoce su velocidad y la cantidad de puntos de historia para los requisitos, puede usar la velocidad para determinar cuánto tiempo tomará crear un grupo determinado de requisitos. Por ejemplo:

» Puede calcular el tiempo que puede tardar un lanzamiento individual si tiene una idea del número de puntos de la historia que se incluirán en esa versión. A nivel de lanzamiento, las estimaciones de los puntos de la historia serán de un nivel más alto que en el nivel del sprint. Si está basando su tiempo de lanzamiento en la entrega de una funcionalidad específica, su fecha de lanzamiento puede cambiar a medida que refina sus historias de usuario y estimaciones a lo largo del proyecto.

» Puede calcular el tiempo que necesita para un grupo específico de historias de usuario: como todas las historias de alta prioridad o todas las historias relacionadas con un tema en particular, utilizando el número de puntos de la historia en ese grupo de historias de usuario.

La velocidad difiere de un sprint a otro. En los primeros sprints, cuando el proyecto es nuevo, el equipo de scrum normalmente tendrá una velocidad baja. A medida que avanza el proyecto, la velocidad debería aumentar porque el equipo scrum habrá aprendido más sobre el producto y habrá madurado como equipo trabajando en conjunto. Los contratiempos dentro de sprints específicos pueden disminuir temporalmente la velocidad de vez en cuando, pero los procesos ágiles como la retrospectiva del sprint pueden ayudar al equipo de scrum a garantizar que esos contratiempos sean temporales. Al comienzo de un proyecto, la velocidad variará considerablemente de un sprint a otro. La velocidad se volverá más constante con el tiempo, siempre que los miembros del equipo de scrum sigan siendo consistentes. Los equipos de Scrum también pueden aumentar su velocidad a través de proyectos ágiles, haciendo que los proyectos sean más cortos y menos costosos. En la siguiente sección, encontrará formas de aumentar la velocidad en cada sprint consecutivo.

CAPITULO 13 Gestión de tiempo y coste

231

Velocidad creciente Si un equipo de scrum tiene una acumulación de productos con 800 puntos de historia y una velocidad promedio de 20 puntos de historia, el proyecto durará 40 sprints: 80 semanas, con sprints de 2 semanas. Pero, ¿y si el equipo de scrum pudiera aumentar su velocidad?

» Aumentar la velocidad promedio a 23 puntos de historia por sprint significaría 34.78 sprints. Si redondea eso a 35 sprints, el mismo proyecto últimas 70 semanas.

» Una velocidad promedio de 26 tomaría alrededor de 31 sprints, o 62 semanas. » Una velocidad promedio de 31 tomaría alrededor de 26 sprints, o 52 semanas. Como puede ver, aumentar la velocidad puede ahorrar mucho tiempo y, en consecuencia, dinero. La velocidad puede aumentar naturalmente con cada sprint, a medida que el equipo de scrum encuentra su ritmo de trabajo conjunto en el proyecto. Sin embargo, existen oportunidades para aumentar también la velocidad en proyectos ágiles, más allá de los aumentos comunes que vienen con el tiempo. Todos en un equipo de scrum juegan un papel importante para ayudar a obtener una mayor velocidad con cada sprint sucesivo:

» Eliminar obstáculos del proyecto: Una forma de aumentar la velocidad es rápidamente eliminar obstáculos o obstáculos del proyecto. Los obstáculos son cualquier cosa que impide que un miembro del equipo de desarrollo trabaje a plena capacidad. Por definición, los obstáculos pueden reducir la velocidad. Despejar los obstáculos tan pronto como surgen aumenta la velocidad al ayudar al equipo de scrum a ser completamente funcional y productivo. Obtenga más información sobre cómo eliminar los impedimentos del proyecto en el Capítulo 9.

» Evite los obstáculos del proyecto: La mejor manera de aumentar la velocidad es estratégicamente en primer lugar, cree formas de evitar obstáculos. Sabiendo o aprendiendo

acerca de los procesos y las necesidades específicas de los grupos con los que trabajará su equipo, puede evitar los obstáculos antes de que surjan.

» Elimina distracciones: Otra forma de aumentar la velocidad es para el scrum.

master para proteger al equipo de desarrollo de las distracciones. Asegurándose las personas no solicitan trabajo fuera del objetivo del sprint del equipo de desarrollo, incluso las tareas que pueden tomar una pequeña cantidad de tiempo, el scrum master podrá ayudar a mantener al equipo de desarrollo enfocado en el sprint. Tener un scrummaster dedicado que ayude continuamente a eliminar las limitaciones del equipo scrum resultará en un aumento continuo de la velocidad. El valor de un scrummaster dedicado es cuantificable.

232

PARTE 4 Gestión ágil

PREVENCIÓN DE BLOQUES Un equipo de desarrollo con el que trabajamos necesitaba comentarios del departamento legal de su empresa, pero no había podido obtener una respuesta por correo electrónico o correo de voz. En una reunión diaria, uno de los miembros del equipo de desarrollo afirmó que esta falta de respuesta era un obstáculo. Después de que terminó el scrummeeting, el scrummaster se acercó al departamento legal y encontró a la persona adecuada con quien trabajar. Después de hablar con esa persona, el scrummaster descubrió que su correo electrónico estaba constantemente inundado de solicitudes y que su correo de voz no era mucho mejor.

El scrummaster luego sugirió un proceso para futuras solicitudes legales: en el futuro, los miembros del equipo de desarrollo podrían dirigirse al departamento legal con solicitudes y obtener comentarios allí mismo, en persona, de inmediato. El nuevo proceso tomó solo unos minutos, pero ahorró días en la respuesta del departamento legal, evitando de manera efectiva obstáculos similares en el futuro. Encontrar formas de prevenir obstáculos ayuda a aumentar la velocidad del equipo de scrum.

» Solicite aportes del equipo: Finalmente, todos en el equipo scrum pueden proporcionar ideas para aumentar la velocidad en la reunión retrospectiva de sprint. La

El equipo de desarrollo es el que mejor conoce su trabajo y puede tener ideas sobre cómo mejorar la producción. El propietario del producto puede tener conocimientos sobre los requisitos que pueden ayudar al equipo de desarrollo a trabajar más rápido. El scrummaster habrá visto obstáculos repetitivos y puede discutir cómo prevenirlos en primer lugar.

Aumentar la velocidad es valioso, pero recuerde que es posible que no vea cambios de la noche a la mañana. La velocidad del equipo de scrum a menudo tiene un patrón de aumentos lentos, algunos saltos de velocidad grandes, un período plano y luego aumentos lentos nuevamente a medida que el equipo de scrum identifica, experimenta y corrige las limitaciones que lo están frenando.

Consistencia para velocidad útil Debido a que la velocidad es una medida del trabajo completado en términos de puntos de la historia, es un indicador y un predictor precisos del desempeño del proyecto solo cuando se utilizan las siguientes prácticas:

» Longitudes de sprint consistentes: Cada sprint debe durar la misma cantidad de tiempo a lo largo de la vida del proyecto. Si la duración del sprint es diferente, la cantidad de El trabajo que el equipo de desarrollo puede completar en cada sprint será diferente y la velocidad no será relevante para predecir el tiempo restante del proyecto.

CAPITULO 13 Gestión de tiempo y coste

233

» Horas de trabajo constantes: Los miembros del equipo de desarrollo individual deben trabajar la misma cantidad de horas en cada sprint. Si Sandy trabaja 45 horas en una

sprint, 23 en otro y 68 en otro, naturalmente completará una cantidad diferente de trabajo de un sprint a otro. Sin embargo, si Sandy siempre trabaja la misma cantidad de horas en un sprint, su velocidad será comparable entre sprints.

» Miembros del equipo de desarrollo consistentes: Diferentes personas trabajan en diferentes tarifas. Tom podría trabajar más rápido que Bob, por lo que si Tom trabaja en un sprint y Bob trabaja en el siguiente, la velocidad del sprint de Tom no será una buena predicción para el sprint de Bob. Cuando la duración de los sprints, las horas de trabajo y los miembros del equipo se mantienen constantes a lo largo de un proyecto, puede usar la velocidad para saber realmente si la velocidad de desarrollo aumenta o disminuye y para estimar con precisión la línea de tiempo del proyecto.

El rendimiento no se escala linealmente con el tiempo disponible. Por ejemplo, si tiene sprints de dos semanas con 20 puntos de historia por sprint, ir a sprints de tres semanas no garantiza 30 puntos de historia. La nueva longitud del sprint generará un cambio desconocido en la velocidad. Aunque cambiar la duración de los sprints introduce una variación en la velocidad y las proyecciones de un equipo de scrum, rara vez desalentamos a los equipos de scrum de reducir la duración de sus sprints (de tres semanas a dos, o de dos semanas a una) porque los ciclos de retroalimentación más cortos permiten que los equipos de scrum reaccionen más rápido a retroalimentación de los clientes, lo que les permite ofrecer más valor a sus clientes. Sin embargo, cambiar la duración del sprint siempre viene con la misma precaución: la velocidad tampoco se escala linealmente en la dirección opuesta, y los equipos de scrum tendrán que establecer una nueva velocidad para su sprint más corto antes de que sus proyecciones vuelvan a ser confiables. Cuando sabe cómo medir con precisión y aumentar la velocidad, tiene una herramienta poderosa para administrar el tiempo y el costo de un proyecto. En la siguiente sección, hablamos sobre cómo administrar una línea de tiempo en un entorno ágil en constante cambio.

Gestión de cambios de alcance desde una perspectiva temporal Los equipos de proyectos ágiles dan la bienvenida a los requisitos cambiantes en cualquier momento a lo largo de un proyecto, lo que significa que el alcance del proyecto refleja las prioridades reales del negocio. Es el "darwinismo de requisitos" en su estado más puro: los equipos de desarrollo completan primero los requisitos de máxima prioridad. Las longitudes de sprint fijas obligan a eliminar requisitos que suenan como buenas ideas en teoría, pero que nunca ganan el concurso "ya sea este requisito o ese requisito".

234

PARTE 4 Gestión ágil

Los nuevos requisitos pueden no tener ningún efecto en el cronograma de un proyecto; solo tienes que priorizar. Al trabajar con las partes interesadas del proyecto, el propietario del producto puede decidir desarrollar solo los requisitos que se ajustarán a una determinada ventana de tiempo o presupuesto. La clasificación de prioridad de los elementos en la cartera de productos determina qué requisitos son lo suficientemente importantes para desarrollar. El equipo de scrum puede garantizar el cumplimiento de los requisitos de mayor prioridad. Los requisitos de menor prioridad pueden ser parte de otro proyecto o es posible que nunca se creen.

En el Capítulo 12, discutimos cómo administrar los cambios de alcance con la acumulación de productos. Cuando agrega un nuevo requisito a un proyecto ágil, prioriza ese requisito frente a todos los demás elementos de su cartera de productos y agrega el nuevo artículo en el lugar apropiado en la cartera de productos. Esto puede reducir la prioridad de otros elementos de la cartera de productos. Si mantiene su cartera de productos y sus estimaciones actualizadas a medida que surgen nuevos requisitos, siempre tendrá una buena idea del cronograma del proyecto, incluso con un alcance en constante cambio. Por otro lado, el propietario del producto y las partes interesadas del proyecto pueden determinar que todos los requisitos de la cartera de pedidos del producto, incluidos los nuevos requisitos, son lo suficientemente útiles como para incluirlos en el proyecto. En este caso, extiende la fecha de finalización del proyecto para acomodar el alcance adicional, aumentar la velocidad o dividir el alcance del proyecto entre varios equipos de scrum que trabajarán simultáneamente en diferentes características del producto. Obtenga más información sobre los proyectos de varios equipos en el Capítulo 17.

Los equipos de proyecto a menudo toman decisiones de programación sobre los requisitos de menor prioridad hacia el final de un proyecto. Las razones de estas decisiones justo a tiempo se deben a que las demandas del mercado de elementos de alcance específicos cambian y también a que la velocidad tiende a aumentar a medida que el equipo de desarrollo se pone en ritmo. Los cambios en la velocidad aumentan sus predicciones sobre cuántos elementos de la cartera de productos puede completar el equipo de desarrollo en un período de tiempo determinado. En proyectos ágiles, esperas hasta el último momento responsable, cuando sabes más sobre la pregunta en cuestión, para tomar decisiones con las que estarás comprometido durante el resto del proyecto.

La siguiente sección le muestra cómo trabajar con más de un equipo de scrum en un proyecto.

Gestionar el tiempo mediante el uso de varios equipos Para proyectos más grandes, varios equipos de scrum que trabajan en paralelo pueden completar un proyecto en un período de tiempo más corto.

CAPITULO 13 Gestión de tiempo y coste

235

Es posible que desee crear un proyecto con varios equipos de scrum si

» Su proyecto es muy grande y requerirá más de un desarrollo. equipo de nueve o menos miembros del equipo de desarrollo para completar.

» Su proyecto tiene una fecha de finalización específica que debe cumplir, y el scrum La velocidad del equipo no será suficiente para completar los requisitos más valiosos. antes de esa fecha de finalización.

El tamaño ideal para un equipo de desarrollo en un proyecto ágil es de no menos de tres y no más de nueve personas. Grupos de más de nueve personas comienzan a construir silos y la cantidad de canales de comunicación dificulta la autogestión. (En algunos casos, hemos visto estos problemas en equipos de menos de nueve). Cuando el desarrollo de su producto requiere más miembros del equipo de desarrollo de los que pueden comunicarse de manera efectiva, puede ser el momento de considerar el uso de varios equipos scrum. Si tiene varios equipos de scrum en un proyecto, divida el trabajo en temas o grupos lógicos de características de productos para cada equipo. Sin embargo, antes de apresurarse a eso, debe considerar el alcance general de los temas y la relación entre ellos. El trabajo debe estar lo suficientemente separado para permitir que los equipos operen de manera independiente, con la menor cantidad de interdependencias posibles. En el Capítulo 17, le mostramos varias técnicas para escalar el trabajo de desarrollo de productos en varios equipos.

Uso de artefactos ágiles para la gestión del tiempo La hoja de ruta del producto, la acumulación de productos, el plan de lanzamiento y la acumulación de sprints juegan un papel en la gestión del tiempo. La Tabla 13-2 muestra cómo cada artefacto contribuye a la administración del tiempo.

En las siguientes secciones, se sumerge en la gestión de costes para proyectos ágiles. La gestión de costes está directamente relacionada con la gestión del tiempo. Compara los enfoques tradicionales de la gestión de costes con los de proyectos ágiles. Descubrirá cómo estimar los costos en un proyecto ágil y cómo usar la velocidad para pronosticar su presupuesto a largo plazo.

236

PARTE 4 Gestión ágil

TABLA 13-2

Artefactos ágiles y gestión del tiempo

Artefacto

Papel en la gestión del tiempo

Hoja de ruta del producto: La hoja de ruta del producto es

La hoja de ruta del producto es una mirada estratégica a las prioridades

una visión holística y priorizada de los requisitos de alto

generales del proyecto. Aunque la hoja de ruta del producto

nivel que respaldan la visión del producto. Obtenga más

probablemente no tendrá fechas específicas, tendrá rangos de fechas

información sobre la hoja de ruta del producto en el

generales para grupos de funcionalidad y permitirá un marco inicial para

Capítulo 7.

llevar el producto al mercado.

Pila de Producto: La cartera de productos es una lista

Los requisitos en la cartera de pedidos de su producto tendrán puntos de historia

completa de todos los requisitos de productos conocidos

estimados. Una vez que conozca la velocidad de su equipo de desarrollo, puede

actualmente. Obtenga más información sobre la acumulación

usar el número total de puntos de la historia en la cartera de pedidos del

de productos en los capítulos 7 y 8.

producto para determinar una fecha de finalización del proyecto realista.

Plan de lanzamiento: El plan de lanzamiento contiene un

El plan de lanzamiento tendrá una fecha de lanzamiento prevista para un

cronograma de lanzamiento para un conjunto mínimo de

objetivo específico respaldado por un conjunto mínimo de

requisitos. Obtenga más información sobre el plan de lanzamiento

funcionalidades. Los equipos de Scrum planifican y trabajan solo en un

en el Capítulo 8.

lanzamiento a la vez.

Cartera de Sprint: El backlog del sprint contiene los

Durante su reunión de planificación de sprints, estima las tareas

requisitos y las tareas del sprint actual. Obtenga más

individuales en el trabajo pendiente en horas. Al final de cada sprint,

información sobre la acumulación de sprints en el

tomas el total de puntos de historia completados del backlog del sprint

Capítulo 8.

para calcular la velocidad de tu equipo de desarrollo para ese sprint.

¿Qué tiene de diferente la gestión ágil de costes? Costo es el presupuesto financiero de un proyecto. Cuando trabaja en un proyecto ágil, se centra en el valor, explota el poder del cambio y busca la simplicidad. Los principios ágiles 1, 2 y 10 establecen lo siguiente:

1. Nuestra máxima prioridad es satisfacer al cliente a través de un proceso temprano y continuo. entrega de software valioso.

2. Bienvenidos los requisitos cambiantes, incluso al final del desarrollo. Procesos ágiles aprovechar el cambio para la ventaja competitiva del cliente.

10. La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial. Debido a este énfasis en el valor, el cambio y la simplicidad, los proyectos ágiles tienen un enfoque diferente para la gestión del presupuesto y los costos que los proyectos tradicionales. La tabla 13-3 destaca algunas de las diferencias.

CAPITULO 13 Gestión de tiempo y coste

237

TABLA 13-3

Gestión de costes tradicional versus ágil

Gestión de costes con enfoques tradicionales

Gestión de costes con enfoques ágiles

El costo, como el tiempo, se basa en un alcance fijo.

El cronograma del proyecto, no el alcance, tiene el mayor efecto sobre el costo. Puede comenzar con un costo fijo y una cantidad fija de tiempo, y luego completar los requisitos como una funcionalidad potencialmente enviable que se ajuste a su presupuesto y cronograma.

Las organizaciones estiman los costos del proyecto y financian

Los propietarios de productos a menudo obtienen la financiación del proyecto una vez

los proyectos antes de que comience el proyecto.

finalizada la etapa de la hoja de ruta del producto. Algunas organizaciones incluso financian proyectos ágiles de uno en uno; Los propietarios de productos obtendrán la financiación después de completar la planificación de lanzamiento para cada lanzamiento.

Los nuevos requisitos implican mayores costos. Debido a

Los equipos de proyecto pueden reemplazar los requisitos de menor

que los gerentes de proyecto estiman los costos en

prioridad con nuevos requisitos de alta prioridad de tamaño equivalente sin

función de lo que saben al inicio del proyecto, que es muy

afectar el tiempo o el costo.

poco, los costos se exceden

son comunes. La hinchazón del alcance (consulte el Capítulo 12)

Debido a que los equipos de desarrollo ágiles completan los requisitos por

desperdicia grandes cantidades de dinero en funciones que

prioridad, se concentran en crear solo las características del producto que los

la gente simplemente no usa.

usuarios necesitan, ya sea que esas características se agreguen el día 1 o el día 100 del proyecto.

Los proyectos no pueden generar ingresos hasta que el

Los equipos de proyectos pueden lanzar la funcionalidad funcional y generadora de

proyecto esté completo.

ingresos con anticipación, creando un proyecto autofinanciado.

Cuando los costos aumentan, los patrocinadores del proyecto a veces se encuentran en una especie de situación de rehenes. Un enfoque en cascada no requiere ninguna funcionalidad completa del producto hasta el final de un proyecto. Debido a que los enfoques tradicionales de desarrollo son propuestas de todo o nada, si los costos aumentan y las partes interesadas no pagan más por el producto, no obtendrán alguna requisitos terminados. El producto incompleto se convierte en rehén secuestrado; Pague más o no obtenga nada. En las siguientes secciones, encontrará información sobre los enfoques de costos en proyectos ágiles, cómo estimar los costos de un proyecto ágil, cómo controlar su presupuesto y cómo reducir los costos.

Gestión de presupuestos ágiles En proyectos ágiles, el costo es principalmente una expresión directa del tiempo del proyecto. Debido a que los equipos de scrum consisten en miembros del equipo dedicados a tiempo completo, tienen un costo de equipo establecido, generalmente expresado como una tarifa fija o por hora por persona, que debería ser el mismo para cada sprint. Duraciones de sprint, horas de trabajo y miembros del equipo consistentes

238

PARTE 4 Gestión ágil

le permiten utilizar con precisión la velocidad para predecir la velocidad de desarrollo. Una vez que use la velocidad para determinar cuántos sprints tomará su proyecto, es decir, cuánto tiempo durará su proyecto, puede saber cuánto costará su equipo de scrum para todo el proyecto. El costo del proyecto también incluye el costo de recursos como hardware, software, licencias y cualquier otro suministro que pueda necesitar para completar su proyecto.

En esta sección, descubrirá cómo crear un presupuesto inicial y cómo usar la velocidad del equipo scrum para determinar los costos a largo plazo.

Creando un presupuesto inicial Para crear el presupuesto de su proyecto, necesita conocer el costo de su equipo de scrum, por sprint, y el costo de cualquier recurso adicional que necesite para completar el proyecto.

Por lo general, calcula el costo de su equipo de scrum utilizando una tarifa por hora para cada miembro del equipo. Multiplique la tarifa por hora de cada miembro del equipo por sus horas disponibles por semana por la cantidad de semanas en sus sprints para calcular el costo por sprint de su equipo scrum. La Tabla 13-4 muestra un presupuesto de muestra para un equipo de scrum (el propietario del producto, cinco miembros del equipo de desarrollo y el maestro de scrum) para un sprint de dos semanas.

TABLA 13-4

Ejemplo de ScrumTeamBudget para un Sprint de dos semanas

Miembro del equipo

Tarifa por hora

Horas semanales

Costo semanal

Coste de Sprint (2 semanas)

Don

$ 80

$ 3,200

$ 6,400

Peggy

$ 70

$ 2,800

$ 5,600

Beto

$ 70

$ 2,800

$ 5,600

Miguel

$ 65

$ 2,600

$ 5.200

Joan

$ 85

$ 3,400

$ 6,800

Tommy

$ 75

$ 3,000

$ 6.000

Pete

$ 55

$ 2,200

$ 4.400

280

$ 20 000

$ 40 000

Total

CAPITULO 13 Gestión de tiempo y coste

239

El costo de los recursos adicionales variará según el proyecto. Además de los costos de los miembros del equipo scrum, tenga en cuenta lo siguiente al determinar los costos de su proyecto:

» Costos de hardware

» Software, incluidos los costos de licencia » Costos de hospedaje

» Costos de formación

» Gastos de equipo varios, como suministros de oficina adicionales, equipo almuerzos, gastos de viaje y el precio de las herramientas que pueda necesitar

Estos costos pueden ser costos únicos, en lugar de costos por sprint. Sugerimos separar estos costos en su presupuesto; como ve en la siguiente sección, necesita el costo de cada sprint para determinar el costo del proyecto. (Para mantener los cálculos simples a lo largo de este capítulo, asumimos que el costo del proyecto de $ 40,000 incluye los costos de los miembros del equipo scrum, así como cualquier recurso adicional, como los que acabamos de enumerar).

Recursos normalmente se refieren a objetos inanimados, no a personas. Es necesario gestionar los recursos. Cuando hable sobre los recursos de un proyecto, refiérase a las personas como miembros

del equipo, talento, o solo personas. Este problema puede parecer menor, pero cuanto más se centre en las personas y las interacciones que en los procesos y las herramientas, incluso en los detalles, más cambiará su forma de pensar para pensar y ser más ágil.

Creación de un proyecto autofinanciado Un gran beneficio de los proyectos ágiles es la capacidad de tener un proyecto autofinanciado. Los equipos de Scrum brindan funcionalidad de trabajo al final de cada sprint y ponen esa funcionalidad a disposición del mercado al final de cada ciclo de lanzamiento. Si su producto es un producto que genera ingresos, podría utilizar los ingresos de los primeros lanzamientos para ayudar a financiar el resto de su proyecto. Por ejemplo, un sitio web de comercio electrónico puede generar $ 15,000 al mes en ventas después del primer lanzamiento, $ 40,000 al mes después del segundo lanzamiento, y así sucesivamente. Las tablas 13-5 y 13-6 comparan los ingresos de un proyecto tradicional de muestra con los ingresos de un proyecto ágil autofinanciado.

240

PARTE 4 Gestión ágil

TABLA 13-5

Ingresos de un proyecto tradicional con un lanzamiento final después de seis meses Mes

Ingresos generados

Ingresos totales del proyecto

enero

febrero

marcha

abril

Mayo

junio

mes de julio

$ 100,000

En la Tabla 13-5, el proyecto generó $ 100,000 en ingresos después de seis meses de desarrollo. Ahora compare el ingreso de la tabla 13-5 con el ingreso generado en la tabla 13-6.

TABLA 13-6

Ingresos de un proyecto con lanzamientos mensuales y un lanzamiento final después de seis meses Mes / lanzamiento

Ingresos generados

Ingresos totales del proyecto

enero

febrero

$ 15 000

marcha

$ 25 000

$ 40 000

abril

$ 40 000

$ 80 000

Mayo

$ 70 000

$ 150 000

junio

$ 80 000

$ 230 000

mes de julio

$ 100,000

$ 330 000

En la Tabla 13-6, el proyecto generó ingresos con el primer lanzamiento. Al final de los seis meses, el proyecto había generado $ 330 000, $ 230 000 más que el proyecto de la Tabla 13-5.

CAPITULO 13 Gestión de tiempo y coste

241

Usar la velocidad para determinar los costos a largo plazo La sección "Uso de la velocidad para estimar la línea de tiempo del proyecto", anteriormente en este capítulo, le muestra cómo determinar cuánto tiempo tomará un proyecto, usando la velocidad del equipo scrum y los puntos restantes de la historia en la cartera de pedidos del producto. Puede utilizar la misma información para determinar el costo del proyecto o de su versión actual. Una vez que conozca la velocidad del equipo de scrum, puede calcular el costo para el resto del proyecto. En el ejemplo de velocidad anterior en este capítulo, donde la velocidad de su equipo de scrum promedia 16 puntos de historia por sprint, su cartera de productos contiene 800 puntos de historia y sus sprints son de 2 semanas de duración, su proyecto tomará 50 sprints, o 100 semanas, para completarse. .

Para determinar el costo restante de su proyecto, multiplique el costo por sprint por la cantidad de sprints que el equipo de scrum necesita para completar la cartera de productos. Si el costo de su equipo de scrum es de $ 40,000 por sprint y le quedan 50 sprints, el costo restante de su proyecto será de $ 2,000,000. En las siguientes secciones, encontrará diferentes formas de reducir los costos de su proyecto.

Reducir el costo al aumentar la velocidad En la sección de administración del tiempo de este capítulo, hablamos sobre cómo aumentar la velocidad del equipo scrum. Usando los ejemplos de la sección anterior, y los $ 40,000 por sprint de dos semanas de la Tabla 13-4, aumentar la velocidad podría reducir sus costos, de la siguiente manera:

» Si el equipo de scrum aumenta su velocidad promedio de 16 a 20 puntos de historia por sprint

• •

Tendrás 40 sprints restantes. Su proyecto costará $ 1.6 millones, ahorrándole más de $ 400,000.

» Si el equipo de scrum aumenta su velocidad a 23 puntos de historia

• •

242

Tendrás 35 sprints restantes. Su proyecto costará $ 1.4 millones, lo que le permitirá ahorrar $ 200,000 adicionales.

PARTE 4 Gestión ágil

» Si el equipo de scrum aumenta su velocidad a 26 puntos de historia

• •

Tendrás 31 sprints restantes. Su proyecto costará $ 1.24 millones, un ahorro adicional de $ 160,000.

Como puede ver, aumentar la velocidad del equipo scrum eliminando los impedimentos puede proporcionar ahorros reales en los costos del proyecto. Vea cómo ayudar al equipo de scrum a ser más productivo en la sección "Aumento de la velocidad", anteriormente en este capítulo.

Reducir el costo al reducir el tiempo También puede reducir los costos de su proyecto al no completar los requisitos de menor prioridad, lo que reduce la cantidad de sprints que necesita. Debido a que la funcionalidad completa se entrega con cada sprint en un proyecto ágil, las partes interesadas del proyecto pueden tomar una decisión comercial para finalizar un proyecto cuando el costo del desarrollo futuro es mayor que el valor de ese desarrollo futuro. Los interesados en el proyecto pueden utilizar el presupuesto restante del proyecto anterior para iniciar un proyecto nuevo y más valioso. La práctica de mover el presupuesto de un proyecto a otro se llama redistribución de capital. Para determinar el final de un proyecto en función del costo, debe saber

» El valor comercial (V) de los requisitos restantes en la cartera de productos. » El costo real (CA) del trabajo que se necesitará para completar los requisitos en la cartera de productos

» El costo de oportunidad (OC), o el valor de tener el trabajo en equipo scrum en un nuevo proyecto

Cuando V <AC + OC, el proyecto puede detenerse porque el costo que incurrirá en el proyecto será mayor que el valor que recibirá del proyecto. Considere este ejemplo: una empresa está ejecutando un proyecto ágil y

» Las funciones restantes en la cartera de productos generarán $ 100,000 en ingresos (V = $ 100.000).

» Se necesitarán tres sprints con un costo de $ 40,000 por sprint para crear esos características, un total de $ 120,000 (AC = $ 120,000).

» El equipo de scrum podría estar trabajando en un nuevo proyecto que generaría $ 150,000 después de tres sprints, menos el costo del equipo scrum (OC = $ 150,000).

» El valor del proyecto, $ 100,000, es menor que los costos reales más la oportunidad. costos, o $ 270,000. Este sería un buen momento para finalizar el proyecto.

CAPITULO 13 Gestión de tiempo y coste

243

La oportunidad de redistribución de capital a veces surge en emergencias, cuando una organización necesita que los miembros del equipo scrum pausen un proyecto para un trabajo crítico no planificado. Los patrocinadores de proyectos a veces evalúan el valor restante y el costo de un proyecto antes de reiniciar un proyecto en pausa. Pausar un proyecto puede resultar caro. Los costos asociados con la desmovilización y la removilización (guardar el trabajo en progreso, documentar el estado actual, informar a los miembros del equipo del proyecto en pausa, reequipar el equipo para el nuevo proyecto, informar a los miembros del equipo sobre el nuevo proyecto, aprender las nuevas habilidades requeridas en el nuevo proyecto) pueden ser significativos y deben ser evaluado antes de tomar la decisión de pausar un proyecto que puede necesitar ser removilizado nuevamente en el futuro. V <AC + OC puede ayudar con esta decisión. Los patrocinadores del proyecto también pueden comparar el valor de la acumulación del producto con los costos de desarrollo restantes a lo largo del proyecto, de modo que sepan el momento adecuado para finalizar el proyecto y recibir el mayor valor.

Determinar otros costos De manera similar a la administración del tiempo, después de conocer la velocidad del equipo de scrum, puede determinar el costo de cualquier cosa en el proyecto. Por ejemplo:

» Puede calcular el costo de una versión individual si tiene una idea del número de puntos de la historia que se incluirán en esa versión. Divida el número de puntos de la historia en el lanzamiento por la velocidad del equipo de scrum para determinar cuántos sprints serán necesarios. En el lanzamiento, las estimaciones de los puntos de su historia serán de más alto nivel que en el sprint, por lo que sus costos pueden cambiar, dependiendo de cómo determine su fecha de lanzamiento.

» Puede calcular el costo de un grupo específico de historias de usuario, como todas historias de alta prioridad o todas las historias relacionadas con un tema en particular, utilizando el número de puntos de la historia en ese grupo de historias de usuario.

Uso de artefactos ágiles para la gestión de costes Puede utilizar la hoja de ruta del producto, el plan de lanzamiento y la acumulación de sprints para la gestión de costes. La Tabla 13-2 muestra cómo cada artefacto le ayuda a medir y evaluar el tiempo y los costos del proyecto. Los pronósticos de tiempo y costo basados en el desempeño real del equipo de desarrollo son más precisos que los pronósticos basados en la esperanza.

244

PARTE 4 Gestión ágil

EN ESTE CAPÍTULO » Reconociendo lo que hace que un equipo sea ágil

dinámica diferente » Descubriendo cómo trabajar con ágil equipos

» Entender cómo la comunicación difiere en proyectos ágiles

» Viendo cómo funciona la comunicación proyectos ágiles

Capítulo

Equipo directivo

Dynamicsand Comunicación

ment. En este capítulo, conocerá los enfoques tradicionales y ágiles de los equipos de Ves cómo un alto las personas Laproyecto dinámica ydelalacomunicación. comunicación y la comunicación son valor partesen importantes de la gestión de proyectos.

e interacciones hacen que los equipos de proyectos ágiles sean excelentes equipos para trabajar. Tu tambien encuentras

Descubra cómo la comunicación cara a cara ayuda a que los proyectos ágiles sean exitosos.

¿Qué tiene de diferente Agile TeamDynamics? ¿Qué hace que un equipo de proyecto en un proyecto ágil sea único? La razón principal por la que los equipos ágiles son diferentes de los equipos tradicionales es la dinámica de su equipo. El Manifiesto Ágil (consulte el Capítulo 2) establece el marco de trabajo de los miembros del equipo del proyecto ágil

CAPITULO 14 Gestión de la dinámica de equipo y la comunicación

245

juntos: El primer elemento de valor del manifiesto es individuos e interacciones sobre procesos y herramientas.

Los siguientes principios ágiles, también del Capítulo 2, apoyan la valoración de las personas en el equipo del proyecto y cómo trabajan juntas:

4. Los empresarios y los desarrolladores deben trabajar juntos a diario durante todo el proyecto.

5. Construya proyectos en torno a personas motivadas. Dales el medio ambiente y el apoyo que necesitan y confíe en ellos para hacer el trabajo.

8. Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores, y los usuarios deben poder mantener un ritmo constante de forma indefinida.

11. Las mejores arquitecturas, requisitos y diseños surgen de la autoorganización equipos.

12. A intervalos regulares, el equipo reflexiona sobre cómo volverse más eficaz, luego sintoniza y ajusta su comportamiento en consecuencia.

Los principios ágiles se aplican a muchas áreas de gestión de proyectos diferentes. Verá algunos de estos principios repetidos en diferentes capítulos de este libro. En proyectos ágiles, el equipo de desarrollo contiene a las personas que hacen el trabajo físico de crear el producto. El equipo de scrum contiene el equipo de desarrollo, además del propietario del producto y el scrummaster. El equipo del proyecto es el equipo scrum y la parte interesada del proyecto. Todos en el equipo de scrum tienen responsabilidades relacionadas con la autogestión. La Tabla 14-1 muestra algunas diferencias entre la gestión de equipos en proyectos tradicionales y en proyectos ágiles. Evitamos el término recursos al referir personas. Hacer referencia a personas y equipos con el mismo término es el comienzo de pensar en los miembros del equipo como objetos intercambiables que se pueden intercambiar hacia adentro y hacia afuera. Los recursos son cosas utilitarias y prescindibles. Las personas de su equipo de proyecto son seres humanos, con emociones, ideas y prioridades dentro y fuera del proyecto. Las personas pueden aprender, crear y crecer a lo largo del proyecto. Respetar a los demás miembros del equipo del proyecto refiriéndose a ellos como personas en vez de recursos es una forma sutil pero poderosa de reforzar el hecho de que las personas son el núcleo de una mentalidad ágil. En las siguientes secciones se analiza cómo trabajar con un equipo dedicado, multifuncional, autoorganizado y de tamaño limitado beneficia los proyectos ágiles. Averigua más sobre el liderazgo de servicio y la creación de un buen entorno para un equipo scrum. En resumen, descubre cómo la dinámica de equipo ayuda a que los proyectos ágiles tengan éxito.

246

PARTE 4 Gestión ágil

TABLA 14-1

Dinámica de equipo tradicional versus ágil

Gestión de equipo con Enfoques tradicionales

Dinámica de equipo con enfoques ágiles

Los equipos de proyecto confían en comando y

Los equipos ágiles se autogestionan, se autoorganizan y se benefician

control - un enfoque de arriba hacia abajo para la gestión de proyectos, donde el director del proyecto es responsable de asignar tareas a los miembros del equipo e intentar controlar lo que hace el equipo.

de liderazgo de servicio. En lugar de una gestión de arriba hacia abajo,

Las empresas evalúan el desempeño individual de los

Las organizaciones ágiles evalúan el desempeño del equipo ágil. Los equipos

empleados.

ágiles, como cualquier equipo deportivo, triunfan o fracasan como un equipo

un líder servidor entrena, elimina obstáculos y evita distracciones para permitir que el equipo prospere.

completo. El desempeño de todo el equipo alienta a los miembros individuales del equipo a aumentar las formas en que pueden contribuir al éxito del equipo.

Los miembros del equipo a menudo se encuentran trabajando en más de un proyecto a la vez,

Los equipos de desarrollo se dedican a un proyecto a la vez y obtienen los beneficios del enfoque.

cambiando su atención de un lado a otro. Los miembros del equipo de desarrollo tienen roles

Las organizaciones ágiles se centran en las habilidades en lugar de los títulos. Los

distintos, como programador o evaluador.

equipos de desarrollo trabajan de manera transversal, realizando diferentes trabajos dentro del equipo para garantizar que completen los requisitos prioritarios rápidamente.

Los equipos de desarrollo no tienen límites de tamaño

Los equipos de desarrollo tienen un tamaño limitado intencionalmente.

específicos.

Idealmente, los equipos de desarrollo no tienen menos de tres ni más de nueve personas.

Los miembros del equipo se conocen comúnmente

Los miembros del equipo se llaman gente, talento, o simplemente miembros

como recursos, un término abreviado para recursos

del equipo. En un proyecto ágil, probablemente no escuche el término recurso

humanos.

utilizado para referirse a personas.

Gestión de dinámica de equipo ágil Una y otra vez, cuando hablamos con propietarios de productos, desarrolladores y scrum masters, escuchamos lo mismo: la gente disfruta trabajando en proyectos ágiles. La dinámica de equipo ágil permite a las personas hacer un gran trabajo de la mejor manera que saben. Las personas en los equipos de scrum tienen la oportunidad de aprender, enseñar, liderar y ser parte de un equipo cohesivo y autogestionado. Las siguientes secciones le muestran cómo trabajar como parte de un equipo ágil (utilizando scrum como contexto) y por qué los enfoques ágiles del trabajo en equipo hacen que los proyectos ágiles sean exitosos.

CAPITULO 14 Gestión de la dinámica de equipo y la comunicación

247

Convertirse en autogestionario

y autoorganizado

En proyectos ágiles, los equipos de scrum son directamente responsables de la creación de entregables. Los equipos Scrum se gestionan a sí mismos, organizando su propio trabajo y tareas. Nadie le dice al equipo de scrum qué hacer. Esto no significa que los proyectos ágiles no tengan liderazgo. Cada miembro del equipo scrum tiene la oportunidad de liderar de manera informal, según sus habilidades, ideas e iniciativa. En proyectos ágiles, el equipo de desarrollo contiene a las personas que están haciendo el trabajo físico de crear el producto. El equipo de scrum contiene el equipo de desarrollo, además del propietario del producto y el scrummaster. El equipo del proyecto es el equipo scrum y las partes interesadas de su proyecto. Tanto el equipo de desarrollo como el equipo de scrum en general tienen responsabilidades relacionadas con la autogestión. La idea de autogestión y autoorganización es una forma madura de pensar sobre el trabajo. La autogestión asume que las personas son profesionales, motivadas y lo suficientemente dedicadas para comprometerse con un trabajo y llevarlo a cabo. En el centro de la autogestión se encuentra la idea de que las personas que realizan un trabajo día a día saben más sobre ese trabajo y están mejor calificadas para determinar cómo completarlo. Trabajar con un equipo scrum autogestionado requiere confianza y respeto dentro del equipo y dentro de la organización del equipo en su conjunto. No obstante, seamos claros: la responsabilidad es el núcleo de los proyectos ágiles. La diferencia es que en un proyecto ágil, los equipos son responsables de los resultados tangibles que puede ver y demostrar. Tradicionalmente, las empresas responsabilizaban a los equipos del cumplimiento del proceso paso a paso de la organización, despojándolos de la capacidad o el incentivo para ser innovadores. La autogestión, sin embargo, devuelve la innovación y la creatividad a los equipos de desarrollo. Para que un equipo de scrum se autogestione, necesita un entorno de confianza. Todos en el equipo de scrum deben confiar unos en otros para hacer lo mejor para el equipo de scrum y el proyecto. La empresa u organización del equipo de scrum también debe confiar en que el equipo de scrum es competente, para tomar decisiones y para administrarse a sí mismo. Para crear y mantener un ambiente de confianza, cada miembro del equipo scrum debe comprometerse, individualmente y como equipo, con el proyecto y entre sí. Los equipos de desarrollo autogestionados crean mejores arquitecturas de productos, requisitos y diseño por una sencilla razón: propiedad. Cuando le das a las personas la libertad y la responsabilidad de resolver problemas, se involucran más mentalmente en su trabajo.

Los miembros del equipo Scrum juegan roles en todas las áreas de la gestión de proyectos. La Tabla 14-2 muestra cómo los equipos de scrum y los equipos de desarrollo administran el alcance, las adquisiciones, el tiempo, el costo, la dinámica del equipo, la comunicación, las partes interesadas, la calidad y el riesgo.

248

PARTE 4 Gestión ágil

TABLA 14-2

Área de proyecto

Gestión Alcance

Gestión de proyectos y equipos de autogestión Cómo los propietarios de productos

Autogestión

Cómo el desarrollo

Cómo ScrumMasters

Autogestión de equipos

Autogestión

Utilice la visión del producto, el

Puede sugerir características

Eliminar impedimentos que

objetivo de lanzamiento y cada

basado en la afinidad técnica.

limitar la cantidad de alcance que

objetivo de sprint para determinar si pertenecen los

Trabaje directamente con el propietario del producto para

A través del coaching, ayuda

aclarar los requisitos.

los equipos de desarrollo se convierten

Identificar cuánto trabajo

más productivo con cada sprint sucesivo.

elementos del alcance y a dónde pertenecen. Utilizar la acumulación de productos

priorización a determinar cual los requisitos son desarrollado.

puede crear el equipo de desarrollo.

pueden enfrentarse en un sprint. Identifique las tareas para completar el alcance en el backlog del Sprint. Determine la mejor manera de crear características específicas.

Obtención

Seguro necesario

Identificar las herramientas que

Ayude a adquirir herramientas

financiación de herramientas y

necesitan para crear

y equipos que aceleren

equipos para

el producto.

velocidad del equipo de desarrollo.

equipos de desarrollo.

Trabaje con el propietario del producto para obtener esas herramientas.

Hora

Asegúrese de que el

Proporcionar estimaciones de esfuerzo

Facilitar la estimación

Equipo de desarrollo

para las características del producto.

juegos de póquer.

Identifique qué funciones pueden

Ayudar a los equipos de desarrollo

crear en un período de tiempo

aumentar la velocidad, que

determinado: el sprint.

afecta el tiempo.

A menudo proporciona tiempo

Protege al equipo de

estimaciones para las tareas

pérdidas de tiempo organizativas

Usar velocidad velocidad de desarrollo

en cada sprint.

y distracciones.

para pronosticar a largo plazo

diarios y administre

entiende correctamente características del producto para que los equipos de desarrollo puedan

estimar correctamente el esfuerzo por crear esas características.

líneas de tiempo.

Costo

Elija sus propios horarios su propio tiempo.

En última instancia responsable

Proporcionar estimaciones de esfuerzo

Facilitar la estimación

por el presupuesto y

para las características del producto.

juegos de póquer.

retorno de la inversión en un proyecto ágil. Utilice la velocidad para pronosticar

Ayudar a los equipos de desarrollo

aumentar la velocidad, que afecta el costo.

los costos a largo plazo, en las líneas de tiempo.

(continuado)

CAPITULO 14 Gestión de la dinámica de equipo y la comunicación

249

TABLA 14-2 ( continuado)

Área de proyecto

Gestión

Dinámica de equipo

Cómo los propietarios de productos

Autogestión

Cómo el desarrollo

Autogestión

Comprometerse con sus

Evite los cuellos de botella

Facilitar el equipo de scrum

proyectos como miembro par

trabajando de manera transversal,

colocación.

integrado del

y están dispuestos a asumir

equipo de scrum.

diferentes tipos de tareas. Aprenda continuamente y enseñarse unos a otros. Comprometerse, ambos individualmente

y como parte del equipo scrum, a sus proyectos y entre ellos. Esfuércese por generar consenso al hacer importantes

decisiones.

Comunicación

Comunicar información sobre el producto y el el negocio necesita equipos de desarrollo en de forma continua.

próximas tareas, y identificar obstáculos en sus reuniones diarias. Mantenga el trabajo pendiente de Sprint actualizado diariamente, proporcionando

precisa, inmediata

progreso del proyecto a

estado del proyecto.

Ayude a eliminar los impedimentos para la autogestión del equipo scrum.

Comprometerse con sus proyectos y ser miembros integrados del equipo scrum. Esfuércese por generar consenso dentro del equipo scrum al tomar decisiones importantes.

Facilitar las relaciones entre el equipo de scrum y las partes interesadas.

Fomentar el cara a cara

comunicación entre todos miembros del equipo scrum. Fomentar una estrecha cooperación

entre el equipo de scrum y otros departamentos dentro de la empresa u organización.

información sobre un Trabajo presente

Ayuda a presentar el trabajo

funcionalidad para proyectar

funcionalidad para

partes interesadas en las reuniones

partes interesadas en el

de revisión del sprint en el

revisión de sprint al final de cada sprint.

final de cada sprint.

Establezca expectativas de objetivos

Demuestre trabajar

de visión, liberación y sprint.

funcionalidad en

Desarrollo de escudo

revisiones de sprint.

Entrenar en scrum y principios ágiles en lo que respecta a su interacción con el equipo scrum.

equipo de

Trabajar a través del producto

ruido de negocios.

propietario para descomponer

Proteja a los desarrolladores de

requisitos.

distracciones no comerciales.

Informe sobre el progreso del

Facilite las revisiones de sprint

proyecto a través de gráficos de

para recopilar comentarios.

Recopile comentarios durante revisiones de sprint.

Reúna los requisitos durante todo el proyecto.

Comunicar liberación fechas y cómo afectan las solicitudes de nuevas funciones fechas de lanzamiento.

250

Informe sobre el progreso,

Comunicar información sobre el partes interesadas.

Partes interesadas

Cómo ScrumMasters

Autogestión de equipos

PARTE 4 Gestión ágil

lanzamiento y desarrollo de sprints.

Actualice el estado de la tarea no menos que al final

de cada día.

Facilitar las interacciones al aire libre revisiones de sprint.

Área de proyecto

Gestión Calidad

Cómo los propietarios de productos

Autogestión

Cómo el desarrollo

Cómo ScrumMasters

Autogestión de equipos

Autogestión

Agregar criterios de aceptación

Comprometerse a proporcionar

Ayude a facilitar la

a los requisitos.

excelencia técnica y buen diseño.

retrospectiva del sprint.

Equipo de desarrollo

Pon a prueba su trabajo a lo

comunicación entre

entiende correctamente

largo del día y

miembros del equipo scrum, que

e interpreta requisitos.

probar exhaustivamente todo

a su vez ayuda a garantizar un

desarrollo cada día.

trabajo de calidad.

Proporcionar desarrollo

Inspeccionar su trabajo y adaptarse a las mejoras.

Ayude a crear un entorno de desarrollo sostenible para

en la retrospectiva de sprint

que el equipo de desarrollo pueda rendir al máximo.

Asegúrese de que el

equipos con comentarios

sobre el producto de la organización y del mercado.

reuniones al final de cada sprint.

Ayude a asegurar cara a cara

Aceptar la funcionalidad como

realizado durante cada sprint. Riesgo

Observe los riesgos generales del

Identificar y desarrollar el enfoque de

proyecto, así como los riesgos de su

mitigación de riesgos.

compromiso de ROI.

para cada sprint.

Ayude a prevenir obstáculos y distracciones. Ayude a eliminar obstáculos y

en la lista de productos pendientes

Alerta al scrummaster sobre obstáculos y

cerca de la parte superior para

distracciones.

Facilitar el equipo de desarrollo

Usar información de

posibles riesgos.

Priorizar los artículos de alto riesgo

abordarlos antes en lugar de que más tarde.

riesgos identificados.

conversaciones sobre

cada retrospectiva de sprint para reducir el riesgo en futuros sprints.

Abrazar la cruz funcionalidad para reducir el riesgo si un miembro inesperadamente

deja el equipo. Comprometerse a cumplir

funcionalidad de envío en al final de cada sprint, reduciendo el riesgo en el proyecto en general.

Con todo, las personas con proyectos ágiles tienden a encontrar una gran satisfacción laboral. La autogestión habla de un deseo humano profundamente arraigado de autonomía, de controlar nuestro propio destino, y permite a las personas este control a diario. La siguiente sección analiza otra razón por la que las personas en proyectos ágiles están felices: el líder servidor.

CAPITULO 14 Gestión de la dinámica de equipo y la comunicación

251

Apoyando al equipo: el líder-servidor El scrum master sirve como un líder servidor, alguien que lidera eliminando obstáculos, previniendo distracciones y ayudando al resto del equipo scrum a hacer su trabajo lo mejor que puede. Los líderes en proyectos ágiles ayudan a encontrar soluciones en lugar de asignar tareas. Los scrum masters entrenan, confían y desafían al equipo scrum para que se administre a sí mismo. Otros miembros del equipo scrum también pueden asumir roles de liderazgo de servicio. Si bien el scrum master ayuda a deshacerse de las distracciones y los obstáculos, el propietario del producto y los miembros del equipo de desarrollo también pueden ayudar cuando sea necesario. El propietario del producto puede liderar proporcionando de forma proactiva detalles importantes sobre las necesidades del producto y proporcionando rápidamente respuestas a las preguntas del equipo de desarrollo. Los miembros del equipo de desarrollo pueden enseñarse y orientarse entre sí a medida que se vuelven más multifuncionales. Cada persona en un equipo de scrum puede actuar como un líder-servidor en algún momento del proyecto.

Larry Spears identificó diez características de un líder-servidor en su artículo, “La comprensión y la práctica del liderazgo-servidor” (Mesa Redonda de Liderazgo Servant, Escuela de Estudios de Liderazgo, Regent University, agosto de 2005). Aquí están esas características, junto con nuestras adiciones sobre cómo cada característica puede beneficiar la dinámica del equipo en un proyecto ágil.

» Escuchando: Escuchar atentamente a otros miembros del equipo scrum ayudará al las personas en el equipo de scrum identifican áreas para ayudarse entre sí. Un sirvienteEl líder puede necesitar escuchar lo que dice la gente, así como lo que la gente está diciendo. no diciendo, con el fin de eliminar obstáculos.

» Empatía: Un líder-servidor trata de comprender y empatizar con las personas en el equipo de scrum, y para ayudar a los demás a entenderse.

» Cicatrización: En un proyecto ágil, curar puede significar deshacer el daño de Procesos no centrados en las personas. Estos son procesos que tratan a las personas como

equipos y otras piezas reemplazables. Muchos enfoques tradicionales de gestión de proyectos pueden describirse como no centrados en las personas.

» Conciencia: En un proyecto ágil, las personas del equipo scrum pueden necesitar estar al tanto de las actividades en muchos niveles para servir mejor al equipo de scrum.

» Persuasión: Los líderes servidores confían en la capacidad de convencer, más que en autoridad de arriba hacia abajo. Fuertes habilidades de persuasión, junto con influencia organizacional o

influencia, ayudará a un scrummaster a abogar por el equipo de scrum en la empresa u organización. Un líder servidor también puede transmitir habilidades de persuasión al resto del equipo de scrum, lo que ayuda a mantener la armonía y generar consenso.

252

PARTE 4 Gestión ágil

» Conceptualización: Cada miembro de un equipo de scrum puede utilizar la conceptualización habilidades en un proyecto ágil. La naturaleza cambiante de los proyectos ágiles fomenta la Scrum Team para visualizar ideas más allá de las que tenemos a mano. Un líder-servidor ayudará a nutrir la creatividad del equipo scrum, tanto para el desarrollo del producto como para la dinámica del equipo.

» Previsión: Los equipos de Scrum adquieren previsión con cada retrospectiva de sprint. Por inspeccionando su trabajo, procesos y dinámica de equipo de manera regular, el El equipo de scrum puede adaptarse continuamente y comprender cómo tomar mejores decisiones para sprints futuros.

» Administración: Un líder servidor es el administrador de las necesidades del equipo scrum. La mayordomía se trata de confianza. Los miembros del equipo scrum confían unos en otros para

Esté atento a las necesidades del equipo y del proyecto en su conjunto.

» Compromiso con el crecimiento de las personas: El crecimiento es esencial para un scrum la capacidad del equipo para ser multifuncional. Un líder servidor alentará y permitirá que un equipo scrum aprenda y crezca.

» Construyendo comunidad: Un equipo de scrum es su propia comunidad. Un líder-servidor ayudará a construir y mantener una dinámica de equipo positiva dentro de esa comunidad.

El liderazgo de servicio funciona porque se enfoca positivamente en las personas y las interacciones, un principio clave de la gestión ágil de proyectos. Al igual que la autogestión, el liderazgo de servicio requiere confianza y respeto. El concepto de liderazgo de servicio no es específico de proyectos ágiles. Si ha estudiado técnicas de gestión, puede reconocer los trabajos de Robert K. Greenleaf, quien inició el movimiento moderno para el liderazgo de servicio y acuñó el término líder de servicio - en un ensayo en 1970. Greenleaf fundó el Center for Applied Ethics, ahora conocido como Greenleaf Center for Servant Leadership, que promueve el concepto de liderazgo de servicio en todo el mundo. Otro experto en líderes sirvientes, Kenneth Blanchard, coescribió con Spencer Johnson la Gerente de

un minuto ( publicado por WilliamMorrow), donde describe las características que hacen que los grandes gerentes de personas y equipos de alto funcionamiento sean excelentes. (El libro se ha actualizado desde entonces como El nuevo administrador de un minuto, publicado por Harper Collins India). La razón por la que los gerentes que Blanchard estudió fueron tan efectivos es porque se enfocaron en garantizar que las personas que realizaban el trabajo tuvieran dirección, recursos y protección contra el ruido para hacer su trabajo lo más rápido posible. Las siguientes dos secciones se relacionan en gran medida con los factores del equipo para el éxito de un proyecto ágil: el equipo dedicado y el equipo multifuncional.

CAPITULO 14 Gestión de la dinámica de equipo y la comunicación

253

Trabajando con un equipo dedicado Tener un equipo de scrum dedicado proporciona los siguientes beneficios importantes a los proyectos:

» Mantener a las personas concentradas en un proyecto a la vez ayuda a evitar distracciones. ciones. La dedicación a un proyecto aumenta la productividad al reducir cambiar de

tarea - moverse de un lado a otro entre diferentes tareas sin realmente completar ninguna de ellas.

» Los equipos de scrum dedicados tienen menos distracciones y menos distracciones. ciones significan menos errores. Cuando una persona no tiene que cumplir con las demandas de más de un proyecto, esa persona tiene el tiempo y la claridad para asegurarse de que su trabajo sea lo mejor posible. El capítulo 15 analiza las formas de aumentar la calidad del producto en detalle.

» Cuando las personas trabajan en equipos de scrum dedicados, saben lo que harán estar trabajando todos los días. Una realidad interesante de la ciencia del comportamiento es que cuando las personas saben en qué estarán trabajando en el futuro inmediato, sus mentes se involucran en esos temas conscientemente en el trabajo e inconscientemente fuera del entorno laboral. La estabilidad de las tareas ocupa su mente durante mucho más tiempo cada día, lo que permite mejores soluciones y productos de mayor calidad.

» Los miembros del equipo de scrum dedicados pueden innovar más en los proyectos.

Cuando las personas se sumergen en un producto sin distracciones, pueden encontrar soluciones creativas para la funcionalidad del producto.

» Es más probable que las personas en equipos de scrum dedicados sean felices en su trabajos. Al poder concentrarse en un proyecto, el trabajo de un miembro del equipo de scrum es más fácil. Muchas personas, si no la mayoría, disfrutan de producir un trabajo de calidad, ser productivas y creativas. Los equipos de scrum dedicados conducen a una mayor satisfacción.

» Cuando tienes un equipo de scrum dedicado que trabaja la misma cantidad de tiempo cada semana, puede calcular con precisión velocidad - los equipos

velocidad de desarrollo. En el Capítulo 13, hablamos sobre la determinación de la velocidad de un equipo de scrum al final de cada sprint y el uso de la velocidad para determinar los costos y las líneas de tiempo a largo plazo. Debido a que la velocidad se basa en comparar el resultado de un sprint con el siguiente, usar la velocidad para pronosticar el tiempo y el costo funciona mejor si las horas de trabajo del equipo de scrum son constantes. Si no puede tener un equipo de scrum dedicado, al menos intente tener miembros del equipo asignados a su proyecto por la misma cantidad de tiempo cada semana.

La idea del multitarea productivo es un mito. En los últimos 25 años, y especialmente en la última década, varios estudios han concluido que el cambio de tareas reduce la productividad, deteriora las habilidades de toma de decisiones y da como resultado más errores.

254

PARTE 4 Gestión ágil

Para tener un equipo de scrum dedicado, necesita un fuerte compromiso por parte de su organización. Muchas empresas piden a los empleados que trabajen en varios proyectos a la vez, bajo la suposición errónea de que la empresa ahorrará dinero contratando menos personas. Cuando las empresas comienzan a adoptar una mentalidad más ágil, aprenden que el enfoque menos costoso es reducir los defectos y aumentar la productividad del desarrollo a través del enfoque. Cada miembro del equipo de scrum puede ayudar a garantizar la dedicación:

» Si es propietario de un producto, asegúrese de que la empresa sepa que un El equipo de scrum seleccionado es una buena decisión fiscal. Eres responsable del proyecto

retorno de la inversión, así que esté dispuesto a luchar por el éxito de su proyecto.

» Si es miembro del equipo de desarrollo y alguien le solicita que

trabajar fuera del proyecto, puede retroceder e involucrar el producto propietario o scrummaster, si es necesario. Una solicitud de trabajo externo, independientemente de cuán benigna sea, es un obstáculo potencial.

» Si eres un scrummaster, como experto en enfoques ágiles, puedes educar la empresa sobre por qué un equipo scrum dedicado significa una mayor productividad,

calidad e innovación. Un buen scrummaster también debe tener la influencia organizativa para evitar que la empresa saque a la gente del equipo de scrum para otros proyectos. Otra característica de los equipos de scrum es que son multifuncionales.

Trabajando con un equipo multifuncional Los equipos de desarrollo multifuncionales también son importantes en proyectos ágiles. El equipo de desarrollo de un proyecto de software ágil no solo incluye programadores; podría incluir a todas las personas que tendrán un trabajo en el proyecto. Por ejemplo, un equipo de desarrollo en un proyecto de software puede incluir programadores, expertos en bases de datos, personal de control de calidad, expertos en usabilidad y diseñadores gráficos. Si bien cada persona tiene especialidades, ser multifuncional significa que todos en el equipo están dispuestos a colaborar en diferentes partes del proyecto, tanto como sea posible. En un equipo de desarrollo ágil, continuamente se hace dos preguntas: "¿Qué puedo aportar hoy?" y "¿Cómo puedo ampliar mi contribución en el futuro?" Todos en el equipo de desarrollo utilizarán sus habilidades y especialidades actuales en cada sprint. La funcionalidad cruzada brinda a los miembros del equipo de desarrollo la oportunidad de aprender nuevas habilidades trabajando en áreas fuera de su experiencia. La funcionalidad cruzada también permite a las personas compartir sus conocimientos con sus compañeros miembros del equipo de desarrollo. No es necesario ser un experto en todos los oficios para trabajar en un equipo de desarrollo ágil, pero debe estar dispuesto a aprender nuevas habilidades y ayudar con todo tipo de tareas.

CAPITULO 14 Gestión de la dinámica de equipo y la comunicación

255

Aunque el cambio de tareas disminuye la productividad, la funcionalidad cruzada funciona porque no está cambiando el contexto de lo que está trabajando; estás viendo el mismo problema desde una perspectiva diferente. Trabajar en diferentes aspectos del mismo problema aumenta la profundidad del conocimiento y su capacidad para hacer un mejor trabajo.

El mayor beneficio de un equipo de desarrollo multifuncional es la eliminación de puntos únicos de falla. Si ha trabajado en un proyecto antes, ¿cuántas veces ha experimentado retrasos porque un miembro crítico del equipo está de vacaciones, enfermo o, peor aún, ha dejado la empresa? Las vacaciones, las enfermedades y la rotación son hechos de la vida, pero con un equipo de desarrollo multifuncional, otros miembros del equipo pueden participar y continuar trabajando con una interrupción mínima. Incluso si un experto abandona el equipo del proyecto de forma inesperada y abrupta, otros miembros del equipo de desarrollo sabrán lo suficiente sobre el trabajo para que siga progresando. Los miembros del equipo de desarrollo se van de vacaciones o contraen la gripe. No sabotees tu proyecto haciendo que solo una persona conozca una habilidad o área funcional. La funcionalidad cruzada requiere un fuerte compromiso por parte del equipo de desarrollo, tanto como miembros individuales como como grupo. La vieja frase, "No hay I en equipo ”Es especialmente cierto en proyectos ágiles. Trabajar en un equipo de desarrollo ágil se trata de habilidades, más que de títulos. Los equipos de desarrollo sin títulos se basan más en el mérito porque la antigüedad y el estado del equipo se basan en el conocimiento, las habilidades y la contribución actuales. Dejar de lado la idea de que eres un “evaluador de control de calidad senior” o un “desarrollador junior” puede requerir una nueva forma de pensar sobre ti mismo. Abrazar el concepto de ser parte de un equipo de desarrollo multifuncional puede requerir algo de trabajo, pero puede ser gratificante a medida que aprende nuevas habilidades y desarrolla un ritmo de trabajo en equipo. Cuando los desarrolladores también prueban, crean código que es fácil de probar.

Tener un equipo de desarrollo multifuncional también requiere compromiso y apoyo de su organización. Algunas empresas eliminan los títulos o los mantienen intencionalmente vagos (es posible que vea algo como "desarrollo de aplicaciones") para fomentar el trabajo en equipo. Otras técnicas para crear un equipo de desarrollo interdisciplinario sólido desde el punto de vista organizacional incluyen ofrecer capacitación, reconocer a los equipos de scrum como un todo y estar dispuesto a hacer cambios si una persona en particular no encaja en un entorno de equipo. Al contratar, su empresa puede buscar activamente personas que trabajen bien en un entorno altamente colaborativo, que quieran aprender nuevas tareas y que estén dispuestas a trabajar en todas las áreas de un proyecto.

256

PARTE 4 Gestión ágil

Tanto el entorno físico como el entorno cultural de una organización son claves importantes para el éxito de los proyectos ágiles. La siguiente sección le muestra cómo.

Reforzando la apertura Como explicamos en otros capítulos, un equipo de scrum colocado es ideal. Internet ha unido a las personas a nivel mundial, pero nada, ni la mejor combinación de correos electrónicos, mensajes instantáneos, videoconferencias, llamadas telefónicas y herramientas de colaboración en línea, puede reemplazar la simplicidad y efectividad de una conversación cara a cara. La figura 14-1 ilustra la diferencia entre un intercambio de correo electrónico y una conversación en persona.

FIGURA 14-1: Correo electrónico versus

cara a cara conversacion.

La idea de que los miembros del equipo scrum trabajen en la misma ubicación física y puedan hablar en persona, al instante, es importante para la dinámica del equipo. Encontrará más detalles sobre la comunicación más adelante en este capítulo. Además, el Capítulo 5 proporciona detalles sobre cómo configurar el entorno físico para un equipo de scrum.

CAPITULO 14 Gestión de la dinámica de equipo y la comunicación

257

Tener un entorno cultural de apertura, que favorece el crecimiento del equipo scrum, es otro factor de éxito para los proyectos ágiles. Todos en un equipo de scrum deberían poder

» Sentirse seguro.

» Expresa lo que piensa de una manera positiva.

» Desafiar el status quo. » Sea abierto sobre los desafíos sin ser penalizado. » Solicite recursos que marcarán la diferencia en el proyecto. » Comete errores y aprende de ellos. » Sugerir un cambio y hacer que otros miembros del equipo scrum consideren seriamente esos cambios.

» Respeta a los miembros del equipo scrum.

» Ser respetado por otros miembros del equipo scrum. La confianza, la apertura y el respeto son fundamentales para la dinámica de equipo en un proyecto ágil. Algunas de las mejores mejoras de productos y procesos provienen de principiantes que hacen preguntas "tontas".

Otra faceta de la dinámica de equipo ágil es el concepto de equipo de tamaño limitado.

Limitar el tamaño del equipo de desarrollo Un aspecto psicológico interesante de la dinámica de equipo en un proyecto ágil es la cantidad de personas en un equipo de desarrollo. Los equipos de desarrollo suelen tener entre tres y nueve personas. Un tamaño ideal está en algún lugar en el medio. Limitar el tamaño del equipo de desarrollo a este rango proporciona un equipo con suficientes habilidades diversas para llevar un requisito desde el papel hasta la producción mientras se mantiene la comunicación y la colaboración simples. Los miembros del equipo de desarrollo pueden interactuar fácilmente entre sí y tomar decisiones por consenso.

Cuando tiene equipos de desarrollo con más de nueve personas, las personas en esos equipos tienden a dividirse en subgrupos y construir silos. Este es un comportamiento humano social normal, pero los subgrupos pueden ser perjudiciales para un equipo de desarrollo que se esfuerza por autogestionarse. También es más difícil comunicarse con equipos de desarrollo más grandes; hay más canales de comunicación y oportunidades para perder o

258

PARTE 4 Gestión ágil

malinterpretar un mensaje. Con más de nueve personas en un equipo de desarrollo, a menudo necesita una persona adicional solo para ayudar a administrar la comunicación. Los equipos de desarrollo con menos de nueve personas, por otro lado, tienden a gravitar naturalmente hacia un enfoque ágil. Sin embargo, los equipos de desarrollo que son demasiado pequeños pueden encontrar difícil el trabajo de funciones cruzadas porque puede que no haya suficientes personas con diferentes habilidades en el proyecto. Si el desarrollo de su producto requiere más de nueve miembros del equipo de desarrollo, considere dividir el trabajo entre varios equipos de scrum. La creación de equipos de personas con personalidades, habilidades y estilos de trabajo similares puede mejorar la productividad. Encuentre detalles sobre cómo trabajar con múltiples equipos de scrum en los Capítulos 13 y 17.

Gestión de proyectos con equipos dislocados Como decimos a lo largo del libro, un equipo de scrum colocado es ideal para proyectos ágiles. Sin embargo, a veces no es posible que un equipo de scrum trabaje en conjunto en un solo lugar. Equipos dislocados los equipos con personas que trabajan en diferentes lugares, existen por muchas razones y en diferentes formas. En algunas empresas, las personas con las habilidades adecuadas para un proyecto pueden trabajar en diferentes oficinas, y es posible que la empresa no quiera el costo de reunir a esas personas durante la duración del proyecto. Algunas organizaciones trabajan conjuntamente con otras organizaciones en proyectos, pero es posible que no quieran o no puedan compartir espacio de oficina. Algunas personas pueden trabajar a distancia, especialmente los contratistas, vivir a grandes distancias de la empresa con la que trabajan y nunca visitar la oficina de esa empresa. Algunas empresas trabajan con grupos offshore y crean proyectos con personas de otros países.

La buena noticia es que aún puede tener un proyecto ágil con un equipo o equipos de scrum dislocados. Si tiene que trabajar con un equipo dislocado, hemos descubierto que un enfoque ágil le permite ver la funcionalidad de trabajo mucho antes y limita el riesgo de malentendidos inevitables que experimentará un equipo dislocado. En Un manual de Scrum ( Scrum Institute Training Press), Jeff Sutherland describe tres modelos de equipos de scrum distribuidos:

» Scrums aislados: Con scrums aislados, los equipos de scrum individuales tienen colomiembros del equipo scrum, pero cada equipo scrum está en un área geográfica separada UBICACION Y FUNCIONA POR SEPARADO. El desarrollo de productos con scrums aislados solo tiene integración a nivel de código; es decir, los diferentes equipos no se comunican ni trabajan juntos, pero esperan que el código funcione cuando sea el momento de integrar cada módulo debido a los estándares de codificación organizacional. Los scrums aislados tienden a tener problemas porque diferentes personas interpretan los estándares de codificación de manera diferente.

CAPITULO 14 Gestión de la dinámica de equipo y la comunicación

259

» Scrum de scrums distribuidos: Con un modelo de scrum distribuido de scrums, Los equipos de scrum están en diferentes ubicaciones, como en scrums aislados. Coordinar

trabajo, los equipos de scrum tienen un scrum de scrums —Una reunión de múltiples scrum masters— para integrarse a diario.

» Scrums integrados: Los equipos de scrum integrados son multifuncionales, con scrum miembros del equipo en diferentes ubicaciones. Se sigue produciendo un scrumof scrums pero

Se pierde la comunicación cara a cara. La Tabla 14-3, de los “Resultados de la encuesta de tasa de adopción ágil” de Ambysoft en 2008, muestra una comparación de las tasas de éxito de los proyectos con equipos de scrum colocados frente a aquellos con equipos de scrum dispersos geográficamente.

TABLA 14-3

Éxito de ScrumTeams colocados y dislocados Ubicación del equipo

Porcentaje de éxito

Equipo de scrum colocado

83%

Dislocado pero físicamente accesible

72%

Distribuido a través de geografías

60%

¿Cómo tiene un proyecto ágil exitoso con un equipo scrum dislocado? Tenemos tres palabras: comunicar, comunicar y comunicar. Debido a que las conversaciones personales diarias no son posibles, los proyectos ágiles con equipos de scrum dislocados requieren esfuerzos únicos por parte de todos los que trabajan en el proyecto. Estos son algunos consejos para una comunicación exitosa entre los miembros del equipo scrum no coubicados:

» Utilice la tecnología de videoconferencia para simular una conversación cara a cara. ciones. La mayor parte de la comunicación interpersonal es visual e incluye señales faciales, gestos con las manos e incluso encogimiento de hombros. La videoconferencia permite que las personas se vean y se beneficien de la comunicación no verbal y de una discusión. Use videoconferencias, o incluso robots de telepresencia, generosamente durante todo el día, no solo para reuniones rápidas. Asegúrese de que los miembros del equipo estén listos para chats de video improvisados y que la tecnología facilite su inicio.

» Si es posible, haga arreglos para que los miembros del equipo scrum se reúnan en persona ubicación central al menos una vez al comienzo del proyecto, y

preferiblemente varias veces a lo largo del proyecto. La experiencia compartida de reunirse en persona, incluso una o dos veces, puede ayudar a construir el trabajo en equipo entre

260

PARTE 4 Gestión ágil

miembros del equipo dislocados. Las relaciones laborales construidas a través de visitas cara a cara son más fuertes y continúan después de que termina la visita.

» Utilice una herramienta de colaboración en línea. Algunas herramientas simulan pizarras y usuarios tarjetas de historias, rastrear conversaciones y permitir que varias personas se actualicen

artefactos al mismo tiempo.

» Incluya imágenes de los miembros del equipo de scrum en las herramientas de colaboración en línea, o incluso en las líneas de firma de la dirección de correo electrónico. Los humanos responden a los rostros más que

solo palabras escritas. Una simple imagen puede ayudar a humanizar los mensajes instantáneos y los correos electrónicos.

» Sea consciente de las diferencias de zona horaria. Ponga varios relojes mostrando diferentes zonas horarias en la pared para que no llame accidentalmente al teléfono celular de alguien a las 3 am y despierte a esa persona, o se pregunte por qué no contesta.

» Sea flexible también debido a las diferencias de zona horaria. Usted puede necesitar tomar videollamadas o llamadas telefónicas en horas impares de vez en cuando para ayudar a mantener el trabajo del proyecto en movimiento. Para diferencias drásticas en las zonas horarias, considere la posibilidad de cambiar las horas en las que esté disponible. Una semana, TeamA puede estar disponible temprano en la mañana. El siguiente, TeamB puede estar disponible más tarde en la noche. De esa forma, nadie siempre tiene un inconveniente.

» Si tiene alguna duda sobre una conversación o un mensaje escrito, pregunte

para aclaraciones por teléfono o video. Siempre es útil verificar dos veces cuando no está seguro de lo que alguien quiso decir. Haga un seguimiento con una llamada para evitar errores por falta de comunicación.

» Tenga en cuenta las diferencias de idioma y cultura entre el equipo de scrum

miembros, especialmente cuando se trabaja con grupos en varios países. Comprender los coloquialismos y las diferencias de pronunciación puede aumentar la calidad de su comunicación a través de las fronteras. También es útil conocer los días festivos locales. Más de una vez nos han sorprendido las oficinas cerradas fuera de nuestra región.

» Haga un intento adicional de discutir temas que no sean del trabajo a veces. Que se discute Los temas no laborales lo ayudan a acercarse más a los miembros del equipo Scrum, independientemente de la ubicación.

Con dedicación, conciencia y comunicación sólida, los proyectos ágiles distribuidos pueden tener éxito. Los enfoques únicos de la dinámica de equipo en proyectos ágiles son parte de lo que hace que los proyectos ágiles sean exitosos. La comunicación está estrechamente relacionada con la dinámica de equipos, y los métodos de comunicación en proyectos ágiles también tienen grandes diferencias con los proyectos tradicionales, como se ve en la siguiente sección.

CAPITULO 14 Gestión de la dinámica de equipo y la comunicación

261

¿Qué tiene de diferente la comunicación ágil? La comunicación, en términos de gestión de proyectos, son las formas formales e informales en que las personas del equipo del proyecto se transmiten información entre sí. Al igual que con los proyectos tradicionales, la buena comunicación es una necesidad para proyectos ágiles. Sin embargo, los principios ágiles establecen un tono diferente para los proyectos ágiles, enfatizando la simplicidad, la franqueza y las conversaciones cara a cara. Los siguientes principios ágiles se relacionan con la comunicación:

4. Los empresarios y los desarrolladores deben trabajar juntos a diario durante todo el proyecto.

6. El método más eficiente y eficaz de transmitir información ay dentro de un equipo de desarrollo es una conversación cara a cara.

7. El software que funciona es la principal medida de progreso. 10. La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial. 12. A intervalos regulares, el equipo reflexiona sobre cómo volverse más eficaz, luego sintoniza y ajusta su comportamiento en consecuencia.

El Manifiesto Ágil también aborda la comunicación, valorando el software funcional sobre la documentación completa. Aunque la documentación tiene valor, la funcionalidad de trabajo tiene más importancia en un proyecto ágil. La Tabla 14-4 muestra algunas diferencias entre la comunicación en proyectos tradicionales y en proyectos ágiles. La cuestión de cuánta documentación se requiere no es una cuestión de volumen, sino una cuestión de idoneidad. ¿Por qué necesita un documento específico? ¿Cómo puedes crearlo de la forma más sencilla posible? Puede usar hojas adhesivas del tamaño de un póster para colocar en la pared y hacer que la información sea digerible. Esto también puede funcionar mejor para transmitir visualmente artefactos como la declaración de visión, la definición de hecho, el registro de impedimentos y decisiones arquitectónicas importantes. Las imágenes realmente valen más que mil palabras.

Las siguientes secciones muestran cómo aprovechar el énfasis del marco ágil en la comunicación en persona, enfocarse en la simplicidad y el valor de la funcionalidad de trabajo como medio de comunicación.

262

PARTE 4 Gestión ágil

TABLA 14-4

Comunicación tradicional versus ágil

Gestión de la comunicación con enfoques tradicionales

Gestión de la comunicación con enfoques ágiles

Es posible que los miembros del equipo no hagan ningún

Los enfoques ágiles de gestión de proyectos valoran la comunicación cara a cara

esfuerzo especial para las conversaciones en persona.

como la mejor forma de transmitir información.

Los enfoques tradicionales dan un gran valor a

Documentos ágiles, o artefactos son intencionadamente simples y proporcionan

la documentación. Los equipos pueden crear

información apenas suficiente. Los artefactos ágiles solo contienen información

una gran cantidad de documentos complejos e

esencial y, a menudo, pueden transmitir el estado del proyecto de un vistazo.

informes de estado basados en el proceso, en lugar de considerar la necesidad real.

Los equipos de proyecto utilizan mostrar, no decir concepto, que muestra un software de trabajo para comunicar el progreso de forma regular en la revisión del sprint.

Es posible que se requiera que los miembros del equipo asistan a un gran número de reuniones, sean o no útiles o necesarias.

Las reuniones sobre proyectos ágiles son, por diseño, lo más rápidas posible e incluyen solo a personas que se sumarán a la reunión y se beneficiarán de la reunión. Las reuniones ágiles brindan todos los beneficios de la comunicación cara a cara sin perder tiempo. La estructura de las reuniones ágiles es mejorar, no reducir, la productividad.

Gestión de la comunicación ágil Para gestionar la comunicación en proyectos ágiles, debe comprender cómo funcionan los diferentes métodos de comunicación ágiles y cómo utilizarlos juntos. También necesita saber por qué el estado de un proyecto ágil es diferente y cómo informar el progreso del proyecto a las partes interesadas. Las siguientes secciones le muestran cómo hacerlo.

Entender la comunicación ágil métodos Puede comunicarse en un proyecto ágil a través de artefactos, reuniones e informalmente.

Las conversaciones cara a cara son el corazón y el alma de los proyectos ágiles. Cuando los miembros del equipo scrum hablan entre ellos sobre el proyecto todos los días, la comunicación es fácil. Con el tiempo, los miembros del equipo scrum comprenden la personalidad, el estilo de comunicación y los procesos de pensamiento de los demás, y podrán comunicarse de forma rápida y eficaz. Figura 14-2, de la presentación de Alistair Cockburn. Desarrollo de software como juego

cooperativo, muestra la eficacia de la comunicación cara a cara frente a otros tipos de comunicación.

CAPITULO 14 Gestión de la dinámica de equipo y la comunicación

263

En capítulos anteriores, describimos una serie de artefactos y reuniones que encajan con proyectos ágiles. Todos los artefactos y reuniones ágiles juegan un papel en la comunicación. Las reuniones ágiles proporcionan un formato para comunicarse en un entorno cara a cara. Las reuniones sobre proyectos ágiles tienen un propósito específico y una cantidad de tiempo específica para que el equipo de desarrollo pueda trabajar, en lugar de sentarse en reuniones. Los artefactos ágiles proporcionan un formato para la comunicación escrita que está estructurado pero no es engorroso ni innecesario.

La Tabla 14-5 proporciona una vista de los diferentes canales de comunicación en un proyecto ágil.

TABLA 14-5

Canales de comunicación de proyectos ágiles

Canal

Tipo

Papel en la comunicación

Planificación de proyectos, lanzamiento

Reuniones

Las reuniones de planificación tienen resultados específicos deseados y comunican

planificación y

de manera concisa el propósito y los detalles del proyecto, el lanzamiento y el sprint

planificación de sprint

al equipo de scrum. Obtenga más información sobre la planificación de reuniones en los capítulos 7 y 8.

Declaración de visión del producto

Artefacto

La declaración de la visión del producto comunica el objetivo final del proyecto al equipo del proyecto y a la organización. Obtenga más información sobre la visión del producto en el Capítulo 7.

Hoja de ruta del producto

Artefacto

La hoja de ruta del producto comunica una visión a largo plazo de las características que respaldan la visión del producto y es probable que formen parte del proyecto. Obtenga más información sobre la hoja de ruta del producto en el Capítulo 7.

Pila de Producto

Artefacto

La cartera de pedidos del producto comunica el alcance del proyecto en su conjunto al equipo del proyecto. Obtenga más información sobre la acumulación de productos en los capítulos 7 y 8.

264

PARTE 4 Gestión ágil

Canal

Tipo

Papel en la comunicación

Plan de lanzamiento

Artefacto

El plan de lanzamiento comunica los objetivos y el tiempo para un lanzamiento específico. Obtenga más información sobre el plan de lanzamiento en el Capítulo 8.

Cartera de Sprint

Artefacto

Cuando se actualiza a diario, la acumulación de sprints proporciona el estado del proyecto y el sprint inmediato a cualquier persona que necesite esa información. El gráfico de evolución en la acumulación de sprints proporciona una visualización rápida del progreso del sprint. Obtenga más información sobre la acumulación de sprints en los capítulos 8 y 9.

Tablero de tareas

Artefacto

El uso de un tablero de tareas irradia visualmente el estado del sprint o liberación actual a cualquiera que pase por el área de trabajo del equipo de scrum. Obtenga más información sobre el tablero de tareas en el Capítulo 9.

Scrum diario

Reunión

El scrum diario proporciona al equipo de scrum una oportunidad verbal y cara a cara para coordinar las prioridades del día e identificar cualquier desafío. Obtenga más información sobre los scrummeetings diarios en el Capítulo 9.

Conversaciones cara a cara

Informal

Las conversaciones cara a cara son el modo de comunicación más importante en un proyecto ágil.

Revisión de Sprint

Reunión

La revisión del sprint es la encarnación de la filosofía de mostrar, no decir. Mostrar la funcionalidad de trabajo a todo el equipo del proyecto transmite el progreso del proyecto de una manera más significativa que un informe escrito o una presentación conceptual. Obtenga más información sobre las revisiones de sprint en el Capítulo 10.

Sprint retrospectiva

Reunión

La retrospectiva del sprint permite que el equipo de scrum se comunique entre sí específicamente para mejorar. Obtenga más información sobre las retrospectivas de sprint en el Capítulo 10.

Notas de la reunión

Informal

Las notas de la reunión son un método de comunicación opcional e informal en un proyecto ágil. Las notas de la reunión pueden capturar elementos de acción de una reunión para garantizar que las personas del equipo scrum los recuerden para más adelante. Las notas de una revisión de sprint incluyen nuevas características para la cartera de productos.

Las notas de una retrospectiva de sprint pueden recordarle al equipo de scrum los planes de mejora.

Soluciones colaborativas

Informal

Las pizarras, las notas adhesivas y las herramientas de colaboración electrónica ayudan al equipo de scrum a comunicarse. Asegúrese de que estas herramientas aumenten, en lugar de reemplazar, las conversaciones cara a cara. Capturar y guardar los resultados de la colaboración es una forma de baja fidelidad de recordar al equipo las decisiones tomadas para su consideración inmediata y futura.

CAPITULO 14 Gestión de la dinámica de equipo y la comunicación

265

Los artefactos, las reuniones y los canales de comunicación más informales son todas herramientas. Tenga en cuenta que incluso las mejores herramientas necesitan que las personas las utilicen correctamente para ser eficaces. Los proyectos ágiles se tratan de personas e interacciones; las herramientas son secundarias al éxito.

La siguiente sección aborda un área específica de la comunicación ágil del proyecto: informes de estado.

Informes de estado y progreso Todos los proyectos tienen partes interesadas, personas fuera del equipo scrum inmediato que tienen un interés personal en el proyecto. Al menos una de las partes interesadas es la persona responsable de pagar su proyecto (el patrocinador del proyecto). Es importante que los interesados, especialmente los responsables de los presupuestos, sepan cómo avanza el proyecto. Esta sección muestra cómo comunicar el estado de su proyecto.

Estado en un proyecto ágil es una medida de las características que ha completado el equipo scrum. Usando la definición de hecho de los Capítulos 2, 8, 10 y 15, una característica está completa si el equipo de scrum ha desarrollado, probado, integrado y documentado esa característica, según el acuerdo entre el propietario del producto y el equipo de desarrollo.

Si ha trabajado en un proyecto de software tradicional, ¿cuántas veces ha estado en una reunión de estado y ha informado que el proyecto se completó, digamos, en un 64 por ciento? Si sus partes interesadas hubieran respondido: “¡Genial! Nos gustaría ese 64 por ciento ahora; nos quedamos sin fondos ”, tanto usted como las partes interesadas estarían perdidos, porque no quería decir que el 64 por ciento de sus funciones estaban listas para usar. Quería decir que cada una de las funciones del producto estaba solo en un 64 por ciento en progreso, no tenía ninguna funcionalidad operativa y aún tenía mucho trabajo por hacer antes de que alguien pudiera usar el producto.

En un proyecto ágil, la funcionalidad de trabajo que cumple con la definición de hecho es la principal medida de progreso. Puede decir con seguridad que las características del proyecto están completas. Debido a que el alcance cambia constantemente en proyectos ágiles, no expresaría el estado como un porcentaje. En cambio, una lista de características potencialmente disponibles sería más interesante de ver para las partes interesadas a medida que crece. Realice un seguimiento diario del progreso de su sprint y del proyecto. Sus herramientas principales para comunicar el estado y el progreso son el tablero de tareas, la lista de tareas pendientes del sprint, la lista de productos pendientes, los gráficos de lanzamiento y evolución del sprint y la revisión del sprint.

266

PARTE 4 Gestión ágil

La revisión del sprint es donde usted demuestra el software que funciona a las partes interesadas de su proyecto. Resista la creación de diapositivas o folletos; la clave de la revisión del sprint es mostrar el progreso de las partes interesadas como una demostración, en lugar de solo decirles lo que completó. Muéstralo, no lo digas. Anime encarecidamente a cualquier persona que pueda tener interés en su proyecto a que asista a sus revisiones de sprint. Cuando las personas ven la funcionalidad de trabajo en acción, especialmente de manera regular, obtienen una idea mucho mejor del trabajo que ha completado. Las empresas y organizaciones que están comenzando a utilizar técnicas ágiles pueden esperar ver informes de estado tradicionales, además de artefactos ágiles. Estas organizaciones también pueden querer que los miembros del equipo de scrum asistan a reuniones de estado regulares, fuera de los scrums diarios y otras reuniones ágiles. Se llama

doble trabajo ágil, porque estás haciendo el doble de trabajo del necesario. El doble trabajo ágil es uno de los principales escollos de los proyectos ágiles. Los equipos de Scrum se agotarán rápidamente si intentan satisfacer las demandas de dos enfoques de proyectos drásticamente diferentes. Puede evitar el doble trabajo ágil al educar a su empresa sobre por qué los artefactos y eventos ágiles son un mejor reemplazo para reuniones y documentos antiguos. Insista en experimentar con artefactos y eventos ágiles para llevar a cabo un proyecto ágil exitoso. La acumulación de Sprint es un informe del estado diario de tu Sprint actual. El backlog del sprint contiene las historias de usuario del sprint y sus tareas y estimaciones relacionadas. El trabajo pendiente del sprint también suele tener un gráfico de evolución que muestra visualmente el estado del trabajo que ha completado el equipo de desarrollo y el trabajo restante para completar los requisitos del sprint. El equipo de desarrollo se encarga de actualizar el backlog del sprint al menos una vez al día actualizando la cantidad de horas de trabajo que quedan para cada tarea. Si es director de proyectos ahora, o si estudia gestión de proyectos en el futuro, es posible que se encuentre con el concepto de gestion del valor ganado ( EVM), como una forma de medir el progreso y el desempeño del proyecto. Algunos profesionales ágiles intentan utilizar una versión ágil de EVM, pero evitamos EVM para proyectos ágiles. EVM asume que su proyecto tiene un alcance fijo, lo que es contrario a un enfoque ágil. En lugar de intentar cambiar los enfoques ágiles para que se ajusten a los modelos antiguos, utilice las herramientas aquí: funcionan. El gráfico de evolución muestra rápidamente, en lugar de decir, el estado. Cuando miras un gráfico de desarrollo de sprints, puedes ver instantáneamente si el sprint va bien o podría estar en problemas. En el Capítulo 9, le mostramos una imagen de gráficos de evolución de muestra para diferentes escenarios de sprint; aquí está de nuevo en la Figura 14-3.

CAPITULO 14 Gestión de la dinámica de equipo y la comunicación

267

FIGURA 14-3: Perfiles de gráficos de quemado.

Si actualiza su backlog de sprint todos los días, siempre tendrá un estado actualizado para las partes interesadas de su proyecto. También puede mostrarles la acumulación de productos para que sepan qué funciones ha completado el equipo de scrum hasta la fecha, qué funciones serán parte de futuros sprints y la prioridad de las funciones. La acumulación de productos cambiará a medida que agregue y cambie la prioridad de las funciones. Asegúrese de que las personas que revisan la acumulación de productos, especialmente por motivos de estado, comprendan este concepto. Un tablero de tareas es una excelente manera de mostrar rápidamente a su equipo de proyecto el estado de un sprint, lanzamiento o incluso de todo el proyecto. Los tableros de tareas tienen notas adhesivas con títulos de historias de usuario en al menos cuatro columnas: Pendiente, En curso, Aceptar y Hecho. Si muestra su tablero de tareas en el área de trabajo del equipo de scrum, cualquier persona que pase puede ver un estado de alto nivel de qué funciones del producto están terminadas y qué funciones están en progreso. El equipo de scrum siempre sabe dónde se encuentra el proyecto, porque el equipo de scrum ve el tablero de tareas todos los días.

Busque siempre radiadores de información simples y de baja fidelidad para comunicar el estado y el progreso. Cuanto más pueda hacer que la información sea accesible y bajo demanda, menos tiempo usted y sus partes interesadas pasarán preparándose y preguntándose sobre el estado.

268

PARTE 4 Gestión ágil

EN ESTE CAPÍTULO » Aprendiendo lo ágil que es el proyecto

enfoques de la calidad de la gestión reducir el riesgo

» Descubriendo formas de garantizar la calidad

desarrollo » Aprovechando la automatización pruebas para una mejor productividad

» Entendiendo cuán ágil proyecto enfoques reducen el riesgo

Capítulo

Gestión de la calidad

andRisk

capítulo, descubre cómo entregar productos de calidad utilizando proyectos ágiles Lamétodos calidad y el riesgo son partes relacionadas de la gestión de proyectos. En esto de gestión. Sabesestrechamente cómo aprovechar las ventajas de agile

enfoques para gestionar el riesgo en sus proyectos. Verá cómo la calidad ha afectado históricamente el riesgo del proyecto y cómo la gestión de la calidad en proyectos ágiles reduce fundamentalmente el riesgo del proyecto.

¿Qué tiene de diferente la calidad ágil? Calidad se refiere a si un producto funciona y si satisface las necesidades de las partes interesadas del proyecto. La calidad es una parte inherente de la gestión ágil de proyectos.

CAPITULO 15 Gestión de la calidad y el riesgo

269

Los 12 principios ágiles que enumeramos en el Capítulo 2 promueven la calidad directa o indirectamente. Estos principios siguen:

1. Nuestra máxima prioridad es satisfacer al cliente a través de un proceso temprano y continuo. entrega de software valioso.

2. Bienvenidos los requisitos cambiantes, incluso al final del desarrollo. Procesos ágiles aprovechar el cambio para la ventaja competitiva del cliente.

3. Entregue software que funcione con frecuencia, desde un par de semanas hasta un par de meses, con preferencia a la escala de tiempo más corta.

4. Los empresarios y los desarrolladores deben trabajar juntos a diario durante todo el proyecto.

5. Construya proyectos en torno a personas motivadas. Dales el medio ambiente y el apoyo que necesitan y confíe en ellos para hacer el trabajo.

6. El método más eficiente y eficaz de transmitir información ay dentro de un equipo de desarrollo es una conversación cara a cara.

9. La atención continua a la excelencia técnica y al buen diseño mejora agilidad.

10. La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial.

11. Las mejores arquitecturas, requisitos y diseños surgen de la autoorganización equipos.

12. A intervalos regulares, el equipo reflexiona sobre cómo volverse más eficaz, luego sintoniza y ajusta su comportamiento en consecuencia.

Estos principios enfatizan la creación de un entorno en el que los equipos ágiles puedan producir una funcionalidad de trabajo valiosa. Los enfoques ágiles fomentan la calidad en el sentido de que los productos funcionan correctamente y satisfacen las necesidades de las partes interesadas del proyecto.

La Tabla 15-1 muestra algunas diferencias entre la gestión de la calidad en proyectos tradicionales y en proyectos ágiles.

270

PARTE 4 Gestión ágil

TABLA 15-1

Calidad tradicional versus ágil

Gestión de la calidad con enfoques tradicionales

Dinámica de la calidad con enfoques ágiles

La prueba es la última fase de un proyecto antes de la implementación del

Las pruebas son una parte diaria de cada sprint y se incluyen

producto. Algunas funciones se prueban meses después de su creación.

en la definición de completado de cada requisito. Utiliza pruebas automatizadas, lo que permite realizar pruebas rápidas y sólidas todos los días.

La calidad es a menudo una práctica reactiva, que se centra principalmente en

Usted aborda la calidad tanto de manera reactiva, a través de

las pruebas de productos y la resolución de problemas.

pruebas, como de manera proactiva, fomentando las prácticas para preparar el escenario para un trabajo de calidad. Los ejemplos de enfoques de calidad proactivos incluyen la comunicación cara a cara, la programación por pares y los estándares de codificación establecidos.

Los problemas son más riesgosos cuando se encuentran al final de un proyecto. Los

Puede crear y probar funciones más riesgosas en los primeros

costos hundidos son altos cuando los equipos llegan a las pruebas.

sprints, cuando los costos hundidos aún son bajos.

Problemas o defectos, a veces llamados insectos en el desarrollo de

Los problemas son fáciles de encontrar cuando se

software, son difíciles de encontrar al final de un proyecto y las soluciones

prueba una cantidad menor de trabajo. Las correcciones

a los problemas al final de un proyecto son costosas.

son más fáciles cuando arregla algo que acaba de crear, en lugar de algo que creó meses antes.

A veces, para cumplir con un plazo o ahorrar dinero, los equipos

Las pruebas están aseguradas en proyectos ágiles porque

acortan la fase de prueba.

son parte de cada sprint.

Al comienzo de este capítulo, afirmamos que la calidad y el riesgo están estrechamente relacionados. Los enfoques ágiles de la Tabla 15-1 reducen en gran medida el riesgo y los costos innecesarios que suelen acompañar a la gestión de la calidad.

INSECTOS. ¿INSECTOS? ¡INSECTOS! ¿Por qué llamamos problemas informáticos? ¿insectos? Las primeras computadoras fueron máquinas grandes, revestidas de vidrio, que ocupaban habitaciones enteras. En 1945, una de estas computadoras gigantes, la calculadora de relés Mark II Aiken de la Universidad de Harvard, tuvo problemas con uno de sus circuitos. Los ingenieros rastrearon el problema hasta una parte, un error literal, en la máquina. Después de eso, la broma del equipo fue que cualquier problema con la computadora tenía que ser un error. El término se atascó, y la gente todavía usa bicho hoy para describir problemas de hardware, problemas de software y, a veces, incluso problemas fuera del ámbito de la informática. Los ingenieros de Harvard incluso los pegaron en un libro de registro. Ese primer error está ahora en exhibición en el Museo Nacional Smithsonian de Historia Estadounidense.

CAPITULO 15 Gestión de la calidad y el riesgo

271

Otra diferencia sobre la calidad en proyectos ágiles son los múltiples ciclos de retroalimentación de calidad a lo largo de un proyecto. En la Figura 15-1, puede ver los diferentes tipos de comentarios sobre el producto que recibe un equipo scrum en el transcurso de un proyecto. El equipo de desarrollo puede incorporar inmediatamente esta retroalimentación al producto, aumentando la calidad del producto de forma regular.

FIGURA 15-1: Comentarios de calidad

en un ágil proyecto.

En el Capítulo 14, le decimos que los equipos de desarrollo en proyectos ágiles pueden incluir a todos los que trabajan en un producto. Los equipos de desarrollo de proyectos ágiles suelen incluir personas expertas en crear y ejecutar pruebas y garantizar la calidad. Los miembros del equipo de desarrollo son multifuncionales; es decir, cada miembro del equipo puede realizar diferentes trabajos en diferentes momentos durante el proyecto. La funcionalidad cruzada se extiende a actividades de calidad como la prevención de problemas, las pruebas y la corrección de errores.

En la siguiente sección, verá cómo utilizar técnicas ágiles de gestión de proyectos para aumentar la calidad.

Gestión de la calidad ágil Los equipos de desarrollo ágiles tienen la responsabilidad principal de la calidad en los proyectos ágiles. La responsabilidad por la calidad es una extensión de las responsabilidades y libertades que conlleva la autogestión. Cuando el equipo de desarrollo tiene la libertad de determinar sus métodos de desarrollo, el equipo de desarrollo también es responsable de garantizar que esos métodos den como resultado un trabajo de calidad. Las organizaciones a menudo se refieren a la gestión de la calidad en su conjunto como seguro de calidad, o QA. Es posible que vea departamentos de control de calidad, evaluadores de control de calidad, gerentes de control de calidad, analistas de control de calidad y todos los demás tipos de títulos con prefijo de control de calidad para referirse a las personas responsables de las actividades de calidad. El control de calidad también se usa a veces como abreviatura de las pruebas, como en "realizamos un control de calidad en el producto" o "ahora estamos en la fase de control de calidad". El control de calidad (QC) también es una forma común de referirse a la gestión de la calidad.

272

PARTE 4 Gestión ágil

Los otros miembros del equipo de scrum, el Scrum Master y el Product Owner, también juegan un papel en la gestión de la calidad. Los propietarios de productos brindan una aclaración sobre los requisitos y también aceptan esos requisitos como hechos a lo largo de cada sprint. Los Scrum masters ayudan a garantizar que los equipos de desarrollo tengan un entorno de trabajo en el que las personas de los equipos de desarrollo puedan trabajar lo mejor que puedan. Afortunadamente, los enfoques de gestión de proyectos ágiles tienen varias formas de ayudar a los equipos de scrum a crear productos de calidad. En esta sección, verá cómo las pruebas en sprints aumentan la probabilidad de encontrar defectos y reducen el costo de corregirlos. Obtendrá una comprensión de las muchas formas en que la gestión ágil de proyectos fomenta de forma proactiva el desarrollo de productos de calidad. Verá cómo la inspección y la adaptación de forma regular abordan la calidad. Finalmente, descubre cómo las pruebas automatizadas son esenciales para entregar productos valiosos de forma continua a lo largo de un proyecto ágil.

Calidad y sprint La gestión de la calidad forma parte del día a día de los proyectos ágiles. Los equipos de Scrum ejecutan proyectos ágiles en sprints, ciclos de desarrollo cortos que duran de una a cuatro semanas. Cada ciclo incluye actividades de las diferentes fases de un proyecto tradicional para cada historia de usuario en el sprint: requisitos, diseño, desarrollo, pruebas e integración para la implementación. Obtenga más información sobre cómo trabajar en sprints en los capítulos 8, 9 y 10. Aquí hay un acertijo rápido: ¿es más fácil encontrar una moneda de veinticinco centavos en una mesa o en un estadio? Evidentemente, la respuesta es una mesa. Igual de obvio es que es más fácil encontrar un defecto en 100 líneas de código de software que en 100.000 líneas. El desarrollo iterativo facilita el desarrollo de productos de calidad. Los equipos de Scrum prueban a lo largo de cada sprint. La Figura 15-2 muestra cómo las pruebas encajan en los sprints en un proyecto ágil. Tenga en cuenta que las pruebas comienzan en el primer sprint, justo después de que los desarrolladores comienzan a crear el primer requisito en el proyecto.

Cuando los equipos de desarrollo prueban a lo largo de cada sprint, pueden encontrar y corregir defectos muy rápidamente. Con una gestión de proyectos ágil, los equipos de desarrollo crean requisitos de productos, prueban inmediatamente esos requisitos y solucionan cualquier problema inmediatamente antes de considerar el trabajo realizado. En lugar de tratar de recordar cómo arreglar algo que crearon hace semanas o meses, los equipos de desarrollo, como mucho, están arreglando el requisito en el que trabajaron uno o dos días antes. Probar todos los días en un proyecto ágil es una excelente manera de garantizar la calidad del producto. Otra forma de garantizar la calidad del producto es crear un producto mejor desde el principio. La siguiente sección le muestra diferentes formas en que la gestión ágil de proyectos le ayuda a evitar errores y crear un producto excelente.

CAPITULO 15 Gestión de la calidad y el riesgo

273

FIGURA 15-2: Pruebas dentro de los sprints.

274

PARTE 4 Gestión ágil

Calidad proactiva Un aspecto importante y a menudo descuidado de la calidad es la idea de prevenir problemas. Una serie de enfoques ágiles permiten y alientan a los equipos de scrum a crear productos de calidad de forma proactiva. Estas prácticas incluyen

» Un énfasis en la excelencia técnica y el buen diseño. » Incorporación de técnicas de desarrollo específicas de la calidad en el producto. creación

» Comunicación diaria entre el equipo de desarrollo y el propietario del producto. » Criterios de aceptación integrados en las historias de los usuarios

» Comunicación y coubicación cara a cara » Desarrollo sostenible » Inspección periódica y adaptación del trabajo y el comportamiento. Las siguientes secciones proporcionan una visión detallada de cada una de estas prácticas de calidad proactivas. Calidad significa tanto que un producto funciona correctamente como que el producto hace lo que las partes interesadas del proyecto necesitan que haga.

Atención continua a la excelencia técnica y al buen diseño. Los equipos ágiles se centran en la excelencia técnica y el buen diseño porque estos rasgos conducen a productos valiosos. ¿Cómo proporcionan los equipos de desarrollo excelentes diseños y soluciones técnicas? Una forma en que los equipos de desarrollo brindan excelencia técnica es a través de la autogestión, que les brinda la libertad de innovar técnicamente. Las organizaciones tradicionales pueden tener estándares técnicos obligatorios que pueden o no tener sentido para un proyecto determinado. Los equipos de desarrollo autoorganizados tienen la libertad de decidir si un estándar proporcionará valor en la creación de un producto o si un enfoque diferente funcionará mejor. La innovación puede conducir a un buen diseño, excelencia técnica y calidad del producto. La autogestión también proporciona a los equipos de desarrollo un sentido de propiedad del producto. Cuando las personas de los equipos de desarrollo sienten una profunda responsabilidad por el producto que están creando, a menudo se esfuerzan por encontrar las mejores soluciones y ejecutarlas de la mejor manera posible.

CAPITULO 15 Gestión de la calidad y el riesgo

275

Nada es más sofisticado que una simple solución. El compromiso organizacional también juega un papel en la excelencia técnica. Algunas empresas y organizaciones, independientemente de sus enfoques de gestión de proyectos, tienen un compromiso con la excelencia. Piense en los productos que usa todos los días y asócielos con la calidad; Es probable que esos productos provengan de empresas que valoran las buenas soluciones técnicas. Si está trabajando en un proyecto ágil para una empresa que cree en la excelencia técnica y la premia, implementar este principio ágil será fácil.

Otras empresas pueden infravalorar la excelencia técnica; Los equipos de proyectos ágiles de estas empresas pueden tener dificultades al intentar justificar la formación o las herramientas que ayudarán a crear mejores productos. Algunas empresas no establecen la conexión entre buena tecnología, buenos productos y rentabilidad. Los scrum masters y los propietarios de productos pueden necesitar educar a sus empresas sobre por qué la buena tecnología y el diseño son importantes y pueden necesitar presionar para que los equipos de desarrollo obtengan lo que necesitan para crear un gran producto. No confunda la excelencia técnica con el uso de nuevas tecnologías por el simple hecho de usar algo nuevo o moderno. Sus soluciones tecnológicas deben respaldar de manera eficiente las necesidades del producto, no solo agregarlas a un currículum vitae o al perfil de habilidades de la empresa.

Al incorporar la excelencia técnica y el buen diseño en su trabajo diario, crea un producto de calidad del que está orgulloso.

Técnicas de desarrollo de calidad Durante las últimas décadas de desarrollo de software, la motivación para ser más adaptables y ágiles ha inspirado una serie de técnicas de desarrollo ágiles que se centran en la calidad. Esta sección proporciona una vista de alto nivel de algunos enfoques de desarrollo de programación extrema (XP) que ayudan a garantizar la calidad de manera proactiva. Para obtener más información sobre las prácticas de XP, consulte el Capítulo 4. Se crearon muchas técnicas ágiles de gestión de la calidad teniendo en cuenta el desarrollo de software. Puede adaptar algunas de estas técnicas al crear otro tipo de productos, como productos de ferretería o incluso construcción de edificios. Si va a trabajar en un proyecto que no es de software, lea sobre los métodos de desarrollo en esta sección teniendo en cuenta la adaptabilidad:

» Desarrollo impulsado por pruebas (TDD): Este método de desarrollo comienza con un desarrollador que crea una prueba para el requisito que desea crear.

Luego, el desarrollador ejecuta la prueba, que debería fallar al principio porque el

276

PARTE 4 Gestión ágil

la funcionalidad aún no existe. El desarrollador desarrolla hasta que se aprueba la prueba y luego refactoriza el código: saca la mayor cantidad de código posible, sin dejar de pasar la prueba. Con TDD, sabe que la funcionalidad recién creada de un requisito funciona correctamente porque prueba mientras crea la funcionalidad y desarrolla la funcionalidad hasta que pasa la prueba.

» Programación en pareja: Con programación en pareja, los desarrolladores trabajan en grupos de dos. Ambos desarrolladores se sientan en la misma computadora y trabajan en equipo para crear

un requisito de producto. Los desarrolladores se turnan en el teclado para colaborar. Por lo general, el que está en el teclado asume un rol táctico directo, mientras que el observador asume un rol más estratégico o de navegación, mirando hacia adelante y brindando retroalimentación en el momento. Debido a que los desarrolladores están literalmente mirando por encima del hombro del otro, pueden detectar errores rápidamente. La programación por pares aumenta la calidad al proporcionar controles y equilibrios instantáneos de errores.

» Revisión por pares: Aveces llamado revisión del código por pares, a revisión por pares involucra miembros del equipo de desarrollo revisando el código de los demás. Como par programación, las revisiones por pares tienen una naturaleza colaborativa; cuando los desarrolladores revisan los productos terminados de los demás, los desarrolladores trabajan juntos para brindar soluciones a cualquier problema que encuentren. Si los equipos de desarrollo no practican la programación por pares, al menos deberían practicar revisiones de pares, que aumentan la calidad al permitir que los expertos en desarrollo busquen problemas estructurales dentro del código del producto.

» Propiedad del código colectivo: En este enfoque, todos en el desarrollo El equipo puede crear, cambiar o corregir cualquier parte del código del proyecto. Colectivo La propiedad del código puede acelerar el desarrollo, fomentar la innovación y, con varios pares de ojos en el código, ayudar a los miembros del equipo de desarrollo a encontrar defectos rápidamente.

» Integración continua: Este enfoque implica la creación de sistemas integrados el código se crea una o más veces al día. La integración continua permite

miembros del equipo de desarrollo para comprobar cómo funciona la historia de usuario que el equipo de desarrollo está creando con el resto del producto. La integración continua ayuda a garantizar la calidad al permitir que el equipo de desarrollo verifique si hay conflictos con regularidad. La integración continua es esencial para las pruebas automatizadas en proyectos ágiles; debe crear una compilación de código al final del día antes de ejecutar pruebas automatizadas durante la noche. Obtenga más información sobre las pruebas automatizadas más adelante en este capítulo.

En un proyecto ágil, el equipo de desarrollo decide qué herramientas y técnicas funcionarán mejor para el proyecto, el producto y el equipo de desarrollo individual.

CAPITULO 15 Gestión de la calidad y el riesgo

277

Muchas técnicas de desarrollo de software ágil ayudan a garantizar la calidad, y hay mucha discusión e información sobre estas técnicas en la comunidad de personas que utilizan enfoques ágiles de gestión de proyectos. Le recomendamos que aprenda más sobre estos enfoques si va a trabajar en un proyecto ágil, especialmente si es un desarrollador. Hay libros completos dedicados a algunas de estas técnicas, como el desarrollo basado en pruebas. La información que proporcionamos aquí está en la punta del iceberg. Consulte el Capítulo 22 para obtener más recomendaciones.

El propietario del producto y el equipo de desarrollo Otro aspecto de la gestión ágil de proyectos que fomenta la calidad es la estrecha relación entre el equipo de desarrollo y el propietario del producto. El propietario del producto es la voz de las necesidades comerciales del producto. En esta función, el propietario del producto trabaja con el equipo de desarrollo todos los días para garantizar que la funcionalidad satisfaga esas necesidades comerciales. Durante las etapas de planificación, el trabajo del propietario del producto es ayudar al equipo de desarrollo a comprender correctamente cada requisito. Durante el sprint, el propietario del producto responde las preguntas que el equipo de desarrollo tiene sobre los requisitos y es responsable de revisar la funcionalidad y aceptarlas como hechas. Cuando el propietario del producto acepta los requisitos, se asegura de que el equipo de desarrollo interprete correctamente la necesidad comercial de cada requisito y de que la nueva funcionalidad realice la tarea que debe realizar. En los proyectos en cascada, los ciclos de retroalimentación entre desarrolladores y propietarios de negocios son menos frecuentes, por lo que el trabajo de un equipo de desarrollo generalmente se desvía de los objetivos originales del producto establecidos en la declaración de visión del producto.

Un propietario de producto que revisa los requisitos a diario detecta las malas interpretaciones temprano. El propietario del producto puede volver a poner al equipo de desarrollo en el camino correcto, evitando una gran cantidad de tiempo y esfuerzo desperdiciados.

La declaración de la visión del producto comunica cómo su producto respalda las estrategias de la empresa u organización. La declaración de visión articula los objetivos del producto. El Capítulo 7 explica cómo crear una declaración de visión de producto.

Historias de usuario y criterios de aceptación Otra medida de calidad proactiva en proyectos ágiles son los criterios de aceptación que se integran en cada historia de usuario. En el Capítulo 7, explicamos que una historia de usuario es un formato para describir los requisitos del producto. Las historias de usuario aumentan la calidad al describir las acciones específicas que el usuario tomará para satisfacer correctamente las necesidades comerciales. La figura 15-3 muestra una historia de usuario y sus criterios de aceptación.

278

PARTE 4 Gestión ágil

FIGURA 15-3: Una historia de usuario y

aceptación Criterios.

Incluso si no describe sus requisitos en un formato de historia de usuario, considere agregar pasos de validación a cada uno de sus requisitos. Los criterios de aceptación no solo ayudan al propietario del producto a revisar los requisitos; ayudan al equipo de desarrollo a comprender cómo crear el producto en primer lugar.

Comunicación cara a cara ¿Alguna vez has tenido una conversación con alguien y sabías, con solo mirarle a la cara, que no te entendía? En el Capítulo 14, explicamos que las conversaciones cara a cara son la forma de comunicación más rápida y eficaz. Esto se debe a que los humanos transmiten información con más que solo palabras; Nuestras expresiones faciales, gestos, lenguaje corporal e incluso hacia dónde miramos contribuyen a comunicarnos y comprendernos unos a otros.

La comunicación cara a cara ayuda a garantizar la calidad en proyectos ágiles porque conduce a una mejor interpretación de los requisitos, obstáculos y discusiones entre los miembros del equipo scrum. La comunicación cara a cara regular requiere un equipo de scrum ubicado.

Desarrollo sostenible Lo más probable es que, en algún momento de su vida, se haya encontrado trabajando o estudiando muchas horas durante un período prolongado de tiempo. Es posible que incluso haya pasado una noche o dos, sin dormir en absoluto durante una noche. ¿Cómo te sentiste durante este tiempo? ¿Tomó buenas decisiones? ¿Cometiste algún error tonto? Desafortunadamente, muchos equipos en proyectos tradicionales se encuentran trabajando largas y locas horas, especialmente hacia el final de un proyecto, cuando se acerca una fecha límite y parece que la única forma de terminar es pasar semanas trabajando días extra largos. Esos largos días a menudo significan más problemas más adelante, ya que los miembros del equipo comienzan a cometer errores, algunos tontos, otros más serios, y finalmente se agotan.

CAPITULO 15 Gestión de la calidad y el riesgo

279

En proyectos ágiles, los equipos scrum ayudan a garantizar que realicen un trabajo de calidad al crear un entorno en el que los miembros del equipo de desarrollo mantienen un ritmo de trabajo constante durante todo el proyecto. Trabajar en sprints ayuda a mantener un ritmo de trabajo constante; cuando el equipo de desarrollo elige el trabajo que puede realizar en cada sprint, no debería tener que apresurarse al final. El equipo de desarrollo puede determinar qué significa sostenible para sí mismo, ya sea que eso signifique trabajar una semana laboral regular de 40 horas, un horario con más o menos días u horas, o trabajar fuera de un marco de tiempo estándar de nueve a cinco. Si los miembros de su equipo de scrum comienzan a trabajar con la camiseta puesta al revés, es posible que desee volver a verificar que está manteniendo un entorno de desarrollo sostenible.

Mantener al equipo de desarrollo feliz, descansado y capaz de tener una vida fuera del trabajo puede conducir a menos errores, más creatividad e innovación y mejores productos en general.

Ser proactivo con la calidad le ahorra muchos dolores de cabeza a largo plazo. Es mucho más fácil y agradable trabajar en un producto con menos defectos que reparar. La siguiente sección analiza un enfoque ágil que aborda la calidad tanto desde un punto de vista proactivo como reactivo: inspeccionar y adaptar.

Calidad mediante inspección y adaptación periódicas El principio ágil de inspeccionar y adaptar es clave para crear productos de calidad. A lo largo de un proyecto ágil, usted observa tanto su producto como su proceso (inspecciona) y realiza los cambios necesarios (se adapta). Los capítulos 7 y 10 tienen más información sobre este principio. En la revisión del sprint y las reuniones retrospectivas del sprint, los equipos de proyectos ágiles dan un paso atrás y revisan su trabajo y métodos y determinan cómo hacer ajustes para un mejor proyecto. Proporcionamos detalles sobre la revisión del sprint y la retrospectiva del sprint en el Capítulo 10. A continuación, se ofrece una descripción general rápida de cómo estas reuniones ayudan a garantizar la calidad en proyectos ágiles. En una revisión de sprint, los equipos de proyectos ágiles revisan los requisitos completados al final de cada sprint. Las revisiones de Sprint abordan la calidad al permitir que las partes interesadas del proyecto vean los requisitos de trabajo y brinden comentarios sobre esos requisitos a lo largo del curso del proyecto. Si un requisito no cumple con las expectativas de las partes interesadas, las partes interesadas informan al equipo de scrum de inmediato. El equipo scrum puede entonces

280

PARTE 4 Gestión ágil

ajustar el producto en un sprint futuro. El equipo de scrum también puede aplicar su comprensión revisada de cómo el producto debe funcionar en otros requisitos del producto. En una retrospectiva de sprint, los equipos de scrum se reúnen para discutir qué funcionó y qué podría necesitar un ajuste al final de cada sprint. Las retrospectivas de Sprint ayudan a garantizar la calidad al permitir que el equipo de scrum discuta y solucione los problemas de inmediato. Las retrospectivas de Sprint también permiten que el equipo se reúna y discuta formalmente los cambios en el producto, proyecto o entorno de trabajo que podrían aumentar la calidad. La revisión del sprint y la retrospectiva del sprint no son las únicas oportunidades para inspeccionar y adaptar la calidad en un proyecto ágil. Los enfoques ágiles fomentan la revisión del trabajo y el ajuste de comportamientos y métodos a lo largo de cada jornada laboral. La inspección diaria y la adaptación de todo lo que hace en el proyecto ayuda a garantizar la calidad. Otra forma de administrar y ayudar a asegurar la calidad en un proyecto ágil es utilizar herramientas de prueba automatizadas. La siguiente sección explica por qué las pruebas automatizadas son importantes para proyectos ágiles y cómo incorporar las pruebas automatizadas en su proyecto.

Pruebas automatizadas La prueba automatizada es el uso de software para probar su producto. Las pruebas automatizadas son fundamentales para proyectos ágiles. Si desea crear rápidamente una funcionalidad de software que cumpla con la definición de hecho (codificado, probado, integrado y documentado), necesita una forma de probar rápidamente cada pieza de funcionalidad a medida que se crea. Las pruebas automatizadas significan pruebas rápidas y sólidas a diario. Los equipos ágiles aumentan continuamente la frecuencia con la que prueban automáticamente su sistema para que puedan disminuir continuamente el tiempo que les lleva completar e implementar nuevas funciones valiosas para sus clientes. Los equipos de proyecto no se volverán ágiles sin pruebas automatizadas. La prueba manual simplemente lleva demasiado tiempo.

A lo largo de este libro, explicamos cómo los equipos de proyectos ágiles adoptan soluciones de baja tecnología. Entonces, ¿por qué hay una sección en este libro sobre pruebas automatizadas, una técnica de gestión de la calidad de alta tecnología? La respuesta a esta pregunta es la eficiencia. Las pruebas automatizadas son como la función de revisión ortográfica de los programas de procesamiento de texto. De hecho, la revisión ortográfica es una forma de prueba automatizada. De la misma manera, las pruebas automatizadas son un método mucho más rápido y, a menudo, más preciso, y por lo tanto, más eficiente, para encontrar defectos de software que las pruebas manuales.

CAPITULO 15 Gestión de la calidad y el riesgo

281

Para desarrollar un producto mediante pruebas automatizadas, los equipos de desarrollo desarrollan y prueban siguiendo los siguientes pasos:

1. Desarrolle código y pruebas automatizadas para respaldar las historias de los usuarios durante el día.

2. Cree una compilación de código integrada al final de cada día. 3. Programe el software de prueba automatizado para probar la compilación más reciente durante la noche. 4. Compruebe los resultados de las pruebas automatizadas a primera hora de cada mañana. 5. Corrija cualquier defecto inmediatamente. Las pruebas de código completas mientras duermes son geniales. Las pruebas automatizadas permiten a los equipos de desarrollo aprovechar el tiempo no laborable para la productividad y tener ciclos rápidos de creación, prueba y reparación. Además, el software de prueba automatizado a menudo puede probar los requisitos más rápido y con más precisión y consistencia que una persona que prueba esos requisitos. El mercado actual tiene muchas herramientas de prueba automatizadas. Algunas herramientas de prueba automatizadas son de código abierto y gratuitas; otros están disponibles para su compra. El equipo de desarrollo debe revisar las opciones de prueba automatizadas y elegir la herramienta que funcione mejor.

Las pruebas automatizadas cambian el trabajo de las personas en roles de calidad en el equipo de desarrollo. Tradicionalmente, una gran parte del trabajo de una persona de gestión de calidad implicaba probar productos manualmente. El evaluador de un proyecto tradicional usaría el producto y buscaría problemas. Sin embargo, con las pruebas automatizadas, las actividades de calidad implican en gran medida la creación de pruebas para ejecutarlas en software de pruebas automatizadas. Las herramientas de prueba automatizadas aumentan, en lugar de reemplazar, las habilidades, el conocimiento y el trabajo de las personas.

Sigue siendo una buena idea que los humanos comprueben periódicamente que los requisitos que está desarrollando funcionan correctamente, especialmente cuando comienza a utilizar una herramienta de prueba automatizada. Cualquier herramienta automatizada puede tener contratiempos de vez en cuando. Al verificar manualmente (a veces llamado prueba de humo) pequeñas partes de las pruebas automatizadas, ayuda a evitar llegar al final de un sprint y descubrir que su producto no funciona como debería.

Puede automatizar casi cualquier tipo de prueba de software. Si es nuevo en el desarrollo de software, es posible que no sepa que existen muchos tipos diferentes de pruebas de software. Una pequeña muestra incluye lo siguiente:

» Examen de la unidad: Prueba unidades individuales, o las partes más pequeñas, del código de producto.

» Pruebas de regresión: Prueba un producto completo de principio a fin, incluido requisitos que ha probado anteriormente.

282

PARTE 4 Gestión ágil

» Pruebas de aceptación del usuario: Partes interesadas del producto o incluso algunas de las Los usuarios finales del producto revisan un producto y lo aceptan como completo.

» Pruebas funcionales: Pruebas para asegurarse de que el producto funciona de acuerdo con criterios de aceptación de la historia del usuario.

» Pruebas de integración: Pruebas para asegurarse de que el producto funciona con otras piezas. del producto.

» Pruebas empresariales: Pruebas para asegurarse de que el producto funciona con otros productos en la organización, según sea necesario.

» Pruebas de rendimiento: Prueba la rapidez con la que se ejecuta un producto en un sistema determinado. bajo diferentes escenarios.

» Prueba de carga: Prueba qué tan bien un producto maneja diferentes cantidades de actividad concurrente.

» Prueba de humo: Pruebas en partes pequeñas pero críticas del código o de un sistema para ayudar a determinar si es probable que funcione el sistema en su conjunto.

» Prueba estática: Se enfoca en verificar los estándares del código, en lugar de trabajar software.

Las pruebas automatizadas funcionan para estas pruebas y muchos otros tipos de pruebas de software que existen.

Como ya comprenderá, la calidad es una parte integral de los proyectos ágiles. Sin embargo, la calidad es solo un factor que diferencia el riesgo en proyectos ágiles de los proyectos tradicionales. En las siguientes secciones, verá cómo el riesgo en proyectos tradicionales se compara con el riesgo en proyectos ágiles.

¿Qué tiene de diferente la gestión ágil de riesgos? Riesgo se refiere a los factores que contribuyen al éxito o fracaso de un proyecto. En proyectos ágiles, la gestión de riesgos no tiene por qué implicar reuniones y documentación de riesgos formales. En cambio, la gestión de riesgos se integra en roles, artefactos y eventos de scrum. Además, considere los siguientes principios ágiles que respaldan la gestión de riesgos:

1. Nuestra máxima prioridad es satisfacer al cliente a través de un proceso temprano y continuo. entrega de software valioso.

CAPITULO 15 Gestión de la calidad y el riesgo

283

Bienvenidos los requisitos cambiantes, incluso al final del desarrollo. Los procesos ágiles aprovechan el cambio para la ventaja competitiva del cliente.

Entregue software que funcione con frecuencia, desde un par de semanas hasta un par de meses, con preferencia a la escala de tiempo más corta.

Los empresarios y los desarrolladores deben trabajar juntos a diario durante todo el proyecto.

El software que funciona es la principal medida de progreso.

Los principios anteriores, y cualquier práctica que demuestre esos principios, mitigan o eliminan significativamente muchos riesgos que frecuentemente conducen a desafíos y fallas en el proyecto. Según el “Informe del caos 2015” de Standish Group, un estudio de 10.000 proyectos de software, los proyectos pequeños y ágiles tienen un 30 por ciento más de probabilidades de éxito que los proyectos tradicionales. Vea la Figura 15-4. Los proyectos de tamaño mediano tienen cuatro veces (400 por ciento) más probabilidades de éxito con un enfoque ágil que con un enfoque tradicional, y los proyectos grandes y complejos tienen seis veces (600 por ciento) más probabilidades de éxito con un enfoque ágil.

FIGURA 15-4: Standish Group “Caos 2015 Informe."

284

PARTE 4 Gestión ágil

La Tabla 15-2 muestra algunas de las diferencias entre el riesgo en proyectos tradicionales y en proyectos ágiles.

TABLA 15-2

Riesgo tradicional versus riesgo ágil

Gestión de riesgos con enfoques tradicionales

Dinámica de riesgo con enfoques ágiles

Un gran número de proyectos fracasan o son desafiados.

El riesgo de una falla catastrófica (gastar grandes cantidades de dinero sin nada que mostrar) está casi eliminado.

Cuanto más grande, más largo y más complejo sea el

El valor del producto se gana de inmediato, en lugar de hundir

proyecto, más riesgoso será. El riesgo es mayor al final de

los costos en un proyecto durante meses o incluso años con la

un proyecto.

creciente posibilidad de fracaso.

Realizar todas las pruebas al final de un proyecto significa

Las pruebas se realizan mientras se desarrolla. Si un enfoque

que encontrar problemas graves puede poner en riesgo

técnico, un requisito o incluso un producto completo no es

todo el proyecto.

factible, el equipo de desarrollo lo descubre en poco tiempo y usted tiene más tiempo para corregir el rumbo. Si la corrección no es posible, las partes interesadas gastan menos dinero en un proyecto fallido.

Los proyectos no pueden adaptarse a los nuevos requisitos a mitad del proyecto sin un mayor tiempo y costo porque existe un gran costo irrecuperable incluso en los requisitos de menor prioridad.

Los proyectos tradicionales requieren estimaciones de tiempo y costos al inicio del proyecto, cuando los equipos saben menos sobre el proyecto. Las estimaciones a menudo son inexactas, lo que crea una brecha entre los cronogramas y presupuestos previstos y reales del proyecto.

Se agradece el cambio en beneficio del producto. Los proyectos ágiles se adaptan a los nuevos requisitos de alta prioridad sin aumentar el tiempo o el costo al eliminar un requisito de baja prioridad de igual tiempo y costo. El tiempo y el costo del proyecto se estiman utilizando el rendimiento real o la velocidad del equipo de scrum. Refina las estimaciones a lo largo del proyecto, porque cuanto más tiempo trabaja en un proyecto, más aprende sobre el proyecto, los requisitos y el equipo scrum.

Cuando las partes interesadas no tienen un objetivo unificado,

Un único propietario de producto es responsable de crear una

pueden terminar confundiendo al equipo del proyecto con

visión para el producto y representa a las partes interesadas en

información contradictoria sobre lo que debería lograr el

el equipo del proyecto.

producto. Las partes interesadas que no responden o están ausentes pueden causar retrasos en el proyecto y dar como resultado productos que no logran los objetivos correctos.

El propietario del producto es responsable de proporcionar información sobre el producto de inmediato. Además, el scrummaster ayuda a eliminar los impedimentos a diario.

El riesgo en proyectos ágiles disminuye a medida que avanza el proyecto. La figura 15-5 muestra una comparación de riesgo y tiempo entre proyectos en cascada y proyectos ágiles. Todos los proyectos tienen algún riesgo, independientemente del enfoque de su proyecto. Sin embargo, con una gestión de proyectos ágil, los días del fracaso catastrófico del proyecto: gastos

CAPITULO 15 Gestión de la calidad y el riesgo

285

grandes cantidades de tiempo y dinero sin retorno de la inversión (ROI), se acabaron. La eliminación de fallas a gran escala es la mayor diferencia entre el riesgo en proyectos tradicionales y en proyectos ágiles. En la siguiente sección, verá por qué.

FIGURA 15-5: Proyectos ágiles ' riesgo decreciente

modelo.

Gestionar el riesgo ágil En esta sección, examina las estructuras clave de proyectos ágiles que reducen el riesgo durante la vida del proyecto. Averigua cómo utilizar herramientas y eventos ágiles para encontrar riesgos en el momento adecuado en un proyecto y cómo priorizar y mitigar esos riesgos.

Reducir el riesgo de forma inherente Los enfoques ágiles, cuando se implementan correctamente, reducen inherentemente el riesgo en el desarrollo de productos. El desarrollo en sprints asegura un corto tiempo entre la inversión del proyecto y la prueba de que el producto funciona. Los Sprints también brindan la posibilidad de que un proyecto genere ingresos temprano. La revisión del sprint, la retrospectiva del sprint y la participación del propietario del producto durante cada sprint brindan comentarios constantes sobre el producto al equipo de desarrollo. La retroalimentación continua ayuda a prevenir desviaciones entre las expectativas del producto y el producto terminado. Tres factores especialmente importantes en la reducción de riesgos en proyectos ágiles son la definición de proyectos realizados, autofinanciados y la idea de fallar rápidamente. Encontrará más información sobre cada uno de estos factores en esta sección.

286

PARTE 4 Gestión ágil

Riesgo y la definición de hecho En el Capítulo 10, discutimos cuándo se cumple un requisito. Para considerar un requisito completo y listo para demostrar al final de un sprint, ese requisito debe cumplir con la definición de hecho del equipo scrum. El propietario del producto y el equipo de desarrollo acuerdan los detalles de la definición; Las definiciones de hecho generalmente incluyen lo siguiente:

» Desarrollado: El equipo de desarrollo debe crear completamente el producto de trabajo. requisito.

» Probado: El equipo de desarrollo debe haber probado que el producto funciona correctamente y sin defectos.

» Integrado: El equipo de desarrollo debe haberse asegurado de que el requisito funciona con todo el producto y cualquier sistema relacionado.

» Documentado: El equipo de desarrollo debe haber creado notas sobre cómo creó el producto y la justificación detrás de las decisiones técnicas clave tomadas.

La figura 15-6 muestra una definición de muestra de hecho, con detalles.

FIGURA 15-6: Muestra definicion de hecho.

El propietario del producto y el equipo de desarrollo también pueden crear una lista de riesgos aceptables. Por ejemplo, pueden estar de acuerdo en que las pruebas de regresión de un extremo a otro o las pruebas de rendimiento son excesivas para la definición de sprint de hecho. O, con la nube

CAPITULO 15 Gestión de la calidad y el riesgo

287

informática, las pruebas de carga pueden no ser tan cruciales porque se puede agregar capacidad adicional fácil y rápidamente a pedido a costos nominales. Los riesgos aceptables permiten que el equipo de desarrollo se concentre en las actividades más importantes. La definición de hecho cambia drásticamente el factor de riesgo para proyectos ágiles. Al crear un producto que cumple con la definición de hecho en cada sprint, finaliza cada sprint con una compilación funcional y una funcionalidad utilizable. Incluso si los factores externos hacen que un proyecto finalice antes de tiempo, las partes interesadas del proyecto siempre verán algún valor y tendrán una funcionalidad de trabajo para usar ahora y desarrollar más tarde.

Proyectos autofinanciados Los proyectos ágiles pueden mitigar el riesgo financiero de una manera única que los proyectos tradicionales no pueden: el proyecto autofinanciado. El capítulo 13 incluye ejemplos de proyectos autofinanciados. Si su producto es un producto que genera ingresos, podría utilizar esos ingresos para ayudar a financiar el resto de su proyecto.

En el Capítulo 13, le mostramos dos modelos de ROI de proyectos diferentes. Aquí están de nuevo, en las Tablas 15-3 y 15-4. Los proyectos en ambas tablas crean productos idénticos.

TABLA 15-3

Ingresos de un proyecto tradicional con un lanzamiento final después de seis meses

Mes

Ingresos generados

Ingresos totales del proyecto

enero

febrero

marcha

abril

Mayo

junio

mes de julio

$ 100,000

En la Tabla 15-3, el proyecto generó $ 100,000 en ingresos después de seis meses de desarrollo. Ahora compare el ROI de la tabla 15-3 con el ROI de la tabla 15-4. En la Tabla 15-4, el proyecto generó ingresos con el primer lanzamiento. Al final de los seis meses, el proyecto había generado $ 330 000, $ 230 000 más que el proyecto de la Tabla 15-3.

288

PARTE 4 Gestión ágil

TABLA 15-4

Ingresos de un proyecto ágil con lanzamientos mensuales y un lanzamiento final después de seis meses

Mes / lanzamiento

Ingresos generados

Ingresos totales del proyecto

enero

febrero

$ 15 000

marcha

$ 25 000

$ 40 000

abril

$ 40 000

$ 80 000

Mayo

$ 70 000

$ 150 000

junio

$ 80 000

$ 230 000

mes de julio

$ 100,000

$ 330 000

La capacidad de generar ingresos en un corto período de tiempo tiene una serie de beneficios para las empresas y los equipos de proyectos. Los proyectos ágiles autofinanciados tienen un buen sentido financiero para casi cualquier organización, pero pueden ser especialmente útiles para organizaciones que pueden no tener los fondos para crear un producto por adelantado. Para los grupos con poco dinero en efectivo, la autofinanciación puede permitir proyectos que de otro modo no serían viables.

Los proyectos autofinanciados también ayudan a mitigar el riesgo de que un proyecto se cancele por falta de fondos. Una emergencia de la empresa puede obligar a desviar el presupuesto de un proyecto tradicional a otra parte, retrasando o cancelando el proyecto. Sin embargo, un proyecto ágil que genera ingresos adicionales con cada lanzamiento tiene buenas posibilidades de continuar durante una crisis. Por último, los proyectos autofinanciados ayudan a vender a las partes interesadas un proyecto en primer lugar; Es difícil discutir con un proyecto que proporciona un valor continuo y paga al menos parte de los costos del proyecto desde el principio.

Fallando rapido Todos los esfuerzos de desarrollo de productos conllevan cierto riesgo de fracaso. Las pruebas dentro de los sprints introducen la idea de fallando rápido: En lugar de hundir los costos en un largo esfuerzo por los requisitos, el diseño y el desarrollo, y luego encontrar problemas que evitarán que el proyecto avance durante la fase de prueba, los equipos de desarrollo en proyectos ágiles pueden identificar problemas críticos en unos pocos sprints. Esta mitigación cuantitativa del riesgo puede ahorrar a las organizaciones grandes cantidades de dinero. Las tablas 15-5 y 15-6 ilustran la diferencia en los costos hundidos para un proyecto de cascada fallido y un proyecto ágil fallido. Los proyectos en ambas tablas son para productos idénticos con costos idénticos.

CAPITULO 15 Gestión de la calidad y el riesgo

289

TABLA 15-5

Costo de falla en un proyecto de cascada

Mes

Fase y problemas

Costo hundido del proyecto

Costo total del proyecto hundido

enero

Fase de requisitos

$ 80 000

febrero

Fase de requisitos

$ 80 000

$ 160 000

marcha

Fase de diseño

$ 80 000

$ 240 000

abril

Fase de diseño

$ 80 000

$ 320 000

Mayo

Fase de diseño

$ 80 000

$ 400 000

junio

Fase de desarrollo

$ 80 000

$ 480 000

mes de julio

Fase de desarrollo

$ 80 000

$ 560 000

agosto

Fase de desarrollo

$ 80 000

$ 640 000

septiembre

Fase de desarrollo

$ 80 000

$ 720 000

octubre

Fase de control de calidad: problema a gran

$ 80 000

$ 800 000

$ 80 000

$ 880 000

escala descubierto durante las pruebas.

noviembre

Fase de control de calidad: el equipo de desarrollo intentó resolver el problema para continuar con el desarrollo.

diciembre

Proyecto cancelado; producto no viable.

En la Tabla 15-5, las partes interesadas del proyecto pasaron 11 meses y cerca de un millón de dólares para descubrir que la idea de un producto no funcionaría. Compare el costo hundido de la tabla 15-5 con el de la tabla 15-6.

TABLA 15-6

Costo del fracaso en un proyecto ágil

Mes

Sprint y problemas

Costo hundido del proyecto

Costo total del proyecto hundido

enero

Sprint 1: Sin problemas.

$ 80 000

$ 160 000

Sprint 2: Sin problemas.

febrero

Sprint 3: Un problema a gran escala descubierto durante la prueba resultó en un sprint fallido.

Sprint 4: el equipo de desarrollo intentó resolver el problema para continuar

desarrollo; sprint finalmente falló. Final

290

Proyecto cancelado; producto no viable.

PARTE 4 Gestión ágil

Al realizar pruebas anticipadas, el equipo de desarrollo de la Tabla 15-6 determinó que el producto no funcionaría a fines de febrero, gastando menos de una sexta parte del tiempo y dinero gastado en el proyecto de la Tabla 15-5. Debido a la definición de hecho, incluso los proyectos fallidos producen algo tangible que una organización puede aprovechar o mejorar. Por ejemplo, el proyecto fallido en la Tabla 15-5 habría proporcionado funcionalidad de trabajo en los dos primeros sprints.

El concepto de fallar rápidamente puede aplicarse más allá de los problemas técnicos de un producto. También puede usar el desarrollo dentro de los sprints y la falla rápida para ver si un producto funcionará en el mercado y cancelar el proyecto antes de tiempo si parece que los clientes no comprarán ni usarán el producto. Al lanzar pequeñas partes del producto y probarlo con clientes potenciales al principio del proyecto, tendrá una buena idea de si su producto es comercialmente viable y ahorrará grandes cantidades de dinero si descubre que la gente no lo comprará. También descubre cambios importantes que podría realizar en el producto para satisfacer mejor las necesidades del cliente. Finalmente, fallar rápido no significa necesariamente la cancelación del proyecto. Si encuentra problemas catastróficos cuando los costos hundidos son bajos, es posible que tenga el tiempo y el presupuesto para determinar un enfoque completamente diferente para crear un producto.

La definición de proyectos realizados, autofinanciados y la idea de fallar rápidamente, junto con la base de los principios ágiles, ayudan a reducir el riesgo en proyectos ágiles. En la siguiente sección, verá cómo utilizar activamente herramientas de gestión de proyectos ágiles para gestionar el riesgo.

Identificar, priorizar y responder a los riesgos de manera temprana Aunque la estructura de los proyectos ágiles reduce de forma inherente muchos riesgos tradicionales, los equipos de desarrollo deben ser conscientes de los problemas que pueden surgir durante un proyecto. Los equipos de Scrum se autogestionan; De la misma manera que son responsables de la calidad, los equipos de scrum son responsables de tratar de identificar los riesgos y las formas de evitar que esos riesgos se materialicen.

En proyectos ágiles, primero prioriza los requisitos de mayor valor y mayor riesgo.

En lugar de pasar horas o días documentando todos los riesgos potenciales de un proyecto, la probabilidad de que ocurran esos riesgos, la gravedad de esos riesgos y las formas de mitigar esos riesgos, los equipos de scrum utilizan los artefactos y reuniones ágiles existentes para

CAPITULO 15 Gestión de la calidad y el riesgo

291

gestionar el riesgo. Los equipos de Scrum también esperan hasta el último minuto responsable para abordar el riesgo, cuando saben más sobre el proyecto y los problemas que es más probable que surjan. La Tabla 15-7 muestra cómo los equipos scrum pueden usar las diferentes herramientas ágiles de gestión de proyectos para gestionar el riesgo en el momento adecuado.

TABLA 15-7

Herramientas ágiles de gestión de riesgos de proyectos

Artefacto o reunión

Papel en la gestión de riesgos

Visión del producto

La declaración de la visión del producto ayuda a unificar la definición de los objetivos del producto por parte del equipo del proyecto, lo que mitiga el riesgo de malentendidos sobre lo que el producto deberá lograr. Al crear la visión del producto, el equipo del proyecto puede pensar en los riesgos a un nivel muy alto, basándose en la retroalimentación del mercado y de los clientes, y en línea con la estrategia organizacional. Obtenga más información sobre la visión del producto en el Capítulo 7.

Hoja de ruta del producto

La hoja de ruta del producto proporciona una descripción visual de los requisitos y prioridades del proyecto. Esta descripción general permite al equipo del proyecto identificar rápidamente las brechas en los requisitos y los requisitos priorizados incorrectamente. Obtenga más información sobre la hoja de ruta del producto en el Capítulo 7.

Pila de Producto

La cartera de productos es una herramienta para adaptarse al cambio en el proyecto. Ser capaz de agregar cambios a la acumulación de productos y volver a priorizar los requisitos con regularidad ayuda a convertir el riesgo tradicional asociado con los cambios de alcance en una forma de crear un mejor producto. Mantener actualizados los requisitos y las prioridades en la acumulación de productos ayuda a garantizar que el equipo de desarrollo pueda trabajar en los requisitos más importantes en el momento adecuado. Obtenga más información sobre la acumulación de productos en los capítulos 7 y 8.

Planificación de lanzamientos

Durante la planificación del lanzamiento, el equipo de scrum analiza los riesgos del lanzamiento y cómo mitigar esos riesgos. Las discusiones sobre riesgos en la reunión de planificación de la versión deben ser de alto nivel y estar relacionadas con la versión en su conjunto. Aborde los riesgos con requisitos individuales en las reuniones de planificación de sprints. Obtenga más información sobre la planificación de lanzamientos en el Capítulo 8.

Planificación de Sprint

Durante cada reunión de planificación de sprints, el equipo de scrum analiza los riesgos de los requisitos y tareas específicos en el sprint y cómo mitigar esos riesgos. Las discusiones sobre riesgos durante la planificación del sprint se pueden realizar en profundidad, pero solo deben estar relacionadas con el sprint actual. Obtenga más información sobre la planificación de sprints en el Capítulo 8.

Cartera de Sprint

El gráfico de evolución en la acumulación de sprints proporciona una vista rápida del estado del sprint. Esta vista rápida ayuda al equipo de scrum a administrar los riesgos del sprint a medida que surgen y a minimizar su efecto al abordar los problemas de inmediato. Obtenga más información sobre los trabajos pendientes de Sprint y cómo los gráficos de evolución muestran el estado del proyecto en el Capítulo 9.

Scrum diario

Durante cada scrum diario, los miembros del equipo de desarrollo discuten los obstáculos. Los obstáculos o impedimentos a veces son riesgos. Hablar sobre obstáculos todos los días le da al equipo de desarrollo y al scrummaster la oportunidad de mitigar esos riesgos de inmediato. Obtenga más información sobre el scrum diario en el Capítulo 9.

292

PARTE 4 Gestión ágil

Artefacto o reunión

Papel en la gestión de riesgos

Tablero de tareas

El tablero de tareas proporciona una vista inevitable del estado del sprint, lo que permite al equipo de scrum detectar los riesgos del sprint y gestionarlos de inmediato. Obtenga más información sobre los tableros de tareas en el Capítulo 9.

Revisión de Sprint

Durante la revisión del sprint, el equipo de scrum se asegura regularmente de que el producto cumpla con las expectativas de las partes interesadas. La revisión del sprint también brinda oportunidades para que las partes interesadas discutan los cambios en el producto para adaptarse a las necesidades comerciales cambiantes. Ambos aspectos de la revisión del sprint ayudan a gestionar el riesgo de llegar al final de un proyecto con el producto incorrecto. Obtenga más información sobre las revisiones de sprint en el Capítulo 10.

Sprint retrospectiva

Durante la retrospectiva del sprint, el equipo de scrum discute problemas con el sprint pasado e identifica cuáles de esos problemas pueden ser riesgos en sprints futuros. El equipo de desarrollo debe determinar formas de evitar que esos riesgos vuelvan a convertirse en problemas. Obtenga más información sobre las retrospectivas de sprint en el Capítulo 10.

Los artefactos y reuniones discutidos en esta sección ayudan sistemáticamente a los equipos ágiles a administrar el riesgo en un proyecto ágil al abordar el riesgo por parte de los roles responsables en los momentos apropiados. Cuanto más grande y complejo sea el proyecto, mayor será la probabilidad de que un enfoque ágil pueda eliminar el riesgo de fracaso.

CAPITULO 15 Gestión de la calidad y el riesgo

293

Asegurando Agile

Éxito

EN ESTA PARTE . . .

Construya una base a través del compromiso organizacional e individual para ser más ágil. Elija un proyecto y cree un entorno que optimice el éxito de la transición ágil. Escale las técnicas ágiles en proyectos de varios equipos de forma adecuada. Conviértase en un agente de cambio en su organización y ayude a evitar errores comunes en las transiciones ágiles.

EN ESTE CAPÍTULO

» Obtener organizacionales y compromiso individual » Armado de equipos con lo necesario destrezas y habilidades

» Establecer una adecuada ambiente » Invertir en formación

» Asegurar soporte inicial y continuo

Capítulo

dieciséis

BuildingaFundación

procesos, debe comenzar con una buena base. Necesita compromiso, tanto de su organización como las personas como individuos, y necesita o pasar con éxito dede los procesos tradicionales de gestión de proyectos a los

para encontrar un buen equipo de proyecto para su primer proyecto ágil, proporcionándoles un entorno

mento propicio para enfoques ágiles. Quiere encontrar la formación adecuada para su equipo de proyecto y apoyar de forma sostenible el enfoque ágil de su organización para que pueda crecer más allá de su primer proyecto. En este capítulo, le mostramos cómo construir una base ágil sólida dentro de su organización.

Organizacional e Individual Compromiso El compromiso con la gestión ágil de proyectos significa hacer un esfuerzo activo y consciente para trabajar con nuevos métodos y abandonar los viejos hábitos. El compromiso tanto a nivel individual como a nivel organizacional es fundamental para el éxito de la transición ágil.

CAPITULO 16 Construyendo una base

297

Sin el apoyo de la organización, incluso los miembros más entusiastas del equipo de proyectos ágiles pueden verse obligados a volver a los viejos procesos de gestión de proyectos. Sin el compromiso de los miembros individuales del equipo del proyecto, una empresa que adopte enfoques ágiles puede encontrar demasiada resistencia, o incluso sabotaje, para poder convertirse en una organización ágil. Las siguientes secciones proporcionan detalles sobre cómo las organizaciones y las personas pueden respaldar una transición ágil.

Compromiso organizacional El compromiso organizacional juega un papel importante en la transición ágil. Cuando una empresa y los grupos de esa empresa adoptan principios ágiles, la transición puede ser más fácil para los miembros del equipo del proyecto. Las organizaciones pueden comprometerse con una transición ágil haciendo lo siguiente:

» Contratar a un experto ágil con experiencia para crear un plan de transición realista y para guiar a la empresa a través de ese plan

» Invertir en la formación de los empleados, empezando por los miembros de la empresa. primer equipo de proyecto ágil y el liderazgo en todos los niveles que los apoya

» Permitir que los equipos de scrum abandonen los procesos en cascada, las reuniones y documentos a favor de enfoques ágiles simplificados

» Asegurar que todos los miembros del equipo scrum necesarios para cada proyecto ágil estén dedicado: un propietario de producto empoderado, un desarrollo multifuncional

equipo de personas polivalentes y un influyente líder-servidor scrummaster

» Alentar a los equipos de desarrollo a aumentar continuamente sus habilidades. » Proporcionar herramientas de prueba automatizadas y un marco de integración continua. » Apoyar logísticamente la colocación del equipo scrum » Permitir que los equipos de scrum se gestionen a sí mismos

» Dar al equipo ágil del proyecto el tiempo y la libertad para pasar por una proceso de prueba y error

» Revisar las evaluaciones del desempeño de los empleados para enfatizar el desempeño del equipo.

» Fomentar equipos de proyectos ágiles y celebrar los éxitos El apoyo organizacional también es importante más allá de la transición ágil. Las empresas pueden garantizar que los procesos ágiles sigan funcionando si contratan a equipos de proyectos ágiles y brindan capacitación ágil a los nuevos empleados. Las organizaciones también pueden

298

PARTE 5 Asegurar el éxito ágil

contrate el apoyo continuo de un mentor ágil, que puede guiar a los equipos del proyecto a medida que se encuentran con situaciones nuevas y desafiantes.

Las organizaciones, por supuesto, están formadas por individuos. El compromiso organizacional y el compromiso individual van de la mano.

Compromiso individual El compromiso individual tiene un papel igual al compromiso organizacional en las transiciones ágiles. Cuando cada persona en un equipo de proyecto trabaja para adoptar prácticas ágiles, los cambios se vuelven más fáciles para todos en el equipo de proyecto. Las personas pueden comprometerse individualmente con una transición ágil utilizando estos métodos:

» Asistir a capacitaciones y conferencias y estar dispuesto a aprender sobre métodos ágiles

» Estar abierto al cambio, dispuesto a probar nuevos procesos y esforzándose por adaptar nuevos hábitos

» Resistir la tentación de recurrir a viejos procesos » Actuar como asesor de pares para los miembros del equipo del proyecto que tienen menos experiencia en técnicas ágiles

» Permitirse cometer errores y aprender de esos errores. » Reflexionar sobre cada sprint con honestidad en la retrospectiva del sprint y comprometerse a los esfuerzos de mejora

» Convertirse activamente en miembros del equipo de desarrollo con múltiples habilidades

» Dejar ir el ego y trabajar como parte de un equipo » Asumir la responsabilidad de los éxitos y fracasos como equipo. » Tomando la iniciativa para ser autogestionado

» Estar activo y presente en cada proyecto ágil Al igual que el compromiso organizacional, el compromiso individual es importante más allá del período de transición ágil. Las personas del primer equipo de proyecto ágil se convertirán en agentes de cambio en toda la empresa, preparando el escenario y ejemplificando para otros equipos de proyecto cómo trabajar eficazmente con métodos ágiles.

Conseguir compromiso El compromiso con los métodos ágiles puede no ser instantáneo. Deberá ayudar a las personas de su organización a superar el impulso natural de resistir el cambio. CAPITULO 16 Construyendo una base

299

Un buen primer paso en una transición ágil es encontrar un campeón ágil, un gerente o ejecutivo de alto nivel que pueda ayudar a garantizar el cambio organizacional. Los cambios fundamentales en los procesos que acompañan a las transiciones ágiles requieren el apoyo de las personas que toman y hacen cumplir las decisiones comerciales. Un buen campeón ágil podrá unir a la organización y a su gente en torno a los cambios de proceso. Otra forma importante de comprometerse es identificar desafíos con los proyectos actuales de la organización y brindar soluciones potenciales con enfoques ágiles. La gestión ágil de proyectos puede abordar muchos problemas, incluidos problemas con la calidad del producto, la satisfacción del cliente, la moral del equipo, los excesos de presupuesto y programación, la financiación, la gestión de la cartera y los problemas generales del proyecto. Por último, destaque algunos de los beneficios generales de la gestión ágil de proyectos. Algunos de los beneficios reales y tangibles que impulsan los cambios de los métodos tradicionales de gestión de proyectos a métodos ágiles incluyen los siguientes:

» Clientes más felices: Los proyectos ágiles suelen tener una mayor satisfacción del cliente porque los equipos de proyectos ágiles producen productos de trabajo rápidamente, pueden responder

para cambiar y colaborar con los clientes como socios.

» Beneficios de ganancias: Los enfoques ágiles permiten a los equipos de proyectos ofrecer funcionalidad comercializar más rápido que con los enfoques tradicionales. Las organizaciones ágiles pueden obtener un mayor retorno de la inversión, lo que a menudo resulta en proyectos autofinanciados.

» Reducción de defectos: La calidad es una parte clave de los enfoques ágiles. Calidad proactiva medidas, integración y pruebas continuas, y mejora continua todos contribuyen a productos de mayor calidad.

» Moral mejorada: Prácticas ágiles como el desarrollo sostenible y Los equipos de desarrollo autogestionados pueden significar empleados más felices, mejorados

eficiencia y menor rotación de la empresa.

Puede encontrar más beneficios de la gestión ágil de proyectos en el Capítulo 19.

¿Puedes hacer la transición? Ha establecido muchas razones valiosas para pasar a un enfoque ágil y su caso se ve bien. Pero, ¿podrá su organización hacer la transición? Aquí hay algunas preguntas clave a considerar:

» ¿Cuáles son los obstáculos organizativos? ¿Su organización tiene un

cultura de entrega de valor o cultura de gestión de riesgos? ¿Apoya el coaching y la tutoría junto con la gestión? ¿Existe apoyo para la formación? ¿Cómo define la organización el éxito? ¿Tiene una cultura abierta que abarcará una alta visibilidad del progreso del proyecto?

300

PARTE 5 Asegurar el éxito ágil

» ¿Cómo está haciendo negocios hoy? ¿Cómo se planifican los proyectos en la macro? ¿nivel? ¿Está la organización obsesionada con un alcance fijo? ¿Qué tan comprometidos están los negocios?

representantes? ¿Subcontratas el desarrollo?

» ¿Cómo trabajan sus equipos hoy en día y qué se necesitará cambiar bajo la modalidad ágil? ¿métodos? ¿Qué tan arraigada está la cascada? ¿Tiene el equipo una fuerte mentalidad de mando y control? ¿Pueden las buenas ideas venir de cualquier parte? ¿Hay confianza en el equipo? ¿Las personas se comparten entre equipos? ¿Qué necesitas pedir para asegurar un turno? ¿Puede conseguir personas, herramientas, espacio y compromiso para poner a prueba el cambio?

» ¿Cuáles son los desafíos regulatorios? ¿Existen procesos y procedimientos que se relacionan con los requisitos reglamentarios? ¿Se le imponen estos

requisitos a partir de reglamentos y normas adoptados externa o internamente? ¿Necesitará crear documentación adicional para satisfacer los requisitos reglamentarios? ¿Es probable que lo auditen para verificar el cumplimiento y cuál sería el costo del incumplimiento? A medida que revisa su análisis de los obstáculos y desafíos, puede descubrir las siguientes inquietudes:

» Los enfoques ágiles revelan que la organización necesita cambiar. Como tu

Si compara las prácticas ágiles y los resultados con lo que ha hecho tradicionalmente, puede revelar que el rendimiento no ha sido todo lo que podría haber sido. Tienes que abordar esto de frente. Su organización ha estado operando dentro de un marco de cómo se esperaba que se ejecutaran los proyectos. Su organización ha hecho todo lo posible para producir un resultado, a menudo frente a desafíos extremos. Para todas las partes involucradas, debe reconocer sus esfuerzos e introducir el potencial de los procesos ágiles para permitirles producir resultados aún mayores.

» Los líderes de gestión de proyectos pueden malinterpretar las técnicas ágiles como insuficiente. A menudo, los valores y principios del Manifiesto Ágil se malinterpretan porque los marcos ágiles implican una planificación y documentación insuficientes e intentan ignorar los estándares de gestión de proyectos generalmente aceptados. Los gerentes de proyectos experimentados pueden ver que parte de ese valor se desvanece en una transición a procesos ágiles. Aproveche cada oportunidad para aclarar qué valores y principios ágiles apoyan y no respaldan. Muestre cómo cada principio aborda los mismos desafíos que la administración de proyectos tradicional intenta resolver, y cómo las técnicas ágiles son una extensión de las capacidades y la carrera de los gerentes de proyectos, no como una devaluación de algo por lo que han trabajado arduamente para asegurar.

» Pasar de un liderazgo a un modelo de servicio puede ser un desafío. Ágil

los líderes están orientados al servicio. El mando y el control dan paso a la facilitación. El liderazgo de servicio es un gran cambio para muchos equipos de proyectos y gerentes funcionales. Demuestre cómo el cambio proporciona resultados más efectivos para todos. Puede leer más sobre el liderazgo de servicio en el Capítulo 14.

CAPITULO 16 Construyendo una base

301

Tenga en cuenta que surgirá alguna resistencia; el cambio no puede ocurrir sin oposición. Esté preparado para la resistencia, pero no permita que esto frustra su plan general.

Programando la transición Desde el punto de vista organizativo, puede iniciar su iniciativa para pasar a un enfoque ágil en cualquier momento. Podría considerar algunos momentos óptimos:

» Cuando necesite demostrar que la gestión ágil de proyectos es necesaria: Usar

el final de un gran proyecto, cuando puede ver claramente lo que no funcionó (por ejemplo, durante una revisión por extinción). Podrá demostrar claramente los problemas con la cascada y obtendrá un trampolín para poner a prueba su primer proyecto ágil.

» Cuando su desafío es hacer un presupuesto preciso: Ejecute su primer ágil

proyecto en el trimestre anterior al inicio del año presupuestario anual (es decir, un trimestre antes del final del ciclo presupuestario actual). Obtendrá métricas de su primer proyecto que le permitirán estar más informado a la hora de planificar el presupuesto del próximo año.

» Cuando comienzas un nuevo proyecto: Pasar a procesos ágiles cuando

Tener un nuevo proyecto le permite empezar de cero sin el bagaje de enfoques antiguos.

» Cuando intenta llegar a un nuevo mercado o industria: Técnicas ágiles

le permiten ofrecer una innovación rápida para ayudar a su organización a crear productos para nuevos tipos de clientes.

» Cuando tienes un nuevo liderazgo: Los cambios de gestión son una gran oportunidad vínculos para establecer nuevas expectativas con enfoques ágiles.

Aunque puede aprovechar cualquiera de estas oportunidades para comenzar a utilizar procesos ágiles, no son necesarias. El mejor momento para ser más ágil es. . . ¡hoy!

Elección de los miembros del equipo piloto adecuados Determinar las personas adecuadas con las que trabajar, especialmente en las primeras etapas, es importante para el éxito de un proyecto ágil. Aquí hay cosas en las que pensar al elegir personas para los diferentes roles en el primer proyecto ágil de su organización.

El campeón ágil Al comienzo de una transición ágil, el campeón ágil será una persona clave para ayudar a garantizar que el equipo del proyecto pueda tener éxito. Esta persona debería poder

302

PARTE 5 Asegurar el éxito ágil

Influir con eficacia y rapidez en cada nivel de la organización que afecte las posibilidades de éxito de los equipos piloto ágiles. Un buen campeón ágil debería poder realizar todas estas tareas:

» Ser un apasionado de la agilidad y las cuestiones organizativas y de mercado ágil enfoques abordarán.

» Tomar decisiones sobre los procesos de la empresa. Si hay un status quo, el ágil El campeón debería poder influir en un cambio.

» Haga que la organización se entusiasme con lo que es posible con procesos ágiles. » Colaborar regular y directamente con el equipo del proyecto y apoyarlo a medida que avanza. a través de los pasos para establecer procesos ágiles.

» Adquirir los miembros del equipo del proyecto necesarios para el éxito, tanto por primera vez proyecto y a largo plazo.

» Sea un punto de escalamiento para eliminar distracciones innecesarias y no ágiles Procesos.

Al elegir un campeón ágil, busque a alguien que tenga autoridad en la organización, cuya voz sea respetada y que haya liderado iniciativas de cambio con éxito en el pasado.

El equipo de transición ágil Tan importante como es el campeón ágil, una persona no puede hacer todo. El campeón ágil debe trabajar junto con otros líderes organizacionales en los que confía el equipo del proyecto ágil para recibir apoyo en la transición. Juntos, el equipo de transición ágil elimina los impedimentos organizativos para garantizar el éxito del equipo piloto y los futuros equipos ágiles. El equipo de transición ágil debería

» Estar comprometido con el éxito organizacional a través del apoyo continuo de pilotear equipos ágiles.

» Establezca una visión clara y una hoja de ruta sobre cómo se convertirá la organización ágil.

» Organícese como un equipo de scrum, con un propietario de producto (campeón ágil), equipo de desarrollo (líderes que pueden realizar cambios organizacionales en apoyo de los equipos pilotos de scrum) y un scrummaster (un líder organizacional que puede enfocarse en ayudar al equipo de transición ágil a adoptar principios ágiles y hacer cumplir las reglas del scrum).

» Operar como un equipo de scrum, llevando a cabo los cinco eventos de scrum e implementando todos tres artefactos de scrum.

CAPITULO 16 Construyendo una base

303

La Figura 16-1 ilustra cómo se alinean las cadencias de sprint del equipo de transición ágil y del equipo de scrum piloto. Los impedimentos identificados en la retrospectiva del sprint del equipo piloto se convierten en elementos de la acumulación para que el equipo de transición los resuelva como mejoras de proceso para el equipo piloto.

FIGURA 16-1: Alineación del transición ágil equipo y el equipo de scrum piloto

cadencias.

El equipo de transición ágil no solo brinda apoyo sistemático para el equipo piloto de scrum, sino que el liderazgo organizacional también se vuelve más ágil al usar scrum junto con el equipo piloto.

El propietario del producto Con un campeón ágil y un equipo de transición ágil en su lugar, la atención se centra en los equipos pilotos de scrum. Los propietarios de productos del equipo de scrum piloto deben provenir del lado comercial de la organización, alineando el negocio con la tecnología. Durante el primer proyecto ágil, es posible que el propietario del producto deba acostumbrarse a trabajar en el proyecto a diario con el equipo de desarrollo. Un buen propietario de producto debe

» Ser decisivo. » Sea un experto en los requisitos del cliente y las necesidades comerciales.

304

PARTE 5 Asegurar el éxito ágil

» Tener la autoridad empresarial y estar facultado para priorizar y volver a priorizar requisitos del producto.

» Sea lo suficientemente organizado para gestionar los cambios en curso en la acumulación de productos.

» Comprometerse a trabajar con el resto del equipo scrum y a ser disponible para el equipo de desarrollo diariamente a lo largo de un proyecto.

» Tener la capacidad de obtener financiación para proyectos y otros recursos. Al elegir un propietario de producto para su primer proyecto ágil, busque a alguien que pueda brindarle experiencia en el producto y compromiso con el proyecto.

El equipo de desarrollo En proyectos ágiles, el equipo de desarrollo autogestionado es fundamental para el éxito del proyecto. El equipo de desarrollo determina cómo realizar el trabajo de creación del producto. Los buenos miembros del equipo de desarrollo deberían poder hacer lo siguiente:

» Sea versátil. » Esté dispuesto a trabajar de manera transversal.

» Planea un sprint y autogestiona ese plan. » Comprenda los requisitos del producto y proporcione estimaciones de esfuerzo. » Brindar asesoramiento técnico al propietario del producto para que pueda comprender

soportar la complejidad de los requisitos y tomar las decisiones adecuadas.

» Responder a las circunstancias y ajustar los procesos, estándares y herramientas para optimizar el rendimiento. Los desarrolladores intelectualmente curiosos, deseosos de aprender cosas nuevas y contribuir a los objetivos del proyecto de diversas formas, tienen más probabilidades de prosperar en un entorno ágil. Al elegir un equipo de desarrollo para el proyecto piloto, seleccione personas que estén abiertas al cambio, disfruten de un desafío, les guste estar a la vanguardia de los nuevos desarrollos y estén dispuestas a hacer lo que sea necesario para garantizar el éxito, incluido el aprendizaje y el uso de nuevos habilidades fuera de su conjunto de habilidades existente.

El scrummaster El scrum master en el primer proyecto ágil de una empresa puede necesitar ser más sensible a las posibles distracciones del equipo de desarrollo que en proyectos posteriores. Un buen scrum master debería

CAPITULO 16 Construyendo una base

305

» Tener influencia (influencia).

» Tener suficiente influencia organizacional para eliminar las distracciones externas que evitar que el equipo del proyecto utilice con éxito métodos ágiles.

» Saber lo suficiente sobre la gestión ágil de proyectos para poder ayudar al proyecto. teamuphold procesos ágiles a lo largo de un proyecto.

» Tener las habilidades de comunicación y facilitación para guiar al equipo de desarrollo. para llegar a un consenso.

» Confíe lo suficiente como para dar un paso atrás y permitir que el equipo de desarrollo se organice y administrarse a sí mismo.

Al determinar el scrummaster para el primer proyecto ágil de una empresa, desea seleccionar a alguien que esté dispuesto a ser un líder servidor. Al mismo tiempo, el scrummaster deberá tener un temperamento lo suficientemente fuerte para ayudar a frustrar las distracciones y mantener procesos ágiles frente a la resistencia organizacional e individual.

Las partes interesadas del proyecto En el primer proyecto ágil de una organización, los buenos interesados en el proyecto deben

» Estar involucrado.

» Delegar al propietario del producto las decisiones finales sobre el producto. » Asista a revisiones de sprint y proporcione comentarios sobre el producto.

» Comprender los procesos ágiles. Envío de partes interesadas del proyecto a la misma formación, ya que el resto del equipo del proyecto les ayudará a sentirse más cómodos

con nuevos procesos.

» Reciba información del proyecto en formatos ágiles, como revisiones de sprint, productos atrasos y atrasos de sprints.

» Proporcione detalles cuando el propietario del producto y el equipo de desarrollo preguntas.

» Trabaje en colaboración con el propietario del producto y el resto del equipo del proyecto. Las partes interesadas del proyecto para su proyecto ágil deben ser colaboradores confiables, cooperativos y activos a un proyecto.

306

PARTE 5 Asegurar el éxito ágil

El agilementor Un mentor ágil, a veces llamado entrenador ágil, es clave para mantener a los equipos y organizaciones en el camino correcto mientras aprenden scrum y comienzan a establecer un entorno más ágil. Un buen mentor ágil debería

» Sea experimentado.

» Sea un experto en procesos ágiles, especialmente en los procesos ágiles que la organización elige.

» Familiarícese con proyectos de diferentes tamaños, grandes y pequeños. » Ayude a los equipos a autogestionarse, haga preguntas para ayudarlos a aprender por sí mismos, y proporcionar asesoramiento y apoyo útiles sin hacerse cargo de un proyecto.

» Guíe al equipo del proyecto a través de su primer sprint al comienzo del proyecto. y estar disponible para responder preguntas según sea necesario durante todo el proyecto.

» Trabajar y relacionarse con el propietario del producto, los miembros del equipo de desarrollo, y el scrummaster.

» Sea una persona ajena a un departamento u organización. Ágil interno Los mentores a menudo provienen del grupo o centro de gestión de proyectos de una empresa.

de excelencia. Si el mentor ágil proviene de dentro de la organización, debe poder dejar de lado las consideraciones políticas al hacer sugerencias y brindar consejos.

Varias organizaciones ofrecen estrategias, planificación y tutoría ágiles, incluida nuestra empresa, Platinum Edge.

Creando un ambiente Que habilita la agilidad Cuando esté sentando las bases para ajustar su enfoque de métodos tradicionales a métodos ágiles, cree un entorno donde los proyectos ágiles puedan tener éxito y los equipos de proyectos puedan prosperar. Un entorno ágil se refiere no solo a entornos físicos, como el que describimos en el Capítulo 5, sino también a un buen entorno organizacional. Para crear un buen entorno de proyecto ágil, debe tener lo siguiente:

» Buen uso de procesos ágiles: Esto puede parecer obvio, pero con una agilidad probada

frameworks y técnicas desde el principio. Utilice la hoja de ruta para valorar Figura 16-2, uso de scrum y otras prácticas ágiles clave para aumentar su

CAPITULO 16 Construyendo una base

307

oportunidades de exito. Empiece por lo básico; construya sobre ellos solo cuando el proyecto y su conocimiento progresen. El progreso por el progreso no conduce a la perfección. Recuerde, la práctica no hace la perfección; la práctica hace permanente. Empiece correctamente.

FIGURA 16-2: La hoja de ruta valorar.

» Transparencia sin límites: Sea abierto sobre el estado del proyecto y los próximos

cambios de proceso. Personas en el equipo del proyecto y en toda la organización. debe estar al tanto de los detalles del proyecto.

» Inspección frecuente: Utilice las oportunidades habituales del ciclo de retroalimentación que scrumprovides para ver de primera mano cómo va el proyecto.

» Adaptación inmediata: Haga un seguimiento de la inspección haciendo necesario cambios de mejora a lo largo del proyecto. Aprovecha las oportunidades para mejorar hoy; no espere hasta el final de un lanzamiento o de todo el proyecto.

» Un equipo de scrum dedicado: Idealmente, el propietario del producto, el equipo de desarrollo, y scrummaster se asignará por completo al proyecto.

» Un equipo de scrum colocado: Para obtener los mejores resultados, el propietario del producto, el desarrollo equipo y scrummaster deben sentarse juntos, en la misma área de la misma oficina.

308

PARTE 5 Asegurar el éxito ágil

» Equipo de proyecto bien capacitado: Cuando los miembros del equipo del proyecto

juntos para aprender sobre los valores y principios ágiles y experimentar con ágil técnicas, tienen conocimientos compartidos y expectativas comunes sobre hacia dónde se dirigen como organización ágil.

Afortunadamente, existen muchas oportunidades de capacitación en procesos ágiles. Puede encontrar programas formales de certificación, así como cursos y talleres ágiles sin certificación. Las certificaciones ágiles disponibles incluyen las siguientes:

» Desde ScrumAlliance: • ScrumMaster certificado (CSM) • ScrumMaster certificado avanzado (A-CSM) • Propietario certificado de producto Scrum (CSPO) • Propietario de producto Scrum certificado avanzado (A-CSPO) • Desarrollador Scrum Certificado (CSD) • Desarrollador Scrum Certificado Avanzado (A-CSD) • Scrum Professional certificado (CSP) para ScrumMasters (CSP-SM), Product Owners (CSP-PO) y Desarrolladores (CSP-D)

• • •

TeamCoach certificado (CTC) Entrenador empresarial certificado (CEC)

Liderazgo ágil certificado (CAL)

» El Project Management Institute Agile Certified Practitioner (PMI-ACP) acreditación

» Desde Scrum.org:

• • •

ScrumMaster profesional (PSM I, II, III) Propietario de producto Scrum profesional (PSPO I, II) Desarrollador profesional de Scrum (PSD)

» Del Consorcio Internacional para Agile (ICAgile): • Varias pistas en coaching ágil, ingeniería, formación, agilidad empresarial, gestión de entregas, DevOps, empresa, agilidad y gestión del valor.

» Numerosos programas de certificación universitaria Con un buen ambiente, tienes buenas posibilidades de éxito.

CAPITULO 16 Construyendo una base

309

Apoye la agilidad al principio y a lo largo del tiempo Cuando se inicie por primera vez en procesos ágiles, dele a su transición ágil todas las posibilidades de éxito prestando atención a los factores clave del éxito:

» Elige un buen piloto. Seleccione un proyecto que sea lo suficientemente importante como para obtener el apoyo de uno. Al mismo tiempo, establezca expectativas: aunque el proyecto producir mejoras mensurables, los resultados serán modestos mientras el equipo del proyecto aprende nuevos métodos y mejorará con el tiempo.

» Consiga un mentor ágil. Utilice un mentor o entrenador para aumentar sus posibilidades de creando un buen entorno ágil y maximizando sus posibilidades de actuación.

» Comuníquese mucho. Siga hablando de procesos ágiles en todos los niveles de

la organización. Utilice su campeón ágil para fomentar el progreso a través del piloto y hacia una adaptación ágil más extensa.

» Prepárese para avanzar. Sigue pensando en el futuro. Considere cómo tomará el lecciones del piloto a nuevos proyectos y equipos. Piense también en cómo

escale muchos proyectos de un solo proyecto, incluidos aquellos con varios equipos.

310

PARTE 5 Asegurar el éxito ágil

EN ESTE CAPÍTULO

» Identificar cuándo y por qué escalar a través de múltiples proyectos de equipo

» Comprender los conceptos básicos del escalado

» Explorando desafíos de escala

Capítulo

Scalingacross AgileTeams

Los proyectos de tamaño mediano se pueden lograr con un solo equipo de scrum. Los proyectos más sin embargo, pueden requerir más de un equipo de scrum paray dependiendo delgrandes, cronograma, el alcance y las habilidades requeridas, muchas pequeñas

lograr la visión del producto y los objetivos de lanzamiento en un lanzamiento al mercado razonable

periodo de tiempo. Cuando se requiere más de un equipo de scrum, los equipos necesitan una colaboración, comunicación y sincronización efectivas entre equipos; deben ser ágiles a escala. Independientemente del tamaño del proyecto, si existen interdependencias entre varios equipos que trabajan juntos en el mismo proyecto, o incluso en una colección de proyectos, es posible que deba escalar. Escale solo si es necesario. Aunque tenga el talento y los recursos disponibles para implementar varios equipos en su proyecto, varios equipos no garantizan automáticamente una mayor calidad y un tiempo de comercialización más rápido. Siempre busque formas de implementar el décimo principio ágil, "La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial". Menos es más. Como un marco ágil, scrum ayuda a los equipos a organizar su trabajo y exponer el progreso de manera efectiva, ya sea que su proyecto comprenda un equipo de scrum o mil equipos de scrum. Sin embargo, el escalado trae nuevos desafíos, por lo que desea implementar técnicas de coordinación y colaboración entre equipos que no solo respalden

CAPITULO 17 Escalar en equipos ágiles

311

valores y principios ágiles, pero también abordar los desafíos específicos a los que se enfrenta su proyecto y organización. En este capítulo, discutimos algunos de los problemas que se deben abordar cuando se necesitan varios equipos en un proyecto ágil. También proporcionamos descripciones generales de algunos marcos y enfoques de escalado ágil comunes que abordan los desafíos del escalado.

Proyectos Multi-TeamAgile Las organizaciones determinan la necesidad de múltiples equipos de scrum cuando la acumulación de productos y el plan de lanzamiento requieren una velocidad de desarrollo más rápida que la que puede lograr un solo equipo de scrum.

Con proyectos ágiles, los equipos multifuncionales trabajan juntos durante cada sprint del proyecto, haciendo los mismos tipos de trabajo en cada sprint e implementando requisitos desde la cartera de productos hasta la funcionalidad completada, operativa y disponible. Sin embargo, cuando varios equipos trabajan con la misma acumulación de productos, tiene nuevos desafíos que abordar. Los desafíos comunes con más de un equipo de scrum trabajando en el mismo proyecto incluyen los siguientes:

» Planificación de proyectos: La planificación ágil es colaborativa, desde el principio. La colaboración para grupos grandes es diferente a la de los equipos de un solo scrum. Establecer una visión con el equipo de proyecto más amplio (todos los equipos de scrum y partes interesadas) y construir una hoja de ruta de productos y una cartera de productos con aportes colaborativos de todas las partes involucradas requiere un enfoque diferente al de los proyectos de un solo equipo.

» Planificación de lanzamiento: Similar al desafío de la planificación de proyectos, lanzamientos implican una planificación más específica del alcance y el tiempo de publicación. Coordinando quien trabajará en qué y cuándo a lo largo del ciclo de lanzamiento es aún más crítico para garantizar que las dependencias, las brechas de alcance y la asignación de talentos coincidan con las necesidades en todo el proyecto.

» Descomposición: Para desglosar los requisitos más importantes en la misma acumulación, Es posible que varios equipos deban participar en la investigación y la discusión de perfeccionamiento.

siones y actividades. ¿Quién inicia estas discusiones? ¿Quién facilita?

» Planificación de Sprint: Aunque no es la última oportunidad para coordinar la planificación y ejecución entre equipos scrum, la planificación del sprint es cuando los equipos scrum

bloquee una cierta cantidad de alcance de la cartera de productos para ejecutar. En esta etapa, las dependencias entre los equipos de scrum se vuelven realidad. Si el anterior

312

PARTE 5 Asegurar el éxito ágil

las actividades de desarrollo de la hoja de ruta del producto y el plan de lanzamiento no han expuesto dependencias, ¿cuáles son algunas de las formas en que los equipos de scrum pueden exponerlas y abordarlas en la planificación del sprint?

» Coordinación diaria: Incluso después de una planificación y colaboración efectivas de Iniciación del proyecto a través de la planificación del sprint, los equipos de scrum pueden y deben

colaborar cada día. ¿Quién participa y qué se puede hacer mientras los equipos están en modo de ejecución?

» Revisión de Sprint: Con tantos equipos demostrando sus incrementos de productos y buscando retroalimentación, ¿cómo pueden las partes interesadas participar con sus

horarios? ¿Cómo pueden los propietarios de productos actualizar la acumulación de productos con todo lo que se aprendió en varios equipos de scrum? ¿Cómo saben los equipos de desarrollo lo que lograron otros equipos de desarrollo?

» Retrospectiva de Sprint: Múltiples equipos de scrum que trabajan juntos forman una

equipo de proyecto más amplio. ¿Cómo identifican oportunidades de mejora? e implementar esas mejoras en todo el programa?

» Integración: Todos los incrementos de producto deben trabajar juntos en un ambiente. ¿Quién hace la integración? ¿Quién proporciona la infraestructura para ¿los equipos? ¿Quién asegura que las integraciones funcionen?

» Decisiones de arquitectura: Quién supervisa la arquitectura y la técnica estándares? ¿Cómo se pueden descentralizar estas decisiones para permitir que los equipos sean

autoorganizarse y trabajar de la forma más autónoma posible?

Estos son algunos ejemplos; es posible que pueda identificar a otros en función de su experiencia. Cualquiera que sea su situación, seleccione soluciones para sus desafíos de escalamiento que aborden su desafío específico. Algunos marcos de escalado ofrecen soluciones a los desafíos que puede que no tenga. Tenga cuidado de no inflar su marco arreglando cosas que no están rotas. A lo largo de este capítulo, nos referimos a productos, proyectos, programas y carteras. En general, un producto es un conjunto de características que proporcionan algún tipo de valor o utilidad a un cliente. A proyecto es un conjunto planificado de trabajo que requiere tiempo, esfuerzo y planificación para completarse. Tiene un comienzo y un final distintos. A programa es una colección de proyectos afines entre sí (dirigidos a un determinado segmento de mercado o incorporados al mismo producto). A portafolio es una colección de programas y proyectos que se utilizan para alcanzar objetivos comerciales estratégicos específicos. Los proyectos o programas del portafolio pueden no estar directamente relacionados entre sí sino que están agrupados para facilitar la gestión del trabajo.

Desde los primeros equipos de scrum a mediados de la década de 1990, ha habido proyectos ágiles que requieren que varios equipos de scrum colaboren juntos de manera efectiva. A continuación se presentan descripciones generales de varios marcos y técnicas de escalamiento que abordan muchos de estos desafíos.

CAPITULO 17 Escalar en equipos ágiles

313

Haciendo el trabajo digerible

a través del corte vertical Uno de los enfoques de escalado más simples se conoce como división vertical, que proporciona una solución sencilla para dividir el trabajo entre equipos para que puedan entregar e integrar funcionalmente de manera incremental en cada sprint. Si su desafío de escalado es dividir el trabajo entre equipos, el corte vertical es la solución.

El concepto de corte vertical también se aplica a proyectos de un solo equipo. Los equipos de desarrollo están formados por personas que, en conjunto, poseen todas las habilidades necesarias para convertir un requisito en una funcionalidad completa y disponible. El equipo de desarrollo se concentra en un requisito a la vez, que es una porción vertical de la acumulación de productos, potencialmente tocando todos los aspectos de la tecnología y las habilidades requeridas. Con rebanado vertical, múltiples equipos de scrum trabajan en sprints sincronizados de la misma duración en un rebanada vertical - una porción o módulo separado del producto general - y luego esos módulos son integrados por un equipo de scrum de integración después de cada sprint. El equipo de scrum de integración va por detrás de los equipos de scrum de desarrollo en un sprint y es su propio equipo de scrum, con un propietario de producto dedicado, miembros del equipo de desarrollo y scrum master. La Figura 17-1 ilustra cómo la acumulación de un producto se divide en requisitos específicos para cada equipo de scrum. Luego, al final de cada sprint, los equipos individuales implementan la funcionalidad de trabajo que se puede integrar con otras funcionalidades de trabajo en el conjunto más amplio de características del producto. Las características de cada equipo individual se incorporan al trabajo pendiente de un equipo de integración (el equipo scrum directamente encima de él en la ilustración) para la coordinación arquitectónica y a nivel del sistema. El número de niveles de equipo de scrum de integración necesarios depende de la complejidad de cada proyecto. La figura muestra cuatro niveles que lógicamente podría requerir un conjunto de funciones de Microsoft Office. (Usamos Microsoft como ejemplo porque es familiar para la mayoría de las personas). Cada equipo de scrum de integración maneja todo el trabajo de desarrollo a nivel del sistema para la integración de la funcionalidad producida por los equipos que lo integran, y proporciona supervisión arquitectónica para unificar los equipos scrum individuales.

Con Microsoft Office como ilustración:

» Un solo equipo scrum desarrolla la funcionalidad de la función de correo electrónico. “Redactar / transmitir mensajes” (requisito ID 1.1.1.1).

314

PARTE 5 Asegurar el éxito ágil

FIGURA 17-1: Equipos Scrum trabajando en rebanadas verticales de Características del producto,

usando Microsoft

Oficina como ejemplo.

» Un equipo de scrum diferente desarrolla la funcionalidad de "revisión gramatical / ortográfica mensajes ”(1.1.1.2).

» Un tercer equipo scrum desarrolla la funcionalidad de "buscar mensajes" (1.1.1.3). » El equipo de scrum de integración (a nivel de actividad) hace el trabajo de desarrollo

para integrar la funcionalidad de la funcionalidad de estos tres equipos scrum en un paquete (1.1.1) que el equipo de integración de correo electrónico puede integrar en todo el módulo de correo electrónico.

» Luego, el equipo de integración de Outlook toma los módulos de correo electrónico, junto con el Calendario, Contactos y otros módulos, para integrarlos en Outlook

paquete (1.1) que luego puede ser integrado por el equipo de integración de MS Office en todo el paquete de MS Office (1). En este ejemplo, los equipos de integración operan como equipos scrum separados, con miembros del equipo dedicados para cada función.

Scrum de scrums ¿Cómo se coordinan estos diferentes equipos de scrum diariamente? La scrum de scrums El modelo facilita la integración, la coordinación y la colaboración efectivas entre los equipos de scrum mediante la división vertical. Casi todos los marcos de escalado que le mostramos en este capítulo utilizan scrum of scrums para permitir la coordinación diaria entre equipos de scrum.

CAPITULO 17 Escalar en equipos ágiles

315

La Figura 17-2 ilustra cada rol de cada equipo coordinando diariamente con personas del mismo rol en otros equipos con respecto a las prioridades, dependencias e impedimentos que afectan al equipo del programa en general. El scrum de scrums para cada rol es facilitado por la persona de nivel de integración para cada rol. Los esfuerzos exhaustivos de integración y liberación establecen un modelo de scrum de scrums consistente y regular.

FIGURA 17-2: Scrum de scrums para coordinar entre scrum equipos.

Cada día, los equipos de scrum individuales realizan sus propios scrums diarios aproximadamente a la misma hora, en ubicaciones separadas. Después de estos scrums diarios, se producen las reuniones de scrum de scrums que se describen a continuación.

Propietario del producto scrumof scrums Cada día, siguiendo los scrums diarios de los equipos de scrum individuales, los propietarios de producto de cada equipo de scrum se reúnen con el propietario de producto del equipo de integración durante no más de 15 minutos. Abordan los requisitos que se están completando y realizan cualquier ajuste en función de las realidades descubiertas durante el scrum diario del equipo de scrum individual. Cada propietario de producto aborda lo siguiente:

» Los requisitos comerciales que cada uno ha aceptado o rechazado desde la última hora en que se conocieron

» Los requisitos que deben ser aceptados para cuando se reúnan.

316

PARTE 5 Asegurar el éxito ágil

» ¿Qué requisitos se ven obstaculizados y necesitan ayuda de otros equipos para resolverlos? (como "John, no podremos cumplir con el requisito 123 hasta que completes requisito xyz de su lista de trabajos pendientes de sprint actual ").

El propietario del producto del equipo de integración toma las decisiones de priorización entre equipos necesarias para garantizar que los impedimentos se aborden durante el scrum diario de los scrums.

Equipo de desarrollo crumof scrums Cada día después de los scrums diarios de los equipos de scrum individuales, un miembro del equipo de desarrollo representante de cada equipo de scrum asiste al scrum diario del equipo de integración (que es el scrum de scrums para desarrolladores) y participa con los miembros del equipo de desarrollo de integración en la discusión de lo siguiente:

» Los logros de su equipo desde la última vez que se conocieron

» Los logros planificados de su equipo entre ahora y la próxima reunión » Preocupaciones técnicas con las que necesitan ayuda

» Decisiones de dirección técnica que ha tomado el equipo y lo que alguien debe tener en cuenta para evitar posibles problemas

Considere la posibilidad de rotar a los miembros del equipo de desarrollo de los equipos de scrum individuales que asisten al scrum de scrums (el scrum diario del equipo de integración), ya sea diariamente o para cada sprint, para asegurarse de que todos estén sintonizados con los esfuerzos de integración de la cartera.

Scrummaster scrum de scrums Los scrum masters de cada equipo de scrum también se reúnen con el scrummaster del equipo de scrum de integración durante no más de 15 minutos para abordar los impedimentos con los que se enfrenta cada equipo. Cada scrum master aborda lo siguiente:

» Los impedimentos individuales a nivel de equipo se resolvieron desde la última vez que se reunieron. y cómo se resolvieron, en caso de que otros scrummasters se encuentren con el problema

» Nuevos impedimentos identificados desde la última vez que se reunieron y los no resueltos. impedimentos

» Qué impedimentos necesitan ayuda para resolver

» Posibles impedimentos que todos deberían conocer

CAPITULO 17 Escalar en equipos ágiles

317

El scrum master del equipo de integración luego se asegura de que los impedimentos escalados se aborden después del scrum diario de scrums. Con la división vertical, existe una sola acumulación de productos y los atributos del equipo se asignan a esos requisitos a medida que se desglosan y se mueven al equipo de scrum de desarrollo. Con este modelo, puede ver el programa general y también filtrar rápidamente a la parte de su propio equipo de ese programa general. Una pregunta común es "¿Quién es responsable de la arquitectura en un programa dividido verticalmente?" La respuesta es que depende de qué módulos se verán afectados por la decisión. Su organización debe tener estándares de arquitectura, estándares de codificación y guías de estilo existentes. De esta forma, cada equipo no tiene que reinventar la rueda. Considere una decisión arquitectónica que debe tomarse y que afectará solo al módulo A. El equipo de desarrollo del módulo A tomaría esa decisión. Si fuera a afectar a varios equipos, el equipo de desarrollo en el nivel de integración al que ingresan todos los equipos afectados tomaría esa decisión. Ese nivel de integración puede ser un nivel superior o cuatro niveles.

Utilizando la Figura 17-2 como ejemplo, el equipo de integración de correo electrónico (1.1.1) tomaría una decisión de arquitectura que afectaría a dos de los equipos del módulo de correo electrónico (1.1.1.2 y 1.1.1.3). El equipo del módulo de correo electrónico de mensajes de búsqueda (1.1.1.3) y el equipo de scrum de integración de Calendar (1.1.2) la tomaría el equipo de scrum de integración de Outlook (1.1). El corte vertical es una forma sencilla de mantener la autonomía de cada equipo de scrum para ofrecer una funcionalidad valiosa dentro de un contexto de programa más amplio. También es eficaz para ayudar a los equipos a tener conversaciones oportunas y relevantes sobre las limitaciones y el progreso.

Alineación de roles con Scrumat Scale Los modelos de escalabilidad ágiles varían en complejidad y simplicidad. El enfoque Scrum at Scale para dos o cientos de equipos de scrum que trabajan juntos es una forma de modelo de scrum básico de scrums para scrummasters y propietarios de productos que coordinan la comunicación, la eliminación de impedimentos, las prioridades, el refinamiento de requisitos y la planificación. El uso de un modelo de scrum of scrums para los roles de scrum master y product owner es la forma en que ocurre esta sincronización diaria entre equipos en programas de diferentes tamaños.

318

PARTE 5 Asegurar el éxito ágil

Escalando el scrummaster Siguiendo el modelo de corte vertical de scrum de scrums, Scrum at Scale agrupa cinco scrum masters en un scrum de scrum master. Refleja el scrum diario para que los equipos de scrum individuales salgan a la superficie y eliminen los impedimentos. Con Scrum at Scale, reducir el alcance de un scrum de scrums a cinco scrum masters de cada uno de los cinco equipos de scrum limita las complejidades de la comunicación para una colaboración eficaz entre equipos sobre en qué están trabajando los equipos de scrum y cómo su trabajo podría estar afectando a los demás. . Un scrum master scrum of scrums coordina las actividades de lanzamiento como equipo de lanzamiento. La Figura 17-3 ilustra el modelo de scrum de scrums de Scrum at Scale.

FIGURA 17-3: Scrum en Scrum de escala de

Con proyectos de más de cinco equipos de scrum, Scrum at Scale implementa un scrum de scrums de scrums, donde un representante de cada scrum master scrum de scrums asiste con otros cuatro representantes de scrum de scrums para aflorar y eliminar impedimentos en el scrum de scrums de scrums nivel. La Figura 17-4 ilustra el modelo Scrum at Scale de scrums de scrums. Cuando un proyecto tiene más de 25 equipos, un equipo de acción ejecutiva (EAT) admite un scrum de scrums de scrums de tercer nivel para eliminar los impedimentos organizativos que los grupos de scrum de scrums no pueden eliminar por sí mismos. La figura 17-5 ilustra el modelo de scrum de scrums de scrums de tercer nivel de Scrum at Scale con un equipo de acción ejecutiva (EAT).

CAPITULO 17 Escalar en equipos ágiles

319

FIGURA 17-5: Scrum a escala scrum de tercer nivel

de scrums de modelo scrums con ejecutivo equipo de acción (EAT).

Escalar al propietario del producto Los propietarios de productos se organizan de manera similar y alineada, solo que en lugar de etiquetarlos como scrum de scrums, son meta scrums. Un meta scrum de primer nivel reúne a cinco propietarios de productos en reuniones de meta scrum para refinar y planificar prioridades. Cada meta scrum tiene un jefe de producto propietario (CPO) que supervisa el mayor

320

PARTE 5 Asegurar el éxito ágil

imagen de la visión y la acumulación de productos y facilita la coordinación entre los propietarios de productos en el meta scrum. La figura 17-6 ilustra el meta scrum de Scrum a escala para propietarios de productos.

FIGURA 17-6: Scrum a escala meta scrum para propietarios de productos.

En los meta scrums de segundo y tercer nivel, la agrupación se alinea con la del scrum master de scrum de scrums de scrums. Un meta scrum ejecutivo (EMS) apoya a los meta scrums al poseer y comunicar la visión de toda la organización, tomando en cuenta la retroalimentación de prioridad técnica de los meta scrums y proporcionando decisiones de prioridad general para el programa. La Figura 17-7 ilustra el modelo de meta scrums de tercer nivel de Scrum at Scale con meta scrum ejecutivo (EMS). La Figura 17-8 ilustra la agrupación alineada de Scrum at Scale, el modelo de scrum de scrums de scrums y meta scrums de tercer nivel con el equipo de acción ejecutiva (EAT) y el meta scrum ejecutivo (EMS). Un meta scrum debe ser una reunión de sincronización que incluya a las partes interesadas. Todas las partes interesadas en el nivel de CPO deben estar presentes para garantizar la alineación en toda la organización y el apoyo de la priorización de la cartera de productos del CPO durante cada sprint.

CAPITULO 17 Escalar en equipos ágiles

321

FIGURA 17-7: Scrum a escala meta de tercer nivel

FIGURA 17-8: Alineación de Scrum a escala scrum de tercer nivel

Sincronizando en una hora al día En una hora o menos por día, toda una organización puede alinear las prioridades del día y lograr una coordinación eficaz de la eliminación de impedimentos. Por ejemplo, a las 8:00 am, cada equipo de scrum individual realiza sus scrums diarios por separado. A las 8:45 am, los scrum masters sostienen su scrum de scrums y los propietarios de productos sostienen sus

322

PARTE 5 Asegurar el éxito ágil

reuniones de meta scrum de nivel uno. A las 9:00 am, los scrum masters se reúnen en scrum de scrums de scrums, y los propietarios de productos se encuentran en meta scrums de nivel dos. Finalmente, a las 9:15 am, el scrum de scrum de scrums de scrums se reúne con el EAT y los representantes de meta scrum del propietario del producto se reúnen con EMS.

Coordinación de equipos múltiples con LeSS Scrum a gran escala (LeSS) es otra forma de escalar el scrum en proyectos masivos.

Menos se basa en principios que respaldan la sencillez de scrum cuando se reúnen varios equipos de scrum para trabajar en la misma cartera de productos. LeSS se centra más en cómo los equipos de scrum trabajan juntos que en las estructuras organizativas. También presenta una variedad de opciones para abordar cada desafío de escala. En esta sección, presentamos una descripción general y luego cubrimos algunas opciones que se destacan. LeSS define dos tamaños de marco: LeSS y LeSS Huge. La diferencia radica en el tamaño del total de equipos involucrados.

LeSS, el marco más pequeño La Figura 17-9 ilustra el marco básico de LeSS, utilizando tres equipos de scrum como ejemplo. LeSS recomienda que no más de ocho equipos de scrum sigan el modelo básico.

FIGURA 17-9: LeSS básico marco de referencia.

Usado con autorización, Craig Larman y Bas Vodde.

CAPITULO 17 Escalar en equipos ágiles

323

LeSS describe cómo los equipos de scrum trabajan juntos un sprint a la vez, comenzando con la planificación del sprint, seguido de la ejecución del sprint y los scrums diarios, y terminando con la revisión del sprint y la planificación del sprint. Aunque gran parte de LeSS sigue siendo fiel al marco de scrum, existen las siguientes diferencias significativas:

» En LeSS, los scrummasters suelen trabajar con uno a tres equipos, y hay solo un propietario de producto para hasta ocho equipos.

Recomendamos encarecidamente dedicar propietarios de productos y scrummasters a cada equipo de scrum para garantizar que los equipos de desarrollo tengan acceso inmediato y directo a las decisiones y aclaraciones comerciales y una resolución rápida de impedimentos, para que puedan seguir moviéndose sin interrupciones.

» La planificación de Sprint (Parte 1) no requiere que todos los desarrolladores asistan, pero al menos Asisten dos miembros por equipo de scrum, junto con el propietario del producto. La los miembros del equipo representativos luego regresan y comparten su información con sus equipos.

» Se produce una planificación de sprint independiente (Parte 2) y scrummeetings diarios, y Los miembros de diferentes equipos pueden asistir a la reunión de los demás para facilitar el intercambio de información.

» Las revisiones de Sprint generalmente se combinan en todos los equipos. » Las retrospectivas generales de sprint se llevan a cabo además de las retrospectivas individuales del equipo. tives. Scrummasters, propietarios de productos y representantes del desarrollo Los equipos inspeccionan y adaptan el sistema general del proyecto, como los procesos, las herramientas y la comunicación.

LeSS enorme marco Con LeSS Huge, algunos miles de personas podrían trabajar en un proyecto. Pero la estructura sigue siendo simple. Los equipos de scrum se agrupan en torno a las principales áreas de requisitos del cliente, denominadas áreas de requisitos. Esta agrupación puede ser similar al grupo de equipos que trabajan juntos bajo un equipo de integración en corte vertical. Para cada área, tiene un propietario de producto de área y entre cuatro y ocho equipos de scrum (un mínimo de cuatro equipos en cada área de requisitos evita demasiada optimización y complejidad local). Un propietario de producto general trabaja con varios propietarios de productos de área, formando un equipo de propietarios de producto para el proyecto. La figura 17-10 ilustra LeSS Huge.

324

PARTE 5 Asegurar el éxito ágil

FIGURA 17-10: El enorme menos marco de referencia.

Usado con autorización, Craig Larman y Bas Vodde.

Al igual que en el scrum a nivel de un solo equipo, así como en el LeSS básico, tiene una cartera de productos, una definición de terminado, un incremento de producto potencialmente enviable, un propietario de producto (área) y una cadencia de sprint entre equipos. LeSS Huge es simplemente un apilamiento de múltiples implementaciones LeSS más pequeñas para cada área de requisitos. Para permitir que estos equipos trabajen juntos de manera efectiva en todas las áreas de requisitos.

» El PO de área se coordina regularmente con cada propietario de producto. » Las áreas de requisitos se agregan a la cartera de productos para identificar quién está planea trabajar en qué partes del producto.

» Se necesita un conjunto de reuniones de sprint paralelas por área de requisitos. General revisiones de sprint y retrospectivas que involucren a todos los equipos son necesarias para permitir

inspección y adaptación continuas más allá de los equipos individuales. Estos eventos de equipos múltiples ayudan a coordinar el trabajo y el proceso general en todo el programa.

Con la excepción de limitar las oportunidades para que los desarrolladores trabajen en estrecha colaboración con la gente de negocios (el propietario del producto) a diario, LeSS proporciona una forma sencilla de escalar scrum en todos los proyectos. También encontramos la flexibilidad de las técnicas de coordinación sugeridas en LeSS para ser efectivas para los equipos que abordan sus desafíos específicos de coordinación de múltiples equipos. Además de un scrum de scrums (discutido anteriormente en este capítulo) y la integración continua (ver Capítulo 4), LeSS sugiere varias opciones para los equipos de scrum que se coordinan con otros equipos de scrum, como se describe en las siguientes secciones.

Sprint reviewbazaar Varios equipos trabajan para lograr el mismo incremento de producto en cada sprint, por lo que todos los equipos tienen algo que demostrar y todos los equipos necesitan comentarios de las partes interesadas.

CAPITULO 17 Escalar en equipos ágiles

325

para actualizar su parte de la cartera de productos. Debido a que todos los equipos de scrum están en la misma cadencia, incluso una organización básica de LeSS implicaría muchas reuniones de revisión de sprint para que las partes interesadas asistan el mismo día. LeSS recomienda un patrón divergente-convergente para la revisión del sprint, similar a un formato de feria de ciencias o bazar. Cada equipo de scrum se instala en una parte de una sala lo suficientemente grande para acomodar a todos los equipos de scrum. Cada equipo de scrum demuestra lo que hizo durante el sprint, recopilando comentarios de las partes interesadas que visitan su área. Las partes interesadas visitan sus áreas de interés. Los equipos Scrum pueden recorrer sus demostraciones varias veces para acomodar a las partes interesadas que visitan varios equipos. Este enfoque también permite a los miembros del equipo scrum ver demostraciones de otros equipos scrum. Tenga en cuenta que las revisiones de sprint combinadas se pueden realizar de otras formas. La combinación de revisiones de sprint aumenta la transparencia y la cultura de colaboración entre los equipos de scrum.

Observadores en el scrum diario Aunque los scrums diarios se llevan a cabo para que el equipo de scrum pueda coordinar su trabajo del día, cualquiera está invitado a escuchar. La transparencia es clave para la agilidad. El modelo de scrum de scrums descrito anteriormente en este capítulo es un modelo participativo: los desarrolladores que asisten al scrum del equipo de scrum de integración participan diariamente en la discusión. Sin embargo, a veces otros miembros del equipo scrum solo necesitan estar al tanto de lo que están haciendo otros equipos.

Un representante del equipo de desarrollo de un equipo puede asistir al scrum diario de otro equipo, observar y luego informar a su propio equipo para determinar cualquier acción a tomar. Esta puede ser una forma no disruptiva para que otros equipos de scrum participen sin gastos adicionales de tiempo de reunión.

Comunidades componentes y mentores LeSS adopta un enfoque de división vertical también para dividir la acumulación de productos entre los equipos, de modo que varios equipos pueden "tocar" el mismo sistema o componentes de tecnología. Por ejemplo, varios equipos pueden trabajar en una base de datos común, una interfaz de usuario o un conjunto de pruebas automatizadas. Establecer comunidades de práctica (CoP) alrededor de estas áreas les da a estas personas la oportunidad de colaborar informalmente en las áreas componentes donde pasan la mayor parte de su tiempo.

Las CoP generalmente las organiza alguien de uno de los equipos de scrum que tiene el conocimiento y la experiencia para enseñar a las personas cómo funciona el componente, monitorear el componente a largo plazo e involucrar a la comunidad en discusiones, talleres y revisiones regulares del trabajo que se está realizando el área del componente.

326

PARTE 5 Asegurar el éxito ágil

Reuniones de varios equipos Al igual que en el modelo combinado de revisión de sprint, los equipos de scrum de LeSS pueden beneficiarse de reunirse para otros eventos y actividades de planificación de scrum. El refinamiento de la cartera de productos, la planificación del sprint, parte dos y otros talleres de diseño son algunos ejemplos. LeSS recomienda formatos similares para cada situación, cuyos elementos comunes incluyen los siguientes:

» Primero, una sesión general, compartida entre todos los equipos, para identificar qué equipos están es probable que asuma qué elementos de la cartera de productos.

» Los representantes de cada equipo asisten a las sesiones generales (todos pueden asistir, pero no se requiere asistencia).

» Las sesiones a nivel de equipo siguen a las sesiones generales para profundizar en los detalles.

» Las rupturas de equipos múltiples siguen a la sesión general, según sea necesario, solo con esos equipos involucrado.

La clave de estas sesiones es que son cara a cara, en la misma sala, lo que permite la colaboración en tiempo real para eliminar las dependencias. Para los grupos de LeSS distribuidos (un equipo en una ubicación geográfica y otros equipos en otras ubicaciones), la videoconferencia es clave.

Viajeros Cuanto más versátil sea su equipo de desarrollo, menos cuellos de botella experimentará su equipo de scrum. Las organizaciones tradicionales tienen especialistas en áreas técnicas, y no hay suficientes para todos los equipos de scrum al iniciar una transición ágil. Para comenzar a cerrar las brechas de habilidades entre los equipos, los expertos técnicos pueden convertirse en viajeros, uniéndose a los equipos de scrum para entrenar y asesorar en su área de especialización a través del emparejamiento (consulte el Capítulo 4), talleres y sesiones de enseñanza. A medida que se comparte esta experiencia, el mentor experto continúa liderando y aumentando las habilidades en toda la organización (como organizador de CoP). Además, los equipos de scrum aumentan su funcionalidad cruzada y pueden desarrollarse de manera más eficiente.

Reducir las dependencias con Nexus Las dependencias entre equipos que trabajan en el mismo producto impiden el tipo de productividad que los equipos de scrum individuales suelen experimentar sin esas dependencias.

Nexo es un marco de escalado centrado en tratar a varios equipos como una sola unidad. La reducción de las dependencias entre equipos es clave para escalar el éxito.

CAPITULO 17 Escalar en equipos ágiles

327

Las dependencias entre equipos generalmente giran en torno a cómo los equipos estructuran los requisitos y la acumulación de productos, las diferencias de conocimiento del dominio entre los equipos y el software y los artefactos de prueba. La asignación de requisitos, el conocimiento de los miembros del equipo y los artefactos de prueba a los mismos equipos de scrum reduce las dependencias.

Nexus es un marco que describe cómo de tres a nueve equipos de scrum: un Nexo - Trabajar juntos en la misma cartera de productos y bajo la guía de un único propietario de producto, para ofrecer una funcionalidad potencialmente disponible para cada sprint. La figura 17-11 ilustra el marco Nexus.

FIGURA 17-11: El nexo marco de referencia.

Además de los roles, artefactos y eventos de scrum, Nexus presenta un nuevo rol, tres nuevos artefactos y cinco nuevos eventos para apoyar al grupo más grande de equipos de scrum que operan juntos. Nexus ayuda a los equipos de scrum que trabajan en el mismo producto a identificar y resolver las dependencias de forma rápida y temprana, lo que permite que cada equipo de scrum avance en su trabajo sin obstáculos y sin obstáculos. Las dependencias entre equipos a menudo se crean cuando los elementos de la cartera de productos no se refinan lo suficiente o no se dividen en elementos relativamente independientes en los que puede trabajar un solo equipo de scrum. Las dependencias también pueden surgir de diferencias en habilidades técnicas o conocimientos de dominio entre equipos. El refinamiento conjunto de la acumulación de productos ayuda a los equipos a identificar las dependencias y minimizarlas antes de que causen conflictos.

Rol de Nexus: equipo de integración de Nexus Similar al concepto de equipo de integración del modelo de corte vertical, el equipo de integración de Nexus asegura que se produzca al menos un incremento de producto integrado

328

PARTE 5 Asegurar el éxito ágil

cada sprint para el Nexus. Los equipos de scrum hacen el trabajo, pero el equipo de integración de Nexus sigue siendo responsable del producto integrado en su conjunto. Las actividades del equipo de integración de Nexus pueden incluir el desarrollo de herramientas y prácticas que ayudarán con la integración o servir como entrenadores y consultores para ayudar con la coordinación. Para realizar estas actividades, los miembros del equipo de integración de Nexus deben tener una mentalidad docente. Sus funciones son ayudar a exponer los problemas que deben resolverse en el nivel Nexus y ayudar a los equipos de scrum a resolver los problemas.

El equipo de integración de Nexus está formado por personas de los equipos de scrum miembros de Nexus. Es un equipo de scrum que consta de lo siguiente:

» La dueño del producto es responsable de ordenar y perfeccionar el producto Nexus atrasos para que el valor máximo se derive del trabajo creado por el Nexus

cada sprint. El rol del propietario del producto no cambia de scrum; el alcance del trabajo es simplemente más complejo.

» Miembros del equipo de desarrollo también suelen ser miembros de equipos de scrum en el nexo. La prioridad para el equipo de desarrollo de integración de Nexus

bers es el equipo de integración de Nexus sobre los equipos de scrum individuales, siendo el incremento de producto integrado el objetivo principal de cada sprint. Con el tiempo, los miembros del equipo de integración de Nexus pueden cambiar según las necesidades de integración específicas durante la vida del proyecto.

Dedicar los miembros del equipo scrum a un equipo elimina la sobrecarga de la desmovilización cognitiva frecuente y la removilización debido al cambio de contexto. Sea siempre consciente de los riesgos de dividir el enfoque de los miembros del equipo en varios equipos.

» La scrummaster tiene la responsabilidad general de garantizar que el marco Nexus el trabajo se promulga y se comprende. Este scrummaster del equipo de integración de Nexus

también puede ser un scrummaster en uno o más de los otros equipos de scrum en el Nexus.

Como último recurso, los miembros del equipo de integración de Nexus pueden extraer elementos de la cartera de productos para implementarlos como un equipo de scrum, pero emprenden este comportamiento de modo de emergencia solo cuando se han agotado todas las demás opciones y los equipos de scrum no son capaces de producir un Incremento de producto integrado. Como el término modo de emergencia sugiere, esta situación es muy inusual, muy indeseable y no sostenible. Se lleva a cabo solo cuando es la única forma de ayudar a los equipos de scrum a volver a encarrilarse.

CAPITULO 17 Escalar en equipos ágiles

329

Artefactos Nexus Tres artefactos adicionales brindan transparencia a nivel de Nexus para la inspección y adaptación:

» Objetivo de Nexus: Aunque el objetivo del sprint no es un artefacto separado en scrum, un El objetivo de sprint de Nexus se indica explícitamente. Tener una clara, visible, común El propósito de todos los equipos de scrum en el Nexus es clave para mantener a todos los equipos sincronizados durante todo el sprint, trabajando hacia el incremento de producto integrado.

» Pila de Sprint de Nexus: Cada equipo de scrum tiene su propia acumulación de sprint de tareas de implementación e integración. La acumulación de sprints de Nexus no es una agregación de estos retrasos en los sprints; existe para exponer y mapear las dependencias entre equipos y cómo fluye el trabajo en todos los equipos de scrum en el Nexus. La acumulación de sprints de Nexus se actualiza diariamente como parte del scrum diario de Nexus.

» Incremento integrado: Todo el trabajo integrado realizado por todos los equipos de scrum en el Nexus durante el sprint es el incremento integrado. Se encuentra con el definición de hecho para una funcionalidad utilizable y potencialmente enviable.

Eventos de Nexus Cinco eventos adicionales mejoran la coordinación de dependencias entre equipos a nivel de Nexus.

Planificación de Sprint Nexus Durante la planificación del sprint de Nexus, el propietario del producto proporciona prioridad y contexto comercial para el sprint y establece el objetivo del sprint. Los equipos de scrum individuales seleccionan el trabajo para el sprint mientras resaltan y minimizan las dependencias. Luego, cada equipo de scrum tiene su propia planificación de sprint para planificar la ejecución del trabajo que ha extraído del backlog de sprint de Nexus. La planificación del sprint de Nexus concluye cuando el último equipo de scrum finaliza con su planificación de sprint individual.

Scrum diario de Nexus Nexus no prescribe quién debe asistir al scrum diario: las personas adecuadas son miembros de equipos de scrums individuales que comprenden cómo su trabajo puede afectar o verse afectado por el trabajo de otros equipos de scrum. Las preguntas que se abordan son similares al scrum diario de un solo equipo de scrum, pero se centran en la integración entre equipos, incluidas las siguientes:

330

PARTE 5 Asegurar el éxito ágil

» ¿Se integró con éxito el trabajo de ayer? » ¿Qué nuevas dependencias se han descubierto? » ¿Qué información se debe compartir entre los equipos? El scrum diario de Nexus se lleva a cabo antes de que cada equipo de scrum realice su propio scrum diario para proporcionar a los equipos de scrum información que les ayude a planificar mejor su trabajo diario.

Revisión del sprint de Nexus De manera similar a otros marcos de escalado, la revisión de sprint de Nexus puede reemplazar las revisiones de sprint de equipos de scrum individuales, porque el enfoque es el incremento integrado. Puede utilizar una variedad de técnicas para llevar a cabo la reunión a fin de maximizar la retroalimentación de las partes interesadas, pero no se prescribe ninguna. Se pueden utilizar las técnicas sugeridas en este capítulo.

Retrospectiva del sprint de Nexus La retrospectiva del sprint del Nexus es una oportunidad formal para mejorar la forma en que funciona el Nexus mediante la inspección y la adaptación. La retrospectiva del sprint de Nexus incluye tres partes:

» Los representantes de los equipos scrum de Nexus se reúnen para identificar problemas entre equipos y hazlos transparentes a través del Nexus.

» Los equipos de scrum individuales tienen sus propias retrospectivas de sprint. » Los representantes de los equipos de scrum se reúnen nuevamente para decidir qué hacer para resolver problemas de todo Nexus.

Refinamiento Un Nexus utiliza el refinamiento para descomponer los elementos de la cartera de productos para que un equipo de scrum pueda desarrollarlos de la manera más independiente posible. Además del proceso general de elaboración progresiva de requisitos que le mostramos en el Capítulo 7, el proceso de Nexus para refinarlos incluye lo siguiente:

» Desglosar los elementos de la cartera de productos lo suficiente para comprender qué scrum los equipos podrían implementarlos

» Identificar y visualizar las dependencias entre los elementos de la cartera de productos. Nexus es un marco liviano, enfocado en extender el enfoque empírico de scrum a productos cuyo desarrollo requiere más de un equipo de scrum.

CAPITULO 17 Escalar en equipos ágiles

331

Planificación del programa conjunto con SAFe Marco ágil escalado (SAFe) se utiliza para escalar scrum y principios ágiles en múltiples capas de una organización de desarrollo de sistemas y software o TI. SAFe aborda el escalado en cuatro niveles: cartera, grandes soluciones, programa y equipo. La Figura 17-12 muestra el panorama completo de SAFe 4.5.

FIGURA 17-12: SAFe 4.5 para software esbelto

SAFe tiene cuatro configuraciones, utilizando combinaciones de los cuatro niveles SAFe. SAFe completo (consulte la Figura 17-12) contiene todos los niveles (cartera, solución grande, programa y equipo). Essential SAFe, que se muestra en la Figura 17-13, es un punto de partida básico para organizaciones más pequeñas y consta únicamente de los niveles de programa y equipo. Portfolio SAFe agrega el nivel de portafolio a SAFe esencial y es para organizaciones que tienen programas más pequeños dentro de un portafolio. Solución grande SAFe agrega el nivel de solución grande a SAFe esencial y está dirigido a organizaciones que están creando soluciones grandes que requieren cientos de personas, pero no requieren coordinación de cartera.

332

PARTE 5 Asegurar el éxito ágil

FIGURA 17-13: SEGURIDAD ESENCIAL

SAFe se destaca por un conjunto de valores fundamentales, una mentalidad ágil y ágil y los valores y principios ágiles del Manifiesto Ágil. Aunque otros marcos de escalado tienen diferencias tácticas, también tienen muchas similitudes, como las siguientes:

» El desarrollo se realiza en equipos ágiles. » Los equipos están alineados en longitud y cadencia de sprint.

» Un scrum de scrums coordina a nivel de programa. No entramos en todos los detalles de SAFe aquí, pero proporcionamos una descripción general y destacamos algunas prácticas que abordan algunos de los desafíos de escala discutidos anteriormente en este capítulo.

Comprensión de los cuatro niveles de SAFe En SAFe, encontrará hasta cuatro niveles prescritos de integración y coordinación, cada uno dirigido a descentralizar las decisiones a los niveles inferiores. Enfatizamos hasta cuatro porque no todas las organizaciones requieren todos los niveles, como el nivel de solución grande.

Los marcos proporcionan flexibilidad sobre rigidez. Aunque SAFe proporciona una visualización detallada en todos los niveles de la organización de la cartera, evite implementar estructuras que sean innecesarias para su situación. Los cuatro niveles (cartera, solución grande, programa y equipo) se describen a continuación.

Nivel de cartera En el nivel de cartera, Se establecen la visión y la hoja de ruta para toda la cartera. Se desarrollan temas estratégicos para apoyar la visión. Presupuesto, negocio

CAPITULO 17 Escalar en equipos ágiles

333

se gestionan los objetivos y la gobernanza de la arquitectura empresarial. La cartera está organizada en flujos de valor que alinean a la organización con el valor entregado. SAFe define un flujo de valor como la secuencia de pasos para entregar valor al cliente, desde el concepto hasta la entrega o recepción del pago. Incluye a las personas que hacen el trabajo, los sistemas y el flujo de materiales. Tres roles a nivel de cartera impulsan las decisiones de cartera:

» Gestión de carteras ajustadas (LPM): Este rol alinea la estrategia y la ejecución comunicando temas estratégicos a la cartera, estableciendo valor

corrientes y la asignación de presupuestos. LPM es responsable de la estrategia, la financiación de inversiones, la orientación ágil del programa y la gobernanza ajustada de toda la cartera. (Obtenga más información sobre lean en el Capítulo 4). LPM colabora con muchos grupos en todos los niveles de la organización.

» Propietario épico: Las epopeyas se introducen en el Capítulo 8, aunque SAFe utiliza una relación característica-épica. En SAFe, epopeyas son las más grandes y de mayor duración

iniciativas e impulsar el valor comercial para la organización. Se desglosan en características o capacidades, que luego se desglosan en historias de usuario que pueden ser ejecutadas por equipos de desarrollo individuales a nivel de equipo. Los propietarios de Epic trabajan con la gestión de soluciones y la gestión de productos en los niveles de programas y soluciones grandes, y con equipos ágiles a nivel de equipo.

» Arquitecto Empresarial: El arquitecto empresarial establece un visión técnica e impulsa el enfoque holístico de la tecnología en

programas a través de la retroalimentación continua, la colaboración y el diseño de ingeniería adaptativa y prácticas de ingeniería. La cartera de pedidos de SAFe se compone de épicas empresariales y de facilitadores. Los habilitadores son requisitos para ampliar las capacidades arquitectónicas para admitir la funcionalidad comercial futura. LPM guía el flujo de grandes iniciativas utilizando kanban. (Obtenga más información sobre kanban en el Capítulo 4.)

Gran nivel de solución La gran nivel de solución aloja el tren de soluciones, que es una construcción organizativa para la coordinación de múltiples trenes de liberación ágiles (ART), que se definen a continuación en la sección "Nivel de programa". El nivel de solución grande es para organizaciones que crean soluciones que requieren más de 125 personas. Los trenes de soluciones están coordinados por tres roles, similares a los roles de nivel de programa, que se describen en la siguiente sección, "Nivel de programa".

334

PARTE 5 Asegurar el éxito ágil

Nivel de programa En consonancia con la visión de la cartera y la cartera de pedidos, programas establecer una visión y una hoja de ruta para definir el límite exterior de su alcance de trabajo, centrado en épicas seleccionadas de la cartera de pedidos. A nivel de programa, se produce la gestión de lanzamientos y productos. Este nivel usa el modelo de

tren de liberación ágil (ART), que es un equipo de múltiples equipos ágiles (50-125 personas en total) que entregan lanzamientos incrementales de valor. El "tren" sale de la estación en un horario confiable y las funciones se pueden cargar en el tren si están listas. El ART proporciona una cadencia fija con la que los equipos del programa se alinean y sincronizan. El resto de la organización, conociendo esta cadencia, también puede planificar de manera confiable su trabajo en torno a este calendario de lanzamiento conocido.

Si se organiza a nivel de solución grande, tres roles brindan coordinación para los ART en cada flujo de valor respectivo: ingeniero de tren de soluciones (STE), administración de soluciones y arquitecto / ingeniero de soluciones. Sin el nivel de solución grande, los ART son impulsados por un ingeniero de tren de versiones (RTE), la administración de productos y un arquitecto / ingeniero de sistemas. Los roles de ART y los roles del tren de soluciones son similares, por lo que los explicamos juntos:

» Ingeniero de trenes de lanzamiento (o ingeniero de trenes de soluciones): Los ART son generalmente autoorganizados, pero necesitan coordinación para dirigirse a sí mismos. Los RTE facilitan los procesos a nivel de programa, la escalada de impedimentos, la gestión de riesgos y la mejora continua. Las STEs brindan un servicio similar, trabajando con las RTE guiando el trabajo de todas las ART en el tren de soluciones. Al igual que los scrummasters a nivel de equipo, los RTE y VSE son líderes de servicio.

» Gestión de productos (o gestión de soluciones): Estas personas continúan Defina y priorice cuidadosamente los requisitos para el ART o el tren de soluciones para que los propietarios de productos tengan la información y el empoderamiento que necesitan para tomar decisiones rápidas y proporcionar una aclaración instantánea a los desarrolladores en los equipos de scrum individuales.

» Arquitecto / ingeniero de sistemas (o arquitecto / ingeniero de soluciones): A través deequipo de disciplina con vista del sistema responsabilidad del diseño arquitectónico y de ingeniería general para el ART respectivo o el tren de soluciones. De manera similar a la forma en que se toman las decisiones de arquitectura en el equipo de integración de nivel más bajo en el corte vertical, el arquitecto / ingeniero proporciona los estándares para permitir que los desarrolladores de los equipos de scrum individuales tomen decisiones técnicas en el momento.

En este nivel de integración, ART funciona a una cadencia de cinco iteraciones por defecto para crear lo que se conoce como incrementos de programa (PI).

CAPITULO 17 Escalar en equipos ágiles

335

Nivel de equipo Los ART se componen de un cierto número de equipos ágiles individuales, que conforman el nivel de equipo de SAFe. Los equipos ágiles en un ART trabajan en cadencia entre sí, y cada uno de sus equipos respalda y se alinea con la visión y el retraso del programa.

SAFe tiene muchos aspectos, pero consideramos que los siguientes son los más valiosos para abordar los desafíos del escalado.

Planificación del incremento del programa conjunto La planificación conjunta del incremento del programa (PI) unifica equipos ágiles en un ART. En la planificación de PI, los equipos ágiles planifican su trabajo para el próximo PI juntos, cara a cara, en la misma sala al mismo tiempo. La planificación de PI incluye lo siguiente:

» Establecer el contexto empresarial para el IP por parte de un ejecutivo senior o propietario de una empresa.

» Comunicar la visión del programa mediante la gestión de productos y el apoyo características del programbacklog.

» Presentar la visión de la arquitectura del sistema y cualquier cambio de apoyo ágil a prácticas de desarrollo (como la automatización de pruebas).

» Descripción del proceso de planificación por parte de la RTE.

» Configurar sesiones ágiles de teambreakout para determinar la capacidad y la acumulación elementos en los que trabajarán en apoyo de la visión del programa.

» Revisar los borradores de planes con todos los equipos ágiles, con cada equipo presentando una clave. planificación de productos, riesgos potenciales y dependencias. Gestión de producto y otras partes interesadas brindan información y comentarios.

» Revisar los planes preliminares por parte de la gerencia para identificar cualquier problema con el alcance, el talento. restricciones de asignación y dependencias. Facilitado por el RTE.

» Separarse de los equipos ágiles para ajustar la planificación en función de todos los comentarios.

» Revisión del plan final, facilitado por el RTE. La magia de la planificación de PI es que las dependencias se identifican y coordinan en el momento durante estas sesiones de dos días, dos días bien empleados. Si un equipo identifica una dependencia en uno de sus propios requisitos durante las interrupciones del equipo, ese equipo envía un miembro del equipo a otro equipo para discutir la dependencia allí mismo. No se produce un vaivén.

336

PARTE 5 Asegurar el éxito ágil

Aunque ninguna cantidad de planificación puede identificar todos los problemas por adelantado, este tipo de colaboración aborda la mayoría de los problemas con anticipación. Además, establece una línea abierta de comunicación a lo largo de la ejecución del incremento del programa, lo que garantiza que los equipos sincronicen y aborden los problemas de manera inmediata y más eficaz que si hubieran planeado como equipos separados, compartiendo documentación sin discusión.

Claridad para los gerentes En los capítulos 3 y 14, analizamos las formas en que la administración cambia para permitir que los equipos sean más ágiles y adaptables por naturaleza. Para organizaciones más grandes, SAFe proporciona una estructura para la participación de la gerencia media con equipos ágiles. La cartera, la solución grande y los niveles de programa describen los roles y funciones que no cumplen los miembros individuales del equipo, lo que proporciona cierta claridad sobre cómo los tipos de liderazgo funcional, técnico y de otro tipo pueden despejar el camino y permitir que los equipos ágiles individuales sean tan efectivos y eficientes como posible, así como conectar la estrategia con la ejecución.

Estructuras modulares con Enterprise Scrum De todos los modelos de escalado presentados en este capítulo, Enterprise Scrum (ES) puede ofrecer el enfoque más modular para escalar. El marco ES es altamente configurable para lograr la agilidad empresarial general. Para proyectos, programas y carteras más grandes, ES extiende las bases de la práctica de scrum de un solo equipo en muchos equipos y respalda la autoorganización a escala a través de menús de opciones de estructuración. Estas opciones permiten a los equipos de equipos no solo realizar un seguimiento de su trabajo de creación de funcionalidad, sino también especificar, probar, inspeccionar y adaptar todo lo que importa para su éxito, incluidas todas sus opciones de configuración, al final de cada iteración. Algunos menús de configuración incluyen patrones para estructurar equipos y roles, estilo de colaboración, modos de entrega, tipos de contrato y una variedad de métricas. ES también generaliza algunos de los elementos centrales de scrum (roles, artefactos y eventos). Discutimos las generalizaciones de los elementos scrum de ES y los menús de configuración clave en esta sección.

ES generalizaciones de scrumelements Escalar la agilidad en una organización atrae a personas que inicialmente pueden no estar familiarizadas con los términos específicos utilizados en scrum. ES generaliza algunos nombres de roles, artefactos y eventos de scrum para que sean más familiares para los miembros de la organización en general, pero mantiene sus funciones alineadas con scrum.

CAPITULO 17 Escalar en equipos ágiles

337

Los elementos de scrum (tres roles, tres artefactos, cinco eventos) son fundamentales para el marco de scrum. Eliminar o cambiar cualquiera de ellos significa que no estás haciendo scrum. No es necesario que use scrum, pero siempre use los cuatro valores ágiles y los 12 principios ágiles como prueba de fuego para determinar si está siendo ágil. Puede obtener más información sobre los valores y principios ágiles en los capítulos 1 y 2. Algunos ejemplos de generalizaciones de scrum de ES incluyen los siguientes:

» El propietario de un producto se convierte en un propietario de la empresa para resaltar que este rol aplica al negocio en general, incluso en iniciativas que pueden no estar centradas en el producto, sino más bien centrado en el servicio o la iniciativa.

» El rol de scrummaster se convierte en un entrenador para enfatizar la naturaleza habilitadora de el rol tanto dentro del equipo como externamente con todas las partes interesadas y Unidades de negocios.

» Una cartera de productos se convierte en una lista de valores para enfatizar que cada lista de valores El elemento puede consistir en historias de usuarios que afecten directamente a la funcionalidad, o cualquier cosa

proporcionar valor a la empresa con respecto a los elementos descritos en el lienzo. Obtenga más información sobre los lienzos en la siguiente sección, "Actividades clave de ES".

La idea de agregar más que solo requisitos de funcionalidad del producto a una cartera de productos se presenta en el Capítulo 7, donde le mostramos ejemplos de elementos de la cartera de productos que incluyen no solo requisitos (funcionalidad) sino también mantenimiento (desarrollo de una funcionalidad existente), gastos generales (trabajo requerido). que no afecta la funcionalidad) y la mejora (elementos de acción de las retrospectivas de sprint para mejorar las estructuras y los procesos para el equipo y la organización).

» Una acumulación de sprint se convierte en un scrumboard para enfatizar el valor de visualizar el trabajo a realizar en un sprint en una pared o un tablero de tareas. Puedes aprender más sobre los tableros de tareas en el Capítulo 9.

» Un sprint se convierte en un ciclo. Con los proyectos de software, los ciclos siguen siendo de uno a cuatro semanas, con la misma cadencia de planificación, inspección y adaptación (revisión y retrospectiva) como sprints. Los ciclos que no son de software pueden ser más largos.

» La planificación y la revisión del sprint se convierten en planificación del ciclo y revisión del ciclo, respectivamente, para alinearse con el cambio de nombre de pique.

» La retrospectiva de Sprint se convierte mejora para enfatizar la visión de futuro dirección de inspección y adaptación.

ES actividades clave ES tiene tres actividades clave, que describimos aquí según la forma en que cada una se aplica al escalado en varios equipos.

338

PARTE 5 Asegurar el éxito ágil

Paso 1: visualiza todo lo que importa ES ofrece una biblioteca cada vez mayor de plantillas para organizar la información del proyecto, incluida la visión, la hoja de ruta, los roles, los equipos involucrados, los recursos, los elementos de la lista de valores, los métodos de implementación, las partes interesadas y los clientes. Estas plantillas se llaman

lienzos y son la base para que los equipos visualicen su trabajo. La Figura 17-14 ilustra la plantilla de lienzo para un proyecto de desarrollo de software a escala. (Las plantillas de lienzo de ES existen para otros tipos de desarrollo que no son de software, pero aquí nos centramos en el lienzo de desarrollo de software escalado).

FIGURA 17-14: ES escalado

Cada sección contiene el trabajo o los problemas que deben abordarse para cada categoría. El equipo coloca los elementos de cada sección en la lista de valores y los subconjuntos de la lista en el scrumboard para su implementación durante cada ciclo. El lienzo ES contiene todo lo que importa para una entrega exitosa. Amplía el concepto de acumulación de productos a una lista de valores personalizada de cada tipo de trabajo requerido. El contenido de la lista de valores comienza en un nivel alto y se refina hasta el nivel de detalle necesario para completar el trabajo en un ciclo. Todo el contenido del lienzo y la lista de valores se revisan para detectar posibles mejoras después de cada ciclo.

Al escalar con varios equipos, el lienzo contiene la lista de valores, incluidas todas las historias de usuario, cortadas y detalladas a medida que avanza el trabajo (sección central). La lista de valores también incluye la gama completa de problemas y relaciones circundantes del lienzo, incluida la visión, los recursos, la propiedad empresarial, la capacitación, los equipos involucrados, las métricas y las interacciones con las partes interesadas, la implementación y los clientes.

CAPITULO 17 Escalar en equipos ágiles

339

Paso 2: elija opciones de configuración activas A escala, ES también ofrece opciones sobre cómo se logran los resultados deseados de algunos roles, artefactos o eventos para abordar circunstancias individuales. Basándose en un conjunto de menús que ofrecen una variedad de opciones, los equipos toman decisiones activas sobre sus configuraciones. En esta sección se describen algunos de los menús y opciones más importantes.

MENÚ DE OBJETIVOS DE ENTREGA

Comprender el nivel de escala que necesita es un primer paso importante para determinar qué enfoque debe adoptar. Para comenzar, ES proporciona un menú de objetivos de entrega, que es un conjunto de pautas para determinar el nivel más alto de entrega coordinada al que se dirige el conjunto de equipos en el esfuerzo de escalado:

» Proyecto grande: dos o más equipos que trabajan juntos para entregar un proyecto.

» Programa: dos o más proyectos que atienden al mismo segmento de clientes

» Cartera: dos o más equipos de aplicaciones que trabajan juntos en varios programas en una unidad de negocio

» Arquitectura empresarial: dos o más áreas comerciales que requieren el uso de elementos de arquitectura comunes

» Proceso empresarial: aplicación de técnicas ágiles a organizaciones sin software unidades, como recursos humanos, finanzas, marketing, ventas, cumplimiento o Finanzas

» Agilidad empresarial: aplicación de principios ágiles en toda la empresa A diferencia de otros modelos de escala que proporcionan una variedad de tamaños de equipos múltiples para enfoques específicos, ES considera que dos o más equipos son la base para considerar cualquier opción en los menús.

MENÚ DE PATRONES ESTRUCTURALES ES se enfoca en roles más que en títulos asignados a personas individuales. Las opciones del menú de patrones estructurales para estructurar los roles de propietario de negocio y entrenador para cada equipo incluyen lo siguiente:

» Propietario de negocio dedicado y entrenador dedicado para cada equipo de scrum (como esquema en el Capítulo 6)

» Un propietario de negocio para todos los equipos y un entrenador para todos los equipos.

» Un propietario de negocio para todos los equipos y un entrenador para cada equipo. » Un propietario de negocio para cada equipo y un entrenador para todos los equipos.

340

PARTE 5 Asegurar el éxito ágil

Dedicar cada función en un equipo scrum reduce el riesgo de pérdida de productividad y defectos que a menudo resultan del cambio de tareas o de la paliza.

» Propietario de negocio virtual o coach virtual: pasos del propietario o coach de un negocio en el rol según sea necesario, mientras que también desempeña otro rol como desarrollador o un

rol externo al equipo

» Jefe de negocios o entrenador para proporcionar orientación al equipo individual dueños de negocios o entrenadores, respectivamente

» Equipos virtuales de dueños de negocios o entrenadores, donde cualquiera de las funciones puede ser realizado por un equipo colaborativo y autogestionado de dueños de negocios o entrenadores

Tener varias personas en los roles de propietario de la empresa (propietario del producto) o entrenador (scrum master) aumenta la complejidad de los canales de comunicación y puede generar confusión para todos los miembros del equipo del proyecto.

La configuración que elija depende de muchos factores, incluido el presupuesto, la cultura organizativa, el estilo de gestión y la experiencia individual.

MENÚ MODOS DE COLABORACIÓN El menú de modos de colaboración se utiliza para coordinar las prioridades comerciales y la aclaración entre los equipos. Se pueden utilizar varios enfoques para apoyar o alinear con el patrón estructural elegido:

» Centralización: El propietario de una empresa toma decisiones de priorización y proporciona aclaración a todos los equipos.

» Delegación: El propietario principal de una empresa proporciona una priorización general y cumple regularmente con los propietarios de equipos individuales para capacitarlos para hacer lo mismo para sus equipos para su parte de la lista de valores.

» Colaboración: El propietario del negocio de cada equipo trabaja con los otros equipos. Los propietarios de empresas deben realizar acuerdos de colaboración sin la supervisión de un propietario principal de la empresa.

» Subsunción: Expertos de áreas más amplias de la organización fuera de

desarrollar funcionalidades (como marketing, finanzas y ventas) colaborar en todo lo que la empresa necesita para ofrecer valor al cliente. Este alcance de colaboración suele ser necesario para abordar los procesos comerciales o los objetivos generales de entrega de agilidad comercial descritos anteriormente.

Al igual que otros enfoques de escalado, el scrum de scrums (consulte la sección de este capítulo sobre corte vertical) también se usa en ES para ayudar a facilitar la resolución de dependencias entre equipos, con el estímulo para mantener las líneas de comunicación siempre abiertas.

CAPITULO 17 Escalar en equipos ágiles

341

MENÚ MODOS DE ENTREGA Cada organización tendrá diferentes requisitos y limitaciones en cuanto a la frecuencia y la cadencia con la que ofrece funcionalidad al cliente. La frecuencia y el tipo de entrega también determinarán el nivel de coordinación necesario entre los equipos a diario, durante cada ciclo y con cada lanzamiento. Los ejemplos del menú de modos de entrega incluyen lo siguiente:

» Entrega continua: El incremento de producto se integra continuamente y probado pero no implementado en producción.

» Despliegue continuo: A medida que se implementa cada requisito, es implementado en producción tan pronto como se complete.

» Ciclo: El incremento de producto se implementa en producción al final de cada ciclo.

» Lanzamiento: El incremento de producto se implementa después de varios ciclos. Las organizaciones pueden progresar o evolucionar de uno de los modos de entrega a otro a medida que inspeccionan y se adaptan con el tiempo, sin romper el marco de ES. Puede obtener más información sobre la liberación de funciones en el Capítulo 8.

Paso 3: planifique, colabore, revise y mejore todo, cada ciclo ES se trata de la inspección y adaptación continuas de todos los aspectos del lienzo, así como de todas las opciones de configuración realizadas desde cada uno de los menús. Al final de cada ciclo, todo lo terminado y todo lo que queda por hacer en el lienzo está abierto para inspección y adaptación. ES también invita a los equipos a considerar métricas hacia una gestión ágil más equilibrada y a proporcionar transparencia en el progreso del equipo o del programa para la inspección y adaptación. Puede obtener más información sobre las métricas ágiles en el Capítulo 21. Cada uno de estos modelos de escala tiene muchas cosas en común. Todos tienen como objetivo abordar los desafíos de coordinación, comunicación, priorización, ejecución e integración que vienen con proyectos y sistemas complejos que requieren más de un equipo. Escalar proyectos a través de múltiples equipos de características multifuncionales requiere coordinación y orientación de liderazgo al más alto nivel de una organización. Las estructuras de gestión deben cambiar del comando y control tradicionales a la toma de decisiones distribuida y la autonomía al nivel más bajo posible donde se está ejecutando el trabajo.

Hacer esta transición requiere el compromiso de toda la organización con cambios a largo plazo en la estructura y la mentalidad, que discutimos en el Capítulo 18.

342

PARTE 5 Asegurar el éxito ágil

EN ESTE CAPÍTULO

» Entender la gestión del cambio problemas y cambios comunes

modelos de gestión » Seguir los pasos para una adopción ágil en

tu organización

» Evitar problemas comunes en adoptando ágil

» Haciendo las preguntas correctas para prevenir

problemas en el camino

Capítulo

BeingaChangeAgent

su empresa u organización, este capítulo puede ayudarlo a comenzar con esos cambios.

Introducir la agilidad significa y practicar unaágil nueva mentalidad, Si está contemplando la idea aprender de introducir la gestión de proyectos en cultura tura, estructuras organizativas, marcos y técnicas. En este capítulo, usted aprender los principios y pasos clave para implementar técnicas ágiles de gestión de proyectos. También presentamos modelos de cambio comunes, incluido el modelo que usamos en nuestra empresa, Platinum Edge. También cubrimos errores comunes para evitar en su transición ágil.

Convertirse en ágil requiere cambio La gestión de proyectos tradicional se centra en procesos, herramientas, documentación integral, negociación de contratos y seguimiento de un plan. Aunque la gestión de proyectos ágil sigue dedicada a abordar cada uno de estos, el enfoque cambia a las personas, las interacciones, la funcionalidad de trabajo, la colaboración con el cliente y la respuesta al cambio. Las organizaciones en cascada no llegaron a donde están de la noche a la mañana y no cambiarán de la noche a la mañana. Para algunas organizaciones, están arraigadas décadas de formar hábitos, establecer y proteger feudos y reforzar una mentalidad tradicional.

CAPITULO 18 Ser un agente de cambio

343

La estructura organizacional requerirá algún tipo de cambio, el liderazgo necesitará aprender una nueva forma de ver a las personas en desarrollo y empoderarlas para que hagan su trabajo, y quienes hagan el trabajo tendrán que aprender a trabajar juntos y a manejarse a sí mismos de la manera que quieran. puede que no esté acostumbrado.

Por qué el cambio no ocurre por sí solo El cambio se trata de personas más que de definir un proceso. La gente se resiste al cambio y esa resistencia se basa en la experiencia personal, la emoción y el miedo. Vemos estas reacciones de primera mano cuando ayudamos a las organizaciones a realizar estos cambios. A menudo, nuestra primera exposición a una organización es cuando solicita capacitación formal en el aula para aprender qué significa ser ágil y cómo funciona Scrum. Después de una clase de dos días, el nivel de entusiasmo por implementar esta forma más moderna de pensar y trabajar generalmente aumenta, y nuestros estudiantes expresan constantemente cuánto tiene sentido.

Scrum es simple. Los valores y principios ágiles resuenan con casi todo el mundo. Pero nada de eso es fácil. Scrum para desarrollar productos y servicios es como jugar un nuevo juego, con nuevas posiciones, nuevas reglas y un campo de juego diferente. Imagínese que un entrenador de fútbol americano llegara a su equipo un día y le dijera: “Hoy vamos a aprender a jugar futbol (fútbol americano). Reúnete conmigo en la cancha en 15 minutos con tu equipo y nos pondremos manos a la obra ". ¿Qué pasaría? Todo el mundo puede saber cómo jugar al fútbol según lo que haya visto en la televisión o experimentado cuando era joven, pero el equipo no estaría listo para hacer el cambio. Se produciría mucha confusión. Las viejas reglas, técnicas, entrenamiento y pensamiento tendrían que desaprenderse para que el equipo aprenda las cosas nuevas y se unan para competir de manera efectiva. Inmediatamente, escucharía preguntas de los jugadores, como las siguientes:

» ¿Cuándo puedo usar mis manos? » ¿Cuántas llamadas de tiempo de espera recibimos?

» ¿Estoy en ataque o en defensa durante esta jugada? » ¿Dónde me alineo en el saque inicial? » ¿Quién sostiene el balón cuando pateamos un gol?

» ¿Cuántos intentos hacemos antes de que el otro equipo reciba el balón? » ¿Dónde está mi casco? » Estos zapatos hacen que a veces sea difícil patear. 344

PARTE 5 Asegurar el éxito ágil

La transición a técnicas ágiles no sucederá de la noche a la mañana, pero sucederá si usted y el liderazgo de su organización adoptan un enfoque de gestión del cambio para su transición ágil. Para las organizaciones en cascada existentes, la transformación ágil toma al menos de uno a tres años desde el tiempo que la administración se compromete con ella. Es un viaje continuo, no un destino.

Enfoques estratégicos para implementar y gestionar el cambio Las iniciativas de cambio organizacional generalmente fracasan sin una estrategia y disciplina. Aquí definimos falla como no alcanzar el objetivo de estado final deseado de cómo se verá la organización después del cambio. El fracaso a menudo se debe a que no está claro el objetivo o porque el plan de cambio no aborda los factores de riesgo más altos y los desafíos que impiden el cambio deseado. Existen varios enfoques para gestionar el cambio. Aquí le mostramos varios, incluido el nuestro (Platinum Edge), para que sepa qué esperar al embarcarse en su propia iniciativa de cambio.

Lewin Kurt Lewin fue un innovador en psicología social y organizacional en la década de 1940 y estableció un modelo fundamental para comprender el cambio organizacional efectivo. La mayoría de los modelos de cambio modernos se basan en esta filosofía, que es descongelar cambiar - volver a congelar, como se ilustra en la Figura 18-1.

FIGURA 18-1: De Lewin descongelar, cambiar, volver a congelar el cambio

filosofía.

Si desea cambiar la forma de un cubo de hielo, primero debe cambiarlo de su estado congelado existente a líquido para que se pueda cambiar o remodelar, luego moldear el líquido en la nueva forma que desee y luego pasarlo un proceso de solidificación para formar la nueva forma. La descongelación está implícita entre los dos primeros estados de la figura y los cambios realizados están implícitos durante el estado descongelado.

CAPITULO 18 Ser un agente de cambio

345

Descongelar La primera etapa representa la preparación necesaria antes de que se produzca el cambio, desafiando las creencias, valores y comportamientos existentes. El reexamen y la búsqueda de motivación para un nuevo equilibrio es lo que conduce a la participación y la aceptación de un cambio significativo.

Cambio La siguiente etapa implica incertidumbre y resolver esa incertidumbre para hacer las cosas de una manera nueva. Esta etapa de transición representa la formación de nuevas creencias, valores y comportamientos. El tiempo y la comunicación son las claves para que los cambios comiencen a surtir efecto.

Vuelva a congelar A medida que las personas adoptan nuevas formas, la confianza y la estabilidad aumentan, y el cambio comienza a tomar forma en un nuevo proceso, estructura, sistema de creencias o conjunto de comportamientos nuevos y sólidos.

Este patrón simple proporciona la base para la mayoría de las herramientas y marcos de gestión de cambios, incluidos los que discutimos en este capítulo.

Los cinco pasos de ADKAR para cambiar Prosci es una de las organizaciones líderes en gestión del cambio e investigación de evaluación comparativa. Una de las herramientas de gestión del cambio de Prosci, ADKAR, es un acrónimo de los cinco resultados (conciencia, deseo, conocimiento, capacidad y refuerzo) que las personas y las organizaciones necesitan para lograr un cambio exitoso. Es un modelo orientado a objetivos para individuos, y un modelo de enfoque para las discusiones y acciones que las organizaciones deben emprender en conjunto. Los cambios organizativos aún requieren cambios para las personas, por lo que el secreto del éxito está en afectar el cambio para todos los involucrados.

ADKAR describe el viaje exitoso del individuo a través del cambio. Los cinco pasos del viaje también se alinean con las actividades de cambio organizacional. Deben completarse en el orden que se describe a continuación.

Conciencia Los humanos encuentran difícil el cambio. Cuando las iniciativas de cambio se dan de arriba hacia abajo en una organización, las personas pueden estar de acuerdo verbalmente con ellas, pero sus acciones cuentan una historia diferente. La falta de correspondencia entre acciones y palabras suele ser inocente y natural. Sin

346

PARTE 5 Asegurar el éxito ágil

la conciencia o la comprensión de los factores que influyen en el deseo de cambio de la dirección, o especialmente sin el reconocimiento de que algo debe cambiar, los individuos no estarán motivados para cambiar. Informar a los individuos de una organización, ayudarlos a tener un entendimiento compartido de los desafíos que existen y luego evaluar si la conciencia es común constituyen el primer paso para un cambio exitoso y duradero. Es la base, sin la cual la iniciativa no avanzará.

Deseo En función de su conciencia de un desafío que debe abordarse, las personas tendrán una opinión sobre si es necesario o desea realizar un cambio para abordarlo. Hacer la conexión entre la conciencia de un problema y lo que podría o debería hacerse al respecto es el siguiente paso. Una vez que existe el deseo por los individuos de una organización, existe la motivación para moverse juntos para cambiar.

Conocimiento El deseo es clave, pero el conocimiento de cómo hacer el cambio y dónde encaja cada individuo en el cambio constituye la siguiente parte crucial del proceso de cambio. Las personas de toda la organización deben comprender lo que significan los cambios para ellos, y el liderazgo debe facilitar la educación y las acciones de manera cooperativa en toda la organización. El conocimiento proviene de la formación y el coaching.

Capacidad

Con nuevos conocimientos sobre cómo cambiar, la implementación requiere adquirir habilidades, redefinir roles y definir claramente nuevas expectativas de desempeño. Es posible que sea necesario retrasar o reemplazar otros compromisos con nuevos comportamientos o responsabilidades. Es posible que se requiera capacitación y tutoría continuos, y el liderazgo debe tener claro que se espera y se alienta esta repriorización de los compromisos.

Reforzamiento Los cambios no se mantienen después de una iteración exitosa. Los nuevos comportamientos, habilidades y procesos deben reforzarse a través de acciones correctivas continuas y entrenamiento para garantizar que los viejos hábitos no regresen.

El modelo ADKAR rodea estos pasos con evaluaciones y planes de acción para guiar a líderes e individuos a través de su viaje de cambio. ADKAR debe usarse de manera iterativa, usando scrum, inspeccionando y adaptándose hasta que se logre cada paso antes de avanzar al siguiente.

CAPITULO 18 Ser un agente de cambio

347

Los ocho pasos de Kotter para liderar el cambio El proceso de John Kotter para liderar el cambio identifica ocho razones comunes pero evitables por las que las organizaciones fracasan en sus iniciativas de cambio, y aborda cada una de las acciones que deben tomarse para liderar el cambio con éxito.

» Permitiendo demasiada complacencia: La acción de liderazgo es crear un

sensación de urgencia. La gente se acostumbra al status quo y aprende a lidiar con él. Ayudar a otros a ver la necesidad de un cambio requiere la creación de un sentido de urgencia por el cambio. Los líderes deben comunicar la importancia de la acción inmediata.

» Falta de una poderosa coalición rectora: La acción de liderazgo es construir un

coalición rectora. El cambio exitoso requerirá más de un patrocinador activo, incluso si esa persona está en el nivel más alto de la organización. Ejecutivos, directores, gerentes e incluso líderes sociales informales con influencia deben estar unidos en la necesidad y visión de cambio. Esta coalición debe formarse e impulsar el cambio.

» Subestimar y comunicar insuficientemente el poder de la visión: La

La acción de liderazgo consiste en formar una visión e iniciativas estratégicas. Kotter estima que el liderazgo subcomunica la visión de cambio tanto como 1.000 veces. Incluso si las personas no están satisfechas con el status quo, no siempre harán sacrificios por un cambio a menos que crean en los beneficios propuestos y que el cambio es posible. Como coalición de cambio, defina claramente en qué se diferencia el futuro del pasado y el presente, así como los pasos para hacer realidad ese futuro. Discutimos visiones y hojas de ruta para productos y servicios en el Capítulo 7; la gestión del cambio también debe comenzar con una visión clara de hacia dónde se dirige.

» Falta de reunión en torno a una oportunidad común: La acción de liderazgo es alista un ejército de voluntarios. El cambio se acelerará y durará si la gente acepta y se impulsa internamente. Como resultado de la comunicación efectiva de la visión y la necesidad del liderazgo, las personas deben unirse en torno a una causa en la que creen. Si no se unen, reevalúe su mensaje, tono y frecuencia.

» Permitir que los obstáculos bloqueen la visión: La acción de liderazgo es eliminar barreras a la acción. Es posible que algunos obstáculos solo se perciban, pero otros son reales. Sin embargo, ambos deben superarse. Un bloqueador en el lugar "correcto" puede ser la única razón del fracaso. Muchas personas tienden a evitar enfrentar obstáculos (procesos, jerarquías, trabajar a través de silos), por lo que el liderazgo debe actuar como servidor-líder para identificar y eliminar los impedimentos que están reduciendo el empoderamiento de las personas que implementan los cambios en el frente.

» Falta de ganancias a corto plazo: La acción de liderazgo es generar a corto plazo gana. El objetivo de transformación final generalmente no se puede lograr a corto plazo, para que todos los involucrados se sientan cansados si los éxitos y el progreso van

348

PARTE 5 Asegurar el éxito ágil

desconocido en el camino. La evidencia del cambio debe destacarse y exponerse de manera temprana y regular. Este refuerzo aumenta la moral en tiempos difíciles de cambio y motiva y fomenta los esfuerzos y el progreso continuos.

» Declarar la victoria demasiado pronto: La acción de liderazgo es mantener la aceleración. Celebrar las ganancias a corto plazo genera una falsa sensación de seguridad de que el cambio

completo. Cada éxito debe basarse en el éxito anterior. Sigue adelante y sigue adelante con más fuerza después de cada éxito, con mayor confianza y credibilidad. Continúe comunicando en exceso la visión a lo largo de la transformación.

» Descuidar el anclaje de los cambios en la cultura organizacional: El liderazgo

la acción es instituir el cambio. El liderazgo tendrá la oportunidad a lo largo del proceso de cambio de conectar los éxitos y los nuevos comportamientos con la evolución y la fuerza creciente de la cultura para evitar que los viejos hábitos regresen. Estas conexiones deben reconocerse abiertamente y hacerse visibles para todos tan pronto como se logren los éxitos y los nuevos comportamientos.

Hoja de ruta del cambio de PlatinumEdge A lo largo de este libro, destacamos el hecho de que los procesos ágiles son diferentes de la gestión de proyectos tradicional. Mover una organización de cascada a una mentalidad ágil es un cambio significativo. A través de nuestra experiencia al guiar a las empresas a través de este tipo de cambio, hemos identificado los siguientes pasos importantes a seguir para convertirnos con éxito en una organización ágil. La Figura 18-2 ilustra nuestra hoja de ruta de transición ágil para lograr una transformación ágil exitosa.

Paso 1: llevar a cabo una estrategia de implementación con métricas de éxito Un estrategia de implementacion es un plan que describe lo siguiente:

» Sus puntos fuertes actuales para seguir construyendo a medida que hace la transición

» Los desafíos que enfrentará en función de su estructura actual » Elementos de acción sobre cómo su organización hará la transición a un proyecto ágil administración

CAPITULO 18 Ser un agente de cambio

349

FIGURA 18-2: Borde de platino

transición ágil mapa vial.

Las estrategias de implementación se llevan a cabo de manera más eficaz por expertos externos ágiles en forma de una evaluación o una auditoría del estado actual.

Ya sea que se relacione con un tercero o realice la evaluación usted mismo, asegúrese de que se respondan las siguientes preguntas:

350

PARTE 5 Asegurar el éxito ágil

» Procesos actuales: ¿Cómo gestiona su organización los proyectos hoy en día? Qué lo hace bien? Cuales son sus problemas?

» Procesos futuros: ¿Cómo se puede beneficiar su empresa de los enfoques ágiles? ¿Qué métodos o marcos ágiles utilizará? ¿Qué cambios clave

organización necesita hacer? ¿Cómo será su empresa transformada desde una perspectiva de equipo y proceso?

» Plan paso a paso: ¿Cómo pasará de los procesos existentes a los

procesos? ¿Qué cambiará de inmediato? ¿En seis meses? ¿En un año o más? Este plan debe ser una hoja de ruta de pasos sucesivos para que la empresa alcance un estado sostenible de madurez ágil.

» Beneficios: ¿Qué ventajas aportará la transición ágil a las personas y

grupos en su organización y la organización en su conjunto? Técnicas ágiles son una victoria para la mayoría de la gente; identificar cómo se beneficiarán.

» Retos potenciales: ¿Cuáles serán los cambios más difíciles? ¿Qué part

o las personas tendrán más problemas con los enfoques ágiles? Cuyo el feudo está siendo interrumpido? ¿Cuáles son sus posibles obstáculos? ¿Cómo superarás estos desafíos?

» Factores de éxito: ¿Qué factores organizativos le ayudarán al cambiar a

procesos ágiles? ¿Cómo se comprometerá la empresa con un nuevo enfoque? Cual ¿Las personas o los departamentos serán campeones ágiles?

Una buena estrategia de implementación guiará a su empresa en su transición hacia prácticas ágiles. Una estrategia puede proporcionar a los partidarios un plan claro para reunirse y apoyar, y puede establecer expectativas realistas para la transición ágil de su organización.

Para su primer proyecto ágil, identifique una forma cuantificable de reconocer el éxito del proyecto. El uso de métricas le brindará una forma de demostrar instantáneamente el éxito a las partes interesadas del proyecto y a su organización. Las métricas proporcionan objetivos específicos y puntos de conversación para las retrospectivas de sprint y ayudan a establecer expectativas claras para el equipo del proyecto.

Las métricas relacionadas con las personas y el desempeño funcionan mejor cuando se relacionan con equipos que con individuos. Los equipos Scrum se administran a sí mismos como un equipo, tienen éxito como equipo, fracasan como equipo y deben ser evaluados como equipo.

Hacer un seguimiento de las mediciones del éxito del proyecto puede más que ayudarlo a mejorar a lo largo del proyecto. Las métricas pueden proporcionar una prueba clara de éxito cuando pasa de su primer proyecto y comienza a escalar las prácticas ágiles en toda su organización. El Capítulo 21 describe las métricas de éxito en detalle.

CAPITULO 18 Ser un agente de cambio

351

Paso 2: generar conciencia y entusiasmo Una vez que tenga una hoja de ruta que le muestre el "cómo" de su transición ágil, debe comunicar los cambios venideros a las personas de su organización. Los enfoques ágiles tienen muchos beneficios; asegúrese de informar a todas las personas de su empresa acerca de esos beneficios y entusiasme con los cambios que se avecinan. A continuación, se muestran algunas formas de generar conciencia:

» Educar a las personas. Es posible que las personas de su organización no sepan mucho, o cualquier cosa, sobre la gestión ágil de proyectos. Educar a las personas sobre ágil principios y enfoques y el cambio que acompañará a los nuevos enfoques. Puede crear un wiki ágil, realizar sesiones de aprendizaje a la hora del almuerzo e incluso tener discusiones interactivas (discusiones cara a cara con líderes donde las personas pueden hablar de manera segura sobre inquietudes y obtener respuestas a sus preguntas sobre cambios y temas ágiles) para abordar inquietudes con la transición.

» Utilice una variedad de herramientas de comunicación. Aprovecha la comunicación canales como boletines, blogs, intranets, correo electrónico y talleres presenciales para hacer correr la voz sobre el cambio que se avecina en su organización.

» Destaque los beneficios. Asegúrese de que las personas de su empresa sepan cómo enfoque ágil ayudará a la organización a crear productos de alto valor, conducir a la satisfacción del cliente y aumentar la moral de los empleados. El Capítulo 19 tiene una gran lista de los beneficios de la gestión ágil de proyectos para este paso.

» Comparta el plan de implementación. Ponga su plan de transición a disposición de todos. Hable de ello, tanto formal como informalmente. Oferta para caminar personas

a través de él y responder preguntas. A menudo imprimimos la hoja de ruta de transición en carteles y la distribuimos por toda la organización.

» Involucre al equipo de scrum inicial. Tan pronto como puedas, deja que la gente diga trabaje en el primer proyecto ágil de su empresa conozca los próximos cambios. Involucre a los miembros del equipo scrum inicial en la planificación de la transición para ayudarlos a convertirse en profesionales ágiles y entusiastas.

» Estar abierto. Dirija la conversación sobre nuevos procesos. Trate de adelantarse a la fábrica de rumores de la empresa hablando abiertamente, respondiendo preguntas y

sofocar los mitos sobre la gestión ágil de proyectos. Las comunicaciones estructuradas como las sesiones de hot-seat que mencionamos anteriormente son un gran ejemplo de comunicación abierta.

Crear conciencia generará apoyo para los cambios venideros y aliviará parte del miedo que naturalmente acompaña al cambio. La comunicación será una herramienta importante para ayudarlo a implementar con éxito procesos ágiles.

352

PARTE 5 Asegurar el éxito ágil

Paso 3: Forma un equipo de transformación e identifica un proyecto piloto Identifique un equipo en su empresa que pueda ser responsable de la transformación ágil a nivel de organización. Este ágil equipo de transición, que se describe en el Capítulo 16, está formado por ejecutivos y otros líderes que mejorarán sistemáticamente los procesos, los requisitos de informes y las mediciones de desempeño en toda la organización.

El equipo de transformación creará cambios dentro de los sprints, al igual que el equipo de desarrollo crea características del producto dentro de los sprints. El equipo de transformación se centrará en los cambios de mayor prioridad que respaldan la agilidad en cada sprint y demostrará su implementación, cuando sea posible, durante una revisión del sprint con todas las partes interesadas, incluidos los miembros del equipo scrum piloto. Comenzar su transición ágil con un solo proyecto piloto es una gran idea. Tener un proyecto inicial le permite descubrir cómo trabajar con métodos ágiles con pocas interrupciones en el negocio general de su organización. Concentrarse en un proyecto para comenzar también le permite resolver algunos de los problemas que inevitablemente siguen al cambio. La figura 18-3 muestra los tipos de proyectos que más se benefician del enfoque ágil.

FIGURA 18-3: Proyectos que pueden

beneficiarse de ágil técnicas.

Al seleccionar su primer proyecto ágil, busque un emprendimiento con estas cualidades:

» Apropiadamente importante: Asegúrate de que el proyecto que elijas sea importante suficiente para generar interés dentro de su empresa. Sin embargo, evite la mayoría

próximo proyecto importante; quiere espacio para hacer y aprender de los errores. Vea la nota sobre el juego de la culpa en la sección posterior "Cómo evitar trampas".

CAPITULO 18 Ser un agente de cambio

353

» Suficientemente visible: Su proyecto piloto debe ser visible para los miembros de su organización. influencers clave, pero no lo conviertas en el elemento más destacado de la agenda. Necesitará libertad para adaptarse a los nuevos procesos; los proyectos críticos pueden no permitir esa libertad en el primer intento de un nuevo enfoque.

» Claro y contenible: Busque un producto con requisitos claros y una grupo empresarial que pueda comprometerse a definir y priorizar aquellos requisitos mentos. Intente elegir un proyecto que tenga un punto final distinto, en lugar de uno que pueda expandirse indefinidamente.

» No demasiado grande: Seleccione un proyecto que pueda completar con no más de dos equipos de scrum que trabajan simultáneamente para evitar demasiadas piezas móviles en una vez.

» Tangiblemente medible: Elija un proyecto que sepa que puede mostrarse medible valor dentro de los sprints.

Las personas necesitan tiempo para adaptarse a los cambios organizativos de cualquier tipo, no solo a las transiciones ágiles. Los estudios han encontrado que con grandes cambios, las empresas y los equipos verán caídas en el rendimiento antes de ver mejoras. Curva de Satir, que se muestra en la Figura 18-4, ilustra el proceso de entusiasmo, caos y finalmente ajuste de los equipos a los nuevos procesos.

FIGURA 18-4: Curva de Satir.

Una vez que haya ejecutado con éxito un proyecto ágil, tendrá una base para futuros éxitos.

354

PARTE 5 Asegurar el éxito ágil

Paso 4: construya un entorno para el éxito Uno de los principios ágiles establece: "Construya proyectos en torno a personas motivadas. Bríndeles el entorno y el apoyo que necesitan, y confíe en ellos para hacer el trabajo".

Describimos lo que significa crear un entorno que permita el éxito en el Capítulo 5. Estudie los 4 valores ágiles y los 12 principios ágiles con detenimiento (consulte el Capítulo 2) y determine seriamente si está creando un entorno para el éxito o racionalizando que el estado quo es lo suficientemente bueno. Empiece a arreglar y mejorar su entorno lo antes posible.

Paso 5: capacite lo suficiente y contrate según sea necesario La formación es un paso fundamental a la hora de cambiar a una mentalidad ágil. La combinación de capacitación presencial con expertos ágiles experimentados y la capacidad de trabajar a través de ejercicios utilizando procesos ágiles es la mejor manera de ayudar al equipo del proyecto a absorber y desarrollar el conocimiento necesario para comenzar con éxito un proyecto ágil. La formación funciona mejor cuando los miembros del equipo del proyecto pueden formarse y aprender juntos. Como instructores y mentores ágiles, hemos tenido la oportunidad de escuchar conversaciones entre los miembros del equipo del proyecto que comienzan, “Recuerden cuando Mark nos mostró cómo hacerlo. . .? Eso funcionó cuando lo hicimos en clase. Probémoslo y veamos qué pasa ". Si el propietario del producto, el equipo de desarrollo, el scrum master y las partes interesadas del proyecto pueden asistir a la misma clase, pueden aplicar las lecciones a su trabajo en equipo.

Reclutar talento para llenar los vacíos en los roles que necesita evita los problemas obvios que tendrá al comienzo de la transición. Sin un propietario de producto dedicado y su dirección clara para el equipo, ¿qué probabilidades hay de que su proyecto tenga éxito? ¿Cómo afectará eso a la capacidad del equipo para autoorganizarse? ¿Quién facilitará las muchas interacciones si te falta un scrum master? ¿Cómo se verá el primer sprint si le falta una habilidad clave en el equipo de desarrollo necesaria para lograr mínimamente el primer objetivo del sprint?

Trabaje con su departamento de recursos humanos lo antes posible para iniciar el proceso de contratación. Trabaje con sus asesores expertos ágiles para aprovechar su red de practicantes ágiles experimentados.

CAPITULO 18 Ser un agente de cambio

355

Paso 6: Comience el piloto con entrenamiento activo Cuando tenga una estrategia de implementación clara y ágil, un equipo de proyecto entusiasmado y capacitado, un proyecto piloto con una acumulación de productos y medidas claras para el éxito, ¡felicitaciones! Estás listo para ejecutar tu primer sprint. Sin embargo, no lo olvide: los enfoques ágiles son nuevos para el equipo piloto. Los equipos necesitan entrenamiento para alcanzar un alto rendimiento. Póngase en contacto con expertos ágiles para obtener un coaching ágil para comenzar bien el proyecto.

La práctica no hace la perfección. La práctica hace permanente. A medida que el equipo de scrum planea su primer sprint, no debería cumplir con demasiados requisitos. Tenga en cuenta que recién está comenzando a aprender sobre un nuevo proceso y un nuevo producto. Los nuevos equipos de scrum a menudo asumen una menor cantidad de trabajo de lo que creen que pueden completar en sus primeros sprints. Sigue una progresión típica. Después de establecer los objetivos generales a través de la declaración de visión del producto, la hoja de ruta del producto y el objetivo de lanzamiento inicial, la cartera de pedidos de su producto solo necesita suficientes requisitos de nivel de historia de usuario (consulte el Capítulo 8) para un sprint para que el equipo de scrum comience el desarrollo.

» En el sprint 1, Los equipos de scrum asumen el 25 por ciento del trabajo que creen que pueden completar durante la planificación del sprint.

» En el sprint 2, Los equipos de scrum asumen el 50 por ciento del trabajo que creen que pueden completar durante la planificación del sprint.

» En el sprint 3, Los equipos de scrum asumen el 75 por ciento del trabajo que creen que pueden completar durante la planificación del sprint.

» En el sprint 4 y más allá, Los equipos de scrum asumen el 100 por ciento del trabajo que creo que pueden completar durante la planificación del sprint.

Para el Sprint 4, el equipo de scrum se sentirá más cómodo con los nuevos procesos, sabrá más sobre el producto y podrá estimar las tareas con mayor precisión.

No se puede planificar la incertidumbre. No sea víctima de la parálisis del análisis; ¡Establece una dirección y listo!

356

PARTE 5 Asegurar el éxito ágil

Durante el primer sprint, asegúrese de seguir conscientemente las prácticas ágiles. Piense en lo siguiente durante su primer sprint:

» Tenga su scrummeeting diario, incluso si siente que no hizo ningún Progreso. ¡Recuerde también indicar los obstáculos!

» El equipo de desarrollo puede necesitar recordar administrarse a sí mismo y no mirar al propietario del producto, al scrummaster o en cualquier lugar además del sprint atrasos para asignaciones de tareas.

» Es posible que el scrummaster deba recordar proteger al equipo de desarrollo fuera del trabajo y las distracciones, especialmente mientras otros miembros del La organización se acostumbra a tener un equipo de proyecto ágil y dedicado.

» Es posible que el propietario del producto tenga que acostumbrarse a trabajar directamente con el equipo de desarrollo, estando disponible para preguntas y revisando y aceptando los requisitos completados inmediatamente.

En el primer sprint, espere que el camino esté un poco accidentado. Esta bien; Los procesos ágiles se tratan de aprender y adaptarse. En el Capítulo 8, puede ver cómo el equipo de scrum puede planificar el sprint. El Capítulo 9 proporciona los detalles del día a día sobre cómo ejecutar el Sprint.

Paso 7: ejecutar la hoja de ruta para generar valor Cuando haya elegido su proyecto piloto, no caiga en la trampa de utilizar un plan de una vieja metodología o un conjunto de hábitos. En su lugar, utilice procesos ágiles desde el inicio del proyecto.

A lo largo de este libro, describimos la Hoja de ruta hacia el valor, la presentamos en el Capítulo 7 y lo guiamos a través de cada una de las siete etapas de los Capítulos 7 al 10.

Paso 8: recopile comentarios y mejore Naturalmente, al principio cometerá errores. No hay problema. Al final de su primer sprint, recopila comentarios y mejora con dos eventos importantes: la revisión del sprint y la retrospectiva del sprint. En su primera revisión del sprint, será importante que el propietario del producto establezca expectativas sobre el formato de la reunión, junto con el objetivo del sprint y la funcionalidad del producto completado. La revisión del sprint trata sobre la demostración del producto: fantasía

CAPITULO 18 Ser un agente de cambio

357

las presentaciones y los folletos son gastos generales innecesarios. Los interesados en el proyecto pueden sorprenderse inicialmente con un enfoque básico. Sin embargo, esas partes interesadas pronto quedarán impresionadas cuando encuentren un producto funcional que reemplace la pelusa de las diapositivas y las listas. Transparencia y visibilidad: muestre, en lugar de contar.

La primera retrospectiva del sprint también puede requerir establecer algunas expectativas. Ayudará a llevar a cabo la reunión con un formato preestablecido, como el del Capítulo 10, tanto para iniciar la conversación como para evitar una sesión de quejas libre para todos.

En su primera retrospectiva de sprint, preste especial atención a lo siguiente:

» Tenga en cuenta qué tan bien cumplió el objetivo del sprint, no cuántas historias de usuarios completó.

» Repase qué tan bien completó los requisitos para conocer la definición de terminado: definido, probado, integrado y documentado.

» Analice cómo alcanzó las métricas de éxito de su proyecto.

» Hable sobre lo bien que se apegó a los principios ágiles. Empezamos el viaje con principios.

» Celebre los éxitos, incluso los pequeños logros, y examine los problemas y soluciones.

» Recuerde que el equipo scrum debe gestionar la reunión como un equipo, ganar consenso sobre cómo mejorar y salir de la reunión con un plan de acción.

Puede encontrar más detalles sobre revisiones de sprint y retrospectivas de sprint en el Capítulo 10.

Paso 9: Madure y solidifique las mejoras Inspeccionar y adaptarse permite que los equipos de scrum crezcan como equipo y maduren con cada sprint. Los practicantes ágiles a veces comparan el proceso de maduración con la técnica de aprendizaje de artes marciales de Shu Ha Ri, un término japonés que se puede traducir como "mantener, separar, trascender". El término describe tres etapas en las que las personas aprenden nuevas habilidades:

» En el Shu etapa, los estudiantes siguen una nueva habilidad tal como se les enseñó, sin desviación, para memorizar esa habilidad y hacerla automática.

358

PARTE 5 Asegurar el éxito ágil

Los nuevos equipos de scrum pueden beneficiarse de hacer un hábito de seguir de cerca los procesos ágiles, hasta que esos procesos se vuelvan familiares. Durante la etapa de Shu, los equipos de scrum pueden trabajar en estrecha colaboración con un entrenador o mentor ágil para seguir los procesos correctamente.

» En el Decir ah etapa, Los estudiantes comienzan a improvisar a medida que comprenden más sobre cómo funciona su nueva habilidad. A veces las improvisaciones funcionarán y

a veces no lo harán. Los estudiantes aprenderán más sobre la habilidad de estos éxitos y fracasos. A medida que los equipos de scrum comprenden mejor cómo funcionan los enfoques ágiles, pueden probar variaciones en los procesos para su propio proyecto. Durante la etapa Ha, los equipos de scrum encontrarán que la retrospectiva del sprint es una herramienta valiosa para hablar sobre cómo funcionaron o no sus improvisaciones. En esta etapa, los miembros del equipo scrum aún pueden aprender de un mentor ágil, pero también pueden aprender unos de otros, de otros profesionales ágiles y de comenzar a enseñar habilidades ágiles a otros.

» En el Rhode Island etapa, la habilidad es algo natural para el ex alumno, quien sabrá qué funciona y qué no. El ex alumno ahora puede innovar con confianza. Con la práctica, los equipos de scrum llegarán al punto en que los procesos ágiles son fáciles y cómodos, como andar en bicicleta o conducir un automóvil. En la etapa Ri, los equipos de scrum pueden personalizar los procesos, sabiendo qué funciona en el espíritu del Manifiesto Ágil y los 12 Principios Ágiles.

Al principio, madurar como un equipo scrum puede requerir un esfuerzo concentrado y un compromiso para usar procesos ágiles y defender valores ágiles. Sin embargo, con el tiempo, el equipo de scrum seguirá avanzando, mejorando de un sprint a otro e inspirando a otros en toda la organización. Con el tiempo, a medida que los equipos de scrum y las partes interesadas del proyecto maduran, empresas enteras pueden madurar y convertirse en organizaciones ágiles y exitosas.

Paso 10: expandirse progresivamente dentro de la organización Completar un proyecto exitoso es un paso importante para llevar a una organización a una gestión de proyectos ágil. Con métricas que demuestran el éxito de su proyecto y el valor de las metodologías ágiles, puede obtener el compromiso de su empresa para respaldar nuevos proyectos ágiles.

CAPITULO 18 Ser un agente de cambio

359

Para escalar progresivamente la gestión ágil de proyectos en una organización, comience con lo siguiente:

» Sembrar nuevos equipos. Un equipo de proyecto ágil que ha alcanzado la madurez: el las personas que trabajaron en el primer proyecto ágil, ahora deberían tener la experiencia y entusiasmo por convertirse en embajadores ágiles de la organización. Estas personas pueden unirse a nuevos equipos de proyectos ágiles y ayudar a esos equipos a aprender y crecer.

» Redefinemetrics. Identificar medidas de éxito en toda la organización. ción, con cada nuevo equipo de scrum y con cada nuevo proyecto.

» Escale metódicamente. Puede ser emocionante producir grandes resultados, pero la empresa Las mejoras amplias requieren cambios de proceso significativos. No te muevas más rápido que la organización puede manejar. Consulte el Capítulo 17 para conocer las diferentes formas de escalar proyectos ágiles en varios equipos.

» Identifica nuevos desafíos. Puede que tu primer proyecto ágil se haya descubierto obstáculos que no consideró en su plan de implementación original. Actualice su estrategia y hoja de ruta de madurez según sea necesario.

» Continúe aprendiendo. A medida que implementa nuevos procesos, asegúrese de que el nuevo equipo los miembros tienen la capacitación, la tutoría y los recursos adecuados para ejecutar proyectos ágiles.

Los pasos anteriores funcionan para lograr transiciones de gestión de proyectos ágiles y exitosas. Siga estos pasos y vuelva a ellos a medida que escala, y podrá hacer que las prácticas ágiles prosperen en su organización.

Evitando trampas Los equipos de proyecto pueden cometer una serie de errores comunes pero graves al implementar prácticas ágiles. La Tabla 18-1 proporciona una descripción general de algunos problemas típicos y formas de solucionarlos.

Como puede notar, muchas de estas dificultades están relacionadas con la falta de apoyo organizacional, la necesidad de capacitación y el recurrir a las viejas prácticas de administración de proyectos. Si su empresa apoya cambios positivos, si el equipo del proyecto está capacitado y si el equipo scrum se compromete activamente a defender los valores ágiles, tendrá una transición ágil exitosa.

360

PARTE 5 Asegurar el éxito ágil

TABLA 18-1

Problemas y soluciones comunes de la transición ágil

Problema

Descripción

Solucion potencial

Faux ágil o doble trabajo ágil o ambos

A veces, las organizaciones dirán que lo están "haciendo

Insista en seguir un proceso: un proceso ágil. Obtenga el apoyo de gestión para evitar principios y prácticas no ágiles.

de manera ágil". Pueden pasar por algunas de las prácticas utilizadas en proyectos ágiles, pero no han adoptado los principios ágiles y continúan creando productos y entregables en cascada. A esto a veces se le llama falso ágil y es un camino seguro para evitar los beneficios de las técnicas ágiles.

Intentar completar procesos ágiles además de procesos en cascada, documentos y reuniones es otro enfoque falsamente ágil. Doble trabajo ágil resulta en un agotamiento rápido del equipo del proyecto. Si está haciendo el doble de trabajo, no se adhiere a los principios ágiles. Falta de entrenamiento

La inversión en una clase de capacitación práctica

Incorpore la formación a su

proporcionará un entorno de aprendizaje mejor y más rápido

estrategia de implementacion. Donación

que incluso el mejor libro, video, blog o documento técnico. La

equipos, la base correcta de

falta de capacitación a menudo indica una falta general de

habilidades es fundamental para el

compromiso organizacional con prácticas ágiles.

éxito y necesaria al comienzo de su transición ágil.

Tenga en cuenta que el entrenamiento puede ayudar a los equipos de scrum a evitar muchos de los errores de esta lista.

Ineficaz

El rol del propietario del producto no es tradicional. Los equipos

Inicie el proyecto con una persona que

dueño del producto

de proyectos ágiles necesitan un propietario de producto que

tenga el tiempo, la experiencia y el

sea un experto en las necesidades y prioridades del negocio y

temperamento para ser un buen

que pueda trabajar bien con el resto del equipo de scrum a

propietario de producto.

diario. Un propietario de producto ausente o indeciso hundirá rápidamente un proyecto ágil.

Asegúrese de que el propietario del producto tenga la formación adecuada.

El scrummaster puede ayudar a entrenar al propietario del producto y puede intentar eliminar los obstáculos que impiden que el propietario del producto sea eficaz. Si

eliminar impedimentos no trabajo, el equipo de scrum debe insistir en reemplazar el Dueño de producto ineficaz con propietario de producto, o al menos un agente, que puede tomar decisiones sobre el producto y ayudar al equipo de scrum a tener éxito.

(continuado)

CAPITULO 18 Ser un agente de cambio

361

TABLA 18-1 ( continuado)

Problema

Descripción

Solucion potencial

Falta de

Sin pruebas automatizadas, puede ser imposible completar y probar

Puede encontrar muchas herramientas de

pruebas automatizadas

el trabajo por completo dentro de un sprint. Las pruebas manuales

prueba de código abierto y de bajo costo en

requieren un tiempo que los equipos de scrum que se mueven

el mercado hoy en día. Busque las

rápidamente no tienen.

herramientas adecuadas y comprométase como equipo de desarrollo a utilizar esas herramientas.

Falta de

apoyo de transición

Hacer la transición con éxito es difícil y está lejos de estar garantizado. Vale la pena hacerlo bien la primera vez con personas que saben lo que están haciendo.

Cuando decida pasar a una gestión ágil de proyectos, pida la ayuda de un ágil mentor, ya sea internamente de su organización o externamente de una firma consultora, que puede apoyar su transición. El proceso es fácil, pero las personas son difíciles. Vale la pena invertir en

apoyo de transición profesional con un socio experimentado que entienda el comportamiento

ciencia y cambio organizacional.

Inapropiado físico ambiente

Cuando los equipos de scrum no están colocados, pierden la ventaja de la comunicación cara a cara. Estar en el mismo edificio no es suficiente; Los equipos de scrum deben sentarse juntos en la misma área.

Si su equipo de scrum está en el mismo edificio pero no en la misma área, mueva el equipo junto. Considere la posibilidad de crear una sala o un anexo para que el equipo de scrum colabore continuamente. Trate de mantener el área del equipo de scrum lejos de distractores, como el tipo que puede hablar para siempre o el gerente que solo necesita un pequeño favor.

Antes de comenzar un proyecto con un equipo scrum dislocado, haga lo que pueda para reclutar talento local. Si debe trabajar con un equipo scrum dislocado, consulte el Capítulo 14 para ver cómo gestionar equipos dislocados. Pobre equipo

selección

Los miembros del equipo Scrum que no apoyan los procesos ágiles, no trabajan bien con otros o no tienen la capacidad de autogestión sabotearán un nuevo proyecto ágil desde adentro.

Al crear un equipo scrum, considere qué tan bien actuarán los miembros potenciales del equipo

los principios ágiles. Las claves son la versatilidad y la voluntad de aprender.

362

PARTE 5 Asegurar el éxito ágil

Problema

Descripción

Solucion potencial

Resbalones de disciplina

Recuerde que los proyectos ágiles aún necesitan requisitos, diseño, desarrollo, pruebas y lanzamientos. Hacer ese trabajo en sprints requiere disciplina.

Necesita más, no menos, disciplina para ofrecer funcionalidad de trabajo en una breve iteración. El progreso debe ser consistente y constante.

El scrum diario ayuda a garantizar que el progreso se produzca a lo largo del sprint. Utilice la retrospectiva del sprint como una oportunidad para reiniciar

enfoques de la disciplina. Falta de apoyo

Los equipos Scrum tienen éxito como equipos y fracasan como

para aprender

equipos; llamar los errores de una persona (conocido como el

juego de la culpa) destruye el entorno de aprendizaje y destruye la innovación.

Diluir hasta morir

Diluir los procesos ágiles con viejos hábitos en cascada erosiona los beneficios de los procesos ágiles hasta que esos beneficios ya no existen.

El equipo de scrum puede comprometerse al comienzo del proyecto a dejar espacio para el aprendizaje y aceptar los éxitos y fracasos como grupo. Al realizar cambios en el proceso, deténgase y considere si esos cambios son compatibles con el Manifiesto Ágil y los 12 Principios Ágiles. Resista los cambios que no funcionen con el manifiesto y los principios. Recuerde maximizar el trabajo no realizado.

Señales de que sus cambios se están desvaneciendo La siguiente lista de preguntas lo ayuda a ver las señales de advertencia y le brinda ideas sobre qué hacer si surgen circunstancias problemáticas:

» ¿Estás haciendo "scrum, pero. . . ”? “ScrumBut ocurre cuando las organizaciones adoptan parcialmente scrum. Algunos puristas ágiles dicen que ScrumBut es inaceptable; otros practicantes ágiles dejan espacio para el crecimiento gradual hacia un nuevo método. Dicho esto, tenga cuidado con las prácticas antiguas que frustran los principios ágiles, como terminar sprints con una funcionalidad incompleta.

Scrum es tres roles, tres artefactos y cinco eventos. Si encuentra que su equipo está modificando esos componentes básicos del marco, pregunte por qué. ¿Scrum está exponiendo algo que no estás dispuesto a inspeccionar y adaptar?

CAPITULO 18 Ser un agente de cambio

363

» ¿Sigues documentando e informando a la antigua usanza? Si todavía está gastando horas en documentación e informes considerables, es una señal de que la organización no ha aceptado enfoques ágiles para transmitir el estado del proyecto. ¡Ayude a los administradores a comprender cómo usar los artefactos de informes ágiles existentes y dejar de hacer el doble trabajo!

» Un equipo que completa 50 puntos de historia en un sprint es mejor que otro equipo haciendo 10, ¿verdad?

No. Tenga en cuenta que los puntos de la historia son relativos y consistentes dentro de un equipo de scrum, no entre varios equipos de scrum. La velocidad no es una métrica de comparación de equipos. Es simplemente un hecho posterior al sprint que los equipos de scrum usan para ayudarlos en su propia planificación. Puede ver más sobre los puntos de la historia y la velocidad en el Capítulo 8.

» ¿Cuándo aprobarán las partes interesadas todas las especificaciones? Si está esperando la aprobación de requisitos integrales para comenzar a desarrollar, no está siguiendo prácticas ágiles. Puede comenzar el desarrollo tan pronto como tenga suficientes requisitos para un sprint.

» ¿Estamos usando offshore para reducir costos? Idealmente, los equipos de scrum están colocados. La capacidad de comunicación instantánea cara a cara ahorra más tiempo y dinero y evita errores más costosos que los ahorros iniciales por hora que puede ver con algunos equipos offshore.

Si trabaja con equipos offshore, invierta en buenas herramientas de colaboración, como cámaras de video individuales y salas de equipo virtuales y persistentes.

» ¿Los miembros del equipo de desarrollo están pidiendo más tiempo en un sprint para terminar las tareas?

Es posible que el equipo de desarrollo no esté trabajando de manera interfuncional o atestado de requisitos prioritarios. Los miembros del equipo de desarrollo pueden ayudarse unos a otros a finalizar las tareas, incluso si esas tareas están fuera de la experiencia principal de una persona.

Esta pregunta también puede indicar presiones externas para subestimar las tareas e incluir más trabajo en un sprint del que el equipo de desarrollo puede manejar.

» ¿Los miembros del equipo de desarrollo se preguntan qué deben hacer a continuación? Una vez que se planifica un sprint y el trabajo de desarrollo está en marcha, si los desarrolladores están esperando instrucciones del scrummaster o del propietario del producto, no son autoorganizados. El equipo de desarrollo debería decirle al scrummaster y al propietario del producto lo que está haciendo a continuación, no al revés.

364

PARTE 5 Asegurar el éxito ágil

» ¿Los miembros del equipo están esperando hasta el final del sprint para realizar las pruebas? Los equipos de desarrollo ágiles deben probar todos los días en un sprint. Todos los miembros del equipo de desarrollo son probadores.

» ¿Están apareciendo las partes interesadas para las revisiones de sprint? Si las únicas personas en las revisiones de sprint son los miembros del equipo scrum, es hora de recordarles a las partes interesadas el valor de los ciclos de retroalimentación frecuentes. Hágales saber a las partes interesadas que están perdiendo la oportunidad de revisar la funcionalidad del producto en funcionamiento con regularidad, corregir el rumbo temprano y ver de primera mano cómo avanza el proyecto.

» ¿El equipo de scrum se queja de que el scrum le da órdenes? ¿Maestro?

Las técnicas de comando y control son la antítesis de la autogestión y están en conflicto directo con los principios ágiles. Los equipos Scrum son equipos de compañeros: el único jefe es el equipo. Tenga una discusión con el mentor ágil y actúe rápidamente para restablecer las expectativas del scrummaster sobre su rol.

» ¿El scrum teamputting en muchas horas extras? Si el final de cada sprint se convierte en una prisa para completar las tareas, no está practicando el desarrollo sostenible. Busque las causas fundamentales, como la presión para subestimar. El scrummaster puede necesitar entrenar al equipo de desarrollo y proteger a sus miembros de la presión del propietario del producto si este es el caso. Reduzca los puntos de la historia para cada sprint hasta que el equipo de desarrollo pueda manejar el trabajo.

» ¿Qué retrospectiva? Si los miembros del equipo de scrum comienzan a evitar o cancelar las retrospectivas de sprint, estás en la diapositiva de regreso a la cascada. Recuerde la importancia de inspeccionar y adaptarse y asegúrese de ver por qué las personas se pierden la retrospectiva en primer lugar. Si no está progresando, la complacencia generalmente resulta en un retroceso. Incluso si el equipo de scrum tiene una gran velocidad, la velocidad de desarrollo siempre puede ser mejor, así que mantén la retrospectiva y sigue mejorando.

CAPITULO 18 Ser un agente de cambio

365

La parte de diez

EN ESTA PARTE . . . Comunique los beneficios de la gestión ágil de proyectos. Aborde los factores clave para el éxito de un proyecto ágil.

Mida el progreso en la inspección y adaptación adecuadas para ser más ágiles como organización. Conviértase en un profesional ágil aprendiendo, con el apoyo de valiosos recursos.

EN ESTE CAPÍTULO » Asegurarse de que los proyectos sean gratificantes

» Facilitar los informes » Mejorando los resultados

» Reducir el riesgo

Capítulo

Diez beneficios clave de ágil

Gestión de proyectos

proporciona a organizaciones, equipos proyectosbeneficios y productos. En este capítulo, proporcionamos diez de importantes que la gestión ágil de proyectos

Para aprovechar los beneficios de la gestión ágil de proyectos, debe confiar en las prácticas ágiles, aprender más sobre los diferentes enfoques ágiles y utilizar lo mejor para su equipo de proyecto.

Mejor calidad de producto Los proyectos existen para crear excelentes productos y resultados impulsados por un propósito. Los métodos ágiles tienen excelentes garantías para garantizar que la calidad sea lo más alta posible. Los equipos de proyectos ágiles ayudan a garantizar la calidad al hacer lo siguiente:

» Adopte un enfoque proactivo de la calidad para evitar problemas con los productos.

» Adoptar la excelencia tecnológica, el buen diseño y el desarrollo sostenible.

Capitulo 19 Diez beneficios clave de la gestión ágil de proyectos

369

» Definir y elaborar requisitos justo a tiempo para que el conocimiento del producto características es lo más relevante posible.

» Incorporar criterios de aceptación en las historias de los usuarios para que el equipo de desarrollo los comprende mejor y el propietario del producto puede validar con precisión

ellos.

» Incorporar la integración continua y las pruebas diarias en el desarrollo. proceso, lo que permite al equipo de desarrollo abordar los problemas mientras están frescos.

» Aproveche las herramientas de prueba automatizadas para desarrollar durante el día, probar durante la noche y reparar los defectos por la mañana.

» Lleve a cabo retrospectivas de sprint, permitiendo que el equipo de scrum continúe mejorar los procesos y el trabajo.

» Trabajo completo usando la definición de hecho: desarrollado, probado, integrado, y documentado.

Puede encontrar más información sobre la calidad del proyecto en el Capítulo 15.

Mayor satisfacción del cliente Los equipos de proyectos ágiles están comprometidos con la producción de productos que satisfagan a los clientes. Los enfoques ágiles para patrocinadores de proyectos más felices incluyen los siguientes:

» Colabore con los clientes como socios y mantenga a los clientes involucrados y comprometido a lo largo de los proyectos.

» Tener un propietario de producto que sea un experto en los requisitos del producto y las necesidades del cliente. (Consulte los Capítulos 6 y 9 para obtener más información sobre el rol del propietario del producto).

» Mantenga la cartera de productos actualizada y priorizada para responder rápidamente a cambio. (Puede obtener información sobre la acumulación de productos en el Capítulo 8 y su función

en respuesta al cambio en el Capítulo 12.)

» Demuestre la funcionalidad de trabajo a los clientes en cada revisión de sprint. (El Capítulo 10 le muestra cómo realizar una revisión de sprint).

» Entregue productos al mercado más rápido y con más frecuencia con cada lanzamiento.

» Poseer el potencial para proyectos autofinanciados. (El Capítulo 13 le informa sobre proyectos autofinanciados.)

370

PARTE 6 La parte de diez

Riesgo reducido Las técnicas ágiles de gestión de proyectos eliminan virtualmente la posibilidad de un fracaso absoluto del proyecto: gastan grandes cantidades de tiempo y dinero sin retorno de la inversión. Los equipos de proyectos ágiles ejecutan proyectos con menor riesgo al hacer lo siguiente:

» Desarrollar en sprints, asegurando un corto tiempo entre la inversión inicial del proyecto. y fallar rápidamente o saber que un producto o un enfoque funcionará.

» Siempre tenga un producto integrado que funcione, comenzando con el primer sprint, por lo que que se agrega algo de valor como funcionalidad de envío en cada sprint, lo que garantiza una El proyecto ágil no fallará por completo.

» Desarrollar requisitos de acuerdo con la definición de hecho en cada sprint para que los patrocinadores del proyecto han completado, funcionalidad utilizable, independientemente de lo

puede suceder con el proyecto en el futuro.

» Proporcionar retroalimentación constante sobre productos y procesos a través de lo siguiente:

• •

Scrummeetings diarios y comunicación constante del equipo de desarrollo Aclaración diaria periódica sobre los requisitos y revisión y aceptación de características por parte del propietario del producto.

•

Revisiones de Sprint, con comentarios de partes interesadas y clientes sobre la funcionalidad

•

Sprint retrospectivas, donde el equipo de desarrollo discute la mejora del

•

Lanzamientos, donde el usuario final puede ver y reaccionar a las nuevas funciones de

completa del producto

proceso.

forma regular

» Genere ingresos temprano con proyectos autofinanciados, lo que permite a las organizaciones Pague un proyecto con pocos gastos iniciales.

Puede encontrar más información sobre la gestión de riesgos en el Capítulo 15.

Mayor colaboración y propiedad Cuando los equipos de desarrollo asumen la responsabilidad de proyectos y productos, pueden producir grandes resultados. Los equipos de desarrollo ágiles colaboran y se apropian de la calidad del producto y el desempeño del proyecto haciendo lo siguiente:

» Asegúrese de que el equipo de desarrollo, el propietario del producto y el scrum El maestro trabaja en estrecha colaboración a diario.

Capitulo 19 Diez beneficios clave de la gestión ágil de proyectos

371

» Llevar a cabo reuniones de planificación de sprint impulsadas por objetivos, lo que permite el desarrollo equipo para comprometerse con el objetivo del sprint y organizar su trabajo para lograrlo.

» Realizar scrummeetings diarios dirigidos por el equipo de desarrollo, donde el desarrollo Los miembros del equipo se organizan en torno al trabajo completado, el trabajo futuro y los obstáculos.

» Realizar revisiones de sprint, donde el equipo de desarrollo puede demostrar y discutir el producto directamente con las partes interesadas.

» Realizar retrospectivas de sprint, lo que permite a los miembros del equipo de desarrollo revisar trabajos anteriores y recomendar mejores prácticas con cada sprint.

» Trabaje en un entorno compartido, lo que permite la comunicación instantánea y colaboración entre los miembros del equipo de desarrollo.

» Tome decisiones por consenso, utilizando técnicas como el póquer de estimación y el puño de cinco.

Puede averiguar cómo los equipos de desarrollo estiman el esfuerzo de los requisitos, descomponen los requisitos y obtienen el consenso del equipo en el Capítulo 7. Para obtener más información sobre la planificación del sprint y las reuniones diarias de scrum, consulte el Capítulo 9. Para obtener más información sobre las retrospectivas del sprint, consulte el Capítulo 10.

Métricas más relevantes Las métricas que utilizan los equipos de proyectos ágiles para estimar el tiempo y el costo, medir el rendimiento del proyecto y tomar decisiones sobre proyectos suelen ser más relevantes y precisas que las métricas de los proyectos tradicionales. Las métricas ágiles deben fomentar el progreso y la eficiencia sostenibles del equipo de una manera que funcione mejor para que el equipo entregue valor al cliente de manera temprana y frecuente. En proyectos ágiles, proporciona métricas haciendo lo siguiente:

» Determine los cronogramas y los presupuestos del proyecto en función de los rendimiento y capacidades reales.

» Asegúrese de que el equipo de desarrollo que hará el trabajo y nadie de lo contrario, proporciona estimaciones de esfuerzo para los requisitos del proyecto.

» Utilice estimaciones relativas, en lugar de horas o días, para adaptar con precisión las estimaciones esfuerzo por el conocimiento y las capacidades de un equipo de desarrollo individual.

» Refine el esfuerzo, el tiempo y el costo estimados de manera regular, a medida que el desarrollo equipo aprende más sobre el proyecto.

» Actualice el gráfico de evolución del sprint todos los días para proporcionar métricas precisas sobre cómo se está desempeñando el equipo de desarrollo en cada sprint.

372

PARTE 6 La parte de diez

» Compare el costo del desarrollo futuro con el valor de ese futuro desarrollo, que ayuda a los equipos del proyecto a determinar cuándo finalizar un proyecto

y reasignar capital a un nuevo proyecto. Puede notar que falta velocidad en esta lista. Velocidad ( una medida de la velocidad de desarrollo, como se detalla en el Capítulo 13) es una herramienta que puede usar para determinar los plazos y los costos, pero funciona solo cuando se adapta a un equipo individual. La velocidad del equipo A no influye en la velocidad del equipo B. Además, la velocidad es excelente para medir y generar tendencias, pero no funciona como mecanismo de control. Tratar de hacer que un equipo de desarrollo alcance un cierto número de velocidad solo interrumpe el desempeño del equipo y frustra la autogestión. Si está interesado en obtener más información sobre la estimación relativa, asegúrese de consultar el Capítulo 7. Puede encontrar herramientas para determinar los plazos y los presupuestos, junto con información sobre la redistribución de capital, en el Capítulo 13. El Capítulo 21 le muestra diez claves métricas para una gestión ágil de proyectos.

Visibilidad de rendimiento mejorada En proyectos ágiles, cada miembro del equipo del proyecto tiene la oportunidad de saber cómo va el proyecto en un momento dado. Los proyectos ágiles pueden proporcionar un alto nivel de visibilidad del rendimiento haciendo lo siguiente:

» Valora mucho la comunicación abierta y honesta entre el equipo de scrum,

partes interesadas, clientes y cualquier otra persona de una organización que desee saber acerca de un proyecto.

» Proporcione mediciones diarias del rendimiento del sprint con el backlog del sprint actualizaciones. Los trabajos pendientes de Sprint pueden estar disponibles para que cualquier persona de una organización

revisión.

» Proporcionar información diaria sobre el progreso inmediato del equipo de desarrollo y obstáculos a través del scrummeeting diario. Aunque solo el desarrollo

teammay hablar en el scrummeeting diario, cualquier miembro del equipo del proyecto puede asistir.

» Muestre físicamente el progreso mediante el uso de tableros de tareas y la publicación de sprint burndown gráficos en el área de trabajo del equipo de desarrollo todos los días.

» Demuestre logros en revisiones de sprint. Cualquiera dentro de una organización Puede asistir a una revisión de sprint.

La visibilidad mejorada del proyecto puede conducir a un mayor control y previsibilidad del proyecto, como se describe en las siguientes secciones.

Capitulo 19 Diez beneficios clave de la gestión ágil de proyectos

373

Mayor control del proyecto Los equipos de proyectos ágiles tienen numerosas oportunidades para controlar el desempeño del proyecto y hacer las correcciones necesarias debido a lo siguiente:

» Ajustar las prioridades a lo largo del proyecto permite que la organización tenga proyectos de tiempo fijo y precio fijo al mismo tiempo que se adaptan al cambio.

» Adoptar el cambio permite que el equipo del proyecto reaccione a factores externos como Demanda de mercado.

» Los scrummeetings diarios permiten al equipo scrum abordar rápidamente los problemas surgen.

» Las actualizaciones diarias de los trabajos pendientes de sprint significan gráficos de evolución de sprint con precisión reflejar el rendimiento del sprint, dando al equipo de scrum la oportunidad de hacer cambia en el momento en que ve problemas.

» Las conversaciones cara a cara eliminan los obstáculos a la comunicación y al problema resolución.

» Las revisiones de Sprint permiten a las partes interesadas del proyecto ver los productos en funcionamiento y proporcionar información sobre los productos antes del lanzamiento.

» Las retrospectivas de Sprint permiten al equipo scrum tomar un rumbo informado

ajustes al final de cada sprint para mejorar la calidad del producto, aumentar el rendimiento del equipo de desarrollo y perfeccionar los procesos del proyecto.

Las muchas oportunidades para inspeccionar y adaptarse a través de proyectos ágiles permiten que todos los miembros del equipo del proyecto (el propietario del producto, el equipo de desarrollo, el scrum master y las partes interesadas) ejerzan el control y, en última instancia, creen mejores productos.

Previsibilidad mejorada del proyecto Las técnicas ágiles de gestión de proyectos ayudan al equipo del proyecto a predecir con precisión cómo irán las cosas a medida que avanza el proyecto. A continuación, se muestran algunas prácticas, artefactos y herramientas para mejorar la previsibilidad:

» Mantener la misma duración de los sprints y la asignación del equipo de desarrollo a través de

El proyecto permite al equipo del proyecto conocer el costo exacto de cada sprint.

» El uso de la velocidad del equipo de desarrollo individual permite al equipo del proyecto predecir cronogramas y presupuestos para lanzamientos, la cartera de productos restante o cualquier

grupo de requisitos.

374

PARTE 6 La parte de diez

» Utilizando la información de los scrummeetings diarios, gráficos de burndown de sprint,

y los tableros de tareas permiten al equipo del proyecto predecir el desempeño de sprints.

Puedes encontrar más información sobre la duración de los sprints en el Capítulo 8.

Estructuras de equipo personalizadas La autogestión pone las decisiones que normalmente tomaría un gerente o la organización en manos de los miembros del equipo scrum. Debido al tamaño limitado de los equipos de desarrollo, que constan de tres a nueve personas, los proyectos ágiles pueden tener varios equipos de scrum en un proyecto si es necesario. La autogestión y la limitación de tamaño significan que los proyectos ágiles pueden brindar oportunidades únicas para personalizar las estructuras de los equipos y los entornos de trabajo. Aquí están algunos ejemplos:

» Los equipos de desarrollo pueden organizarse en grupos con habilidades específicas. o que funcionan en partes específicas del sistema y características del producto.

» Los equipos de desarrollo pueden organizar la estructura de su equipo en torno a personas con estilos de trabajo y personalidades específicos. Organización en torno a estilos de trabajo

proporciona estos beneficios:

• • •

Permite a los miembros del equipo trabajar de la forma en que quieren trabajar Anima a los miembros del equipo a ampliar sus habilidades para encajar en los equipos que les gustan.

Ayuda a aumentar el rendimiento del equipo porque a las personas que hacen un buen trabajo les gusta trabajar juntas y gravitan naturalmente entre sí.

» Los equipos Scrum pueden tomar decisiones adaptadas para proporcionar equilibrio entre el equipo. la vida profesional y personal de los miembros.

» En última instancia, los equipos de scrum pueden establecer sus propias reglas sobre con quién trabajan. con y cómo funcionan. La idea de la personalización del equipo permite que los lugares de trabajo ágiles tengan más diversidad. Las organizaciones con estilos de gestión tradicionales tienden a tener equipos monolíticos donde todos siguen las mismas reglas. Los entornos de trabajo ágiles son muy parecidos a la antigua analogía de la ensaladera. Al igual que las ensaladas pueden tener ingredientes con sabores muy diferentes que encajan para hacer un plato delicioso, los proyectos ágiles pueden tener personas en equipos con fortalezas muy diversas que encajan para hacer excelentes productos.

Capitulo 19 Diez beneficios clave de la gestión ágil de proyectos

375

Equipo superiorMorale Trabajar con personas felices que disfrutan de su trabajo puede ser satisfactorio y gratificante. La gestión ágil de proyectos mejora la moral de los equipos de scrum de estas formas:

» Formar parte de un equipo de autogestión permite que las personas sean creativas, innovadoras, y reconocidos por sus contribuciones.

» Centrarse en prácticas laborales sostenibles asegura que las personas no se agoten por estrés o exceso de trabajo.

» Fomentar un enfoque de líder servidor ayuda a los equipos de scrum en la gestión y evita activamente los métodos de comando y control.

» Tener un scrummaster dedicado, que sirve al equipo de scrum, elimina

impedimentos y protege al equipo de desarrollo de interferencias externas.

» Brindar un ambiente de apoyo y confianza aumenta la gente en general. motivación y moral.

» Tener conversaciones cara a cara ayuda a reducir la frustración de falta de comunicación.

» Trabajar de manera transversal permite a los miembros del equipo de desarrollo aprender habilidades y crecer enseñando a otros.

Puede obtener más información sobre la dinámica de equipo en el Capítulo 14.

376

PARTE 6 La parte de diez

EN ESTE CAPÍTULO » Asegurarse de que los equipos de scrum tengan la

entorno y herramientas que necesitan » Cumplir todos los roles con el talento adecuado » Capacitar a los equipos con una dirección clara

y apoyo

Capítulo

TenKeyFactors para Éxito del proyecto

triunfar. No es necesario que se resuelvan todos los problemas antes de comenzar. Solo debefactores conocerlos tener un plan para abordarlos tanágil pronto como Hay diez clavey que determinan si una transición

viaje como sea posible.

Hemos descubierto que los tres primeros son los indicadores más sólidos de éxito. Hágalo bien y la probabilidad de éxito aumenta drásticamente.

Miembros del equipo dedicados En el Capítulo 6, hablamos de la importancia de dedicar a los miembros del equipo (propietario del producto, miembros del equipo de desarrollo y scrummaster) a un solo proyecto a la vez. Esto es especialmente crítico al principio, cuando el equipo scrum y el resto de la organización aún están aprendiendo lo que significa valorar la agilidad y encarnar principios ágiles.

Si los miembros del equipo están saltando entre los contextos del proyecto cada hora, diariamente, semanalmente o incluso mensualmente, el enfoque en obtener las técnicas ágiles correctas se minimiza en el

CAPITULO 20 Diez factores clave para el éxito de un proyecto

377

gasto de simplemente tratar de mantenerse al día con múltiples listas de tareas. Además, el tiempo perdido debido a la continua desmovilización y removilización cognitiva que implica el cambio de tareas es muy costoso para cada proyecto involucrado.

Si cree que no tiene suficientes personas para dedicar a sus equipos de scrum, definitivamente no tiene suficientes personas para distribuirlos en múltiples proyectos simultáneamente. La Asociación Estadounidense de Psicología informa que cambiar de tarea desperdicia hasta un 40 por ciento del tiempo.

Colocación El Manifiesto Ágil enumera a las personas y las interacciones como el primer valor. La forma de obtener este valor correctamente es colocando a los miembros del equipo para poder tener una comunicación clara, efectiva y directa a lo largo de un proyecto. En el Capítulo 5, hablamos de la colocación como el primer elemento crucial de un entorno ágil. Bell Laboratories mostró una mejora de cincuenta veces en la productividad simplemente al hacer que los individuos y las interacciones se realizaran correctamente mediante la colocación. Con este factor de éxito abordado de manera adecuada, la colaboración con el cliente, la funcionalidad de trabajo y la respuesta eficaz al cambio se convierten en una realidad mucho más.

Pruebas automatizadas Los equipos de desarrollo no pueden desarrollar al ritmo que la tecnología y las condiciones del mercado cambian si tienen que probar manualmente su trabajo cada vez que integran nuevas piezas de funcionalidad a lo largo del sprint. Cuanto más tiempo confían los equipos en las pruebas manuales, más grandes se vuelven los huecos en la cobertura de las pruebas; las pruebas manuales simplemente toman demasiado tiempo y en realidad se convierten en controles puntuales. Sin la automatización, los equipos de scrum tendrán dificultades para ofrecer valor por completo en cada sprint. En el Capítulo 4, analizamos las prácticas de programación extremas destinadas a desarrollar la calidad desde el principio; Las pruebas automatizadas son una de las prácticas principales. El Capítulo 15 también analiza la construcción de calidad a través de la automatización y la integración continua.

Definición impuesta de hecho Poner fin a los sprints con una funcionalidad que no se puede enviar es un anti-patrón para volverse más ágil. Su definición de hecho debe aclarar lo siguiente:

378

PARTE 6 La parte de diez

» El entorno en el que se debe integrar la funcionalidad. » Los tipos de pruebas » Los tipos de documentación requerida El equipo de scrum también debe hacer cumplir su definición de hecho. Si los equipos de scrum les dicen a sus partes interesadas que han terminado después de un sprint, pero no se cumple un aspecto de la definición de hecho, el trabajo para terminar de cumplir con la definición de hecho debe agregarse al siguiente sprint, lo que quita la capacidad de trabajar en nuevos. elementos valiosos de la cartera de productos. Este escenario es un esquema Ponzi. Los equipos de desarrollo se encargan de hacerlo pululando por historias de usuarios, trabajando juntos en una historia de usuario a la vez hasta que esté completa antes de comenzar la siguiente. Los desarrolladores se responsabilizan mutuamente asegurándose de que se cumplan todas las reglas para su definición de hecho antes de comenzar una nueva historia de usuario. Los propietarios de productos revisan el trabajo completado contra la definición de hecho del equipo de scrum (así como los criterios de aceptación de la historia del usuario; consulte el Capítulo 8) tan pronto como los desarrolladores lo completen, y el scrum master se asegura de que los desarrolladores resuelvan los problemas rechazados por el propietario del producto antes de continuar. a nuevas historias de usuarios.

Enjambrar para seguir una definición clara de hecho hace que los sprints sean exitosos. Consulte los capítulos 2, 8, 10 y 15 para obtener más información sobre la definición de hecho.

Visión clara del producto y hoja de ruta Aunque el propietario del producto posee la visión del producto y la hoja de ruta del producto, muchas personas tienen la responsabilidad de garantizar la claridad de estos ágiles artefactos. Los propietarios de productos necesitan acceso a las partes interesadas y los clientes al principio durante la planificación del proyecto, así como durante todo el proyecto para garantizar que la visión y la hoja de ruta reflejen continuamente lo que el cliente y el mercado necesitan. El desarrollo impulsado por un propósito ofrece valor comercial y para el cliente y mitiga el riesgo de manera efectiva.

Sin un propósito claro, las personas deambulan y carecen de propiedad. Cuando todos los miembros del equipo comprenden el propósito, se unen. Recuerde el principio ágil, "Las mejores arquitecturas, requisitos y diseños surgen de equipos autoorganizados".

Discutimos la mecánica del desarrollo de la visión y la hoja de ruta del producto en el Capítulo 7.

CAPITULO 20 Diez factores clave para el éxito de un proyecto

379

Empoderamiento del propietario del producto El rol del propietario del producto es optimizar el valor producido por el equipo de desarrollo. Esta responsabilidad del propietario del producto requiere que alguien tenga conocimiento sobre el producto y el cliente, esté disponible para el equipo de desarrollo durante todo el día, y esté capacitado para tomar decisiones prioritarias y dar aclaraciones en el momento para que los equipos de desarrollo no esperen o tomen decisiones inapropiadas para el dirección del producto. Aunque todos los roles en el equipo de scrum son vitales e igualmente importantes, un propietario de producto ineficaz y sin poder generalmente hace que los equipos de scrum fracasen en la entrega del valor que los clientes necesitan del equipo. Consulte el Capítulo 6 para obtener más información sobre el rol del propietario del producto.

Versatilidad del desarrollador Probablemente no comience su primer proyecto ágil con un equipo de desarrollo que tenga el nivel ideal de habilidades requeridas para cada requisito en su cartera de productos. Sin embargo, el objetivo debe ser lograr la cobertura de habilidades lo antes posible. Su equipo también enfrentará el desafío de alcanzar su objetivo de sprint si tiene puntos únicos de falla en cualquier habilidad, incluidas las pruebas. Desde el primer día, necesita desarrolladores en su equipo con curiosidad e interés intelectual para aprender cosas nuevas, experimentar, ser mentores y recibir tutoría, y trabajar juntos como un equipo para hacer las cosas lo más rápido posible. Esta versatilidad se analiza con más detalle en el Capítulo 6.

ScrumMaster Clout A medida que se aparta del liderazgo de mando y control para empoderar a las personas que realizan el trabajo para tomar decisiones, el liderazgo de servicio proporciona la solución. Con autoridad formal, un scrummaster sería visto como un gerente, alguien a quien informar. A los scrummasters no se les debe dar autoridad formal, pero el liderazgo debe empoderarlos para trabajar con los miembros del equipo de scrum, las partes interesadas y otros terceros para despejar el camino y que el equipo de desarrollo pueda funcionar sin obstáculos.

Si los scrum masters tienen influencia organizacional, que es informal y es una habilidad de influencia ganada socialmente, pueden servir mejor a sus equipos para optimizar sus

380

PARTE 6 La parte de diez

ambiente de trabajo. En el Capítulo 6, hablamos más sobre los diferentes tipos de influencia. Brinde capacitación y tutoría para asegurarse de que sus scrum masters desarrollen las habilidades blandas del liderazgo de servicio y eliminen las tendencias de mando y dirección.

Soporte de gestión para el aprendizaje Cuando los líderes ejecutivos deciden volverse ágiles, su mentalidad debe cambiar. Con demasiada frecuencia vemos directivas de liderazgo sin ningún seguimiento para apoyar el proceso de aprendizaje para implementar los cambios. No es realista esperar todos los beneficios de seguir los principios ágiles después del primer sprint. En el Capítulo 18, hablamos sobre la elección de un proyecto piloto ágil apropiado, uno con margen para tropezar un poco al principio mientras todos aprenden una nueva forma de trabajar juntos. La conclusión: si el apoyo para el aprendizaje es simplemente de labios para afuera, los equipos de scrum lo entenderán temprano, perderán la motivación para probar cosas nuevas y volverán a esperar las directivas de arriba hacia abajo sobre cómo hacer su trabajo.

Soporte de transición El capítulo 18 compara una transición ágil con la transición de un equipo deportivo para practicar un deporte diferente. Un buen entrenamiento a nivel de liderazgo y de equipo aumenta sus posibilidades de éxito. El coaching brinda apoyo en las siguientes formas:

» Corrección de rumbo en el momento cuando la disciplina comienza a fallar o cometer errores son hechos

» Reforzar el entrenamiento

» Mentoría personalizada para desafíos específicos basados

en roles

» Estilo de liderazgo ejecutivo y ajustes de mentalidad Consulte nuestra hoja de ruta de transición ágil de Platinum Edge en el Capítulo 18 para conocer los pasos específicos que debe seguir junto con sus entrenadores expertos ágiles de confianza.

CAPITULO 20 Diez factores clave para el éxito de un proyecto

381

EN ESTE CAPÍTULO

» Usar métricas de éxito » Calcular métricas de tiempo y costo » Comprender las métricas de satisfacción

Capítulo

TenMetrics forAgile Organizaciones

adaptarse y comprender el progreso a lo largo del tiempo. Las tasas de éxito o fracaso permitirle un equipo scrum saber si necesita hacer cambios positivos Enpueden un proyecto ágil, las a métricas pueden ser herramientas poderosas para planificar, inspeccionar,

o continuar con su buen trabajo. Los números de tiempo y costo pueden resaltar los beneficios de

proyectos ágiles y brindan apoyo a las actividades financieras de una organización. Las métricas que cuantifican la satisfacción de las personas pueden ayudar a un equipo scrum a identificar áreas de mejora con los clientes y con el equipo en sí. Este capítulo describe diez métricas clave para ayudar a guiar a los equipos de proyectos ágiles.

Retorno de la inversión Retorno de la inversión (ROI) son los ingresos generados por el producto menos los costos del proyecto: entrada de dinero frente a salida de dinero. El ROI es fundamentalmente diferente en proyectos ágiles que en proyectos tradicionales. Los proyectos ágiles tienen el potencial de generar ingresos con la primera versión y pueden aumentar los ingresos con cada nueva versión.

Capitulo 21 TenMetrics para organizaciones ágiles

383

Para apreciar completamente la diferencia entre el ROI en proyectos tradicionales y ágiles, compare los ejemplos en las Tablas 21-1 y 21-2. Los proyectos de ambos ejemplos tienen los mismos costos de proyecto y requieren la misma cantidad de tiempo para completarse. Ambos productos tienen el potencial de generar $ 100,000 en ingresos cada mes cuando se terminan todos los requisitos. Primero, observe el ROI en un proyecto tradicional en la Tabla 21-1.

TABLA 21-1

ROI en un proyecto tradicional

Mes

Mensual Ingreso

Mensual Costos

Mensual

ROI

enero

$ 80 000

- $ 80 000

febrero

$ 80 000

marcha

abril

Total

Costos

ROI

$ 80 000

- $ 80 000

$ 160 000

- $ 160 000

$ 80 000

- $ 80 000

$ 240 000

- $ 240 000

$ 80 000

- $ 80 000

$ 320 000

- $ 320 000

Mayo

$ 80 000

- $ 80 000

$ 400 000

- $ 400 000

Junio (proyecto

$ 80 000

- $ 80 000

$ 480 000

- $ 480 000

mes de julio

$ 100,000

$ 480 000

- $ 380 000

agosto

$ 100,000

$ 200 000

$ 480 000

- $ 280 000

septiembre

$ 100,000

$ 300 000

$ 480 000

- $ 180 000

octubre

$ 100,000

$ 400 000

$ 480 000

- $ 80 000

noviembre

$ 100,000

$ 500 000

$ 480 000

$ 20 000

$ 100,000

$ 600 000

$ 480 000

$ 120 000

Ingreso

lanzamiento)

(punto de equilibrio)

diciembre

A continuación, se muestran algunos puntos clave del proyecto tradicional en la Tabla 21-1:

» El proyecto generó ingresos por primera vez en julio, después del lanzamiento del proyecto a fines de junio.

» El proyecto finalmente tuvo un ROI total positivo en noviembre, 11 meses después de la proyecto iniciado.

» Al final de un año, el proyecto generó $ 600,000 en ingresos. » Al final del año, el ROI total del proyecto fue de $ 120,000. Ahora mire el ROI para un proyecto ágil en la Tabla 21-2.

384

PARTE 6 La parte de diez

TABLA 21-2

ROI en un proyecto ágil

Mes

Mensual Ingreso

Mensual Costos

Mensual

ROI

enero

$ 80 000

- $ 80 000

febrero

$ 15 000

$ 80 000

marcha

$ 25 000

abril

Total

Costos

ROI

$ 80 000

- $ 80 000

- $ 65 000

$ 15 000

$ 160 000

- $ 145 000

$ 80 000

- $ 55 000

$ 40 000

$ 240 000

- $ 200 000

$ 40 000

$ 80 000

- $ 40 000

$ 80 000

$ 320 000

- $ 240 000

Mayo

$ 70 000

$ 80 000

- $ 10,000

$ 150 000

$ 400 000

- $ 250 000

Junio (proyecto

$ 80 000

$ 230 000

$ 480 000

- $ 250 000

mes de julio

$ 100,000

$ 330 000

$ 480 000

- $ 150 000

agosto

$ 100,000

$ 430 000

$ 480 000

- $ 50 000

septiembre

$ 100,000

$ 530 000

$ 480 000

$ 50 000

octubre

$ 100,000

$ 630 000

$ 480 000

$ 150 000

noviembre

$ 100,000

$ 730 000

$ 480 000

$ 250 000

diciembre

$ 100,000

$ 830 000

$ 480 000

$ 350 000

Ingreso

final)

(punto de equilibrio)

Preste especial atención a estos puntos del proyecto ágil en la Tabla 21-2:

» El proyecto generó ingresos por primera vez en febrero, poco después del inicio del proyecto.

» El proyecto tuvo un ROI total positivo en septiembre, dos meses antes de el proyecto tradicional.

» Al final de un año, el proyecto generó $ 830.000 en ingresos, casi 40 por ciento más que el proyecto tradicional.

» Al final del año, el ROI total fue de $ 350,000, casi tres veces el ROI en el proyecto tradicional.

Al igual que el tiempo de comercialización, las métricas de ROI son una excelente manera para que una organización aprecie el valor continuo de un proyecto ágil. Las métricas de ROI ayudan a justificar los proyectos desde el principio porque las empresas pueden financiar proyectos en función del potencial de ROI. Las organizaciones pueden realizar un seguimiento del ROI para proyectos individuales, así como para la organización en su conjunto.

Capitulo 21 TenMetrics para organizaciones ágiles

385

Nuevas solicitudes en los presupuestos de ROI La capacidad de un proyecto ágil para generar rápidamente un alto ROI proporciona a las organizaciones una forma única de financiar el desarrollo de productos adicionales. La funcionalidad de los nuevos productos puede traducirse en mayores ingresos por productos.

Por ejemplo, suponga que en el proyecto de ejemplo de la Tabla 21-2, el equipo del proyecto debía identificar una nueva característica que tardaría un mes en completarse y aumentaría los ingresos del producto de $ 100.000 por mes a $ 120.000 por mes. Este es el efecto que tendría en el ROI:

» El proyecto aún tendría su primer ROI positivo en septiembre, con un ROI de $ 110,000 en lugar de $ 50,000.

» Al final del año, el proyecto habría generado un ingreso total de

$ 950.000, un 14 por ciento más que si generara $ 100.000 al mes.

» A finales de año, el ROI total sería de 470.000 dólares, un 34 por ciento más que el proyecto original.

Si un proyecto ya está generando ingresos, puede tener sentido que una organización transfiera esos ingresos a un nuevo desarrollo y obtenga mayores ingresos.

Redistribución de capital En un proyecto ágil, cuando el costo del desarrollo futuro es mayor que el valor de ese desarrollo futuro, es hora de que el proyecto termine. El propietario del producto prioriza los requisitos, en parte, por su capacidad para generar ingresos o valor. Si solo los requisitos de bajos ingresos o de bajo valor permanecen en la cartera de pedidos, un proyecto puede finalizar antes de que el equipo del proyecto haya utilizado todo su presupuesto. Luego, la organización puede usar el presupuesto restante del proyecto anterior para comenzar un proyecto nuevo y más valioso. La práctica de mover un presupuesto de un proyecto a otro se llama redistribución

de capital. Para determinar el final de un proyecto, necesita las siguientes métricas:

» El valor (V) de los requisitos restantes en la cartera de productos. » El costo real (CA) del trabajo para completar los requisitos del producto reserva

» El costo de oportunidad (OC), o el valor de tener el trabajo en equipo scrum en un nuevo proyecto

386

PARTE 6 La parte de diez

Cuando V <AC + OC, el proyecto puede detenerse. El costo que se hundiría en el proyecto sería mayor que el valor que recibiría del proyecto. La redistribución de capital permite a una organización gastar de manera eficiente en el desarrollo de productos valiosos y maximizar el ROI general de la organización. Puede encontrar los detalles sobre la redistribución de capital en el Capítulo 13.

Encuestas de satisfacción En proyectos ágiles, la máxima prioridad de un equipo scrum es satisfacer al cliente temprano y con frecuencia. Al mismo tiempo, el equipo scrum se esfuerza por motivar a los miembros individuales del equipo y promover prácticas de desarrollo sostenible. Un equipo scrum puede beneficiarse de profundizar en las experiencias de los clientes y los miembros del equipo. Una forma de obtener información cuantificable sobre qué tan bien un equipo scrum está incorporando principios ágiles es a través de encuestas de satisfacción:

» Encuestas de satisfacción del cliente: Medir la experiencia del cliente con el proyecto, el proceso y el equipo de scrum.

El equipo de scrum puede querer usar encuestas de clientes varias veces durante un proyecto. El equipo de scrum puede utilizar los resultados de la encuesta de clientes para examinar los procesos, continuar con las prácticas positivas y ajustar el comportamiento según sea necesario.

» Encuestas de satisfacción del equipo: Mide la experiencia de los miembros del equipo scrum con la organización, el entorno de trabajo, los procesos, otro equipo del proyecto miembros y su trabajo. Todos en el equipo de scrum pueden realizar encuestas de equipo. Al igual que con la encuesta de clientes, el equipo de scrum puede optar por realizar encuestas de equipo a lo largo de un proyecto. Los miembros del equipo Scrum pueden usar los resultados de la encuesta del equipo para afinar y ajustar regularmente los comportamientos personales y de equipo. El equipo de scrum también puede usar los resultados para abordar problemas organizacionales. Los resultados de las encuestas de clientes a lo largo del tiempo pueden proporcionar una visión cuantitativa de cómo está madurando el equipo scrum como equipo.

Los resultados de la encuesta serán más honestos y gratuitos si la organización fomenta una cultura de apertura, transparencia y apoyo al aprendizaje. Puede armar encuestas informales en papel o utilizar una de las muchas herramientas de encuestas en línea. Algunas empresas incluso tienen software de encuestas disponible a través de su departamento de recursos humanos.

Capitulo 21 TenMetrics para organizaciones ágiles

387

Defectos en la producción Los defectos son parte de cualquier proyecto. Sin embargo, probarlos y repararlos puede llevar mucho tiempo y ser costoso, especialmente cuando llegan a producción. Los enfoques ágiles ayudan a los equipos de desarrollo a minimizar los defectos de forma proactiva. A medida que los equipos de desarrollo repiten el desarrollo de un requisito, prueban y encuentran defectos. El ciclo de sprint facilita la reparación de esos defectos inmediatamente antes de que lleguen a producción. Idealmente, los defectos en la producción no ocurren debido a las pruebas automatizadas y la integración continua, como se analiza en los Capítulos 7 y 15.

El seguimiento de las métricas de defectos puede permitir al equipo de desarrollo saber qué tan bien está previniendo problemas y cuándo perfeccionar sus procesos. Para realizar un seguimiento de los defectos, es útil observar los siguientes números:

» Construir defectos: Si el equipo de desarrollo utiliza pruebas automatizadas y integración, puede rastrear el número de defectos en el nivel de construcción en cada sprint.

Al comprender la cantidad de defectos de construcción, el equipo de desarrollo puede saber si ajustar los procesos de desarrollo y los factores ambientales para poder detectar defectos incluso antes en su proceso de desarrollo.

» Defectos de las pruebas de aceptación del usuario (UAT): El equipo de desarrollo puede rastrear el número de defectos que encuentra el propietario del producto al revisar la funcionalidad completada en cada sprint. Al rastrear los defectos de UAT, el equipo de desarrollo y el propietario del producto pueden identificar la necesidad de refinar los procesos para comprender los requisitos. El equipo de desarrollo también puede determinar si es necesario realizar ajustes en las herramientas de prueba automatizadas.

» Liberar defectos: El equipo de desarrollo puede rastrear el número de defectos que sobrepasar el lanzamiento al mercado.

Los equipos de desarrollo también pueden rastrear el número de días entre la aceptación de la historia del usuario y el descubrimiento de defectos. Cuantos menos días hayan pasado desde que un desarrollador trabajó en la funcionalidad, menor será el costo de reparar el defecto.

Al rastrear los defectos de la versión, el equipo de desarrollo y el propietario del producto pueden saber si son necesarios cambios en el proceso UAT, las pruebas automatizadas o el proceso de desarrollo. Un gran número de defectos en el nivel de lanzamiento puede indicar problemas mayores en el equipo de scrum.

388

PARTE 6 La parte de diez

La cantidad de defectos y si los defectos aumentan, disminuyen o permanecen igual son buenas métricas para iniciar discusiones sobre los procesos del proyecto y las técnicas de desarrollo en las retrospectivas de sprint. Puede obtener más información sobre las pruebas y la gestión proactiva de la calidad en el Capítulo 15.

Tasas de éxito de los objetivos de Sprint Una forma de medir el desempeño ágil del proyecto es la tasa de logro del objetivo del sprint.

Es posible que el sprint no necesite todos los requisitos y tareas del backlog del sprint para lograr el objetivo. Sin embargo, un sprint exitoso debe tener un incremento de producto funcional que cumpla con los objetivos del sprint y cumpla con la definición de hecho del equipo scrum: desarrollado, probado, integrado y documentado. A lo largo del proyecto, el equipo de scrum puede realizar un seguimiento de la frecuencia con la que logra alcanzar los objetivos del sprint y utilizar las tasas de éxito para ver si el equipo está madurando o necesita corregir su rumbo. Las tasas de éxito de Sprint son un punto de partida útil para la inspección y la adaptación. Puede obtener más información sobre cómo establecer objetivos de sprint en el Capítulo 8.

Hora de comprar Hora de comprar es la cantidad de tiempo que tarda un proyecto ágil en proporcionar valor al liberar la funcionalidad de trabajo a los usuarios. Las organizaciones pueden percibir el valor de dos maneras:

» Cuando un producto genera ingresos directamente, su valor es el dinero que puede generar.

» Cuando un producto es para uso interno de una organización, su valor será el capacidad de los empleados para utilizar el producto y contendrá factores subjetivos basados sobre lo que puede hacer el producto.

Capitulo 21 TenMetrics para organizaciones ágiles

389

Al medir el tiempo de comercialización, considere lo siguiente:

» Mida el tiempo desde el inicio del proyecto hasta que muestre el valor por primera vez. » Algunos equipos de scrum implementan nuevas funciones de productos para usar al final de cada pique. Para los equipos de scrum que lanzan con cada sprint, el tiempo de mercado es simplemente la duración del sprint, medida en días.

» Otros equipos de scrum planean lanzamientos después de múltiples sprints e implementan productos características en grupos. Para los equipos de scrum que usan tiempos de lanzamiento más largos, el tiempo para

mercado es el número de días entre cada lanzamiento. El tiempo de comercialización ayuda a las organizaciones a reconocer y cuantificar el valor continuo de los proyectos ágiles. El tiempo de mercado es especialmente importante para las empresas con productos que generan ingresos porque ayuda a presupuestar durante todo el año. También es importante si tiene un proyecto autofinanciado, un proyecto que se paga con los ingresos del producto. Puede obtener más información sobre la generación de ingresos por productos y los proyectos de autofinanciamiento en el Capítulo 13.

Tiempos de ciclo y plomo Tiempo de espera es la cantidad de tiempo promedio entre la recepción de una solicitud de un requisito y la entrega finalizada. Tiempo del ciclo es el tiempo promedio entre el inicio del desarrollo de un requisito y su entrega. Los equipos ágiles trabajan en un entorno ajustado, uno que busca eliminar el desperdicio. Existen restricciones en cada flujo de trabajo o flujo de creación de valor. Los equipos ágiles buscan continuamente formas de identificar y eliminar restricciones para maximizar el flujo de trabajo a través de su sistema. El tiempo de entrega y ciclo brindan no solo una medida de dónde pueden existir cuellos de botella, sino también las expectativas de las partes interesadas con respecto al tiempo promedio que una solicitud que envían puede tardar en completarse. Si el tiempo de espera para un equipo de scrum en particular es de 45 días pero el tiempo de ciclo es de solo 5 días, esta discrepancia puede alertar al equipo para que evalúe su proceso de planificación y refinamiento de la cartera de productos para ver cómo podría ajustar la diferencia de 40 días. Del mismo modo, si el tiempo de entrega es de 45 días y el tiempo del ciclo es de 40 días, es posible que el equipo desee evaluar su flujo de trabajo de desarrollo en busca de cuellos de botella. En cualquier caso, los equipos de scrum siempre deben estar buscando eliminar las restricciones para disminuir tanto el tiempo de liderazgo como el de ciclo de manera adecuada.

390

PARTE 6 La parte de diez

Costo del cambio Los líderes y equipos ágiles adoptan el cambio para la ventaja competitiva del cliente. Pero la aceptación del cambio no debería significar la aceptación de costos innecesarios asociados con los cambios. A medida que los equipos ágiles inspeccionan y adaptan el producto y sus procesos, su objetivo debe ser minimizar continuamente el efecto del cambio. Incrementar la flexibilidad del producto es una forma común de reducir el costo del cambio. Con el desarrollo de software, el uso de una estrategia de arquitectura orientada a servicios (SOA) permite a los equipos ágiles hacer que cada componente de una aplicación sea independiente de los demás, de modo que todo el sistema no requiera cambios cuando se deba cambiar un componente. El desarrollo, las pruebas y la documentación requieren un esfuerzo significativamente menor.

En la fabricación, la estandarización y modularización de piezas ha permitido a los fabricantes de automóviles como Toyota y, más recientemente, WikiSpeed construir automóviles más rápidamente y con menos reparaciones innecesarias debido a la incompatibilidad. (Consulte el Capítulo 4 para obtener más información sobre el sistema de producción de Toyota).

El mapeo de flujo de valor es una técnica común para identificar restricciones en un sistema o flujo de trabajo. Al visualizar (en una pizarra, por ejemplo) cada paso de un proceso, los equipos ágiles pueden identificar dónde la introducción de cambios genera más estrés o costo en sus procesos. Cuando se identifica una restricción, el scrum master y otros agentes de cambio organizacional pueden trabajar para eliminar esa restricción y disminuir el costo de cambios futuros en el sistema.

Rotación de miembros del equipo Los proyectos ágiles tienden a tener una moral más alta. Una forma de cuantificar la moral es midiendo la rotación. Aunque la rotación no siempre está directamente relacionada con la satisfacción, puede ser útil observar las siguientes métricas:

» Rotación del equipo Scrum: La baja rotación del equipo scrum puede ser una señal de ambiente de equipo saludable. La rotación alta del equipo scrum puede indicar problemas con el proyecto, la organización, el trabajo, los miembros individuales del equipo scrum, el agotamiento, los propietarios de productos ineficaces que obligan a los equipos de desarrollo a comprometerse, la incompatibilidad de personalidad, un scrummaster que no logra eliminar los impedimentos o la dinámica general del equipo.

» Facturación de la empresa: Alta rotación de la empresa, incluso si no incluye la equipo de scrum, puede afectar la moral y la eficacia. La alta rotación de la empresa puede ser un signo de problemas en la organización. A medida que una empresa adopta prácticas ágiles, puede ver una disminución en la facturación.

Capitulo 21 TenMetrics para organizaciones ágiles

391

Cuando el equipo de scrum conoce las métricas de rotación y comprende las razones detrás de esas métricas, es posible que pueda tomar acciones para mantener la moral y mejorar el entorno de trabajo. Si la rotación es alta, comience a preguntar por qué.

Versatilidad de habilidades Los equipos de scrum maduros suelen tener más funciones cruzadas que los equipos de scrum menos maduros. Al eliminar los puntos únicos de falla en un equipo scrum, aumenta su capacidad para moverse más rápido y producir productos de mayor calidad. El seguimiento de la versatilidad de las habilidades permite a los equipos scrum y a los gerentes funcionales medir el crecimiento de la funcionalidad cruzada.

Al comenzar, capture las habilidades y niveles existentes contenidos en cada una de las siguientes estructuras organizacionales:

» Habilidades y niveles por persona » Habilidades y niveles por equipo

» Habilidades y niveles por organización Con el tiempo, a medida que cada persona aumenta su cantidad y nivel de habilidades, desaparecen las limitaciones y retrasos debidos a la falta de habilidades. Los equipos ágiles se tratan de habilidades, no de títulos. Quieres miembros del equipo que puedan contribuir al objetivo del sprint todos los días sin el riesgo de puntos únicos de falla.

Proporción de administrador a creador Es probable que las organizaciones más grandes hayan desarrollado una fuerte capa intermedia de gerentes. Muchas organizaciones no han descubierto cómo funcionar bien sin varios gerentes que manejen el personal, la capacitación y la dirección técnica en temas de desarrollo. Sin embargo, debe lograr el equilibrio adecuado entre gerentes e individuos que producen productos. Imagínese dos equipos rivales profesionales de fútbol (fútbol americano) de 11 jugadores cada uno que entrenan intensamente y se preparan para un partido entre ellos. El equipo B vence al equipo A 1-0. Ambos equipos vuelven a entrenar para el próximo partido. La gerencia del equipo A llama a un analista para que brinde una solución. Después de un análisis cuidadoso de ambos equipos, ve que

392

PARTE 6 La parte de diez

El equipo B tiene un jugador como portero y diez repartidos por el campo como defensores, mediocampistas y delanteros, mientras que el equipo A juega con diez porteros a la vez y un delantero para maniobrar el balón hacia la portería sin que ningún miembro del equipo entre en el camino. La gerencia del equipo A llama a un consultor para reestructurar el equipo. Ella encuentra lo que parece obvio: TeamA está jugando con demasiados porteros. El consultor recomienda que el equipo juegue con la mitad de porteros (cinco) y con cinco defensores que puedan transmitir instrucciones al delantero de los porteros que tienen una vista de todo el campo. También sugiere duplicar el cuerpo técnico asistente para aumentar el entrenamiento y la motivación del delantero para marcar goles. En el siguiente partido, el equipo B vuelve a vencer al equipo A, pero esta vez 2-0.

El delantero es cortado, los entrenadores asistentes y los defensores son reconocidos por su estrategia de motivación, pero la dirección pide otro análisis. Como resultado del análisis, construyen un centro de práctica más moderno e invierten en la última tecnología de calzado para la próxima temporada. Cada dólar gastado en alguien que gestiona los procesos organizativos es un dólar que no se gasta en un creador de productos. Realice un seguimiento de su proporción de gerente a creador para identificar la hinchazón y las formas de minimizar la inversión que está haciendo en las personas que no crean productos.

Capitulo 21 TenMetrics para organizaciones ágiles

393

EN ESTE CAPÍTULO

» Encontrar apoyo para un ágil exitoso transiciones

» Involucrarse con Active Agile comunidades » Accediendo a recursos para común

enfoques ágiles

Capítulo

TenValuableResources para profesionales ágiles

METRO

información y soporte para la gestión ágil de proyectos. Para ayudarlo a comenzar, compilamos una listacualquier de diez recursossitio queweb, creemos que son organización, blog y empresa que exista para proporcionar

valioso para respaldar su viaje hacia la gestión ágil de proyectos.

Gestión ágil de proyectos para principiantes Hoja de referencia en línea www.dummies.com Puede utilizar nuestra hoja de trucos en línea como complemento de este libro a medida que comienza a implementar los valores y principios ágiles del Manifiesto Ágil, así como los modelos descritos a lo largo del libro. Encontrará guías prácticas, herramientas, plantillas y otros recursos útiles para su ágil kit de herramientas. Para acceder a la hoja de referencia, vaya a

www.dummies.com, y luego escribe Gestión ágil de proyectos para principiantes en el cuadro de búsqueda.

Capitulo 22 Diez recursos valiosos para profesionales ágiles

395

Scrum para tontos En 2014 publicamos Scrum para tontos ( Wiley) como una guía de campo no solo para scrum sino también para scrum en industrias y funciones comerciales fuera de la tecnología de la información (TI) y el desarrollo de software. Scrum se puede aplicar en cualquier situación en la que desee una retroalimentación empírica temprana sobre lo que está construyendo o persiguiendo en un proyecto.

Obtenga información sobre scrum en industrias como el desarrollo de software de juegos y la producción de bienes tangibles (construcción, fabricación, desarrollo de hardware) y en servicios como la salud, la educación y la publicación. Explore las aplicaciones de scrum en funciones comerciales, incluidas operaciones, gestión de carteras, recursos humanos, finanzas, ventas, marketing y servicio al cliente. Y en la vida cotidiana, vea cómo scrum puede ayudarlo a organizar sus búsquedas de citas, vida familiar, planificación de la jubilación y educación.

La ScrumAlliance www.scrumalliance.org Scrum Alliance es una organización de membresía profesional sin fines de lucro que promueve la comprensión y el uso de scrum. La alianza logra este objetivo promoviendo clases de certificación y entrenamiento de scrum, organizando reuniones de scrum internacionales y regionales y apoyando a las comunidades locales de usuarios de scrum. El sitio de Scrum Alliance es rico en entradas de blog, documentos técnicos, estudios de casos y otras herramientas para aprender y trabajar con scrum. El Capítulo 16 enumera muchas de las certificaciones de Scrum Alliance.

La alianza ágil www.agilealliance.org Agile Alliance es la comunidad ágil global original, con la misión de ayudar a promover los 12 principios ágiles y las prácticas ágiles comunes, independientemente del enfoque. El sitio de Agile Alliance tiene una amplia sección de recursos que incluye artículos, videos, presentaciones y un índice de grupos comunitarios ágiles independientes en todo el mundo.

396

PARTE 6 La parte de diez

La comunidad ágil del Project Management Institute www.projectmanagement.com/practices/agile El Project Management Institute (PMI) es la asociación de membresía de gestión de proyectos sin fines de lucro más grande del mundo. Tiene más de 400.000 miembros y presencia en más de 200 países. PMI apoya una comunidad de práctica ágil y una certificación ágil, el PMI Agile Certified Practitioner (PMI-ACP).

El sitio web de PMI proporciona información y requisitos para la certificación junto con acceso a artículos, libros y seminarios sobre la gestión ágil de proyectos. Los miembros de PMI también pueden acceder al sitio web de la comunidad ágil de PMI, con un centro de conocimiento extenso que incluye publicaciones en blogs, foros, seminarios web e información sobre eventos locales de redes ágiles.

Consorcio Internacional para

Ágil (ICAgile) icagile.com

ICAgile es una organización impulsada por la comunidad que ayuda a las personas a ser ágiles mediante la educación, la concienciación y la certificación. Su hoja de ruta de aprendizaje proporciona apoyo para el desarrollo de la trayectoria profesional en agilidad empresarial, coaching ágil para empresas y equipos, gestión del valor, gestión de la entrega, ingeniería ágil, pruebas ágiles y DevOps.

InfoQ www.infoq.com/agile InfoQ es una comunidad en línea independiente con una sección ágil prominente que ofrece noticias, artículos, entrevistas en video, presentaciones en video y minilibros, todos escritos por expertos en el dominio en técnicas ágiles. Los recursos en InfoQ tienden a ser de alta calidad, y el contenido es único y relevante para los problemas que enfrentan los equipos de proyectos ágiles.

Capitulo 22 Diez recursos valiosos para profesionales ágiles

397

Instituto de empresa ajustada www.lean.org Lean Enterprise Institute publica libros, blogs, bases de conocimientos, noticias y eventos para la comunidad más amplia de pensadores y profesionales de Lean. Mientras busca una gestión ágil de proyectos, recuerde incorporar el pensamiento lean en todo lo que haga. Lean.org es una buena plataforma de lanzamiento para que explore los temas lean relevantes para su situación.

Programación extrema ronjeffries.com/xprog/what-is-extreme-programming/ Ron Jeffries fue uno de los creadores del enfoque de desarrollo de programación extrema (XP), junto con Kent Beck y Ward Cunningham. Ron proporciona recursos y servicios para apoyar el avance de XP en su sitio ronjeffries.com. La sección "¿Qué es la programación extrema?" La sección del sitio resume los conceptos básicos de XP. También están disponibles otros artículos y recursos de programación extrema. en formato wiki en http://wiki.c2.com/?ExtremeProgrammingCorePractices.

PlatinumEdge www.platinumedge.com Desde 2001, nuestro equipo en Platinum Edge ha estado ayudando a las empresas a maximizar el retorno de la inversión (ROI) organizacional. Visite nuestro blog para obtener la información más reciente sobre prácticas, herramientas y soluciones innovadoras que surgen de nuestro trabajo con las empresas Global 1000 y la comunidad ágil dinámica.

También proporcionamos los siguientes servicios, que se describen con más detalle en el Capítulo 18:

» Auditorías ágiles: Auditar su estructura organizativa actual y sus procesos para Cree una estrategia de implementación ágil que genere resultados finales.

» Reclutamiento: Con acceso al mejor talento ágil y scrum, porque hemos

capacitados: lo ayudamos a encontrar las personas adecuadas para iniciar su scrum proyectos, incluidos scrummasters, propietarios de scrumproduct y desarrolladores de scrum.

398

PARTE 6 La parte de diez

» Capacitación: Capacitación corporativa ágil y scrum pública y privada personalizada y certificación, independientemente de su nivel de conocimiento. Además de personalizado y opciones de formación no certificadas, ofrecemos las siguientes certificaciones:

• • • • •

Clases certificadas de ScrumMaster (CSM) Clases de propietario de producto certificado Scrum (CSPO)

Clases certificadas de ScrumDeveloper (CSD) Capacitación e implementaciones de SAFe Scaled Agile Clases de preparación para exámenes de PMI Agile Certified Practitioner (PMI-ACP)

» Transformación: Nada es un factor más importante de éxito futuro que el adecuado entrenamiento. Realizamos un seguimiento de la formación ágil con coaching ágil integrado y

tutoría para asegurar que las prácticas correctas ocurran en el mundo real.

Capitulo 22 Diez recursos valiosos para profesionales ágiles

399

Índice A habilidad, en ADKAR, 347 criterios de aceptación, historias de usuario, 140, 278–279 responsabilidad, en dinámica de equipo, 248 adaptación

de gestión de proyectos, 33–36 de calidad, 30–31 del trabajo en equipo, 31–33

gestión de proyectos ágiles. Ver también ágil específico

enfoques y características

enfoques, descripción general, 65–69

en enfoque ágil, 16, 59

enfoques, similitudes entre, 80 beneficios

en entorno de proyecto ágil, 308 en

de, 57–61, 300, 369–376 certificaciones,

enfoque empírico, 14, 66 en

77, 309

Enterprise Scrum, 342

compromiso con, 297–299

en planificación just-in-time, 120-121

definido, 7

en gestión de calidad, 280-281 en

doble trabajo ágil, 267, 361

scrum framework, 73-74

como enfoque empírico, 13-14, 66

en equipos de desarrollo autogestionados, 112

entorno propicio, creación de, 307-309 falla en, 57

retrospectiva de sprint, 191 Herramienta de gestión de cambios ADKAR, 346–347

falso ágil, 361

estimación de afinidad, 150–152

flexibilidad y estabilidad de, 49–51 versus

fiesta posterior, 165

enfoques históricos, 43–48 historia de,

Agile Alliance, 18, 396

11–13

auditorías ágiles, 398

enfoque integrado en las organizaciones, 40

campeón ágil, 300, 302-303 entrenador ágil. Ver mentor

factores clave para el éxito, 377–381

ágil; prueba de tornasol ágil scrummaster, 41–42

tareas no productivas reducidas en, 51–53 descripción general, 1–3

Manifiesto ágil

control de proyectos con, 56

prueba de fuego ágil, 41–42

calidad y entrega con, 53–54

cambios resultantes de, 40–41

recursos para, 395–399

colaboración con el cliente, 20, 24–25

superioridad de, 14, 16

definido, 18

soporte para, 310

discusión general, 17-20

rendimiento del equipo en, 54–56

individuos e interacciones, 19, 20–22

transición a, 300–302, 343–344, 360–363, 381 versus

descripción general, 13

metodología de cascada, 15, 45–46 modelo de tren de

responder al cambio, 20, 25–26

liberación ágil (ART), 335–336 equipo de transición

funcionalidad de trabajo, 19, 22–24

ágil, 303–304, 353

mentor ágil, 75, 102, 125, 307, 310

historia del ancla, 149

Principios ágiles

arquitectura, 313, 318

prueba de fuego ágil, 41–42

artefactos

cambios resultantes de, 40-41 de

accesibilidad de, 162

satisfacción del cliente, 27-30

en comunicación ágil, 264–265

definido, 18

gestión de costes, 244

panorama general, 13, 26–27

Principios de platino, 37–40

definido, 134 Nexus, 330

Índice

401

artefactos continuado)

CI (integración continua), 31, 79, 176, 277 Cirillo,

descripción general, 263

Francesco, 105

gestión de riesgos, 292-293

influencia, de scrummaster, 100, 178, 380–381

gestión del alcance, 213-214 scrum, 75

coaching, 338, 356–357, 381. Ver también mentor ágil; scrummaster

gestión del tiempo, 236-237

Cockburn, Alistair, 83, 263–264

gestión de la línea de montaje, 188 auditorías, Platinum Edge, 398

codificación, en XP, 78, 79 colaboración

pruebas automatizadas, 176, 281–283, 362, 378

canales de comunicación, 265

velocidad promedio, 230

cliente, en valores del Manifiesto Ágil, 20, 24-25 en

conciencia, 346–347, 352

proceso de elaboración, 175 como beneficio clave de ágil, 371–372

en gestión de adquisiciones, 214, 219–221

en equipos de desarrollo autoorganizados, menú de

documentación apenas suficiente, 23

modos de colaboración 110-111, ES, 341

Beck, Kent, 76

sitios web de colaboración, 89–90, 261

desarrollo del big bang, 44

propiedad del código colectivo, 79, 277

juego de culpas, 363

colocación

Blanchard, Kenneth, 253

señales ágiles de problemas, 364

inflado, alcance, 10-11, 207, 238

crear un entorno de proyecto ágil, 308 como

presupuesto, 228, 239-240

factor clave para el éxito, 378

bichos, 271

papel en el trabajo en equipo,

defectos de construcción, seguimiento, 388

33, 55 creación, 82–83

gráfico de combustión, 87, 157, 167–169, 267–268

éxito de, 260

propietario de la empresa, en Enterprise Scrum, 338

enfoque de mando y control, compromiso

valor y riesgo empresarial, evaluación, 133

247, 103, 297–299 comunicación

métodos ágiles, 263–266 colocación, función en, 82–83

lienzos, Enterprise Scrum, 339

en equipos dislocados, 260-261 en

redistribución de capital, 243–244, 386–387

programación extrema, 78 de alta

certificaciones, 77, 309, 399

tecnología, 88-90

cambio. Ver también Hoja de ruta de cambio de Platinum Edge;

gestión del alcance adaptación a como beneficio de ágil, 59 volverse ágil como requiere, 343–344 desafíos relacionados con, 344–345 costo de, 391 falta de, como fracaso, 206 escollos, evitación, 360–363

respondiendo a, en los valores del Manifiesto Ágil, 20, 25–26 estabilidad y flexibilidad del enfoque ágil, 48–50 enfoques estratégicos a, 345–349 señales de advertencia relacionadas con, 363–365 cheat sheet, 2, 395

jefe de producto propietario (CPO), 320–321

402

Gestión ágil de proyectos para principiantes

baja tecnología, 86–88

resumen, 245 en Platinum Edge change roadmap, 352 prácticas de calidad proactivas, 279 en equipos autogestionados, 250

en equipos de desarrollo autoorganizados, 110 informes de estado y progreso, 266–268 en el éxito de Agile, 310 en el trabajo en equipo, 32–33

tradicional versus ágil, 262–263 fidelidad de comunicación, 82–83 plan de comunicación, 23 comunidades de práctica (CoP), en LeSS, 326

volumen de negocios de la empresa, 391. Ver también restricciones

tiempo de ciclo, 72, 390

de compatibilidad de la organización, herramientas ágiles,

ciclos, en Enterprise Scrum, 338

documentación completa 90–91, 19, 22–24

trabajo cíclico, 163

gestión de proyectos relacionados con la informática, 8-11,

66–69, 271. Ver también desarrollo de software

menús de configuración, ES, 340–342

Patrón de quemado conforme, 169

proceso diario, ágil

consenso, 101, 111

scrum diario, 163-166

consistencia, importancia para la velocidad, 233-234

actividades al final del día, 179–180

cambio de contexto, 107-108

múltiples equipos, desafíos para, 313

mejora continua, equipo de proyecto, 55–56

descripción general, 163

integración continua (CI), 31, 79, 176, 277 contratos,

gestión de adquisiciones, 216

20, 24–25, 215, 219–221, 224 control, con agile, 56,

barricadas, identificación, 178–179

374

roles y responsabilidades, 172-173 funciones de

manejo de costos

envío, creación, 173-179 trabajos pendientes de

artefactos para, 244

sprint, 166-170

terminar proyectos basados en el costo, 243–244

tablero de tareas, 170-172

presupuesto inicial, creación, 239–240 costos a largo plazo, determinación, 242–244 descripción general,

seguimiento del progreso, 166-172

scrum diario

238–239

canales de comunicación, 265

proyecto autofinanciado, creación, 240–241

comunicación cara a cara en, 86

equipos autogestionados, 249

discusión general, 163–166

tradicional versus ágil, 237-238

Nexus, 330–331

velocidad, determinando costos con, 242–244

observadores en, en LeSS, 326

costo de cambio, 391

gestión de adquisiciones, 216

estructuras de costos, 218-219

en sprints de lanzamiento,

coraje, como valor central, 103-104 CPO

196 gestión de riesgos, 292

(jefe de producto), 320-321 equipos

en Roadmap to Value, 119

multifuncionales

gestión del alcance, 210

en LeSS, 327 descripción general, 97, 98

en el marco de scrum, 73, 76 castigos por tardanza, 165, 166

en gestión de calidad, 272

fecha límite, como determinación de la duración del proyecto, 228

dinámica de equipo, 255-257

marcha de la muerte, 35

filosofía del equipo, 107, 108–109 representante

descomposición, 120, 129, 139, 312

del cliente. Ver Product Owner Satisfacción del

área dedicada, configuración, 83–84

cliente, 27–30, 77, 370, 387 Departamento de

equipos dedicados, 107–108, 254–255, 308, 377–378

servicio al cliente, 128

métricas de defectos, 388–389

clientes

definición de hecho. Ver hecho, definición de

beneficios de ágil para, 59

parto, 53–54, 70

colaboración con, 20, 24–25

menú de modos de entrega, ES,

comentarios de, 184

menú de objetivos de entrega 342,

identificando, 122

ES, 340 dependencias, requisito, 133

participación en proyectos, 60

Derby, Esther, 190-191

prepararse para la implementación del producto, 200-201 como

diseño, 79, 275–276

partes interesadas, 128

deseo, en ADKAR, 347

estructuras de equipo personalizadas, 375

uso compartido de escritorio, basado en web, 89

Índice

403

plan de comunicación detallado del proyecto,

responsabilidades de 97–98

23 desarrollo

barricadas, 178–179

prácticas de calidad proactivas, 276–278

gestión del alcance, 208, 212 en

funcionalidad de envío, 175–176

scrum framework, 73, 74

sostenible, 32, 35, 79, 279–280

soporte de scrummaster para, 55, 98, 111, 112

Operaciones de desarrollo (DevOps), velocidad

scrum de scrums, 317

de desarrollo de 198. Ver Sprints de desarrollo de

autogestión, 111–112, 249–251

velocidad. Ver sprints

autoorganización, 110-111

Equipo de desarrollo. Ver también múltiples equipos;

liderazgo de servicio, 252

dinámica de equipo; velocidad

atrasos de sprint, 157

estimación de afinidad, 150-152

reuniones de planificación de sprint,

roles ágiles, 97–98

159–162 retrospectiva de sprint, 187–191

señales ágiles de problemas, 364–365

revisión de sprint, 182, 183, 185

beneficios de ágil para, 61

estabilidad y flexibilidad, 49–50, 51

mejor calidad y entrega, logro, 54 funciones

mecanismos de apoyo, 54–55

cruzadas, 108–109

filosofía del equipo, 107-114

roles y responsabilidades diarios, 172

excelencia técnica y buen diseño, 275 gestión

scrum diario, 164, 165

del tiempo, 235-236

equipos dedicados, 107–108, 255

historias de usuario, beneficios de, 141

definidos, 94, 246

verificar la funcionalidad de envío, 176–178

definición de hecho y riesgo, 287–288 en

versatilidad de, como factor de éxito, 380 corte

proceso de desarrollo, 175

vertical, 314

proceso de elaboración, 174-175

diferencias, búsqueda, 106 disciplina, en

actividades al final del día, 179–180

transición a ágil, 363 equipos

estimación del esfuerzo, 132-133

dislocados, 259-261

póquer de estimación, 148-150

distracciones, 84–85, 104–105, 232, 254

comentarios de 183–184

equipos distribuidos, 259–261

enfoque, 55

documentación

rendimiento mejorado de, 54–55

aproximaciones ágiles a, 53

tamaño límite de, 112–113, 258–259

en los valores del Manifiesto ágil, 19, 22–24

miembros de, en equipo scrum, 93

Principios ágiles, 34

equipo de integración Nexus, 329

necesario, 262

tareas no productivas, 51–53

técnico, 195

apoyo operativo, 197-199 descripción general, 48

propiedad en, 113-114

señales de problemas, 364

usuario, 195

hecho, definición de

entorno físico para, 82-86 miembros

en vigor, 378–379

del equipo piloto, 305

estimación de póquer, 150

prácticas de calidad proactivas, 278

gestión de la calidad, 31

gestión de adquisiciones, 216–217 propietario del producto como ayudante, 55, 96, 98 rol de creación de hoja de ruta del producto, 126 declaración de visión del producto, 125 en gestión de calidad, 272

relación con otros equipos ágiles, 94

404

Gestión ágil de proyectos para principiantes

en sprints de lanzamiento, 194

gestión de riesgos, 287–288 revisión de sprint, 183

funcionalidad de trabajo, 22

doble trabajo ágil, 267, 361 borrador de declaración de visión del producto, 123–125

primeros en adoptar, 123

comunicación cara a cara

gestión del valor ganado (EVM), 267 eBay,

en comunicación ágil, 263

beneficios de, 86

eficiencia, como beneficio del esfuerzo ágil,

canales de comunicación, 265

en equipos dislocados, 260-261

confirmando estimaciones, 159–160

importancia de, 257

definido, 131, 140

versus otros tipos de comunicación, 263–264

estimación, 132-133

prácticas de calidad proactivas, 279

póquer de estimación, 148-150

en sprint backlog, 156-157

papel en el trabajo en equipo, 32

fallando rápido, 57, 169, 289-291

proceso de elaboración, 174-175

falla, con ágil, 57

software de placa electrónica kanban, 89 correo

falso ágil, 361

electrónico, 52, 257

características. Ver también planificación de lanzamientos;

Enfoque empírico de gestión de proyectos, 13-14, 66

libera requisitos de descomposición para, 146 definidos,

actividades al final del día, 179-180

129, 146

definición forzada de terminado, 378–379

agrupación, en la hoja de ruta del producto, 130-131

arquitecto empresarial, SAFe, 334

identificando, en la hoja de ruta del producto, 128-130

Enterprise Scrum (ES), 337–342 pruebas

comercializables mínimos, 152, 227

empresariales, 283

sugerencias para, 211

medio ambiente, ágil, 307-309. Ver también trabajando

ambiente propietarios épicos, SAFe, 334

historias de usuario épicas, 129, 146, 334 Essential SAFe, 332, 333

estimación, definida, 131 estimando afinidad, 150-152

utilizado por los clientes, centrándose en, 120 comentarios, 183–184, 186–187, 272, 357–358 Secuencia de Fibonacci, 148 puño de cinco, 101

proyectos de precio fijo, 218 proyectos de tiempo fijo, 218

flexibilidad, 49–51 flujo, gestión, 72

esfuerzo, en la acumulación de sprints, 156–157

enfoque, 55, 104-105, 254

cronograma del proyecto, con velocidad, 230–231

formalidad, resistencia, 37-38

requisitos, 131–134

SEGURIDAD COMPLETA, 332

póquer de estimación, 148-150

pruebas funcionales, 283

entusiasmo por el cambio, construcción, 352 equipo

funcionalidad

de acción ejecutiva (EAT), 319, 320, 321, 322 meta

completado, y duración del proyecto, 228

scrum ejecutivo (EMS), 321, 322 ejecutivos, beneficios

entrega anticipada de, 58

de ágil para, 58

aparejado, 185

Patrón de quemado esperado, 168, 169

envío, 174-179, 183

programación extrema (XP)

trabajando, 19, 22-24, 193-196, 266

enfoques básicos en, 78 métodos de desarrollo, 276–278 proceso de desarrollo, 175-176

GRAMO

prácticas clave, 78–79

baño de oro, 23, 185

descripción general, 66, 76–78

buen diseño, 275–276

recursos, 398

chismes, desalentador, 106

similitudes con lean y scrum, 80

Greenleaf, Robert K., 253

desarrollo sostenible, 35

coalición rectora, 348

Índice

405

Decir ah etapa, Shu Ha Ri técnica, 359 marcos de

tablero kanban, 72, 87–88, 89

tiempo de alto nivel, determinación, 135

prácticas kanban, 71–72

comunicación de alta tecnología, 88–90

conocimiento, en ADKAR, 347

Enorme marco, LeSS, 324–325

Kotter, John, 348–349

iconos, explicado, 2

solución grande SAFe®, 332, 334, 335

adaptación inmediata, 14, 66 estrategia

scrum a gran escala (LeSS), 323–327

de implementación, 349–351

Larsen, Diana, 190–191

InfoQ, 397

plazo de entrega, 72, 390 liderazgo, 111. Ver también liderazgo

radiadores de información, 87

de servicio liderando el cambio, 348–349

innovación, 51, 254 inspección

Instituto de la empresa ajustada, 398

crear un entorno de proyecto ágil, 308 en

gestión de carteras ajustadas (LPM), 334

enfoque empírico, 14, 66

desarrollo de productos ajustados, 66, 69–72, 80,

en Enterprise Scrum, 342

188 lean-kanban, 71–72

en planificación justo a tiempo, 120–121

aprendizaje, 70, 363, 381

descripción general, 16

departamento legal, 128

en gestión de calidad, 280–281 en

Patrón de quemado menos complicado, 169

scrum framework, 73–74

Lewin, Kurt, 345–346

en equipos de desarrollo autogestionados, 112

prueba de carga, 283

retrospectiva de sprint, 191

costos a largo plazo, 242–244

mensajería instantánea, 89

vendedores de poca monta, 219

enfoque ágil integrado, 40

comunicación de baja tecnología, 86–88

incrementos integrados, Nexus, 330

Patrón de quemado acostado, 169

scrums integrados, 260 equipos de integración, 314–315, 316–318, 328–329 pruebas de integración, 283

METRO

interacciones, en el Manifiesto Ágil, 19, 20–22

trabajos de mantenimiento, 197-199

Consorcio Internacional para Agile (ICAgile), 309, 397

administración, 60–61, 85, 337, 381 proporción

Enfoque INVEST, 147

de administrador por creador, 392–393

scrums aislados, 259

fabricación, 8, 69–70

Operaciones de TI, modelo DevOps, 198

Mark II Aiken Relay Calculator, 271

iteraciones, en metodología de cascada, 67–68

departamento de marketing, 128, 201

iteraciones, 14, 28, 46, 155. Ver también desarrollo

marketplace, preparación para el lanzamiento, 200-201

iterativo de sprints, 53, 55, 59, 65

marshmallow challenge, 44 métodos de producción en masa, 69–70 mejoras de maduración, 358–359

reuniones. Ver también enfoques

Jeffries, Ron, 398

ágiles de scrum diarios a, 52

planificación conjunta del incremento del programa (PI),

en comunicación ágil, 264-265 en

336–337 elaboración justo a tiempo (JIT), 60, 69–70 planificación

equipos dislocados, 260-261

justo a tiempo (JIT). Ver planificación

multiequipo, en LeSS, 327

406

Gestión ágil de proyectos para principiantes

notas de, 265 planificación de sprints, 157–162

tradicional versus ágil, 263 Mehrabian, Albert, 82–83 meta scrums, 320–322 métrica ágil, relevancia de, 372–373 costo del cambio, 391 defectos en la producción, 388-389 tiempos de ciclo y de producción, 390 Proporción de administrador a creador, 392–393 descripción general, 383

retorno de la inversión, 383–387 encuestas de satisfacción, 387 versatilidad de habilidades, 392

Tasas de éxito en las metas de sprint, 389 de éxito, 349–351 Rotación de miembros del equipo, 391–392 tiempo de comercialización, 389–390

características de comercialización mínimas, 152, 227 entorno de trabajo móvil, 85–86 Moore, Geoffrey, 123–124 moral, equipo, 376 Patrón de quemado más complicado, 168, 169 proyectos múltiples, 85 varios equipos desafíos para trabajar con, 312–313 Enterprise Scrum, 337–342

O Ohno, Taiichi, 188 Icono de On The Web, explicado, 2 sprints de un día, 199 apertura, 105–106, 257–258, 352 apoyo operativo, 197–199 organización compromiso, 276, 298–299 restricciones en las herramientas ágiles, 90–91 equipos multifuncionales, soporte para, 256 entornos que habilitan el entorno ágil, 307–309 enfoque ágil integrado en, 40 preparación para la implementación del producto, 199–200 consideraciones sobre adquisiciones, 221–223

barricadas en 178, 300–301 cambio organizacional. Ver cambio; Borde de platino cambiar hoja de ruta influencias externas, como distracción, 85 supervisión excesiva, como distracción, 85 propiedad

código colectivo, 79, 277 como beneficio clave de ágil, 371–372 en equipos autogestionados, 248

en filosofía de equipo, 107, 113-114

PAG programación por pares, 38, 79, 177, 277

scrum a gran escala, 323–327

revisión por pares, 176-177, 277

Nexus, 327–331

pruebas de rendimiento, 283

descripción general, 311–312

visibilidad de rendimiento, 373

Scaled Agile Framework, 332–337

personas, 143, 144–145

Scrum at Scale enfoque, 318–323 en

entorno físico, 82–86, 362

gestión del tiempo, 235–236 corte

PI (incrementos de programa), 335, 336–337

vertical, 314–318

proyectos piloto, 353–354, 356–357 equipo

miembros de equipo con múltiples habilidades,

piloto, elección, 302–307

74, 97 multitarea, 85, 254

planificación. Ver también planificación de lanzamientos; Estimación de

reuniones de varios equipos, en LeSS, 327

afinidad de planificación de sprint, 150-152

canales de comunicación, 264

norte Nexus, 327–331 Nonaka, Ikujiro, 13 años

tareas no productivas, 51–53 Patrón de quemado no participante, 169

requisitos de descomposición, 129, 146–147 estimación de póquer, 148–150 en programación extrema, 79 inspección y adaptación, 120–121 equipos múltiples, desafíos para, 312 descripción general, 117–120, 139–140

proyectos que no deben excederse, 218

Índice

407

planificación continuado)

estructuras de costos, 218-219

cartera de productos, 135-137

determinar la necesidad y seleccionar el proveedor, 216-217

hoja de ruta del producto, 126-135

consideraciones organizativas, 221-223

declaración de visión del producto, incremento

resumen, 205

del programa 121–126, 336–337

equipos autogestionados, 249

elaboración progresiva, 120

tradicional versus ágil, 214–215

para la retrospectiva de sprint, 189 historias de usuario, 140–145

trabajando con el proveedor, 223 producto

planificación de póquer, 148–150

beneficios de ágil para, 60

planes, en valores del Manifiesto Ágil, 20, 25–26

definidos, 313

Platinum Edge change roadmap

objetivo de, desarrollar, 122-123

coaching activo, 356–357

calidad de, 369-370

conciencia y entusiasmo, 352 entorno para

apoyo, preparación, 197–199

el éxito, 355 recopilación de comentarios,

especificaciones técnicas, 23 Pila de Producto

357–358

estrategia de implementación, 349–351

canales de comunicación, 264

mejoras, 357–359

completando, 135-137

descripción general, 349, 350

definido, 130, 134

proyecto piloto, identificación, 353–354

en Enterprise Scrum, 338 priorizando historias de

en expansión progresiva, 359–360

usuarios en, 145 revisando en la planificación de

Hoja de ruta hacia el valor, ejecución, 357

lanzamientos, 152-153 gestión de riesgos, 292

capacitación y contratación, 355

equipo de transformación, formación, 353–354 Platinum Edge Services, 398–399 Platinum Principles, 37–39

gestión del alcance, 212-213, 214 en scrum framework, 75 informes de estado y progreso, 268 en gestión del tiempo, 235,

PMI (Project Management Institute), 77, 397

237 estimación de cartera de productos, 137 características de

Técnica Pomodoro, 105

productos. Ver cuenta con incremento de producto, 75. Ver

Poppendieck, Mary, 70–71

también gestión de productos con funcionalidad de envío, SAFe®,

Poppendieck, Tom, 70–71

335

cartera, definida, 313 Portfolio SAFe®, 332, 333–334

dueño del producto

positividad, alentadora, 106

estimación de afinidad, 151

previsibilidad, 374–375

como rol ágil, 94–96

presentaciones, 52–53

roles y responsabilidades diarios, 172-173

estructuras de precios, 218–219

scrum diario, 165

priorización

equipos dedicados, asegurando, 255

como aumento del control del proyecto, 56

definidos, 28, 48

de los requisitos, 48 a 49, 132, 134 de

definición de hecho, relación con el riesgo, 287–288

riesgo, temprano, 291 a 293

en proceso de desarrollo, 175

en la gestión del alcance, 212

equipo de desarrollo, soporte para, 55, 96, 98

prácticas de calidad proactivas, 271, 275–280

proceso de elaboración, 174

procesos, 19, 20–22, 53

actividades al final del día, 180

dirección de Procuración

en Enterprise Scrum, 338 póquer de

contrato, cierre, 224

estimación, 148, 149

creación de contrato, 219-221

comunicación cara a cara con, 86

408

Gestión ágil de proyectos para principiantes

comentarios de 183–184 como factor clave para el éxito, 380

partes interesadas, identificación, 127-128

gestión del tiempo, 237

LeSS, 324–325

alcance del producto, 206. Ver también temas de productos de

Equipo de integración de Nexus, 329

gestión del alcance, 128-131, 146

en el equipo piloto, 304–305

declaración de visión del producto

preparando el mercado, 200-201

claridad como factor clave para el éxito, 379

priorización de requisitos, 132, 133

canales de comunicación, 264

prácticas de calidad proactivas, 278

borrador, creación, 123–125

gestión de adquisiciones, 217

finalizando, 126

creación de hoja de ruta del producto,

resumen, 80, 121–122, 278 gestión

126-135 declaración de visión del producto,

de adquisiciones, 216

121-126 gestión de calidad, 273

objetivo de producto, 122-123

planificación de lanzamientos, 152-155

gestión de riesgos, 292

responsabilidades de, 95–96

en Hoja de ruta hacia el valor, 119

gestión del alcance, 208–210, 212

gestión del alcance, 209, 211, 213

Scrum at Scale enfoque, 320–322 en

validación y revisión, 125-126 trabajo

scrum framework, 73, 74

productivo, maximización, 51-53

scrum de scrums, 316-317 en el

programa, definido, 313

equipo de scrum, 93

incrementos de programa (PI), 335, 336–337

autogestión, 249-251

nivel de programa, SAFe®, 335

liderazgo de servicio, 252

Progreso

reuniones de planificación de sprint, 159–160 retrospectiva de sprint, 187–191

informes, 112, 266–268 seguimiento diario, 166-172

revisión de sprint, 182, 185, 186

elaboración progresiva, proyecto 120,

estabilidad y flexibilidad de ágil, 49–50 en

129

transición a ágil, 361

control de, 374

verificar la funcionalidad de envío, 177–178

definido, 7, 313

lanzamiento del producto. Ver planificación de lanzamientos; lanzar sprints; lanzamientos

requisitos del producto. Ver requisitos; alcance administración hoja de ruta del producto

claridad de, relación con el éxito, 379 canales de comunicación, 264 requisitos de descomposición para, 146

factores clave para el éxito, 377–381 pausa, 244 previsibilidad, 374–375 costo del proyecto. Ver Facilitador de proyectos de gestión de costes. Ver scrummaster

gestión de proyectos. Ver también proyecto ágil administración; aspectos de gestión específicos;

metodología cascada

Estimación y priorización de requisitos, 131-134

principios ágiles de, 33–36

características, organización, 130-131

necesidad de modernización,

marcos de tiempo de alto nivel, 135

7–11 orígenes de lo moderno,

descripción general, 80, 126-127

8–10 alcance inflado, 10–11

gestión de adquisiciones, 216

tradicional versus ágil, 35–36, 43–48

requisitos, establecimiento, 128-130

metodología de cascada, 15

gestión de riesgos, 292

Project Management Institute (PMI), 77, 397 planificación

en Hoja de ruta hacia el valor, 119

de proyectos. Ver sala de proyectos de planificación, 83–84

ahorrando trabajo, 135

gestión del alcance, 209, 213

cronograma del proyecto, 23

Índice

409

alcance del proyecto, 206. Ver también partes interesadas del proyecto

refuerzo, en ADKAR, 347 estimación

de gestión del alcance. Ver equipo de proyecto de las partes

relativa, 80, 132-133 prioridad

interesadas. Ver también dinámica de equipo rol de mentor ágil, 102

relativa, 133 planificación de lanzamiento

crear un entorno de proyecto ágil, 309

canales de comunicación, 264, 265

definido, 94, 100, 246

requisitos de descomposición para, 146

mejor desempeño de, 54–56 tareas no

definidos, 80

productivas, reducción, 52–53 descripción

discusión general, 152-155

general, 48

múltiples equipos, desafíos para, 312

entorno físico para, 82–86 relación con otros

gestión de adquisiciones, 216

equipos ágiles, 94 estabilidad y flexibilidad de ágil, 49–50 cronograma del proyecto, 228, 230–231 Herramienta Prosci ADKAR, 346–347

gestión de riesgos, 292 en Roadmap to Value, 119 gestión de alcance, 209, 214 gestión del tiempo, 227, 237 lista de trabajos pendientes de sprints de lanzamiento, 199–200 sprints

de lanzamiento

debate general, 193-196

calidad

marketplace, preparación, 200-201

con ágil, 53–54, 60, 369–370

apoyo operativo, 197-199

principios ágiles de, 30–31

organización, preparación, 199-200

incorporados, en lean, 71 definido, 269, 275 gestión de la calidad pruebas automatizadas, 281–283

métodos de desarrollo, 276–278 comunicación cara a cara, 279 panorama general, 31, 272–273

prácticas proactivas, 275–280 propietario del producto y equipo de desarrollo, 278

descripción general, 154, 193

ingeniero de trenes de lanzamiento (RTE), 335 lanzamientos

cálculo del costo de, 244 defectos, seguimiento, 388

definido, 127 estimación de la duración del proyecto, 231 en programación extrema, 79 gestión del alcance, 212

inspección y adaptación periódicas, 280–281 equipos

Recordar icono, explicado, 2

de autogestión, 251

áreas de requisitos, requisitos LeSS Huge, 324,

en sprints, 273–274

325. Ver también estimación de afinidad de

desarrollo sostenible, 279–280

gestión del alcance, 150-152

excelencia técnica y buen diseño, 275–276 tradicional

en gestión ágil de proyectos, 48–49, 56

versus ágil, 269–272

descomposición de, 146–147

historias de usuario y criterios de aceptación, 278–279

establecimiento, 128-130

estimación, 131-134

reclutamiento, 355, 398

refactorización, en XP, 78 refinamiento, Nexus, 331 etapa de recongelación, modelo de cambio de Lewin, 346 pruebas de regresión, 282

desafíos regulatorios, 301

410

documentación de, 23

Gestión ágil de proyectos para principiantes

póquer de estimación, 148-150

priorización, 134 cartera de productos, 135-137 elaboración progresiva de 120, 129 historias de usuarios, 140–145

recursos, 107–108, 240, 246

respeto, 104, 106 retorno de la inversión (ROI), 58, 123, 383–387

similitudes con Lean y XP, 80 sprints, 73–74

Rhode Island etapa, Shu Ha Ri técnica, 359

Scrum Alliance, 77, 309, 396 Scrum at

funcionalidad amañada, 185

Scale Approach, 318–323 Scrummaster

riesgo, 132, 133, 283, 371 perfil de riesgo e inversión, 57

como función ágil, 98-100 señales

gestión de riesgos

ágiles de problemas, 365

definición de hecho, 287–288

accesibilidad de artefactos, 162

identificación temprana, priorización y respuesta, 291–293 fallando

influencia de, 100, 178, 380–381 habilidades de

rápidamente, 289–291

creación de consenso, 101

descripción general, 286

creación de contratos para adquisiciones, 219

proyectos autofinanciados, 288–289

roles y responsabilidades diarios, 172, 173

equipos autogestionados, 251

scrum diario, 164, 165

tradicional versus ágil, 283–286

equipos dedicados, asegurando,

Hoja de ruta hacia el valor, 118–120, 208–210, 307–308, 357

255 en proceso de desarrollo, 175

ROI (retorno de la inversión), 58, 123, 383–387 Royce,

apoyo al equipo de desarrollo, 55, 98, 111, 112

Winston, 8–9, 67–68

distracciones, eliminación, 84–85, 232

RTE (ingeniero de tren de liberación), 335

actividades al final del día, 180

en Enterprise Scrum, 338

S departamento de ventas, 128

Curva de Satir, 354 encuestas de satisfacción, 387

Scaled Agile Framework® (SAFe®), 332–337 escalado en

póquer de estimación, 148, 149 en LeSS, 324 Equipo de integración de Nexus, 329 tareas no productivas, reducción, 52 descripción general, 48 en el equipo piloto, 305–306

equipos ágiles. Ver calendario de equipos múltiples, 23. Ver

gestión de adquisiciones, 217, 222, 224 gestión

también hinchazón del alcance de la gestión del tiempo,

de la calidad, 273

10-11, 207, 238

responsabilidades de 99–100

fluencia del alcance, 16, 207-208 gestión del alcance

revisión de la declaración de visión del producto, 125 obstáculos, identificación, 178-179

artefactos para, 213–214

obstáculos, prevención, 233

introducción de cambios de alcance, 211

Enfoque de Scrum at Scale, 319–320 en

gestión de cambios de alcance, 211–213

Scrum Framework, 74

descripción general, 205–224

scrum de scrums, 317-318 en el

equipos autogestionados, 249

equipo de scrum, 93

en todo el proyecto, 208–210

autogestión, 249-251

gestión del tiempo, 234-235

liderazgo de servicio, 252-253

tradicional versus ágil, scrum 206-208 certificaciones, 77 ES generalizaciones de elementos, 337–338 historia de, 13

reuniones de planificación de sprint, 159 retrospectiva de sprint, 187-191 revisión de sprint, 186 seguimiento del progreso, 172

scrum de scrums, 260, 315–318

descripción general, 46,

scrum de scrums de scrums, 319, 320, 321, 322

66, 73 recursos para, 396

scrum room, 83–84

roles, artefactos y eventos, 74–76

Índice

411

equipo de scrum. Ver también proceso diario, ágil; múltiples equipos; dinámica de equipo; velocidad

en el Manifiesto Ágil, 20 principios ágiles de calidad, 30, 31

coaching activo para, 356–357

pruebas automatizadas, 281–283

señales ágiles de problemas, 365

bichos, 271

presupuesto, creación inicial, 239

métodos de desarrollo, 276–278

mejora continua, 56

Modelo de DevOps, 198

valores fundamentales, 102–106

método de control empírico, 13-14

crear un entorno de proyecto ágil, 308

programación extrema, 76-79

definido, 93, 246

magro, 70–72

distribuido, 259-260

modernizar la gestión de proyectos en, 10-11, 17-18 tasas

actividades al final del día, 179–180

de éxito y fracaso de proyectos, 9

costo a largo plazo de, determinar, 242 reducir el costo de, 242–243

hinchazón del alcance, 10-11

metodología en cascada, 8–9, 67–69 arquitecto

apoyo operativo, preparación para, 197-199

/ ingeniero de soluciones, SAFe®, 335 gestión de

entorno físico para, 82-86

soluciones, SAFe®, 335 ingeniero de trenes de

piloto, 304

soluciones (STE), 335 trenes de soluciones,

relación con otros equipos ágiles, 94

SAFe®, 334

sprints de lanzamiento, 193-196

Spears, Larry, 252-253

gestión de riesgos, 291-293

Spira, Jonathan, 104

Shu Ha Ri técnica de aprendizaje, 358–359

atrasos de sprint

planificación de sprints, 156–162

dividir historias de usuarios en tareas, 160–162

retrospectiva de sprint, 187-191

canales de comunicación, 265

revisión de sprint, 181-187

actividades al final del día, 179–180

filosofía del equipo, 107-114

en Enterprise Scrum, 338

gestión del tiempo, 235–236

ejemplo de, 158

volumen de negocios en, 391

velocidad, 154

Nexus, 330 sprints de lanzamiento, 194,

scrumboard, en ES, 338

196 gestión de riesgos, 292

ScrumBut, 363

gestión del alcance, 214

scrumming the scrum, 191

en el marco de scrum, 75

certificaciones de Scrum.org, 309

informes de estado y progreso, 267, 268

proyectos autofinanciados, 58, 240–241, 288–289

gestión del tiempo, 237

autogestión, equipo, 97, 107, 111–112, 248–251, 275 autoorganización, equipo, 97, 107, 110–111, 248–251 liderazgo de servicio, 98, 100, 247, 252–253, 301 sombreado, definido, 38

seguimiento del progreso, 166-170 planificación de sprint

canales de comunicación, 264 descomponiendo los requisitos para, 146

funcionalidad de envío, 174–179, 183

en Enterprise Scrum, 338

mostrar, no decir concepto, 263

en LeSS, 324

Shu Ha Ri técnica de aprendizaje, 358–359 simplicidad, 60–61, 79 estrategia informada situacionalmente. Ver planificación de equipos de tamaño limitado, 107, 112–113, 258–259 habilidad,

reunión para, 157–162 varios equipos, desafíos para, 312–313 Nexus, 330 descripción general, 155–156

versatilidad, seguimiento, 392

gestión de adquisiciones, 216

pequeñas emisiones, en XP, 79

gestión de riesgos, 292

pruebas de humo, 282, 283

en Roadmap to Value, 119

desarrollo de software. Ver también Equipo de desarrollo; aspectos específicos del desarrollo

gestión del alcance, 209–210

412

Gestión ágil de proyectos para principiantes

en el enfoque de scrum, 76

gestión del alcance, 210

sprint backlog, 156-157

en el marco de scrum, 76

reunión de planificación de sprint, 157-162 gestión del tiempo, 227

Sprint retrospectiva agenda para 190-191 señales ágiles de problemas, 365

informes de estado y progreso, 267 sprints. Ver también proceso diario, ágil; lanzar sprints; velocidad

actividades involucradas, 156 principios ágiles, 35

canales de comunicación, 265

signos de problemas ágiles, 364

definido, 56

presupuesto, creación inicial, 239

en Enterprise Scrum, 338

gráficos de evolución, 167-169

inspeccionando y adaptando, 191

equipos dedicados, beneficios de, 108

elementos para discutir, 190

definidos, 14, 28, 155

longitud de, 189

en Enterprise Scrum, 338

en LeSS, 324

estimar el número necesario, 154 tasas

reunión para, 189-191

de éxito de metas, 389

varios equipos, desafíos para, 313

duración de, 155, 233, 234

Nexus, 331

objetivos Nexus para, 330 un

panorama general, 181, 187–188

planificación para, 189

día, 199

Platinum Edge change roadmap, 356–357

en Platinum Edge change roadmap, 358

calidad y entrega relacionada con, 54 gestión

gestión de adquisiciones, 216

de calidad en, 273–274

gestión de calidad, 280, 281 en

en gestión de riesgos, 286

sprints de lanzamiento, 196

roles y responsabilidades en, 172-173

gestión de riesgos, 293

gestión del alcance, 212

en Roadmap to Value, 120

en el enfoque scrum, 73–74, 75

gestión del alcance, 210

estabilidad y flexibilidad debido a, 49–50

en scrum framework, 73, 76

pruebas en, 273–274

revisión de sprint señales ágiles de problemas, 365

seguimiento del progreso, 166-172

versus métodos tradicionales, 46

canales de comunicación, 265

tablas kanban específicas de sprint, 87

en Enterprise Scrum, 338

estabilidad, de ágil, 49–51

comentarios, 183–184, 186–187

partes interesadas

directrices para 184-185

como función ágil, 100-102

en scrum a gran escala, 325–326

señales de problemas ágiles,

longitud de, 184

365 comentarios de, 184

en LeSS, 324

participación en proyectos, 60

varios equipos, desafíos para, 313

creación de persona con la ayuda de, 144 en el

Nexus, 331

equipo piloto, 306

descripción general, 181–182

Hoja de ruta del cambio de Platinum Edge, 357–358 preparándose para, 182–183

hoja de ruta del producto, identificación en, 127-128 en el equipo del proyecto, 94

revisar la declaración de visión del producto con, 125

gestión de adquisiciones, 216

en el marco de scrum, 75

gestión de la calidad, 280–281

equipos autogestionados, 250

en sprints de lanzamiento, 196 gestión de riesgos, 293 en Hoja de ruta hacia el valor, 119

retrospectiva de sprint, 187 revisión de sprint, 185, 186 historias de usuario, identificando, 142–143

Índice

413

código estándar, en XP, 79

equipos dislocados, 259-261

Standish Group, 9, 10, 11, 14, 284

limitación del tamaño del equipo de desarrollo,

pruebas estáticas, 176, 283

258-259 apertura, refuerzo, 257-258

informes de estado, 23, 266–268 STE (ingeniero de

resumen, 247

trenes de soluciones), 335 procesos de fabricación

autogestión y autoorganización, 248-251 liderazgo de

basados en pasos, 8 notas adhesivas, 87

servicio, 252-253 tradicional versus ágil, nivel de

puntos de la historia, 364. Ver también historias de usuarios;

equipo 245–247, SAFe®, 336

enfoques estratégicos de velocidad para el cambio, 345–349

filosofía del equipo

programas estratégicos, 227

funcionalidad cruzada, 108–109

racionalización, 34

equipo dedicado, 107–108

menú de patrones estructurales, ES, 340–341

descripción general, 107

métricas de éxito, 349–351

propiedad, 113-114

tasas de éxito, 16. Ver también gestión de riesgos

autogestión, 111–112

desarrollo sostenible, 32, 35, 79, 279–280

autoorganización, 110-111

Sutherland, Jeff, 259–260

equipos de tamaño limitado, 112–113

enjambre, 80, 160, 379

encuestas de satisfacción del equipo, 387

arquitecto / ingeniero de sistemas, SAFe®, 335

equipos. Ver también equipos multifuncionales; desarrollo

systemmetaphor, en XP, 79 prueba de sistema, automatizada, 176

equipo; múltiples equipos; Grupo de proyecto; equipo de scrum transición ágil, 303–304, 353 estructuras personalizadas para, 375

dedicado, 107–108, 254–255, 308, 377–378

barricadas tácticas, 178

empoderamiento de in lean, 71 acción

horarios tácticos, 227

ejecutiva, 319, 320, 321, 322

Takeuchi, Hirotaka, 13 años

programación extrema, 78, 79

asignación de talentos, 107–108

integración, 314–315, 316–318, 328–329

tablero de tareas

prácticas kanban, 71–72

dislocados, 259–261

canales de comunicación, 265

rotación de miembros, 391–392

actividades al final del día, 180

moral de, 376

descripción general, 72, 87–88

rendimiento de, en ágil, 54–56

gestión de riesgos, 293

piloto, eligiendo miembros de, 302–307 en

informes de estado y progreso, 268

Platinum Principles, 38

seguimiento del progreso con, 170-172

tamaño limitado, 107, 112–113, 258–259

tareas

transformación, formación, 353–354

dividir las historias de usuario en 160–162

Problemas de transición relacionados con,

definidas, 129

362 trabajo en equipo, principios ágiles de,

estimación del esfuerzo para completar, 156–157

31–33 documentación técnica, 195

seguimiento del progreso de, 166–172

excelencia técnica, 275–276

cambio de tarea, 254

especificaciones técnicas, 23

TDD (desarrollo impulsado por pruebas), 79, 276–277

Ícono de Material técnico, explicado, 2

acuerdo de equipo, 112

desarrollo impulsado por pruebas (TDD), 79, 276–277

dinámica de equipo

pruebas

comunicación, 262–268

automatizado, 176, 281–283, 362, 378

equipos multifuncionales, 255–257

cliente, 201

equipos dedicados, 254–255

en programación extrema, 78

414

Gestión ágil de proyectos para principiantes

en la gestión de la calidad, 271, 273–274 en

épico, 129, 146, 334

la gestión de riesgos, 285

póquer de estimación, 148-150

en sprints, 273–274

Enfoque INVEST, 147

en cascada versus metodología ágil, 46 temas,

descripción general, 140–141

128-131, 146

prácticas de calidad proactivas, 278–279

paliza, 70, 108

planificación de versiones, 153–154

marcos de tiempo, determinación de alto nivel,

requisitos, determinantes, 144-145

135 gestión del tiempo

funcionalidad de envío en términos de, 174

artefactos para, 236–237

sprint backlog, 156-157

reducción de costos al reducir el tiempo, 243–244

partes interesadas, identificación, 142–143

equipos múltiples, 235–236

pasos para crear, 142-145

resumen, 227

enjambres, 160

duración del proyecto, determinante,

en el tablero de tareas, 171

228 gestión del alcance, 234-235

usuarios, identificación, 143–144

equipos autogestionados, 249

tradicional versus ágil, 225-227 de

verificando, 177 usuarios, 28, 143–144

velocidad, 228-234 tiempo de comercialización, 389–390

proyectos de tiempo y materiales, 218

Timeboxing, 158, 199 Icono de sugerencia, explicado, 2 Toyota, 69–70, 188

formación, 355, 361, 399 equipo de transformación, formando, 353–354 equipo de transición, ágil, 303–304, 353 transparencia, 14, 66, 308 viajeros, en LeSS, 327

V valor como beneficio de negocios ágiles, 59, 60-61, evaluando, 133

definido, 132 tiempo de comercialización, 389–390 historia de usuario, 140

lista de valores, en ES, 338, 339 value streammapping, 391

confianza, 114, 248

flujo de valor, SAFe®, 334

rotación, miembro del equipo, 391–392

valores Manifiesto ágil, 19-26

núcleo ágil, 102-106 velocidad

etapa de descongelación, modelo de cambio de Lewin, 346

promedio, 230

unidades de prueba, automatizado, 176, 282

calculando, 229-230

unidades de trabajo, 87

consistencia, importancia de, 233–234 de

prueba de aceptación del usuario (UAT), 283, 388

equipos dedicados, 254

documentación del usuario, 195

estimando el cronograma del proyecto con

historias de usuarios

230-231 en aumento, 231-233

estimación de afinidad, 150-152

costos a largo plazo, determinantes, 242–244

historia del ancla, 149

reducción de costos al aumentar, 242–243

dividir en tareas, 160–162

monitoreo, 229

calcular el costo de, 244

descripción general, 80, 228–229,

elegir para sprint, 159–160 requisitos de descomposición para, 147

373 equipo scrum, 154

definidos, 80, 129, 139, 228

proveedores, en gestión de adquisiciones, 215, 216–217, 219, 223

elaboración, 174-175

verificar la funcionalidad de envío, 176–178

Índice

415

versatilidad, 380, 392

cámaras web, 89

corte vertical, 314–318, 326

informes de estado semanales,

videoconferencia, 89, 260

23 pizarrones, 87

visión, liderar el cambio, 348

trabajo en curso (WIP), limitación, 72

visualización, 38–39, 71–72, 339 von

velocidad de trabajo. Ver entorno de

Moltke, Helmuth, 118

trabajo de velocidad equipo de colocación, 82–83

área dedicada, preparación, 83–84 distracciones, eliminación, 84–85

Despierta, Bill, 147 Icono de advertencia, explicado, 2 residuos, 60, 70

metodología cascada versus métodos ágiles, 15, 45–46

en dispositivos móviles, 85–86

comunicación de alta tecnología, 88–90 comunicación de baja tecnología, 86–88 descripción general, 81–82

entorno físico, 82–86

en gestión de proyectos relacionados con la informática, 66-69

en Platinum Edge cambiar la hoja de ruta, 355

costo de proyectos fallidos en, 289-290

herramientas, elegir, 90–91

iteración en, 67–68

para la transición a ágil, 362

aspectos principales de, 47

funcionalidad de trabajo, 19, 22–24, 193–196, 266

oportunidad de cambio, 26

escritura, prefiriendo la visualización a, 38–39 Wujec,

descripción general, 8–9

Tom, 44

perfil de riesgo e inversión para, 57 gestión de riesgos en, 285, 286 variación del alcance, 207-208 Uso compartido de escritorio basado en web, 89

416

Gestión ágil de proyectos para principiantes

X XP. Ver Programación extrema

Sobre los autores Mark C. Layton, conocido globalmente como Sr. ágil, es un estratega organizacional e instructor de certificación Scrum Alliance con más de 20 años en el campo de la gestión de proyectos / programas. Es el presidente de Los Ángeles para Agile Leadership Network, el autor de la revista internacional Scrum para tontos y Gestión ágil de proyectos para principiantes serie de libros (ambos publicados por Wiley), el creador de la Curso de video completo de

Fundamentos ágiles con Pearson Education y el fundador de Platinum Edge, LLC, una empresa de mejora organizativa que apoya a las empresas que realizan la transición de cascada a ágil.

Antes de fundar Platinum Edge en 2001, Mark desarrolló su experiencia como ejecutivo de una firma consultora, entrenador de administración de programas y líder de proyectos en las trincheras. También pasó 11 años como Especialista en Criptografía para la Fuerza Aérea de EE. UU., Donde obtuvo medallas de elogio y logros por sus logros.

Mark tiene un MBA de la Universidad de California, Los Ángeles y la Universidad Nacional de Singapur; un B.Sc. ( summa cum laude) en Ciencias del Comportamiento de Pitzer College / Universidad de La Verne; y un AS en Sistemas Electrónicos de Air Force's Air College. También es un Graduado Distinguido de la Escuela de Liderazgo de la Fuerza Aérea, un Entrenador de Scrum Certificado (CST), un Profesional de Gestión de Proyectos (PMP) certificado, un receptor de la certificación de gestión de proyectos avanzados (SCPM) de la Universidad de Stanford y un Programa Marco Ágil Escalado certificado. Consultor (SAFe SPC).

Además de sus libros y videos, Mark es un orador frecuente en las principales conferencias sobre Lean, Scrum, XP y otras soluciones ágiles. Puede encontrar información adicional en platinumedge.com. Steven J. Ostermiller es un coach, mentor y formador que empodera a líderes, equipos e individuos para que sean más ágiles. Steve es cofundador y organizador de Utah Agile (patrocinado por Agile Alliance, ScrumAlliance y Agile Leadership Network), una comunidad profesional comprometida con aumentar la agilidad para las empresas, la tecnología y las personas de Utah. Desarrolló y enseñó el plan de estudios de gestión de proyectos ágil de una escuela de negocios y es miembro de su junta asesora de gestión de proyectos. Steve también fue editor técnico en proyectos como Scrum para tontos y de Pearson Education Curso en video

completo de Fundamentos ágiles. También ocasionalmente habla y escribe sobre su experiencia con técnicas ágiles para el hogar.

Steve facilita los compromisos de transformación ágil de Platinum Edge, LLC a través de auditorías, reclutamiento, capacitación y coaching integrado. Ha trabajado con liderazgo ejecutivo y equipos individuales en finanzas, salud, medios de comunicación, entretenimiento, defensa y energía, gobierno local y estatal, logística, comercio electrónico, fabricación, implementaciones de ERP, desarrollo de PMO, startups y organizaciones sin fines de lucro. Es un Scrum Professional certificado (CSP) y un Project Management Professional (PMP), y tiene una licenciatura en Business Management / Organizational Behavior de Marriott School of Management en Brigham Young University. Steve pasa el mayor tiempo posible con su adorable esposa y sus cinco encantadores hijos en Utah viviendo sus sueños, una comida casera a la vez.

Dedicatorias A los amigos, familiares y seres queridos especiales que aman y apoyan incansablemente mientras persigo estas ideas locas. Su tiempo es ahora. -Marcos Para Gwen, mi respuesta final y completa. Y a nuestros cinco pequeños, que me dan todas las razones para inspeccionar y adaptar continuamente. - Steve

Agradecimientos de los autores Nos gustaría agradecer nuevamente a las numerosas personas que contribuyeron a la primera edición de este libro y ayudaron a hacerla realidad.

También estamos muy agradecidos con quienes ayudaron a hacer de esta segunda edición una guía de campo más valiosa: David Morrow por su conocimiento y edición técnica; Caroline Patchen por asegurarse de que estos conceptos se entienden más fácilmente a través de una visualización clara; Jeff Sutherland, Ken Schwaber, Kurt Bittner, Patricia Kong, Dean Leffingwell, Alex Yakyma, Inbar Oren, Craig Larman, Bas Vodde, Mike Beedle y Michael Herman por brindar opciones de escalado al público y por sus valiosos comentarios con el nuevo capítulo de escalado ; ya Amy Fandrei, Susan Pink y el equipo más amplio de John Wiley & Sons. Todos ustedes son fantásticos profesionales; gracias por la oportunidad de mejorar aún más este libro. Y un agradecimiento a los firmantes del Manifiesto Ágil. Gracias por unirse, encontrar puntos en común e iniciar el debate que nos inspira a seguir siendo más ágiles.

Agradecimientos del editor Editor de adquisiciones: Amy Fandrei

Editor de producción: Antony Sami

Editor de proyectos: Susan Pink

Editor de copia: Susan Pink

Editor técnico: David Morrow Asistente editorial sénior: Cherie caso

ACUERDO DE LICENCIA DE USUARIO FINAL DE WILEY Vaya a www.wiley.com/go/eula para acceder al EULA del libro electrónico de Wiley.