Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta historias de usuario. Mostrar todas las entradas
Mostrando las entradas con la etiqueta historias de usuario. Mostrar todas las entradas

viernes, abril 17, 2015

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

#RSGECU2015: Ágil es algo que eres, CMMI es algo que usas
Este viernes 17 de abril, presenté en el Regional Scrum Gathering 2015, en Quito, mi disertación sobre Ágil y enfoques tradicionales. Mi asunto principal es 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, como erróneamente pregonan muchos. Los líderes de los procesos actuales pueden y 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 tipo 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 está hablando en el  #RSGECU2015.

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.

¿Quieres saber más?

Pueden descargar la nueva versión de la presentación haciendo clic aquí o en esta dirección: http://goo.gl/leJ5N8.


No olviden escribirme con sus inquietudes o sugerencias a lucho.salazar@gmail.com o en el foro del blog.

lunes, abril 13, 2015

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í.


jueves, marzo 05, 2015

De historias de usuario, culturas y del arte de narrar historias

“Yo no sé muchas cosas, en verdad,

Digo tan solo lo que he visto.
Y he visto que la cuna del hombre
la mecen con cuentos,
que los gritos de angustia del hombre
los ahogan con cuentos,
que el llanto del hombre
lo taponan con cuentos.
Y que el miedo del hombre
ha inventado todos los cuentos…
Yo sé muy pocas cosas, es verdad,
pero me han dormido con todos los cuentos
y sé todos los cuentos ...”
[León Felipe, Aguaviva.]

La vida es una alegoría, los seres humanos no solo estamos configurados como cuerpos biológicos abastecidos de estímulos y pulsiones, pues nacemos en un entorno social y por tanto nos relacionamos, desde lo más esencial –lo familiar, hasta lo más universal, con nuestros semejantes. Pero además poseemos una visión personal para interpretar nuestra cotidianidad, tenemos ideales y pensamientos, emociones y aversiones que nos hacen actuar  de formas particulares al interpretar nuestra realidad.

En todo esto, la narración de historias juega un papel muy importante  en la construcción de conocimiento. La narrativa es una forma de caracterizar los fenómenos de la experiencia humana. Dice Ivar Jacobson en su libro Casos de Uso 2.0 que “la narración de historias permite a las culturas sobrevivir y progresar; es el camino más simple y más efectivo para pasar el conocimiento de una persona a otra. Es la mejor manera de comunicar lo que un sistema debe hacer y hacer que todo el mundo trabaje en el sistema sobre los mismos objetivos.” [1]

Las historias (de usuario) establecen una manera de organizar y comunicar experiencias. Las personas usan instintivamente la narración de historias para organizar un cúmulo de ideas que consideran disperso; además, gracias a ellas pueden organizar lo que saben acerca de su trabajo y de cómo lo hacen. Al narrar historias, las personas nos invitan de una forma u otra  a investigar sus pensamientos, sus sentimientos y sus intenciones. Finalmente, como oyentes y más tarde como lectores de las historias de usuario, adherimos a los acontecimientos, como una exploración de la experiencia de los usuarios, entendiéndolas mejor y de la forma más completa posible, pero sobre todo, comprendiendo su valor real.

Quienes transitamos a diario por el vasto universo del diseño y construcción de productos de software sabemos que es importante enfocarnos en el valor que estos prestarán a sus dueños, los usuarios, y a otros interesados. El mismo Jacobson dice que “solo se genera valor si el sistema se usa realmente; así, es mejor enfocarse en cómo se usará el sistema que en las largas listas de funciones o características que ofrecerá.” [2] Y agrega más adelante: “es fácil capturar y validar la completitud de las historias y estas, a su vez, facilitan filtrar las formas potenciales de usar el sistema que ofrezcan poco o ningún valor real a los usuarios. Este foco constante en el valor permite asegurar que cada entrega del sistema sea tan pequeña como sea posible, a la vez que tenga valor real para los usuarios del sistema y para los interesados que financian el desarrollo.” [3]

