Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta incrementos. Mostrar todas las entradas
Mostrando las entradas con la etiqueta incrementos. Mostrar todas las entradas

martes, noviembre 11, 2014

Á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:


Publicado con permiso del autor.

miércoles, noviembre 05, 2014

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

 Ecosistema de Métodos y Prácticas Ágiles (Parcial)
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í:




miércoles, febrero 06, 2013

Todavía Otra Lección Más Sobre Porciones de Casos de Uso


Ya sabemos que Casos de Uso 2.0 es una práctica escalable y ágil que usa casos de uso y porciones de casos de uso para conducir el desarrollo incremental de sistemas de software. Sabemos que cualquier tipo de equipo de desarrollo lo puede usar, desde uno pequeño y local hasta uno grande y distribuido en varias locaciones,  en cualquier tipo de esfuerzo de desarrollo, desde la construcción de productos nuevos y simples hasta la elaboración de productos complejos o multisistemas, con cualquier enfoque metodológico, desde la tradicional cascada, hasta enfoques conducidos por bitácora de requisitos.
También sabemos que la porción de caso de uso es el elemento más importante de Casos de Uso 2.0. Una porción de casos de uso nos permite construir los sistemas de manera incremental, por partes, conduciendo todo el esfuerzo, desde el análisis del caso de uso, de una o varias porciones del mismo, pasando por el diseño de la porción, es decir, la realización del caso de uso (de la porción), para luego ir a la implementación de la porción, hasta someter el software a la verificación vía casos (scripts) de prueba; todo, en un ciclo corto de desarrollo, por ejemplo, una iteración de dos semanas o de un mes calendario.
Las porciones están compuestas de historias y de sus casos de prueba asociados, es decir, hay una sindicación entre las historias de un caso de uso y los casos de prueba que son las que finalmente verificarán que la porción del caso de uso está bien construida y satisface las necesidades del usuario. Esta compilación de historias y de casos de prueba tiene un valor claro que es entendido y acordado por los usuarios y los demás interesados en el producto. Por ejemplo, la siguiente figura muestra un caso de uso típico de un sistema de publicación de un periódico digital, con sus atributos más relevantes, y algunas de sus porciones, que podrían implementarse en una iteración.

Propiedades de un Caso de Uso y de algunas de sus Porciones en notas Post-it.
(Haga clic en la imagen para ampliarla)

Esta imagen, que muestra un tablero “repleto” de notas post-it, donde cada nota muestra el caso de uso con sus propiedades o la información destacada de cada una de sus porciones. En estas últimas, vemos un identificador de la porción (número y descripción), los flujos del caso de uso que forman la porción, es decir, las historias, donde FB es Flujo Básico, y A1, A2, etc., son las secuencias alternativas del caso de uso. Y también encontramos los casos de prueba, estos son los escenarios que finalmente comprobarán que la implementación de la porción fue exitosa.

No es necesario que estén todos los casos de prueba para verificar la porción, en términos generales, una historia y un caso de prueba serán suficientes para tener algo de valor para el usuario y empezar a entregar el sistema mediante incrementos. Finalmente, los números grandes en la esquina inferior derecha de cada nota post-it representan el esfuerzo que toma implementar esa porción. Es un estimado que puede realizarse con cualquiera de las técnicas habituales de estimación: puntos de historia, juicio de expertos, la estimación de Fibonacci, etc. Lo bueno de las estimaciones es que no tienen que ser exactas la primera vez, por eso se llaman estimaciones. ¡Si solo entendiéramos eso!

Un Ejemplo de Porciones de Casos de Uso

Con todo esto en mente, veamos un ejemplo característico de una de las actividades principales que incluye Casos de Uso 2.0: Preparar una porción de caso de uso. Si usamos el enfoque iterativo y una bitácora de requisitos, podemos dividir las tareas en dos grandes grupos:
  1.    Tareas antes del desarrollo
  2.    Tareas en cada iteración

En el primer grupo, Casos de Uso 2.0 propone las actividades típicas de Encontrar Actores y Casos de Uso, para conocer el “cuadro” completo, es decir, tener una visión de lo que será el sistema de software; pero a continuación, Casos de Uso 2.0 incluye la práctica de Dividir los Casos de Uso y la de Preparar una Porción de Caso de Uso. Entre tanto, las tareas del segundo grupo se muestran en la figura a continuación:

Actividades de Caso de Uso 2.0 para Enfoques de Desarrollo Iterativos
Fuente: Libro-e Use Case 2. 0 Jacobson y otros.
(Haga clic en la imagen para ampliarla)

En el caso de los actores y casos de uso, la figura siguiente muestra un subconjunto del modelo de un sistema de publicación de un periódico digital. Nómina y Facturación son dos ejemplos de actores que no son personas, son sistemas de software, externos al sistema que se está construyendo. Por su lado, Editor, Periodista, Bloguero y Lector, representan actores persona, grupos de usuario del software. Cada uno de estos tiene asociados uno o más casos de uso.

Diagrama (parcial) de Casos de Uso de un Sistema de Publicación de un Periódico Digital
(Haga clic en la imagen para ampliarla)
Para ilustrar el ejemplo de las porciones, tomemos el caso de uso Comprar Artículo, ejecutado por el Lector del periódico. A continuación muestro la narrativa del caso de uso.

