Los Fundamentos de Agile Scrum

Frank Turley, Nader K. Rad

• Editorial: Van Haren Publishing
• Año: 2019
• ISBN:
  9789401805407
• Edición: 1
• Categoría: Éducation
• Categoría: Éducation générale

Esta es una guía simple y fácil de entender para cualquiera que quiera aprender sobre Agile y el marco Scrum. Cubre los conceptos y principios subyacentes, junto con los roles y responsabilidades de Scrum, eventos, artefactos y enfoques a cómo escalar, así como prácticas y técnicas generales.? En lugar de elogiar Agile, el libro se enfoca en comprender qué es Agile de verdad, de una manera simple y consistente, y examina los tipos de proyectos para los que funciona y aquellos para los que puede no funcionar. Es una base que le ayuda a navegar por los problemas cotidianos que nos encontramos en el mundo real.? El libro es una guía completa del núcleo del marco de Scrum, basado en la Guía Scrum (edición de noviembre de 2017). Cubre todos los roles y responsabilidades, eventos y artefactos, con una breve sección sobre Scrum Escalado.? Hay un capítulo sobre Programación eXtrema, que sirve para explorar de manera integral, algunos de los métodos y técnicas Agile más importantes, como el Desarrollo guiado por pruebas y la Programación en pareja.? El cuarto capítulo es una descripción general de la metodología DSDM®, que se centra principalmente en el enfoque y la gestión del alcance y los contratos de precio fijo de manera estructurada.? En el último capítulo hay una descripción general de Kanban y ScrumBan.Este libro está alineado con el programa de certificación de EXIN Agile Scrum Foundation

1. EL CONCEPTO AGILE

Si su objetivo es aprender algo que le pueda beneficiar en sus proyectos, debe reflexionar sobre dos temas que a menudo se malinterpretan:

1. Puede que a menudo escuche la frase, “Agile es una forma de pensar”. La verdad es que Agile requiere una determinada forma de pensar, como todo, pero no es correcto decir que es una forma de pensar. Decir “Agile es una forma de pensar”, en la práctica, solo lleva a una cosa: poder trabajar como uno quiera, llamándolo Agile, sin aceptar críticas ni buscar mejoras reales.

2. Si tiene el más mínimo conocimiento de cómo funcionan los sistemas autoritarios, sabrá que siempre tiene que haber un enemigo. Este concepto cubre los agujeros que pueda tener su sistema y ayuda a controlar a las masas. Muchos profesionales de Agile usan la palabra “cascada” para referirse al enemigo; y mientras que el concepto “cascada” no se acaba de definir del todo, se insinúa que son los sistemas de gestión de proyectos ya establecidos y conocidos. Si su objetivo es tener éxito en proyectos, no necesita crear la ilusión de un enemigo externo. Y recuerde que todo sistema de éxito se construye sobre sistemas existentes, sin tener que empezar de cero. Y aunque la crítica es absolutamente necesaria, debe hacerse desde el respeto y el conocimiento.

Así pues, hablemos de la verdadera naturaleza de Agile.

■ METODOLOGÍA DE ENTREGA DE PROYECTO Y CICLO DE VIDA

Cuando se desarrolla software, de una manera u otra, se realizan los siguientes pasos, bien para funcionalidades individuales o para la solución completa:

■ Analizar

■ Diseñar

■ Desarrollar

■ Integrar

■ Prueba (Test)

Por supuesto, se puede usar otra terminología para esos pasos, o agruparlos en menos pasos, o dividirlos en más; está bien. Estos pasos los podemos llamar procesos de entrega.

Ahora, la pregunta es, ¿Cómo vamos a gestionar y realizar estos procesos? Piense en algunas opciones antes de leer el resto de este capítulo.

¿En cuántas opciones ha pensado?

Puede que tenga muchas opciones en mente, pero todas deben pertenecer a una de las dos formas genéricas que hay. A propósito, estas opciones las podemos llamar el ciclo de vida del desarrollo.

Un ciclo de vida genérico es algo así:

En este ciclo de vida, cada proceso se debe completar antes de proceder al siguiente; es decir, analizamos por completo el requisito y decidimos qué queremos que contenga la solución. Entonces, diseñamos la arquitectura de la solución y averiguamos la mejor manera de dar forma a las características. Entonces, los programadores empiezan a trabajar en las distintas unidades y después las unidades se integran en una solución. Y esa solución se prueba.

Es obvio que los pasos se pueden solapar; por ejemplo, no es necesario esperar a que todas las unidades estén completas antes de integrarlas y probarlas. Su ciclo de vida puede tener el siguiente aspecto:

En esencia, no es distinto del ciclo de vida anterior; seguimos teniendo una secuencia de procesos de desarrollo como motor principal del ciclo de vida.