Cuenta las historias, no las escribas

En su libro “Fifty Quick Ideas to Improve your User Stories”, Gojko Adzic & David Evans [4], compilan una serie de conceptos sobre cómo mejorar nuestras historias de usuario o, mejor aun, sobre cómo mejorar el desempeño del equipo ágil usando la técnica de las historias de usuario. Me interesó mucho la primera de esas ideas, muy acorde a mi interés actual sobre las historias y la supervivencia de las culturas. Esta idea es precisamente la del título de esta sección: cuenta historias, no las escribas.

Uno de los errores más comunes de las personas que empiezan a usar prácticas ágiles es creer que las historias de usuario son requisitos livianos. Las historias de usuario no son requisitos, son más bien una carta de intención de lo que queremos que haga el sistema, son recordatorios para conversaciones que tendremos más adelante, el Equipo de Desarrollo y el Dueño de Producto, pero definitivamente no son requisitos. Este malentendido conduce a situaciones en que las historias sean recolectadas en herramientas de gestión de actividades, con muchos detalles escritos o proporcionados por representantes del negocio.

Nada más alejado de una buena práctica. Las historias de usuario implican un modelo totalmente diferente, Gojko y David lo llaman “requisitos por colaboración”, un modelo donde la transferencia de conocimiento vía documentos “pesados” se reemplaza por involucramiento y colaboración, al mejor estilo del Manifiesto Ágil. Ya sabemos que la conversación cara a cara es la forma más efectiva de comunicar información y que una buena discusión entre los interesados y el equipo ágil lleva a mejores preguntas/respuestas, opciones e ideas del producto. Cuando los requisitos se escriben, aun si los llamamos historias de usuario, estas discusiones nunca suceden y las mejores ideas se pierden para siempre. Tengo algo de experiencia en esto, pasé dos décadas escribiendo requisitos de software, todo tipo de requisitos, todo tipo de productos de software.

La recomendación es simple, avanzan Adzic y Evans en su libro: intenta contar historias o que te cuenten historias, en vez de escribirlas. Usa tarjetas físicas o un sistema de tiquetes electrónicos, pero solo como recordatorios de esa conversación que tendrás más adelante. No gastes mucho tiempo tratando de descifrar los detalles de las historias con anticipación. Compromete a los interesados del negocio e involucra a los miembros del equipo en una discusión, busca distintas perspectivas de la historia y explora opciones. Esta es la forma de acceder a los beneficios reales de trabajar con historias de usuario.

Beneficios clave de contar historias

Las discusiones permiten a los representantes del negocio, no solo explicar lo que quieren, sino también asegurarse de que los miembros del equipo entiendan esto correctamente. Uno de los mayores problemas en los modelos tradicionales son los malos entendidos entre los distintos roles en el equipo y entre los interesados, entre quienes existen niveles heterogéneos de conocimiento acerca de las necesidades de cada uno, complemento además del ya típico fenómeno del “teléfono roto” [5]. Es un hecho, explicar una historia cara a cara evita caer en vacíos de conocimiento sobre la historia.

El segundo beneficio, apuntan Adzic & Evans, es el análisis más rápido. Cuando el equipo completo se involucra en una discusión, los vacíos funcionales, las inconsistencias y los requisitos no claros se descubren más rápidamente que cuando una sola persona (léase Analista del Negocio o similar), escribe los detalles.

Pero el beneficio más importante de la comunicación cara a cara, comparada con el paso de información vía documentos, es que la primera produce mejores soluciones, mejores productos. Para ser capaz de construir buenas soluciones, las personas necesitan conocer los planes y las oportunidades del negocio, entender el dominio del problema, tener un conocimiento profundo de las restricciones técnicas estar al tanto de las nuevas tecnologías que potencialmente les puedan servir. Involucrar a un grupo de personas en el análisis desde diferentes perspectivas ayuda al equipo a beneficiarse del conocimiento compartido.

