Buscar en Gazafatonario IT

jueves, febrero 01, 2018

Diferencias en el tratamiento de los requisitos entre los enfoques Cascada y Ágil


¡Una pregunta de un viejo amigo me llevó una vez más por este sendero!
Es un hecho. Muchos profesionales trabajan actualmente en circunstancias desafortunadas y, sin embargo, no toman la iniciativa de cambiar su situación porque están condicionados a un formato de seguridad, conformidad y conservación, donde todo puede parecer tranquilo pero, en realidad, nada es más perjudicial para el espíritu innovador y de transformación que requerimos hoy quienes vivimos en los tiempos del VUCA*.
En particular, durante la transición de un enfoque en cascada a uno Ágil tenemos que lidiar con la búsqueda de medios y maneras para acortar el tiempo de salida al mercado y entregar productos de alta calidad y de más valor, más temprano y más frecuente y, si es posible, a un costo menor. Sin embargo, el camino hacia la Agilidad puede ser escabroso, con baches riesgosos y con personas deambulando por allí erráticamente y hasta en dirección opuesta, incluso con temor a o sin saber cómo avanzar.
Y uno de los aspectos que empiezan a diferenciar en profundidad el uso de uno u otro enfoque es este de los requisitos. Abordamos este asunto con Carlos Gil, Johnny Ordoñez, Carlos Quiroga, Luis Mulato y el grandioso equipo de coaches del Scrum Coaching Retreat Cartagena y, como siempre, llegamos a algunas conclusiones que se mueven en el terreno de los principios y, más en el fondo, de los valores Ágiles, la cultura ágil, el Ágil es algo que eres:

  • En Ágil no hablamos de requisitos, más bien de respuestas a necesidades y, en otros casos, de hipótesis de cosas que queremos aprender. Cambiar el enfoque de “requisito” a “necesidad” o respuesta a necesidad, genera un sentido profundo de empatía entre todos los interesados, es decir, equipo de desarrollo de producto y usuarios o clientes finales.
  • A propósito de clientes finales, en Ágil, el cliente siempre es el centro de atención. Esto habilita a los equipos a buscar las mejores formas de suplir esa necesidad o de comprobar las hipótesis. Estas en últimas son necesidades de aprendizaje.
  • Creemos que esta es la distinción más grande entre las dos propuestas: el requisito te lleva a algo preestablecido, definitivo o definible claramente. Hablar de necesidades o de hipótesis abre la puesta al cambio.
  • En el enfoque Cascada se definen experiencias orientadas al proceso, con momentos de interacción preconcebidos por los formularios y procesos definidos en los requisitos, y aun hablamos de interacciones y no de conversaciones con las soluciones tecnológicas. En Ágil, aspectos como la experiencia de usuario, momentos de verdad, conversaciones, son esenciales para la definición de la historia de usuario que guía el desarrollo de producto.
Vamos con las disparidades entre uno y otro enfoque cuando de requisitos se trata
Son muchas las diferencias que existen en la forma de abordar los requisitos de un producto cuando usamos (o usábamos) la forma Cascada y lo que hacemos ahora, motivados por el pensamiento Ágil. Estas que describo a continuación son apenas algunas de ellas, algunas más relevantes que otras pero significativas todas al fin y al cabo.
Al principio del proyecto o del esfuerzo de desarrollo

