De acuerdo al popular Gurú de ágil, Jim Highsmith, ser ágil es poseer la habilidad de crear y responder al cambio para poder producir ganancias en un ambiente laboral turbulento.
¿Cuál es su utilidad?
Agilidad es "la capacidad de equilibrar la flexibilidad con la estabilidad" Ser ágil significa adaptarse al cambio; ser flexible; ser capaz de enfrentar los cambios.
¿Cuáles son sus Principios de agilidad?
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
Los mejores proyectos se desarrollan con individuos motivados. Por favor, ya está en el pasado eso de controlar la hora de llegada y la hora de salida, está fuera de base eso de controlar si van al baño o si gastan tiempo yendo a la tienda. Eso de controlar que vean videos en youtube durante la jornada laboral, por favor entiendan que si las personas están motivadas van a rendir más, van a trabajar y ser realmente productivos. Ya es hora de aprender a darles la confianza que necesitan para la ejecución del trabajo y apoyarlos cuando lo necesiten, por favor, ya no estamos en la década pasada, debemos aprender a movernos con el tiempo.
Les dejo la siguiente frase para que por favor la interioricen: "La confianza como política de reducción de costos".
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.
Si quieres obtener calidad desde el inicio debes permitir al equipo tres cosas fundamentales, y es por esto que siempre divido este principio en: (Atención Continua) + (Excelencia Técnica) + (Buen Diseño) = (Mejora de la Agilidad). No sé porque algunas personas piensan que el diseño de un software solo se hace en una fase inicial o en un sprint cero, por favor, quiero que entendamos que esto es algo continuo. Tan solo porque debes pensar cómo crear un buen software y no solo al inicio, sino cómo hacer que el mantenimiento sea simple y así todos puedan vivir felices y más tranquilos. La excelencia técnica no solo puede ser durante el desarrollo, debes pensar en todos los aspectos y esto es parte de la agilidad.
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.
La simplicidad es esencial. Me gusta la frase de “Menos es Más”, obviamente sabiéndola usar, no como algunos que la usan de una forma totalmente inaceptable, pero bueno, volviendo al tema, lo sencillo se mantiene más fácilmente, debemos enfocarnos en resolver el problema real. He visto aplicaciones en que para ciertas cosas terminan creando montones de tablas en la base de datos y montones de pantallas de gestión, que a la final nunca se usan. Aplicaciones que tienen 80 tablas y que transaccionales solo son 10. Personas que llegan a darle mantenimiento a aplicaciones y que tienen que pasar días de análisis tratando de entender lo que se hizo, cuando realmente si se hubiera simplificado y hecho con lo esencial serían mejores aplicaciones. Por favor no exijan lo que no saben y siempre busquen que las decisiones tengan soportes, pero sobre todo tengan presente la importancia de la simplicidad.
Esto no quiere decir que porque es simple, no funciona o no cumpla con lo esperado. Por el contrario, las soluciones simples por lo general generarán más valor que las complejas.
La simplicidad es esencial. Me gusta la frase de “Menos es Más”, obviamente sabiéndola usar, no como algunos que la usan de una forma totalmente inaceptable, pero bueno, volviendo al tema, lo sencillo se mantiene más fácilmente, debemos enfocarnos en resolver el problema real. He visto aplicaciones en que para ciertas cosas terminan creando montones de tablas en la base de datos y montones de pantallas de gestión, que a la final nunca se usan. Aplicaciones que tienen 80 tablas y que transaccionales solo son 10. Personas que llegan a darle mantenimiento a aplicaciones y que tienen que pasar días de análisis tratando de entender lo que se hizo, cuando realmente si se hubiera simplificado y hecho con lo esencial serían mejores aplicaciones. Por favor no exijan lo que no saben y siempre busquen que las decisiones tengan soportes, pero sobre todo tengan presente la importancia de la simplicidad.
Esto no quiere decir que porque es simple, no funciona o no cumpla con lo esperado. Por el contrario, las soluciones simples por lo general generarán más valor que las complejas.
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.
Por Dios, si tú estás contratando gente experta, gente que sabe hacer su trabajo, pues entonces déjalos que sean ellos los que decidan como hacer las cosas, porque ellos son los que mejor saben hacerlas.
Deja de decirle a los equipos de desarrollo (y a las personas en general) como hacer las cosas, recuerda que estás tratando con seres humanos, no con máquinas a las cuales solo les das instrucciones.
Si les otorgas la responsabilidad y la autonomía, van a tener mayor conciencia y por ende obtendrás un aumento en la motivación, y ya sabemos que cuando las personas están motivadas ejecutan grandes proyectos, generan mejores ideas y son estas ideas las que por lo general te llevarán hacer las mejores aplicaciones.
Por Dios, si tú estás contratando gente experta, gente que sabe hacer su trabajo, pues entonces déjalos que sean ellos los que decidan como hacer las cosas, porque ellos son los que mejor saben hacerlas.
Deja de decirle a los equipos de desarrollo (y a las personas en general) como hacer las cosas, recuerda que estás tratando con seres humanos, no con máquinas a las cuales solo les das instrucciones.
Si les otorgas la responsabilidad y la autonomía, van a tener mayor conciencia y por ende obtendrás un aumento en la motivación, y ya sabemos que cuando las personas están motivadas ejecutan grandes proyectos, generan mejores ideas y son estas ideas las que por lo general te llevarán hacer las mejores aplicaciones.
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.
No hay comentarios:
Publicar un comentario