archivo

Archivos diarios: abril 4, 2014

En mis artículos utilizo mucho los términos sistemas de información, producto, etc… en referencia al software que estamos desarrollando en un proyecto.

Hay quienes piensan que la terminología más adecuada debería ser solución porque es precisamente eso lo que estamos intentando hacer: resolver una problemática de un cliente (interno o externo).

Es muy importante tener en cuenta ese aspecto: el cliente realiza una inversión para tratar de mejorar la calidad y cantidad de los resultados de alguna de sus áreas de negocio, para tener una visión global de la información y extraer conocimiento de ella, etc…

A alto nivel su expectativa es mejorar y nuestro objetivo debe ser dar una solución a esa expectativa.

Esta sencilla ecuación se rompe en el momento en el que el proveedor centra su objetivo en el beneficio y no en las expectativas del cliente, pasando a ser el proyecto su solución y no de quién la está pagando. Esto es muy común y hace mucho daño al negocio y a nuestra profesión porque la calidad final del resultado se resiente y la imagen de todos (porque se nos mete a todos en el mismo saco) queda muy deteriorada.

No me invento nada, en esta época de crisis, muchas organizaciones en lugar de invertir en TIC para tratar de conseguir ventajas competitivas, huyen porque no creen en un retorno de la inversión.

Las empresas trabajan para ganar dinero, hasta ahí de acuerdo, pero esa aspiración legítima no debe justificar que el cliente sea el sacrificado.

En muchas ocasiones el cliente, ya sea, por falta de implicación, por no haber elegido el momento más adecuado para realizar el proyecto, por la aparición de otras prioridades que deben atender, etc…, es culpable de que los resultados no sean los esperados, pero en otros muchos casos sí que cumple, sí que trata de poner los medios para que el proyecto vaya adelante y sin embargo no es tratado justamente por el proveedor.

Mi recomendación es que las historias de usuario estén desarrolladas antes del inicio del sprint, así como que tengamos disponibles todos aquellos inputs que necesitamos en el mismo (por ejemplo, si una de las actividades consiste en una carga de datos, se necesitará tener acceso a ese origen de datos, si necesitamos conocer un determinado dominio de datos, necesitaremos que nos lo indiquen, etc…).

¿Qué es tener la historia de usuario desarrollada? Saber qué es lo que hay que hacer.

¿Cuál es el nivel de detalle que se necesita? Lo mismo. El que te permita saber qué hay que hacer, y eso puede variar en función de cada historia de usuario. No se trata de una especificación detallada de requisitos, tampoco de casos de uso (ahora bien, si entiendes que lo tienes que hacer así o que la historia de usuario lo necesita, adelante), se trata de tener la suficiente información para hacer una buena estimación y para conocer si necesitas algún tipo de input (para de esta forma tenerlo antes de empezar).

¿Eso quiere decir que no hará falta comunicación con el responsable funcional durante el sprint? No. La comunicación es esencial, la base. Una cosa es saber lo que hay que hacer y otra conocer todos los detalles.

¿Cuándo se debería hacer esa tarea? Este refinamiento de la pila de producto (porque al conocer más detalle se puede precisar mejor el valor de la historia de usuario y, en consecuencia, su prioridad), se hace mientras se está ejecutando un sprint.

¿Mientras se ejecuta un sprint? Sí, lo que no quiere decir que esté contemplada en el sprint. Decides tú. Puedes dedicar capacidad dentro del sprint a realizar esta actividad o hacerlo como una actividad paralela. Personalmente me gusta más la segunda opción, si bien, es importante que quien o quiénes la hagan participen en el sprint (lo que se hace es detraer de la capacidad total del sprint un porcentaje de estas personas para dedicarlo a generar el detalle de las historias de usuario).

¿Y si no se tiene detallada una historia de usuario y se quiere incluir en el sprint? Se puede hacer, ¿por qué no?, lo mismo la historia es tan simple que con su propia descripción ya se entiende qué es lo que hay que hacer (esto sucederá, sobre todo, cuando ya se tiene el producto bastante maduro).

Pero tampoco es necesario que la historia sea sencilla, también se puede hacer con otras más complejas, teniendo en cuenta que será más complicado acertar en la estimación, lo que puede afectar, si nos equivocamos, al cumplimiento de compromisos en el sprint.

Y no solo eso, al no tener la historia de usuario detallada, estamos dependiendo de que el responsable funcional pueda dedicarnos el tiempo que necesitamos para obtener la información que necesitamos o para que nos generen los inputs necesarios. Esto nos puede romper la producción y no solo afectar al desarrollo de esta historia, sino de otras que también formen parte del sprint.