Hoy, domingo 4 por la tarde, ha vuelto a colocarse mi libro Gestión Práctica de Proyectos con Scrum como libro más vendido en la categoría de Programación y Desarrollo de Software de libros electrónicos en Amazon España. El número 2 en ventas en la misma categoría pero para libros en papel también.
Está actualmente en el puesto 935 entre todos los ebooks vendidos por Amazon en España lo que no está mal para ser un libro de informática o de gestión de proyectos después de 4 años a la venta.
Es frecuente que el equipo, metido en las prisas por entregar lo comprometido en el Sprint, olvidé que al final del mismo tiene que demostrar lo que ha hecho y que esas demos tienen un coste de preparación. Normalmente es necesario:
Cuando estamos en los primeros sprints y aún no estamos muy acostumbrados a hacer las demos, no sabemos bien dónde está el entorno de demo ni estamos acostumbrados a mostrar la aplicación es frecuente que todo falle: El usuario que escogimos no loguea, no tiene todos los permisos para entrar en las áreas de la aplicación que vamos a mostrar hoy y es necesario que alguien salga de la reunión para darle esos permisos. Necesitamos estar creando registros para poder probar delante del Dueño del Producto y los Interesados alguna de las funcionalidades.
Por esta razón, unos dos días antes de la reunión de demo suelo hacer una reunión que he dado en llamar de pre-demo. En ella, de forma informal y breve, los desarrolladores hacen una mini-demo de las funcionalidades que les ha tocado hacer y que se les ha pedido que preparen primero. En esta pre-demo suelen surgir muchas incidencias y dudas para las que todavía quedan dos días a resolver antes de entregarlas al cliente. Para entonces ya estarán más rodadas cuando se vayan a mostrar de forma algo más oficial.
La certificación Professional Scrum Master (PSM I) es sólo un examen online que podría parecer fácil de pasar pero es una de las certificaciones más duras que existen en el mercado.
Son 80 preguntas a resolver en 60 minutos por lo que sólo tendrás 45 segundos de media para resolver cada una de ellas. No es mucho tiempo para pensar y mucho menos para buscar la respuesta en la guía de Scrum o en Internet. Debes ser capaz de responder muy rápido a las preguntas más sencillas para que te dé tiempo a pararte unos segundos más en las preguntas más complejas.
Debes conocer muy bien la guía de Scrum. Ahí están directamente el 80% de las respuestas pero está muy resumida como para entender todos los conceptos a la primera. Te conviene ampliarla con otras perspectivas como el libro Scrum from the Trenches de Henrik Kniberg. Quizás no te haga falta leerte todos los capítulos del libro pero la mayoría te ayudarán a poner en contexto la aplicación de Scrum.
Léete la guía en inglés. Léetela primero en español si quieres, pero acostúmbrate a los términos y expresiones en inglés. El examen es en ese idioma y necesitarás estar acostumbrado a ese vocabulario. No tendrás tiempo de buscar lo que significa una palabra durante el examen. El glosario de Scrum.org es también muy útil. Léetelo porque en muy poco texto tienes una gran cantidad de definiciones muy útiles.
Repite y repite los tests gratuitos que te pone Scrum.org en su Open Assessment. Algunas de las preguntas que te encuentres ahí te las encontrarás en el examen real por lo que ya tienes un 10% más de preguntas acertadas. Asegurate de entender cada respuesta que das y repite el examen hasta que puedas dar un 90% de respuestas acertadas de forma consistente. Si lo haces así dificilmente suspenderás luego el examen de certificación.
Haz también test de práctica como los que puedes encontrar en mi web con tests de preparación. Algunas de las preguntas están pensadas para hacerte caer en los errores comunes. Por lo que, repito de nuevo, asegúrate de entender todas las preguntas hasta acertar en un 90% de forma reiterada. Te habrás asegurado de entender el concepto y si te lo encuentras más adelante, formulado de otra manera, serás capaz de acertar cuál es la respuesta correcta. Tienes más test de práctica por jassergarcia en Classmarker. Lo dicho, asegúrate de entender las respuestas correctas (y por qué las otras no lo son).
Tienes más recursos también en mi blog:
O puedes ayudarte con mi curso online de preparación para el examen Professional Scrum Master (PSM I). Allí encontrarás no sólo más tests de preparación, recursos o consejos para pasar la certificación sino también un completo curso de Scrum en español. Te explicará en palabras sencillas la guía de Scrum y te pondrá ejemplos prácticos en situaciones reales. Tienes también un bono de 5 emails para consultas que puedes hacerme directamente sobre el curso o la propia certificación en sí. Espero que te sea de ayuda.
Acabo de lanzar un nuevo curso de Scrum para la preparación del certificado Professional Scrum Master (PSM I) de Scrum.org. El curso es online y, además de enseñarte el Scrum que necesitas para aprobar el certificado, incluye ayudas y consejos a la preparación, numerosos tests y preguntas de práctica y libros y plantillas de regalo.
Tendrás también, entre otras cosas, un capítulo dedicado a los recursos que puedes encontrar en Internet para que puedas documentarte, practicar los exámenes y aprender más sobre estas certificaciones. Además podrás encontrar abundante información sobre los distintos tipos de examen de certificación para Scrum Master: Una Comparativa entre las certificaciones de Scrum Master más populares en el mercado, explicando las ventajas e inconvenientes de cada una de ellas:
Si te interesa, échale un vistazo a la página del curso online. Ahí tienes una preview de algunos de los capítulos del curso. Está a la venta ahora por tan sólo 79€ el curso completo.
Curso de Scrum: Preparación para el certificado Professional Scrum Master (PSM I).
Este es un error muy habitual en el que yo y los equipos con los que he trabajado hemos caído más de una vez. Es frecuente que no se pregunte al Dueño del Producto por los detalles del trabajo que tienen que hacer. Asumen que la tarea es de una cierta manera sin preguntar y luego aparecen las diferencias cuando el Dueño del Producto lo ve en funcionamiento en la reunión de demo. Es cuando surge la temida pregunta «¿Quién les dijo que hicieran esto así?»
Esto puede suceder sobre todo por doscosas 1) temor a parecer demasiado ignorantes si preguntan nimiedades 2) por querer ir demasiado deprisa sin pararse a preguntar por qué las cosas son así cuando algo suena raro. Nos surge alguna pregunta pero asumimos una de las posibles respuestas para poder seguir adelante.
El feedback entre el Dueño del Producto y los miembros del Equipo de Trabajo debería ser algo común y frecuente. El Product Owner debe tener una alta accesibilidad y el Equipo de Trabajo no debe de tener miedo de preguntar, preguntar y volver a preguntar antes de hacer las cosas. Podrían tener que hacerse de nuevo si se entendió mal o se asumieron demasiadas cosas.
Esto requiere de mucha dedicación del Product Owner que debe estar siempre disponible para multitud de preguntas y reuniones pero requiere también de mucha atención al detalle del equipo de desarrollo. Es necesario levantar la mano (o el teléfono) y preguntar siempre que sea necesario. Terminará ahorrando trabajo a todo en lugar de darlo.
A veces tenemos que manejar un montón de interrupciones para resolver problemas de mantenimiento, corrección de errores o soporte que hacen que no lleguemos al objetivo del Sprint porque nos llega una cantidad grande de tareas que no estaban planificadas al inicio del Sprint.
Lo segundo que debemos hacer es ver cuál es la razón principal por la que tenemos tantas interrupciones y de forma tan constante ¿Se deben a la mala calidad del software? ¿Quizás debido a las constantes interrupciones? Quizás debamos dedicar algunos sprints a resolver la deuda técnica que hemos ido dejando atrás o a dar más estabilidad a las partes del software que más problemas están dando.
También hay otras cosas que podemos hacer:
Esto funcionaría en un mundo ideal pero no todas las tareas pueden esperar varios días para ser solucionadas. El servicio entero podría depender de ella.
Si sabemos que con frecuencia nos llegarán tareas inesperadas que debemos resolver con mucha rapidez podemos bajar el factor de dedicación durante el Sprint para dar ‘hueco’ a la resolución de estos problemas.
En mi opinión esta solución puede ser útil en ciertos proyectos pero puede crear otro problema. Me explico: Habitualmente el factor de dedicación es del 75%, si lo bajamos para poder dedicar un 30% del tiempo del equipo a las tareas urgentes deberíamos aplicar un factor de dedicación del 40-50%. Sobre este 40% aplicamos Scrum pero ¿Cómo se está gestionando el resto del tiempo del equipo? ¿Qué sabemos sobre esa pila de tareas que estamos resolviendo Sprint tras Sprint?
Eso sería un anti-patrón a evitar en todo tipo de proyectos. Si creamos equipos que se dedican sólo a resolver bugs o errores encontrados en producción dejaremos al resto de equipos con las manos libres para centrarse en su trabajo sin interrupciones para llegar al final del Sprint pero esto puede hacer que cada vez aumente más el número de errores encontrados.
Estas últimas semanas antes de Navidad he estado jugueteando un poco con un pet-project, una app para móviles Android que usan los sensores de temperatura, humedad y presión que tienen algunos modelos como el Samsung Galaxy S4 y el Galaxy Note para mostrarle estos datos al usuario pero también para guardarlos en la nube de Google con Firebase.
La app te mostraría la temperatura actual que registra el sensor del móvil, si lo tiene, pero al mismo tiempo te pide permiso para guardar estos datos y los de presión y humedad en la nube junto a las coordenadas de latitud y longitud del sitio donde fue tomada esa temperatura. Si tu móvil no tiene sensores de temperatura, humedad o presión la app te avisa de ello.
Este es el aspecto que tiene la aplicación (la presentación gráfica del termómetro está tomada de un sitio web, referencias al final):
Imagen de la consola de Firebase, la base de datos en la nube de Google donde se guarda la información, en la que cada nodo del árbol es una toma de temperaturas desde un móvil. En el centro se ve uno de los nodos desplegados con la información que se toma, o se podría tomar, en cada ejecución de la app.
La idea es que, si existe una red suficientemente amplia de móviles con esta app, todos los datos de temperatura almacenados alrededor de todo el mundo con los usuarios que se han descargado la app, queden guardados en registros en una base de datos NoSQL de Google que pueda ser consultada por algún científico que esté interesado.
El código de la app está disponible en un repositorio abierto de GitHub. Aquí algunos snippets del código que guarda en la base de datos:
En esta otra parte del código, la sección que toma los datos del sensor de temperatura:
Referencias:
Cuando dependemos demasiado de uno o dos programadores estrella dentro de nuestro equipo, de los que necesitamos que no fallen nunca, que hagan muchas horas extra porque no llegamos o que, cuando están de vacaciones, los echamos demasiado en falta, estamos ante un gran problema.
Scrum nos puede ayudar a conseguir grandes equipos de trabajo, equipos de alto rendimiento que pueden conseguir entregar mucho trabajo y de calidad. Si lo que tenemos es un equipo formado por un desarrollador estrella del que dependemos absolutamente y el resto del equipo sólo resuelve tareas de menor nivel, no tenemos exactamente un Equipo de Trabajo, tenemos un cirujano y tres o cuatro auxiliares.
Debemos evitar esto facilitando que más miembros del Equipo de Trabajo conozcan las partes de la arquitectura que sólo el programador o programadora estrella conocen, que otras personas realicen también las partes del trabajo que sólo le tocaban a él para que el conocimiento (y el esfuerzo) quede más distribuido.
 |
