Ajedrez - antoniomartel.com

Archivos por Etiqueta: SCRUM

Implementar Scrum y cómo sobrevivir para contarlo

Pocas cosas hay más de moda ahora en el mundo IT que Scrum y otras técnicas ágiles. Muchas empresas están adoptando Scrum en sus proyectos pero no todas tienen éxito. Muchas fallan miserablemente al primer intento y deciden no volver a probar. Comentan ‘Scrum no es para nosotros, ya lo intentamos y no sirve para nuestros proyectos‘ o ‘Al cliente no le gustó. Quería volver a sus diagramas de Gantt y sus entregas a final de año‘.

No suele ser debido a nuestro tipo de proyecto o lo especial de nuestros requerimientos. Tendemos a pensar que nuestros proyectos son muy particulares o más complejos que ningún otro pero la mayoría de nosotros no trabaja en proyectos tan poco comunes. Adoptar técnicas como Scrum no es fácil. Suponen un cambio importante en la forma de trabajar y cuando algunas cosas empiezan a no ir bien algunos señalarán con el dedo al Scrum Master y a esas técnicas raras que no les están llevando por buen camino.

Si aún así decides apostar por esta metodología y te planteas llevar tu próximo proyecto con Scrum aquí tienes algunos de los posibles problemas con los que te encontrarás:

Clientes: esto es una cosas de frikies

No todos tus clientes habrán oído hablar de estas técnicas ágiles y quizás no les importe demasiado la forma en que tú y tu equipo se organicen. Quieren los resultados por los que te han contratado y para ello supervisarán tu trabajo y te exigirán unas fechas y unos compromisos. No estaba en sus planes oírte hablar usando terminología rara.
En la reunión de arranque de uno de los primeros proyectos en los que empecé a utilizar Scrum quise explicar la metodología que íbamos a usar y cuál iba a ser nuestro funcionamiento. Comencé hablando de deliverables, sprints o scrum masters para continuar después con daily meetings y gráficas burndown. Pronto vi que me miraban atónitos así que me salté el resto de puntos pendientes y fui directamente a la conclusión. Nadie se dio cuenta ni hizo ninguna pregunta al respecto.
Desde entonces no entro en gran detalle sobre nuestros procedimientos y desde luego tampoco uso términos que puedan sonar raros a alguien que no conozca esta metodología. Para mi sorpresa algunos clientes terminan preguntándome un tiempo después cómo se llama esta forma de trabajar y adaptándose rápidamente a los tiempos de los sprints y los spikes.

Directores: Scrum es anarquía

La máxima preocupación del director de una compañía IT suele ser que desarrolles un buen producto pero que lo hagas dentro del plazo y presupuesto previsto. Si no puedes cumplirlo puedes dejar un enorme agujero en las cuentas de la empresa y encima puedes perder un posible cliente contento. Demasiado riesgo para dejarlo en manos de nuevas metodologías.
Puede sonar más tranquilizador oír hablar al jefe de proyecto de calendarios, seguimiento de costes y de ocupación en lugar de entregas frecuentes y software funcionando. No dudo que los primeros puntos sean también importantes pero sirven de poco si el cliente no tiene un software con el que pueda ir trabajando. El jefe de proyectos tendrá que ir haciendo malabares con su tiempo para entregar los informes de facturación, el registro de horas empleadas o hacer estimaciones pero, sobre todo, no debe olvidar que su principal trabajo es entregar software que funcione.
Pueden haber muchos otros inconvenientes a la hora de implantar Scrum en tus proyectos. Iré desgranando algunos de ellos en mis próximos posts. En cualquier caso, si no quieres esperar, puedes echarle un ojo a esta presentación en prezi en la que cuento Cómo sobrevivir a la adopción de Scrum. Espero que te guste.

Si te ha gustado este post, puedes encontrar más contenidos que expliquen Scrum de forma práctica y desde su base en mi libro en Amazon Curso práctico de Scrum: Algo más que teoría.

Libro en Amazon: Curso práctico de Scrum: Algo más que teoría
Libro en Amazon: Curso práctico de Scrum – Algo mas que teoría

Construir lo correcto, construirlo correctamente o construirlo rápido

Siempre que desarrollamos un producto, nos demos cuenta o no, estamos haciendo un balance entre construir lo correcto (la funcionalidad exacta que necesita nuestro cliente), construirla correctamente (siguiendo la mejor arquitectura o los mejores estándares), o construirla de la forma más rápida posible.

Por supuesto, todos queremos estar en el punto del centro de la imagen y conseguir los tres aspectos al mismo pero es muy difícil lograr el equilibrio perfecto, cuando no imposible. A menudo debemos ir hacia uno de los lados de la figura para sacar la mejor versión de nuestro producto adelante.

