Pages Menu
Categories Menu

Posted by on Mar 28, 2016 in General | 10 comments

¿Deben existir las Historias Técnicas?

“Siento predilección por los disidentes, capaces de hacer de su existencia un viaje personal con destino incierto, que permanecen firmes con sus contradicciones a cuestas. No me gustan los creyentes de verdades absolutas, incapaces de cambiar una coma el guión de su vida.”

— Loquillo

En una disciplina tan cambiante como la nuestra, de tanto alcance e impacto, es imposible pretender encasillar todo bajo definiciones cerradas y evitar que haya múltiples, y libres, maneras de ver las cosas.

Está claro que si piensas “A” no vas a compartir las ideas de los que piensan “B”, pero al igual que “lo cortés no quita lo valiente”, que no compartas una idea no implica que NO tengas que respetar, e incluso no tengas que increpar, a quien la dice.

El área de lo que podríamos llamar “agilidad” es un ejemplo más de ello, de múltiples maneras, muchas encontradas, de ver las cosas. Si Nadie sabe lo que significa agilidad (en lo que refiere a buscar una definición que lo acote) y donde, además, las metodologías ágiles no existen, imagina qué debate y diferentes interpretaciones puede haber de muchos conceptos bajo el paraguas ágil.

Un ejemplo de ello es el debate que se originó la semana pasada, en plena Semana Santa, en Twitter, alrededor del, aparentemente simple, concepto de “Historia Técnica”, con casi 300 Tweets de ideas coincidentes y divergentes sólo sobre este “artefacto”.

Salvo que se me colara algo previo, el debate se originó con este Tweet, que te dejo más abajo, de Ron Jeffries.

Los que conoceis a Ron Jeffries ya sabréis que es muy dado a debates por Twitter, y que no se corta, y para los que no, es uno de los firmantes del manifiesto ágil y uno de los autores de eXtreme Programming. Yo tuve la oportunidad de verlo hablar en Washington D.C., en el #Agile2015, y de poder preguntarle por el #noestimates (esto es otra historia).

Resumidamente, se originó un debate posterior que  giraba entorno a si las “historias técnicas” son necesarias o son un problema encubierto.

Como te puedes imaginar, entre tanto Tweet hay ideas, muchas, y algunas muy interesantes, de todo tipo, y lo que leerás a continuación es mi personal síntesis del gran debate. Algo se me puede haber colado. Vamos a ello.

Los que defienden, Ron Jeffries entre otros, que la “historia técnica” es un problema, idea con la que personalmente me encuentro más identificado, argumentan que no existe ninguna justificación para que se pongan en el “Product Backlog”, herramienta que gestiona el Product Owner, que contiene “cosas” que aportan valor a los usuarios, necesidades de carácter técnico, es decir, no aplican “cosas” que no aportan valor directamente al usuario.

Poner en un Product Backlog cosas como “Refactorizar” o “Disminuir la deuda técnica” puede esconder el hacerlo sólo para ese Sprint, que las cosas se hayan ido de madre, puede hacer evitar que las cosas técnicas, concretamente las relativas a calidad, sean algo rutinario, que estas llamadas “Historias Técnicas” deberían estar en el DoD (En un proyecto ágil, acordar una buena definición de lo que significa terminado (el done)), que no “hay que pedir permiso” para hacer Test o Refactorizar, etc.

Los que argumentan que si debe haber “historias técnicas”, hablan de que no hay que obsesionarse con dejar al negocio fuera de los aspectos técnicos, como si estos no existieran, y que así se les mete en la importancia de ello, y que deben ser conscientes del coste que supone hacer esas “historias técnicas”, etc.

¿Cómo lo ves tú?

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.
Javier Garzás

10 Comments

  1. Es que hay historias e historias, por ejemplo, que llegue un nuevo servidor y que sea “nuestro turno” de prepararlo luego haber pasado por los amigos de infraestructura… no es algo que podamos repartir entre varios aspectos de negocio. Lo mismo, una tarea de investigación, por ejemplo.

  2. Hay de todo creo, pensaba en temas que tienen implicancias directas del negocio para salir, por ejemplo, haces un sitio y el nombre del mismo no lo tienes registrado o bien necesitas comprar un certificado https. En tales casos la compra necesita visarse por ente de negocio, porque no todo es ágil en la organización. En tales casos, no me parece mal que se incluya. Pero claro, depende de la organización

  3. Hay temas que un P.O. puede obviar o dar por sentado, como por ejemplo, que la aplicación sea segura o que permita x cantidad de usuarios concurrentes. En ese caso, las historias técnicas podrían ser necesarias, o se pueden poner como tareas adicionales en una historia.

  4. Hay temas que un P.O. puede obviar o dar por sentado, como por ejemplo, que la aplicación sea segura o que permita x cantidad de usuarios concurrentes. En ese caso, las historias técnicas podrían ser necesarias, o se pueden poner como tareas adicionales en una historia.

    • O son más bien “restricciones” que están en el DoD…

  5. Muchas veces, el negocio, con el objetivo de poder cumplir sus objetivos y entregar rapidamente las cosas, acepta soluciones poco prolijas, sabiendo que eso tiene un costo en el futuro.
    Cuando estos puntos fueron bien explicados al PO y consensuados, mas que nada que ese tiempo “ganado” hoy, es tiempo “perdido” en el futuro, las stories técnicas si deberían existir en el backlog, ya que tienen un valor de negocio justificado y ademas, si la calidad es un valor de negocio, es un concepto que atraviesa a todos los roles del scrum.

  6. Yo no creo en las “historias técnicas”, el problema aparece cuando el P.O. o algún otro stackeholder, sin los conocimientos técnicos necesarios, se permite el lujo de opinar sobre el esfuerzo de realizar las cosas. Como se comenta en el post, yo creo que aquellas tareas referentes a la calidad, deben formar parte del DoD y el equipo las debe tener muy presentes a la hora de estimar, pero no creo que sea una buena práctica añadir este tipo de historias al backlog sólo por justificar el tiempo que lleva su realización.

    • Lo dicho anteriormente, si se va a pasar del servidor provisional de BD a los que seran definitivos en el pase a producción… ¿amerita o no una historia tecnica? ¿Como lo diluyo entre las historias de negocio?

  7. El testeo sí que creo que debería ser un criterio de aceptación de una historia de usuario, pero en algunos casos sí que hay que hacer trabajo que no aporta valor al usuario y que no veo otro sitio que sea una historia técnica. Por ejemplo, al arrancar el proyecto, hay que crear una infraestructura para el mismo, que, según la organización y proyecto, puede incluir tareas como darlo de alta en una intranet, crear el sistema de control de versiones, montar el framework oportuno, etc.

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This