El siguiente post está basado en hechos reales. Son algunas de las cosas que hemos hecho mal cuando hemos querido aplicar Scrum por primera vez. Seguro que más de uno se siente identificado, lo bueno es que de los errores también se aprende. Ahí van:
Dejar de lado al cliente
Esto es algo en lo que tenemos que concienciarnos los que nos gusta ir a nuestra bola (el primero yo). Por muy bien que se te dé programar, diseñar, analizar pliegos de 200 páginas o crear la mejor arquitectura… nadie conoce mejor el producto / proyecto que tu cliente. Pretender trabajar de espaldas a él, sólo te va a llevar a una cosa: “hacer algo que no sirve” y no hay nada más desmotivante que desarrollar aplicaciones que no usa nadie.
Así que involucra a tu cliente en el proceso de desarrollo de software y si no quiere, entonces olvídate de Scrum.
Esto tiene sus riesgos, básicamente porque como norma tu cliente no sabe de gestión de proyectos software. Así que antes de empezar a trabajar con él deberías explicarle cómo desarrollas software (Scrum u otra metodología ágil), sino pensará que todo vale e irá pidiendo cosas sin ton ni son. Es decir, hay que involucrar al cliente, pero jugando con nuestras reglas.
No redactar historias de usuario
Seguramente hay mil maneras de definir requisitos software. Desde redactar casos de uso hasta el gran fiasco de la ingeniería del software: ‘modelar los requisitos’.
Sin embargo, utilizar historias de usuario te lleva mucho más al grano, a hablar del problema y de lo que interesa del problema. Quién, qué y para qué. Luego cuéntame algunas restricciones, validaciones y cómo lo vas a probar. Que sea fácil de mantener, actualizar y que todos entendamos de lo que estamos hablando.
Parece una chorrada pero este es uno de los puntos clave para poder ser ágil o no, y ojo, que sigue siendo una de las cosas más complicadas dentro del desarrollo de software y que Scrum (ni ninguna metodología ágil) resuelve aunque si tiene técnicas que ayudan.
Equipo poco experto
Pensar que cualquiera puede ser ágil es otro error típico. Hace falta un equipo con personas que sepan de todo y además sean buenos. Pretender aplicar Scrum en una aplicación web donde 4 de 6 miembros del equipo no saben lo que es Javascript no te va a hacer ágil, te va a hacer pensar que Scrum no sirve… lo que no sirve es tu equipo.
Equipo no comprometido
Esto normalmente no debería pasar, a no ser que alguien tenga la idea de aplicar Scrum pero incorporando al equipo personas que no saben de qué va eso. Scrum va de compromiso, sino tampoco funciona.
Tu cliente no es ‘ágil’
Y si sois muy cracks, expertos, hacéis TDD, integración contínua, etc. pero vuestro cliente os dice: “A mí dejarme de chorradas y de aquí a 6 meses me entregáis la aplicación”. Fracaso absoluto
¿Quién es mi dueño de producto?
Otra cosa que me ha pasado, es aplicar Scrum a un proyecto interno, donde el dueño de producto era alguien interno de la empresa. Y de repente, a mitad de Sprint que llegue otra persona que no está en el día a día del proyecto (un jefe), vea las tareas del Sprint y diga que no hay que hacer eso, sino otra cosa que es más prioritaria. El resultado se llama: desmotivación.
Otra situación es, planificar un sprint y que a la semana alguien decida que dos personas del equipo se tienen que poner a hacer otra cosa para otro proyecto. Resultado: tu cliente piensa que eres un inepto, deja de confiar en ti y obviamente el equipo se desmotiva.
No terminar historias completas
Esto es algo peliagudo. ¿Cuándo algo está terminado? Una cosa está clara y es que según Scrum hay que entregar historias completas y terminadas al final de cada sprint. Bien pues, prioridad número uno, qué es terminado y acordarlo bien con el cliente, sino Scrum no sirve.
No dimensionar bien las tareas
Otra experiencia personal, después de pelear para desglosar las historias en tareas pequeñas de no más de 15 horas, me voy de vacaciones y al volver me veo el panel con historias de 40 horas o_O. Obviamente las 40 se convirtieron en 80 y algunas nunca se acabaron, lo que se acabó es Scrum.
No tener la visión de producto
Esto me ha pasado durante muchos años y es trabajar en proyectos donde no sé ni quién es el cliente, ni quién va a usar lo que estoy programando, si es alguien con estudios, si es un señor mayor que no ve o no sabe manejar el ratón, ni realmente cuál es la finalidad de lo que hago, ¿es para ser más productivo, es sólo porque tenían dinero para gastar en un proyecto, es una inversión clave de nuestro cliente? ¿Es un producto? Si no lo es, seguramente no necesites ser ágil.
No tener la ambición de mejorar
Esto no tiene que ver con Scrum directamente, pero me he dado cuenta a lo largo del tiempo. Ver programadores con varios (más de 5) años de experiencia y que conforme pasan los años no hacen las cosas mejor… ese apalancamiento, el no querer mejorar, aprender cosas nuevas (patrones, cómo testear, cómo automatizar esos despliegues que hago a mano desde hace 10 años…). Al fin y al cabo hacer mejor tu trabajo.
Querer ser ágil al final te lleva a replantearte la manera en las que haces las cosas, buscar siempre una manera mejor. Aquí entran en juego también las retrospectivas, si no haces retrospectivas no haces Scrum.
En fin, sin ser un experto en Scrum o metodologías ágiles, esas son algunas de las cagadas que he ido haciendo los últimos meses y lo que me queda 🙂 Lo dicho de todo se aprende. Aunque lo realmente importante es que se pueden hacer grandes productos software sin aplicar Scrum y se puede hacer la mierda más grande siendo ágil.
Hola Sr. Romeu
Son buenos los posts que publicas ya que tienen muy buen contenido.
¿Me podrías asesorar con algunas dudas que tengo?
Lo que sucede es que quiero realizar y administrar un proyecto de desarrollo de sw (como freelancer). Lo cual nunca he realizado antes, sólo me he puesto a trabajar como codificador … perdón … como programado jr, el ver puro código.
Me he puesto a estudiar un nuevo lenguaje y nva. tecnología C# ASP.NET y MVC. Y deseo aplicarlo en un caso práctico.
Pero a la vez quiero administrarlo muy bien, llevar una documentación, por lo tanto tomé un curso de Agil Project Managment .
Luego leí tus posts. Y me surgieron varias dudas.
¿Agil Project Managment es lo mismo que Scrum?
¿Debería de utilizar el Proceso Unificado para le desarrollo de sw y a la vez utilizar APM (Scrum) para la administración del proyecto ? Para ser claro. ¿Se debe de trabajar con los dos o solo con uno?
Tengo entendido que los dos se trabajan por iteraciones (Sprints).
Tenía pensado utilizar Project de Microsoft para administrar el proyecto, pero leí tu post de que esa herramienta no sirve para desarrolo de sw, entonces, sólo utilizo Burndown chart? O cuál otra herramienta me recomendarías para administrar el proyecto?
Muchas gracias.
Saludos.
Hola Rodrigo,
me alegro de que mis posts te despierten esas inquietudes :). Antes de nada quiero decirte que lo que escribo son simplemente opiniones personales basadas en mi experiencia, por ejemplo, cuando digo que los diagramas de Gantt no sirven para planificar proyectos software, es sólo mi opinión (argumentada), por supuesto que habrá quién lo considere válido y puede argumentar lo contrario.
Una vez dicho esto, te doy mi opinión respecto a tus dos preguntas:
Scrum es sólo una manera de hacer gestión ágil de proyectos, pero hay muchas otras maneras. Normalmente en los cursos de gestión ágil de proyectos software, explican Scrum, porque define un conjunto de buenas prácticas y pasos para gestionar proyectos. Digamos que facilita a equipos de desarrollo hacer gestión ágil de proyectos, sin tener que pensar mucho.
Mi recomendación sería que leyeras todo lo que puedas sobre Scrum y gestión ágil y lo apliques en un proyecto al pie de la letra, luego con tu experiencia lo vayas adaptando a tus gustos o tu manera de trabajar. También te digo una cosa, hacer Scrum bien NO es nada fácil.
El proceso unificado es otra manera de gestionar proyectos y no es ágil, pero puede ser igual de válido.
Yo te diría que pensaras en el tipo de proyecto, tu cliente, las personas que van a trabajar en el proyecto y luego elijas el ‘framework’ de gestión de proyectos que mejor se adapte.
Por ejemplo, si el proyecto en el que vais a trabajar va a ser muy cambiante o innovador, las personas que van a trabajar tienen mucha experiencia y saben lo que es el desarrollo ágil y el cliente está dispuesto a involucrarse en el proyecto a diario, entonces haz gestión ágil (Scrum, Pivotal, etc.)
Por otra parte, si vas a empezar un proyecto que está bastante mejor definido o a coste cerrado, donde hay unos casos de uso que se pueden descomponer en iteraciones de dos o tres semanas, donde el cliente irá viendo el resultado cada mes o algo así y el equipo de desarrollo no es experto como para hacer integración continua, TDD, etc. entonces puedes hacer una gestión más clásica (proceso unificado)
Respecto a herramientas, nosotros usamos JIRA que es de pago, pero para proyectos de software libre dan licencias gratuitas. Para proyectos ágiles yo soy más partidario de utilizar el típico panel de Scrum en la pared que todo el mundo pueda ver y tocar.
Al final las respuestas las vas a encontrar en tu propia experiencia, es cuestión de ir probando 🙂
Ánimo 🙂