Buscar en Gazafatonario IT

domingo, septiembre 01, 2013

Gerentes de Proyectos de software, ¿una especie en vías de extinción?


“En los próximos treinta años, sin hacer ningún  ruido, un día dejaremos de ser los seres más brillantes de la tierra”. James McAclear.
Gerentes de Proyectos de software, ¿una especie en vías de extinción?
Imagen de Mark Garlick/Science Photo Library
Hace poco, durante la sesión de preguntas y respuestas de una conferencia sobre transición al universo ágil y a Scrum que facilité con todas mis ganas, alguien del público censuró arduamente algunos de mis puntos de vista… Esta es su historia.
La pregunta
-         “Lucho, quiero referirme específicamente al asunto de la Gerencia del Proyecto en este mundo ágil que planteas” – comenzó diciendo con firmeza. “Afirmas que nosotros no necesitamos un Gerente de Proyectos si estamos empleando una metodología Ágil, específicamente si empleamos Scrum”
Aunque aun no sabía en qué iba a terminar aquello, no quería hacer parte de lo que venía a continuación. Empecé a pensar que el asunto podía convertirse en un ejercicio de semántica, en vez de uno de fondo, empezando con la definición de “nosotros” y la de “Gerente de Proyectos”.
-          Por ejemplo, – prosiguió ella, con un tono que rayaba en lo trascendental – dices que el Scrum Master es quien facilita las reuniones Diarias, la reunión de Planificación del Sprint, la Retrospectiva; es quien le da un empujoncito al Dueño del Producto para que sus historias estén a tiempo para la Planificación del Sprint; y es a quién acuden los miembros del Equipo cuando tienen problemas que no pueden resolver.
En un instante calculé muchas de las preguntas que podían resultar de aquel soliloquio y con preocupación noté que la referencia inicial al Scrum Master haría que entráramos a un terreno escabroso, a una discusión que podría exacerbar los ánimos de Ella y de algunos de los asistentes.
-          No tienes que llamar a esa persona un Gerente de Proyecto si no quieres – aseveró Ella con una modulación culminante, aunque con las mejillas rojizas, - y, en Scrum, esa persona es el Scrum Master.
Otra vez el Scrum Master. Sin duda, lo que venía era equipararlo con el Gerente de Proyectos tradicional.
-          Aun así, mucho de este trabajo se parece a la clase de cosas que hacen los Gerentes de Proyectos. – Ahí estuvo, no me equivoqué, pero antes de que pudiera pensar en algo más, siguió diciendo - El hecho de que un Gerente de Proyectos asociado con tipos diferentes de proyectos haga cosas que no son consistentes con Scrum no elimina la necesidad de que alguien haga esas cosas que parecen tan espantosas en los proyectos Scrum.
En cierto sentido tenía razón. Pero ¿y la pregunta?
-          Mi punto es, aunque no se llame Gerente de Proyectos, sí hay gerencia de proyectos en los proyectos Scrum. ¿Qué nos puedes decir al respecto? – Se sentó más tranquila que cuando se levantó para hacer el cuestionamiento. Es como si hubiese aliviado setenta y cinco minutos de ansiedad de un solo tirón, el mismo tiempo que tardó mi intervención.
La respuesta
Mi punto en cambio – pensé - es que embrollarse mucho con el vocabulario e insistir en que alguien que llena el rol de Scrum Master absoluta y positivamente no hace nada que se parezca al trabajo de gerencia de proyectos, no es un uso constructivo del tiempo. Es más lucrativo averiguar lo que se necesita hacer para que el proyecto sea exitoso… ¡Y hacerlo!
Sin embargo, quise iniciar mi respuesta dándole parcialmente la razón. Le dije que tal y como concebimos el proceso, un proyecto Scrum está inmerso dentro de un conjunto de actividades relacionadas que requieren habilidades más clásicas de un Gerente de Proyectos, como la negociación contractual, la puesta en marcha de la operación o la misma selección del equipo. En Scrum, el equipo se autoorganiza, pero no es capaz de autoseleccionarse, hay restricciones de disponibilidad de las personas, de habilidades necesarias y de motivación, entre otras, que deben tomarse en cuenta. Sí, es cierto que quien se pone en los zapatos del Scrum Master bien puede hacer estas cosas, en cuyo caso llamarlo Gerente de Proyectos (así como Scrum Master) tiene mucho sentido.
Mientras yo hablaba, miraba cómo la expresión de su rostro cambiaba; el tono rojizo que tenía durante su intervención se había disipado y sus mejillas volvieron a su color habitual. Incluso sonrió, asintió con la cabeza y le susurró algo que nunca sabremos a su compañero de la izquierda, aunque tuve la ligera desesperanza de que decía: – sí, ¡yo tenía razón! – En parte la tenía… pero solo si hubiésemos estado hablando de proyectos tratados con métodos tradicionales, no ágiles.
Mientras hacía la pausa para continuar, pensaba que esa pregunta ponía de manifiesto una vez más algo común en los procesos de transformación hacia lo ágil y era que, aun cuando creyeran que ya habían llegado al final del camino (¡somos ágiles, somos Scrum!), muchos todavía tenían un largo camino por recorrer antes de que realmente entendieran lo que significaba hacer Scrum y “ser ágil”. Imaginé a Ken Schwaber o a Jeff Sutherland interviniendo en la discusión, pero solo para argumentar que  ninguno de los roles en Scrum eran eufemismos para “Gerente de Proyectos”, y finalmente pensé que ninguno de ellos ni ninguno de los otros 15 personajes que firmaron el Manifiesto Ágil, entrarían alguna vez en una discusión como esta.
Pero – justo en este instante tuve la idea completa – quienes tratamos de aplicar Scrum adhiriéndonos a sus reglas tan íntimamente como podamos, sabemos que es el Equipo el que toma las decisiones y que el Dueño del Producto es el “familiar” más inmediato que los Equipos Scrum tienen a un(a) Gerente de Proyectos. – Ya estaba dicho, sentía que debía deshacer de raíz ese arraigo de las personas de quedarse en la mitad del proceso de renovación hacia la filosofía ágil.
La guía de Scrum dice textualmente: “El Dueño de Producto es el responsable de maximizar el valor del producto y del trabajo del Equipo de Desarrollo.” Y más adelante, en el mismo apartado sobre el Dueño del Producto, complementa: “toda la organización debe respetar sus decisiones.” Les recomiendo además el artículo “Scrum: Cediendo el mando y control AL EQUIPO” de mi colega Jorge Abad y con quien he abordado estos asuntos en la Comunidad Ágiles Colombia. Bien dice él que el “rol de la gerencia de proyectos queda inoperante y se convierte en un reto profesional pasar de gerente de proyectos a Scrum Master” [1]. Jorge se refiere a los Proyectos/Equipos Scrum. Le decía precisamente sobre esta aseveración que, aunque estuviera claro que el gerente de proyectos de hoy puede ser un Scrum Master, el trámite de ir de un punto a otro no es algo lineal y mucho menos algo que se pueda lograr durante el sueño.
En este punto de mi parlamento, no solo la expresión corporal de mi interlocutora, sino la de muchos en el auditorio, era de desconcierto. Así que debía anticiparme a sus preguntas.
La pregunta entonces es – continué – ¿cómo lograr esa metamorfosis? ¿Cómo hacer que ese cambio no se quede en un mero “regateo”, que no se quede en una evolución trunca o, dicho de otra forma, en una mera mutación involutiva? No queremos que el resultado sea algo así como “gerenscrummaster de proyectos”… como lo que sucede en La Mosca, aquella película de 1986, dirigida por David Cronenberg, con Jeff Golblum y Geena Davis.
Y la respuesta a esa pregunta es: dejarse abrazar por los valores y principios del Manifiesto Ágil, por los pilares de Scrum de Transparencia, Inspección y Adaptación, ese trípode que se constituye precisamente en el soporte de los Equipos Scrum, autoorganizados, esos que según la misma Guía de Scrum “eligen la mejor forma de llevar a cabo su trabajo y no son dirigidos por personas externas al equipo.” Además, “tienen todas las competencias necesarias para llevar a cabo el trabajo sin depender de otras personas que no son parte del equipo.
Me pareció que no había nada más que decir. Así que me propuse cerrar el tema diciéndoles que, de hecho, la conversión de los gerentes de proyecto actuales hacia otros roles era un factor de resistencia al cambio durante el proceso de renovación hacia “ser ágil” y esa resistencia normalmente redundaba en una crisis organizacional. Pero no había nada que hacer, buena parte, sino todas las responsabilidades del gerente se distribuyen en estos nuevos roles que hoy estamos jugando en Scrum. Por ejemplo, la visión y las guías del proyecto están a cargo del Dueño del Producto, el Equipo automaneja la organización diaria del flujo del proyecto, mientras que la facilitación y el entrenamiento son responsabilidad del Scrum Master.

