Los trinomios cuadrados perfectos no son ágiles… o del principio de la simplicidad

“La perfección no se logra cuando no hay nada más que añadir, sino cuando no hay nada  más que quitar” [Antoine de Saint Exupéry]

En el último conversatorio sobre Scrum que facilitamos en la Comunidad de Ágiles Colombia en Medellín, hablamos de lo que significa ser ágil y llegamos necesariamente a los valores y principios del Manifiesto ágil.  Uno de los principios llamó especialmente la atención: “La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.”

Luego me encontré un artículo* de alguien que decía que había vivido gran parte de o toda su vida sin usar el trinomio cuadrado perfecto y muchas otras cosas complejas que le enseñaron en la escuela. A pesas de mi fascinación por el Álgebra, tuve que ceder un espacio en mi mente para estar de acuerdo con este pensamiento.

La tarea que me quedó fue entonces definir qué significaba #simplicidad y qué era eso de ‘maximizar’ el trabajo no realizado. Aquí algunas pistas:

Simplicidad es:

• Tener un equipo totalmente horizontal, sin títulos ni especialidades adheridas a la frente de  cada miembro, sin protocolos que seguir para comunicarse unos con otros, incluyendo al usuario, donde cada uno sea responsable de sincronizarse con los demás y que nadie le rinda cuentas a nadie. Son equipos altamente productivos.

• Usar un framework que te permita adaptarte a los continuos cambios del entorno, que te permita inspeccionar tu situación y la de tu equipo y con el que puedas modificar tu comportamiento basado en la experiencia que vas adquiriendo. Un framework que no sea una fuente de artes adivinatorias, sino más bien que evolucione contigo.

• Priorizar las características del producto y construir solo aquellas que entreguen valor al usuario y al negocio. Según algunos estudios más del 65% del software que se construye se deja de usar muy pronto o nunca llega a instalarse, así que ¿por qué no construir solo lo que el usuario verdaderamente necesita y que genere un alto valor para la organización? Construye solo necesario para obtener rápida retroalimentación.

• No realizar estimaciones a mediano/largo plazo ni prometer una fecha fija de entrega. No componer planes súper elaborados sino planificar continuamente: planificar las entregas/salidas a producción, planificar las iteraciones o sprints, planificar cada día de trabajo. A la larga, los planes no son nada, pero la planificación lo es todo.

• Usar herramientas simples, como tableros de tareas simples que estén a la vista de todos, tarjetas simples con lo que quiere el usuario (las historias de usuario: como <<usuario>> quiero <<hacer algo>> para <<obtener algún valor>>): no hagas nada a menos que su valor esté plenamente establecido. Elaborar la documentación suficiente para cubrir las necesidades de la organización.

"Pero no más simples"

• No usar trinomios cuadrados perfectos todo el tiempo. Einstein lo dijo, las cosas deberían hacerse lo más simple posible… para construir algo, una funcionalidad por ejemplo, usa la técnica de reusar-comprar-hacer. Consulta primero si ya la tienes o la tiene alguien cercano a ti. ¿No? Búscala entonces en el mercado. ¿No la encontraste? Fabrícala, pero hazlo de manera simple, sin artificios exagerados, no vuelvas el software más complejo de lo que es por naturaleza.

• Aprender continuamente. Si conoces muchas cosas, encontrarás respuestas cada vez más simples a problemas cada vez más complejos, como los que surgen en la construcción de productos de software. Así que nunca pares de aprender. Y conviértete en maestro, pero recuerda, no se trata solo de decir las cosas, porque tu aprendiz las olvida; tampoco se trata solo de enseñar, porque quizás solo logres que él/ella las recuerde; involúcralo y verás que también aprende.

¿Qué más se les ocurre que es #simplicidad? Háganmelo saber por este medio o por cualquiera de los medios habituales de comunicación.

*El artículo al que me refiero lo encuentran haciendo clic aquí.

Ágil Necesita Ser Tanto Iterativo como Incremental

Noviembre 11 de 2014, por Mike Cohn

Este artículo se publicó originalmente en el boletín mensual de Mike Cohn. Si te gusta lo que estás leyendo, suscríbete para que este contenido te llegue directamente a tu buzón semanas antes de que sea publicado en el blog, aquí.

Scrum, como todos los procesos ágiles, es tanto iterativo como incremental. Puesto que estas palabras se usan frecuentemente sin definición, permítanme definirlas.

Un proceso iterativo es uno que permite progresar a través de refinamiento sucesivo. Un equipo de desarrollo hace un primer corte del sistema sabiendo que está incompleto o frágil en algunas áreas (quizás en muchas). El equipo luego refina iterativamente esas áreas hasta que el producto es satisfactorio. Con cada iteración, el software se mejora mediante la adición de mayor detalle.

