Ediciones ENI Editorial | líder en informática
Introducir la agilidad en los proyectos
Los fundamentos de la agilidad
Durante mucho tiempo, el desarrollo de programas informáticos se rigió por enfoques relativamente cerrados, por no decir rígidos. No es que estos enfoques sean malos o que presenten bajo 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 está impulsando una productividad cada vez mayor y acelerando el tiempo de comercialización de innumerables soluciones informáticas, está interrumpiendo constantemente el horizonte de posibilidades, estrategias y necesidades. Esta restricción del tiempo está lejos de ser una limitación, porque se puede convertir en una oportunidad para aquellos que ajustan su enfoque al descubrimiento gradual de la necesidad, volviendo a poner el acento en el negocio constantemente hasta obtener un resultado satisfactorio.
1. Control de riesgos
A veces, los proyectos informáticos tienen mala reputación: largos, inacabados y mal documentados. Pero se reconoce que los equipos enfrentan dificultades bastante comunes.
El contexto cambia constantemente, la expresión de necesidades no es estable o la plataforma técnica no está verificada. También se rechaza el efecto túnel; mientras que un puñado de desarrolladores se esfuerzan por producir una versión demostrable, el cliente, que se ha mantenido alejado del proceso, no sospecha el drama que se está produciendo detrás de la escena. Cuando se produce la demostración, la brecha entre lo deseado y la realidad es tan grande que la estrategia se pone en duda. Hay que empezar de cero. Los errores de estimación también se mencionan a menudo como una de las fuentes de problemas. Pero, ¿cómo dar una estimación precisa cuando no se tienen especificaciones detalladas? Dejamos que los desarrolladores completen el proyecto y es entonces cuando conocemos cuánto ha costado en realidad.
La falta de consideración del riesgo es el punto que tienen en común estas afirmaciones. No se cuestiona a los equipos, los métodos tradicionales no prevén adaptarse a un contexto evolutivo.
a. Los límites de los enfoques clásicos
Los enfoques clásicos se conciben como procesos...
Principales enfoques ágiles
1. La metodología Scrum
El método Scrum, desarrollado a partir de 1986, se ha extendido y consolidado en los últimos años como la referencia en la implementación de proyectos ágiles. Se trata de un enfoque holístico que procede en ciclos cortos (sprints o iteraciones), para organizar el desarrollo de software de forma incremental e iterativa. Las funcionalidades se realizan gradualmente y se entregan poco a poco.
La terminología de Scrum casi ha pasado al lenguaje cotidiano para referirnos por extensión a cualquier método ágil.
a. La definición del backlog
El backlog o pila representa el conjunto de todas las entradas funcionales y técnicas que se deben realizar. Se trata de un almacén que se actualiza continuamente, y en el que cada sprint es una oportunidad para prototipar los elementos que se van a implementar o añadir otros.
El elemento básico de trabajo es la historia de usuario y su complemento es la historia técnica, respectivamente denominada user story (US) y technical story (TS). Una US describe la funcionalidad tal como la entiende el usuario. En una US, no es necesario incluir instrucciones técnicas necesarias para la implementación, aunque es posible.
El elemento de trabajo incluye un título, una referencia única determinada por el sistema de gestión (Jira, VSTS, etc.), una descripción funcional, así como criterios de finalización o definition of done.
Con el fin de mapear el sistema de software en construcción y de estructurar las US en un conjunto de elementos de trabajo que puede llegar a ser muy amplio, los sistemas de gestión introducen superconjuntos de US, como las epics y las features.
El backlog también incluye errores reportados durante los ciclos de prueba o por los usuarios.
El trabajo de redacción de las US toma prestado un proceso iterativo e incremental. Es habitual enumerar la lista de US en el backlog, para posteriormente completarlas a lo largo de los sprints.
Aunque, en esencia, Scrum no establece ninguna regla para estructurar sprints (en otras palabras, el orden y la cantidad de US que se deben procesar no está determinado por el método), los nuevos enfoques apuntan a organizar la división del proyecto para lograr la satisfacción del cliente de manera más...
Herramientas adaptadas al método ágil
El auge de los métodos ágiles también sigue la evolución tecnológica en la que están inmersos tanto los clientes como los equipos. El éxito de un proyecto depende de la capacidad de los equipos para comunicarse de manera efectiva, para demostrar rápidamente y para superar una cierta complejidad que provocan los cambios constantes.
1. Estructuración y planificación
Sin duda, controlar el alcance del proyecto es el primer desafío para los equipos. Cosas como mantener el backlog, estructurar las iteraciones, hacer un seguimiento de los compromisos de código (commit), etc. son las funcionalidades que ofrecen los sistemas integrados de gestión de proyectos.
a. Sistemas integrados de gestión de proyectos
Muchos equipos trabajan con Jira (el producto estrella de Atlassian) o con Azure DevOps en función de su ecosistema de referencia. Estos dos sistemas integrados de gestión de proyectos tienen muchas cosas en común. Una vez que se crea el backlog, se presentan dashboards para cada proyecto que se va a llevar a cabo siguiendo un proceso personalizable de tipo Scrum o Kanban.
Además de innumerables estados del proyecto, estos sistemas también están integrados en la producción de código. Cada movimiento de código (extracción, modificación, archivado, división...
Integración de proyectos ágiles
Elegir un método ágil se ha convertido en algo obvio para algunos equipos de desarrollo, aunque esta elección no siempre es unánime dentro de una empresa. Hay algunos aspectos como las ceremonias, el ajuste del perímetro o el no determinismo de la planificación, que pueden haber puesto en duda su validez y la seriedad de los equipos que los utilizan.
Sin embargo, estos métodos son muy estructurados, coherentes y efectivos para tener éxito en los proyectos más complejos. ¿Se deben aplicar sin reservas o la organización debe estar preparada antes de poner en marcha proyectos ágiles?
1. El lugar de la metodología ágil en la organización de I+D
Hay que reconocer que los talentos disponibles en el mercado laboral listos para ser contratados en puestos de I+D ahora están mucho más familiarizados con los métodos ágiles que con el modelo en cascada o el ciclo en V. Las formaciones y las herramientas de desarrollo han evolucionado con la tecnología, por lo que volver atrás no parece estar en la agenda.
Dicho esto, los métodos tradicionales siguen siendo aplicables y son totalmente adecuados para realizar proyectos informáticos a gran escala, siempre que exista un análisis de riesgos que analice y valide esta elección.
Observamos que, especialmente entre los desarrolladores...
El story telling de Sports’ net
Incluso si el equipo fundador de Sports’ net formuló rápidamente la ambición de monetizar su actividad, el procedimiento a seguir no era obvio. Nadie había dado crédito a su proyecto.
Al combinar sus habilidades comerciales y técnicas, los miembros del equipo pudieron encontrar formas originales de promover su negocio y confiaron en gran medida en el enfoque ágil.
1. Composición del equipo y organización del proyecto
Consciente de los enfoques ágiles, el equipo se centró inmediatamente en una fuerza de trabajo unida, solidaria y que buscara constantemente la eficiencia. En cualquier caso, el pragmatismo de los fundadores se topó rápidamente con la realidad: a menos que solicitaran inversores (empresas de capital de riesgo), no tenían la posibilidad de asumir el coste financiero de las contrataciones que, además, los hubieran retrasado en su proyecto empresarial.
a. Inicialmente, sin scope y sin medios (todavía)
Un buen proyecto siempre comienza con un análisis del contexto y del nivel general de riesgo. Sin un equipo completo o un alcance claramente definido, solo los métodos que se centran en el cambio podrían haber permitido realizar el proyecto. Los fundadores comenzaron desempeñando tanto el papel del cliente como el del propietario del producto, registrando en una hoja de cálculo la lista de necesidades business: tener una red publicitaria, compartir con la comunidad de usuarios los vídeos de hazañas deportivas, etc. Estos grandes temas (epics) se detallaron posteriormente en funcionalidades (user stories).
Este backlog, formado de esta manera, ayuda al equipo a ver de manera más clara su proyecto, y también a presentarlo a futuras partes interesadas.
b. Ser un líder del proyecto sin ser responsable de él
Algunas veces, los equipos ágiles ponen en duda el papel del director de proyecto. Este papel entra en contradicción con los principios según los cuales la jerarquía introduce un riesgo innecesario de distorsión de los requisitos del cliente, en favor de una planificación demasiado rigurosa.
Sin tratar de verificar la relevancia de esta afirmación, el equipo de Sports’ net evitó el escollo al posicionarse como líder del proyecto y no como responsable....