Scrum – Comparte tu Backlog con el Cliente

Los mayores problemas que se producen en la gestión de proyectos se dan en el flujo de información, ocurre muchas veces que esta se tergiversa cuando pasa entre las diferentes personas que trabajan en el proyecto y al final se desarrolla algo que muchas veces no ofrece una solución para el problema presentado por el cliente. Esto hace que la relación con tu cliente se degrade y al final tu proyecto se demore haciendo que este tenga un mayor sobrecoste y perjudicando tu relación con el cliente.

Creo que todos conocéis la graciosa imagen que representa esto:

clip_image001

Un problema habitual se origina en el control de la entrada de información. Se dice, que normalmente debe existir una sola persona que trate con el cliente, yo pienso que esto es algo complicado de gestionar, sobre todo en grandes proyectos, en los que participan muchas personas, pues el cliente a veces, prefiere tratar con miembros del equipo de desarrollo con los que ha tenido mayor relación, con lo que la entrada de información puede originarse a través de los diferentes miembros del equipo y de esta forma las alteraciones con seguridad serán mayores, pues cada uno tendemos a interpretar la información a nuestra manera. Cuanto mas cercano se encuentra el equipo con respecto al cliente y mayor número de personas participan en el proyecto más difícil es controlar esta entrada de información.

Yo creo que la información debe introducirse solo por un sitio, y a ser posible sin interaccionar con más personas, para evitar filtros, modificaciones o interpretaciones personales y que esta sea fiel reflejo de los pensamientos del cliente, inclusive si esta presenta algún error para que posteriormente pueda ser analizada por todo el equipo. Pienso que debemos huir del pensamiento de que sea una sola persona la que hable con el cliente, que procese, filtre y finalmente traslade la información al equipo de desarrollo. Esto traslada toda la responsabilidad a una sola persona que puede cometer errores en la planificación y el diseño, al no contar con información relevante de otros miembros del equipo de desarrollo que seguramente conozcan a fondo áreas del cliente en las que han estado trabajando. Creo que deber ser el equipo al completo, el que analice la información y tome las decisiones en conjunto pues entre todos contaremos con una visión general mas completa para resolver el problema.

A veces el cliente llama directamente o la persona encargada del proyecto habla con el personalmente, el cliente traslada cualquier problema o necesidad con una prioridad determinada para resolverla. En este caso se producen varios problemas adicionales:

– Por un lado el cliente interrumpe el trabajo que estas haciendo y aquí se producen las mayores pérdidas de productividad, porque estas interrupciones nos obligan a veces a dejar tareas importantes. haciendo que la productividad decaiga en picado, no solamente se pierde el tiempo de la interrupción, si no que después obliga a que la persona tenga que volver a concentrarse para poder continuar el trabajo que estaban realizando. Debemos intentar eliminar estas interrupciones, cuando veo equipos de desarrollo en los que habitualmente hay una o dos personas hablando constantemente por teléfono suelo pensar que las cosas se están haciendo mal. Debemos eliminar estas interrupciones, las reuniones de scrum están para algo y debemos tratar de minimizar las conversaciones con el cliente, sobre todo aquellas que son por teléfono y que no quedan debidamente registradas o pueden sufrir diferentes interpretaciones y que además, afectan al rendimiento de las demás personas del equipo que se encuentra en el mismo entorno. Pienso que una buena solución aunque a algunos les suene un poco radical es simplemente descolgar el teléfono y bloquear las entradas de información como skype, en nuestro caso intentamos centrarnos solo en el email que nos permite estar al tanto de cualquier incidencia urgente que requiera una atención inmediata, las conversaciones con un cliente no aportan absolutamente nada, la información no queda registra y esta normalmente llega alterada al repositorio, lo que si puede aportar valor como veremos mas adelante es un diálogo con un cliente que quede registrado en el sistema y que no obligue a ninguna de las dos partes a interrumpir su trabajo.

– Puede ser además, que cuando el cliente llame le atienda una persona que no conozca a fondo su contexto de trabajo y de esta forma no sepa captar adecuadamente sus necesidades trasladando información incompleta o errónea al equipo de desarrollo.

– La información que nos traslada el cliente no queda registrada, con lo cual nunca sabremos si esta ha sufrido alguna alteración, es importante que todos los diálogos sobre un ítem determinado queden registrados y esta información sea accesible tanto por el propio cliente como por los miembros del equipo de desarrollo.