Por ejemplo, en una primera iteración, una pantalla de búsqueda podría codificarse para soportar solamente el tipo más simple de búsqueda. La segunda iteración podría agregar criterios adicionales de búsqueda. Finalmente, una tercera iteración puede agregar manejo de errores.

Una buena analogía es la escultura. Primero, el escultor selecciona una piedra de un tamaño apropiado. A continuación, el escultor talla la forma general de la piedra. En este punto, uno quizás pueda distinguir la cabeza y el torso y hasta pueda descifrar que el trabajo finalizado será un cuerpo humano en vez de un pájaro. Luego, el escultor refina su trabajo adicionando detalles. Sin embargo, es poco probable que el escultor dé por completada un área hasta que el trabajo entero esté terminado.

Por su parte, un proceso incremental es uno en el que el software se construye y entrega por piezas. Cada pieza, o incremento, representa un subconjunto completo de funcionalidad. El incremento puede ser pequeño o grande, quizás algo que vaya desde una pantalla de ingreso al sistema hasta un conjunto altamente flexible de pantallas de administración de datos.

Cada incremento se codifica y se prueba completamente y la expectativa común es que el trabajo de una iteración no necesitará volver a revisarse. Un escultor incremental elegirá una parte de su trabajo y se enfocará completamente en esta hasta que esté finalizada. Él/ella puede seleccionar pequeños incrementos (primero la nariz, luego los ojos, después la boca y así sucesivamente) o incrementos grandes (cabeza, torso, piernas y luego los brazos). Sin embargo, independientemente del tamaño del incremento, el escultor incremental intentará finalizar el trabajo de ese incremento tan completamente como le sea posible.

Scrum y ágil usan un enfoque tanto incremental como iterativo. Iterativo en el sentido de que planean que el trabajo de una iteración sea mejorado en las iteraciones subsiguientes. Incremental porque el trabajo terminado se entrega durante todo el proyecto.

Para ilustrar mejor las diferencias entre iterativo e incremental, consideremos la construcción de un sitio Web pero no de manera incremental. Para hacer esto, el equipo construiría un poco de cada parte del sitio –manejo de perfiles, búsqueda, anuncios, etc. Luego el equipo revisaría todas las partes, mejorando cada una de ellas.

Más adelante el equipo revisaría todas las partes nuevamente, haciendo otras mejoras. En este enfoque puramente iterativo, se consigue mejorar un poco el sitio completo.

Ahora, consideremos desarrollar el mismo sitio con un proceso puramente incremental pero no iterativo. Si un sitio de citas fuera construido incrementalmente, el equipo construiría y perfeccionaría la administración de perfiles antes de empezar cualquier otra parte del sitio. El equipo luego construiría y perfeccionaría otra área, digamos las búsquedas, antes de moverse a una tercera área. Cada área funcional se perfeccionaría antes de iniciar el área siguiente.

Ni iterativo ni incremental son grandiosos por sí solos. Pero juntos –como están en Scrum– son fantásticos.

Nota del traductor (¡ese soy yo!):

Traducido del artículo original de Mike Cohn: ‘Agile Needs to Be Both Iterative and Incremental’, que pueden encontrar en este enlace:

http://www.mountaingoatsoftware.com/blog/agile-needs-to-be-both-iterative-and-incremental

Publicado con permiso del autor.

Mañana empiezo un nuevo proyecto: ¿qué metodología ágil me pongo?

Ecosistema de Métodos y Prácticas Ágiles (Parcial)

El ecosistema ágil está formado por un conjunto de organismos “vivos” llamados “métodos y prácticas ágiles” (biocenosis) y el medio físico donde se relacionan, llamados Organizaciones (biotopo). Estas últimas están conformadas por personas y estas personas usan distintas clases de biocenosis, es decir, de métodos y prácticas ágiles, según sus necesidades.

Como todo ecosistema, el ágil tiene barreras que a veces impiden su normal evolución. Barreras físicas, como la falta de entornos adecuados dentro de las Organizaciones para albergar equipos que respiren “agilidad”. Barreras culturales y hasta emocionales, arraigos y miedos que se dan entre las personas, quienes experimentan temores muchas veces infundados debido a la falta de información o de acompañamiento efectivo por parte de expertos, de conocedores de ese ecosistema ágil en formación.

Pero, ¿cuáles son esos métodos y prácticas ágiles? ¿Para qué sirve cada uno de ellos? En esta sesión exploraremos, a manera de introducción, las metodologías más usadas, como Scrum, eXtreme Programming (XP), Kanban, Lean; y algunas de las técnicas necesarias en un primer esfuerzo por implementar la Cultura Ágil en una Organización: User Story Mapping, Product Vision Board, User Persona, User Stories, TDD, BDD, para mencionar solo algunas.

