[ Estás en Unidades Didácticas / Unidad 2. Técnicas y recursos ágiles / 2.1 Representación y control del flujo del proyecto ]
 
El desarrollo de software es, entre otras cosas, gestión de proyectos. El agilismo promueve transparencia en el flujo del proyecto, cualquier individuo de la organización debería saber en cualquier momento cómo se está desarrollando el proyecto. Se deben usar técnicas que permitan representar sus partes, visualizarlas o gestionar su flujo.

Analizaremos en clase cada una de las técnicas presentadas en esta página. Para ir asimilando el contenido de esta asignatura sería preferible que tuvierais una idea de cada una de ellas antes de que yo las plantee en clase por lo que en esta unidad, al finalizar cada clase os pediré que leáis (sólo leer) las técnicas que analizaremos en la siguiente clase.

Historias de usuario

 
Una historia de usuario (caché) es la descripción (no técnica) de un requisito del sistema. Debe ser una descripción breve y en un lenguaje comprensible para el cliente, que es quien tiene que validarla.

• Escrita en una tarjeta (nota adhesiva) para limitar su longitud.
• Ampliable sólo para añadir textos literales, condiciones detalladas…
• Incluyen criterios de validación, que serán los que use el cliente para aceptar la implementación del requisito.

Cuando en un proyecto se definen correctamente todas las historias de usuario necesaria facilitan:

• La comprensión de todos los requisitos por parte de cliente y empresa de desarrollo.
• La división del proyecto en entregas.
• La estimación del coste de cada requisito.

Además el mantenimiento de estas historias suele ser sencillo, no tanto su creación si el cliente no tiene excesivamente claro qué características quiere en el producto encargado. Para definir una historia de usuario se debe partir de la siguiente plantilla: Como (rol) quiero (algo) para poder (beneficio).

Como quiero para poder

No hay un formato único que defina la información que debe recogerse en una Historia de Usuario, sólo se debe intentar ser conciso y recoger toda la historia en poco espacio. Cada equipo ágil sabrá qué formato necesita, a menudo diferente para diferentes estereotipos de clientes. El ejemplo mostrado en ProyectosAgiles.org es bastante genérico.

Historia de Usuario

Los criterios de aceptación se han de definir para cada historia de usuario. El equipo de desarrollo ha de saber diseñar sus pruebas para dar por terminada una historia de usuario. El cliente se basará en estos criterios para aceptar la entrega que incluye a una historia de usuario concreta. La incertidumbre o falta de experiencia de clientes o equipos de desarrollo puede provocar que se descubra tarde, una vez hecha la entrega, que cierta historia de usuario no funciona como se esperaba o no proporciona el valor estimado o… Tanto cliente como equipo de desarrollo han firmado un contrato y especificado unas condiciones de aceptación que se han cumplido aunque no eran las correctas, como hablamos de equipos y clientes ágiles encontrarán una solución puntual a este imprevisto.

Valor de una historia de usuario

 
El cliente, tenga o no razón, es quien decide la prioridad de las historias de usuario en la Pila del Producto. Cuando trabaja con un equipo ágil profesional podrá recibir consejos valiosos derivados de la experiencia del equipo, pero será él quien financie el desarrollo de cada historia y quien decidirá si vale la pena invertir mucho o poco dinero en historias que al equipo pueden parecer más o menos valiosas para el producto final.

El diálogo entre cliente y equipo es fundamental en toda metodología ágil. Si tras el diálogo se llega a acuerdos que el equipo no comparte del todo pero es capaz de realizar no debe terminar en un conflicto de malentendidos si no en mayor satisfacción del cliente.

Requisitos

 
Los requisitos definen el producto final, tanto en su aspecto como en su funcionalidad. Su definición y conocimiento por parte del cliente y de todo el equipo sirve para definir el flujo del desarrollo del software y para saber en cada momento cuál es la situación real del proceso, qué partes están ya implementadas, ensambladas…