Como lograrlo

La excusa más común para llenarnos de documentación es la insistencia del negocio en la aprobación formal, las regulaciones legales o gubernamentales o las dependencias con terceros. Si es necesario “firmar” las historias hazlo a medida que las discutes. Es más, si el alcance final debe ser aprobado por varios interesados en el negocio, involúcralos en las reuniones de Refinamiento, días antes de la reunión de planificación del Sprint donde se van a construir las historias. En cualquier caso, el Dueño de Producto juega un papel muy importante en la consecución de tales aprobaciones. Es una de sus responsabilidades directas.

Como siempre, ensaya distintos acercamientos y en cada retrospectiva analiza como le fue a tu equipo. Como dice el refrán, la experiencia no se improvisa. Hasta allí el tema, recomiendo amplísimamente los libros que usé como referencia

Referencias

[1] [2] [3] Ivar Jacobson et all. Use Case 2.0. Ivar Jacobson International. 2011. Traducción de Luis Antonio Salazar y Carlos Mario Zapata.

[4] Gojko Adzic & David Evans, Fifty Quick Ideas to Improve your User Stories, © 2013 – 2014 Nueri Consulting LLP

[5] Conocido también en algunas culturas o regiones como el fenómeno o el juego del “teléfono descompuesto”

Para saber más de historias de usuario puedes leer mi serie de artículos en este mismo Gazafatonario:

http://goo.gl/iJvj7
http://goo.gl/NZv4vj
http://goo.gl/e1DSVh
http://goo.gl/eGHQQU

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




martes, marzo 04, 2014

Algunas Notas Sobre Gestión del Producto en Scrum

"Si puedes soñarlo, puedes hacerlo". Walt Disney.
Image courtesy of Stuart Miles / FreeDigitalPhotos.net
Image courtesy of Stuart Miles / FreeDigitalPhotos.net
Quienes venimos de enfoques tradicionales de desarrollo de software caracterizados por proponer y hasta exigir una diversidad de artefactos, encontramos la Lista de Producto (Product Backlog) de Scrum como algo tan hermosamente simple que raya en lo poético. Quizás a esa simplicidad se deba su inmensa popularidad entre los practicantes ágiles.
La Lista de Producto es un inventario priorizado del trabajo pendiente necesario para traer el producto a la vida. El Dueño de Producto es el responsable de la Lista de Producto y de su contenido. Nadie tiene una visión del producto que va más allá del producto en sí, como el Dueño de Producto.

Sus elementos pueden incluir:
  • Una exploración de las necesidades del usuario
  • Opciones técnicas variadas
  • Una descripción tanto de requisitos funcionales como no funcionales
  • El trabajo necesario para lanzar el producto

También puede contener otros elementos como:
  • Configuración del entorno
  • Defectos del producto. 

La Lista de Producto reemplaza los artefactos tradicionales de requisitos, tales como las especificaciones de requisitos del software. Mientras que el Dueño de Producto se compromete a manejar la Lista de Producto, el Scrum Master, el equipo y los interesados contribuyen a esta tarea. Juntos, descubren la funcionalidad del producto. Además, la Lista de Producto es también una herramienta para proporcionar transparencia durante el proyecto.
Sobre la Priorización
La priorización de la Lista puede hacerse de muchas formas, pero es algo que siempre se hace con el Dueño de Producto a bordo, liderando la priorización. Por ejemplo, es posible crear temas que contienen una lista de historias. Cada uno de estos temas tiene un “costo de retardo” asociado. Esto permite conocer el impacto de no implementar un tema si antes implementamos otro.
En este apartado debemos tener en cuenta que si se nos dificulta la priorización de la Lista de Elementos del Producto, puede estar sucediendo que:
  1. Los elementos, por ejemplo las historias de usuario, son muy grandes para priorizar
  2. No hay ningún valor de negocio asociado al Elemento de la Lista de Producto.