Conclusión
Estoy seguro que a mi interpelante no le gustó esta respuesta, pero que le vamos a hacer. A algunos les sabe cruda la verdad. Lo que ocurre es que las organizaciones no se mueven rápida y fácilmente a Ágil/Scrum y tienen malos momentos consiguiendo velocidad y experiencia en los nuevos roles. El cambio es duro. Ágil no es una construcción de conveniencia; demanda un cambio radical del pensamiento tradicional acerca del desarrollo. Si una persona no puede verdaderamente adoptar los valores y principios del Manifiesto, entonces en mi opinión ellos son ADNS – Ágil De Nombre Solamente. ¿Eres tú un ADNS?
Lo otro que me inquieta son los certificados. Cuando escucho o leo a gente con CSM y CSPO, PSM o similares, y combinados con PMP o algo así, haciéndome preguntas o expresándose como lo hizo el personaje de esta historia, me pregunto si fueron al entrenamiento y obtuvieron las certificaciones simplemente para llenar sus Hojas de Vida. No parecen comprometidos con el pensamiento ágil o con los valores y principios del Manifiesto Ágil.
He tenido la colosal fortuna de trabajar con personas/colegas supremamente inteligentes, en proyectos de software extremadamente complejos; y ellos siempre me tienen en cuenta para resolver problemas comunes y no tan comunes pero peculiares en esta clase de proyectos; también quieren conocer mi opinión sobre ideas técnicas que los mantuvieran enfocados en los objetivos primordiales, es decir, los entregables del proyecto. Soy parte del equipo, no una figura de autoridad. Lo que hecho, en la práctica, es contribuir al éxito del proyecto y al triunfo del equipo, a la satisfacción del usuario. No importa nada más.
Con Ágil/Scrum simplemente lo estamos haciendo más frecuentemente, con mayor calidad y, sobre todo, con mayor entusiasmo y felicidad.
Referencias

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


