De valor, historias técnicas y mantenimiento

A veces una reunión de la comunidad te genera un debate interno una revisión de tópicos que ya se habitan visto antes pero que conviene reflexionar y visitar de nuevo, así en la ultima reunión de Agile Perú Cynthia presento como tema principal si existían las historias técnicas, planteándose los siguientes conceptos clave: los componentes técnicos dependen o tienen que depender de un requerimiento de valor de negocio, siendo mayormente tareas y no deberían ser considerados como “historias” puesto que estas son una base para conversar, siendo clave el reflexionar valor de negocio que se le deja al cliente si al día de hoy se acaba el proyecto.

El debate posterior fue interesante, se comento que de haberlas no se debería llamarla “historias” sino “epicas” “enablers”, que si lo que importa únicamente es el negocio, lo cual me ha derivado a unas reflexiones que quiero compartir con ustedes.

Ante todo, hay que precisar ¿a que llamamos historias técnicas? En mi experiencia creo que corresponde llamar así a las actividades técnicas (sorry por lo redundante) que no se pueden subordinar o mapear directamente a requerimientos de negocio, siendo así ¿deberíamos considerar como tal al código que implementa una funcionalidad o historia de usuario? para respondernos planteémonos el caso de que  por X razones debemos escribir un script para conectarnos a una BD externa a fin de lograr realizar una consulta para uso de nuestros usuarios, pues no… no es historia técnica a pesar de su complejidad ya que hay una vinculación directa con un historia de usuario, lo contrario pasa con actividades tales como refactorización, configuración de infraestructura, etc, procesos que por su naturaleza transversal No deberíamos forzarlos (como muchas veces se insiste) a que encajen como tareas hijas de una historia de usuario.

Siendo así ¿que tipos de historias técnicas hay? pues Alexander Menzinsky nos recuerda una muy razonable categorización (**):  Arquitectura, Infraestructura de Producto, Infraestructura del Equipo, Refactorización y Spikes (investigación).

Como pueden darse cuenta, mi posición es a favor de la “existencia” de las historias técnicas como la ha sido desde hace unos años, ya entonces insistía en su lugar debido a la necesidad de hacer visible el “como” se llega a la necesaria entrega de valor que se propugna desde la agilidad, los años transcurrido han reafirmado mis posturas visto que las tendencias que ya comentaba entonces respecto al descuido al componente técnico no han hecho sino acrecentarse, siendo que sin pelear por la visibilidad no se lograra el cambio. ¿Y por qué es importante esa visibilidad? pues, como me comentaba Omares como si las historias (tradicionales) se hubiesen hecho para mostrar el exterior y no el interior… ” por lo que “hay una especie de vacío sobre donde poder ver dichos aspectos (técnicos) y que se valoren” ya que “las historias están hechas para conversar con el cliente y entenderse….pero la parte técnica, no la comprenderá mucho pero la valorara de la forma que pueda y en ese sentido la relegara hasta que pueda aprender sobre la importancia de esta en algún momento“, lo cual nos lleva a algo que sale a nuestras conversaciones de tanto en tanto, la importancia de explicar adecuadamente el rol estos componentes para que el Producto Owner acepte su inclusión en los sprints que vayan saliendo, y claro… ¿como se puede iniciar el dialogo sobre estos componentes si no están visibles? (*).

Dicho esto queda pendiente sobre como se deben visibilizar y nombrar, y reitero que no debe forzarse su subordinación a una historia de negocio, sino asumir su rol transversal en la generación de valor con calidad y su impacto en la capacidad del equipo, ahora… que no te guste el nombre de “historias técnicas” es otra cosa (a mi si, aunque si no te gusta usa otra opción, pero siempre hay que recordar que la nomenclatura tiene impacto en como entendemos las cosas), pero no por eso hay que retirar su lugar visible dentro de los flujos de un equipo, muy por el contrario toca potenciarlo como muestra Henrik Kniberg:

Dicho esto, toca tener un necesario balance para evitar que por mor de la excelencia técnica nos encontremos atrapados en ciclos de refactorización sin generación de valor como ironiza Angel Medinilla:

 

Así que toca seguir dando vueltas y recalcar la importancia de la visibilidad de los componentes técnicos dentro de nuestros backlogs y sprints, como parte importante de la calidad del software y el valor que entregamos.