En el primer caso podemos dividir las historias en historias más pequeñas y relacionadas. En el segundo caso, podemos desechar estas historias “sin valor” y encontrar otras que sí reflejen valor del negocio o Retorno de la Inversión. Recuerda, si el Dueño de Producto no es capaz de escribir estas historias, el Scrum Master está a su servicio para ayudarle. No pretendas en el primer intento que un usuario tenga las habilidades y experiencia necesarias para escribir historias de usuario que cumplan con los atributos INVEST. Además, por lo general, no es posible cambiar de Dueño de Producto, es alguien sin quien el proyecto no puede vivir.

Sobre los defectos del producto
Si te estás preguntando como encargarte de esas anomalías que surgen o pueden surgir luego de la salida a producción del software y no sabes si decidirte por usar historias y priorizarlas en la Lista de Producto junto con las nuevas características, y si no estás buscando dogmas, puedes simplemente pensar en trabajar con el Dueño de Producto para clasificar y priorizar esos defectos en producción, luego los puedes tratar como historias de usuario a incluirlos en una entrega específica.
Al igual que en enfoques clásicos de mantenimiento de productos, si el defecto causa un alto impacto en los usuarios, este debe escalarse y resolverse como un ajuste en producción sin pasar por la cadencia normal de Scrum. Lo que sí puedes hacer es manejar la reparación del software usando un proceso Kanban, el cual permite un enfoque más liviano de gestión. Eso sí, no olvides que un error en producción representa valor negativo para el negocio así que dedica un esfuerzo mayor a evitarlos o a reducirlos al mínimo más que a corregirlos.
Cuando hagas esto piensa que:
  • Si una parte del producto tiene desperfectos, todavía no está Terminada.
  • Cualquier trabajo que necesite hacerse, necesita priorizarse.
  • Cualquier actividad que realice el equipo, toma tiempo.
  • El tiempo consumido en una cosa, no puede consumirse en otras cosas.