Y lo más importante, ¿para qué sirve cada uno de estos especímenes ágiles? ¿Alguno de ellos es adecuado para el proyecto que inicio mañana? ¿Varios de estos? ¿Son complementarios? ¿Qué problemas puedo encontrar si elijo mal? Y en el fondo, ¿cuáles son las razones por las que debo permitir el nacimiento y expansión de un nuevo ecosistema aun si el actual me está rindiendo beneficios? Y hablando de utilidades, ¿cuáles puedo obtener al implementar la “agilidad” en mi Organización?

Finalmente, sabemos que los ecosistemas están gobernados principalmente por eventos estocásticos (azar), por las reacciones que estos eventos ocasionan en sus componentes y por las respuestas de los organismos a las condiciones que los rodean. ¿Cómo controlar estos eventos y sobrevivir en el intento? Una mirada Darwiniana nos ayudará a entender cómo, mediante la inspección y la adaptación, nos iremos adecuando a los cambios que ocurren en todo proceso de evolución y entenderemos que la cultura ágil es el siguiente paso en la evolución de la inteligencia.

Nota:

Esta fue la presentación que hice durante el marco de las VII Jornadas Latinoamericanas de Metodologías Ágiles - Ágiles 2014, en Medellín, Colombia. Del 23 al 25 de octubre de 2014.

Nivel: Principiante

Título: Mañana empiezo un nuevo proyecto: ¿qué metodología ágil me pongo?

Resumen:

Uno de los impedimentos más grandes a la hora de implementar Ágil se origina en el desconocimiento que tienen las personas sobre lo que harán a continuación. ¿Por cuál de los métodos empiezo? ¿Uno solo es suficiente? La respuesta corta a esta última pregunta es “no”. Entonces, ¿qué debo saber para dar el salto de aquí hasta ágil? ¿De qué me “agarro” para no caer en el abismo? Estos son los asuntos que abordaré en esta sesión introductoria.

Con definiciones simples y ejemplificadas, basado en hechos históricos de los cuales he sido protagonista, le contaré a la audiencia de qué se trata toda esta jerigonza ágil, a manera de Gazafatonario.

La presentación completa la pueden descargar aquí:

Mañana empiezo un nuevo proyecto: ¿qué metodología ágil me pongo? de Luis Antonio Salazar Caraballo

#Agiles2014: Ágil es algo que eres, CMMI es algo que usas

ser ágil significa reemplazar la predictibilidad falsa por la eficiencia

Con una actualización debido al cambio de audiencia, presenté en #Agiles2014 mi disertación sobre Ágil y CMMI. Como en la versión 1.0, durante la SEPG LA 2014 en Manizales, mi asunto principal era que los métodos ágiles no tienen por qué entrar en conflicto con otros modelos o enfoques de construcción de software, no es la idea de ser ágil o, al menos, no está en el flujo de un proceso de transformación a ágil echar tierra a las prácticas existentes en una organización. Los líderes de los procesos actuales deben trabajar en conjunto con los nuevos líderes para que estos últimos obtengan los beneficios de ambos universos y aprovechar esa sinergia para mejorar dramáticamente el rendimiento del negocio.

Para apoyar este concepto, expliqué que los modelos como CMMI, PMI e ISO nos dan una idea de cuales procesos son necesarios para mantener una organización madura y disciplinada, capaz de predecir y mejorar el desempeño de la organización misma y de los proyectos. Entre tanto, las técnicas ágiles proporcionan guías para un manejo eficiente de los proyectos de una manera que permite alta flexibilidad y adaptabilidad. Al mezclar los dos enfoques, la filosofía ágil asegura que los procesos se implementen eficientemente a la vez que aceptan los cambios; y los modelos tradicionales aseguran que se consideren todos los procesos relevantes.

Pero de inmediato fui al centro de mi exposición: una de las grandes diferencias, radicales por demás, entre los métodos tradicionales y los ágiles es que estos últimos son generativos, no prescriptivos. Los procesos necesitan evolucionar según las necesidades, no prescritos con anticipación. Un enfoque prescriptivo genera procesos complejos y complicados, mientras que un enfoque generativo comienza con un conjunto de procesos simples y adiciona otros a medida que se requieren.