La Wikipedia (caché) nos ofrece el siguiente resumen sobre el término en el ámbito del desarrollo de software:

En la ingeniería de sistemas, un requisito es una necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio. Se usa en un sentido formal en la ingeniería de sistemas, ingeniería de software e ingeniería de requisitos.

En la ingeniería clásica, los requisitos se utilizan como datos de entrada en la etapa de diseño del producto. Establecen qué debe hacer el sistema, pero no cómo hacerlo.

La fase de captura, elicitación y registro de requisitos puede estar precedida por una fase de análisis conceptual del proyecto. Esta fase puede dividirse en recolección de requisitos, análisis de consistencia e integridad, definición en términos descriptivos para los desarrolladores y un esbozo de especificación, previo al diseño completo.

Forman parte fundamental del contrato establecido entre el cliente y la empresa de desarrollo de software ya que bien gestionados sirven para que todos conozcan los objetivos completos del software a desarrollar, el estado del proyecto en cualquier momento en cuanto a requisitos implementados, la evaluación del producto en base al cumplimiento de requisitos… Su importancia es tal que podemos hablar de una Ingeniería de Requisitos (caché) que convendría interiorizara cualquier miembro de un equipo ágil. La experiencia personal en la gestión de proyecto es fundamental para poder trabajar con los mejores requisitos en cada proyecto pero la experiencia colectiva siempre aportará visiones que nos harán tener en cuenta conceptos o posibilidades que no contemplaremos en nuestros primeros usos de requisitos para cualquier proyecto.

En principio los define el cliente pero muchos de ellos los propone la empresa de desarrollo cuando conoce los requisitos del cliente. Se han de definir todos claramente de modo que tanto el cliente como el equipo de desarrollo no tengan dudas de cuál ha sido el encargo, por ello aparecerán otros elementos que facilitarán la gestión de los requisitos, adaptándolos a las características diferenciales de clientes y desarrolladores.

En el aspecto puramente de desarrollo se definen los requisitos funcionales (caché) y los requisitos no funcionales (caché)

Pila del Producto (Product Backlog)

 
La Pila del Producto (Product Backlog) es la lista de requisitos (objetivos) priorizada según la visión y expectativas del cliente. La Pila del Producto define por completo al producto que demanda el cliente.

En la ingeniería tradicional consistía en el listado que describía por completo a la aplicación a desarrollar. En las técnicas ágiles también, pero se da más importancia a la priorización y al cambio, se realizan entregas funcionales de parte del producto final por lo que se definirán conceptos definiendo esas partes entregadas, el Sprint Backlog en el caso de Scrum.

Las técnicas ágiles incrementan de forma constante y predecible el valor del producto entregado al cliente. El cliente se beneficia del uso del software desde la primera entrega, no tiene que esperar unos meses para recibir el producto final. El cliente puede revisar las historias de usuario que ya están planificadas y decidir si alguna de ellas ha de sufrir alguna variación, ser eliminada o adelantada en el tiempo. El producto se adapta al cliente y su desarrollo al equipo ágil. Los cambios que se produzcan sobre la Pila del Producto original se valoran con rapidez y las estimaciones de tiempo y costes son cada vez más acertadas. El equipo ágil es capaz de aprender tras cada entrega cómo fueron de acertadas sus anteriores estimaciones, si se interioriza esta información por parte de todos los miembros del equipo se estará creciendo como empresa de desarrollo.

Tanto el cliente como la empresa de desarrollo han de tener claro el alcance de la aplicación a desarrollar, su Pila del Producto queda definida y valorizada desde el principio. El desarrollo de software está sujeto a muchos imprevistos, los reducimos mediante la técnica de «Divide y vencerás«, pero antes de dividir hemos de conocer las expectativas del cliente y estimar los costes y tiempos asociados. La experiencia de los desarrolladores es fundamental en esta fase del producto, si son conscientes de sus conocimientos, limitaciones, herramientas disponibles… podrán hacer buenas estimaciones sobre el tiempo y costo que supondrá el proyecto. Sin conocer el alcance real del proyecto y su coste difícilmente se llegaría a un acuerdo entre ambas partes, quizá el cliente apueste por la oferta recibida por otra empresa de desarrollo o por la compra de un software genérico que resuelva (mejor o peor) sus necesidades.

