“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.
OK, maybe there is such a thing as a “technical story”. But that thing you want to do? It doesn’t call for a technical story.
— Ron Jeffries (@RonJeffries) 22 de marzo de 2016
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ú?
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024
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.
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
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.
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…
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.
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?
Tienes el Sprint Backlog para ello…
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.
Yo no se si estoy de acuerdo o no con historias tecnicas.. pero como QA mr pregunto.. como testeamos una historia tecnica , sin criterios de aceptacion.. que dice algo como «get function now use async method to storage in db»?. Ed imposible poder entender algo asi para un QA. Que piensan?