– Por otro lado a veces el cliente establece una prioridad determinada abduciendo que la necesidad es urgente y prioriza tu trabajo, de manera que esto nos obliga a dejar de lado aquello que estamos haciendo, para solucionar el problema lo antes posible, dejando aquello que teníamos planificado y que a veces puede tener una mayor prioridad.

– Muchas veces, parte del equipo de trabajo no cuenta con esta información a tiempo, ya que se comienza a desarrollar mucho antes de que el equipo pueda evaluar su solicitud. En estos casos a lo mejor no conocemos toda la información necesaria y ofrecemos una solución errónea debido a dependencias desconocidas y hacemos algo que debería haber sido correctamente planificado y estudiado.

Este y otros problemas son derivados del flujo de información y se convierte en una de las principales causas por la que muchos proyectos fracasan.

Una solución que a nosotros nos ha funcionado muy bien es la de intentar trasladar y compartir el backlog del proyecto con el cliente, con ello evitaremos la mayoría de estos problemas y lograremos varias ventajas:

– Se minimizan las interrupciones: Ya no tenemos que atender al cliente por teléfono o skype cada vez que nos llame, podemos visualizar las incidencias y requisitos que van llegando y pararnos solo si detectamos que estas requieren una atención inmediata, de esta forma podemos trabajar sin constantes interrupciones, el cliente también se beneficia del mismo sistema de trabajo, si tenemos que realizar alguna pregunta sobre un requisito en concreto utilizaremos el mismo sistema de dialogo con el, evitando interrumpirle en su trabajo y minimizando nuestro tiempo para contactar con el.

– Registro del flujo de información: Por un lado tanto el cliente como el equipo son los que escriben la información y esto queda registrado, con lo que evitaremos las alteraciones en la información cuando las filtra cualquier persona que hace de intermediario.

– Una mejor información disminuye los tiempos de desarrollo: Muchas veces una llamada no es suficiente para describir adecuadamente un problema, si el sistema de gestión del backlog permite adjuntar archivos, el cliente puede fácilmente introducir un documento, un gráfico o cualquier tipo de información que considere de interés para facilitar su comprensión, esto facilita mucho que la información este localizada en un lugar determinada y que el equipo entienda el problema adecuadamente evitando que perdamos el tiempo buscando o intentando entender mejor el proceso.

– Seguimiento del proceso: El cliente puede conocer en tiempo real la situación de su incidencia, mejora o el desarrollo de una nueva funcionalidad que haya solicitado, pudiendo además obtener información adicional, fecha de planificación, personas que lo desarrollaran, estado actual, etc, etc. Esto es muy importante pues evita constantes interrupciones con preguntas del tipo: ¿Ya has terminado aquello?, ¿Por qué no se ha hecho? ¿Qué problemas habéis tenido en el desarrollo?, de esta forma el cliente tiene constancia de las incidencias que ocurren, puede ocurrir que el desarrollo de un módulo tal y como propone el cliente afecte a otros módulos que el desconoce y es importante que si no se realiza como él ha solicitado pueda conozca las causas o los motivos por los que se ha realizado de otra manera.

– Por otro lado esta información va quedando almacenada en un histórico, de manera que otros usuario pueden acceder a esta información sobre problemas que ya tienen una respuesta determinada. Este debería ser un proceso que el cliente debe hacer antes de introducir una nueva incidencia, de manera que pueda beneficiarse de soluciones que ya hayan sido realizadas obteniendo una respuesta inmediata evitando requerir al equipo de trabajo.

– La información fluye hacia todos los miembros del equipo: Esto es fundamental en un equipo de desarrollo, algunos miembros del equipo desconocen como se han desarrollado otros módulos y las dependencias entre ellos, todo el equipo debe conocer el trabajo de los demás para así poder ofrecer la información relevante a otros miembros del equipo que la desconocen y lograr la solución mas adecuada.

– Filtrado de información: Normalmente no nos interesa compartir toda la información con toda la gente que participa del proyecto, nuestro sistema permite compartir solo aquellos ítems que deseemos con determinadas personas que trabajan en el cliente, de manera que el director financiero quizás no quiera visualizar información que solo es relevante para el responsable de nóminas, es importante que podamos controlar con quien queremos compartir esta información, no todas las personas que trabajan en el proyecto necesitan estar informadas de todos los aspectos de este. Con lo que logramos que la información fluya solo a aquellas personas relevantes evitando sobrecargar de información a otras que no la necesitan.

– El sistema de alerta nos avisa de cualquier incidencia urgente: Es importante que existan ciertos mecanismos que nos permitan notificar rápidamente una incidencia urgente, que se bloquee un servidor de BD requiere atención inmediata, nuestro sistema de alertas a través de email hace que estemos informados en tiempo real de cualquier incidencia grave y esto nos permite reaccionar con rapidez.