Estimación de esfuerzo

 
Para que historias de usuario y requisitos formen realmente una Pila del Producto se han de completar con estimaciones del esfuerzo que ha de realizar el equipo ágil para completar cada uno de ellos. Es totalmente independiente del valor que el cliente asigne a cada ítem, se trata de una estimación indirecta del coste que tendrá llevarlo a cabo, el cliente es quien decide si quiere invertir más o menos tiempo y dinero para obtener cada una de sus historias de usuario.

Aquí entra en juego la profesionalidad y experiencia del equipo ágil. Las metodologías ayudan a crecer en este aspecto, son una serie de conceptos y acciones que se ha demostrado que pueden darnos información muy valiosa sobre las características específicas de nuestro equipo de desarrollo, incluso ayudarnos a decidir que necesitamos más desarrolladores o probadores o comerciales o… Hay metodologías, como Scrum, que estipulan que no debe estimarse el esfuerzo de llevar a cabo tareas triviales, se ha de reservar el esfuerzo que conllevan esas estimaciones para aquellas tareas más inciertas. La experiencia del equipo es la que, con el tiempo, permitirá clasificar como triviales muchas tareas que ya ha llevado a cabo en otros proyectos.

Cuando una tarea no forma parte de la entrega actual no es necesario dedicar demasiado tiempo para estimar cuánto nos costará. Como somos ágiles sabemos que existirán dependencias entre lo que consigamos ahora y lo que necesitemos añadir para completar la tarea, dependencias que pueden ser complicadas en su momento o pueden estar ya resueltas.

En general, la modularidad impuesta por las metodologías ágiles nos sugerirá que las historias de usuario que representen un gran esfuerzo se dividan en historias menores. Sin llegar a límites extremos de granularidad hemos de ser capaces de tener una Pila del Producto con requisitos que puedan completarse en periodos de tiempo pequeños, incluso dentro de la misma jornada laboral si queremos que los desarrolladores no salgan del trabajo con la sensación de tener que dedicar algo de tiempo al proyecto en su tiempo personal.

En la ingeniería tradicional estas estimaciones se basan en el tiempo que llevará a cabo el proceso de la historia, algo bastante incierto que se convierte en dinero multiplicando un par de valores. En las ingenierías ágiles se basan en esfuerzo, un concepto más abstracto que incluye el tiempo de las metodologías pesadas.

Pueden ocurrir muchas cosas que afecten al tiempo necesario para llevar a cabo cierto desarrollo, que durante una semana tengamos 5 miembros menos en el equipo o que tengamos 12 más sería uno de ellos. La empresa ágil de desarrollo de software no vende tiempo, vende esfuerzo. Los equipos de desarrollo ágil estiman el esfuerzo que conlleva la ejecución del trabajo al que se enfrentan.

Lo más relevante de las metodologías ágiles es la autogestión del equipo. Es el equipo encargado del desarrollo actual quien estima el esfuerzo. Todo el equipo se encarga de hacer esta estimación, generalmente llegando a consensos si hay disparidad de estimaciones.

El equipo ágil debe saber hacer estimaciones rápidas (y poco precisas) y en el futuro ajustará lo que sea necesario. También debe saber hacer estimaciones más complejas y precisas para las tareas de la iteración actual. Existen muchas técnicas que ayudan al equipo a hacer estas estimaciones (debes leer un ejemplo de cada una de ellas en el libro de Eugenia Bahit que usamos en la asignatura y buscar información sobre el resto).

• T-Shirt Sizing
• Planning Poker
• Columnas
• Juicio de expertos
• Bola de cristal
• Número al azar

Criterios de aceptación (DoD, Definition of Done)

 
Son pruebas no subjetivas que permiten dar por cerrada una historia de usuario, requisito o tarea.

• El cliente decidirá los suyos, p.ej. tener un tiempo de respuesta inferior a 1 minuto en procesos que actualmente son inciertos en el software que quiere sustituir.
• Los desarrolladores pueden ver rechazado su trabajo si no se ha refactorizado correctamente el código, siempre que se haya fijado ese criterio por aquellos que integran una nueva historia en el producto.
• Los encargados de las pruebas antes de producción pueden aceptar la historia cuando ha superado cierto porcentaje de las posibles pruebas.

Son descripciones claras de qué se espera poder hacer cuando la historia de usuario esté implementada. Son concisas y sencillas, debemos tomarnos el tiempo suficiente para pensar en ellas y en que no supongan un problema para quienes se ven afectados por ellas, han de facilitar la decisión de cualquier involucrado en el producto para afirmar «He terminado con mi aportación a esta historia de usuario.

Por supuesto, un equipo ágil sabe que algunos criterios de aceptación sufrirán cambios con el tiempo. El cambio no afecta a un desarrollo ágil tanto como lo hace en en otras metodologías, es parte de su razón de ser.

Tareas

 
Las historias de usuario o requisitos se pueden dividir aún más. Al cliente no le interesa saber cuántos pasos son necesarios para conseguir que a su aplicación sólo acceda personal autorizado, o que accedan con diferentes roles. Cuando se traduce una historia de usuario en código, que es el mayor valor de una empresa de desarrollo software, se ha de considerar este punto. El cliente no es un experto informático, el equipo ágil sí.

Para hacer buenas estimaciones de esfuerzo el equipo ágil ha de dividir las historias de usuario en tareas, realmente estimará el esfuerzo para cada tarea y una simple suma le permite informar al cliente sobre el esfuerzo necesario para cada una de sus historias.

De nuevo es el equipo quien aporta su experiencia para llevar a cabo esta labor. Un equipo senior considerará que «Identificarse en el software» es una tarea que ya tienen resuelta en las circunstancias del nuevo proyecto, incluso pueden estimar que se trata de una tarea trivial si ya tienen implementado el código. No perderá el tiempo en este punto, valorará el esfuerzo en función de su valor como equipo y no del tiempo que tardaría en desarrollarlo. Un equipo que se enfrenta por primera vez a esta historia la dividirá en muchas tareas, tantas como sus miembros estimen que tienen suficiente entidad como para dedicarles al menos una hora de tiempo en su desarrollo (digo una hora por hacer más corto el discurso).

Existen muchas técnicas que ya conoce el graduado en informática para visualizar una historia de usuario desde distintas perspectivas y ser capaces de dividirla en tareas de desarrollo, en porciones de código.

Ciclo de Vida

 
El ciclo de vida de un proceso de desarrollo de software consta básicamente de seis fases, generalmente divididas en sub-procesos con la misma estructura:

1. Definición de requisitos
2. Diseño
3. Análisis
4. Desarrollo (programación)
5. Pruebas de validación
6. Integración

Casos de Uso

 
Los casos de uso (caché) son una representación de las actividades necesarias para llevar a cabo un proceso.

Kanban

 
Kanban (caché) es un sistema visual guiado por tarjetas que ayuda a tener un mejor control sobre la producción. Da lugar a una metodología ágil.

Kanban significa «tarjeta», en un esquema de producción sirve para tener un mayor control sobre la producción de las partes que se necesitan. En la siguiente figura se muestra el diagrama conceptual del Sistema Kanban utilizado por Toyota.

Diagrama conceptual del Sistema Kanban (Toyota)