En Cascada se toman o "levantan" (casi) la totalidad de los requisitos y de muchos de ellos se toma en gran detalle. En Ágil no. Se establece un alcance, sí, una visión, pero de muy alto nivel, muy horizontal, es decir, no se llega a ningún detalle excepto quizás para esas necesidades de los dos primeros Sprint (a lo sumo), la porción de producto que se va a construir durante las primeras de cambio. El llamado Mínimo (o Minimísimo) Producto Viable.
En Cascada nos tardamos semanas y hasta meses haciendo esta primera actividad. En Ágil nos tardamos unas pocas horas, a lo sumo unos pocos días, se establece un bloque de tiempo (time-box) y cuando este se acaba, se acaba.
En Cascada participa una persona del lado del equipo de desarrollo o un "subequipo", el o los analistas funcionales o de requisitos. Quizás en algún momento entra uno que otro rol, como el Arquitecto de Software. En cualquier caso, no participa todo el equipo. En Ágil participa todo el equipo de desarrollo desde el inicio, escuchando a los usuarios e interesados en el producto.
Más adelante, cuando el proyecto está en marcha
En Cascada se refinan los requisitos, hay ajustes, controles de cambios. El sobrevaluado CCC (léase Comité de Control de Cambios que se reúne el último jueves de cada mes, mientras el cliente ve impaciente cómo su competencia se adelanta y le quita parte del mercado. Mientras tanto, en Ágil se van refinando los requisitos iteración tras iteración. Siempre nos concentramos en lo que se va a construir en los siguientes 2 sprints o iteraciones, a lo sumo. Más tiempo no, porque las cosas pueden cambiar. Los equipos Ágiles aprovechamos los cambios para brindar ventaja competitiva a nuestros clientes.
En Cascada los requisitos siempre los "administra" una persona o un subequipo (analistas), con los usuarios. En Ágil hay un Dueño de Producto (representante de los usuarios), pero la responsabilidad es de todo el equipo.
En Cascada los requisitos se construyen, como sabemos, siguiendo un proceso secuencial donde ellos se tratan aparte y son una entrada al resto de ese proceso; además, el producto se entrega como un todo. En Ágil se construye un incremento del producto en cada iteración (de muy pocos días), esto es, producto probado y funcionando con valor, potencialmente desplegable y que genera retorno de la inversión (ROI) o, al menos, permite recibir retroalimentación, con lo que podemos aprender muchísimo del comportamiento y de la reacción de los usuarios al uso del producto.
En Cascada normalmente el orden de construcción lo decide el equipo de desarrollo (quizás en cabeza de un arquitecto o un subequipo). En Ágil el orden de construcción lo decide el usuario (dueño de producto), es él quien tiene la última palabra sobre esto.
En Cascada, el énfasis en cuanto a requisitos está en la especificación (documentación) de los mismos, en otras palabras, en escribir y escribir requisitos. En Ágil, el énfasis está en la conversación que tienen los usuarios o su representante (dueño de producto) con el equipo de desarrollo. Esta conversación es cara a cara y continua, durante todo el proyecto o esfuerzo de desarrollo.
Esta última característica es lo que nos empieza a volver ágiles, cuando lo logramos nos damos cuenta que estamos usando el pensamiento Ágil y estamos dejando atrás la cascada y otras formas tradicionales de trabajo.
En Cascada se espera que prácticas de aseguramiento de calidad permitan que se entregue un producto que cumpla con casos de prueba previamente definidos y aprobados con el área de negocio. En Ágil damos espacios a prácticas como TDD y BDD para guiar la definición de los criterios de aceptación, identificando de manera temprana la respuesta real que espera el usuario final, la prueba es guiada por la retroalimentación continua, lo cual mejora el uso y por lo tanto la aceptación del usuario.
Y sobre medios o herramientas para “recolectar” y administrar requisitos
Una diferencia en cuanto a los medios o mecanismos para "recolectar" requisitos:
En Cascada se usan medios como los documentos escritos tradicionales llenos de expresiones tipo "el sistema debe hacer esto" o "el sistema debe hacer aquello", o se usan mecanismos como casos de uso, entre otros. En cualquier caso, como mencioné antes, la fuerza está en elaborar grandes cantidades de documentación de requisitos. Escribí mucho sobre esto aquí en el Gazafatonario durante la década pasada y publiqué un libro al respecto. Lo pueden encontrar en Amazon.
En Ágil, por su parte, usamos medios o mecanismos que promuevan la conversación entre los interesados (usuarios y equipo de desarrollo). Las Historias de Usuario se han constituido en el medio esencial para esto. Pueden encontrar una especie de índice de mis artículos y propuestas y las de mi gran amigo Jorge Abad sobre este tema en bit.ly/lashistoriasdelucho.
Ahora sí, cuéntame en el foro de otras diferencias a la hora de recolectar y administrar requisitos o necesidades que consideres importantes.



*VUCA: siglas en inglés de Vulnerabilidad, Incertidumbre, Complejidad, Ambigüedad

miércoles, enero 17, 2018

Revisión a la Guía de Nexus 2018


Ken Schwaber y Scrum.org anunciaron hoy (enero 17 de 2018) que fue publicada una actualización a Nexus, el marco de trabajo para escalar Scrum. Acorde con los recientes cambios a su marco de trabajo subyacente, los cambios a Nexus aumentan la claridad, enfatizan la criticidad de “Terminado” a Escala y extienden el alcance mundial de Nexus, se anunció hoy en un comunicado oficial.
Las actualizaciones fueron determinadas en parte a través de los comentarios de la comunidad de Scrum a través del sitio web Scrum Guide User Voice, la comunidad de Scrum.org y sus entrenadores profesionales de Scrum (PST). Un énfasis en aumentar las aclaraciones sobre el Equipo de Integración de Nexus y el propósito de su rol, afirmando la importancia de la transparencia a escala para la integración y definiendo qué significa "Terminado" a Escala, son algunos de los principales cambios que los practicantes de Scrum encontrarán en la versión actualizada de la Guía Nexus.
Estos son los cambios más significativos:
1.    Actualizada la descripción de la Guía Nexus de “El exoesqueleto de desarrollo a escala con Scrum” a “La guía definitiva para escalar Scrum con Nexus: las Reglas del Juego”.
2.    Nexus se define ahora como “una relación o conexión entre personas o cosas”.
3.    En el Flujo del Proceso Nexus, la terminología se cambió para hacer foco en los equipos en vez de en los miembros individuales, “Un Nexus consiste de múltiples equipos Scrum multifuncionales que trabajan en conjunto para entregar al menos un Incremento Integrado potencialmente distribuible en cada Sprint”.  También se agregó que basados en las dependencias, los equipos se autoorganizan y seleccionan los miembros más apropiados para hacer un trabajo específico.
4.    Claridad alrededor del rol del Equipo de Integración Nexus:
a.    El Equipo de Integración Nexus está conformado a menudo de miembros de los Equipos Scrum individuales del Nexus. Esta composición soporta la necesidad de inteligencia hacia arriba de los Equipos Scrum individuales en el Nexus.
b.    El Equipo de Integración Nexus no es el encargado de hacer la integración. Los Equipos Scrum individuales realizan el trabajo de integración.
c.    Se eliminó la definición de que el Equipo de Integración Nexus es un Equipo Scrum puesto que esto ha causado confusión, permitiendo creer que sus miembros son un Equipo Scrum separado permanentemente de los demás en el Nexus.
5.    El Refinamiento se movió en los Eventos Nexus hasta la parte superior. Ahora aparece antes que la Planificación del Sprint Nexus.
a.    El Refinamiento ya no está prescrito como un evento de dos partes. La terminología se enfoca en la transparencia en vez de en la visualización.
b.    Se eliminó la referencia al Refinamiento como “reuniones”, en vez de eso solo “Refinamiento”.
c.    Se enfatiza en el Refinamiento como una actividad continua a lo largo del Sprint mientras sea necesario y apropiado.
6.    La Meta Nexus ya no se especifica como una entrada o salida de la Planificación del Sprint Nexus puesto que esto puede variar, en cambio se define como una meta que el Dueño de Producto discute durante la Planificación del Sprint Nexus. Se eliminó terminología sobre la necesidad de estar en el mismo espacio físico.
a.    La Meta Nexus es ahora la Meta del Sprint Nexus y ya no se encuentra en la lista de nuevos artefactos, para ser consistente con el Marco de Trabajo Scrum.
b.    Se eliminó de la Tabla de Contenido.
7.    El Scrum Diario Nexus es una oportunidad para que los equipos busquen impactos entre equipos así como dependencias entre ellos.
a.    El Scrum Diario Nexus no es la única vez que la Lista de Pendientes del Sprint Nexus debería ajustarse. Es al menos uno de los momentos en los cuales los equipos se juntan para ajustar la Lista de Pendientes del Sprint Nexus para reflejar su entendimiento del trabajo y las dependencias entre equipos.
b.    El Scrum Diario Nexus es el momento en el que los Equipos de Desarrollo en el Nexus inspeccionan el progreso hacia la Meta del Sprint Nexus.
8.    La Revisión del Sprint Nexus no es para mostrar algo a la audiencia y contarle sobre eso, como no lo es en Scrum – se agregó terminología que la clarifica como una oportunidad de adaptar La Lista de Elementos del Producto si es necesario. También se menciona la necesidad de retroalimentación en la descripción de la Revisión del Sprint Nexus en el “Flujo del Proceso Nexus” en la página 5.
9.    Se agregó que la Retrospectiva del Sprint Nexus es una oportunidad formal para que el Nexus se inspeccione y adapte y cree un plan de mejoramiento que se ejecute a partir del próximo Sprint.
a.    Similar a la actualización de la Guía de Scrum, la Retrospectiva del Sprint Nexus existe para asegurar el mejoramiento continuo para el Nexus.
10. El Incremento Integrado representa el estado actual del trabajo integrado.
11. La Definición de “Terminado” especifica que el Incremento Integrado debe estar integrado.
12. En “Transparencia de los Artefactos” se eliminó la definición “la prueba de deuda técnica inaceptable es cuando la integración ocurre y sigue sin estar claro que todas las dependencias están resueltas”. Se reemplazó con “El software debe ser desarrollado de tal forma que las dependencias sean detectadas y resueltas antes de que la deuda técnica sea inaceptable para el Nexus”.
13. Se eliminó el párrafo sobre las prácticas de software. Aunque importante y relevante, el tema requiere de mayor elaboración para que agregue valor.
14. Se adicionó la cláusula de Creative Commons, lo que permitirá a los equipos y organizaciones, a nivel mundial, reutilizar el contenido de la guía y ampliar su alcance.
Como siempre, con mis grandes amigos Jorge Abad (@jorge_abad) y LeonardoAgudelo (@sweepnoise), hicimos la traducción de los cambios y mejoramos también algunos aspectos de la terminología en español.
La guía actualizada puede descargarse ya en español (2018) desde el sitio Web:  https://www.scrum.org/resources/nexus-guide.
Para conocer más de Nexus, pueden leer mi artículo:
En el que también podrán ver y descargar una presentación al respecto.

¿Cómo les ha ido con el uso de Nexus? ¿Tienes alguna pregunta adicional al respecto? Por favor, déjanoslo saber en el foro.