Metodologías Ágiles

Ciclo de Deming

Edward Deming era un estadista norteamericano que tras la segunda guerra mundial empezó
a divulgar por allí conceptos relacionados con la mejora de los procesos y el aumento de la
calidad. Debemos recordar que Japón se encontraba desolada y habiendo sido perdedor de una
gran guerra. Poco a poco los japoneses fueron adoptando los consejos de Deming
principalmente en la industria automovilística, encabezada por Toyota.

Deming se hizo popular por divulgar los conceptos de Walter Andrew Shewhart, otro estadista
que realizó diferentes estudios sobre la optimización de procesos. Uno de los términos que
popularizó Deming fue el posteriormente llamado Ciclo de Deming que básicamente consiste en
establecer el modelo de aprendizaje empírico utilizando en otros ámbitos como las ciencias. Este
proceso consta de cuatro fases:

Planificación
Hacer
Inspección de los resultados.
Adaptación en función de los resultados obtenidos
 Metodologías Ágiles

Planificación (Plan): En esta fase dedicamos el tiempo a pensar en todo lo relacionado

con el proyecto y con lo que haremos próximamente. Es un buen momento para
pensar en qué tareas tendremos que realizar (con más o menos detalle) así como
evaluar posibles riesgos y problemas futuros. Hay muchas leyendas que hablan de
que en las metodologías ágiles no hay que dedicar tiempo a la planificación. Esto es
totalmente falso ya que siempre deberemos pensar antes de actuar. Lo que sí que
nos comentan estos enfoques ágiles es que no le dediquemos un tiempo excesivo si
no el mínimo indispensable para poder empezar a funcionar.
Hacer (Do): En esta fase propiamente dicha es donde realizamos el trabajo. Los
enfoques ágiles promueven el empezar a realizar esta fase lo antes posible, ya que
solo cuando esto se produce empezaremos a ver los problemas reales que nos
podamos encontrar.
Comprobación (Check): La fase más importante desde el punto de vista de la mejora
continua. En esta fase es donde deberemos pararnos a reflexionar y comprobar cómo
ha ido todo el trabajo realizado durante la fase de Hacer. Si queremos mejorar
deberemos tener estos momentos de reflexión.
Actuar (Act): La reflexión sin acción no sirve de mucho. Una vez analizado y
comprobado todo lo realizado y recibido feedback deberemos Actuar con una serie
de cambios o mejoras. Hay veces que la actuación consiste en consolidar los cambios
realizados y asimilarlos como acuerdos de trabajo.

En estos conceptos se encuentra gran parte de la esencia de Agile.

 Metodologías Ágiles

Triángulo de hierro

Tiempo que vamos a tardar en realizar el proyecto. Alcance como el conjunto de requerimientos
a cubrir. Coste como el dinero que deberemos invertir. Está directamente relacionado con las
personas y recursos materiales que participen en el proyecto.

Por mucho que queramos, no podemos cerrar los tres vértices ya que siempre al menos uno
debe ser variable para que la calidad (en el centro) no se vea repercutida. Esto quiere decir que
nunca en un proyecto podremos fijar el tiempo de duración, el número de tareas o alcance a
realizar, así como cuantas personas lo van a formar. Es decir, no podríamos fijar que vamos a
realizar un proyecto en tres meses, para realizar 25 tareas con 5 personas sin que la calidad el
mismo se vea afectada. De esta manera podemos cerrar tiempo y alcance y dejar libre el número
de personas necesarias (coste), o bien decidir el alcance del proyecto y las personas que lo van
a formar y así dejar libre el tiempo que tardarán en realizarlo.

Nunca debemos perder de vista la calidad en el centro de todo. Por tanto, cualquier decisión que
tomemos debería ir orientada a no repercutir en esta calidad. Construir proyectos de baja
calidad a la larga nos traerá muchos problemas de mantenimiento e inestabilidad futuros.