lunes, agosto 12, 2013

Historias de Usuario Altamente Efectivas, 3

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

Cualidad :: Negociable

Historias de Usuario Negociables
Las Historias de Usuario se negocian entre los usuarios
y el equipo de desarrollo
Una buena historia de usuario permite que entre el negocio y el equipo del proyecto haya arreglos flexibles o un balance entre la funcionalidad a construir y las fechas de entrega. Un aspecto importante a tener en cuenta es que una historia de usuario se puede convertir fácilmente en dos o más, adicionando o eliminando criterios de aceptación, modificando el objetivo o valor del negocio de la historia y aun la misma actividad que implementa la historia. Los buenos equipos de desarrollo detectan a tiempo y rápidamente los aspectos que se pueden negociar de una historia con el usuario (por ejemplo con el Dueño del Producto) y establecen las razones por las cuales debería modificarse el alcance expuesto en una historia o la fecha de entrega de la misma.
Esta última puede ser en una iteración posterior, en una entrega (release) futura, o en una eventual versión que esté pendiente por definir. Una práctica útil en estos casos es clasificar las historias en:
  • Requeridas o críticas
  • Importantes
  • Opcionales
  • No se construirán

Esta clasificación también nos ofrece un marco de negociación. Incluso una tipificación de este tipo se puede aplicar rápidamente a cada criterio de aceptación de la historia, lo que permitiría ampliar el margen de negociación con los usuarios o con el negocio. Las historias requeridas son aquellas sin las cuales la solución no puede vivir (van en las primeras entregas); entre tanto, las importantes son aquellas sin las cuales el sistema puede vivir durante algún tiempo, es decir, podemos salir a producción sin estas, pero van en las entregas intermedias del proyecto.
Las historias opcionales, por su parte, son aquellas funcionalidades conocidas coloquialmente como las “buenas, bonitas y baratas”, es decir, aquellas que si hay tiempo y presupuesto se construyen y van en las entregas finales del proyecto. En ocasiones también es importante establecer funcionalidades que no se construirán debido quizás a restricciones de presupuesto o de tiempo o simplemente porque no tienen ningún valor para el negocio.
Historia Negociable 1
Como: Bloguero
Quiero: hacer una entrada al blog
Para: posicionarme como experto en un tema específico
Criterios de Aceptación:
  • Debo ser capaz de publicar contenido multimedia (imágenes y video)
  • El texto de la entrada debe ser enriquecido (que permita enlaces Web, formato, etc.)
  • La entrada se debe poder compartir vía redes sociales
  • La entrada se debe poder imprimir
  • La entrada se debe poder enviar vía correo electrónico