Son las tarjetas quienes indican, visualmente y con las instrucciones que tengan escritas, qué proceso debe hacerse. Cada tarjeta se desplaza al siguiente punto de operación del proceso hasta llegar al final del mismo, y no se vuelve a crear una tarjeta nueva hasta que no es necesaria (producción Just-In-Time, JIT).

La tarjeta ha dado lugar a la Pizarra Kanban, en la que una tarjeta se desplaza a lo largo de la pizarra en función del estado en que se encuentra. Es un recurso visual muy útil para conocer el estado de un proyecto, y en las empresas ágiles es un recurso que está a la vista de todos por lo que puede llegar a estimular el trabajo coordinado de todos los trabajadores de la empresa.

Pizarra Kanban (extraída del libro «Kanban and Scrum, making the most of both» de Henrik Kniberg y Mattias Skarin)

 
Este ejemplo viene acompañado de una breve explicación de las posibilidades visuales que tiene una pizarra Kanban (caché).

Cumulative Flow Diagram (CFD)

 
El diagrama de flujo acumulativo (CFD) representa gráficamente la evolución del proceso en el tiempo. El eje vertical representa el número de características que se han de añadir al proyecto y el horizontal es el calendario del proyecto. Asociado a la pizarra kanban, cada semana (día, jornada…) se anota un punto sobre la fecha actual indicando el número de características que ya han pasado por esa columna (es acumulativo, de ahí que se cuenten todas las características ya realizadas en la columna específica) y un punto indicando el número de características del backlog (generalmente constante en cada iteración).

CFD by Pawel Brodzinski

Fuente: Cumulative Flow Diagram by Pawel Brodzinski on July 15, 2013 y este vídeo.

Iteración

 
Llamamos iteración a cada uno de los ciclos temporales en que se descompone la construcción ágil de un producto. Cada iteración produce un incremento de valor al producto, generalmente un entregable, un producto funcional con las características pactadas previamente con el cliente. Una iteración comienza decidiendo qué historias de usuario se van a desarrollar y cuándo se entregarán al cliente como parte integrada del producto final. La entrega del producto funcional no finaliza la iteración, las técnicas ágiles promueven el análisis de lo ocurrido durante cada iteración y su consecuente reflexión para que las siguientes iteraciones, de este o cualquier otro producto, se beneficien de la experiencia adquirida.

Los procesos ágiles son procesos evolutivos, las iteraciones son intervalos en el tiempo de esa evolución. Una iteración es algo específico de un proyecto concreto, pero en realidad es una de las mejores fuentes de información para que el equipo ágil tome consciencia de sí mismo como equipo, como parte de una empresa y de una sociedad, como parte de las soluciones que necesitan nuestros clientes antiguos, presentes y futuros.

Diagrama Burndown

 
Este diagrama refleja la cantidad de esfuerzo que aún no se ha completado en cada iteración.

By PabloStraub (Own work) [Public domain], via Wikimedia Commons

La Wikipedia lo define en un único párrafo:

Un diagrama burn down o diagrama de quemado es una representación gráfica del trabajo por hacer en un proyecto en el tiempo. Usualmente el trabajo remanente (o backlog) se muestra en el eje vertical y el tiempo en el eje horizontal. Es decir, el diagrama representa una serie temporal del trabajo pendiente. Este diagrama es útil para predecir cuándo se completará todo el trabajo. Usualmente se usa en el desarrollo ágil de software, especialmente con Scrum.

Ejercicios

1. Escribe 2 casos en que la línea de tareas realizadas quede por debajo de la línea ideal.
2. Escribe 3 casos en que la línea de tareas realizadas quede por encima de la línea ideal.
3. ¿Qué relación tiene este diagrama con la velocidad del equipo?

Fuentes

• ¿Qué es y cómo hacer un diagrama de Burndown?
• Generador de diagrama BurnDown

Recursos adicionales

 
Amplía tus conocimientos en ProyectosÁgiles.