A lo largo de las últimas décadas, desde principios de los ’90, Scrum y el desarrollo ágil se han convertido en una auténtica seña de identidad en un número cada vez mayor de proyectos de desarrollo de software.
La visión centrada en eventos iterativos incrementales, el reparto de papeles y las pizarras llenas de post-its de colores vivos se han venido identificando cada vez mas con el desarrollo de software, y su biblia, el manifiesto ágil, ha devenido en una especie de garantía, de manera de asegurar que se seguía un procedimiento adecuado, moderno y centrado en la eficiencia. Son muchos los proyectos que responsabilizan al desarrollo ágil y a metodologías como Scrum de una parte muy significativa de su éxito.
En el mundo del desarrollo de software, Scrum se ha visto habitualmente como una manera moderna de entender la administración de tareas con una coordinación compleja. Ponía una metodología estructurada en algo que, tradicionalmente, había funcionado de una manera demasiado caótica o excesivamente secuencial y rígida. Pero el mundo del software ha evolucionado muchísimo en los últimos tiempos, y nada hace pensar que Scrum y las metodologías ágiles, por mucho que algunos pretendan convertirlas en algo cercano a la religión, vayan a tener vida eterna.
Un interesante comentario en Slashdot, «Is Scrum still relevant?«, me lleva a leer sobre Open Development Method, una metodología de desarrollo de software que trata de incorporar toda la experiencia de los cada vez más abundantes y ubicuos proyectos de código abierto. Indudablemente, la idea de «abierto mejor que cerrado» que hace algunos años todavía era puesta en duda, ha probado sobradamente su valor a lo largo de miles de proyectos de desarrollo de software en todo el mundo y todas las industrias, y es cada vez más abrazado por más compañías, incluyendo las que inicialmente lo atacaban y despreciaban.
¿Cómo se integran las prácticas habituales en los proyectos de código abierto en una metodología de desarrollo de software? La idea, según su desarrollo incipiente, intenta poner el foco en la calidad del software, acompañada de los adecuado procesos de documentación, los procesos de testing adecuados, la participación en discusiones, y valores como la transparencia, la asincronía y la democracia. Elementos que están presentes de una u otra manera en los infinitos proyectos de código abierto exitosos que han generado cantidades ingentes de valor en todo tipo de actividades, pero que no están especialmente sistematizados, procedimentados o destilados en forma de metodología específica. De ser capaz de hacerlo de una manera eficiente y con visos de funcionar, esta idea del Open Development Method podría llegar a convertirse no en una simple idea que evoluciona como siguiente paso tras «la era Scrum», sino en algo mucho más importante que nos cansaremos de ver en todas partes.
De entrada, la idea de plantearse un «adiós Scrum» resultará, sin duda provocativa. Aunque no es una metodología tan longeva, lo cierto es que se ha implantado con bastante solidez, con resultados razonablemente positivos en general, y con auténticos impulsores que ven no solo Scrum como un método de trabajo, sino el agilismo como una especie de religión. Para alguien que ha sublimado una herramienta, la idea de que ésta tiene carencias resulta difícil de aceptar, y se tiende a preferir hacer pequeñas modificaciones inclusivas incrementales frente a cambios radicales. La comunidad creada en torno a Scrum y al desarrollo ágil, por otro lado, está bastante cohesionada como corresponde a algo que se inició como trabajo colectivo de una comunidad, lo que anticipa que no van a dar por muerta su metodología sin algo de lucha.
¿Hablamos de cambio de era? ¿De evolución razonable? ¿De sustitución por algo que se adapta mejor a los cambios que ha experimentado el desarrollo de software en los últimos tiempos? En cualquiera de los casos, veo muy posible que escuchemos hablar de Open Development Method en unos cuantos sitios…
This article is also available in English in my Medium page, “Goodbye, Scrum?«
Agile es una metodología secuencial de gestión de procesos. Establece prioridades y «milestones». La metodología de desarrollo de Open Source no la sustituye, ya que es un sistema de asignación de recursos y tareas. No hay un proceso, solo una cola de tareas para cada recurso. Son peras y manzanas.
Probablemente la metodología Open Source está más cercana al paradigma Kaizen, que es lo que se está poniendo de moda últimamente, dada la velocidad que adquieren ahora los cambios en la mejora del software. Es un proceso continuo.
El entorno Open Source difiere mucho de un entorno corporativo, ya que en este es necesario hacer una asignación de tareas dividida y limitada en el tiempo, mientras que en Open Source el desarrollo adopta un desarrollo más continuado y flexible.
No creo que exista un modelo único, aunque sí es cierto que SCRUM ha sido un estándar en entornos corporativos y ahora acusa bastantes limitaciones.
Para quién no entienda esto, puede empezar por leer «La Catedral y el Bazar» para comprender un poco mejor las diferencias en el desarrollo de software.
La gestión de proyectos siempre evoluciona según se van desarrollando nuevos marcos de trabajo y herramientas, y ahora mismo, los sistemas de control de versiones y gestión de proyectos hacen más cercano al mundo corporativo la metodología Open Source.
La gestión de procesos en la actualidad es algo más complejo que el tablero de SCRUM, eso desde luego.
El principal problema de Scrum, y que ha llevado al escepticismo sobre esa metodología ha sido el abuso provocado por la moda de implantarlo incluso en entornos donde no era viable. Yo he vivido el fracaso de Scrum varias veces y he conseguido implantar con mucho éxito Kanban como sustituto, funcionando bastante bien.
Scrum funciona sólo en proyectos modulares y con equipos de tamaño medio. Para equipos pequeños que funcionan con microproyectos, en algunas ocasiones mezclados incluso con tareas de servicio, Kanban se ha demostrado, en mi experiencia, muchísimo más flexible y eficaz.
Totalmente de acuerdo contigo. Y cierto que ya te piden scrum hasta para ser director de marketing… Cuando hace un par de años solo sr sabía de estos métodos en entornos de programación.
Personalmente el método jit, del que viene el kanbam, me parece el más optimo. El problema es saber implantar estos sistemas, ya que muchas veces los equipos carecen de formación o conicimientos básicos.
Un saludo.
Forma parte del ciclo tecnológico habitual. Siempre ha habido un lenguaje de programación, una metodología, una plataforma, una [ponga el nombre que le apetezca] que se ha puesto de moda y que hay que seguir a pies juntillas ‘porque es lo mejor que se ha inventado’.
Con el tiempo todo (todo) es sustituido por la nueva moda de turno.
Bueno, Don Enrique, Maestro.
Yo todavía le doy larga vida.
Recuerde que a COBOL lo dieron por muerto hace 30 años… y dicen por ahí que todavía colea.
;-)
COBOL está muerto. Si sigue en activo es únicamente por la proverbial falta de inversión en tecnología que se da en España, que ha hecho que pervivan aplicaciones hechas en COBOL en banca y seguros principalmente, donde se siguen usando incluso AS400. Esa miopía en lo referente a la inversión en IT, fuera de España es inexistente. Y lo digo desde Alemania, con conocimiento de causa. Pero el mercado de IT español es completamente disfuncional, y no sólo en este aspecto.
Si bien es cierto que España no se caracteriza por ser el mercado IT más puntero del mundo, achacar la supervivencia de COBOL y entornos AS/ 400 únicamente a la falta de inversión en tecnología me parece simplificar demasiado el problema. La complejidad de migrar determinados tipos de carteras de seguros (por ejemplo la de productos de vida) es por ejemplo otro factor muy importante para que muchas aseguradoras no se planteen estos cambios. Y por cierto, algunas de las instalaciones de AS/ 400 más grandes de Europa no son precisamente de empresas españolas.
Colear, lo que se dice Colear….
Pues aun varias mainframes y sistemas de empresas tienen como punto de entrada, sistemas que dependenden de Cobol..
Funcionando ya en lugares inesperados: Open development en marcha en el Ayuntamiento de Madrid: https://github.com/AyuntamientoMadrid/participacion
¡¡Qué bueno, no lo sabía!! Aunque en realidad, no esperaba menos de Pablo! :-)
Interesante el Open Development Method, le tengo que echar un buen vistazo.
Waterfall, Scrum, Kanban, Lean… son metodologías. No todos los proyectos necesitan seguir la misma metodología, y algunas son contraproducentes para determinados equipos y proyectos. Por poner una analogía de estas que nunca funcionan bien, no es lo mismo construir una chabola con tu abuelo, que una catedral con otros cientos de personas durante varios siglos.
Es más, no todos los proyectos necesitan adoptar todas las partes de Agile (dicho esto por uno de los autores originales del Agile Manifesto).
Parte del problema es que alrededor de Agile y sobre todo de Scrum, se ha montado un negocio y se ha corrompido su esencia, cobrando dinerales por certificaciones cuyo beneficio no está muy claro. ¿De verdad pagar esta cantidad de dinero por formar a alguien un par de días va a mejorar enormemente la calidad del software de mi empresa?
Pero las empresas quieren garantías, quieren rigidez, quieren estabilidad y todo esto trae orden al caos. Pero acaban convirtiendo lo «ágil» en lo mismo que tenían antes, pero con otro nombre que podemos estampar como un sello.
Y ya lo siento, me he dejado llevar.
Estoy de acuerdo, hay mucho negocio, pero te puedes certificar simplemente pagando un examen. Y con respecto a la pregunta que haces la verdad es que conozco casos en los que pagando ese dineral por dos días ha mejorado el software y la gestión de procesos. A medio plazo se ha recuperado la inversión.
Leer un post titulado ¿Adios Scrum? se te antoja un título sensacionalista cuando has tenido la suerte contar con el equipo humano y las condiciones empresariales adecuadas para que Scrum u otra metodología agil o una combinación de varias con personalizaciones te de buenos resultados. Por que? porque entonces entiendes q lo importante no son las reglas de la metodología, ni el nombre, lo importante son los conceptos que subyacen y sobre todo su asimilación por parte de toda la empresa.
Por otro lado si contribuyes en algún proyecto open source sabrás que no todo son discusiones en hilos ya que es habitual que haya un comité que hace reuniones semanales que en parte se asemeja a las reuniones de sprint pues en ellos se asignan historias a miembros del comité, y también se parecen a las reuniones de fin de sprint pues se muestran demos de lo desarrollado. Claro obviamente no se estima el coste de las tareas pues los desarrolladores son voluntarios y su dedicación no esta asegurada. Por tanto es la naturaleza open source de los proyectos la que condiciona la metodología de trabajo,. Cuando trabajas en proyectos donde alguien paga por los desarrollos las estimaciones pasan a ser relevantes y por tanto necesitas una metodología que tenga esto en cuenta.
Vamos que en mi opinión estamos mezclando el tocino con la velocidad.
Creo que no es para nada incompatible. En mi empresa hay proyectos que se terminan liberando o incluso nacen abiertos, con colaboradores y pull requests externas, pero internamente seguimos trabajando como siempre, con algo que llamamos scrum, que en realidad no lo es, pero no está lejos y nos funciona. Y sobra decir que cuando el software en sí mismo es una ventaja competitiva, esa parte de la app o servicio es lógico que siga interno o cerrado. Tenéis el código de Whatsapp? Podéis federar o montar un nodo de Telegram? Y de Wallapop? Del buscador de Google? De Gmail? Es una buena noticia que se liberar código y desarrollarlo de forma abierta es a día de hoy pan nuestro de cada día mientras que hace no mucho era cosa casi de hacktivistas pero no nos engañemos, en mayor parte se comparte código «no core» y obviamente por razones legítimas egoístas: que otros mejoren mi código, atraer talento, publicidad para la marca, fomentar ciertas adopciones…
No se nada de Scrum, jamás lo he utilizado, pero he utilizado un montón de tecnologías de control de desarrollo de software. Todas ellas mostraron poca utilidad en la práctica, desde luego menos que el trabaja adicional de documentación que generan y sobre todo el trabajo adicional que supone mantener actualizada esa documentación.
Me he pasado mi vida profesional poniendo parches a programas o haciendo ampliaciones de programas ya existentes. Afortunadamente casi todos estaban en Cobol y algunos, no todos, bastante bien documentados internamente,, pues la realidad es que la documentación de las aplicaciones, del simple Análisis Funcional y Organico a cualquiera de estas tecnologías mas «perfectas» en la practica, o se ha perdido, o no es accesible, o es accesible pero no fiable. porque no recoge posteriores modificaciones de la aplicación.
El Cobol es viejuno y esta diseñado para trabajar por lotes, no on-line, lo que se ha hecho para poder trabajar asi, es bastante deficiente. No obstante tiene ventajas sobre otros lenguajes posteriores más ágiles de programar, como por ejemplo Ruby on Rails, y es que obliga a una disciplina de trabajo, en un sitio se definen las variables, en otro se abren las bases de datos y ficheros, en otro esta el esqueleto de programa y otro se definen las funciones, que permite trabajar muy bien en equipo y hacer mantenmiento posteriores a personas que no intervinieron en el desarrollo inicial. Mientras que por ejemplo Ruby es un lenguaje muy practico para desarrollar rápidamente de forma independiente, Lo malo es que si hay que trabajar en equipo, se hace mal y retocar posteriormente el programa, o lo hace quien lo programó o te puedes volver loco desentrañando lo que hace a poco que no esté perfectamente documentado el programa, (algo que nunca he visto, a lo sumo esta espartanamente documentado) ..
Enrique
En la IX edición del Programa de Dirección Estratégica de Proyectos del IE que comienza en Febrero en la cual tu eres profesor, incorporaremos este nuevo concepto para nuestros alumnos
Gracias por estar siempre a la última en todo.
http://www.ie.edu/es/execed/programa-direccion-estrategica-proyectos/
¿Cómo Open Development Method, que es un set de buenas prácticas, que ya esta mas que demostrado que solo funcionan en entornos complicados puede sustituir a una marco de trabajo (no metodología) que está diseñada para el desarrollo de software, que es un entorno complejo?
Creo que estás confundido sobre lo que es Scrum, Enrique. Estaría encantado de enviarte información y explicarte en mas detalle en que consiste y para que sirve.
Por supuesto, como Professional Scrum Trainer, puede que mi visión esté sesgada por mis creencias. Aún así, sigo sin entenderlo
Buenos días, me ha sorprendido el título y por eso he leído el post, vamos, que he picado. Interesante, como casi todo lo que escribe Enrique, pero más interesante aún los comentarios que hay escritos hasta ahora.
Este es un enterno debate en el desarrollo de software, no me refiero a la metodología de turno, a la que se intentan apuntar porque sí los que quieren mostrar que van más la última. Hay mucha vanidad y soberbia en nuestra profesión (hablo del mundo IT en general y sobre el desarrollo de software en particular).
Yo repito continuamente este mantra: en software no hay mejores ni peores metodologías, de ningún modo, lo único que hay son PROYECTOS DISTINTOS en los que encajará mejor o peor una u otra forma de trabajar. Y también repito lo siguiente: mejor aplicar una metodología mala, que ninguna.
El eterno debate de que si ésto es mejor que aquéllo es cansino, recurrente, infantil y evidencia falta de experiencia, me temo.
No sólo el tipo de proyecto, sino también la composición e idiosincrasia del equipo que lo va desarrollar y el tipo de cliente final determinan igualmente la mejor metodología a aplicar, pero más importante aún es mantener la disciplina en el día a día en su aplicación. Cualquier metodología es buena y genera beneficios siempre que se siga, claro.
Este tema, como digo, es recurrente y da para mucho. Insisto, sólo cuando has trabajado para muchos proyectos, muchos clientes y con muchos y diversos desarrolladores, sólo así tienes la perspectiva clara de qué metodología encaja mejor (en ocasiones ni te lo planteas porque hay cosas que tienen que estar para antes de ayer).
Por mi experiencia también puedo afirmar una cosa: cuanto más sencillo un método de trabajo, más y mejor se implantará, por eso scrum ha tenido éxito, porque cualquiera en una mañana se puede hacer una idea de cómo dar los primeros pasos, cualquiera, con poco esfuerzo, obtiene resultados positivos. Todavía recuerdo cuando se intentaba usar CMMi para cualquier cosa que se hiciera en una antigua etapa laboral…
Aún no conozco bien Open Development Method aunque estoy seguro que funcionará muy bien para cierto tipo de proyectos, pero de ahí a afirmar que scrum y el agilismo morirán… es en mi opinión bastante exagerado.
Desde el punto de vista del desarrollador hay opiniones (con las cuales estoy en cierto modo alineado) respecto a la efectividad que ha demostrado Scrum a nivel de proyecto pero con un cierto grado de toxicidad a nivel de personas (en este caso desarrolladores).
Realmente, Scrum, no es ni un modelo ni una metodología, sino que se trata de más bien de un framework (marco de trabajo) para la construcción de proyectos.
En este framework hay prácticas muy recomendables, como por ejemplo las reuniones diarias, gracias a las cuales todo el equipo está al tanto del avance del sprint, o la reunión de planificación del sprint en la cual se discute como se lleva a cabo una historia de usuario …
Cuando una empresa hace software propietario aporta algunas ventajas al desarrollo con respecto a las metodologías en cascada más tradicionales.
Por lo que yo estoy viendo últimamente en grandes empresas españolas que tratan de mejorar sus procesos software, me parece más bien que está ocurriendo la tendencia contraria: están diciéndole «hola» a Scrum. Sin embargo, lo difícil de esta metodología no es aprenderla, sino implantarla. Scrum se aprende muy fácil (3 roles, 3 artefactos y 4 ceremonias), pero también se dice que es como «el sexo en los adolescentes: todos dicen que lo hacen pero casi siempre es mentira y los pocos que lo hacen lo hacen mal» ;-). A nivel mundial, es un hecho que las grandes empresas de software usan métodos ágiles (la mayoría Scrum), aquí pueden ver un vídeo de Spotify: https://vimeo.com/85490944
La tendencia que tenemos muchos seres humanos es la de estandarizar, y eso es bueno pero siempre es necesario hacerlo con criterio.
Con esto quiero decir que Scrum es válido en determinados entornos y circunstancias, pero es inviable o directamente dañino. Lo mismo pasa en cualquier otra metodología sobre desarrollo de proyectos.
Llevo muchos años dirigiendo proyectos de software, y, personalmente, uso un criterio propio a la hora de planificar el proyecto. Este criterio puede estar basado en los principios de Scrum o no. Mido objetivos del proyecto, fechas e hitos, equipo implicado (desarrolladores, diseñadores, maquetadores, etc), personalidad del cliente y del responsable del proyecto… Y con esa mezcla activo un protocolo de trabajo, bajo lo que mi jefe denomina como mi «alto sentido común».
¿Qué quiero decir con esto? Que las metodologías de trabajo están bien, son necesarias, pero es importante no convertirlas en un dogma, y menos en tiempos como estos, donde todo es cambiante. Así que Scrum será sustituido algún día por otro procedimiento que pasará a estar de moda, y luego vendrá otro, y otro… Los profesionales del sector nos tenemos que adaptar a los nuevos tiempos (de forma contínua), ¿cómo no lo van a hacer los sistemas de trabajo?
Perdón por la parrafada.
Perdón, en mi anterior comentario he puesto «Con esto quiero decir que Scrum es válido en determinados entornos y circunstancias, pero es inviable o directamente dañino» cuando quería decir «Con esto quiero decir que Scrum es válido en determinados entornos y circunstancias, pero EN OTRAS CIRCUNSTANCIAS es inviable o directamente dañino»
¡No puedo estar más de acuerdo! «Alto sentido común», la mejor metodología, me apunto esa expresión, me encanta.
Pues si bien es cierto que en empresas americanas Agile, Scrum o Scaled Agile Framework andan bastante de moda en los ultimos 4 años. Es mas conveniente una personalizacion o adaptación de Agile, eliminando ciertas cosas y adaptandolo mas a tu área de IT.
RUP anduvo de moda en inicios del 90tas y 2000 , pero ya no. Lo mas risorio es cuando alguien te comenta aqui llevamos waterfall como metodología de desarrollo y nos funciona la perfección.
Agile te da un sentido de mejor comunicación entre los miembros del equipo y del status de como va el proyecto, la comunicación es mínima o inexistente en waterfall..
Open Development Method y temas como Inner Sourcing son más un conjunto de buenas prácticas para el desarrollo de software que una metodología de desarrollo de software en sí mismo. De hecho, no creo que estén tan reñidas con temas como Scrum como para matarlo.
Desde Bitergia llevamos tiempo analizando los procesos de desarrollo de software que se podrían encuadrar en Open Development Method, y hemos visto sitios donde se aplica Scrum u otras metodologías y no está reñido con trabajo abierto.
En nuestro caso, la parte que interesa a nuestros clientes es la transparencia, como herramienta de marketing y como ayuda a la gestión del proyecto.
Y que deberías enseñar en las universidades: Scrum, RUP, Open Development Method y/o cualquier otro para un desarrollo decente de software?
En mi experiencia con Scrum hemos funcionado cuando el equipo de desarrollo éramos como un «grupo de jazz«, pocos componentes, media docena, profesionales, con experiencia, capacidad de innovación y que disfrutábamos tocando juntos.
_
Pero cuando el equipo de desarrollo éramos como una «banda municipal«, con más de 20 miembros, mezclándonos experimentados con novatos, resabiados con ilusionados, de diferentes procedencias y aspiraciones, con Scrum el riesgo de fracaso era alto. Hay sectores como el bancario donde este tipo de equipos subcontratados es habitual.