La importancia del término «software funcionando»

Uno de los 12 principios ágiles dice claramente «El software funcionando es la medida principal de progreso».  Esto puede parecer muy claro cuando se están leyendo los principios de inicio a fin pero tiene aspectos que deben tenerse en cuenta.

¿Qué significa «software funcionando»? Seguramente haya tantas respuestas como ingenieros tecleando código. Una forma de llegar a un consenso de equipo sobre los criterios que lo forman es hacer entre todos la Definition of Done (DoD). Estos criterios pueden contener aspectos como mínimos de cobertura de test, de validación de código según reglas de Sonar u otro analizador, de tests manuales realizados por un QC, etc .. y no servir absolutamente para nada.

Hace poco en un proyecto subestimé la importancia de lo que significa «software funcionando». Me di cuenta de que debe contener todos los criterios que hagan del sofware que se está produciendo una herramienta real y completa. Con completa me refiero a que de nada  sirve probar historias de usuario ejecutadas sólamente con datos moqueados porque los servicios web (que posiblemente haga un tercero) no están listos, tampoco sirve que estas pruebas se ejecuten en un entorno que no tiene que ver con el entorno real en el que se va a vivir la aplicación… Si en el proyecto faltan integraciones, fases de deploy o cualquier otro paso posterior  estamos desarrollando en un sistema Waterfall por sprints, no estamos en un proyecto Agile.

Si no vamos realizando todas las fases imprescindibles (from concept to cash) de todas las historias de usuario completadas, estas no serán más que papel mojado y al terminar «nuestro trabajo» entraremos en un entorno de incertidumbre sin saber cuándo va a funcionar de verdad todo eso que hemos estado enseñando en los Sprint Reviews. El cliente seguramente ya no creerá en el proveedor cuando le muestre el progreso en historias completadas y perderá la confianza en eso que llamamos Agile.

Para evitar estos problemas, asegurate de tener el entorno real (o como el real) lo antes posible, asegurate de integrar todas las piezas conforme se va construyendo el software.  Si no lo consigues porque está fuera de tus dominios, al menos, ten claro que ha dejado de ser un proyecto Agile.

 

2 comentarios sobre “La importancia del término «software funcionando»”

  1. Entiendo tu punto, pero. ¿Realmente necesitas «todo» el entorno funcionando?

    De la misma manera en que tu construcción se debe montar en «lonchas» (y no en capas) y el diseño ha de ser emergente. De la misma forma en que tu arquitectura sólo debe de tener contempladas las decisiones estrictamente necesarias para poder comenzar (siento la simplificación en la expresión, pero supongo que nos entendemos en este punto). No deberías de necesitar toda la infraestructura disponible, no necesitas todas las integraciones, no necesitas todo el modelo de datos, no necesitas el conjunto de datos completo, no necesitas una granja de servidores. Necesitas sólo aquellas que aporten valor y que contribuyan al objetivo del sprint (supondré que estamos trabajando en Scrum). De otra forma, nos iremos de cabeza a modelos de gestión tipo waterfall o modelos en V (que están muy bien, pero que entiendo no son el objeto de esta entrada). El problema que describes es, en mi experiencia, fruto de que el equipo de Desarrollo quizá esté haciendo Scrum (o cualquier otro framework ágil de la elección del cliente) pero. ¿Y el resto de los equipos? Si tienes muchas dependencias, quizá debería de contemplarse un framework escalado como Nexus.

  2. Hola
    Primero gracias por el comentario.
    Si el entorno e infrastructuras es emergente, en el sprint 1 deberíamos disponer de una forma sencilla y real de hacer llegar el software al cliente. Igualmente funcionaría porque cumple todos los requisitos que se tienen en cada punto del proyecto. Sin embargo, si el software tiene unos requisitos de entorno e integraciones ya establecidos, es «trampa» terminar historias sin que funcionen según los mismos. No hace falta que sea el entorno del usuario pero sí uno como el mismo. Que funcione «en mi pc» no vale como historia de usuario completada.
    En otro proyecto estoy usando gestión de dependencias con Nexus según este artículo https://www.scrum.org/Portals/0/Documents/Community%20Work/Visualizing%20the%20Nexus%20Sprint%20Backlog.pdf.
    El que proyecto que comento, los otros equipos eran de otra empresa y no se pudo tener ese nivel de coordinación,aunque se intentará con más ahínco para la siguiente.
    Un saludo

Los comentarios están cerrados.