LECCIÓN 13: Medición Ágil

La información es la materia prima de la toma de decisiones, proporcionando criterios objetivos de gestión y seguimiento. Una de las principales actividades que, además, favorece la toma de decisiones en la gestión y seguimiento de proyectos ágiles es la medición de todo el proceso y del producto resultante.

Sin embargo, un problema común en los proyectos tradicionales es la tendencia a medir en exceso, sin tener en cuenta su utilidad, generando costes,  pérdidas de tiempo, lentitud en el desarrollo del proyecto, etc. De acuerdo con los principios del Manifiesto Ágil (ver lección 3 El Manifiesto Ágil), en el caso de este tipo de proyectos el objetivo debe ser medir lo mínimo necesario para entregar el máximo valor al cliente.

¿Cómo elegir un indicador ágil?

Cualquier indicador que se obtenga en un proyecto debería ayudar a tomar decisiones y estar relacionado directamente con un objetivo. Hartmann y Dymond enumeran un conjunto de recomendaciones a la hora de elegir un indicador ágil:

• Reforzar los principios ágiles. Los indicadores deberán ser “ágiles” y no solo por medir un proyecto que ha seguido una metodología ágil. Un indicador comunicado de manera deficiente, complejo de calcular o poco flexible es un ejemplo de indicador poco “ágil”.
• Medir resultados y no salidas. Por ejemplo se podría realizar la medición del trabajo que todavía falta para terminar una iteración; pero sin embargo, medir la cantidad de líneas de código desarrolladas, no proporcionaría ningún tipo de información valiosa para el equipo o el cliente.
• Seguir tendencias y no cifras. Al igual que en el caso de la estadística, es necesario trabajar con información agregada. No se debería trabajar con una granularidad menor que la proporcionada por el nivel de “equipo” o “iteración”.
• Trabajar con poca cantidad de indicadores. Si se trabaja con demasiada información, esta puede ocultar tendencias importantes.
• Fácil de recolectar. Debería ser tan fácil como presionar un botón para obtener listados de datos.
• Proveer información de manera periódica y frecuente. Para lograr diagnósticos rápidos, evitar desviaciones profundas o mejorar la motivación, los indicadores deben actualizarse diariamente, semanalmente o al final de cada iteración.

Los indicadores deberían estar siempre relacionados con el valor para el cliente producido por el equipo. De esta manera se pretende obtener software de calidad, con un desarrollo rápido y que aporte valor al cliente.

Siguiente semana: LECCIÓN 14 Principales Indicadores Ágiles

LECCIÓN 12: Estimación Ágil

Según McConnell, autor del libro Software Estimation: Demystifying the Black Art, la mayoría de los errores que se producen con más frecuencia en los proyectos software están relacionados con aspectos de estimación. Y, siendo este un factor tan crítico, no es extrañar que los proyectos ágiles incluyan tecnicas de estimacion.

Para poder entender la estimación ágil se deben tener en cuenta los siguientes factores:

• Estimación del tamaño (Estimation of Size): técnica que proporciona una estimación de alto nivel para los elementos de trabajo. Se suele usar una medida neutral como por ejemplo los puntos de historia (story points).
• Velocidad (Velocity): indicador que describe el número de la cantidad de trabajo (medido en tareas, por ejemplo) que los programadores pueden desarrollar en una iteración.
• Estimación del esfuerzo (Estimation of Effort): técnica que proporciona una estimación, normalmente en días u horas, del esfuerzo requerido por el equipo para completar el trabajo expresado.

Planning Poker

Una vez elegidas las historias de usuario que se van a realizar en un Sprint, es necesario realizar una estimación más detallada. El Planning Poker  es una técnica para calcular una estimación basada en el consenso y es utilizado para estimar el esfuerzo o el tamaño relativo de las tareas de desarrollo de software. El Planning Poker está muy arraigado en las técnicas ágiles por su sencillez, facilidad y bajo coste.

