Con este blog cerramos esta serie de posts en los que explicamos los principios ágiles de una forma detallada y tomando ejemplos.
9. La atención continua a la excelencia técnica y al buen diseño incrementan la agilidad.
El equipo debe tener el conocimiento y las habilidades necesarias para que los cambios en el producto puedan darse de forma rápida.
El diseño es una actividad continua a lo largo del proyecto, es decir, en cada iteración tendrá también su parte de diseño.
Valor fundamental
Prestar atención a la excelencia en las técnicas de diseño hace que el código mantenga una integridad funcional que permite mejorar la productividad en tareas de mantenimiento, pruebas y reusabilidad.
Ejemplo:
Si no se presta atención a la excelencia técnica y al uso de buenas pautas de diseño, la productividad a largo plazo se verá perjudicada especialmente en fases de mantenimiento. Se creará así una deuda técnica que es el coste y los intereses a pagar por hacer mal las cosas. El sobre esfuerzo a pagar para mantener un producto software mal hecho.
Martin Fowler (eXtreme Programming) explica en su teoría Design Stamina Hypothesis las consecuencias de utilizar un buen diseño frente a no usarlo.
En resumidas cuentas, lo que viene a decir es que sin utilizar ningún diseño inicialmente (línea azul) podremos obtener funcionalidad más rápido (agilidad mal entendida), pero llegados a un punto en el tiempo (design payoff line) esto dejará de ser así porque no permite que la productividad sea lineal en el tiempo.
Por otro lado, el uso de un buen diseño, no nos permite ser tan ágiles al inicio, pero podremos mantener ese ritmo de forma constante en el tiempo y a la larga nos permitirá ser más agiles.
10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
Contexto:
Como ya hemos dicho en posts anteriores, se pone más esfuerzo en la elaboración del producto que en la elaboración de la documentación, esto se debe a que los requisitos se actualizarán constantemente y por consiguiente la documentación también. En pocas palabras la documentación es susceptible de quedar desactualizada. Por lo tanto, debemos cargar más tiempo en la elaboración (codificación) del programa que en su documentación.
A la hora de capturar los requisitos hemos de ser eficientes en el tiempo, para ello se utilizan las historias de usuario que nos permiten capturar los requisitos maximizando el trabajo no hecho, esto nos ayuda a dividir grandes conjuntos de funcionalidades en partes más pequeñas. Se entregan antes las historias que proporcionan valor al cliente. El conjunto del trabajo no hecho se puede organizar en lo que se denomina product backlog (permitiendo eliminar del mismo las historias de usuario que aportan poco valor al cliente y que pueden distraer al equipo, si dichas historias de usuario son importantes pueden volver a introducirse en el product backlog).
En las metodologías ágiles, los elementos del product backlog se priorizan constantemente. Se busca obtener un mínimo producto viable MVP (siglas en inglés) que reúna la funcionalidad software suficiente para ser entregada al cliente. Sin desperdiciar el tiempo en hacer todo a la perfección.
El cliente nos indicará:
- Las nuevas características que desea: Estas características serán desarrolladas en siguientes iteraciones por medio de la incorporación de nuevas funcionalidades (incrementos).
- Las características que desea mejorar: Estas características se mejorarán de forma iterativa a lo largo del proceso.
Valores:
Se debe centrar el esfuerzo en implementar únicamente la funcionalidad que el cliente ha solicitado, sin excederse en refinamientos y optimizaciones innecesarias. Es decir, si el software funciona, se debe dejar así (sin dejar de lado la calidad). En el caso de que el equipo considere que se puede mejorar la funcionalidad de un aspecto del programa, se debe estudiar el costo del beneficio.
Lo que se busca es:
- Eliminar desperdicios de tiempo
- Entregar lo más rápido posible
- Construir con calidad
Ejemplos:
En las metodologías pesadas es muy probable que se desarrollen por error un montón de características para un producto que nadie quiere usar, de manera que se pierde mucho tiempo y esfuerzo.
En las metodologías ágiles se maximiza el trabajo no hecho a través de pequeñas iteraciones (periodos de tiempo muy cortos). Nos permite detectar características/historias de usuario no valiosas.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados
Contexto:
Durante mucho tiempo, la experiencia de la ingeniería tradicional se basó en que se trabajara con especialistas. Especialistas que centraran su atención en su especialidad y crearan la mejor solución dentro de su campo de especialización. Es decir: El diseñador de la interacción diseñaba la interfaz de usuario, el arquitecto modelaba el sistema y los desarrolladores creaban el código.
Al final había especialistas que creaban su mejor solución dentro de sus capacidades. Sin embargo, cuando todos estos componentes se juntaban, se observó que no algo no funcionaba correctamente y que se creaban retrasos cada vez que trataban de adaptar cada una de las necesidades.
Esto es algo muy común en procesos en cascada que siguen un funcionamiento en cadena.
Los proyectos ágiles no se aferran a la idea de que tiene que haber especialistas siguiendo un procedimiento en cadena, los miembros han de tener las habilidades para desarrollar el producto, pero sin tener que ser necesariamente especialistas. El punto es que han de estar motivados para fomentar un ambiente en lo que lo fundamental es la comunicación y la búsqueda de multifuncionalidad, (los grupos no han de ser muy grandes), donde puedan evaluar frecuentemente el producto.
“El equipo auto-organizado es un equipo dirigido y organizado por sus propios miembros, para alcanzar los objetivos especificados por la gerencia, dentro, obviamente, de las limitaciones de su entorno.”- Brad Appleton.
- El gerente indica lo que se debe hacer, pero no dicta los detalles de cuál es la solución ni cómo debe realizarse.
- El equipo es responsable no sólo de dirigir y organizarse para alcanzar sus objetivos, sino también de controlarse y adaptarse para corregir y mejorar sus actividades.
- No existe un único líder, el líder no es una figura estática, sino que cumple un papel dinámico. (La persona que dirige el equipo en un momento dado puede cambiar.)
Valor fundamental:
Los equipos auto-organizados tienen las siguientes características:
- Motivación: El equipo genera un ambiente donde se fomenta la motivación
- Habilidades: Se ajusta dinámicamente según sea necesario.
- Poder de decisión: No existe una única figura capaz de tomar decisiones
- Responsabilidad: El equipo comparte la responsabilidad.
El resultado es que los miembros se comunican, se ayudan entre sí, comparten ideas, buscan mejoras y entregan productos de calidad.
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.
Contexto:
La Agilidad se basa en ser flexible y en realizar solo aquellas actividades que sean necesarias para tener el éxito en el producto.
Es importante revisar siempre las actividades que se han realizado y las que se harán en la próxima iteración. Y esencial para siempre cuestionar la lógica que hay detrás de estas actividades. Esto ayudará al equipo a ser más productivo.
Valor fundamental:
Este principio consiste en revisar todas las actividades del proceso y aplicar los cambios que sean necesarios para hacer que el proceso sea más productivo (más ágil). La clave es aprender lecciones e implementar cambios en etapas posteriores.
Ejemplo:
En las metodologías ágiles (en el marco de Scrum), se utilizan las retrospectivas para revisar el proceso en un ambiente colaborativo donde fluyan las conversaciones y las revisiones sean breves con acciones claras (no se debe intentar arreglar todo el proceso en la primera iteración).
Por otro lado, en las metodologías en cascada es frecuente que las revisiones posteriores tarden mucho tiempo en organizarse, además arrastran consigo la lentitud conlleva documentar.
Si desea conocer más sobre las retrospectivas puede ver más en las siguientes entradas de este mismo blog:
Retrospectivas ágiles Estructura para llevar a cabo una reunión ordenada y obtener información agrupada
Dinámicas para restrospectivas: Escenario Necesario para comunicar al equipo el tiempo del que se dispone, recordar por qué se lleva a cabo esta reunión, sus beneficios y definiendo la dinámica que se llevará a cabo y su objetivo
Dinámicas para retrospectivas: Recopilar datos Necesaria para recordar todo lo sucedido en el Sprint y ordenar estos sucesos el equipo.
Dinámicas para retrospectivas: Generar ideas Para encontrar los problemas, sus causas e implementar los cambios necesarios.
Dinámicas para retrospectivas: Qué hacer En el que se habla sobre la toma de decisiones de las mejoras que se van a introducir y a llevar a cabo en el siguiente Sprint o iteración.
Dinámicas para retrospectivas: Finalizar Se muestran las posibles actividades para concluir la retrospectiva.
Contnúa con la explicación:
Add new comment