La filosofía ágil reconoce que los procesos de software más efectivos no pueden definirse por adelantado; es un proceso continuo. Los métodos tradicionales se enfocan en definir y reforzar procesos y gastan muy poco tiempo en identificar y entregar lo que los usuarios necesitan. Aunque su propósito es mejorar la consistencia y la calidad, esto muchas veces se consigue a expensas de la productividad y la entrega. El enfoque tradicional de procesos tipo CMMI también usa herramientas monolíticas y pesadas que causan construcciones frágiles y traspasos inefectivos entre desarrollo, pruebas, despliegue y operaciones.

Lo que siguió fue enfatizar en lo que significa ser ágil: específicamente, la interiorización y la práctica de los Valores y Principios del Manifiesto Ágil, nada alejado de lo que se habló en el resto de #Agiles2014.

Hacia el final quise poner mi propio manifiesto, el ‘Ágil es algo que eres…’, se trata de la persona, no de las cosas ni de los procesos. Ya lo he dicho en otras oportunidades, ser ágil significa reemplazar la predictibilidad falsa por la eficiencia.

Para descargar la presentación

Puedes descargar las memorias de esta conferencia de: http://goo.gl/rhNMcf

Por qué usar métodos + prácticas ágiles

Anualmente, la consultora VersionOne.com publica un estudio sobre el uso de metodologías y prácticas ágiles. Este año, el estudio llegó a su octava edición. El estudio dice, por ejemplo, que Scrum es el método más ampliamente usado en el ecosistema ágil y así ha sido en los últimos 8 años, mismos en los cuales se ha incrementado su uso desde un 40% hasta el 55% de este año. Además, otros sabores de Scrum, combinados con métodos o prácticas como XP y Kanban también son bastante usados. Es un hecho, Scrum está aquí para quedarse.

Fuente: VersionOne.com. 8th Annual State of Agile Survey

Pero quiero referirme es a las principales razones por las cuales se usa Ágil. El estudio dice en esta sección que los 3 motivos primordiales que dieron los participantes de la encuesta son:

• Acelera la salida del producto al mercado: 23%
• Maneja más fácilmente los cambios en las prioridades: 16% y
• Mejora la alineación del negocio y de la IT: 15%

Fuente: VersionOne.com. 8th Annual State of Agile Survey

El 75% de los encuestados considera que es muy importante o de la más alta importancia el que los métodos ágiles aceleren la salida del producto al mercado. Este es el principal beneficio de usar prácticas y metodologías ágiles. Las salidas “tempranas” se logran construyendo el producto de manera orgánica, en iteraciones cortas de 4 semanas o menos, con preferencia al tiempo más corto posible. Y si bien es cierto que es posible no salir a producción al final de cada iteración, siempre debemos planear para que haya entregas a Operación cada muy pocas iteraciones.

Los equipos ágiles no congelan las prioridades ni las firman con sangre. Es el usuario (por ejemplo, el Dueño de Producto en Scrum), quien establece qué quiere ver primero y qué quiere ver más adelante. En consistencia con el aspecto anterior, es el usuario quien tiene la última palabra en el orden de prioridad conque el mercado llega al mercado o a los usuarios finales. Se trata además, de software con valor, recordemos que en Ágil todo es acerca de entrega de valor al negocio.

En ese mismo orden de ideas, la alineación de la IT con los objetivos del negocio siempre ha sido uno de los pilares de los métodos ágiles, de hecho, tiene sus cimientos en aquel valor del Manifiesto Ágil de Colaboración con el cliente sobre la negociación contractual. Recordemos también que los desarrolladores y el negocio trabajamos juntos cotidianamente durante todo el proyecto, o así reza uno de los principios del Manifiesto. El 65% de los encuestados respondió que esta razón es muy importante o de la más alta importancia para ellos a la hora de hace uso de las metodologías ágiles.

El estudio completo lo encuentran en versionone.com.

Scrum Orgánico para Iniciantes

Advertencia: al final de este artículo podrás empezar a usar Scrum en tus proyectos.

Marco de Trabajo Scrum

Presentación

Cuando publiqué la lista de chequeo de Scrum, asumí que mis lectores ya conocían este marco de trabajo (para software o productos y servicios de otro tipo) o que estarían familiarizados con el concepto de prácticas y técnicas ágiles y que conocían el suficientemente expuesto manifiesto ágil. Pensé que  no hacía falta abordar los aspectos más básicos del asunto. Me equivoqué. Acaso para algunos de nosotros esta sea la primera vez con Scrum, el primer contacto con un marco de trabajo ágil, la primera incursión en esta forma de construir productos de software. Así es que decidí volver a lo fundamental. Aquí vamos otra vez.