Usando Planning Poker es fácil estimar las historias de usuario de una manera ágil y rápida combinando la analogía y el juicio experto a un entorno grupal democrático. Esta técnica nos lleva a estimaciones respaldadas por todos los involucrados y basadas en consensos. A continuación se enumeran los pasos básicos en una estimación por Planning Poker:

1. Se presentan las historias de usuario (o sus tareas) a estimar una por una haciendo una descripción de las mismas. Y se procede a discutir aquellos detalles más relevantes o que no hayan quedado claros.
2. Tras este período de discusión cada una de las personas implicadas en el proceso de estimación toma un mazo de cartas (que están numeradas según la serie de FibonaccI). El valor de la carta representa la estimación del esfuerzo que implica realizar la historia de usuario que se está discutiendo. Las estimaciones son privadas.
3. Las unidades utilizadas pueden ser variadas y deben estar definidas previamente. Pueden ser días reales, días ideales o puntos de la historia. Como consenso se denominan “puntos de poker”.
4. Finalmente se publican todas las estimaciones realizadas por los miembros del equipo.
5. Generalmente la dispersión en las estimaciones es síntoma de que la información que manejan parte de los involucrados en el proceso de estimación no es completa o exacta. La segunda ronda de discusión permite aclarar aquellos puntos poco claros, diferencias de criterio y desvelar información que pueda no ser obvia sobre el requisito.
6. Por último, si no existe una gran dispersión, se llega por consenso a un acuerdo en la estimación de la historia de usuario.

Animación

Presentamos la quinta entrega de la animación creada por el equipo de Kybele Consulting: “Valoración y estimación del Product Backlog”. Nuestros amigos animados nos enseñarán, de una manera simplificada, cómo estimar usando Planning Poker.

Siguiente semana:
LECCIÓN 13 Medición ágil

LECCIÓN 11: Kanban

Kanban es una palabra japonesa que significa “tarjetas visuales” (kan significa visual, y ban tarjeta). El origen del Kanban es muy similar a Lean Manufacturing (la última semana pasada vimos el Lean Software Development), son métodos de trabajo creados por Toyota para mejorar la eficiencia de su producción.

Se basa en el desarrollo incremental, dividiendo el trabajo en partes. Una de las principales aportaciones es que utiliza técnicas visuales para ver la situación de cada tarea. Cada una de esas partes se escribe en una tarjeta y se pega en un tablero.

Las principales reglas de Kanban son las tres siguientes:

1- Visualizar el trabajo y las fases del ciclo de producción, o flujo de trabajo.

Es muy importante analizar los estados del flujo de trabajo en el proyecto. Una de las formas de visualizar dichos estados es implementando tableros (también conocidos como muros o pizarras) con información visual para mejorar la comunicación en el equipo Kanban.

El trabajo a realizar en el proyecto se divide en partes, normalmente cada una de esas partes se escriben en un post-it y se pegan en una pizarra. Los post-it suelen tener información variada, si bien, aparte de la descripción, debieran tener la estimación de la duración de la tarea. Los post-it podrían ser la representación de las historias de usuario que vimos en la lección 4.

La pizarra tiene tantas columnas como estados por los que puede pasar la tarea (ejemplo, en espera de ser desarrollada, en análisis, en diseño, etc.). Podéis ver un ejemplo en la tabla siguiente:

2 – Determinar el límite de “trabajo en curso”.

Quizás una de las principales ideas del Kanban es que el trabajo en curso (Work In Progress) debería estar limitado, es decir, que el número de tareas que se pueden realizar en cada fase debe ser algo conocido.

En Kanban se debe definir cuantas tareas como máximo puede realizarse en cada fase del ciclo de trabajo. A esto se añade otra idea tan razonable como que para empezar con una nueva tarea alguna otra tarea previa debe haber finalizado.