En las metodologías ágiles lo normal es fijar el tiempo (entre 1 y 4 semanas) y el coste, es decir,
el número de personas que participarán en cada sprint y variaremos el alcance o número de
requisitos o funcionalidades que entregaremos en cada periodo de tiempo. De esta manera al
fijar el tiempo estaremos consiguiendo un ritmo continuo por parte del equipo y si conseguimos
que el equipo sea estable (sin demasiadas salidas y entradas de personas) conseguiremos
también mayor efectividad con el consiguiente éxito en el proyecto.
 Metodologías Ágiles

Cono de incertidumbre.

El cono de incertidumbre describe la medida de incertidumbre de un proyecto. Nos dice que al

inicio de un proyecto tenemos mayor probabilidad de confundirnos en nuestras estimaciones ya
que es la fase inicial cuando menos información y conocimiento tenemos sobre la resolución del
problema. Lógicamente esto no se puede aplicar a todos los ámbitos ya que si nos paramos a
pensar en la construcción de una casa o un avión esta incertidumbre no es la misma. En estas
ingenierías conocemos de antemano los planos y hasta los más mínimos detalles del plan ya que
es un resultado conocido (la casa o el avión) lo que se pretende construir.

Pero en los proyectos relacionados con la gestión del conocimiento, proyectos cuyo resultado es
algo inmaterial (que no se puede tocar) como por ejemplo el desarrollo de software, no se puede
aplicar los mismos esquemas ya que lo que estamos intentando construir ni siquiera sabemos
cómo es.

Es por ello que las metodologías ágiles promueven el inicio de la fase de “hacer” lo antes posible
para tratar de que aparezcan estos impedimentos tan pronto como sea posible. De esta manera
pasamos del ámbito de lo teórico, al tratar de “adivinar” que impedimentos tendremos, al
ámbito de lo práctico donde los impedimentos tarde o temprano terminan apareciendo.
 Metodologías Ágiles

Iterativo e incremental

Uno de los pilares en torno a las metodologías ágiles es que promueven el desarrollo de
proyectos de forma iterativa e incremental. Este enfoque es diferente al de otros enfoques o
metodologías como, por ejemplo, el enfoque en cascada donde se divide el proyecto en fases
para acabar construyendo el proyecto al final.

Los enfoques ágiles promueven sin embargo el desarrollo iterativo e incremental ya que están
pensados para proyectos con una alta incertidumbre y una gran variabilidad en los requisitos, es
decir, muchos cambios. Por ello, lo que nos interesa en este tipo de proyectos es ir obteniendo
feedback lo antes posible de nuestros clientes, con el objetivo de reducir la incertidumbre y saber
si lo que estamos construyendo es realmente lo que quieren.

Por ello, necesitamos un enfoque de proyecto que priorice esta entrega frecuente (en el caso
del software de funcionalidades) que nos permita saber si vamos en la buena dirección. Veamos
de qué manera nos puede ayudar.

El concepto de iterativo tiene que ver con dividir el proyecto en pequeñas fases (o iteraciones)
con el objetivo de entregar al final de cada iteración un pequeño entregable de nuestro producto
que añada (incremente) valor al anterior. Quizás el resultado final de cada iteración no sea el
producto tal y como lo quiere nuestro cliente, pero si será algo que le aporte valor y que nos
permita al equipo de desarrollo conocer si lo entregado se adapta o no a sus necesidades y
cumple con sus expectativas.

Por otro lado, el concepto de incremental tendría más que ver con dividir el cuadro de tal manera
que partamos de un lienzo con trazos muy sencillos y fuéramos poco a poco dotando de color y
complejidad a nuestro cuadro.

En el desarrollo de productos de software debemos tener presente que no tenemos la certeza

absoluta de lo que el cliente quiere al inicio del proyecto. Vamos a utilizar otra metáfora de
Henrik Kniberg para explicar el concepto de iterativo e incremental. En este caso supongamos
que tenemos un cliente cuyas aspiraciones es ir a los sitios de una manera más rápida que a pie.
Si enfocamos esta necesidad con la idea de construir un coche podemos enfocarlo de dos
maneras esta construcción.