Los Atributos DEEP de la Lista de Producto
Dice Mike Cohn que una Lista de Producto efectiva tiene estas cuatro propiedades: detallada apropiadamente, estimada, emergente y priorizada. De allí el acrónimo DEEP.
Detallada Apropiadamente
Los Elementos de la Lista de Producto en la parte superior se describen en mayor detalle que los que están en la parte inferior de la Lista. A medida que bajamos en la lista, los elementos están menos detallados. Esto tiene sentido: son elementos que se convertirán en software apenas varias iteraciones más adelante o quizás nunca, si el usuario nota que no los necesita o si se acaba el presupuesto del proyecto. De hecho, es posible que el Dueño de Producto cambie la prioridad de alguno de estos, en cuyo caso solo debe llenar los vacíos de ese elemento para que quede “preparado” para construirse.
Figura: La priorización de la Lista de Elementos del Producto determina el nivel de detalle
Figura: La priorización de la Lista de Elementos del Producto determina el nivel de detalle
Esta técnica asegura que la Lista de Producto se mantenga concisa y que los elementos a implementarse en el siguiente sprint son trabajables. Una consecuencia de este enfoque es que los requisitos se descubren, se descomponen y se refinan a lo largo de todo el proyecto. Es otra de las razones por las cuales el Dueño de Producto debe trabajar con el Equipo de Desarrollo cotidianamente durante todo el proyecto, o más o menos así reza uno de los Principios Ágiles.
Estimada
La estimación de los Elementos de la Lista de Producto usualmente se expresa en puntos de historia o en “días ideales”. Conocer el tamaño de los elementos ayuda a priorizar y a planificar las entregas a producción. Recordemos que otras estimaciones más detalladas a nivel de tareas se realizan durante la Reunión de Planificación del Sprint; y también, estas tareas y sus estimados se capturan en la Lista de Pendientes del Sprint.
Un día ideal es una abstracción del número de horas diarias en las que normalmente esperas que un miembro del equipo sea productivo, restando tiempo para asistir a reuniones, ir al baño, tomar un café o simplemente hacer una pausa laboral.
Emergente
La Lista de Producto tiene una cualidad orgánica. Evoluciona y su contenido cambia frecuentemente. Nuevos elementos se descubren y adicionan a la Lista basados en retroalimentación del usuario, principalmente. Los elementos existentes se modifican, re-priorizan, refinan o se remueven permanentemente.
Priorizada
Todos los elementos en la Lista de Producto se ordenan según su valor e trascendencia para la Organización. Los elementos más importantes y de más alta prioridad se implementan primero. Estos pueden encontrarse al principio de la lista, como indico en la Figura 1. Luego de que un elemento esté “Terminado”, se elimina de la Lista de Producto.
Finalmente
La Lista de Producto existe por un propósito más grande: construir un producto que impacte a los usuarios, que haga resonancia en ellos/ellas y que cambie en algo sus estilos de vida.
El producto debe construirse de manera orgánica, es decir, tan pronto como sea posible, debemos tener una versión que los usuarios puedan usar, el producto mínimo viable. A partir de este producto parcial, coherente y de valor, se construye el producto completo.
Al construirlo, piensa que estás componiendo una pieza musical grandiosa, la sinfonía definitiva, una que será recordada por siempre. Una obra así despliega patrones, trayectorias e incita a las personas a estar a su alrededor.
¿Quieres saber más?
Te recomiendo ampliamente este artículo de Jeff Sutherland:
Enabling Specifications: The Key to Building Agile Systems
El libro de Roman Pichler, Agile Management with Scrum, Creating Products That Customers Love. Addinson-Wesley, 2010.
Sobre Historias de Usuario, mi serie de artículos:
Historias de Usuario: un nuevo orden en los requisitos del software
Historias de Usuario Altamente Efectivas, Parte 1
Historias de Usuario Altamente Efectivas, 2
Historias de Usuario Altamente Efectivas, 3
Historias de Usuario Altamente Efectivas, 4

lunes, agosto 19, 2013

Historias de Usuario Altamente Efectivas 4

VademeScrum, Sección 2: Las Historias de Usuario 4

Cualidad :: Valiosa (y Valuada)

Escribiendo Historias de Usuario Altamente Efectivas, 4
Las Historias de Usuario deben tener Valor para los usuarios
Veamos esta situación:
Historia de Poco Valor
Como: Lector del blog
Quiero: ver la lista de temas tratados en el blog
Para: buscar las entradas que más se acomoden a mis intereses personales
Es mejor escribir esta historia desde el punto de vista del Bloguero:
Historia de Mucho Valor
Como: Bloguero
Quiero: mostrar a los lectores los nuevos temas tratados en mi blog
Para: que ellos continúen más propensos a leer más entradas del blog
Con esta historia tenemos una perspectiva más clara del valor real de la historia. La implementación de esta podría llevar a más lectores a leer más entradas del blog con lo que se incrementaría el tráfico en el sitio Web y posicionarían al bloguero como experto en los temas de su dominio. Mientras que ambas historias son pequeñas, negociables, independientes, y pueden tener los demás atributos de las buenas historias de usuario, el valor de la segunda es mucho más alto para el negocio que el valor de la primera.
Al negociar la funcionalidad de una historia también tenemos en cuenta su valor para el negocio. Una visión que siempre debemos tener los equipos ágiles es encontrar ese 20% de la funcionalidad que se usa el 80% de las veces o ese 20% del producto que tiene el 80% del valor para el negocio, recordemos que la filosofía ágil se basa en entregar valor al usuario. Esto quiere decir que si tenemos una funcionalidad como la siguiente:
Como: Bloguero
Quiero: ingresar a mi blog con usuario y contraseña
Para: mantener la seguridad y confiabilidad de la información del blog
Criterios de Aceptación:
  • Debo ser capaz de cambiar la contraseña cuando lo desee
  • El sistema debe enviarme un correo electrónico para confirmar el cambio de contraseña
  • El usuario puede ser un nombre seleccionado por mí o una dirección de correo electrónico
  • El sistema debe bloquear la cuenta cuando haga tres intentos fallidos consecutivos
  • El sistema debe permitir que ingrese automáticamente si uso el mismo computador o dispositivo
  • Si olvidé la contraseña, el sistema debe preguntarme por la dirección de correo asociada a mi cuenta o por mi nombre de usuario y enviarme un enlace para establecer una nueva contraseña
  • [Siguen…]

Esta es, a todas luces, una historia que se puede dividir en varias historias dado el alto número de criterios de confirmación que tiene. Con los usuarios buscamos lo que proporcione mayor valor para el negocio y lo que se vaya a usar más, por ejemplo: “el sistema debe permitir establecer una nueva contraseña cuando lo desee”, y salir en la primera iteración o entrega con esta funcionalidad. Las demás se van adicionando a medida que avanzan las iteraciones o las entregas. Y como antes, algunos de estos criterios quizás nunca lleguen a implementarse, por ejemplo, el de bloquear la cuenta después de varios intentos errados.
Finalmente, quien mejor conoce el valor de una historia de usuario es precisamente el usuario, personificado en alguien como el Dueño del Producto, que habla como una sola voz ante el equipo de desarrollo y que representa los intereses del negocio. Es a esta persona a quien debemos apoyar para que los esfuerzos de desarrollo sean conducidos efectiva y eficientemente.
A estas alturas solo hace falta recordar que el Valor es el atributo más importante en el modelo INVEST. Cada historia de usuario debe proporcionar algún valor, el mayor posible, al usuario, al cliente o a cualquier interesado en el producto. Con esto en mente, debemos entonces reorientar nuestras estructuras de descomposición funcional del software de un enfoque horizontal a uno vertical, esto es, para el usuario o interesado no tiene prácticamente ningún valor si cierta funcionalidad requiere de uno o varios procedimientos almacenados, o de uno o varios componentes en las capas intermedias de la solución.
El usuario necesita de la funcionalidad que le permite interactuar con el sistema, es lo que tiene valor para él/ella. Entonces debemos crear historias que atraviesen la arquitectura para poder presentar valor al usuario y obtener así la mejor retroalimentación en el menor tiempo posible. Esto es consistente con los modelos de gestión ágiles como Scrum, donde el Dueño de Producto es quien orienta los esfuerzos del equipo de desarrollo y prioriza las historias de usuario teniendo en cuenta su valor para el negocio. Y normalmente el Dueño de Producto no conoce de los aspectos puramente técnicos que subyacen a una historia de usuario (procedimientos almacenados, clases, componentes, Web services, etcétera).
En este punto llegamos al no menos peliagudo asunto de los requisitos técnicos o no funcionales, del software. Dos estrategias se usan habitualmente: la primera de ellas es que estas condiciones técnicas hagan parte de los criterios de aceptación de la historia, como en:
Como: Editor
Quiero: establecer el período de expiración de la contraseña
Para: que los blogueros se vean forzados a cambiar sus contraseñas periódicamente.
Criterios de Aceptación:
  • La contraseña se debe poder cambiar antes de finalizar el período de expiración
  • Ninguna persona distinta a su creador debe tener acceso a la contraseña

El segundo criterio, relacionado con el acceso a la contraseña, es una restricción típica de seguridad que bien puede ser establecida por un usuario, en este caso, por el Editor; también puede ser un Administrador de la Aplicación. Este enfoque de incluir las características no funcionales de una historia como parte de esta tiene la ventaja de permitir al mismo usuario reconocer su valor y al equipo completo de negociar su implementación.
La segunda táctica es crear historias independientes para cada propiedad o condición técnica, o para un grupo de estas, como en:
Como: Bloguero
Quiero: que mis entradas de blog soporten hasta 10 mil comentarios cada una
Para: mantenerme en contacto con el mayor número de personas posible
Criterios de Aceptación:
  • Cada comentario debe contener hasta 500 palabras o 4000 caracteres