Si nos movemos hacia el punto 1, en la intersección entre construir lo correcto y construirlo correctamente tendremos un producto perfecto con una arquitectura también perfecta pero podemos haber tardado demasiado en construirlo y no tenerlo disponible cuando el cliente la necesita o cuando el mercado lo demanda. Construir un Whatsapp con interfaz web puede estar muy bien justo ahora y hacerse muy popular y hacerse muy popular en poco tiempo pero podría ser demasiado tarde si lo entregamos dentro de un año.

En cambio, si tendemos hacia la intersección del punto 2, crearemos muy rápido el producto correcto partiendo quizás de un prototipo evolucionado pero que podría llevarnos a arrastrar una deuda técnica muy grande. Esta deuda técnica podría hacer que termine siendo inabordable cada vez que queramos construir nuevas cosas sobre una arquitectura base tan pobre.

En la tercera y última de las opciones podríamos construir muy rápidamente un vehículo con una bonita línea deportiva y un gran motor pero olvidamos construir lo correcto: nuestro cliente en realidad necesitaba un producto con algo de capacidad de carga para su trabajo diario.

Según sea nuestro papel en el proyecto todos tenemos cierto sesgo hacia alguno de los círculos. Los dueños del producto, es decir nuestros clientes, tienden a poner todo el foco en construir lo correcto. A su vez los miembros del equipo de desarrollo tienden en cambio hacia construir correctamente, centrándose en las cuestiones de diseño de la arquitectura y de la solución técnica. Por último el Scrum Master tiende habitualmente hacia construir el producto de la forma más rápida posible.

Ese es el papel que suelo tener yo, el de Scrum Master o jefe de proyectos, que solemos andar preocupados por el tiempo en el que vamos a entregar las cosas. En nuestro descargo debo decir que la velocidad es siempre un aspecto importante. Iterar y entregar nuevas funcionalidades más pronto nos va a permitir aprender antes qué es lo más importante a construir ahora y cómo construirlo técnicamente de la mejor forma posible.

Todo esto que comento aquí lo puedes encontrar de forma muy condensada en el vídeo sobre Product Ownership de Henrik Kniberg. No sólo habla de este dilema entre construir lo correcto, construirlo rápido o de la mejor forma posible sino de muchos otros aspectos relevantes para los dueños del producto y directores de proyecto en el cliente. Échale un vistazo, es muy bueno.

Nueva edición del libro Gestión práctica de proyectos con Scrum

Esta semana he lanzado en Amazon una nueva edición del libro Gestión práctica de proyectos con Scrum. Nueva portada, nuevos capítulos, revisión de contenidos, en definitiva, un montón de cosas en esta segunda edición del libro ¿Aún no lo has leído? Échale un vistazo en Amazon.com. Aquí tienes el enlace: Gestión práctica de proyectos con Scrum.

Con estos cambios el libro se ha colocado como número 1 en tres categorías al mismo tiempo (Programación y desarrollo software de la Tienda Kindle y Programación y desarrollo de software e Internet y web dentro de todos los libros de Amazon.es). En el momento en que escribo esto el libro se ha colocado en la posición nº 166 en ventas de todos los libros Amazon España ¿Llegará al top 100?

El rol de Product Owner en Scrum

Hay muchas formas de denominar a la persona que cumple las funciones de Director del Proyecto en la organización que nos contrata. Aquel que tiene la visión del producto que necesita su compañía y que la representa ante el equipo de trabajo. Si pertenece a la organización externa que nos ha encargado el trabajo, el nombre que mejor se le ajusta es el de Dueño del Producto, como hace Scrum, porque es eso literalmente, el ‘Dueño’ de lo que se ha contratado. Si en cambio es una persona de nuestra propia organización la que va a representar al ‘negocio’ en el proyecto suele denominársele Product Manager o incluso Business Analyst según la empresa que le haya dado el cargo. Personalmente, quizás por el tipo de proyecto que habitualmente gestiono, me siento más cómodo llamándolo simplemente Director del Proyecto en el Cliente.

Lo llamemos como lo llamemos, cumple una función muy importante para el éxito de un proyecto. Es el encargado de decidir qué funcionalidades tendrá el producto que se está construyendo, cuáles son importantes y cuáles son prescindibles. Es posible que sea un usuario final del producto por lo que tendrá muy claro qué se necesita para obtener una herramienta útil en su trabajo diario, pero no debe ser útil solo para si mismo o su departamento, sino que deberá tener en cuenta los requisitos de toda su empresa.

Cuando comenzamos un nuevo proyecto, el Director del Proyecto en el cliente y todos los usuarios interesados en el producto final tienen un montón de ideas y grandes expectativas para el nuevo sistema. Lamentablemente, ningún proyecto, por grande que sea, puede contemplar todas y cada una de las sugerencias de sus usuarios. Algunas ideas serían irrelevantes para la mayoría, otras funcionalidades serán demasiado costosas de implementar o llevaría tanto tiempo desarrollarlas que retrasarían la puesta en marcha del producto. Es aquí donde el Director del Proyecto en el Cliente, que conoce bien el mercado y tiene una clara visión del producto, tendrá que priorizar las características más importantes y descartar aquellas que aportan menos valor al resultado final.