– El equipo de desarrollo planifica y prioriza: Somos nosotros los que debemos priorizar, no el cliente, el cliente no tiene toda la información relevante del desarrollo del proyecto y el equipo si, muchas veces ocurre que para el cliente es muy importante la realización de una tarea en concreto, pero en el proyecto pueden existir otras tareas que tengan una prioridad mayor, con un backlog compartido podemos cambiar la prioridad y notificar al cliente del porqué de estas decisiones, para justificar y hacerlo participe de nuestro trabajo.

Voy a poner un ejemplo de un ítem de un backlog para ver su funcionamiento, en este caso hemos implementado un pequeño programa para realizar esta operación, que notifica de forma automática a los usuarios a través del correo electrónico de cualquier cambio en el backlog, he leído en alguna parte que en la nueva versión del TFS, esto va a ser posible, seguro que El bruno puede avanzarnos algo sobre este tema.

1º – El cliente notifica un nuevo ítem.

Código: 4212 Fecha: 12/07/2012 9:12 Prioridad: Urgente

Usuario: Jose Angel García (Cliente – Agente comercial)

Descripción: Necesitamos que en el informe de facturación aparezca el número del agente de aduanas. Te adjunto un pdf con el informe de la factura para que veáis como debe quedar.

2 º – Hemos recibido su notificación con fecha 12/07/2012

3º – Respuesta de Ana Martínez (Responsable del proyecto) a la notificación nº 4212 el día 13/07/2012 10:00

La propuesta indicada será realizada por Julio Otero (Desarrollador).

Uno de los miembros del equipo comenta que las facturas pueden contener varios albaranes y estos podrían utilizar un agente de aduanas diferente, como procedemos en este caso.

4º – Respuesta de José Ángel García (Agente comercial) a la notificación nº 4212 el día 12/07/2012 11:45

Este caso no se puede dar, ya que antes de hacer la factura se comprueba que todos los albaranes tengan el mismo agente de aduanas, si existiesen albaranes con diferente agente se generarían varias facturas.

5º – Respuesta de Ana Martínez (Responsable del proyecto) a la notificación nº 4212 el día 12/07/2012 12:25

Bien, en este momento no podemos hacerla pues existen dos incidencias prioritarias que debemos resolver antes, cambio la fecha de planificación para el día 16/07/2012, para salir del paso podéis editar el PDF de la factura e introducirlo de forma manual.

6º – Respuesta de Julio Otero (Desarrollador) a la notificación nº 4212 el día 17/07/2012 10:25

La notificación 4212 ha sido resulta, te envió el pdf adjunto para que verifiques si todo esta correcto.

7º – Respuesta de José Ángel García (Agente comercial) a la notificación nº 4212 el día 17/07/2012 11:00

             Lo he verificado y funciona correctamente.

8º – Cerrada la notificación número 4212 por José Ángel García (Agente comercial)

De esta forma la información fluye sin que tengamos que controlar por donde entra y quien la procesa, ya que existe un solo punto de entrada (la aplicación que permite acceder a nuestro backlog), se disminuyen las interrupciones ya que no tenemos que hablar directamente con el cliente, la información sobre los cambios se distribuye de forma automática notificando al cliente por email de cualquier cambio que se produce, nos permite planificar y cambiar la prioridad de la tarea y estudiar mejor los cambios a aplicar, es el cliente quien escribe sus necesidades, y estas no se tergiversan, el registro guarda la información tal y como el cliente la ha introducido, el equipo trabaja como un conjunto en la planificación de tareas y la corrección de errores evitando errores en el diseño por el desconocimiento de las dependencias y ofrece entre todos sus miembros una solución mas adecuada y el sistema de alertas notifica en tiempo real de cualquier incidencia grave que pueda surgir para permitirnos reaccionar con rapidez.

He puesto Scrum porque es la metología que utilizamos, pero creo que este sistema de trabajo es trasladable cualquier metodología Ágil, si habéis llegado hasta aquí, espero vuestros comentarios.

Visual Studio 2012 – Primeras impresiones

Llevo ya varios días trabajando con la nueva versión de VS, lo cierto es que después de las últimas versiones, me esperaba mas de lo mismo, los mismos errores sin corregir versión tras versión, los cuelgues con el diseñador de formularios que se producían a diario, la carga eterna de los controles del toolbar, los enormes tiempos de compilación, etc, etc, nada mas lejos de la realidad, por fin, después de estos años parece que las cosas han empezado a cambiar, los desarrolladores somos un valor al alza, (me gustaría saber cuanta culpa tiene Google y Apple) en todo esto.