En el anterior ejemplo vemos que, en el muro Kanban, el número límite de tareas (work in progress) se ha colocado entre paréntesis debajo del nombre de cada estado del flujo de desarrollo. Podéis ver, por ejemplo, que el límite del “work in progress” para el desarrollo es 4. Es decir, que, como máximo, se podrán realizar simultáneamente 4 tareas en este estado de desarrollo.

3 – Medir el tiempo en completar una tarea.

El tiempo que se tarda en terminar cada tarea se debe medir, a ese tiempo se le llama “lead time”. El “lead time” cuenta desde que se hace una petición hasta que se hace la entrega. Aunque la métrica más conocida del Kanban es el “lead time”, normalmente se suele utilizar también otra métrica importante: el “cycle time”. El “cycle time” mide desde que el trabajo sobre una tarea comienza hasta que termina. Si con el “lead time” se mide lo que ven los clientes, lo que esperan, y con el “cycle time” se mide más el rendimiento del proceso.

Puede haber más métricas, pero las anteriores son las realmente importantes, y necesarias para el control y mejora continua.

Siguiente semana: LECCIÓN 12 Estimación Ágil

LECCIÓN 1: Introducción a la gestión ágil de proyectos software

Aunque muchas veces se compara a la ingeniería del software con la arquitectura o la fabricación de productos físicos, como las cadenas de montaje, construir software no es igual que construir productos físicos. Pero son muchas las ocasiones en las que escuchamos que el desarrollo software debiera trabajar igual que este tipo de procesos de construcción de productos físicos. El desarrollo “debería trabajar como las cadenas de montaje, deberíamos enviar una especificación de requisitos a la empresa o equipo de desarrollo y esperar un producto que cumpla plenamente con la misma”.

Pero difícilmente el cómo se desarrolla software será igual que fabricar un coche o construir un edificio. El producto final, el software, tiene diferencias muy sustanciales con estos productos físicos. Y obviar estas diferencias puede implicar importantes problemas a la hora de desarrollar, planificar, gestionar, etc., el proyecto software.

Uno de los pilares de las metodologías ágiles es reconocer y dejar clara esta diferencia (fabricar software no es lo mismo que fabricar un producto físico). ¿Por qué? Porque aunque hay muchas diferencias, a la hora de desarrollar software las fases de diseño y construcción no se comportan de manera similar y los costes del proyecto se comportan de manera diferente. Veámoslo a continuación.

Separación diseño y construcción

En la ingeniería software, a diferencia de la arquitectura u otras ingenierías tradicionales, no se puede separar tan claramente la fase de diseño de la fase de construcción.

Desde sus orígenes, la ingeniería del software intentó perseverantemente emular a las ingenierías clásicas o a la arquitectura. El objetivo era tener una fase de diseño muy separada de la fase de codificación. La codificación no debía comenzar hasta que no terminase el diseño. El diseño concluiría con unos “planos” (p.e. un UML) precisos que guiarían totalmente la construcción. Idealmente, una vez hecho el diseño, éste no se modificaría durante el resto del desarrollo (como ocurre a la hora de construir un edificio, que los planos son previos a la obra, y no se modifican una vez empezada la construcción). De hecho, notaciones para “planos” como UML y ciclos de vida como el cascada (donde cada fase se hace una sola vez y no se pasa a la siguiente fase hasta que se termina la previa) nacieron con este objetivo. De ahí que a las metodologías más tradicionales se las denominaran también “dirigidas por el plan”.

Está demostrado que es muy difícil especificar en una única y primera fase de diseño todas las cuestiones a tratar en la programación. Por la complejidad de las reglas de negocio que automatizamos cuando construimos software es muy difícil saber qué software se quiere hasta que ya se trabaja en su implementación. De ahí que, en el software, el diseño y la construcción se solapen y que, por ello, muchas veces se recomiende construir por iteraciones (mediante el uso de prototipos incrementales). El diseño muchas veces se construye casi en paralelo a la codificación.