Como podrá observar, este tipo de ciclo de vida se basa en un esfuerzo inicial por entender qué es lo que vamos a producir. Tenemos una especificación por adelantado, un diseño por adelantado y, por consiguiente, un plan por adelantado. Por eso, a veces se le llama un desarrollo dirigido por el plan. También intentamos predecir qué es lo que queremos y cómo se puede producir, y por eso también se le suele llamar predictivo.

Un Ciclo de vida Predictivo es la manera habitual y apropiada de desarrollar muchos proyectos, como por ejemplo un proyecto de construcción. En primer lugar, se planifica y diseña, y luego se sigue ese plan y diseño. Sin embargo, esto no es cómodo para algunos tipos de proyectos.

Piense en el típico proyecto de desarrollo de TI. Puede dedicarle mucho tiempo a la especificación y análisis de los requisitos, y basarlo todo en eso. ¿Qué ocurre después? ¡Que el cliente no estará contento cuando vea el resultado! Pedirá cambios, y los cambios son caros en este ciclo de vida porque es posible que haya que revisar todo el trabajo anterior.

Como se suele decir en este sector, el cliente no sabe lo que quiere hasta que ve el producto. ¿Cuándo ven el producto? Hacia el final del proyecto. En ese punto, el coste de cambiar es máximo.

Para superar este problema, podemos renunciar a la comodidad y a la estructura de un ciclo de vida predictivo y usar uno que cree el producto de forma incremental, es decir en múltiples versiones, cada vez con más características. Este es un lujo que tenemos en los proyectos de desarrollo de TI que no puede tener todo el mundo: múltiples versiones de software funcional, cada vez con más características. Piense en un proyecto de construcción, no hay incrementos significativos y el producto no se puede utilizar hasta el final.

Para ser justos, esta desventaja de un proyecto de construcción se compensa con el hecho de que si se tiene que empezar un proyecto para construir un hospital, el resultado final será un hospital, con independencia de la cantidad de cambios que haga, y no, por ejemplo, ¡un parque de atracciones! Sin embargo, en desarrollo de TI, se puede empezar un proyecto para crear algo parecido a un hospital y acabar con algo parecido a un parque de atracciones.

Por lo tanto, en los proyectos de desarrollo de TI, podemos tener entregas incrementales: aprovechemos esta oportunidad mediante un ciclo de vida como el siguiente:

No hay una predicción real en este ciclo de vida. En vez de predecir el producto y depender de esa predicción, tenemos pequeños periodos de tiempo durante los cuales creamos incrementos del producto. Mostraremos ese incremento (la última versión del producto) al cliente y a los usuarios finales, recibiremos su feedback (sus comentarios al respecto), y decidiremos qué hacer en el siguiente periodo de tiempo. Así que, en vez de basarnos en la predicción, seguimos con el proyecto y nos adaptamos al feedback. ¿Cómo queréis llamar a este ciclo de vida? “Adaptativo” es un buen nombre: ciclo de vida adaptativo.

Para crear cada incremento, necesitamos ejecutar todos los procesos de desarrollo durante ese periodo de tiempo. En el siguiente periodo, repetiremos los procesos: iteramos. Por eso, este método de desarrollo se llama a veces desarrollo iterativo. Los periodos de tiempo durante los cuales iteramos, se pueden llamar iteraciones. No es el único nombre que se utiliza para ello. Puede que ya conozca por lo menos un nombre más para las iteraciones. Volveremos pronto a este tema.

■ CICLOS DE VIDA PREDICTIVOS VS ADAPTATIVOS

Tanto el ciclo de vida adaptativo como el predictivo, tienen ventajas y desventajas. Que la selección del ciclo sea la correcta depende de muchos factores, pero el más importante es el tipo de producto.

Se pueden hacer dos preguntas esenciales antes de decidir el tipo de ciclo de vida que necesita para su proyecto:

1. ¿Necesito poder adaptarme? Porque si no, un ciclo de vida predictivo es…. ¡Pues más predecible! Es más fácil y está más estructurado. Se necesita un sistema adaptativo cuando existe el riesgo de empezar con la idea de crear un hospital y acabar con un parque de atracciones.

2. ¿Puedo adaptarme? Esta pregunta es todavía más importante. Para ser adaptativo, se debe tener la posibilidad de desarrollar de formar iterativa y de entregar de forma incremental. Pensemos de nuevo en un proyecto de construcción: ¿puede construir el edificio de forma iterativa? ¿Puede diseñar la base sin diseñar el resto del edificio que determinará la carga que debe soportar la base? ¡La respuesta es sencillamente NO! No es posible usar el desarrollo i...