Durante la negociación podemos llegar a acuerdos con los usuarios, por ejemplo, en una primera iteración podríamos solo permitir la publicación de texto en la entrada, más adelante podríamos permitir la adición de contenido multimedia. En otra iteración, quizás en otra entrega, podremos permitir que la entrada se comparta vía redes sociales y por correo electrónico. Incluso podríamos llegar a la conclusión de no implementar la funcionalidad de impresión de la entrada y dejar simplemente que el lector imprima usando las características que vienen con su navegador Web.
Las cosas así, esta historia de usuario podría convertirse en:
ID: Hacer una entrada básica al blog
Como: Bloguero
Quiero: hacer una entrada al blog
Para: posicionarme como experto en un tema específico
Criterios de Aceptación:
  • El texto de la entrada debe ser enriquecido (que permita enlaces Web, formato, etc.)

Los demás criterios de aceptación estarán presentes en otras historias “Hacer una entrada al blog”, como por ejemplo:
ID: Hacer una entrada al blog para compartir
Como: Bloguero
Quiero: hacer una entrada al blog
Para: posicionarme como experto en un tema específico
Criterios de Aceptación:
  • La entrada se debe poder compartir vía redes sociales
  • La entrada se debe poder enviar vía correo electrónico

O esta otra:
ID: Hacer una entrada básica al blog con contenido multimedia
Como: Bloguero
Quiero: hacer una entrada al blog
Para: posicionarme como experto en un tema específico
Criterios de Aceptación:
  • Debo ser capaz de publicar contenido multimedia (imágenes y video)

Recomendaciones
La negociación de las historias de usuario es parte fundamental de todo proyecto ágil. Y como en todo proyecto ágil, es necesario tener a los usuarios, representados quizás por un Dueño de Producto, y al equipo de desarrollo, del mismo lado. Habrá una negociación fluida si el usuario está realmente interesado en el éxito del proyecto, si está dispuesto a comunicarse de manera efectiva y a trabajar con el equipo. Y tanto el usuario como el equipo de desarrollo deben tener en cuenta que las historias de usuario, incluyendo sus pruebas de aceptación, evolucionan iteración tras iteración. Además, el enfoque que se use para abordar y negociar los requisitos del negocio, también se puede aplicar a los requisitos técnicos o no funcionales.
Resumiendo, una historia de usuario no es un contrato firmado en piedra con sangre, más bien es una carta de intención de algo que el sistema debe hacer y cuyos detalles se abordan durante la conversación entre el usuario (Dueño del Producto) y el equipo de desarrollo. Y esto se hace justo antes de iniciar la construcción de esa historia, en el caso de proyectos conducidos con Scrum, esta negociación puede hacer parte de la Reunión de Planeación, pero no está supeditada a este marco de tiempo nada más, puede ocurrir en cualquier momento durante un sprint. Además, la negociación es una habilidad en la que deben trabajar los equipos de desarrollo, ya no es más un asunto que atañe solo a los comerciales de la organización de software.
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:
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:
Referencias
  • INVEST in Good Stories, and SMART Tasks

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


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/