Lo siento mucho, pero sólo con Scrum… no vas a terminar un desarrollo software con éxito

Como en todo, en esto del software también hay mucha “softwarepredicación”. Y como en cualquier pseudociencia, hay quien se aprovecha de los proyectos desesperados, vendiéndoles maravillosas soluciones. A grandes problemas y gente desesperada… soluciones fáciles. Milenaria estrategia de venta que no falla.
Supongo que ganaría más clientes y vendería más libros predicando que SÓLO necesitas Scrum, que es la mejor solución jamás inventada para TODOS los problemas del software. Es fácil, bonito, se puede enseñar jugando, se explica con alegría, lo usa Google.
“Tu confía ciegamente en los sprint y todo se va arreglando poco a poco” (esto lo he escuchado yo en pesona). «No intentes adaptar Scrum a tu empresa, confía en la agilidad (en la fuerza?) y sigue usandolo». Como en la parapsicología, si dudas o no te funciona Scrum… «es que no has creído lo suficiente en él» (esto lo he escuchado y leído yo en persona).
Pero lo siento, no puedo hacerlo ni lo voy a hacer; ni he vendido nunca, ni voy a vender, que sólo con Scrum vas a ser feliz toda tu vida, aunque me quede sólo diciéndolo. En mi experiencia profesional (de dejo aqui el post de después de pasar por más de 56 empresas), nunca he visto a una empresa mejorar de la noche a la mañana SÓLO usando una nueva metodología.

No me cansaré de decir que hacer software es complejo, lo ha sido y lo será. El día que no lo sea lo harán máquinas (en ello están mis amigos del MDD) y estaremos hablando de otra cosa.
Concluir un proyecto con éxito, y de la mejor manera, en economía y calidad, requiere de mucho conocimiento, ingeniería, gestión, talento y técnica, así resumidamente. No te dejes engañar.
Claro, hay proyectos y proyectos. Si tienes un pequeño proyecto, seguro requieres menos prácticas de ingeniería del software. Pero si trabajas en un proyecto medio o grande, si quieres asegurarte el terminar vivo, necesitas (entre otros muchos, la siguiente es solo un ejemplo)…
– Control de versiones y gestión de la configuración.
– Gestión de riesgos.
– Asegurar la calidad del producto software.
– Pruebas: carga, unitarias, integración, etc. Que no te van a funcionar si no tienes…
– Una buena arquitectura y un buen diseño.
– Trazabilidad, control de incidencias y problemas, etc.
– …
Y ninguna de las anteriores prácticas están contempladas en Scrum. Y en sí mismas, cada una de las anteriores, es mucho más complicada (y también menos vendible y marketiniana) que Scrum. Ni leyendo los para mi 10 mejores libros de ingeniería del software, aprenderíamos todo lo necesario para conocer solo las anteriores áreas de ejemplo.
¿Es Scrum una buena práctica? Sin duda. Buenísima. A mí me encanta. Pero es sólo una parte de la solución. Y, además, no es la única solución. Hay otras muchas maneras de gestionar un proyecto. Y cuando digo que hay otras soluciones no estoy diciendo que esas soluciones sean predictivas o el cascada, antes de que algún amigo me lo comente en los comentarios. Hay otras maneras de gestionar iterativa e incrementalmente un proyecto, con menos presión en tener iteraciones cortas, iterativos y no incrementales, etc.