La primera vez que arrancas VS 2012 y observas el menú, ya te dan ganas de salir corriendo, vaya un diseño que han aplicado, colores grises, fuentes del menú principal en mayúscula, etc, he leído que se están acercando el diseño Metro, yo creo que el diseñador principal debería acudir a un par de desfiles de Victoria Secret, a ver si se le pega algo sobre la combinación de colores, aunque lo cierto es que después de unos pocos días de trabajo, el diseño es, con diferencia lo que menos importa, por mi, como si en la siguiente versión solo funciona en una pantalla de fosforo verde.

En lo que al entorno de trabajo se refiere, han corregido los errores de las versiones anteriores y han mejorado en gran medida el performance general de todas las operaciones, verificación de las reglas de fxcop, unit test, el diseño de los formularios ya no da errores constantemente debido a la carga en memoria de librerías, la carga del toolbar ya no te hace esperar varios minutos, algunos de nuestros proyectos tienen un gran número de controles y esto hace que cada vez que querías diseñar un formulario después de compilar se tuviera que regenerar de nuevo toda la tabla de controles, la carga de los proyectos se realiza en paralelo y en soluciones con muchos proyectos el tiempo de espera se reduce considerablemente, mi conexión remota al servidor de TFS utilizando una VPN a funcionado a la primera, por fin no pierdo las credenciales cada dos por tres, los tiempos de compilación han mejorado mucho, increíblemente no he encontrado ni un solo problema, he instalado Coderush y Resharper y funcionan de maravilla a pesar del aumento de los recursos que requieren.

En el desarrollo diario con Visual Studio 2010, os puedo asegurar que muchos de estos problemas suponían unas perdidas de tiempo enormes, hemos calculado que mas de una hora diaria por persona, esto supone para algunas empresas de desarrollo unas perdidas enormes, no entiendo porque no han corregido estos problemas hasta ahora, pero al menos lo han logrado en esta versión, ya era hora, en estos días no hemos tenido ni un solo problema trabajando con VS 2012, de hecho acabo de borrar de mi equipo la versión de VS 2010, a su favor diré que era mucho mas bonito…

Por fin, Entity FrameWork 5, permite realizar diferentes diagramas, al fin podremos trabajar en el diseñador con bases de datos que contiene muchas tablas, aunque los nombres de estas siguen sin incorporar el esquema de seguridad, algo con lo que sigo sin estar de acuerdo, no es lo mismo una tabla llamada dbo.Articulos que gestion.Articulos y en este caso EF llama a la primera Articulos y a la segunda Articulos1 y no muestra el nombre completo con su esquema, algo que para nosotros es importante, pues forma parte del esquema de seguridad de la tabla y siempre debe ser reflejado en las consultas.

Uno de los problemas que he visto y que no me ha gustado nada, es que después de actualizar uno de los proyectos a la versión 4.5 del FrameWork basado en Windows Forms, nos hemos dado cuenta que al instalar este en equipos que usen XP no funciona, en la información de Microsoft aparece que solo se da soporte a versiones que parten desde Windows Vista hacia adelante, parece que Microsoft quiere forzar a que los usuarios actualicen a Windows Vista o Windows 7, pienso que es un gran error no dar soporte a Windows XP, hay muchos equipos que funcionan muy bien con este S.O. y que no tienen ninguna necesidad de actualizarse o que su hardware no les permitirá hacerlo, pienso que deberían haberse esforzado en hacerlo compatible al menos para soluciones realizadas en Windows Forms, que todavía hoy siguen siendo la mayoría.

Sigo sin entender que pasa con el desarrollo de los dispositivos móviles industriales en Windows CE y Pocke PC, están abandonando un sector que tiene un potencial increíble, no he visto que Windows Phone se integre todavía con estos dispositivos, pero en fin, ya llegara alguien para hacerse con este hueco y luego llegaran las prisas como con Windows Phone y Windows 8, parece que algunos no reaccionan hasta que viene alguien y se hace con su mercado.

No he tenido tiempo de ver mucho mas, algún proyecto en ASP.NET y ASP MVC que han funcionado sin problemas, pero si os diré que en general, la primera impresión ha sido muy positiva, pienso que han realizado un excelente trabajo en esta versión, así que animaros Visual Studio 2012 supone un cambio enorme respecto a las versiones anteriores, solo las mejoras de rendimiento ya justifican el cambio, espero que continúen así.