Buscar en Gazafatonario IT

domingo, agosto 04, 2013

Historias de Usuario Altamente Efectivas, 2

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

INVEST es un acrónimo acuñado por Bill Wake para referirse a ciertas propiedades que debería tener una buena historia de usuario:


- Independiente
- Negociable
- Valiosa
- Estimable
- Sucinta

- cerTificable

Una presentación previa de este tema la hice en:
Cualidad :: Independiente
Para entender mejor este rasgo de las historias de usuario, veamos un par de historias dependientes entre sí:
Historia Dependiente 1
Como: Editor
Quiero: establecer las reglas de seguridad de la contraseña de los blogueros
Para: que los blogueros se obliguen a crear y retener contraseñas seguras, manteniendo seguro el sistema.
Historia Dependiente 2
Como: Bloguero
Quiero: Seguir las reglas de seguridad de las contraseñas establecidas por el Editor
Para: que mi cuenta se mantenga bastante segura.
A todas luces es evidente que completar la historia del Editor no deja el producto en un estado de potencialmente distribuible, por lo tanto, no tiene valor o no es valiosa por sí sola para el negocio. Esto ocurre porque la historia del Editor solo es verificable en cuanto a establecer, eliminar y preservar la política, pero no es verificable cuando de hacerla cumplir al bloguero. Reconsiderando las historias y el diseño del sistema, podemos eliminar la dependencia dividiendo las historias de una manera diferente, en este caso, a través de los tipos de políticas de seguridad aplicadas y combinando la configuración de la política con normas para hacerlas cumplir en cada historia:
Historia independiente 1
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.
Historia Independiente 2
Como: Editor
Quiero: establecer las características de solidez de la contraseña
Para: que los blogueros deban crear contraseñas difíciles de jaquear o de descifrar.
Ambas historias están escritas desde el punto de vista del Editor. Esto es así porque los blogueros simplemente “usan” o “consumen” las restricciones impuestas por el Editor. En el segundo ejemplo, cada historia puede valerse (y valorarse) por sí misma y puede desarrollarse, verificarse y entregarse independientemente. Una buena práctica es preguntarnos para cada Historia de Usuario si hemos hecho todo lo posible para que esta sea independiente del resto. La independencia permite además construir la historia, es decir, convertirla en software funcionando, en iteraciones diferentes o aun en entregas distintas del mismo proyecto.
Ahora bien, la dependencia entre historias de usuario se presenta de distintas formas. Bill Wake, el creador del modelo INVEST, describe4 tres tipos comunes de dependencia: de Superposición, de Orden y de Contención.
Dependencia por Superposición de Funciones
El primero de estos casos es el más doloroso de todos. El siguiente par de historias nos muestran esta situación:
Figura 1: Historias dependientes por superposición de funciones
Figura 1: Historias dependientes por superposición de funciones (Haga clic sobre la imagen para ampliarla)
Observemos la actividad (el “Quiero”) de estas historias. La conjunción “Y” presente en cada una de ellas ya hace que estas historias sean “sospechosas”. Por supuesto, la superposición se da entre dos o más historias y lo que procede es tratar de reducir o de eliminar la trasposición de funciones. En el caso actual podemos convertir estas dos historias en tres, teniendo en cuenta que “Agregar comentarios a las entradas” se repite en ambas historias:
Figura 2: Historias independientes luego de remover la superposición de funciones
Figura 2: Historias independientes luego de remover la superposición de funciones (Haga clic sobre la imagen para ampliarla)
Como siempre debe ocurrir con las historias de usuario, las estamos viendo desde el punto de vista del usuario, no de lo que tenemos que hacer para implementarla. En este sentido, seguramente parte de la funcionalidad de agregar comentarios, sino toda, se comparte con la de Responder a Comentarios, pero eso es un asunto técnico que poco o nada interesa a quien usará las funcionalidades una vez estén expuestas. No se trata de interposición técnica, sino funcional.
Dependencia por Orden de Funciones
Esta es quizás la dependencia a la que estamos más atentos. Se trata de esas funciones de la solución que se deben implementar antes que otras. Pero también son dependencias fáciles de remover cuando se presentan. Por ejemplo, para agregar o responder a comentarios a las entradas, el lector del blog debe identificarse primero y para ello debe registrarse primero. Es la secuencia del proceso de negocio y, por consiguiente, funcional. Estas historias pueden lucir como se muestra en la figura a continuación:
Figura 3: Historias dependientes por orden de funciones
Figura 3: Historias dependientes por orden de funciones (Haga clic sobre la imagen para ampliarla)
En principio, el registro (registrarse) puede evitarse matriculando “a mano” las primeras cuentas para que el sistema comience a funcionar o, incluso, se puede usar la funcionalidad de Ingresar al Blog para hacer el registro sin que el usuario esté consciente de ello. Pero Ingresar al Blog también se puede dejar para después de Agregar Comentarios y realizar una entrega de la solución donde los lectores puedan adicionar comentarios sin tener que identificarse. Como siempre lo que prima es implementar primero lo de mayor valor para el negocio (para el Dueño del Producto) y lo de mayor riesgo. En este caso, con la historia Agregar Comentarios se logran ambos cometidos.
Dependencia por Contención
Se trata de esas historias que hacen parte de otra, llamadas así sub-historias o algo por el estilo. La confusión se hace latente cuando decidimos aceptar la jerarquía típica de las historias en Épicas y Temas, que son técnicas para describir un sistema de software. Pero dejando de lado esa clasificación, lo que debemos tener en cuenta es que la ordenación o estructura de un sistema casi nunca coincide con la agenda de su implementación. Pensemos por ejemplo en la historia Ingresar al Blog de la sección anterior.
Esta historia podría incluir una funcionalidad para recordar el nombre de usuario al lector del blog o una para restablecer la contraseña si está se ha olvidado, o ambas. Decimos que estas dos funcionalidades adicionales están contenidas en la funcionalidad de la historia Ingresar al Blog que se transforma así en una épica. La carta de intención de estas historias podría lucir como en la siguiente figura:
Figura 4: Historias dependientes por contención de funciones
Figura 4: Historias dependientes por contención de funciones (Haga clic sobre la imagen para ampliarla)
Lo que puede ocurrir al implementar la historia Ingresar al Blog como un todo es que hayan dos enlaces rotos en la funcionalidad (“Restablecer contraseña” y “Recordar usuario”) hasta tanto estas dos últimas historias no se implementen. Y si esto no se logra durante la misma iteración (Sprint) entonces no tendríamos un incremento del software funcionando potencialmente distribuible, al menos, no uno completo.
En cambio, si tratamos estas historias como totalmente independientes y los enlaces “Restablecer contraseña” y “Recordar usuario” los tratamos en cada historia respectiva, al terminar de implementar la historia Ingresar al Blog sí tendremos un incremento funcional distribuible. Otra vez, el valor para el negocio y el riesgo son dos aspectos muy importantes a tener en cuenta a la hora de tomar una decisión sobre cual historia implementar primero y cual historia construir después. En este caso, el tamaño (cualidad que abordaré en otra sección), también juega un papel significativo.
Comentarios Finales
Aplicar el modelo INVEST a cada historia de usuario es una tarea compleja y lleva tiempo lograr los resultados que queremos. En particular, lograr que todas las historias sean independientes es una labor colosal que puede retrasar el proyecto innecesariamente si no tenemos la experiencia suficiente. Contar con un equipo multidisciplinario, maduro y conocedor profundo de estos atributos ayuda. De lo contrario, la I de INVEST no será por Independiente sino por Imposible. La buena noticia es que no tenemos que hacerlo todo de una vez. Como siempre, aplicamos el enfoque iterativo y a medida que refinamos el Backlog del producto, podemos tratar los asuntos de dependencia entre una historia y otra.
Hasta aquí mi enfoque sobre la independencia en las buenas historias de usuario. En la próxima entrada abordaré el no menos espinoso asunto de la Negociabilidad de las historias de usuario.
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:
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:
Referencias
  1. INVEST in Good Stories, and SMART Tasks: http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
  2. A User Story Primer, by Dean Leffingwell with Pete Behrens
  3. User Stories Applied, by Mike Cohn
  4. Independent Stories in the INVEST Model: http://xp123.com/articles/independent-stories-in-the-invest-model/



jueves, agosto 01, 2013

Nueva Versión de la Guía Oficial de Scrum (Ahora en español)

Portada de la Guía de Scrum 2013 en español
Portada de la Guía de Scrum 2013 en español
Actualización 2016/07/23. Este artículo ya está obsoleto. En julio de 2016 apareció una nueva revisión a la guía de Scrum. Todos los detalles aquí mismo en el Gazafatonario:
******************************************************************************
Actualización 20130902. Ya está disponible la versión en español de la Guía Definitiva de Scrum: las reglas del juego. La encuentran en la página oficial de la Guía (https://www.scrum.org/Scrum-Guides), en la sección correspondiente a "Spanish (July 2013)".
Cambios entre las Guías de Scrum de 2011 y 2013
La nueva versión de la guía Scrum acaba de ser publicada este 1 de agosto de2013 por sus autores. La encuentran en . Según Jeff y Ken, estos son los cambios que aparecen en la versión 2013:
1. Se adicionó una sección de Transparencia de Artefactos. Scrum se basa en la transparencia. Las decisiones para optimizar el valor y controlar el riesgo se basan en el estado percibido de los artefactos. En la medida en que la transparencia sea completa, estas decisiones tienen unas bases sólidas. En la medida en que los artefactos no son completamente transparentes, estas decisiones pueden ser erróneas, el valor puede disminuir y el riesgo puede aumentar.
2. La planificación del Sprint es ahora un evento. Dos temas se abordan en esta: Qué puede hacerse en el Sprint y Cómo será hecho el trabajo seleccionado. Después de que el equipo de desarrollo aprovisiona los ítems del Backlog del Producto para el Sprint, el Equipo Scrum define una Meta del Sprint. La Meta del Sprint crea coherencia en el trabajo del Equipo de Desarrollo que podría no estar presente en iniciativas separadas son una meta común. Note la inclusión formal de una Meta de Sprint.
3. El Backlog del Producto es refinado en vez de preparado (groomed). Los ítems del Backlog del Producto refinado son transparentes, lo suficientemente entendidos y granulares como para servir de entrada en la Planificación del Sprint y para selección del Sprint. Los ítems del Backlog del Producto con esta transparencia se llaman “Listos”. Listo y Hecho son dos estados que refuerzan la transparencia.
4. Scrum prescribe sus eventos para crear regularidad y para minimizar la necesidad de reuniones no definidas en Scrum. Todos los eventos son eventos en la forma de bloques de tiempo, de tal manera que cada evento tiene una duración máxima. Un Sprint, como evento contenedor, tiene una duración fija que no se puede acortar o alargar. Los eventos restantes pueden terminar cuando se logra el propósito del evento, asegurando que una cantidad apropiada de tiempo se consuma sin permitir desperdicios en el proceso.
5. Se refuerza la importancia del Scrum Diario como un evento de planificación. Muy a menudo se ve como un evento de estado. Cada día, el Equipo de Desarrollo debería entender cómo intenta trabajar como un equipo auto-organizado para alcanzar la Meta del Sprint y crear el Incremento previsto hacia el final del Sprint. La entrada a la reunión debería ser cómo el equipo está trabajando hacia el logro de la Meta del Sprint; la salida debería ser un plan nuevo o revisado que optimice los esfuerzos del equipo para cumplir con la Meta del Sprint. Para tal efecto, las tres preguntas se han reformulado para hacer más énfasis sobre el equipo que sobre el individuo:
   a. ¿Qué hice ayer que ayudó al Equipo de Desarrollo a alcanzar la Meta del Sprint?
   b. ¿Qué voy a hacer hoy para ayudar al Equipo de Desarrollo a cumplir con la Meta del Sprint?
  c. ¿Veo algún impedimento que evite que el Equipo de Desarrollo o yo alcancemos la Meta del Sprint?
6. El concepto de valor se refuerza para usarse en la Revisión del Sprint. Durante la Revisión del Sprint, el Equipo Scrum y los interesados colaboran acerca de lo que fue hecho en el Sprint. Con base en eso y en los cambios al Backlog del Producto durante el Sprint, los asistentes colaboran en las siguientes cosas que se pueden hacer para optimizar el valor.
[Hasta aquí el resumen de los cambios escrito por los autores de la guía]
Resumiendo, los cambios importantes se enfocan en 6 aspectos:
  1. Transparencia
  2. La Meta del Sprint
  3. Refinamiento y Listo
  4. Eventos en Bloques de Tiempo
  5. Reunión Diaria como evento de Planeación
  6. Valor
Algunas notas adicionales:
  • Refinement en vez Grooming,
  • Importante el énfasis de la Reunión Diaria como reunión de planeación en vez de reunión de status.
  • Las tres preguntas también superponen al equipo sobre los miembros del equipo, el todo es mayor que la suma de las partes.
  • El Valor del producto se eleva de categoría, importantísimo.
  • La Meta del Sprint, ¿cambia la definición de "hecho"? Yo creo que más bien la refuerza.
También hay un video donde los mismísimos creadores de Scrum y de la guía explican los cambios. Lo encuentran en: 


miércoles, julio 31, 2013

Historias de Usuario Altamente Efectivas, Parte 1

Escribir Historias de Usuario Altamente Efectivas
VademeScrum, Sección 2: Las Historias de Usuario 2

Veamos algunos ejemplos de historias de usuario, al menos, en lo que tiene que ver con su primera parte, la así llamada Carta (de Intención) de la historia:
Ejemplo 1:
Como: editor <<Rol>>
Quiero: leer un libro <<Actividad>>
Para: estudiar la viabilidad de publicarlo <<Valor para el negocio>>
Ejemplo 2:
Como: bloguero
Quiero: recibir alertas de los comentarios hechos por mis lectores
Para: responder los comentarios lo más pronto posible y mantener una comunicación fluida con mis lectores
Ejemplo 3:
Como: miembro de la red social
Quiero: ser capaz de cambiar mi contraseña de acceso
Para: evitar suplantaciones de identidad o accesos no autorizados a mi cuenta
Ejemplo 4:
Como: usuario del cajero electrónico (ATM)
Quiero: programar el pago de mi factura de servicios públicos
Para: viajar tranquilamente sin que me suspendan los servicios y no perder tiempo haciendo diligencias innecesarias
Recordemos que el Rol representa quien está ejecutando la acción o quizás quien está recibiendo el valor de la actividad. Normalmente se refiere a un grupo de usuarios o puede ser incluso otro sistema, si es el que ha iniciado la actividad. Entre tanto, la Actividad representa la acción a ser ejecutada por el sistema y el Valor para el Negocio representa el valor de la funcionalidad para el negocio y para los usuarios que la ejecutan. Esta forma de historia de usuario, llamada a veces “la voz de la historia de usuario”, mejora significativamente el entendimiento del por qué y el  cómo que los desarrolladores necesitan para implementar un sistema que cumpla verdaderamente las necesidades de los usuarios.
Cada elemento proporciona un contexto importante y expansivo. El rol permite una segmentación de la funcionalidad del producto y típicamente genera otras necesidades basadas en ese rol y también suministra un contexto para la actividad. La actividad típicamente representa el ‘requisito’ necesitado por el rol. Y el valor comunica por qué es necesaria la actividad, la cual puede conducir muchas veces al equipo a encontrar posibles actividades alternativas que pueden proveer el mismo valor con menos esfuerzo.
Obsérvese que el valor puede ser distinto para el mismo rol y para la misma actividad. Por ejemplo, otros “blogueros” podrían querer el sistema para:
  • Brindar un mejor servicio al cliente (cuando se trata de un negocio)
  • Crear o incrementar el tráfico hacia un sitio específico
  • Lograr reconocimiento
  • Tener una voz (hacerse con una voz)
  • Para que la gente lo encuentre (un independiente, por ejemplo)
  • Ofrecer mis propios productos y servicios
  • Lograr un crecimiento profesional a largo plazo y continuo
  • Recibir retroalimentación “temprana” sobre los temas tratados para escribir un libro
  • Etcétera

Cada uno de estos valores o metas para el negocio generan o pueden generar historias distintas. Ahora bien, todas estas historias tienen algunas cosas en común:
  • Son independientes unas de otras, aun si representaran características del mismo sistema.
  • Sus características y su intención se pueden negociar entre el equipo de desarrollo y el usuario.
  • Tienen cierto valor para el usuario, unas más que otras.
  • El esfuerzo requerido para su construcción, es decir, para su conversión a una funcionalidad de software, se puede estimar con muy poco trabajo, usando técnicas simples.
  • Son pequeñas, en el sentido de sucintas, y la funcionalidad que se produce a partir de ellas también.
  • Sus criterios de aceptación y su funcionalidad se pueden certificar, es decir, verificar y validar mediante un procedimiento sencillo y viable, tanto en lo económico como en lo técnico.

Estos aspectos comunes constituyen lo que se conoce como los atributos INVEST de las historias de usuario. INVEST es un acrónimo acuñado por Bill Wake para referirse a ciertas propiedades que deberían tener una buena historia de usuario:
  • Independiente
  • Negociable
  • Valiosa
  • Estimable
  • Sucinta
  • cerTificable

En inglés Independent, Negotiable, Valuable, Estimable, Small (o Sized appropriately) y Testable.
En las siguientes entradas abordaré en detalle cada una de estas cualidades.

domingo, julio 21, 2013

Historias de Usuario: un nuevo orden en los requisitos del software

Papiro - Historias de Usuario: un nuevo orden en los requisitos del software
Las Historias de Usuario no requieren almacenarse en
documentos pesados o especiales
VademeScrum, Sección 2: Las Historias de Usuario 1
Estoy escribiendo un artículo sobre Scrum sin Historias de Usuario, pero entonces noté que quizás muchos de mis lectores no sabrían que es una historia de usuario y por qué se usan en Scrum. Así es que tomé la decisión de cambiar el curso del destino y escribir primero sobre este asunto. En el desarrollo ágil, la historia de usuario es un sustituto más ligero para lo que han sido nuestros medios tradicionales de especificar requisitos de software: documentos de especificaciones de requisitos de software, especificaciones de casos de uso y similares.
Ejemplo 1: La historia de usuario “Leer un libro”
Pensemos en una historia de usuario como una manera de dejar un legado, algo que trascienda más allá del tiempo, por ejemplo, de un proyecto y que permita que las culturas sobrevivan. Para ello, las historias tienen que ser simples, cortas, fáciles de entender y de aceptar y de franca recordación sin que tengan que escribirse todos sus detalles. Ese es el gran poder de las historias de usuario. Veamos, por ejemplo, la siguiente historia de un caso no software pero que ilustra perfectamente la estructura y comportamiento de una historia de usuario:
Como: crítico literario
Quiero: leer un libro
Para: escribir una reseña sobre el libro
Estos tres elementos conforman el núcleo de toda historia de usuario. En el primero (Como) se establece quién es el usuario o grupo de usuarios que “intervienen” en la historia, típicamente es un rol de usuario, en el desarrollo de software este elemento responde a la pregunta “quién usará la funcionalidad” descrita por esta historia. El segundo elemento (Qué) es la actividad, el eje de la historia, qué hace el usuario en la historia. Y el tercer elemento (Para) es el propósito de la historia, la meta que quiere alcanzar el usuario al ejecutar la historia. Todos, en conjunto, describen una finalidad, más que un requisito.
Definición
En resumen, una Historia de Usuario es una corta declaración de intención que describe algo que el sistema necesita hacer para el usuario. Se describe desde el punto de vista de quien usará la funcionalidad, es decir, su usuario. Pero ya que definimos qué es una historia de usuario, dejemos claro también qué no es: no es una especificación detallada de requisitos de software, algo que el sistema debe hacer, es más bien, un contrato negociable de intención que indica que el sistema necesita hacer algo más o menos así.
Algunas características de las historias de usuario son:
  • Son cortas y fáciles de leer, entendibles por los desarrolladores, interesados y usuarios
  • Representan incrementos pequeños de funcionalidad valorada, que puede ser desarrollada en un período de días o semanas
  • Son relativamente fáciles de estimar porque el esfuerzo de implementar la funcionalidad puede determinarse rápidamente
  • No se llevan en documentos grandes o pesados, sino más bien en listas organizadas que pueden ordenarse más fácilmente y reordenarse a medida que se descubre nueva información
  • No se detallan al principio del proyecto, sino que se elaboran sobre una base JIT – evitando así especificidad demasiado pronto, retardos en el desarrollo, inventario de requisitos y una declaración sobre-restringida de la solución.
  • Necesitan poco o ningún mantenimiento y se pueden desechar con seguridad después de la implementación
  • Las historias de usuario, y el código que se crea rápidamente a continuación, sirven como insumo para la documentación, la cual también es elaborada de manera incremental.

Ejemplo 2: La historia de usuario “Ingresar a la red social”
Un aspecto que viene con la simplicidad y el tamaño relativamente pequeño de las historias de usuario es que, por lo general, representan funcionalidades parciales, es decir, no indican funciones o procedimientos complejos y grandes que el sistema debe hacer. Por ejemplo, podríamos tener una historia llamada “Ingreso Básico a la Red” para especificar la entrada a una red social en Internet. El usuario es un “miembro de la red” y lo que hace más habitualmente este miembro es compartir enlaces con sus contactos. La historia luciría más o menos así:
Como: miembro de la red social
Quiero: ingresar a la red
Para: compartir un enlace
La “Narración” de las Historias de Usuario
Pero y ¿dónde están los detalles de la historia de usuario? ¿Cómo sabemos que efectivamente la historia descrita en el ejemplo anterior es simple y representa una funcionalidad parcial? ¿Cómo ingresa el usuario a la red? Estos pormenores se dan durante la Conversación y se especifican en los Criterios de Aceptación de la Historia. La Conversación representa una discusión entre el equipo, el usuario, el propietario del producto y los otros interesados, que es necesaria para determinar el comportamiento más detallado requerido para implementar la intención.
En el ejemplo citado, la conversación puede responder a preguntas como:
  • ¿Qué información necesita el usuario proporcionar al sistema para ingresar?
  • ¿Es obligatoria toda la información o puede ser parcial, esto es, hay datos opcionales?
  • ¿Qué ocurre cuando la información está incorrecta o incompleta?

Encontrar respuestas  a estas y a otras cuestiones relacionadas delimita la funcionalidad de la historia. Por ejemplo, en una primera entrega del software o salida a producción del mismo, podemos acordar con los usuarios tener solo la funcionalidad básica de ingreso, de allí el nombre de la historia establecido en la sección anterior. O sea, solo se solicitará un nombre de usuario y una contraseña con algunas características. A continuación, el sistema validará que el par nombre de usuario + contraseña coincidan y permitirá el ingreso del usuario, nada más. En caso contrario mostrará un mensaje advirtiendo la imposibilidad de ingreso a la red.
Entre tanto, los criterios de aceptación, llamados también Confirmación, representan las condiciones de satisfacción que se aplicarán para determinar si la historia cumple o no la intención así como los requisitos más detallados. Es precisamente la Prueba de Aceptación del usuario, que muestra cómo el usuario confirmará que la historia se ha implementado a su entera satisfacción. Los flujos alternativos en la actividad, los límites de aceptación y otras clarificaciones deberían capturarse junto con la historia. Muchos de estos se pueden convertir en casos de pruebas de aceptación u otros casos de pruebas funcionales, para la historia.
En la historia “Ingreso Básico a la Red”, estos criterios de aceptación podrían incluir:
  • El nombre de usuario es la dirección de correo electrónico del usuario.
  • La contraseña debe contener letras y números.
  • La contraseña debe ser de al menos 8 caracteres y máximo de 32.
  • El usuario ya debe estar registrado en la red social.
  • Si la contraseña no coincide con el nombre de usuario, el sistema mostrará el mensaje “Combinación incorrecta de correo electrónico/contraseña”.
  • Entre otros.

Notamos de inmediato que en esta historia “Ingreso Básico a la Red” no se estableció nada acerca de olvido de la contraseña o del nombre de usuario, o qué ocurre luego de mostrar el mensaje sobre datos incorrectos, o de cambio de contraseña o de otras funcionalidades adicionales al ingreso como “No cerrar sesión”, restablecer la contraseña, usar el número de teléfono móvil en vez del correo electrónico para ingresar o si la cuenta se bloquea al hacer varios intentos de ingreso fallidos y qué se debe hacer para restablecer el acceso, entre muchas otras cosas que giran alrededor del ingreso a la red. Estos detalles pueden hacer parte de otras historias a construirse más adelante para la versión actual del producto o para otras versiones sucesivas del producto.
Lo que hicimos con este ejemplo fue encontrar la historia de mayor valor para el negocio, es decir, esa funcionalidad o parte de la funcionalidad que será usada la mayor parte del tiempo por los usuarios y que, por consiguiente, permite obtener el máximo valor de negocio o el retorno de inversión más rápidamente posible. Recordemos que cuando se trata de desarrollo de software, las prácticas ágiles lo son porque permiten entrega rápida de valor. Hablaremos de este asunto en otra oportunidad porque me parece vital a la hora de acoger los principios o pilares ágiles.
Ejemplo 3: La historia de usuario “Quiero publicar una entrada básica de blog”
Veamos un ejemplo completo de una historia de usuario relacionada con la creación de blogs y la publicación de entradas al blog.
Carta:
Como Bloguero (<rol de usuario>) quiero ser capaz de publicar entradas en un blog (<lo que hago con el sistema>) para aumentar mi credibilidad y posicionarme como experto en el área de mi interés (<valor del negocio que recibo>).
Conversación:
P1. ¿Cuál es su área de interés? (El equipo al Bloguero)
R1. El área de mi interés es la literatura contemporánea hispanoamericana
P2. ¿Cuál es el público esperado?
R2. El público esperado es el compuesto por jóvenes y adultos
P3. ¿Cuál es la frecuencia de publicación?
R3. El objetivo es publicar una entrada quincenal
(Sigue…)
En el caso de Scrum, esta conversación se da típicamente durante la planeación del sprint, al principio del mismo, y durante el sprint.
Confirmación (criterios de aceptación): 
El contenido de las entradas debe ser texto principalmente
El sistema debe permitir entradas de hasta tres mil palabras
Cada entrada debe llevar un título de hasta 256 caracteres
Cada entrada debe publicarse en una página separada
(Sigue…)
Este esquema estructural de la historia de usuario es lo que se conoce como la “Aliteración Carta, Conversación, Confirmación”, propuesta por Ron Jeffries, uno de los co-creadores de eXtreme Programming o XP.
¿Cuándo se usan las historias de usuario?
Dado su carácter de simplicidad y tamaño (pequeño), la poca información explícita que contienen, las historias de usuario se usan o son beneficiosas cuando hay requisitos cambiantes, lo que ocurre la mayor parte del tiempo, pero y más importante, cuando los usuarios o representantes de estos están disponibles sin protocolo para que el equipo de desarrollo resuelva todas las inquietudes que se le presenten mientras convierten la historia en funcionalidad. En Scrum, por ejemplo, ese representante de los usuarios e interesados en el producto es precisamente el Dueño del Producto.
En otros artículos proporcionaré más ejemplos, buenas prácticas para identificar y documentar historias de usuario y hablaré de los principales atributos de toda historia de usuario, agrupados bajo las siglas INVEST.

Otros artículos de esta serie:

Sobre los atributos INVEST de las historias de usuario:

Escribiendo Historias de Usuario Altamente Efectivas, 1 - Introducción
http://www.gazafatonarioit.com/2013/07/escribiendo-historias-de-usuario.html

Escribiendo Historias de Usuario Altamente Efectivas, 2 - Independiente

http://www.gazafatonarioit.com/2013/08/escribiendo-historias-de-usuario.html

Escribiendo Historias de Usuario Altamente Efectivas, 3 - Negociable

http://www.gazafatonarioit.com/2013/08/escribiendo-historias-de-usuario_12.html

Escribiendo Historias de Usuario Altamente Efectivas, 4 - Valiosa (y Valuada)

http://www.gazafatonarioit.com/2013/08/escribiendo-historias-de-usuario_19.html

jueves, junio 27, 2013

Vademescrum, Sección I: El Scrum Master 1

El Vademescrum
No se trata de un lapsus calami ni de ninguna charada. Simplemente usé un procedimiento morfológico para crear una nueva palabra cuyo significado se hará evidente en breve. Usando el formato de la Academia de la Lengua, podemos decir que Vademescrum proviene de Vademécum (obra de referencia que contiene las nociones más importantes de una materia, ya sea ciencia o arte) y de Scrum (marco de trabajo liviano y adaptativo para desarrollo iterativo e incremental de software). El Vademescrum es, por lo tanto, una especie de marco referencial de Scrum y de sus componentes.
Vademescrum, Sección I: El Scrum Master 1
Entrando en materia, el Scrum Master es quien inspira los valores y las prácticas de Scrum en todo el equipo Scrum y, junto con otros Scrum Masters, en la organización. Es quien debe llevar al equipo a jugar Scrum Extremo y que lo haga a su máxima capacidad. El SM es como el médico que prescribe una receta o régimen a su paciente (el equipo Scrum) y se asegura de su cumplimiento y, aunque el SM no tiene autoridad sobre el equipo, sí tiene autoridad sobre el proceso Scrum que se sigue, por ejemplo, puede tomar la decisión de cambiar la duración de los sprints.
El SM también busca en las entrañas del proyecto y del equipo para encontrar los motivos por los que algo salió mal, por ejemplo, si no se entregó software potencialmente distribuible, probado y funcionando, al final de un sprint, o si el equipo no logró la velocidad esperada, o simplemente el por qué no se alcanzó la definición de Hecho (Done), o que los miembros del equipo no estén “anclados” en roles específicos. El Scrum Master también sirve como un escudo insalvable del equipo de interferencias externas, por ejemplo, cuando un interesado quiere modificar el alcance o la duración de un sprint, o ambos.

La guía de Scrum dice además que:
“El Scrum Master es el responsable de asegurar que Scrum es entendido y llevado a cabo. Los Scrum Masters hacen esto asegurándose de que el Equipo Scrum trabaja ajustándose a la teoría, prácticas y reglas de Scrum. El Scrum Master es un líder servil, al servicio del Equipo Scrum. El Scrum Master ayuda a las personas externas al Equipo Scrum a entender qué interacciones con el Equipo Scrum pueden ser de ayuda y cuáles no. El Scrum Master ayuda a todos a modificar estas interacciones, para maximizar el valor creado por el Equipo Scrum.”
Ahora bien, cuando un Scrum Master se une a un equipo, debe recordar que está allí para servir a:
  1. El Dueño de Producto
  2. El Equipo de Desarrollo
  3. La Organización

Para ello el SM debe tener en cuenta no solo el nivel de madurez en Scrum del equipo y de la organización, sino la capacidad de los miembros del equipo para obrar bajo el manto del espíritu Scrum. Esto quiere decir que el SM debe interactuar con cada persona en el equipo tanto como sea posible y promover la interacción entre ellos ya que, como recordarán, “valoramos individuos e interacciones sobre procesos y herramientas”.
En principio, no es buena idea que el SM haga cambios profundos en la Forma de Trabajo del equipo porque esto podría disminuir considerablemente su velocidad; en cambio, el SM debe considerar acompañar y guiar al equipo hacia el éxito constante. También debe lograr que haya confianza entre todos los miembros del equipo y que ellos tengan confianza en su SM, tal y como un paciente confía en su médico de cabecera.
Otras indicaciones que debe tener en cuenta el Scrum Master son:
  • Soportar activamente el proceso de adopción, adaptación y mejoramiento de prácticas ágiles en la organización.
  • Entender lo bueno y las mejoras que el equipo está buscando.
  • Tratar de establecer una comunicación abierta con el Dueño del Producto.
  • Interactuar con otros SM e identificar los desafíos que enfrentan.
  • Constantemente inspeccionar, ser transparente y adaptar, es decir, promover los pilares de Scrum.
  • Entrenar al equipo, entrenarlo y luego entrenarlo más. Cuando esté cansado de entrenar al equipo, entrenarlo en algo más. Ser el mentor que todos esperan que sea.
  • Promover la comunicación abierta.
  • Resaltar cuando el equipo alcance hitos de adaptación y mejoramiento.
  • Preguntarle al Dueño del Producto por 2 o 3 cosas que él/ella piense que no están bien, dañadas o que no están funcionando o simplemente con las que no está feliz.
  • Hacer lo anterior, pero con el Equipo de Desarrollo.
  • Mostrar a todos como planea corregir estos aspectos con la mayor brevedad.
  • Entender la cultura y el contexto del equipo.
  • Identificar oportunidades de mejora y facilitar y fomentar el mejoramiento.
  • Promover la retrospectiva al final del Sprint e, incluso, durante el Sprint.
  • Finalmente, pero no menos importante, hacer que el equipo tenga acceso rápido a una buena máquina de bebidas de café, esto también resuelve muchos asuntos.

Contraindicaciones
Esta es la primera entrega de este Vademescrum, volveré con más. Mientras tanto es importante tener claro que un SM hace mucho más de lo que enumeré aquí. Una persona debe preguntarse, ¿cómo me llegó la idea de convertirme en Scrum Master? Y también, ¿dónde consigo la experiencia necesaria y suficiente para hacerlo bien? ¿Dónde y cómo puedo aprender más? Asimismo debe cuestionarse quién le enseña.
Es un hecho, en estos días parece que Scrum Masters con toda esa experiencia son concebidos en cursos de 2 días y un examen de selección múltiple. Al final, caen en el olvido sin que nadie en el equipo se haga cargo. Es toda una experiencia misteriosa que se puede dominar sin antes pasar por las etapas clásicas de aprendiz –> practicante –> practicante -> experto –> entrenador -> mentor y sin que se extienda el manto ágil de Scrum sobre el equipo y la organización.

Lecturas Adicionales

Scrum Fundamental lo encuentran en este mismo Gazafatonario, en:

La lista de verificación de Scrum la encuentran en:

Mitos, Monstruos, Leyendas Urbanas y otros Desvaríos de Ágil y Scrum

Scrum Orgánico para Iniciantes