24 comentarios en “Lo siento mucho, pero sólo con Scrum… no vas a terminar un desarrollo software con éxito”

  1. Es cierto que alguien está ciego o ha sido engañado si cree que por usar Scrum solo va ha terminar bien el proyecto mágicamente. Pero los ejemplos que has puesto (y otros muchos), ¿no se podrían considerar parte de esta metodología? Por ejemplo, he leído en algún libro de Scrum de meter tareas tales como pruebas unitarias, control de versiones en el Backlog dándoles identidad de tarea aunque su desarrollo vaya a ser en paralelo, y en caso de que el cliente no lo entienda al pensar que todo eso sobra al no ser puro desarrollo (supongo que te sonará), asignarle un tiempo mayor a las tareas para poder incluirlo.

  2. Pingback: Bitacoras.com

  3. Hola Javier,
    Pienso que lo que venía en los libros que leíste en mi opinión es Scrum + otras prácticas de ingeniería del software totalmente necesarias. Lo que coincide con aquello de que sólo con Scrum no tienes lo suficiente.
    Saludos

  4. Al final es tener sentido común y saber bien de que hablamos 🙂 Scrum es para gestionar equipos, da igual que sea software, que sea hacer coches, etc. Es, como dices, gestión de equipos. Luego, para el caso concreto del software, hacen falta prácticas de ingeniería como XP.
    Los talibanismos no sirven, el sentido común si 😉

  5. La única forma de asegurarte el exito en un proyecto de desarrollo de software es tener a los mejores programadores. Punto!
    Todo lo demás son escusas para no reconocer que no los tienes.

  6. Hummmm no estoy tan de acuerdo virgilio, aunque depende a que llames buenos programadores. Pues puede haber mucho talento tecnico pero todo en si es una orquesta donde un director dirige los diferentes talentos de cada integrante y cada integrante aparte de ser muy talentoso debe (a fuerza) estar haciendo lo que le gusta, sino, la musica no se escucha bien, no transmite.
    Igual los equipos de sw, muy cierto, lo mas importante son las personas, y en su forma integral, no solo conocimiento tecnico, si buenos programadores significa integral, estoy de acuerdo contigo.
    Saludos,

    1. Claro, eso mismo creo que es a lo que se refería Virgilio. Los buenos programadores ( son carismáticos, simpáticos, se ayudan entre si, y funcionan como una máquina ). Vamos, que no se busca el saber más que el resto, buscan trabajar ( como si fuesen fundadores todos de una empresa y el éxito dependiera de ello ).

      1. Esos son los programadores «buena gente». Pero algunas veces los «buenos programadores» no son ni simpaticos, ni carismaticos, ni nada de eso. Sin embargo puede existir un liderazgo que sepa canalizar las diferencias. No me creo yo que con hacer una barbacoa y jugar todos un arcade retro, se vayan a solucionar los roces.
        Y lo otro, lo de «buscar trabajar», yo le llamo «ponerse la camiseta» y eso se lo reservo a los duen^os. Especialmente si tomo en cuenta que tengo compan^eros que a las 5pm salen disparados para ver a sus hijos, y al mismo tiempo hacen muy bien su trabajo.
        Perdonad la falta de acentos y virgulillas

  7. Pingback: 20 cosas importantes que te puedes haber perdido este verano… - Javier Garzás, sobre calidad software y otros temas relacionados

  8. Hola,
    estoy muy interesado en el tema del aseguramiento de la calidad en equipos y desarrollos Scrum. ¿Puedes recomendarme algún articulo, libro, etc..?
    Muchas gracias por tu ayuda.
    Salut,

  9. Pingback: Analisis-Estimacion-y-Planificacion-Agil | Business World TI

  10. Hola que tal;
    He leído sobre sus comentarios y en general son muy interesantes, por mi parte soy Analista de Negocio y he pasado por las áreas de desarrollo, programación, pruebas, diseño, etc. En todos los casos he visto que cada proyecto es diferente y por ende se debe abordar según sus particularidades. Es necesario conocer de todos los recuersos disponibles por lo que creo que las metodologías que sean …RUP, SCRUM, SDLC, etc son herramientas para la definición de requerimientos de software que son utilizadas solas o en conjunto para poder obtener resultados dependiendo de la particularidad de cada proyecto. Sin embargo un gran problema que veo es que se asume que el proyecto existe… y de hecho las metodologías de desarrollo de software en general parten del hecho de que el proyecto y la necesidad de crear un software existe, sin embargo es común encontrar que se desarrollan aplicaciones de software extraordinarias, con una gran cantidad de funcionalidad incorporada completamente alineados a los estándares de desarrollo… en general el software funciona perfecto.. pero no sirve.. Y no sirve no por que sea malo si no por que no cumple con los requrimientos del negocio.
    Bajo ello discrepo de la opinión de Virgilio ya que 9 mamás no hacen un bebé en un mes.. es decir los mejores programadores el mundo no hacen el mejor software del mundo ya que el mejor software del mundo es aquel que cumple con las necesidades del negocio al 100% en el menor tiempo posible y al menor costo … y eso no depende de la cantidad de programadores o de su conocimiento en el área técnica.. eso depende de saber ´con certeza que es lo que se quiere hacer y por qué es necesario.
    De ahi que me uno al comentario inicial, ninguna metodología te resuelve todos los proyectos, ya que lo mismo puedes topar con optimizaciones, rediseños o reingenierías e incluso con mezclas de cada una dependiendo de cada parte que se aborde del negocio, el reto existe en saber cuales son los requerimientos del negocio y la justificación de los mismos, para que ahora si el trabajo de los programadores sea eficaz, eficiente y dirigido.. no que tengan que estar trbajando sabados domingos y dias festivos solo por que alguien no supo definir la dirección real del proyecto.

  11. Como comentario adicional, el tener un martillo en la mano no nos hace carpinteros… es el saber como y cuando usarlo lo que nos da la posiblidad de llegar a serlo…

  12. Sin duda, SCRUM es algo que no puede ayudar, pero como lo dice Javier no soluciona todo, me desespera aquellos amantes de SCRUM que lo defienden, creo que scrum no permite resaltar las habilidades de cada miembro del equipo y que se invierte demasiado tiempo en reuniones, en fin pienso que con sentido comun se pueden obtener cosas mejores al scrum.

  13. Basura metodológica creada para sustentar una nueva profesión innecesaria a la que sus practicantes atribuyen beneficios económicos para empresas. Se apoya en actividades improvisadas con nombres sofisticados para enredar a cualquier curioso o empresa incauta a la que le venden esto como lo último y que luego de un tiempo se dan cuenta que no es más que una perdida de tiempo sin resultados de impacto.

  14. Sandra Da Silva

    Hola a todos… Estoy muy de acuerdo con el artículo y también con la opinión original del autor… pienso personalmente que SCRUM no es más que una moda… hay mucha gente que conozco que de verdad cree que aplicando esto milagrosamente el proyecto se gestionará por si solo… y de manera exitosa… SCRUM no es para nada robusto ni sustentable en el tiempo… Adicional a sus comentarios, pienso que para aplicar SCRUM en cualquier organización y que funcione (esta parte pequeña en la gestión de todo proyecto) debe antes prepararse al equipo del proyecto… Si un equipo; por cultura de la organización; no posee la costumbre de reportar sus avances a tiempo, trabajar bajo presión documentando lo que hace, reportando inconvenientes y de verdad dedicandose a ejecutar lo que debe hacer de manera oportuna… NO VA A FUNCIONAR… Será solo una lindisima cartelera con unos bellos cuadrantes repletos de papelitos muy lindos… pero que solo servirán como decoración en la oficina…
    Una organización debe; antes de incorporar SCRUM en su gestión de proyectos; dedicarse a romper paradigmas y hacer que el nivel de madurez de la organización aumente… Por otro lado; y como gerente de calidad y mejores prácticas y profesor universitario de proyectos siempre lo comento: lo más importante en todo proyecto es dedicarse a entender el requerimiento, la necesidad a cubrir con el proyecto, el problema que se debe resolver, involucrando de manera temprana y efectiva a los interesados (todos los que serán impactados) por el proyecto… que a su vez serán los que lo evaluarán y aceptarán… luego de tener esto muy claro será mucho más efectivo ejecutar el proyecto con éxito.

  15. Estamos 2018 y la moda sigue fuerte, ahora hay gente que solo se prepara para dar charlas de Scrum y Agiles. Y convencer al resto que se deben de certificar.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba