.

Los 12 Principios Ágiles en los que se basa SCRUM

aprender de la experiencia con prince2

Además de los cuatro valores del Manifiesto Ágil, existen doce principios que completan el Manifiesto Ágil y que describen la idea de Agilidad con mayor detalle:

Principio 1: Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continuada de software con valor

El objetivo es lograr un cliente satisfecho, lo que contribuirá a que tengamos más clientes en el futuro.  ¿Pero cómo? Proporcionando a los clientes la solución que realmente quieren, aunque ya sabemos que esto no es posible sin ser adaptativos, y sin entregas tempranas y continuas de software funcionando. Esta flexibilidad necesaria, aunque es posible en los ciclos de vida predictivos, resulta demasiado cara.

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

Empleando un ciclo de vida adaptable estamos abiertos al cambio ya que no existe ningún diseño inicial al que debamos ceñirnos cada vez que queramos realizar un cambio. Además, cualquier petición de cambio nos hará felices, pues será un paso más que nos permitirá acercarnos a lo que el cliente realmente desea.

Principio 3: Entregamos software funcional frecuentemente, entre dos semanas y un mes, con preferencia por periodos de tiempo lo más corto posibles.

El cliente tendrá una mejor comprensión de lo que quiere cuando vea el software en funcionamiento. Nosotros, recibiremos información (feedback) que podremos utilizar para adaptarlo.

Hay distintos marcos Agiles que emplean diferentes iteraciones. Por ejemplo, en Scrum no están permitidas las iteraciones de más de un mes, mientras que otros marcos Ágiles aceptan iteraciones más largas. Siempre y cuando sean suficientes para crear un incremento significativo (software en funcionamiento) preferiremos las iteraciones más cortas.

Principio 4: Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto

En un entorno predictivo la participación de la empresa/cliente se limita generalmente a especificar los requisitos al inicio, y de nuevo al final a aprobar la solución final. Sin embargo, en un entorno adaptable necesitamos que la empresa/cliente trabaje a diario con los desarrolladores, ya que sus inputs son la fuente de la adaptabilidad.

Principio 5: 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.

Un entorno ágil se basa en un equipo multifuncional y auto-organizado que se auto-gestiona y encuentra su camino en lugar de recibir órdenes. Esta es una gran responsabilidad para los desarrolladores, y no todos son capaces de trabajar de esta manera.

Cuando tenemos los miembros de equipo adecuados, debemos confiar en ellos, motivarles y darles la posibilidad de permitir la agilidad

Principio 6: 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

En un entorno tradicional los miembros del equipo se centran en sus actividades de especialista, incluso podrían estar ubicados en lugares diferentes, por lo general en sus respectivos departamentos dentro de la organización.

A veces ni siquiera podemos llamarlos “equipo”; no son más que una serie de personas que trabajan en el mismo proyecto. Por el contrario en un entorno Ágil necesitamos un verdadero equipo,  en el que los miembros deben estar co-localizados para poder comunicarse continuamente.  Nada puede sustituir una conversación cara a cara.

Aunque ciertamente es una gran ventaja contar con equipos co-localizados, esto no significa que no podamos tener un proyecto Ágil con un equipo “distribuido”. En estos casos sin embargo, necesitaremos aprovechar al máximo la tecnología para reducir al mínimo la falta comunicación cara a cara, y asumir un nivel de productividad inferior al final del día.

Principio 7: El software funcionando es la principal medida progreso

¡Un producto acabado al 99 % es un producto que esta 0 % “completo” o “hecho”!.

Pero entonces,  ¿cómo conocer el progreso de nuestro trabajo sin entrar en detalles técnicos? Recuerda que estamos interesados en mantener al cliente involucrado en el proyecto, y para ello debemos tratar de evitar los detalles técnicos, y mantener un lenguaje sencillo, dado que en muchas ocasiones se tratará de un cliente “no técnico”.

La solución pasa por diferenciar los artículos del Backlog de Producto únicamente en dos categorías: “completo” y “no completo”. Esta simple distinción es suficiente ya que los elementos del Backlog son lo bastante pequeños para mostrar nuestro progreso simplemente diferenciando entre completo/no completo.

Principio 8: Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

Trabajar no es el objetivo; alcanzar el producto es el objetivo.

Podría parecernos que hacer horas extras puede acelerar las cosas, pero en realidad reduce los outputs disminuyendo la productividad y aumentando los defectos.  Es preferible mantener un ritmo sostenido a lo largo del tiempo.

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

No tener un diseño inicial no significa que no tengamos que estar preocupado por el diseño.

Los proyectos ágiles tienen diseño, lo que ocurre es que este se realiza en cada iteración para cada elemento del Backlog de Producto.

Debemos prestar atención a la excelencia técnica y el buen diseño para evitar problemas; sin olvidar que el objetivo es encontrar una solución lo “suficientemente buena” más que la solución perfecta.

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

Un proyecto Ágil se gestiona y entrega de manera simple.  

Por ejemplo, la gestión del alcance se realice simplemente detallando la información esencial en una tarjeta o nota adhesiva (ficha); no son necesarios instrumentos sofisticados para gestionar el producto. Además, hacerlo de manera sencilla favorece la colaboración del cliente.  

Principio 11: Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.

Por lo general la gente trabaja mejor cuando se siente respetada y están autorizados para decidir cómo funcionar.

Además, es mejor que todos los miembros del equipo sean responsables de todo el proyecto. Por ejemplo, sí los diseñadores no funcionan de manera aislada, entonces estarán constantemente en contacto con los programadores, y pueden utilizar la información que se genera para mejorar los diseños y hacerlos más prácticos.

Principio 12: A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

¡Creemos que siempre hay margen de mejora, sin importar lo bien que estemos haciendo las cosas!

Por ello necesitamos tiempo para investigar la iteración anterior y encontrar la manera de implementar mejoras, por muy pequeñas que sean.  El objetivo es mejorar  un poco cada iteración.

¿Quieres saber más sobre SCRUM?
QuieresCursoGratisImagen700X150_3

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

AUTOR:  miguel

Dirección proyectos TI y #ecommerce bajo Prince2 o Scrum . Usabilidad, Conversión, Seo, AdWords, Marketing online, Analítica. Consultor y desarrollador.

Utilizamos cookies de terceros para mejorar nuestros servicios. Si continúa navegando, considera que acepta su uso. Más información aquí.  CERRAR