Scrum es un marco de trabajo liviano e iterativo de gestión de proyectos que ayuda a los equipos a ejecutar y a entregar exitosamente el valor de negocio más alto en el tiempo más corto posible. Este método es particularmente bien apropiado para entornos donde los requisitos están sujetos a cambios continuos o donde los requisitos no se entienden correctamente. “Scrum es un marco de trabajo con el cual podemos afrontar problemas complejos y adaptativos y con el cual podemos emplear distintos procesos y técnicas, así como también podemos optimizar nuestra predictibilidad y tener un mejor control de los riesgos”[i].

Métodos Ágiles

Pero Scrum no es el único método ágil que podemos encontrar. Algunos otros marcos de trabajo ágil son:

·         Adaptive Software Development (ASD)

·         Crystal Clear

·         Kanban
·         Extreme Programming (XP)
·         Dynamic System Development Method (DSDM)

·         Feature Driven Development (FDD)

·         Lean Software Development (LSD)

·         Open Unified Process (OpenUP)

·         Essential unified process (ESSUP)

·         Agile Unified Process (AUP)

·         Use Case 2.0

La Filosofía Ágil

Todos estos métodos tienen sus cimientos en lo que se conoce como Filosofía Ágil:

·         Usted no puede predecir o planear con absoluta certeza lo que va a entregar, cuándo lo entregará y cuánto será su costo.

·         Empiece con planes iniciales alrededor de las estimaciones, fechas y alcance, pero enfóquese en la revisión continua de estas restricciones a medida que avanza.

·         La meta es entregar el mejor software posible, dadas estas restricciones, pero ningún método con el enfoque de receta de cocina mejorará lo que es “mejor”.

Scrum

Scrum define explícitamente tres roles, cuatro ceremonias y cuatro artefactos principales. El Dueño del Producto, el Equipo de Desarrollo y el Scrum Master son quienes tienen bajo su responsabilidad entregar software probado y funcionando cada cuatro semanas o menos. Todos ellos forman el Equipo Scrum que, además de las actividades regulares de desarrollo de software, realiza cuatro ritos durante cada iteración que en Scrum se llama Sprint: Planificación del Sprint, Reunión Diaria, Revisión del Sprint y Retrospectiva. Durante estas ceremonias, el equipo actualiza la Lista (Backlog) del Producto, la Lista de Pendientes (Backlog) del Sprint y la Lista de Impedimentos; y al final entrega un incremento del producto potencialmente distribuible.

Actores en Scrum

El Dueño del Producto es la persona encargada de maximizar el valor del producto elaborado por el equipo de desarrollo. Es quien define y prioriza los ítems de la bitácora de producto y quien proporciona al equipo todo el conocimiento del negocio necesario para que este sea transformado en software. Entre tanto, el Equipo de Desarrollo es el responsable de construir el producto, teniendo en cuenta las necesidades y prioridades del dueño del producto. En Scrum no existen roles especializados, es simplemente el equipo, comprometido todo con el éxito del proyecto.

Finalmente, el Scrum Master es un servidor, es quien vela porque se ejecute el proceso como está definido y que se lleven a cabo cada una de las ceremonias Scrum como está consignado en la Guía de Scrum. También es el encargado de introducir nuevas prácticas al proceso y al proyecto, acompañando de cerca su implantación y monitoreando los resultados. Es importante aclarar que el Scrum Master no es un gerente, aunque bien podríamos decir que hace parte de y reporta al área de manejo de la organización, por ejemplo, a la oficina de proyectos. Contando el SM, el equipo Scrum no debe superar las 9 personas.

Ceremonias y Artefactos Scrum

En un proyecto gestionado bajo el manto de Scrum, todo ocurre en el marco de un Sprint: este es una iteración de un tiempo máximo de 4 semanas. La industria del software está gritando a cielo abierto que este tiempo sea de solo 2 semanas o de menor duración. Al principio del Sprint se realiza la Planificación del Sprint. En esta reunión, el dueño del producto asiste con la Lista del Producto actualizada y priorizada, de acuerdo con las necesidades del negocio. Junto con el equipo de trabajo, se seleccionan algunos de los elementos de la lista, usualmente los de mayor valor para el negocio, para ser desarrollados durante la iteración.

Con estos elementos seleccionados se conforma lo que se llama la Lista de Pendientes del Sprint, el trabajo del sprint. A continuación, el equipo de desarrollo define cómo hará el desarrollo y estima el esfuerzo necesario para cada uno de los elementos seleccionados, teniendo en cuenta que el esfuerzo máximo es el definido para el sprint, ni un minuto más. Con estas premisas, el Equipo en pleno elabora la Definición de Terminado y se asegura que todo el mundo la entienda y la comparta. Esta “definición de Terminado” se convierte en una especie de “contrato” del sprint, define las cláusulas sine qua non el incremento del producto no satisface a su dueño ni a la organización.

Con la definición de Terminado en la mente de los miembros del equipo Scrum, este inicia el ciclo de vida del software. Todos los días, a la misma hora y en el mismo lugar, de pie y durante 15 minutos máximo, el equipo se congrega en la Reunión Diaria. En esta sesión, cada integrante del equipo responde tres preguntas: ¿qué hice ayer? ¿Qué haré hoy? Y ¿Qué problemas tengo? Solo tres y nada más que tres. Esta reunión no es para saludarse ni para hablar de asuntos que no estén relacionados con el proyecto o con las personas que lo ejecutan. Tampoco es para resolver los problemas expuestos.

De la reunión diaria sale actualizada la Lista de Impedimentos, la cual es tratada fuera de la reunión, por cada uno de los responsables de solucionarlos. En Scrum, el equipo es autogestionado, multidisciplinario y debería tener la capacidad de resolver sus propios problemas sin la ayuda de alguien externo. Hacia el final de la iteración, se realiza la Revisión del Sprint. En esta sesión, el equipo Scrum y los interesados realizan un escrutinio de lo que se hizo en el sprint y ajustan la lista del producto si fuese necesario. En definitiva, el dueño del Producto verifica que se haya cumplido la Definición de Terminado.

Justo a continuación de la revisión, se hace una Retrospectiva del Sprint: ¿Qué hicimos mal que no repetiremos? ¿Por qué no se alcanzó la Definición de Terminado? ¿Qué hicimos bien que podemos mejorar? ¿Qué hicimos bien que seguiremos haciendo tal cual? Estas son algunas de las cuestiones que, con ayuda del Scrum Master, se responden en esta reunión. En esta sesión también deberíamos separar unos instantes para realizar una introspectiva: ¿Cómo está nuestro estado de ánimo? ¿Seguimos? ¿Paramos? Si seguimos, ¿qué acciones de mejoramiento podemos introducir a partir del siguiente Sprint?

Conclusión

Estos son, grosso modo, los elementos que subyacen el método Scrum. Todas las ceremonias tardan un tiempo fijo definido en el libro de reglas de Scrum o Guía de Scrum. No hay que saber nada más para comenzar a usar el marco de trabajo. Y para usarlo hay que ser ágil, porque Ágil es algo que eres, no algo que haces. Una vez que puedes diferenciar esto, entonces convertirse en ágil será algo fácil. Extrapolando, una organización no puede forzar la filosofía ágil en su cultura, sino que debe permitir que su cultura evolucione hacia un estado ágil. Ágil es un estado de la mente, es una forma de pensar y de ver las cosas.

Se me olvidaba decirles, la retrospectiva siempre debe hacerse al final de cada sprint, a menos que el equipo esté bien ocupado. En cuyo caso, se deberían hacer dos.

Lecturas Adicionales

Mi artículo de Scrum Fundamental lo encuentran en este mismo Gazafatonario, en: http://www.gazafatonarioit.com/2013/05/scrum-lo-fundamental.html.

El libro de reglas de Scrum, la guía de Scrum, lo encuentran en:

http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide%202011%20-%20ES.pdf#zoom=100.

La lista de verificación de Scrum que desató esta serie de artículos  la encuentran en: http://www.gazafatonarioit.com/2013/05/lista-de-chequeo-scrum.html.

Otros sitios que pueden visitar para aprender más de Scrum y libros que pueden leer son:

http://www.scrum.org/scrumguides

http://www.scrumalliance.org

http://www.mountaingoatsoftware.com/

http://scrum.jeffsutherland.com/

http://www.controlchaos.com/

http://americalatina.pmi.org/latam/CertificationsAndCredentials/PMI-ACP/PMI-ACPExamPreparation/MaterialsAndResourcesInAgile.aspx

Essential Scrum: A Practical Guide to the Most Popular Agile Process. Mike Cohn.

Succeeding with Agile: Software Development Using Scrum. Mike Cohn.

Agile Project Management with Scrum (Microsoft Professional). Ken Schwaber.

Agile Product Management with Scrum: Creating Products that Customers Love. Roman Pichler.

Professional Scrum Development with Microsoft® Visual Studio® 2012. Richard Hundhausen.

User Stories Applied: For Agile Software Development. Mike Cohn.

---

[i] La Guía de Scrum. © 1991-2011 Ken Schwaber y Jeff Sutherland, Todos los Derechos Reservados.

Casos de Abuso, Parte 11: Cada caso de uso se diseña e implementa de manera independiente

El diseñador y el desarrollador sólo ven el caso de uso en desarrollo sin importarles el sistema como un todo.  Cuando esto se hace así, y no por paquetes relacionados, corremos el riesgo de no armar el “rompecabezas” con facilidad al final de la operación.

Y lo que es peor, muchas veces durante el diseño e implementación del caso de uso no tenemos en cuenta los lineamientos arquitectónicos impuestos a la solución. El producto termina siendo una colcha de retazos mal cosidos. Esta situación convierte los hitos de integración del producto, iteración tras iteración, fase tras fase, en un serio dolor de cabeza para el arquitecto, los diseñadores y los mismos programadores. Entonces surgen los reprocesos, el desperdicio de código, rediseños, y el resultado final: un producto de mala calidad.

El tratamiento: la arquitectura del software. Una que sirva como una gran lista de chequeo para los diseñadores y para los implementadores del producto. La arquitectura de software es la organización fundamental de un sistema, formado por sus componentes, las relaciones entre ellos mismos y con el entorno, y los principios que gobiernan su diseño y evolución (IEEE 1471-2000). Según Booch, Kruchten y otros, la Arquitectura de Software incluye decisiones acerca de la organización de un sistema de software como:

·         La selección de los elementos estructurales que componen el sistema y sus interfaces

·         El comportamiento del sistema, especificado en las colaboraciones entre esos elementos

·         La composición de estos elementos estructurales y comportacionales en subsistemas más grandes

·         El estilo arquitectónico que guía esta organización

Toda arquitectura de software comienza por una arquitectura funcional o vista de casos de uso, un subconjunto del modelo de casos de uso del sistema, compuesto a su vez por los así llamados casos de uso o requisitos arquitectónicos. Después están la vista lógica, que le habla a los analistas y diseñadores sobre la estructura del software. La vista de implementación, que les cuenta a los programadores detalles sobre el manejo del software. Por su parte, la vista de procesos habla de desempeño, escalabilidad y puesta en marcha a los integradores del sistema. Y también está la vista de despliegue que nos explica de manera lacónica la topología del sistema, aspectos de la entrega del mismo, de instalación y de comunicación subyacentes.

El diseño y la implementación de todo el producto de software debe obedecer a estas restricciones, casi leyes, impuestas por la arquitectura así descrita. Es lo que hace posible que los casos de uso se diseñen en grupos heterogéneos de paquetes o subsistemas diferentes.

Impacto en la calidad: Alto.

PD. Para saber sobre Arquitectura de Software, específicamente sobre el modelo de las 4 + 1 vistas expuesto por Krutchen, pueden tener en cuenta la siguiente referencia:

P.B. Kruchten, “The 4 + 1 View Model of Architecture,” IEEE Software, pp. 42–50, Nov. 1995. http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&arnumber=469759&isnumber=9910

También la encuentran en:

http://www.softwarearchitectures.com/library/resources/Kruchten4+1.pdf

Además, sobre análisis y diseño de casos de uso, en particular, sobre realización de casos de uso, pueden visitar mi Lectura Fundamental 10:

Lectura # 10: Realización de Casos de Uso: De los Objetos y sus Interacciones

http://gazafatonarioit.blogspot.com/2007/10/lecturas-fundamentales-10-lectura_3046.html

Y sobre programación orientada a objetos, pueden leer mi Lectura Fundamental 11: Orientación a Objetos: Un Enfoque Teórico Moderno (Actualizado)

http://gazafatonarioit.blogspot.com/2007/11/lectura-fundamental-anterior-realizacin.html

¡Quiero una Porción de Caso de Uso!

No se trata de una charada ni nada por el estilo. El concepto fundamental de Casos de Uso 2.0 (como fue expuesta por Ivar Jacobson en su eBook “Use Case 2.0 The Definitive Guide”), es el de caso de uso y con este, el de “porción de caso de uso” (Use Case Slide, en inglés).

Ya sabemos ampliamente qué es un caso de uso y que todos los casos de uso de un sistema constituyen todos los posibles caminos que un usuario puede tomar para usar el sistema. Un caso de uso tiene una meta bien establecida, una estructura de historia entendida por todos los involucrados en el proyecto, pero también un conjunto de historias que el sistema debe satisfacer o cumplir, incluyendo la más simple, la cual es la historia más simple que le permite al usuario alcanzar la meta.

Y todo esto se puede lograr implementando cada caso de uso porción por porción. Así que ¿qué es una porción de caso de uso? Una porción de caso de uso es una o más historias seleccionadas de un caso de uso para formar un elemento de trabajo que es de valor claro para el usuario. La porción actúa como un contenedor para todo el trabajo requerido para completar la implementación de las historias seleccionadas. Las porciones de casos de uso son más que requisitos y casos de prueba y evolucionan para incluir las porciones correspondientes a través del diseño, la implementación y las pruebas.

La porción de caso de uso es la parte más importante de Casos de Uso 2.0 y no es solamente usada para ayudar con los requisitos sino también para conducir el desarrollo de un sistema que los solucione. Las porciones de caso de uso:

·         Posibilitan que los casos de uso sean divididos en unidades de trabajo más pequeñas e independientemente entregables.

·         Posibilitan que los requisitos contenidos en un conjunto de casos de uso sean ordenados, priorizados y tratados en paralelo.

·         Enlazan los distintos modelos de un sistema (requisitos, análisis, diseño, implementación y pruebas) usados en el desarrollo dirigido por casos de uso.

Por ejemplo, en un caso de uso cuyo propósito es que un cliente de un banco retire dinero vía cajeros electrónicos (ATM), una porción básica del caso de uso es aquella en la que el cliente inserta su tarjeta débito, proporciona los datos de su pin y la cantidad a retirar y la máquina le entrega la cantidad solicitada. Otra porción puede ser aquella en la que el pin no concuerda con los datos de la tarjeta, otra porción es cuando el cliente no tiene fondos suficientes, otra es cuando el cliente ingresa varias veces el pin de manera incorrecta y el sistema bloquea la tarjeta. Y así, puede haber muchas porciones de caso de uso en un caso de uso relativamente simple.

Así que ¿de qué sabor quieres tu porción de caso de uso?

PD. Sobre casos de uso, los invito a leer las Lecturas Fundamentales de este Gazafatonario IT. http://gazafatonarioit.blogspot.com/2006/11/lecturas-fundamentales.html.

Sobre casos de uso 2.0, pueden ver mi artículo en:

http://gazafatonarioit.blogspot.com/2012/04/casos-de-uso-20.html

Y este otro:

http://gazafatonarioit.blogspot.com/2012/04/casos-de-uso-20-y-metodos-agiles.html

Casos de Uso 2.0 y Métodos Ágiles

Quienes ven un sabor “ágil” en la práctica Casos de Uso 2.0, como la expone Jacobson, no se equivocan. Esta es una práctica escalable y ágil que puede ser usada junto a prácticas administrativas y técnicas seleccionadas para apoyar el desarrollo exitoso de software y otras formas de sistemas. Su primera característica es que es una práctica liviana y fácil de usar. De hecho, los autores comienzan diciendo que la guía (se refieren al eBook Use Case 2.0 - Guía Definitiva), describe como aplicar casos de uso de una manera “ágil” y escalable. Y estos dos conceptos se extienden a lo largo de cada una de las páginas del documento.

El concepto de “incrementos” y de “historias de usuario”, generalizado en toda la práctica, es inherente a los métodos ágiles como Scrum. De hecho Casos de Uso 2.0 hace referencia a técnicas como el de “Backlog del producto” también usada en los Sprints o iteraciones de Scrum. el backlog (Product Backlog en Scrum) se crea con casos de uso, historias de usuario y porciones de casos de uso, o una combinación de todas estas.

Pero también es importante aclarar que esta técnica no es una franquicia solo para estrategias ágiles. También puede ser usada con otros métodos o procesos como RUP o MSF. La práctica “no es solo aplicable a pequeños equipos ágiles ubicados en una misma oficina, sino que también es para grandes equipos distribuidos que desarrollan de multi-sistemas complejos.” 

Para precisar mi punto quiero referirme al “principio 5: Entregar el sistema en incrementos”, del que habla la guía en el primer capítulo.

En este apartado, los metodólogos enfatizan que “la mayoría de los sistemas de software evolucionan a través de muchas generaciones. Estos no son producidos de una sola vez, sino que son construidos como una serie de versiones, cada una de las cuales es implementada sobre la anterior. Aun las versiones mismas no son producidas de un solo tirón, sino que evolucionan a través de una serie de incrementos. Cada incremento arroja una versión demostrable o usable del sistema. Cada incremento se construye sobre el incremento previo para adicionar más funcionalidad o mejorar la calidad de lo que se ha hecho antes. Esta es la forma en que todos los sistemas deberían ser producidos.”

Más adelante remarcan: “Las porciones de casos de uso son una herramienta fabulosa para construir incrementos más pequeños en forma de una versión completa. Esta herramienta permite apuntar independientemente a porciones implementables y verificables de los incrementos, asegurando que cada incremento sea más grande que, y esté construido sobre, el anterior.” El concepto es a todas luces aplicable tanto a los métodos ágiles como a los no ágiles.

PD. Para quienes entran tarde a la sintonía, estoy extendiendo el tema de Casos de Uso 2.0, que inicié hace algunos días en otra entrada. Lo pueden encontrar en http://gazafatonarioit.blogspot.com/2012/04/casos-de-uso-20.html