Una primera aproximación, la que siguen los enfoques más tradicionales en el que damos por
supuesto que nuestro cliente lo que necesita es un coche. Dado esto por supuesto dividimos la
construcción de este en diferentes fases. Al finalizar cada fase le entregamos a nuestro cliente
un trocito de ese coche. Solo en la fase final nuestro cliente se sentirá contento y tendrá su coche
 Metodologías Ágiles

listo. Por el resto de fases anteriores no le hemos aportado nada de valor ya que no ha podido
hacer nada con solo dos ruedas, un chasis, etc.

Si, por el contrario, optamos por una aproximación iterativa e incremental trataremos de aportar
valor en cada una de las diferentes fases del proyecto. Sabiendo que la necesidad real de nuestro
cliente es viajar o transportarse a los sitios de una manera más rápida podemos optar en una
primera iteración por construirle un pequeño monopatín. De acuerdo, este monopatín no es un
coche, pero si pensamos en la necesidad que queríamos cubrir (viajar o transportarse más
rápido) creo que de esta manera ya estamos cubriendo con esa necesidad y nuestro cliente
puede empezar a estar un poco más satisfecho.

Lo malo de las metáforas es que son reducidas y pueden llevar a confusión. Está claro que, si
nuestro cliente tiene claro que quiere un coche, no estará muy contento si le entregamos un
monopatín al inicio, pero, estamos utilizando estos enfoques porque es nuestro cliente
precisamente el que no tiene claro lo que necesita.
 Metodologías Ágiles

Manifiesto Ágil: Valores

En nuestro contexto, los valores del manifiesto ágil son la base sobre la que tomar decisiones y
primar unas cosas por encima de las otras. En el manifiesto ágil así se indican estos valores:

Individuos e interacciones sobre procesos y herramientas

Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan

El manifiesto ágil fue firmado por expertos de desarrollo de software que llevaban varios años
en la industria. Fue firmado pues por personas con amplios
conocimientos y experiencia. Fue en base a esta experiencia anterior lo que les había permitido
darse cuenta de que podría haber maneras diferentes de desarrollar software ya que los
enfoques hasta la fecha estaban centrados en metodologías y procesos que primaban más otras
cosas.
 Metodologías Ágiles

Manifiesto Ágil: Principios

Para complementar a los valores tenemos los principios que podríamos decir que son más
concretos. En el propio manifiesto ágil se incluyen 12 principios que pasamos a enumerar:

Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y

continua de software con valor.

Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los
procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al
cliente.

Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con
preferencia al periodo de tiempo más corto posible.

Los responsables de negocio y los desarrolladores trabajamos juntos de forma

cotidiana durante todo el proyecto.

Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el

entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.

El método más eficiente y efectivo de comunicar información al equipo de desarrollo

y entre sus miembros es la conversación cara a cara.

El software funcionando es la medida principal de progreso.

Los procesos Ágiles promueven el desarrollo sostenible. Los promotores,

desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de
forma indefinida.

La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados.

A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a
continuación ajustar y perfeccionar su comportamiento en consecuencia.
 Metodologías Ágiles

Scrum

Scrum es un proceso iterativo e incremental utilizado para la construcción de productos. Esto

significa que el proceso se compone de diferentes interacciones a las que llamaremos Sprints.
Estas interacciones o sprints son fijos en el tiempo y se recomienda que tengan una duración de
1 a 4 semanas máximo. El objetivo de estos sprints es el de construir un incremento del producto
que potencialmente se pudiera utilizar por parte de los clientes. Por tanto, no nos serviría
entregar algo que no pudiéramos utilizar al final del proceso.

Generalmente a las personas para las que construimos el producto se les llama Interesados o
Stakeholders en inglés. Pueden ser todas las personas que tienen interés en lo que estamos
construyendo. Por ejemplo, si estuviéramos construyendo una aplicación para un hospital, los
interesados podrían ir desde el Director General del Hospital, pasado por Celadores, Enfermeras,
Médicos, Supervisores, Recepcionistas y todas aquellas personas que de algún modo les afecte
directa o indirectamente en su trabajo la construcción de la aplicación.