| Dependemos demasiado de héroes |
En algunas ocasiones nos encontramos con clientes que están atados de pies y manos por su proveedor de software. Usan un software que es sistémico para la empresa pero no están contentos con el mantenimiento que el proveedor realiza, los tiempos medios para la corrección de errores y lo tarde y mal que entrega nuevas características del programa. A veces el servicio no es del todo malo pero sí caro pero no pueden pedir ofertas a otros proveedores y estimular la competencia porque ellos son los únicos que conocen el software o quienes tienen contratados a los expertos en esa solución.
Se les suele pedir a estos proveedores que continuamente documenten todo lo que hacen para así asegurarse un traspaso tranquilo y cómodo a otro proveedor si se diera el caso. La empresa probablemente asegure que sí, que todo está bien documentado y esto da cierta tranquilidad al cliente pero ¿pueden estar tranquilos con esta afirmación? ¿basta con documentar el código para evitar la dependencia de proveedores? Probablemente no.
En la empresa proveedora cada vez que llega una nueva andanada de peticiones de documentación, ésta se vuelve como loca a producir documentos pero pueden pasar estas cosas:
¿Cuántos proyectos conoces que hayan acabado dentro del tiempo y presupuesto estimado sin que haya habido que reducir el alcance del proyecto? Muy pocos ¿no? Yo tampoco conozco muchos casos. Esto pasa en casi todos los sectores, no sólo en la industria del software, pero me temo que nuestra industria tiene una tasa de proyectos fracasados más alta que otras industrias. El estudio realizado para el Informe CHAOS 2015 revela que sólo el 29% de los proyectos TI pudo considerarse un éxito.
Nuestras estimaciones de tiempo y coste de un proyecto se salen de toda escala e incumplimos habitualmente nuestros relucientes diagramas de Gantt hechos al inicio del proyecto ¿A qué se debe esto? Bueno, al menos tiene una explicación científica. Se debe a un sesgo cognitivo que tenemos todas las personas no deprimidas y que hace que caigamos, una y otra vez, por exceso de optimismo en la llamada falacia de la planificación.
Este fenómemo, el de la falacia de la planificación, es debido a que los seres humanos tendemos a subestimar cuanto nos va a llevar terminar una tarea. Somos demasiado optimistas y siempre pensamos que vamos a tardar mucho menos de lo que finalmente nos va a llevar terminarla.
Lovallo y Kahneman, los autores de esta teoría, realizaron un estudio en el que preguntaron a 87 estudiantes de una universidad cuánto tiempo creían ellos que necesitarían para terminar su proyecto de fin de carrera. De media estos estudiantes estimaron que tardarían 34 días en finalizarlo el proyecto pero sólo el 30% de ellos fueron capaces de hacerlo en ese tiempo. La media real empleada en terminar sus tesis fue de 55.5 días, un 63% más de lo estimado.
Este exceso de optimismo es provocado en parte por la llamada ceguera de ausencia (absence blindness) que nos dice que por muy bien que planifiquemos nuestro proyecto nos será muy difícil planificar los imprevistos porque son eso, imprevistos, y no los conocemos de antemano. Planificamos todo lo relacionado con las especificaciones del proyecto pero olvidamos calcular los tiempos para las vacaciones, bajas por enfermedad, paternidad, maternidad, reuniones, otras tareas que causan overhead, dependencias de otros proyectos, requisitos que no están bien definidos y un larguísimo etcétera. Como dice Forrest Gump en su película, shit happens (esas cosas pasan).
Todo esto nos lleva además a tener en cuenta la Ley de Hofstadter: «Todo proyecto lleva siempre más tiempo del previsto incluso si se tiene en cuenta la propia Ley de Hofstadter«. Y si esto ocurre y nuestro proyecto se alarga más de lo previsto, probablemente caigamos todavía en más costes de lo que supone terminar más tarde. Como no llegamos a la fecha del fin del proyecto la presión nos llevará a meter a más gente dentro del proyecto para terminaar a tiempo haciendo que tengamos que contabilizar gastos extra directos como el salario de estas nuevas personas pero también indirectos de los cuáles no siempre somos conscientes.
Al incluir más personas olvidamos que necesitarán formación en el proyecto y que cometerán más errores al ser nuevos, errores que habrá que dedicar un tiempo a corregir. Se estima que un nuevo perfil en un proyecto tarda unos tres meses en ser totalmente productivo. Por otro lado, alguien que ya estaba trabajando en el proyecto tendrá que parar lo que estaba haciendo para enseñar a los nuevos. Como ya nos decía Brooks en los 70: «Añadir más gente a un proyecto retrasado, hará que se retrase aún más«.
Pero la presión aún nos hará incurrir en más costes en el proyecto. Las prisas nos harán bajar la calidad del producto que producimos, aparecerán más errores que también necesitarán tiempo para ser corregidos, o nos saltaríamos las pruebas del software con lo que saldrá a producción con bugs que nos harán perder la confianza y credibilidad con nuestro cliente. Y queremos que nos contrate de nuevo ¿no?
En primer lugar debemos hacer un esfuerzo para tener en cuenta el máximo número posible de imprevistos que puedan surgir calculando así un tiempo extra para esos inconvenientes del día a día y aquellos otros que puedan ser aún más imprevisibles.
La mayor parte de mi vida profesional, como muchos otros, la he vivido trabajando en proyectos a precio cerrado (fixed price) en concreto trabajando para administraciones públicas en las que el alcance del proyecto venía prefijado de antemano en pliegos de condiciones administrativas y claúsulas técnicas.
En este tipo de proyectos tienes que presentar una propuesta económica, de recursos y de tiempo a la administración pública que valorará cuál es la mejor de las ofertas presentadas, normalmente la de presupuesto económico más bajo, decidiendo luego qué proveedor será el adjudicatario. Por tanto, desde antes de iniciar el proyecto, tendrás que estudiar las condiciones y el alcance fijados en los pliegos y hacer una arriesgada estimación de cada una de las tareas o módulos que se requiere desarrollar y lanzar tu oferta.
¿Se puede ser ágil en proyectos en los que el costo, el alcance y a veces la fecha de entrega están cerrados desde el inicio? Yo pienso que sí, veamos cómo.
Este es el lado más arriesgado de este triángulo de hierro. Hemos hecho una estimación basada en lo que ponía en los pliegos de contratación pero estos contienen en la mayor parte de las ocasiones una descripción genérica de las tareas a realizar que luego se concretará a medida que se avanza en el proyecto o se analiza con las partes interesadas. Más que una oferta hemos hecho una apuesta que no sabemos si nos saldrá bien.
Tendremos que confiar en haber hecho una buena estimación. Por naturaleza todos tendemos a ser demasiado optimistas teniendo en cuenta sólo los escenarios en los que todo marcha bien. Sólo cuando usamos estimaciones tipo PERT en la que se nos obliga a ponernos también en el peor caso nos paramos a pensar en esos grandes imprevistos que siempre pueden pasar (como se dice en inglés, shit happens). A partir de aquí nos basaremos en las mejoras de eficacia que proporciona la agilidad.
En Scrum y otros frameworks iremos entregando cada poco tiempo una parte del alcance prometido lo que permitirá ir enseñando nuestros trabajo, haciendo correcciones y aprendiendo de lo que ya hemos hecho. En los proyectos en cascada también hay fases: Análisis, Diseño, Construcción y Testeo pero al final de las primeras sólo entregamos unos documentos sobre lo que se va a construir. Sería como analizar, diseñar un nuevo prototipo de móvil y esperar a construir 10.000 unidades para luego comenzar a venderlo y ver si le gusta a los usuarios que lo han comprado o no.
Incluir los tests y planes de aseguramiento de la calidad en cada sprint nos permitirá construir bien desde el inicio y con menos costes. Es mucho más fácil corregir los problemas de cobertura de un móvil cuando se está desarrollando y diseñando la antena en los primeros modelos que cuando ésta ya ha llegado a la línea de ensamblaje para la producción en masa.
A medida que avanza el proyecto es habitual que el cliente se dé cuenta de que necesita cosas que no están incluidas en el contrato inicial. Elaboró los pliegos con el conocimiento que tenía en ese momento pero según se adquiere más experiencia en el proyecto y se va usando la aplicación (recordemos que la vamos entregando poco a poco para que la comiencen a utilizar) se va dando cuenta de que hay partes sin las que el software sería mucho menos provechoso.
En los proyectos ágiles en los que he trabajado admito modificaciones negociadas al alcance. Si se quieren incluir cinco informes nuevos a la aplicación que la harían mucho más útil deberemos acordar qué otras tareas de igual o similar estimación quitamos del alcance del proyecto. Normalmente está tan interesado en incluir las nuevas funcionalidades que no le importa sacar del proyecto otras tareas que ahora no ve tan importantes o que incluso considera que no deben hacerse.
Para la negociación habré presentado al cliente desde el arranque del proyecto una estimación de cada una de las funcionalidades a entregar de forma que sabe cuánto valen para él cada uno de estos puntos si decide quitarlos del alcance. Esta estimación fue realizada al inicio del proyecto y puede que ahora sepamos que hay cosas que son mucho más costosas de realizar de lo que estimamos al inicio, sin embargo, no cambio esta estimación inicial para que el cliente no se sienta engañado. Normalmente las estimaciones que ahora son más costosas son compensadas con otras que ahora sabemos que no lo son tanto y que también quiere que quitemos del proyecto. En cualquier caso, si hemos conseguido que el cliente esté satisfecho con el trabajo que le hemos ido entregando poco a poco y además está contento por las nuevas funcionalidades que va a conseguir, la negociación no debería ser muy dura.
A veces, además de tener un importe económico y un alcance fijos tenemos que cumplir también con unas fechas de entregas inalterables que nos obligarían a aumentar las horas extras, los tiempos dedicados durante el fin de semana y el número de desarrolladores implicados en el proyecto aumentando considerablemente nuestro coste del proyecto.
Si hemos sido ágiles en el proyecto y hemos ido poniendo en producción cada poco tiempo lo que hemos ido desarrollando, el cliente podrá tener ya en uso el día de la fecha de entrega un porcentaje alto de lo que se necesita entregar. Si además hemos priorizado correctamente, desarrollando en primer lugar aquellas funcionalidades que más valor aportan, sólo quedarán fuera aquellas de menor importancia por lo que normalmente pueden entregarse en una segunda fase sin que se altere demasiado el valor del sistema.
Si hubiésemos realizado un desarrollo en cascada y estuviésemos retrasados, en la fecha de entrega no tendríamos nada que subir a producción a pesar de que podríamos tener un 80% del trabajo realizado. Durante las últimas semanas del proyecto tendríamos que abusar de las horas extras y del estrés para entregar ese 20% que nos falta pero probablemente sólo consigamos que sufra la calidad del software que entregamos y que se se ignore la fase de tests del desarrollo apareciendo un montón de bugs después de la entrega.
Son habituales en la industria ciertos proyectos, denominados de mantenimiento, en los que el trabajo consiste no en desarrollar nuevas funcionalidades al producto sino en realizar correcciones a bugs o las tareas mínimas para lograr que el sistema esté activo y dando servicio las 24 horas.
Pero a veces la carga de trabajo es tan alta, o la organización del equipo no es todo lo eficiente que debería ser, que no hay tiempo para corregir estos problemas de raíz y en lugar de corregir el código que produce los bugs ponemos parches que dan una patada hacia adelante a los problemas. Tampoco tenemos tiempo para refactorizar el código y aumentarle su calidad de forma que el número de errores tan alto que se come todo el tiempo de desarrollo. El problema llega a ser tan preocupante que, incluso cuando nuestro contrato incluye tareas de mantenimiento evolutivo, la corrección de bugs nos consume todo el tiempo disponible evitando que añadamos más valor a nuestro producto.
Si intentamos usar Scrum para poner orden en esto probablemente no nos vaya a funcionar porque semana tras semana nuevas tareas de corrección de bugs nos asaltan de forma urgente en nuestra planificación del sprint impidiendo que lleguemos nunca a cumplirlo. Retomar el trabajo días después hace que tardemos aún más debido a los cambios de contexto y porque nos vemos asaltados de nuevo por más bugs urgentes. Las planificaciones de los sprints no serán nada fiables, el análisis hecho para las nuevas funcionalidades caducará o habrá que revisarlo y ningún sprint se cumple.
Yo utilizaría Kanban en lugar de Scrum en una primera fase de estos proyectos. El uso de Kanban conlleva un menor cambio cultural en el equipo de trabajo y en los clientes y una menor sobrecarga de reuniones pero sobre todo permite una mayor agilidad para dar entrada a tareas urgentes en medio de la carga de trabajo de la semana.
En este Kanban utilizaría tres códigos de tarjetas de colores: Rojo para las tareas de corrección de bugs, amarillo para las tareas que corrigen deficiencias técnicas y code smells en nuestro código y que están haciendo que el código sea difícilmente mantenible o están produciendo bugs de forma continuada. Por último utilizaría el color verde para las tarjetas que implican el desarrollo de nuevas funcionalidades.
Tampoco separaría el equipo en dos partes, uno para corregir bugs y otro para desarrollar nuevas funcionalidades. Hacer eso está reconocido como una mala práctica debido a que los equipos dedicados a los nuevos desarrollos no aprenden lo que pasa cuando se introducen errores y por otro lado se castiga a los equipos de mantenimiento a que sólo arreglan desaguisados y con prisas y tampoco crean nada nuevo que aporte valor y reconocimiento al equipo.
En un principio nuestro Kanban estará lleno de tarjetas de color rojo pero si logramos introducir nuevas tarjetas de color amarillo y subirles la prioridad a aquellas que solucionan un número alto de bugs, en un periodo prudente de tiempo deberíamos conseguir bajar el número de bugs que se están produciendo obteniendo tiempo así para añadir al Kanban más tarjetas amarillas o incluso verdes.
Con el paso del tiempo, nuestro tablero Kanban deberá mostrar un reportorio más amplio de colores en el que finalmente, con suerte, predominará el color verde. Para esto sirven los tableros visuales Kanban, para dar visibilidad a lo que está sucediendo en nuestros proyectos.
Es en este momento, en el que el equipo realiza sobre todo tareas de mantenimiento evolutivo, cuando podríamos volver a pensar en utilizar Scrum para nuestro proyecto bajando un poco el factor de dedicación para solventar aquellas tareas urgentes que nos llegan ahora con menor asiduidad.
En Scrum es mejor no diseñar todo el proyecto antes de comenzarlo. Analizarlo todo, diseñarlo todo, construir un gran documento de requisitos de proyecto muy detallado es volver a trabajar como en los clásicos proyectos en cascada. Todas las especificaciones han sido declaradas desde el inicio y no hay posibilidad de cambio.
A estos diseños se les llama big up-front design y no permiten adaptarse a los cambios que pueden verse necesarios a medida que se va construyendo porque todo está ya especificado en un gran diseño antes de comenzar a construir una sola línea de código.
Si tienes una lista de producto pequeña al inicio, que puede ir creciendo a medida que se va avanzando en el proyecto y que se va adaptando a las opiniones y necesidades del Interesado, podrás construir un mejor producto que si haces todo o buena parte del diseño por adelantado. Mientras se va construyendo el proyecto, incluso puede que ya lo estén usando. Alguno de los Interesados puede opinar que es mejor crear una exportación a MS Excel de los informes, y esto es algo en lo que nadie había pensado por lo que no se incluyó en el diseño hecho por adelantado al inicio del proyecto.
Puede también que ya no estén tan interesados en la integración con el sistema de contabilidad Contaplus. Es un desarrollo muy complejo para las ventajas que se obtendrían y corre el rumor por la empresa que el sistema de contabilidad será migrado a SAP antes o después, así que para qué desarrollarlo ¿Qué hacemos ahora con todas las horas que usamos para diseñar esa integración con Contaplus? Puede incluso que ya estén preparadas las clases y los esquemas de base de datos con los campos necesarios para esa integración y ahora ya no van a ser usados.
El proyecto se te ha vuelto una pesadilla, todas las tareas hay que volver a abrirlas cuando se está terminando el proyecto porque el cliente las rechaza en las pruebas de aceptación o porque se convierten en bugs una vez están en producción. Los Interesados están descontentos y tu equipo está más tiempo buscando y corrigiendo incidencias que desarrollando nuevas funcionalidades que den más valor al producto. Para colmo de males todos están perdiendo los nervios con la situación.
Esto es señal de que en cada Sprint se han estado entregando las cosas sin estar realmente terminadas y sin ser suficientemente probadas. Una forma de probar más y mejor es automatizando los tests con pruebas unitarias, o tests de regresión y de integración con herramientas como JUnit, o de record&play como Selenium IDE. Irás creando unos pocos tests más cada Sprint para probar las historias de usuario desarrolladas en ese Sprint y el núcleo de la aplicación pero añadirás más el siguiente Sprint mientras se siguen probando automáticamente las pruebas de todos los sprints anteriores.
Los tests automatizados difícilmente sustituirán totalmente a los testers y a las pruebas manuales. Resérvate los dos o tres últimos días del Sprint para que se pare el desarrollo de funcionalidades y todos los miembros del equipo comiencen a probar las funcionalidades ya hechas para asegurarse de que están completamente libres de errores. Cada uno puede probar sus propios tickets y al terminar pueden coger las tarjetas de otros y comenzar a probar las funcionalidades de los demás miembros del equipo.
Esto sucede cuando la Lista del Producto ha sido dividida en fases coincidiendo los sprints con una serie de entregables definidos desde el inicio del proyecto. Es decir, que si tenemos que entregar 80 funcionalidades en un proyecto de un año, se definirá desde el arranque del proyecto que debemos entregar 3 funcionalidades en los 26 sprints del año (suponiendo sprints de dos semanas) y además se definirá qué tres funcionalidades en concreto se van a entregar y éstas son inamovibles.
Esto puede convertir al proyecto en un terror de noches sin dormir porque en este Sprint hay que entregar las funcionalidades P, Q y R y en los sprints pasados no pudieron terminarse E, H, J y L. El trabajo se nos acumula. Además no estamos dando la oportunidad de redirigir el proyecto dando más peso a unas funcionalidades, quitándoselo a otras para añadir o quitar funcionalidades según lo que se demuestre más efectivo o importante.
La Lista del Producto se ha convertido en un contrato y cada Sprint en otro del que además arrastramos errores y deuda técnica dejada en el anterior. No se deja hueco para trabajar más en unas funcionalidades que llevaron más tiempo del previsto inicialmente. Todo está fijado y anclado a una estimación que se hizo al inicio del proyecto cuando no se tenía idea de qué iba a ser más fácil, qué más difícil o que podía obviarse por resultar irrelevante. Cumpliremos el ‘contrato’ de nuestra estimación diga lo que diga aunque el tiempo haya demostrado lo equivocado que estábamos cuando la hicimos.
Ya está a la venta en Amazon las versiones en papel y electrónica del libro Curso Práctico de Scrum: Algo más que teoría. Puedes comprarlo aún a un precio reducido mientras esté en promoción.
 |
| Curso práctico de Scrum: Algo más que teoría |
En esta seríe de posts voy a publicar una lista de los errores de Scrum más habituales que hacen que fallen las implementaciones de Scrum en muchos proyectos. Muchos de estos errores los he cometido yo mismo. Te dejo aquí los dos primeros de la serie por si pueden ayudarte a que no los cometas tú:
