Ediciones ENI Editorial | líder en informática
Los enfoques ágiles
Las bases de la agilidad
Durante mucho tiempo, el desarrollo de programas informáticos se ha regido por enfoques relativamente cerrados, por no decir rígido. No es que estos enfoques sean malos o afecten negativamente al rendimiento, pero el éxito de un desarrollo que sigue el proceso en cascada (o sus derivados) depende en primer lugar de la estabilidad de sus especificaciones.
Los tiempos han cambiado, la tecnología aporta una productividad en constante crecimiento y la rapidez con que se ponen en el mercado innumerables soluciones informáticas transforma constantemente el horizonte de las posibilidades, las estrategias y las necesidades. Lo ajustado del tiempo está lejos de ser una restricción, sino que se puede convertir en una oportunidad para aquel que ajuste su paso al descubrimiento progresivo de las necesidades, dando cien vueltas al enfoque del negocio hasta conseguir un resultado satisfactorio.
1. El control del riesgo
Los proyectos informáticos algunas veces tienen mala reputación: resultan largos, inacabados y poco documentados. Sin embargo, se suele admitir que los equipos se enfrentan a dificultades bastante habituales.
Normalmente se destaca el contexto cambiante, la expresión de las necesidades no es estable e incluso la plataforma técnica no está verificada. También nos lamentamos del efecto túnel; mientras que un puñado de desarrolladores se esfuerza por producir una versión demostrable, el cliente, que se ha mantenido a un lado, no duda del drama que se está produciendo entre bastidores. Cuando llega la demostración, la distancia entre lo deseado y la realidad se revela tan grande que se cuestiona la estrategia. Hay que volver a partir de cero. Los errores de estimación también se mencionan muy habitualmente como una de las fuentes de fallos. Pero, ¿cómo dar una cifra concreta cuando no se dispone de especificaciones detalladas? Dejamos a los desarrolladores conducir el proyecto hasta su terminación y es entonces cuando sabemos decir cuál es su coste.
La ausencia de consideraciones del riesgo constituye el punto común de estas afirmaciones. Los equipos no se ponen en duda, los métodos clásicos no prevén adaptarse a un contexto cambiante.
a. Los límites de los enfoques clásicos
Los enfoques clásicos se conciben como procesos...
Los enfoques ágiles destacables
1. La metodología Scrum
El método Scrum, elaborado a partir de 1986, se ha extendido y se ha impuesto desde hace algunos años como el modelo de referencia en la puesta en marcha de proyectos ágiles. Se trata de un enfoque holístico que procede por ciclos cortos (sprints o iteraciones), para organizar el desarrollo de software de manera incremental e iterativa. Las funcionalidades se realizan progresivamente y se entregan sobre la marcha.
La terminología Scrum proviene del lenguaje habitual. Se aplica por extensión a otros métodos ágiles.
a. La definición del backlog
El backlog representa el conjunto de entradas funcionales y técnicas que se deben realizar. Se trata de un almacén actualizado continuamente, cada sprint es la ocasión de analizar los elementos a implementar o añadir otros.
El elemento de trabajo básico es la historia de usuario y su historia técnica. En base a ellas, se diseñan una user story (US) y una technical story (TS) respectivamente. Una US describe la funcionalidad tal y como la entiende el usuario. No es necesario que en la US estén las instrucciones técnicas relativas a la implementación, aunque es posible. El elemento de trabajo tiene un título, una referencia única determinada por el sistema de gestión (Jira, VSTS...), una descripción funcional, así como los criterios de consecución o Definition of done.
De manera que se pueda cartografiar el futuro sistema de software y estructurar las US en un conjunto de elementos de trabajo en ocasiones grande, los sistemas de gestión introducen super-conjuntos de US tales como los epics y las features.
De esta manera, el backlog incluye los errores encontrados durante los ciclos de pruebas o por los usuarios.
El trabajo de redacción de las US constituye en sí mismo un proceso iterativo e incremental. Es habitual listar las US en el backlog y después completarlas durante la realización de los sprints.
Esencialmente Scrum no fija ninguna regla respecto a estructuración de los sprints (dicho de otra manera, el orden y la cantidad de US a tratar no se determinan por el método). Hay nuevos enfoques que intentan organizar la descomposición del proyecto para alcanzar más rápida y fácilmente la satisfacción...
Las herramientas adaptadas a la agilidad
El boom de los métodos ágiles se ha visto seguido por una evolución tecnológica en la que están inmersos los clientes y los equipos. El éxito de un proyecto reposa en la capacidad de los equipos para comunicar eficazmente, demostrar rápidamente y deshacerse de una determinada complejidad añadida por cambios continuos.
1. Estructuración y planificación
El control del perímetro del proyecto es, sin lugar a dudas, el primer reto de los equipos. Mantener el backlog, estructurar las iteraciones, seguir la generación de código (commit), son las funcionalidades propuestas por los sistemas integrados de gestión de proyectos.
a. Los sistemas integrados de gestión de proyectos
Muchos equipos trabajan con Jira (el producto principal de Atlassian) o con VSTS, dependiendo de si evolucionan en el ecosistema open source o Microsoft. Estos dos sistemas integrados de gestión de proyectos tienen numerosos puntos en común. Una vez que el backlog se ha creado, presentan los cuadros de mando para cada proyecto a desarrollar, según un proceso personalizado de tipo Scrum o Kanban.
Además de innumerables estados del proyecto, estos sistemas también se integran con la producción de código. Cada movimiento de código (extracción, modificación, archivado, commit, etc.) desencadenado por la herramienta...
Integración de los proyectos ágiles
Aunque se ha convertido en algo evidente para algunos equipos de desarrollo, la opción de un método ágil no siempre es unánime dentro de una empresa. Los principios tales como las ceremonias, el ajuste del perímetro o el no determinismo de la planificación han podido cuestionar su razón de ser así como la seriedad de los equipos que recurren a él.
Sin embargo, estos métodos se muestran muy estructurados, coherentes y eficaces para tener éxito en los proyectos más complejos. ¿Se tienen que aplicar sin reservas o bien la organización debe estar preparada con antelación para conducir proyectos ágiles?
1. El lugar de la agilidad en la organización I&D
Hay que reconocerlo, los talentos disponibles en el mercado, listos para ser reclutados en los puestos de I&D, conocen ahora mucho mejor los métodos ágiles que el modelo en cascada o el ciclo en V. Las formaciones y las herramientas de desarrollo han evolucionado con la tecnología y la vuelta atrás no parece estar a la orden del día.
Dicho esto, los métodos clásicos siguen siendo aplicables y, por supuesto, siguen estando adaptados para la realización de proyectos informáticos de envergadura, hasta el momento en que un análisis de riesgo aclare la opción más adecuada.
Sobre todo...
El story telling de Sports’net
Aunque el equipo que fundó Sports’net rápidamente formula la ambición de obtener beneficios económicos de su actividad, el proceso a seguir no era evidente. Nadie les hubiera dado crédito por su proyecto.
Al combinar sus competencias comerciales y técnicas, los miembros del equipo encontraron sistemas originales para promocionar su empresa. Además hicieron un uso extensivo de los enfoques ágiles.
1. Composición del equipo y organización del proyecto
Sensibilizado por los enfoques ágiles, el equipo se basó desde el principio en una fuerza de trabajo compacta, solidaria y buscando constantemente la efectividad. De todas maneras, el pragmatismo de los fundadores rápidamente les enfrentó a la realidad: salvo que buscaran inversores (empresas de capital de riesgo), no tenían posibilidad de soportar el coste financiero de las contrataciones que, cada vez más, los hubieran retrasado en su proyecto de negocio.
a. Al inicio, sin scope, sin (tampoco) medios
Un buen proyecto siempre empieza analizando el contexto y el nivel de riesgo general. Sin equipo completo ni perímetro concreto definido, los únicos métodos se dirigían por cambios que permitían realizar el proyecto. Los fundadores empezaron jugando al mismo tiempo el rol de cliente y el de product owner, consignando en un tablero la lista de las necesidades de negocio: disponer de una agencia de publicidad, compartir con la comunidad de usuarios los vídeos de las hazañas deportivas, etc. A continuación, estas grandes temáticas (los epics) se detallaron en funcionalidades (las user stories).
Este backlog, formado de esta manera, ayudó al equipo a ver más claramente su proyecto, así como a presentarlo a las partes implicadas.
b. Ser líder del proyecto sin ser responsable
Algunas veces los equipos ágiles sortean el rol del jefe de proyecto; este rol entrará en contradicción con los principios según los que la jerarquía introduce un riesgo inútil de deformación de las exigencias del cliente, respecto al beneficio de una planificación demasiado rigurosa.
Sin querer comprobar la pertinencia de esta afirmación, el equipo Sportse net ha evitado la trampa de posicionarse como líder del proyecto y no como...
