Ajedrez - antoniomartel.com

Archivos por Etiqueta: valores

Los valores que están detrás de Scrum (II)

Responding to change over following a plan
Si al inicio del proyecto trazamos un plan inmutable por el cual en el primer mes tendremos una funcionalidad A, en el segundo mes las funcionalidades B y C, en el tercer mes la funcionalidad D y seguimos así hasta el final del proyecto tendremos una planificación reluciente que, aparentemente, nos conducirá sin un solo problema hasta el final del proyecto.
Pero la realidad es tozuda y en algunas funcionalidades tardamos más de los previsto, en otras menos. En otras ocasiones nos pedirán que modifiquemos una o dos de las funcionalidades o que quitemos una tercera porque ya no hace falta. El resultado se traducirá en un millón de modificaciones al diagrama de Gantt y mucha presión para que las funcionalidades estén listas en el mes prefijado sin tener en cuenta la gran cantidad de cambios que han habido.
Es necesario hablar constantemente con el cliente, explicarle los cambios y volver a colaborar con él para reajustar la planificación o roadmap previsto. Puede que termine con una lista de funcionalidades distintas pero será las que él ha pedido y no las que se grabaron a fuego al inicio del proyecto y que se terminaron haciendo sean ya útiles o no.
De este Agile Manifiesto salió también una lista de doce principios a seguir por todas las metodologías ágiles. Uno de estos principios es:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Parece obvio que esto es lo que debe hacerse en cualquier desarrollo, y con ese ánimo comenzamos cada nuevo proyecto, pero pronto comienzan las prisas. Nuestro director nos pregunta cuántas horas llevamos empleadas (y llevamos ya muchas), nuestro cliente nos pregunta cuándo va a tener listas todas las funcionalidades y nuestros compañeros de trabajo nos preguntan si ya pueden cogerse las dos semanas de vacaciones que les debemos.
Empieza a pintar feo. Ya nos hemos vuelto a meter en un jaleo. Tenemos que volver a rehacer el diagrama de Gantt con las nuevas fechas de entrega programadas, tenemos que buscar otras fechas para las vacaciones (incluso las nuestras) y tenemos que dar un montón de explicaciones al director: ‘Es que nos han pedido cambios, es que las tecnologías eran nuevas, es que estimamos mal’.
A partir de aquí es cuando tendemos a ponernos firmes, a exigir un esfuerzo adicional al Equipo de Trabajo y a negar cualquier pequeño cambio al cliente. Si no está exactamente escrito así en el contrato que firmamos o en el acta de una reunión que tuvo lugar hace ocho meses, lo siento, pero no lo haremos.
El caso es que el cliente también hizo esto. Redactó un contrato muy claro en el que te dijo cada una de las funciones que quería (o las que quería en el momento de redactarlo). Quizás ya no las necesite o se haya dado cuenta de que hay otras más importantes pero están en el contrato y hay que hacerlas. El proyecto no puede acabar y dejar un 30% de funcionalidades por hacer.
En este momento ya hemos perdido de vista la que debe ser la máxima prioridad en nuestro trabajo. Entregar de forma continua software que funcione y que aporte valor. A partir de aquí ya no quedan sino duras negociaciones y un contrato que trataremos de cerrar cuanto antes con el menor daño posible.
El contrato podrá tener muchos artículos y estipulaciones pero, ponga lo que ponga, cuando el cliente lo redactó lo que quería era una solución a su problema, no una discusión sobre si se debe o no implementar esa función o la otra.
Pero, si vamos entregando cada poco tiempo el software que vamos haciendo, lo dejamos para que lo pruebe y lo use, que nos diga su opinión. Dejemos que encuentre lo que echa en falta o lo que podría mejorar. Va a querer que le implementemos esto que ahora ha visto que necesita y estará encantado de quitar a cambio esa funcionalidad para exportar a ficheros .rpt que ya ni se acuerda de quién se lo pidió ni por qué.
Al finalizar el proyecto el cliente tendrá un producto que de verdad resuelve sus problemas, que ha ido evolucionando a medida que él mismo aprendía y que ha podido usar y probar desde las primeras semanas del proyecto. Suena mejor para cliente y proveedor ¿no?
Otro de esos principios que rigen Scrum es:
Working software is the primary measure of progress.
Cuántas veces no nos habremos puesto a escribir software y sin enseñárselo a nadie ni que nadie lo use hemos ido poniendo cada semana o cada mes que íbamos por el 30, 40 o 50% del software hecho ¿Cómo podíamos haber sabido esto si nunca estuvo todo el software funcionando junto ni lo vió ningún responsable para saber que eso era en verdad lo que ellos requerían?

Esos porcentajes eran una simple estimación, una medida de progreso que no se basaba en una realidad constatable. Por esto se definió este principio: El software funcionando es la principal medida de progreso. Si hemos hecho 10 de las 20 funcionalidades que nos han solicitado, éstas son de tamaño similar, las hemos probado, hemos recibido la aprobación del cliente, entonces, y sólo entonces, podremos decir que nuestro proyecto está completado en un 50% (mejor aún si ese 50% ya ha sido subido a producción y ha sido usado por usuarios reales que son la verdadera prueba de fuego).

Los valores que están detrás de Scrum

Hace 16 años, en 2001, se reunieron en Utah diecisiete profesionales del software críticos con los modelos de desarrollo de software que se llevaban hasta entonces. Los consideraban demasiado pesados o rígidos. En esa reunión estaba gente como los fundadores de Scrum o Kent Beck y Martin Fowler. Habían quedado para hablar sobre nuevas técnicas y procesos para desarrollar software.
De esa reunión salió un manifiesto con una serie de valores y principios que debían cumplir los nuevos métodos alternativos (y ágiles) que estaban proponiendo: Valores detrás del movimiento ágil.
Estos valores que rigen los principios ágiles son:
Individuals and interactions over processes and tools
Se pone el énfasis en los individuos y los equipos de trabajo más que en los procesos rígidos que hayamos establecido para comunicarnos entre todos o para hacer las cosas. Poniendo a los miembros del equipo de trabajo en el centro de las decisiones obtendremos un plus de productividad mayor que si es un proceso el que dicta qué hacer y no hacer en cada momento.
Tampoco las herramientas son importantes. Nos basta un tablero o unas hojas de papel con las listas del producto y del sprint o unos pequeños post-it. Las últimas herramientas, más caras (y difíciles de usar) herramientas en gestión de proyectos no nos van a dar una gran ayuda a la hora de resolver nuestro trabajo. Por esto, rara vez, una implementación de Scrum aconseja usar una u otra herramienta. Eres libre de elegir la que quieras siempre que seas consciente que esa no es la decisión más importante en tu proyecto.
Working software over comprehensive documentation
Esto significa que valoramos más un software que funciona y que está libre de errores que una exhaustiva documentación que documenta con pelos y señales cada sección de la aplicación. Esto no quiere decir que ignoremos o pasemos de la documentación. La documentación sigue siendo necesaria pero, por favor, no la pongamos por encima de loa verdaderamente importante, que es el código funcionando. Un código chapuza o de difícil mantenimiento funciona igual si tiene mucha o poco documentación. Prestémosle nuestro tiempo a mejorar el código y no a documentarlo. Nos pagan por línea de código funcionando no por tonelada de papel con documentación.
Customer collaboration over contract negotiation
Esta es uno de los problemas más enraizados en el desarrollo de software hoy en día. Los proyectos salen mal, se pasan de horas, se retrasan las fechas de entrega y para evitarnos las posibles discusiones con los clientes ponemos paños calientes sobre el problema preparando una batería de cambios que han solicitado y que no estaban en el contrato inicial.
Probablemente el cliente no entenderá que los cambios solicitados sean tan importantes como para justificar un retraso tan grande y aquí comienzan las negociaciones sobre el contrato: ‘Yo no te haré la integración con el sistema SAP porque me has saturado con pequeños cambios en las funcionalidades anteriores’ a lo que el cliente contesta ‘Sin esa integración el proyecto vale poco o nada por lo que no voy a abonar los pagos pendientes hasta que esté hecha hasta la última coma del contrato’.
En una negociación no seas el primero el poner el arma encima de la mesa. El cliente siempre tendrá una arma más poderosa que la tuya y ambos saldrán perdiendo. Sobre todo tú que perderás un posible futuro cliente y ganará en malas referencias.

 

Es más fácil tener la lista del producto sobre la mesa desde el inicio cuando comenzaron a pedir cambios que probablemente sí que les hacían falta hacer. Sobre esa lista del producto anotar los nuevos cambios y pedirle al cliente que saque de la lista otra serie de funcionalidades de igual valor que ya no le resulten tan importantes. Seguro que de buen grado encontrará funcionalidades a las que ya no le ve tanto sentido y que estará encantado de quitarlas con tal de que les hagas las que sí les hacen falta realmente.

Suscríbete

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información
Privacidad