Los Fundamentos de Agile Scrum. Frank Turley
3: Colaboración con el cliente sobre negociación contractual
Cualquier proyecto tendría más éxito si tuviera un nivel de colaboración más alto del cliente. En los sistemas Adaptativos, es más que importante: es necesario. El cliente tiene que colaborar con nosotros todo el tiempo ya que estamos constantemente especificando nuevos requisitos y requiriéndole que compruebe los incrementos y que nos dé feedback. Si no lo hace, no podremos adaptar la solución.
Y a todos nos encanta la negociación contractual
Valor 4: Respuesta ante el cambio sobre seguir un plan
Esta declaración, como la segunda declaración, es específica a los sistemas Adaptativos. En vez de tener un plan por adelantado, Predictivo, que nos muestra el camino, dependemos de la adaptación. A esto último, se le suele llamar “cambio” en Agile, probablemente porque hace feliz a los clientes saber que pueden cambiarlo todo, aunque de hecho, no es un cambio salvo que no cuadre con el plan de base inicial que no tenemos en los sistemas Adaptativos. Técnicamente, lo que tenemos es un flujo continuo de ideas nuevas. Sin embargo, continuemos llamándolos cambios, por el bien de todos los clientes.
■ Muy probablemente haya preguntas sobre el Manifiesto Agile en el examen. No es mala idea revisarlo varias veces y poder incluso memorizar las cuatro declaraciones.
■ LOS PRINCIPIOS AGILE
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