Narrativa del caso de uso Comprar Artículos de un sistema de información de publicación de un periódico digital
(Haga clic en la imagen para ampliarla)
Lo que sigue es encontrar algunas de las historias del caso de uso con las que podamos iniciar el desarrollo, no de todo el caso de uso, pero sí de algunas de sus partes que tengan valor claro y entendido para el usuario.


Algunas historias del caso de uso Comprar Artículos del Sistema de publicación digital
(Haga clic en la imagen para ampliarla)
Notamos que algunos de los flujos están definidos explícitamente en la narrativa del caso de uso, mientras que otros como el A8 y el A9 no lo están. Estos cabrían dentro del grupo “etcétera” de la narrativa. Observamos también que el flujo básico es suficiente para tener una historia con sentido completo, de valor para el usuario. A esta historia le podemos “sumar” uno o más casos de prueba y estamos listos para construir una pequeña parte del software que tiene un peso bien definido para los usuarios.

Algunas porciones del caso de uso Comprar Artículos del Sistema de publicación digital
(Haga clic en la imagen para ampliarla)
En este cuadro vemos algunas de estas porciones para el caso de uso Comprar Artículos. Esto completa el trabajo de dividir el caso de uso. A continuación, preparamos la porción, digamos la primera de ellas, hacemos una estimación del esfuerzo que nos tomará someterla al resto del ciclo de vida durante una iteración y seguimos con el proceso: diseño (realización), implementación y verificación y, finalmente, demostración del producto (parcial) a los usuarios.
Conclusión
En el pasado hemos visto como un caso de uso puede llegar a ser lo suficientemente grande y complejo como para que se pueda implementar en una iteración corta. Las porciones de casos de uso proporcionan el medio y la coherencia de artilugios de las metodologías ágiles, como las historias de usuario, con el poder del modelado de los casos de uso para que no perdamos de vista el alcance completo del producto de software que estamos construyendo, permitiendo fabricar en un ciclo corto (una iteración de muy pocas semanas a un mes) una parte del producto que tiene valor significativo para los usuarios.
De esta manera es posible, por ejemplo, usar la práctica de Casos de Uso 2.0 con un marco de trabajo ágil como Scrum o con otros enfoques como AUP u otras metodologías livianas. Pero de este asunto hablaremos en los próximos días, cuando les presente La Esencia de la Ingeniería de Software.
Nota:
Esta entrada se puede descargar como artículo para su libre distribución, haciendo clic en:


martes, octubre 02, 2012

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:
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:
Y sobre programación orientada a objetos, pueden leer mi Lectura Fundamental 11: Orientación a Objetos: Un Enfoque Teórico Moderno (Actualizado)

domingo, septiembre 30, 2012

Casos de Abuso, Parte 10: Los flujos de eventos en los casos de uso son escritos en pseudocódigo


Este es el que yo llamo “síndrome del programador que se volvió analista”, algo así como el hombre-lobo del proceso de desarrollo de software. Creo que todos los que hemos recorrido este largo pero tortuoso laberinto que significa el ciclo de vida del desarrollo de software hemos experimentado, al menos, una o más de esas manifestaciones “fenomenoides” del universo informático. Además, este abuso es primo del abuso 5, donde usamos detalles técnicos en la documentación del caso de uso.
El antídoto es sencillo: un caso de uso siempre, sin ninguna excepción, se escribe en terminología del negocio, con las palabras que usa el usuario en sus actividades diarias. Si esto no es posible, quizás no estamos ante un caso de uso.
Nada de incluir expresiones como: “si ocurre esto entonces hacer aquello”, en cambio usar distintas secuencias o flujos alternos; o “mientras se cumpla una condición, realizar estas acciones”, en vez de ello, describir el conjunto de acciones para un elemento-sujeto de la condición y en los requisitos especiales del caso de uso dejar de manifiesto que puede haber uno o más elementos para esa condición. Y mucho menos usar nombres de “variables”, ciclos for o while o selección múltiple. Lo único que lograremos con ello es confundir a los usuarios.
Veamos con un caso de uso algo escueto un ejemplo típico:
Caso de uso: Retirar fondos
Actor: Cliente
Secuencia Básica:
1.    El caso de uso inicia cuando el cliente decide retirar dinero en efectivo de un cajero automático
2.    El sistema solicita la cantidad de dinero a retirar
3.    El Cliente ingresa la cantidad de dinero a retirar
4.    El sistema verifica el saldo del Cliente
5.    Si el Saldo del Cliente es mayor que o igual a la cantidad a retirar, el cajero entrega el dinero. De lo contrario, muestra el mensaje “Fondos insuficientes”
6.    El caso de uso termina
Los pasos 4 y 5 de este caso de uso son una muestra de lo que no se debe hacer al documentar requisitos. En cambio, podríamos decir:
4.    El sistema verifica que el Cliente tiene saldo suficiente en su cuenta y entrega el dinero.
5.    El caso de uso termina
Para el caso de falta de fondos, escribimos una secuencia alternativa. Esta estrategia además posibilita una implementación más rápida y “limpia” del caso de uso y permite al equipo de pruebas tener mayor visibilidad de los escenarios para verificar el software.
Impacto en la calidad: Alto.

PD. Para saber más de sobre casos de uso, abecés, anatomía, prácticas y requisitos en general, puedes visitar mi Sección Lecturas Fundamentales en mi Gazafatonario IT.

lunes, abril 16, 2012

¡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:
Y este otro:

lunes, abril 09, 2012

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