Segun Steve McConnell las metodologías ágiles se han quedado cortas

Hace poco el gran Steve McConnell autor de algunos de los libros que más han influido en mi carrera profesional, y algunos de los más vendidos sobre desarrollo de software, defendia en una conferencia que las metodologias ágiles se han quedado cortas. Yo no comparto su visión, sino que creo que las personas que han intentado implementar estas metodologías son la que se han quedado cortas.


En cuarquier caso, aquí podeís leer las ideas sobre el tema que tiene Steve.


Por cierto, leed los libros de McConnell si no lo habies hecho, expecialmente Code Complete y Software Project Survival Guide. Si quereís profundizar Rapid Application Development es un copendio de todo los publicado sobre gestión ‘clásica’ de proyectos de software.

15 comentarios sobre “Segun Steve McConnell las metodologías ágiles se han quedado cortas”

  1. Las metodologías agiles son las «no metodologías». Confunden lo agil con lo chapucero. El pensamiento del programador agil es el siguiente: si hoy no estoy haciendo documentos funcionales ni gestion de requisitos ni nada de nada y sigo trabajando en un grupo de desarrollo estupendamente, no es que me falte conocimiento, es que el desarrollo es así por tanto escribo un libro para contar las chapuzas que hago junto a un toque de buen rollito y filing contracultural a lo hippy y le llamo Programación XP. Esta gente lo que hace es continuar enfangando la profesión con la gresca habitual («quién demonios pidio esta pantalla?, no sé, creo que fulanito. Fulanito dice que no fue el, etc, etc, etc») y dan la imagen a terceros de falta de seriedad y de que todo informatico es un hacker que hace las cosas al tun-tun.

  2. Esponjita, hablas desde la más completa ignoracia. Tu postura está superada hace siglos, es un ataque muy antiguo contra las metodologías ágiles.

    Los equipos ágiles no ignoarmos el análisis, la estimación, la planificación, la gestión de requisitos u otros aspectos del desarollo del software, simplemente los realizamos de otra manera. Y sobre todo nunca en cascada.

    A un equipo ágil no se le cuela una pantalla que no sabe por qué está ahí nunca. La colaboración continua con el cliente, la revisión entre pares contínua y las revisiones al final de las iteraciones lo impiden. Si supieses algo sobre metodologías ágiles y no solo contases con los típicos prejucios de quien las desconoce lo sabrías.

    La imagen de seriedad se consigue entregando a los clientes software que funciona de manera continua, software que aporta valor, no documentación sobre lo que vamos a hacer y sobre lo bien que hemos planeado el proyecto.

    A ver si espabilamos Esponjita, gente que piensa como tu lleva gestionando proyectos fallidos durante mucho tiempo. Se está produciendo un cambio importante en la gestión de proyectos y muchos se van a quedar fuera.

    Gracias por tu comentario!!!

  3. Todavía no entiendo porqué la gente que cantais glorias sobre la programación XP seguís reiterándoos una y otra vez en lo mismo. Mi comentario no es un ataque antiguo, es «el ataque». Es decir, sois como chiquillos que decís, no me vuelvas a decir lo mismo papá, pasa del rollo, no seas antiguo, que con la minifalda no paso frio en noruega… Querido Rodrigo, piensa en lo siguiente: si con las metodologias agiles haces lo que dices que haces, ya no es ágil. ¿Como quereis que os lo digan? si os poneis los pantalones no vais con minifalda y viceversa. Es tan difícil de entender para vosotros?. Por cierto, no veo por qué relacionas el ciclo de vida software (en cascada o lo que quieras) con la metodología, curioso, curioso…

  4. Ya puestos, por qué no gastas un millón de euros en un chalet del que no te han enseñado los planos, ni la memoria de calidades, ni una infografía, etc. A lo mejor con el buen rollito, el constructor con la frasecita de «La imagen de seriedad se consigue entregando a los clientes un chalet que funciona de manera continua, no con los planos!» consiguen que sueltes la pasta y vayas viendo las cosas según se construye, para darle más emoción al asunto, que se ve que os gusta… Por cierto, el cambio es tan revolucionario que no acaba de cuajar, tales son sus ventajas… curioso también… si es que debe haber más viejos de los que te piensas.

  5. Esponjita te voy a dar dos consejos:
    1) Enteraté de que construir software no es construir chalets
    http://geeks.ms/blogs/rcorral/archive/2008/04/06/la-falacia-de-la-industrializaci-243-n-del-desarrollo-de-software.aspx

    2) Aprende algo sobre metodologías ágiles y gestión de proyectos en general, así podrás criticarlas con criterio, como el amigo Steve.
    http://geeks.ms/blogs/rcorral/archive/tags/Gesti_26002300_243_3B00_n+de+proyectos/default.aspx

    Si he sonado prepotente y cabreado en este comentario, es por que lo pretendía… ya vale de gente que opina desde el más absoluto desconocimiento.

    Agredezco tu comentario en cualquier caso.

    Un saludo.

  6. Esponjita, si no entiende por que el ciclo de vida tiene que ver con la metodología es que no tienes la más remota idea de que es una metodología… y por lo tanto entiendo lo absurdo de tus comentarios.

    Un saludo!

  7. Todo el mundo sabe ya que programar no es hacer coches, pero aún así no es algo tan aleatorio como pintar un óleo y es bastante automatizable. Si tienes alguna duda, tienes un método muy fácil para comprobarlo: trata de calcular ciertas estadísticas dentro de un proyecto como LOC, tiempo de desarrollo de cada módulo, numero de informes, coste final del proyecto, etc, luego, si no te da miedo, introdúcelas en el Statgraphics y halla la correlación de las variables. Puede que te sorprendas.Imagino que, con tu opinión, tendrás serios problemas para trabajar dentro de un marco tipo CMMi. Tanta investigación y esfuerzo, para que llegue un tal Kent Beck y con un librito de 100 hojas de buen rollito nos haga ver la luz a todos sus joyas de la metodología del estilo «yo donde no hay una máquina de comida no me gusta y por tanto no quiero trabajar ahí». No se que opinas tú de uno de los gurús de las «Metodologías Ágiles». A lo mejor, por escribir en inglés, le das más crédito.

  8. Esponjita, si a estas alturas de la pelicula me vienes hablando de métricas y lo que te viene a la cabeza son LOC está todo dicho. Deberías actualizar un poco tus conocimientos de gestión de proyectos y descubrir que la ingeniería del software ha evolucionado mucho en los últimos 20 años…

    Respecto a un marco CMMi… mejor ni hablamos… no me sirve. Es en el 99% de los casos un simple sello. Una vez conseguido a base de dilapidar recursos caen en las mismas prácticas que destrozan los equipos y la productividad… los siento CMMi es un marco que se ha quedado obsoleto, desfasado, que no sirve en un mundo que se mueve tan rápido…

    Sobre la investigación… hay tanta detrás de las metodologías ágiles como detrás de CMMi, solo que la de CMMi se hizo desde un despacho, en una universidad, por gente que en su vida había completado un proyecto fuera del marco academico, en el mundo real. CMMi lo diseñaron personas que pretendieron decir como, en teoria, debe hacerse software… olvidando que no conocian lo que era hacer software, gente que en su vida pico una sola línea de código. Las metodologías ágiles nacen del día a día, de la investigación empírica, de observar como funciona el mundo… nacen de gente que no solo aporta metodologías sino patrones, herramientas, nuevas técnicas…

    Deberías ver la diferencia… el resultado final las metologías ágiles ayudan, CMMi molesta.

    Si quieres datos: http://geeks.ms/blogs/rcorral/archive/2008/08/25/tercera-encuesta-de-versionone-sobre-el-estado-de-desarrollo-225-gil.aspx

    Muestrame estadísticas similares sobre CMMi…

  9. Tengo que decir, en primer lugar, que el informe que me indicas es interesado y por tanto sesgado, es decir, elaborado por una empresa que se dedica a las metodologías Ágiles y consulta únicamente cosas sobre dichas metodologías, no ofrece una visión global, por tanto no es de extrañar que los resultados les den redondos. Deberías abrir tu mente y mirar las cosas de una forma más imparcial (a no ser que tu empresa venda metodologías Ágiles con lo que entiendo tu interés sobre el tema).
    Para que puedas empezar a pensar en ello observa una comparativa (podía ser cualquier otra), de la Universidad de California, entre CMMi vs Metodologías Ágiles, realizada conjuntamente por personal de (NASA, Xerox, USC, Aerospace Corporation, etc) que llega a la conclusión de que con ambos marcos se pueden realizar proyectos fallidos, indicando que la gente que vende ambas metodologias son CMMs (Consultant Money Makers). O sea, que dejémonos de tonterías.
    En segundo lugar, no hay nada en las metodologías Ágiles que no encaje en CMMi, si bien CMMi incluye muchas más prácticas y procesos que las Metodologías Ágiles.
    En tercer lugar, no está claro qué son las Metodologías Ágiles por mucho que insistais los que decís apoyarlas: revisiones en parejas?, trabajar en una misma sala?, trabajar en contacto con el cliente?, desarrollo iterativo?,…, que yo sepa, eso lo hacemos todas las empresas y dentro de un marco de trabajo más sólido como es CMMi, y sin ningún problema. Como te decía, que el desarrollo sea iterativo no tiene que ver con que la metodología sea Ágil o no, nosotros realizamos desarrollos iterativos generalmente, y cuando el proyecto es muy sencillo, en cascada. No veo donde veis los problemas. On empeñais en asociar metodologías «antiguas» con desarrollo en cascada. Estais obsoletos y/o obcecados.
    Por último, decirte que tus previsiones de la gran revolución van camino de No-cumplirse, porque para vuestra desgracia todas las iniciativas en el ámbito de las metodologías en el panorama nacional se están alejando de vosotros. O sea, que los distintos clusters TIC de las comunidades están en proceso, si no ya finalizado, de certificar sus grupos y proyectos en CMMI / ISO 15504/ ISO 12207.
    Parece que, o reflexionais sobre vuestra cruzada partidista, o os vais a quedar fuera. Yo por mi parte considero útil intentar que los proyectos SW sean predecibles y repetibles (aunque me encanta la dosis de creatividad que existe en esta profesión), menos estrés para todos, menos problemas para todos… 🙂

  10. Otro documento que puede ser de tu interés, realizado por Borland, la mítica compañía del Turbo Pascal y Turbo C, y que se titula «10 Common Misconceptions about CMMI»:

    http://www.improveit.fi/docs/10Misconceptions.pdf

    Presta especial atención al «Misconception 7: CMMI is not suitable for companies using Agile methods».
    Cientos de informes y documentos similares puedes encontrarlos en la red, de múltiples compañías donde se dan cifras como las que aparecen al final de este documento sobre ROI, etc.
    Como apunte final, decir que mis conocimientos de los Métodos Ágiles se basan en artículos en revistas especializadas y en el libro de «Programación XP» de kent Beck, que he leído y resumido para buscar ideas interesantes. Y sí que tiene ideas sueltas e interesantes, pero la metodología XP en sí, es difusa, vaga, con muchas lagunas y agujeros negros, y abierta a todo tipo de interpretaciones. Las ideas que aportan son fruto de su experiencia y útiles, pero nada que cualquier otro consultor no pueda conocer después de varios años de trabajo en este negocio (muchas de ellas presentes en otras metodologías).

  11. Esponjita, te cito: «En segundo lugar, no hay nada en las metodologías Ágiles que no encaje en CMMi, si bien CMMi incluye muchas más prácticas y procesos que las Metodologías Ágiles.»

    Es curioso como la gente que defiende CMMi, ataca las metodólogías ágiles para luego decir que tienen cabida en CMMi…

    Otro tema que me llama la atención es que no veaís que el problema es, precisamente, que CMMi es demasiado para el 95% de proyectos… y sin embargo para tener ‘la certificación’ hay que cubrir todas la areas sean de interes o no. Eso genera un nivle de burocracia que aniquila de raiz cualquier mejora de competitividad que la metodología en sí pueda introducir.

    Evidentemente XP o Scrum no tratan de dar la ‘gran solución’ sino de introducir un marco en el que los equipos, de manera autoorganizada, sin imposición de burocracia y en base a sus necesidades reales, encuentren una manera productiva y organizada de trabajar.

    No todos los proyectos necesitan la misma medicina de madurez.

    El informe que cite, solo hace mención a metodologías ágiles, pero eso no invalida mi punto. Mira el nivel de mejora y satisfación que los encuestados ponen de manifiesto… Sin embargo cuando hablamos de CMMi no encuentro el mismo nivel de satisfación beba en la fuente que beba.

    Claro que hay documentos de casos de exito… si has pagado millones por implantar CMMi nadie va a decir que es una cagada… enseñame datos anánimos… basados en encuestas…

    Mi experiencia de años es que la gente dice una cosa en publico sobre CMMi, y otra en privado, una cosa es el mensaje oficial… y otra cosa es lo que los equipos que sufren CMMi opinan.

    Hay otra diferencia notable. No hay un negocio oficial establecido entorno a las metodologías ágiles, nadie te exige ni te vende certificaciones… ni te pone un sello como mayor valor añadido de la certificación… ni necesitas obligatoriamente carísimos consultores que te vendan humo…

  12. Los equipos de desarrollo que se quejan de CMMi, normalmente, es debido a que no ha sido correctamente implantado en su empresa.
    Mira, con una ISO 9001, todas las empresas se afanan 3 meses antes de la auditoría en arreglar los desaguisados de no haber seguido el proceso definido, pero como dicha norma constituye un marco muy laxo, es fácil para las empresas elaborar el montaje que engañe al auditor (especialmente si se le invita a una buena comida…).
    CMMi falla en muchas organizaciones porque realmente no hay un interés real en implantarlo. En este pais, las certificaciones se cosideran un mero asunto económico dado que los auditores son muy sobornables. Tienes que hacer una gran cagada para que te pongan una no conformidad grave. Con la certificación puedes vender mejor la moto y presentarte a los concursos que la requieran. Desde la gerencia «cutre» de las empresas de este pais se piensa que poniendo a un becario o a un conjunto de personas mal pagadas a trabajar en «optimizar» el proceso de la empresa ya se soluciona el asunto de obtener el sello, total la calidad es algo secundario…
    Como resultado se obtiene una metodología que realmente es un pastiche que no «optimiza» para nada el proceso que ya había antes. Esto es lo que verdaderamente captan las encuestas de satisfacción: la mentalidad cutre y salchichera del empresario español, y su cutre y barriobajera visión del I+D+i, siempre buscando el engaño, el ahorro máximo, el trapicheo…
    El espíritu de CMMi no es eso, por ello realmente no es una certificación de empresas, simplemente es una afirmación de que un día se hizo una evaluación de procesos y se encontró que en el proyecto X y con el grupo de personas Y, las cosas parecían funcionar como la seda. Si luego todo ello fue fruto de un montaje para engañar al auditor o un soborno en toda regla, es cosa de la empresa…
    Normalmente es difícil hacer un montaje para CMMi que sea fácil de colar (al contrario que con las ISO), porque la norma es mucho más específica. Pero al final, con lo que hay que quedarse es que el problema no son CMMi, o ISO 9001, o lo que sea, sino la intención que subyace de engañar o hacerlo bien.
    Una empresa que trapichee con CMMi harán proyectos tan horrorosos como un grupo que utilice «Metodologías Ágiles» tal y como interpreté en mi primer post. La diferencia es que por lo menos, los que conocen CMMi, saben más claramente qué cosas deberían haber hecho bien para que el proyecto tuviera éxito.

Responder a rcorral Cancelar respuesta

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