A la mayoría de los diseños de las ingenierías clásicas, arquitecturas, etc., no les sucede esto porque se basan en las matemáticas o la física. En software no es así. Y aunque se pretenda emular ese modo de fabricación en software no funciona bien. Debemos tener muy claro que es casi imposible cerrar un diseño a la primera para pasarlo a codificación sin tener que modificarlo.

La diferente distribución de los costes del proyecto

Por lo general, realizar un cambio en el producto final de una ingeniería clásica o en un edificio es muy costoso. Cambiar un pilar en un edificio ya construido es altamente costoso. Cambiar una pieza en un coche ya construido implica altos costes. Pero en cambio el software, por su naturaleza (y si se construye bien), es fácil de modificar y versionar. Cambiar líneas de código tiene menos coste que cambiar los pilares de un edificio ya construido. De ahí que existan numerosas propuestas que recomiendan construir rápido una versión software y modificarla evolutivamente (p.e. la técnica de refactorización). Y por ello, las metodologías ágiles aceptan el cambio del software, y están pensadas para convivir con esta constante evolución y cambio del producto software. Cambiar el software no es un problema… es una ventaja.

Conclusión

Intentar construir software de la misma manera a como se hace un edificio puede implicar importantes problemas a la hora de desarrollar, de planificar el proyecto, gestionarlo o incluso a la hora de poner solución a una posible desviación sobre el plan.

Los intentos por comparar e intentar emular la construcción de productos físicos han llevado a grandes errores en gestión de proyectos software. Como intentar añadir más programadores a un proyecto retrasado con el objetivo de acelerarlo, creando el efecto contrario (te recomiendo aquí la lectura de este post). O intentar calcular el avance de proyecto contando líneas de código. Ambos errores vienen de pensar que construir software es como construir un edificio (si la obra va retrasada añado más albañiles o cuento el avance según los “ladrillos” o los metros de altura del edificio).

Las características de los proyectos de desarrollo software hacen necesario seguir prácticas específicas para optimizar los resultados del desarrollo. Es por ello que surgen diferentes metodologías para dirigir y gestionar proyectos software, entre ellas las metodologías ágiles. Éstas están especialmente indicadas para proyectos con requisitos cambiantes y cuando se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad.

La semana que viene veremos el ciclo de vida iterativo e incremental, base de las metodologías ágiles y que refleja un método de gestión diferente a aquel dirigido por el plan.

Siguiente semana: LECCIÓN 2
El ciclo de vida iterativo e incremental

LECCIÓN 2: El ciclo de vida iterativo e incremental

Como vimos en la anterior lección, el ciclo de vida en cascada es muy típico en la construcción de productos físicos. Y aunque ha sido utilizado ampliamente en el mundo del software… también ha sido  muy criticado desde el punto de vista ágil. Frente al ciclo de vida en cascada, el paradigma ágil (en la mayoría de sus metodologías) recomienda el uso de otro tipo de ciclo de vida: el iterativo e incremental.

Si en un ciclo de vida en cascada las fases del ciclo de vida (requisitos, análisis, diseño, etc.) se realizan (en teoría) una única vez, y el inicio de una fase no comienza hasta que termina la fase que le precede, en un ciclo de vida iterativo e incremental se va liberando parte del producto (prototipos) periódicamente, en cada iteración. En vez de una única fase final de elaboración del producto, en el ciclo de vida iterativo e incremental hay múltiples fases intermedias (tantas como iteraciones), en las que se elabora parte del producto (prototipo); cada prototipo incrementa la funcionalidad y mejora al anterior; cada iteración hace “crecer y mejorar” el producto. El producto se desarrolla por ciclos (iteraciones).

Iterativo + Incremental

Aunque normalmente hablamos de iterativo e incremental (o incluso sólo de iterativo), ello no quiere decir que ambos sean lo mismo. De hecho, el desarrollo iterativo no implica, ni presupone el uso del incremental, y viceversa. Para ver la diferencia, veamos la definición de cada tipo de ciclo de vida:

• El desarrollo incremental surge para eliminar los riesgos asociados a construir productos software grandes o con alto grado de complejidad. Se centra en desarrollar por partes el producto software, para después integrarlas a medida que se completan. Un ejemplo de un desarrollo puramente incremental puede ser la agregación de módulos en diferentes fases. Gráficamente vemos como cada vez se van añadiendo nuevas partes que se van integrando para formar el producto final.

• El desarrollo iterativo se centra en mejorar y revisar el producto ya creado. En cada ciclo se revisa y mejora el trabajo. Un ejemplo de desarrollo iterativo y no incremental es aquel basado en refactorizaciones (te dejamos una pequeña introducción a la refactorización), en el que cada ciclo mejorando más el producto. En el ejemplo gráfico de abajo se puede apreciar que se trata de un método de mejora a través de las sucesivas  iteraciones. Es importante señalar no hay adición de funcionalidades en el producto, hay revisión y mejora.

De la unión del ciclo de vida iterativo y el incremental al final de cada iteración se consigue una versión estable del software, añadiendo además nuevas funcionalidades a las versiones anteriores. Así, el producto software se desarrolla por incrementos en el que cada iteración (incluida la primera) obtiene una versión operativa del producto, así el sistema se desarrolla y mejora poco a poco y se obtiene un “feedback” continuo por parte del cliente sobre un producto operativo.

En el siguiente ejemplo gráfico, a diferencia de los anteriores, vemos cómo en cada iteración al producto creado en la primera se le van añadiendo nuevas formas, tonos, colores (funcionalidades).

Además, como podemos observar, las nuevas modificaciones se aplican sobre el trabajo ya creado desde el principio ya que, desde la iteración 1, es una versión del producto final. Y cada iteración mejora el producto.

Ventajas del ciclo de vida iterativo e incremental

Las ventajas que ofrece un ciclo de vida iterativo e incremental son varias. Además de intentar evitar todos los problemas que vimos en la lección anterior con el ciclo de vida en cascada, te dejamos algunas más:

• Visión de avance en el desarrollo, viendo trabajo operativo real desde etapas iníciales del ciclo de desarrollo.
• Obtención del “feedback” del usuario sobre un prototipo operativo. Así puede orientar el desarrollo hacia el cumplimiento de sus necesidades, y realizar todas las adaptaciones identificadas para cumplir con los objetivos planteados.
• Permite manejar el riesgo del proyecto, apuntando a la resolución de los problemas por partes, y no caer en la inanición del “súper análisis” del producto.
• El aprendizaje y experiencia del equipo iteración tras iteración sobre un prototipo operativo, lo que mejora exponencialmente el trabajo, aumenta la productividad y permite optimizar el proceso en el corto plazo.

Siguiente semana:

LECCIÓN 3 El manifiesto ágil

LECCIÓN 4: La historia de usuario

Una historia de usuario describe funcionalidad que será útil para el usuario, o el comprador, de un sistema software. Por definición, las historias de usuario no suelen ni deben tener el nivel de detalle que tiene la especificación de un requisito tradicional. Se recomienda que las historias de usuario se escriban en un espacio reducido, y que el soporte físico, normalmente un post-it o una tarjeta, tenga apenas una frase.

Ron Jeffries comentaba que una historia no es sólo una descripción de una funcionalidad, normalmente en un post-it, una historia de usuario además está formada por tres partes:

1. Creación de la tarjeta (o post-it).  Una descripción escrita con un título asociado que sirve como identificación del requisito.  También puede contener la estimación, el valor de negocio que tiene la historia para el usuario, etc.
2. Conversación. El diálogo llevado a cabo entre el equipo y el cliente para aclarar los detalles y las dudas que puedan surgir  sobre la historia de usuario. Esta es la parte más importante de la historia de usuario.  En el caso de estar usando post-it, estas aclaraciones (o confirmaciones) se podrían especificar a la vuelta del mismo.
3. Confirmación. Selección de las pruebas que se realizarán para comprobar que la historia de usuario se ha completado con éxito.

Las historias de usuario, frente a mostrar un “cómo”, sólo dicen el “qué”.  Es decir, muestran funcionalidad que será desarrollada, pero no cómo se desarrollará. Por ello, cosas como que “el software se escribirá en C++” no es una buena historia de usuario.

Aparte de por su manejabilidad y como herramienta para la interacción con el cliente, las historias de usuario han tomado un gran protagonismo en las metodologías ágiles ya que

• Favorecen la participación del equipo en la toma de decisiones.
• Se crean y evolucionan a medida que el proyecto avanza.
• Son peticiones concretas y pequeñas.
• Contiene la información imprescindible.
• Apoyan la cooperación, colaboración y conversación entre los miembros del equipo.

Información contenida en  la historia de usuario

A continuación vamos a ver las partes más comunes que se suelen encontrar en una historia de usuario. La historia de usuario está compuesta por:

• ID: Identificador de la historia de usuario.
• TÍTULO: Título descriptivo de la historia de usuario.
• DESCRIPCIÓN: Descripción sintetizada de la historia de usuario. Si bien el estilo puede ser libre, la historia de usuario debe responder a tres preguntas: ¿Quién se beneficia? ¿Qué se quiere? y ¿Cuál es el beneficio? Por ello, algunos autores recomiendan redactar las historias de usuario según el formato:Como (rol) quiero (algo) para poder (beneficio)
• ESTIMACIÓN: Estimación del coste de implementación en unidades de desarrollo (estas unidades representarán el tiempo teórico de desarrollo/hombre que se estipule al comienzo del proyecto).
• VALOR: Es dado por el cliente. El Manifiesto Ágil deja claro que una de nuestras prioridades debe ser entregar software que funciona. Éste, además, maximizará el valor y la satisfacción percibida por el cliente. El valor determinará, junto con el tiempo, el orden con el que las historias de usuario van a ser implementadas.
• DEPENDENCIAS: Una historia de usuario no debería ser dependiente de otra historia, pero en ocasiones es necesario mantener la relación. En este apartado se indicarían los IDs de las tareas de las que depende una tarea.
• PRUEBAS DE ACEPTACIÓN: Pruebas consensuadas entre el cliente y el desarrollador y que el código debe superar para dar como finalizada la implementación del requerimiento. También se las suele denominar “criterios de aceptación”.

Las historias de usuario son comúnmente usadas en las metodologías ágiles como Scrum o XP.

Siguiente semana:
LECCIÓN 5 Scrum

LECCIÓN 5: Scrum (1/2)

Scrum es una metodología ágil que proporciona un marco para la gestión de proyectos. Podríamos decir que hoy es la metodología ágil más popular. El objetivo principal de Scrum es obtener resultados tempranos adaptándose a los cambios.

De manera sintetizada, los pilares de Scrum son, principalmente, dos:

• El ciclo de vida iterativo e incremental (puedes repasar aquí la lección 2: El ciclo de vida iterativo e incremental).
• Las reuniones a lo largo del proyecto (de las cuales hablaremos la próxima semana).

Veamos a continuación las principales herramientas de Scrum.

El Sprint, el Product Backlog y el Sprint Backlog

Como hemos visto, una de las bases de la mayoría de las prácticas ágiles es el ciclo de vida iterativo e incremental, y en Scrum éste está representado a través de “Sprints”. En Scrum a cada iteración se le denomina Sprint.

El Sprint es un periodo de corta duración (2-4 semanas) en el que se crea un producto, un prototipo operativo. Las características que van a implementarse en el Sprint provienen de la Pila del Producto (Product Backlog), que contiene una serie de historias de usuario ordenadas (puedes ver la lección 4: La historia de usuario).

Una vez seleccionadas las historias de usuario que se van a desarrollar en el Sprint, se conforma la Pila del Sprint (Sprint Backlog). Ésta es una lista de tareas, donde se describe cómo el equipo va a implementar las historias de usuario durante el siguiente Sprint. Además, se mantendrá inamovible durante toda la iteración.

Para mejorar la gestión de las historias de usuario y las tareas de cada Sprint usualmente se utilizan pizarras u otros mecanismos que aporta información inmediata al equipo. En la figura de abajo, podemos ver cómo cada historia de usuario del Product Backlog se divide en tareas. En el ejemplo, las tareas pasarán de estar pendientes a iniciadas, hasta que se completen. Este mecanismo de comunicación visual es muy utilizado en otras prácticas, como, por ejemplo, Kanban.

Una animación: Comenzando un proyecto Scrum

A continuación podéis ver la segunda entrega de la animación creada por el equipo de Kybele Consulting: “Introducción y conceptos de Scrum”.

Nuestros amigos animados inician un nuevo proyecto en el que van a utilizar por primera vez metodologías ágiles. Concretamente van a aplicar Scrum y el jefe de proyecto es explica la metodología.

Siguiente semana:
LECCIÓN 6 Scrum (2/2)

LECCIÓN 7: eXtreme Programming (1/3)

eXtreme Programming (en adelante, XP), al igual que en otras metodologías ágiles, es una metodología adaptativa y centrada en las personas.XP agrega buenas prácticas que abarcan más allá de la gestión de proyectos definiendo aspectos más técnicos y cercanos al desarrollo software.

Por tanto, no es raro ver que Scrum se complementa perfectamente con XP. Llegando al punto que hay quien dice que si quieres implantar Scrum en tu empresa (aquí te dejamos las lecciones de Scrum (1/2) y Scrum (2/2)), un buen punto de partida es seguir las buenas prácticas de XP.

Las buenas prácticas de XP

XP establece unas buenas prácticas que hacen el proyecto más flexible para conseguir reducir los riesgos. Durante esta semana y la que viene comentaremos algunas de ellas:

• Planning Game: Su objetivo es determinar rápidamente el alcance de la siguiente iteración. Para ello se utilizarán tanto las prioridades del negocio como las estimaciones técnicas. En este sentido, los desarrolladores tendrán mayor peso en los aspectos técnicos: las estimaciones ágiles, riesgos técnicos, orden en las actividades, etc. Y los jefes de proyecto o, en general, los encargados del negocio tendrán una perspectiva más global: el establecimiento del alcance o la priorización de las entregas.
• Entregas pequeñas: Su objetivo es que los ciclos de construcción y despliegue de nuevas funcionalidades sean rápidas. Es necesario poner en producción rápidamente una nueva versión del sistema para planificar la siguiente.
• Metáfora: Su objetivo es generar una descripción simple, conocida y entendida por todos, para guiar a los desarrolladores acerca de cómo funciona el sistema.Cada proyecto software estará guiado por una metáfora. Una buena metáfora es fácil de comprender por el cliente y contener suficiente información para guiar la arquitectura del proyecto. A continuación, en la siguiente tabla, se resumen las características de una metáfora.
  

  Características	Pero…
  Ayuda a entender los elementos básicos y sus relaciones	No es una explicación detallada y profunda
  Se pueden utilizar ejemplos para aclarar la metáfora	Un ejemplo no debe ser tomado de manera literal.
  La metáfora es una forma de reemplazar la arquitectura	La metáfora no es sinónimo de arquitectura
  Fácil de elaborar y de comunicar	No es solo para los programadores, clientes o jefes de proyecto

• Clientes On-site: Incluir un cliente en el equipo, disponible para contestar preguntas. A partir de los clientes se pueden resolver pequeñas disputas o priorizaciones.
• Programación estándar: Los programadores escribirán el código fuente de acuerdo con estándares de programación y buenas prácticas que favorezcan la comunicación. En este sentido, la buena práctica no tiene que malinterpretarse y generar una gran cantidad de documentación sobre cómo escribir código fuente.

Siguiente semana:
LECCIÓN 8 XP (2/3)