En este ejemplo, tanto la acción expuesta en la historia de usuario, como el criterio de confirmación son requisitos no funcionales que se pueden implementar. Este segundo enfoque ayuda a independizar las historias de usuario y a aplicar criterios a un grupo de funcionalidades (este no es el caso en el ejemplo); sin embargo, estas historias tienen la desventaja de que los usuarios o interesados (el Dueño del Producto) no le vean ningún valor y son difíciles de negociar con ellos/ellas.
En la práctica se usa una combinación de las dos estrategias. Ahora bien, hay que decir es que no existe tal cosa como la historia del desarrollador o la del arquitecto del software, ni mucho menos la del Dueño del Producto, como en:
Historias de Poco o Ningún Valor
Como: Desarrollador
Quiero: matricular mi aplicación en Jenkins
Para: tener integración continua automatizada

Como: Arquitecto
Quiero: que las transacciones de la aplicación se tarden menos de 1 segundo
Para: poner en producción una solución de alto desempeño

Como: Analista de Pruebas
Quiero: automatizar los casos de prueba de la aplicación
Para: hacer pruebas de regresión de manera eficiente y efectiva

Como: Desarrollador
Quiero: implementar el procedimiento almacenado spAdicionarComentario
Para: que la aplicación tenga la capacidad de añadir comentarios a las entradas de blogs
Simplemente estas historias no deberían existir, de hecho, no son historias de usuario del todo, ningún usuario final las usa. Para el usuario no es importante, por ejemplo, donde se registran los errores de una aplicación, quizás ni le interese si se registran en alguna herramienta; tampoco es de valor conocer el número de inconformidades que tiene el código fuente frente a las buenas prácticas de programación. El usuario da por hecho que el equipo de desarrollo sabe, precisamente, construir productos de software y que le va a entregar el mejor posible y el de mayor valor.
Conclusiones Finales
Es un hecho, sin importar que tanto trabajemos como equipo de desarrollo en poner a punto el ambiente de pruebas, en tener los mejores servidores de integración continua disponibles, en usar las mejores prácticas de escritura de código fuente, en crear componentes reutilizables de alta calidad o procedimientos almacenados optimizados, el Bloguero de nuestro sistema de publicaciones no puede crear una entrada de blog con el reporte que genera el analizador de código estático de nuestro entorno de desarrollo al compilar el código fuente, ni con las docenas o cientos de procedimientos almacenados implementados sobre el motor de la base de datos, ni con la implementación del algoritmo Blowfish para encriptar las contraseñas.
Simplemente necesita de una interfaz de usuario que pueda utilizar para realizar todas sus operaciones.
Artículos Relacionados
El artículo donde presento las Historias de Usuario, a manera de introducción: Historias de Usuario: un nuevo orden en los requisitos del software, lo encuentran en:
http://www.gazafatonarioit.com/2013/07/historias-de-usuario-un-nuevo-orden-en.html
La primera parte de esta serie de artículos sobre los atributos INVEST y las buenas historias de usuario: Historias de Usuario Altamente Efectivas, Parte 1. Lo encuentran en:
La parte 2 de esta serie de artículos sobre los atributos INVEST y las buenas historias de usuario: Historias de Usuario Altamente Efectivas, Parte 2 – Cualidad :: Independiente. Lo encuentran en:
La parte 3 de esta serie de artículos sobre los atributos INVEST y las buenas historias de usuario: Historias de Usuario Altamente Efectivas, Parte 2 – Cualidad :: Negociable. Lo encuentran en:
Referencias
  • INVEST in Good Stories, and SMART Tasks:

  • A User Story Primer, by Dean Leffingwell with Pete Behrens
  • User Stories Applied, by Mike Cohn