Ayer iba a «postear» el resultado de la última encuesta, la de la semana pasada, qué framework ágil usas, y se me complicó al máximo la temprana mañana, entre que tenía que ir corriendo a dar una charla al CSTIC de la AEC, y que antes de salir me enteré de la huelga de Taxis, que pensé que no llegaba… ahhh. Bueno, eso fue ayer, hoy, aquí van los resultados.
Encuestas previas en el blog:
- Resultados encuesta: ¿Se enseña (te enseñaron) agilidad en la Universidad?
- Resultados de la encuesta “qué nos motiva”
- Resultados de la encuesta herramientas software marzo 2015
- Resultados de la encuesta herramientas software diciembre 2013
- Resultados de la encuesta sobre el Test Garzás
- Resultados encuesta sobre equipos de desarrollo de software
Ya te avisaba que esta era una encuesta complicada, por la respuesta a las preguntas, y su planteamiento. Te recuerdo que la idea es sacar una idea de qué “frameworks” ágiles usamos. Y aquí está lo que habéis opinado los 212 que habéis contestado:
Son solo unos resultados y cada uno puede sacar las interpretaciones que quiera. Yo me he hecho las siguientes ideas…
– Creo que todo framework que tiene menos de un 5% de respuestas no es significativo, quiero decir, que es como si casi nadie lo usara.
– Según lo anterior, la representación mayoritaria es, en orden, Scrum, Kanban, TD, Clean Code, DevOps, XP, BDD y Management 3.0
– El resto, tampoco es cuestión de enumerar cada uno, curiosamente, apenas se usan (según esta nuestra humilde encuesta).
– Y de los anteriores, me han llamado la atención la prácticamente ausencia en los datos de marcos, más discutibles o no, de escalado, especialmente SAFe.
Cualquier opinión o conclusión que a mí se me haya pasado es bienvenida, te dejo abiertos los comentarios.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
Javier, una pregunta, ¿Qué es Clean Code como «framework» ágil? Para mi practicar clean code es algo a poner en práctica a la hora de programar, uses o no agilidad.
Sí, puede verse así, como si que se suele asociar con agilidad, por eso lo añadí
Hola Javier, hace mucho sigo tu blog y si bien es la primera vez que comento, no quería dejar pasar la oportunidad de saludarte y agradecerte desde Argentina.
Respecto a los resultados, en una primera mirada, me llamó la atención entre la desproporción en el uso de Scrum o Kanban y lo que aparece como Management 3.0″ . En lo personal, uso Scrum en un equipo y Kanban en otro y ambos frameworks no puedo pensarlo a disociados de las prácticas de Management 3.0. Solo esa pequeña observación. Es cierto que en mi caso utilizó agilidad y lean en tareas no vinculadas al desarrollo de software (sino en el área de «Rrhh» y quizá de ahí venga mi distorsión, pero bueno, eso me llamó la atención de los resultados.
Saludos
Hola Javier, interesantes los resultados. Con esto me pregunto. Estamos intentando dividir temas que no son excluyentes?
Por ejemplo,
Un equipo trabaja en Scrum y el manager de ese equipo (Sea un Project manager, jefe o cómo sea que su estructura lo llame) puede gestionar con Management 3.0, igual es Scrum master puede utilizar esas ptrácticas. El equipo que tiene que desarrollar software puede usar prácticas de eXtreme programming y escribir su código con clean code. Puede escribir los casos de prueba primero usando BDD y TDD para facilitar su cultura Devops. Si su producto es muy grande puede escalar todo lo anterior usando un framewrok como Safe o Less y finalmente si tienen luego que gestionar su proceso (Por ejemplo, atender casos en producción) usarán Kanban
Ojo, que se podía seleccionar varias opciones, no eran excluyentes