Y ya que hablamos de valor, no puedo dejar de mencionar una conversación en la que se hablaba de como pasar de los ciclos de desarrollo y entrega a la etapa en que un software es mantenido, en ese momento se comenzó de hablar de “equipos de mantenimiento” y de “equipos que generan valor”, lo cual me hizo un ruido instantáneo por lo que tuve que manifestar mi postura respecto a que ese lenguaje involucraba que los equipos de mantenimiento NO generaban valor, siendo que consideraba que hay valor en el sostenimiento de las operaciones del negocio, y que encima agravaba las barreras dentro de la organización, generando naturales recelos que no hacen sino bloquear los objetivos de la organización, es que las palabras cuentan, y mucho.

(*) Mas allá del caso obvio de los aspectos de Infraestructura de Producto, como puede ser la instalación y configuración de un servidor, escenarios sobre los cuales también he escuchado defensas de colocarlos como subordinados a una historia técnica.

(**) Gracias a Guino por apuntar que quien planteo esta categorización fue Robert Galen.

Tu buen nombre cuenta en las comunidades online

Como ya sabran una de mis aficiones es la fotografia y este año en mis viajes he estado usando mi nueva Sony A-100, y la verdad es que estoy encantado con ella (de lo cual tendre que hablar en breve) pero siendo como es una Reflex amateur, no cuenta con una empuñadura (grip) vertical, lo cual hace que al tomar fotos verticales uno deba colocar la mano en posiciones no muy practicas (*).

Situacion curiosa, pero justamente la habilidad del emprendedor esta en encontrar un nicho de negocio en situaciones como esta y es lo que hizo la empresa coreana Dicain al ofrecer empuñaduras tanto para la A-100 como para su predecesora la Konica Minolta 5D.

Entonces tenemos los primeros pasos: encontrar una necesidad insatisfecha y ofrecer una solucion para ello, pero eso si bien permite empezar un negocio, no garantiza su continuidad, la solucion: calidad y atencion al cliente.

Y es eso lo que han tratado de hacer estos coreanos, quienes han comprado sus productos no hablan sino maravillas de la calidad de las empuñaduras, y asi mismo quienes han comprado directamente al fabricante (en Corea!!!) dan buenas referencias (referencias que como es logico animan a otros potenciales clientes) sobre la atencion que sus encargados dan con relacion al pago y al seguimiento de los envios. Y creanme, he pasado buen tiempo en los foros de fotografia como para saber cuan exigentes y meticulosos pueden ser quienes llevan tiempo en esta aficion, asi como la gran importancia que se da a la opinion de tus pares.

Como es logico iniciado el ciclo de ventas, la cosa es no decaer y por lo visto siguen en ese ritmo lo cual no hace sino ayudar a que mas fotografos se animen a comprar sus productos, lo cual tiene merito tratandose de un sector tan especifico. Ahora bien, es curioso que hasta el momento dicha marca no tenga una version en ingles de su website, lo cual logicamente limita su potencial de ventas por mas de que tengas la capacidad de exportar a todo el mundo, es interesante que aun a pesar de esa limitacion ellos hayan podido ganar cierta imagen en este mundillo, pero esa situacion no se puede sostener por mucho tiempo, so pena de no poder sostener el exito logrado hasta el momento.

Este pequeño ejemplo nos permite darnos cuenta que si se hacen las cosas bien, enfocandose en el cliente, los foros y comunidades online pueden ser de ayuda (aun sin proponerselo) para la consolidacion del prestigio de una marca. En un tiempo en que el consumidor tiene tantas herramientas para formarse una opinion, que la opinion sobre un producto puede destrozarla instantaneamente, la respuesta es calidad y enfocarse en la atencion al cliente, utilizando a las comunidades de usuarios a fin de generar masa critica.

MinoltaSpain: Grip para sony alpha
MinoltaSpain: ANÁLISIS: DICAIN VG-II – MINOLTA 5D VERTICAL SHUTTER GRIP
Dpreview: Ordering from Dicain

(*)Como nota debemos comentar que la nueva Sony A-700 al ser un modelo de la gama superior si cuenta con ese accesorio como opcional.