Tras nuestro post inicial sobre nuestro enfoque de mejora en la gestión del ciclo de vida del software en torno a DevOps, éste es el primero de una serie de ocho posts en los que desgranamos en detalle cuál es nuestro enfoque de mejora en cada una de las fases de DevOps. Así que hoy es turno para la fase PLAN.
En la fase PLAN, los objetivos principales son:
- Validar con el cliente que tenemos recogidos todos los requisitos y ambas partes los comprendemos de la misma manera. Éste es el punto principal de fricción en la mayoría de proyectos software.
- Definir todas las tareas de proyecto y distribuirlas a lo largo del tiempo, de forma que hagamos entrega de una versión que pueda ser probada por el cliente. Muchos clientes necesitan tocar y probar software para darse cuenta de lo que realmente quieren.
- Recoger el resultado de las pruebas del software para cada una de las tareas del proyecto, validando que éstas hayan sido correctamente ejecutadas. A su vez, la validación de correcta finalización del conjunto de tareas cuyo origen es un mismo requisito, validará que hemos satisfecho dicho requisito.
La herramienta de seguimiento para todo lo anterior es la tabla de seguimiento de requisitos, que toda herramienta de gestión de proyecto debe ofrecer. En ella podremos definir en cada fila un requisito, con su descripción textual, la lista de tareas de proyecto que (una vez ejecutadas) van a satisfacer ese requisito; e información adicional, como los componentes o las versiones del software asociados a los distintos requisitos.
Según vaya creciendo el número de requisitos, tareas de proyecto, componentes, versiones y cualquier otro criterio de estructuración del trabajo a realizar, será de especial importancia la capacidad de nuestra herramienta para ordenar y filtrar toda esta información.
En la figura anterior, podemos ver un wireframe mostrando cómo una tabla de este tipo nos ayuda a asociar requisitos con tareas de proyecto. Normalmente, usaremos wireframes en nuestras publicaciones para ayudar a abstraernos del aspecto y funcionalidad concretos de una herramienta específica.
La figura anterior muestra cómo el grado de finalización de las tareas contribuye al grado de finalización del requisito al que cada una está asociado y cómo todo esto permite definir el grado de progreso del proyecto completo. Por ejemplo, el requisito REQ 0001 se satisface mediante la finalización de las tareas de proyecto PROY-001 a PROY-005; la estimación de su grado de finalización (90%, 35%, 8%, 0% and 0%, respectivamente) permite estimar que REQ 0001 está al 35% de progreso de estar completamente satisfecho, según se ha especificado en la herramienta de gestión de proyecto.
A su vez, la estimación de avance de cada uno de los requisitos (35%, 9%, 0%, …, 0%) permite estimar el avance total del proyecto (3%).
Hay muchos aspectos de detalle que comentar en torno a la planificación, lo cual haremos en futuras publicaciones. De momento, anticipamos que el desarrollo ágil de software será una de nuestras principales guías, que el hecho exclusivo de usar un tablero Scrum o Kanban en una herramienta o en nuestra pared no es ser ágil y que uno de los principales problemas en los proyectos software es la falacia del precio y el alcance cerrados.
El hecho de que la “definición” de las tareas de proyecto de la figura anterior recuerde a una historia de usuario no es casualidad, y hablaremos de pila de producto en lugar de “tareas de proyecto”, y de ítem o elemento de la pila de trabajo en lugar de “tarea de proyecto”.
También veremos cómo, si nos apoyamos para definir las tareas del proyecto (o elementos de la pila de trabajo) en la definición de pruebas que determinen cuándo éstas se darán por bien hechas, avanzaremos hacia el desarrollo guiado por pruebas.
Y, por encima de todo, como todo el trabajo de organización y técnico tiene que estar inmerso en una cultura realmente ágil: equipos auto-organizados y colaboración máxima entre los miembros.
Volvemos en breve. ¡Seguid conectados!