Una vez tenemos claro que personas son a las que les vamos a aportar valor es necesario
recopilar en un único sitio todas las ideas, funcionalidades y demás elementos que van a
componer nuestro producto. A este conjunto de elementos ordenados por valor de negocio
(arriba los que más valor aportan) se le llama Pila de Producto o Product Backlog en inglés. A los
elementos que componen esta Pila de Producto se les conoce como PBIs del inglés Product
Backlog Items o Elementos de la Pila de Producto.

Para gestionar toda esta comunicación y gestionar la pila de producto existe un rol específico
llamado Dueño de Producto o Product Owner en inglés, cuyo objetivo es maximizar la entrega
de valor en cada Sprint, es decir, que el equipo construya lo que le aporte más valor a los
Interesados.

Otro rol clave entonces es Equipo de Construcción, encargado de las labores puramente de
construcción del producto. Es el encargado en cada Sprint de entregar una parte del incremento.

Tanto la selección de los PBIs más importantes como el desgranado de estos en tareas técnicas
se realiza en la Reunión de Planificación del Sprint o Sprint Planning en inglés. A esta reunión
acuden Dueño de Producto, Equipo de Construcción y Scrum Master y el resultado de la misma
debería ser una Pila del Sprint junto con los objetivos claros del mismo. Debe quedar claro que
en la Reunión de planificación el Dueño del producto junto con el Equipo de construcción
deciden de forma colaborativa que elementos entrarán en el siguiente Sprint. Ya que puede
haber elementos que aporten mucho valor a los clientes pero que técnicamente sean muy
difíciles de realizar en este momento. Por tanto, debe ser algo consensuado entre ambos roles.
 Metodologías Ágiles

Una vez comienza el Sprint de duración fija entre una y cuatro semanas, el Equipo de
construcción comienza a trabajar sobre la Pila de Producto. Para realizar una gestión de riesgos
adecuada y fomentar la comunicación y sincronización entre los miembros del equipo Scrum
introduce la Reunión diaria o Daily Meeting donde el principal objetivo es detectar problemas e
impedimentos que afecten al desarrollo del Sprint. Esta reunión es una reunión corta de no más
de 15 minutos.

Pues esto se repite durante todo el Sprint y el equipo va terminando todos los elementos de la
Pila del Sprint. Por ello, al finalizar este, es necesario revisar todo lo construido para ver si se
ajusta a lo que necesitan los Interesados y así poder recibir feedback de estos Interesados. Eso
sucede en la Reunión de Revisión o Demo donde se inspecciona todo lo realizado por el Equipo
de construcción. A esta reunión acuden el Dueño de Producto como representante de los
Interesados, además del Equipo de Construcción y el Scrum Master. También puede acudir
cualquier otra persona que quiera ver lo entregado. Sería muy recomendable que hubiera algún
Interesado, aunque esto no siempre es posible.

Después de haberse producido esta reunión para inspeccionar el Incremento entregado en el

Sprint el equipo debe reunirse para inspeccionar el proceso y la manera en la que han trabajado
con el único objetivo de mejorar y detectar posibles problemas y dar soluciones a los mismos.
Esta reunión, sucede después de la Reunión de revisión y se llama Retrospectiva. Es en la
retrospectiva donde pondremos el foco en las personas y el proceso dejando a un lado el
producto en sí que ya lo inspeccionamos en la reunión anterior.
A esta reunión deben acudir todos los miembros del Equipo Scrum, es decir, Dueño de Producto,
Scrum Master y Equipo de Construcción. Es facilitada por el Scrum Master, aunque en algunas
ocasiones puede ser interesante que sea facilitada por otra persona para que el Scrum Master
pueda también participar como un miembro más el equipo.

Existe una última reunión cuyo objetivo es trabajar sobre los elementos futuros que entrarán en
el Sprint, es decir, trabajar sobre los siguientes elementos de la Pila de Producto. A esta reunión
donde el Equipo Scrum trabaja para refinar esos elementos, es decir, hacerlos más pequeños,
claros y entendibles se le llama Reunión de Refinamiento.
 Metodologías Ágiles