Para explicar hasta dónde llegan sus responsabilidades imaginemos que nuestra empresa decide contratar el desarrollo de un nuevo sistema de reserva de billetes de avión. En esta empresa han nombrado a Raúl como Dueño del Producto o Director del Proyecto y tendrá que trasladar a la empresa contratada todos los requisitos y necesidades que el nuevo sistema deberá cubrir.

Raúl tiene una visión muy clara de lo que quiere y está muy ilusionado con el proyecto. También lo están los responsables de IT, marketing y ventas que han elaborado una exhaustiva lista de funcionalidades a incluir en el nuevo producto. Incluso en conversaciones informales, los que serán nuevos usuarios del sistema, le trasladan a diario peticiones de nuevas funcionalidades. Raúl no quiere que se le escape nada importante y anota cuidadosamente todos estos requisitos en un cuaderno.

Al segundo mes de comenzado el proyecto Raúl se da cuenta que el Equipo de Trabajo en la empresa desarrolladora está entregando de 4 a 6 nuevas funcionalidades a la semana y que esta parece su capacidad máxima de trabajo. Está contento con el trabajo que están haciendo pero tiene un problema: en su libreta anota una media de 10 nuevos requisitos a la semana. La lista está creciendo y pronto necesitará un nuevo cuaderno.

Primero solicitó al Equipo de Trabajo que hiciera un esfuerzo para entregar estas diez funcionalidades cada semana. Lamentablemente, no muchas más funcionalidades eran entregadas y, lo que es peor, se comenzaba a percibir que la calidad de las mismas había bajado. En ocasiones incluso había que parar todo para corregir defectos en entregas previas. Si seguían así, la desmoralización y el estrés iban a dominar el proyecto.

Raúl iba a decidir a partir de ahora qué se hacía y qué no. Todas las funcionalidades no iban a poder se desarrolladas, por lo menos no ahora. Algunas tendrían que esperar a una futura versión. Desde luego, la funcionalidad similar al Clippy de Windows para asistir en la compra de los billetes de avión era un claro ‘No’.

 

Pero ¿cuáles desarrollar primero? ¿qué criterio seguir? Raúl se dio cuenta de que no había relación directa entre el coste de las funcionalidades y su valor para el producto final. Algunas funcionalidades eran fáciles de construir pero otras, en cambio, llevaban mucho tiempo de desarrollo pero no por ello eran las que más valor aportaban. Si preguntaba directamente al Equipo de Trabajo en cuantos días podría estar hecha cada una de las funcionalidades sabría su coste aproximado y si preguntaba a los usuarios por una valoración del 1 al 5 para cada funcionalidad sabría calcular el valor para su empresa.

Si había dos funcionalidades que tienen el mismo coste aproximado pero una tiene valor 1 y la segunda valor 3 estaba claro que se construiría la segunda funcionalidad. Si en cambio, había dos funcionalidades de aproximadamente el mismo valor para la empresa pero tardaríamos 5 días en desarrollar una de ellas cuando la segunda podría estar desarrollada en una horas, también estaba claro en cuál se trabajaría primero.

Raúl sabía que el coste y el valor de cada funcionalidad no eran números absolutos sino solo una aproximación. No sabemos cuánto pesa una manzana pero sí sabemos que es aproximadamente 5 veces más grande que una fresa y que la fresa gusta más (para los que van a pagar por ella al menos) por lo que la fresa se construiría primero. Es un modo fácil de decidir qué aporta más valor y más rápido a nuestro proyecto.

La comunicación es una parte importante de las responsabilidades de Raúl. Deberá estar en contacto directo con el Equipo de Trabajo pero también con las personas de su empresa que tienen algo que decir sobre el producto que se va a construir. Debe ser hábil para saber decir ‘no’ cuando sea necesario. Debe ser práctico también para tomar esta decisión de forma rápida y directa y, además, conocer muy bien su negocio para asegurarse de que se construye lo que realmente aportará valor a su empresa. Todo un papel para Raúl ¿no creen?

Este artículo se publicó por primera vez en el número 3 de la revista IT Proiectus. Puedes encontrar este artículo y muchos otros en la web de Proiectus, consultoría y formación en dirección de proyectos.

Curso práctico de Scrum

El pasado jueves 16 terminaron las sesiones de formación dentro del curso Organización de los Servicios TIC en Departamentos de Desarrollo Software organizados por la SPEGC y ITPROIECTUS.

Yo impartí una de las charlas dedicada a Scrum el jueves anterior, el 9 de octubre. Les dejo algunas fotos del evento y la presentación que usé durante la sesión.

 

 

 

Suscríbete