Читать книгу Los Fundamentos de Agile Scrum - Frank Turley - Страница 14

El Manifiesto Agile es felizmente breve. Sin embargo, los autores consideraron que sería buena idea elaborar un poco la recién nombrada idea de Agile, así que crearon estos doce principios:

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

Al fin y al cabo, esto es un negocio y necesitamos que los clientes estén felices. Eso está claro. Pues, hoy en día, se dice que la satisfacción del usuario final es la medida definitiva porque eso le generará beneficios al cliente y, tarde o temprano, satisfará al cliente de una forma sostenible. ¿Es demasiado idealista?

Entonces, ¿cómo les satisfacemos? Por el software que creamos, que tiene el potencial de generarle valor (por ejemplo, dinero). Cuando hacemos entregas de forma anticipada y continua, generaremos valor antes, y además nos da la oportunidad de adaptar la solución y crear algo que el mercado quiere realmente y por lo que pagará, en vez de crear algo que nosotros esperamos que quiera.

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.

Hagamos un poco más de marketing acerca de la palabra “cambio” que tanto les encanta a los clientes

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

¿Recuerda las iteraciones de las que hablamos – esos periodos de tiempo en los que iteramos (repetimos los procesos de desarrollo) para crear un incremento del producto? Este principio dice que no deben durar más que un par de meses. En Scrum, el plazo máximo es de un mes. Hablaremos mucho sobre ello de aquí al final del libro.

¿Ve también la sugerencia de un par de semanas? Muchos se reían en aquella época – la idea de tener un incremento nuevo en tan solo un par de semanas. Sin embargo, ahora tenemos proyectos con iteraciones incluso más cortas.

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

Esto va en contra de la idea de separar a los responsables de negocios (clientes u otros) de los técnicos, lo cual sigue siendo un problema en proyectos hoy en día. A veces, se consideran el enemigo el uno al otro, lo cual no es beneficioso para un proyecto.

Además, no podemos realizar adaptaciones si los responsables del negocio no están disponibles en todo momento. Piense en el análisis continuo de las nuevas características y en las pruebas de las unidades completadas. Además, ¡siempre será más divertido, cuántas más personas celebren el haber completado otra iteración!

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.

Pronto, hablaremos de más aspectos de los sistemas Adaptativos. Uno de ellos es que necesitamos tener a personas empoderadas a nivel de proyecto; no solo porque es bueno, sino porque el ciclo de vida Adaptativo lo requiere. Quizá pueda preguntarse el porqué de esta afirmación, hasta que lo volvamos a comentar en las siguientes secciones.

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 vez de los correos electrónicos! Tome nota que, históricamente, este principio siempre ha sido el más popular a la hora de hacer el examen.

Volveré a este tema en un capítulo aparte cuando hablemos de Comunicación osmótica.

Principio 7: El software funcionando es la medida principal de progreso.

La mayoría de los proyectos miden conceptos equivocados. Es un problema de base porque lo que se mide es lo que se obtiene. Si mide cuántas líneas de codificación se producen, sólo obtendrá más líneas de codificación. Si mide la ocupación de los desarrolladores, obtendrá desarrolladores más ocupados. Si mide velocidad (una medida habitual en Agile sobre la velocidad de desarrollo que comentaremos más adelante), obtendrá mayor velocidad (pero no es el objetivo).

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.

Nada de horas extras adicionales antes de las entregas. Se trata de maximizar el valor a largo plazo. No se trata de ganancias a corto plazo que puedan llevar a disminuir la productividad y la calidad.

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

Existe el riesgo de tener un diseño de mala calidad en los sistemas Adaptativos porque se diseña sobre la marcha en vez de por adelantado. Existen ciertas prácticas para poder superar este problema.

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

Es una forma muy complicada de decir algo muy sencillo: tener más características no siempre es bueno.

Es bueno simplificar la solución y tener solo las funcionalidades que son realmente útiles porque ahorra tiempo y dinero (que se pueden utilizar para otros proyectos) y reduce el coste de mantenimiento.

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

La auto-organización significa tener a personas empoderadas en el proyecto que se involucran en las decisiones y normalmente, es buena idea hacerlo.

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.

Debe aceptar que su forma de trabajar no es perfecta, y siempre puede mejorarla en pequeños pasos. Pero no se fije en la forma en la que se han mejorado el Manifiesto y los Principios: Haga lo que dicen en el Manifiesto, no lo que hacen

■ Ya hemos acabado de revisar los Principios de Agile. No olvide que son temas muy comunes en el examen.