Como resumen podemos decir que Scrum está formado por:

Artefactos, como los elementos con los que trabajamos. Estos son la Pila del producto,
Pila del Sprint, el Sprint, el Incremento del producto, Definición de Listo y Definición de
Terminado.

Reuniones, como los eventos donde se reúnen los diferentes roles. Estas reuniones son:
Reunión de planificación, Reunión de revisión, Retrospectiva, Reunión diaria y Reunión
de refinamiento.

Roles, existen básicamente para dividir las diferentes responsabilidades que nos
encontramos a la hora de construir un producto. El Dueño de producto, encargado de
maximizar la cantidad de trabajo que se realizará, es, por tanto, el encargado de
mantener la visión del producto y la comunicación con los interesados. El Equipo de
Construcción, como encargado de construir el producto, el Scrum Master responsable de
cumplir el proceso y preocupado de las personas. Los Interesados como esas personas
para las que construimos el producto. Debe añadirse que, al equipo formado por Dueño
de Producto, Equipo de Construcción y Scrum Master se le conoce como Equipo Scrum.
 Metodologías Ágiles

Scrum – Roles: Dueño del producto

El dueño de producto es el responsable de mantener la visión del producto que se va a construir

maximizando la cantidad de valor entregado al finalizar cada Sprint. Para mantener esa visión el
dueño de producto tiene diferentes interlocutores a los que llamamos Stakeholders o
interesados en el proyecto.

Una de las funciones del dueño del producto es la de mantener la pila de producto o conjunto
de funcionalidades actualizada y priorizada para que el equipo de construcción sepa en todo
momento cuales son los elementos que aportan más valor a los usuarios.

Además, el dueño de producto asistirá a las reuniones de planificación y revisiones del sprint
con el equipo de construcción para transmitir de una forma efectiva esta visión de producto a
todos los implicados.

Scrum – Roles: Scrum Master

El Scrum Master es un rol con un conjunto de responsabilidades muy variadas. Realiza labores
de facilitador de reuniones, así como acompañante del equipo para ayudarle a resolver las
problemáticas que se vaya encontrando a lo largo del proyecto. El scrum master es el vigía del
proceso que vela porque este se lleve a cabo sin olvidar que está pendiente de las personas que
conforman el equipo.

También debe tener una visión de la organización y buenas dotes de comunicación y gestión de
conflictos que ayuden al equipo a mejorar.
 Metodologías Ágiles

Scrum – Roles: Equipo de construcción

Equipo de construcción son los encargados de construir el producto. Si estamos hablando de
equipos de construcción de software estará formado por desarrolladores, diseñadores,
arquitectos, testers y cualquier persona que esté implicada de una u otra manera en la
construcción del producto.

Las metodologías ágiles nos hablan de que estos equipos deben ser pequeños (de no más de 9
personas), multidisciplinares, es decir, que entre todos los miembros puedan dar servicio al
proyecto y auto-organizados, es decir, que ellos mismos decidan la mejor manera de desarrollar
su trabajo. Algunas tareas típicas de autoorganización de estos equipos son la de asignación de
tareas y estimación, así como el desglose técnico de los requisitos en tareas de bajo nivel.
Diremos que estos equipos son más o menos auto-organizados en función de su nivel para lidiar
con todos estos temas.

Scrum – Roles: Clientes / Usuarios

Otro elemento fundamental son los clientes y usuarios. Son todas aquellas personas que de una
manera u otra utilizan el resultado de nuestro producto. Si hablamos de aplicaciones de
software serán los usuarios y clientes que se conectarán a la aplicación para utilizarla. Debemos
distinguir a usuario (cualquier persona que utilice la aplicación) de cliente (aquella persona que
realmente paga por ella). Realmente nuestros productos deben estar enfocados a los clientes
ya que estos son los que están dispuestos a pagar por usarla.