Tengo un plan: ser ágil

La columna que viene escribiendo Antonio Quirós en la indispensable revista dotNetmania, me viene sirviendo ya desde hace unos meses como excelente escusa para enfrentar la visión clásica y guiada por un plan con la visión ágil de la gestión de proyectos de desarrollo de software. Ya he ‘enfrentado’ estas dos visiones en anteriores entradas de este blog, cuya lectura recomiendo antes de abordar la lectura de este post: ¿Nos podemos caer de maduros?  y Métricas mal entendidas .


Siguiendo con la tradición, voy a tocar el tema de la planificación que Antonio Quirós comentaba en el número de Diciembre de dotNetmania, desde un punto de vista ágil.

No seré yo quien menosprecie el valor de la planificación. A menudo se acusa a las metodologías ágiles, sin fundamento, de adolecer de una ausencia de planificación. Las metodologías ágiles no carecen de planificación, simplemente la abordan de una manera diferente, centrando en lo cercano, evitando caer en la adivinación.

En su artículo Antonio Quirós dice: “Con la planificación el proyecto no está hecho, pero sí tenemos una imagen que se pretende fiel de cómo irán sucediendo las cosas hasta que el proyecto se complete”. Ojalá fuese así, nuestro trabajo sería mucho más simple (y mucho más aburrido dicho sea de paso), pero pensad en los proyectos en los que habéis participado… ¿En alguno de ellos la planificación a sido una “imagen fiel” de algo?.

El plan perfecto es un mito. Un mito atractivo pero un mito al fin y al cabo. De verdad alguien con experiencia en el desarrollo de software puede creer que será capaz de conocer todas las tareas y hitos, dependencias entre estos, los recursos con los que contará, los requisitos del cliente, y además ser capaz de estimar con una precisión suficiente como para poder tratar las estimaciones como certezas… La base de la dificultad para trazar un plan perfecto se encuentra en imposibilidad de establecer un entorno predecible en el que desarrollar el proyecto: La tecnología cambia, los miembros del equipo cambian, los requisitos cambian, la legislación cambia, el negocio cambia todo cambia… esa es la única certeza con la que contamos… Todos sabemos lo que cuesta trazar un plan de proyecto clásico, horas de reuniones, estimaciones, etc… En un entorno tan cambiante no estamos trazando planes, estamos haciendo predicciones, no nos engañemos. Y cuanto más extenso sea nuestro plan, más predicciones estamos haciendo y más nos vamos a equivocar. De todos modos Rappel se equivoca cada año y sigue viviendo de eso… ¿Qué sentido tiene centrarse en seguir un plan que con seguridad se verá sobrepasado por los acontecimientos al cuarto de hora de ser desarrollado?. Si no contamos con un plan perfecto, ¿sigue teneniendo sentido centrar toda la gestión de nuestro proyecto en seguir un plan?. Puede ser, que desde el punto de vista económico, mantener esta falacia tenga sentido, pero ¿Qué es lo que buscamos como empresa?, ¿cual es nuestra primera prioridad?Asegurarnos un margen a toda costa en nuestros proyectos o lograr que nuestros clientes logren valor  y por tanto esten ‘encantados’ de pagarnos. Yo tengo claro por cúal me inclino. Ya escribí anteriormente sobre este tema.

¿Significa esto que desde las metodologías ágiles se propugna que no debamos trazar planes? NO!. Simplemente se nos recuerda que nuestro principal plan debe ser ser ágiles.  Estar preparados para los cambios que con seguridad ocurrirán a lo largo del proyecto. Sobre esto me encanta una cita de Eisenhower: “Durante una batalla los planes siempre son inútiles, pero la planificación es indispensable”. Debemos centrarnos en realizar una planificación adaptativa en lugar de una planificación predictiva. La planificación adaptativa consiste en realizar una planificación de alto nivel, y refinarla solo para el futuro inmediato, para el trabajo que vamos a abordar de inmediato. El futuro cercano es mucho más fácil de predecir con precisión y mucho más útil. Este enfoque nos permite además contar con la información sobre como fueron nuestros anteriores planes a la hora de planear la siguiente iteración o sprint. Este enfoque es el que proponen las metodologías más en auge hoy en día: Scrum y MSF Agile. 

En Scrum, contamos con el Product Backlog como referencia que guía el desarrollo a largo medio plazo, y solo refinamos las estimaciones para los elementos seleccionados durante el Sprint Planning Meeting para ser abordados durante el próximo Sprint. En MSF Agile, es planteamiento es similar, contamos con un plan entrega y un plan de iteraciones, que desgrana que escenarios abordaremos en cada iteración, pero solo durante la planificación detallada de la iteración ser realiza un desglose detallado en tareas. Ambas metodologías reconocen que es un esfuerzo inutil el tratar de desarrollar una planificación detallada a priori.

Asumir la utilidad del enfoque adaptativo en la planificación tambien exige distinguir entre planificación y estimación. No es necesario desentrañar hasta la última tarea para hacer una estimación, siempre que seamos capaces de tratar las estimaciones como estimaciones y no como compromisos.

Para la planificación a medio-largo plazo es mucho más útil centrarse en realizar planes de entrega en lugar de planificaciones detallas. La idea de los planes de entrega es trazar una planificación de en qué orden se entregará la funcionalidad del sistema que se está desarrollando, centrándose en seleccionar la funcionalidad de mayor valor desde el punto de vista del negocio para las primeras entregas. ¿De qué sirve realizar el esfuerzo de planificar en detalle y dividir en tareas un trabajo que realizaremos dentro de seis meses? Mientras trazamos un plan detallado estamos privando a nuestro cliente de la posibilidad de ver software que funciona, que puede usar para descubrir sus necesidades o del que pueda comenzar a disfrutar para mejorar su negocio. ¿Cuántos proyectos conocéis que se han pasado meses en fases de planificación?.

Permitidme que de una nota de humor a este post con una viñeta de Dilbert, esclarecedora, sobre el tema que tratamos hoy. Especialmente interesante es el juego de leer la viñeta dos o tres veces seguidas, para ver como su caracter iterativo hace que el problema que plantea sea especialmente grave.


¡Espero vuestros comentarios y experiencias sobre este tema!

22 comentarios sobre “Tengo un plan: ser ágil”

  1. Hola Rodrigo

    Muy buena exposición pero me surgen ciertas dudas.

    Imaginemos que un cliente nos solicita que le hagamos una valoración del desarrollo de una solución que en principio se preveé que tenga una duración de más de 10 meses. Dicha valoración debería de contener tanto la parte económica como el tiempo que tardaría en desarrollarse. El cliente no nos conoce y quería contar con dicha valoración antes de comenzar a trabajar con nosotros.

    Según tu experiencia ¿que le entregaríamos, si no es un planning con perfiles y tiempos?.

    Recordemos que el cliente no nos conoce no puede arriesgarse a que realicemos una primera entrega que posteriormente no le satisfaga o no cumpla la perspectivas esperadas (si, podríamos decir, “realizaríamos un seguimiento exhaustivo”) pero el cliente quiere ver un global ¿cuanto me costara esta solución con vosotros?. Asemejándolo con una reforma por poner un símil, ¿podríamos plantear la reforma de una cocina al cliente?, le pondremos el fregadero y si queda satisfecho continuamos. El cliente espera un plan completo no puede arriesgarse.

    Lo dicho el tema es mas que interesante espero que podamos seguir comentándolo.

    Un Saludo.

  2. Aupa Jose Luis!!!

    Sabía que este tema iba a surgir. Evidentemente, la metodologías ágiles no son de universal aplicación. Ninguna metodología lo es.

    Una precondición imprescindible para poder usar una aproximación ágil es centrarse en construir una relación de confianza entre las partes, no en negociar ferreos contratos con el afán de protegernos unos de otros.

    Este es un tema muy interesante que merece ser tratado con más profundidad que un simple comentario. En los próximos días escribiré sobre este tema y como se aborda desde las metodologías agiles.

    De todos modos el problema que planteas es de estimación, no de planificación. El cliente necesita que tu estimes cuanto vas a tardar y cuanto va a costar. Para realizar esto no es necesario realizar una planificación detallada a priori, ni siquiera es necesario entrar con absoluto detalle en cada requisitos. Solo es necesario tener una lista de requisitos y, idealmente, datos historicos sobre como se comporto nuestra empresa en desarrollo similares. No existe relación alguna entre contar con un plan detallado y realizar mejores estimaciones.

    El simil de la cocina no me vale. Ni ningún simil relacionado con la construcción. En las cocinas puedes ver una exposición y descubrir tus necesidades. En construcción las necesidades son siempre similares: las casas deben ser habitables, los puentes unir dos orillas… en software es diferente. Cada proyecto que se desarrollo cubre necesidades diferentes, nuevas y que, a menudo, solo se descubren a lo largo del desarrollo. Si existe un software que cubre nuestras necesidades mejor comprarlo que desarrollar un nuevo.

    Que la industria del software lleve muchos años haciendo creer a sus clientes que puede saber a priori cuanto cuesta un desarrollo no quiere decir que sea cierto. Sino mira lo que ocurre en la gran mayoría de los proyectos: el cliente insatisfecho tiene que quedarse con lo que la empresa de desarrolo hizo, le guste o no, tras una fuerte fase de tiras y aflojas, simplemente porque ‘se acabo el presupuesto’.

  3. Lo cierto es que es la mar de interesante todo esto. Espero que compartan sus impresiones todos los que puedan porque es un tema que como muy bien dicen José Luis y Rodrigo, es interesantísimo.

    Leo atentamente los comentarios de José Luis y Rodrigo y a la vez medito y en voz alta (escrito aquí) lo siguiente:

    Muchos clientes, quieren «entregables» para ir viendo como va el proyecto (por falta de confianza, por que no nos conocen, porque tienen esa forma de trabajar, porque quieren saber como se están haciendo las cosas y controlar todo, etc).

    En la oferta económica, muchas empresas detallan el coste y el porqué de esos costes, proponiendo los entregables en un plan general en el que se detalla además la fecha final de entrega de acuerdo a unas métricas (odio personalmente las métricas estrictas que en muchas ocasiones generan tensiones inadecuadas en un proyecto, adios a la creatividad).

    Luego, se pide el detalle del planning del proyecto (Project por ejemplo), con las tareas, el entregable de cada una de las tareas indicadas, su fecha, personas o recursos como dicen los «mal hablados», y eso se asocia con el coste. Es decir, se comprime todo.

    De esos entregables, diré a modo de ejemplo que imaginemos que mantenemos varias reuniones con el cliente para la toma de requisitos. Si la planificación del proyecto es completa desde antes de la primera reunión (el comercial de turno puede meter la pata y haber vendido «la moto»), nadie nos asegura que trás la primera reunión, no haya surgido una nueva reunión que hace que el planning se desplace, y que por lo tanto, los tiempos predispuestos no se cumplan ya desde el principio.

    YA se que para que te den a veces un proyecto, la oferta debe ajustarse porque estamos en un mundo de competencia voraz, el planning se comprime y los tiempos se hacen irrealizables, aunque no haya más remedio. Y lo peor es que lo sabemos y en muchas empresas se da aún y así con el látigo.
    Vamos, que la planificación que se hace en muchos proyectos, nace en mi opinión viciada en la irrealidad más absoluta desde el comienzo. No ocurre en todos los proyectos, pero sí generalmente en los que están basados en tiempos y no en calidad… y el que diga que se puede dar calidad ajustándola al tiempo, creo en mi modesta opinión que no está en la realidad y sí en Matrix.

    Lo que sí he visto en otras ocasiones, es que si las fechas se van del planning (que ocurre en el 99,9% de los proyectos claro), es que el cliente mirando la planificación inicial que tenemos muy bien detallada, los entregables y sus fechas, etc, comienza a ponerse nervioso pensando en que los costes derivados de la demora de tiempos caerán a su patio, además no se cumplen las espectativas iniciales vendidas en forma de planning rígido y el proyecto entra en una espiral de tensión que genera siempre unas consecuencias en forma de problemas.

    La gestión de proyectos informáticos, es sin lugar a dudas complicadísima. Nadie dijo que fuera fácil lo se. La búsqueda de la idoneidad en abordar un proyecto también es dificilísima, pero creo que hay planificaciones que son contraproducentes y otras que no tanto, y las que tratan de ajustar todo al milímetro creo que lo son, porque siempre hay factores incontrolables (alguien que se pone enfermo por ejemplo o alguien que se va de la empresa cliente o de la que da el servicio), que provocan que un proyecto planificado no se cumpla en tiempos.

    La planificación no muestra una imagen fiel de cómo irán sucediendo las cosas, algo que comenta Antonio Quirós (ex-jefe mío por cierto), muestra una imagen de como quieres que sucedan las cosas que es muy diferente.

    Yo siempre digo algo cuando se aborda este tema o similar, hay que ser proactivo en lugar de reactivo, y tanto en la proactividad como en la reactividad, es necesaria la misma cosa, un cambio. Y ese cambio debe ser ágil y consecuente… no basta con meter un hito en una planificación y correr la planificación de fecha. Lo siento pero no. La planificación estricta tampoco ayuda. Meter cosas con calzador para no pasarnos de tiempos es un error. Si un proyecto se va de tiempo por la razón «x», el hablarlo con el cliente, exponerlo y ver sus soluciones es más acertado en mi opinión que el meter con cuña esa funcionalidad en el planning… es un conjunto de opiniones nada más. 🙂

  4. En mi opinión la historia es el mejor argumento. Es decir. Un cliente típico ya ha «sufrido» potencialmente varios proyectos. Cosas que tenían en común:

    – La consultora de marras le muestra la estimación, le dice lo buenos que son mostrándole otros casos de éxito, o su certificación CMMI.

    – El cliente asume que estas estimaciones son garantías de algo.

    – El proyecto arranca y se van realizando toneladas de documentación, planificaciones en project, etc…

    – El equipo de desarrollo va descubriendo lagunas mayores o menores en los requisitos. En algunos casos, asumen cosas. En otros, buscan feedback. En algunos casos, este feedback muestra que los requisitos son incompletos / desviados de la realidad. Aquí la técnica utilizada puede variar. Me he encontrado con consultoras que se acogen a la quinta enmienda (lo que el cliente firmó es lo que va a misa). Y complentan en tiempo algo que le es inútil al cliente, generando insatisfacción en el cliente. Otras consultoras prefieren que el tiempo se vaya al cuerno pero al menos entregar algo que sea una fracción de lo que prometieron, generando también insatisfacción en el cliente. Y en otros casos (que también he visto), las consultoras pretenden que el equipo de desarrollo termine en el tiempo especificado lo que el cliente realmente necesita a golpe de horas extras (aquí sería muy útil una slide de esclavos en galeras), generando insatisfacción en el cliente y en el equipo.

    Moraleja: Lo mires como lo mires, acabas teniendo insatisfacción por parte del cliente. Y en algunos casos, también en el equipo de desarrollo.

    Si el cliente se siente identificado con esta historia, se le puede explicar que, en efecto, con las metodologías ágiles no se pretende el poder predecir todas las variables (scope, tiempo, calidad). Pero en realidad, si miramos más arriba, si tenemos memoria, descubriremos que las otras consultoras que han venido nos han engañado como a chinos, y tampoco nos han dado lo que queríamos, ni en el tiempo que prometían ni con los costes que esperábamos.

    Es decir: Una vez que nos damos cuenta de que con la aproximación tradicional aquello falla 4 veces de cada 5, igual el cliente empieza a ser más propenso a explorar otras vías.

    Eso espero.

  5. > ¿ Cúántas veces le han prometido el oro y el moro a un cliente?
    > ¿ cuántas veces le han tomado el pelo?
    > ¿ cuántas empresas hay que desarrollan buen software?
    > ¿ cuántas empresas han fracasado o entregado verdaderas chapuzas?
    > ¿ cuántas malas experiencias es capaz de soportar un cliente ?

    Es normal que con tantas experiencias malas se quiera «más control» …sobre todo si empiezas a trabajar con una empresa nueva. ¿ Cómo se asegura el cliente que esta vez va a ser todo diferente?

    Ya sé que la mentalidad tiene que cambiar y que el cliente tiene que entender, tiene que hacer…tiene….pero el cliente también desconfía con razón, porque constantemente se le ha engañado. Por eso veo muy complicado el cambiar la mentalidad. Eso sí, otra cosa es que te conozca, que sepa que trabajas bien y que se pueda fiar de lo que le dices.

    Por lo demás, el cliente necesita más una estimación que una planificación detallada. Es importante tener una estimación para poder valorar los costes que podrá tener el desarrollo de la aplicación y el tiempo que llevará.

    Un saludo,

  6. La cuestión no es asegurar nada al cliente. La cuestión es establecer una relación de confianza y colaboración que permita abordar los proyectos de una manera diferente.

    Es absurdo esperar diferentes resultados si seguimos actuando de la misma manera. Sobre todo si esta manera de actuar, además, contradice la experiencia y el sentido común. Y lo que es evidente que hasta ahora los proyectos de desarrollo no optienen excelentes resultados.

    Es como las charlas o cursos de CMMI, que siempre empiezan con la misma diapositiva: «Un estudio de XXXX dice que el 60/70/80% de los proyectos de desarrollo fallan». CMMI, paradigma de la gestión clásica de proyectos, ya tiene unos cuantos años, ¿qué ha hecho CMMI por cambiar la situación? NADA. ¿Cuantas ediciones del PMBOK llevamos? Y en que ha cambiado la situación, en NADA.

    No seré yo quien persevere en el error. Las metodologías ágiles no tienen un record de exitos apabullante, pero no tienen un historia espectacular de fracasos, clientes descontentos y equipos quemados. Ni parece que la vayan a tener.

  7. También hay muchas empresas con certificaciones varias, ISO 9001, etc. Y claro, este tipo de certificaciones es para muchos básico o fundamental (en fin…), pero en muchas otras ocasiones, muestra esa aparente calidad que les da a los clientes esa tranquilidad y seguridad que no tenían antes (marketing vamos),… y luego llegan los disgustos porque no deja de ser un papel y la realidad queda disfrazada. Con un papel sólo no haces un entregable en condiciones y según las condiciones pactadas inicialmente.

    La relación de confianza y colaboración es el camino del éxito como bien dice Rodrigo,… en otras palabras, hacer equipo. 🙂

  8. Coritel y CMMI..Aquí cuál es el error? Echamos la culpa a la metodoloía o a la empresa? En la mayoría de los casos dónde está el problema? Para mí generalmente en la empresa, no en la metodología. Otra cosa es que haya mejores o peores metologías.

    Rodrigo dice..»La cuestión es establecer una relación de confianza y colaboración que permita abordar los proyectos de una manera diferente.»

    Con esto totalmente de acuerdo…Sólo digo que cuando a uno le han engañado tantas veces es difícil hacerle ver que tiene que seguir confiando, sobre todo, si no te conoce.

  9. No estoy seguro de cómo se obtiene el CMMI, pero sospecho que es bastante similar a las certificaciones de calidad que conozco. Voy a establecer un símil:

    Cuando una persona se pretende presentar a unos exámenes de certificación de Microsoft (o exámenes de universidad, o de casi cualquier cosa. Simplemente que los de Microsoft me los conozco bien), tiene varias opciones. Una de ellas coincide con el propósito del propio examen: Evaluar la pericia de una persona en una determinada materia (luego podríamos hablar sobre si un examen mide o no esta pericia). Es decir, te lo curras, aprendes de que va el tema, y eventualmente apruebas el examen. Simplemente, porque sabes del tema. Pero es que luego alguien se inventó los TestKing (y similares). Y entonces dices: ¿Para qué cojones me tengo que empollar todo el temario? Me miro examenes con preguntas reales hasta que me he visto todas las posibles preguntas. Y apruebas. Ambas personas (el que se lo sabe, y el del Testking) tienen el examen aprobado. Sin embargo, el propósito del examen (demostrar quién vale y quién no) ha sido burlado. Y el sentido ha quedado pervertido.

    Del mismo modo, cuando una empresa se plantea enfrentarse a un proceso de certificación, puede hacerlo con una intención de normalizar y mejorar sus procesos. O puede hacerlo sólamente para ponerse una medallita y para ir a sus clientes diciendo: Tengo el CMMI 5. En definitiva, una prueba a la que se someten periódicamente y que no dice nada de la forma habitual de trabajo.

    Yo he llegado a estas conclusiones porque lo veo desde dentro. Pero un cliente al que le están vendiendo la moto Coriteles (y similares) continuamente, y le cuentan lo buenos que son, y las maravillosas certificaciones que tienen, y luego lo compara con los resultados que obtienen, tendría que sacar sus conclusiones acerca de la validez de estas certificaciones.

  10. Con eso estoy de acuerdo, tener la certificación no significa nada. Lo que quería decir es que el problema no es CMMI en sí. Yo puedo usar metodologías ágiles ( más bien decir que usas ) y seguir entregando verdaderas chapuzas, y por eso no vamos a decir que las metodologías ágiles no valen. Realmente siempre hay que saber si las metodologías se llevan a la práctica, sea cual sea la elegida.

  11. Q buen post … pero QUE BUENOS COMENTARIOS !!!

    Me gustó el comentario de Jorge cuando nos dice «la oferta debe ajustarse porque estamos en un mundo de competencia voraz, el planning se comprime y los tiempos se hacen irrealizables, aunque no haya más remedio. Y lo peor es que lo sabemos y en muchas empresas se da aún y así con el látigo.» Esto es una triste realidad que a aquellas personas que tratamos de generar un vínculo de confianza con nuestros clientes nos cuesta muchísimo. Un ejemplo, puede ser uno de los padres de la empresa donde trabajo (Tio_Luiso sabe de que hablo)

    En esta empresa, la máxima general es la planificación super-detallada, hasta llegar al extremo de tener proyectos de 30 personas, donde 20 de las mismas están encargadas de la gestión del proyecto. Esta gestión se estima en una etapa inicial utilizando herramientas y métricas incorrectas; y usualmente sin conocer todas las variables externas que afectarán al proyecto. Aquí se consume muchísimo tiempo del proyecto y también del cliente; ya que es el primer contacto real que tiene con su proveedor (nosotros) y a partir de allí; se crea una falsa expectativa en relación con la dinámica que llevará el proyecto.

    ¿Cuál suele ser el siguiente paso?, el Miedo. Cuando un cliente tiene una planificación muy detallada (por ejemplo con tareas de 2 horas), y ve que algunas de las mismas no se cumplen (un desarrollador tuvo la osadía de enfermarse!), comienza a temer retrasos y obviamente más gastos para su proyecto. Y lamentablemente en ese momento, solemos aparecer personas que tenemos otro enfoque.

    Aquí debemos demostrar a nuestro cliente que existen otras alternativas a una planificación tan estricta, que brinda resultados similares y que se basa en un trabajo más realista teniendo un objetivo claro (a donde queremos llegar). Pero este tipo de trabajo, no supone una planificación y no nos vemos mas hasta la entrega, sino que supone sumar al cliente como un integrante más de nuestro equipo de trabajo para que comprenda el día a día de un equipo de desarrollo (agile, msf, cmmi, pin pun pan o el que sea) para que conozca la dinámica de trabajo y que aporte sus necesidades dentro de ésta dinámica 😀
    … (viaje en metro) …
    Retomo el post, después de un rato y cuando releo mi respuesta veo la cantidad de veces que escribí “dinámica” ¿será porque esa es la clave de nuestro trabajo actual?

    Saludos

  12. Ibón, tu mismo has dicho que la diferencia esta en la gente. Recuerda el manifiesto ágil: «Individuos e interacciones sobre procesos y herramientas». Y recuerda CMMI: «Proceso y burocrácia sobre documentación y más burocracia» ;)… Soy un poco malo… pero es que CMMI es seguir tropezando en la misma piedra.

  13. “Una precondición imprescindible para poder usar una aproximación ágil es centrarse en construir una relación de confianza entre las partes, no en negociar ferreos contratos con el afán de protegernos unos de otros.”

    “Aquí debemos demostrar a nuestro cliente que existen otras alternativas a una planificación tan estricta, que brinda resultados similares y que se basa en un trabajo más realista teniendo un objetivo claro ….…supone sumar al cliente como un integrante más de nuestro equipo de trabajo para que comprenda el día a día de un equipo de desarrollo”

    —————-

    Esta muy claro que la teoría la tenemos bien aprendida, pero no en todos los casos podemos presentarnos frente a un cliente y decirle. Tranquilo nosotros somos distintos nuestra metodología es Agile, vamos nuestro propio nombre nos vende tranquilo intégrese en nuestro equipo y vera como si no podemos sacar el proyecto adelante no será por que no lo hemos intentado. Señores seamos serios que estamos jugando con el pan del cliente [Uff que tajante he sido].

    Lo dicho el tema da para mucho, espero y deseo que este tema se siga sacando a debate, ya que seguro que de el podremos sacar muchas cosas. aH y yo también intento seguir la tan querida metodología Agile pero no pensemos que es la panacea.

    Un Saludo 😉

  14. Hola Jose Luis,

    creo o creía que había quedado claro que las metologías ábiles no son la panacea, hasta el mismo Rodrigo creo que lo ha mencionado más arriba.

    Todas las metodologías tienen sus pros y sus contras, pero una metodología ágil tiene menos tendencia al fracaso a priori.

    Tú acabas de decir que no se le puede decir en todos los casos al cliente que se esté tranquilo y que se integre en el equipo, que así irá mejor, y que si no, que no es porque no se ha intentado… pero es que ahí está el quiz creo yo.

    ¿Cuántos proyectos conocéis en los que el cliente se implique y salga mal frente a los que el cliente no se implica y salen mal?. En mi opinión, y espero que en la de la mayoría también, no basta con una metología. También es necesario otras premisas como la implicación, formar equipo, sumar como dice la segunda frase que muy bien seleccionas de otras que ha comentado Rodrigo, etc.

    Lo que pasa es que nuestro trabajo no sólo consiste en aplicar esas metologías, sino en transmitir esa confianza. Tampoco es camino fácil, ya lo sabemos todos, pero es un camino obligado, más largo al principio, pero más productivo en la curva de madurez.

    Bueno… ando algo dormido ya… creo que es hora de descansar.

    Abrazotes, esto es muy muy interesante. 🙂

  15. Buenos post, me gustaria rescatar algunos a partir de mi experiencia,

    1.- No es lo mismo estimación que planificación.
    Las estimaciones no siempre son verdaderas, independientemente de la metodología son expresiones de deseo. La Planificación viene despues de cerrar los acuerdos comerciales y ahí vienen los problemas.
    2.- Las metodologías no son universales… yo agregaría tampoco son «puras»… siempre se combinan.
    3.- Un proyecto es en definitiva una relación entre cliente y proveedor, una negociación… y esa la pierde el mas debil.
    4.- La metodología exitosa es la que se cumple… y por ambas partes…
    5.- Desde el proveedor… el problema es el cliente… Desde el cliente el problema es el proveedor… hay que buscar nuevas relaciones….
    6.- La calidad del software requiere de tiempo…. y no existe el software terminado… se acaban los presupuestos, las paciencias, y los conflictos pueden llegar a no resolverse…
    7.- Los proyectos son permanentes, son un proceso…

    El desarrollo de sistemas, además de tener aspectos cientificos, es un arte…. hay que desarrollar para lo que viene despues del proyecto… lo importante es el resultado… hay que buscar un exito, un modulo que funcione… y construir sobre el exito…. hay que detectar al «dueño» y concentrase en él… no se puede satisfacer a todos … hay que satisfacer al o los que estan involucrados en el liderazgo… sin liderazgo no hay proyecto… y el liderazgo en la empresa no puede ser parte del outsourcing.

  16. A mi, Agile (o más bien XP) me parece que tiene 2 cosas:

    1.- Se definen los problemas de las metodologías pesadas, y se definen 4 valores que se supone que son el espíritu de todo desarrollo agil. Estos 4 valores son: Comunicación, Simplicidad, Feedback y Coraje. Esto no es trivial. Es un resumen de los problemas que tienen las metodologías pesadas. Falta de comunicación en el equipo (o comunicación ineficiente, superburocratizada), falta de feedback del cliente, falta de coraje a la hora de acometer cambios (o más bien, negarse a aceptar cambios y agarrarse a las especificaciones firmadas como un clavo ardiendo) y falta de simplicidad a todos los niveles. Esta es la filosofía de XP.

    2.- Un conjunto de principios y prácticas que en principio se derivan de los valores. Vienen un conjunto, pero en principio, mientras seas fiel a los valores, puedes usar o no las que quieras, o los que te resulten útiles. O puedes inventarte tus propias prácticas. ¿Por qué no?.

    Es decir: Hay cosas innegables (las metodologías pesadas fallan y los motivos por los que fallan) y cosas discutibles (soluciones para estos problemas).

    Solo 3 peros:

    1.- En efecto, Agile no es una bala de plata. Nada lo es. ¿A alguien le suena la expresión «Golden Hammer»?

    2.- Cada cosa tiene su medida. El que ahora haya nuevas teorías no invalida todo lo antiguo. Me he encontrado gente que ahora reniega de UML, o cualquier cosa que huela a metodología pesada. Me parece un error. UML me parece una buena forma de comunicación.

    3.- A raiz del éxito de Agile ahora todo el mundo es Agile. Y lo mismo que dije antes de CMMI se puede aplicar a Agile. No por decir que eres Agile lo eres. En realidad, ni siquiera hace falta seguir ninguna metodología concreta (Scrum, XP, MSF Agile) para ser Agile. Basta con llevar los valores dentro.

    Por último, recomiendo encarecidamente la lectura del ensayo «The New Methodology» de Martin Fowler: http://www.martinfowler.com/articles/newMethodology.html

  17. Genial el POST señores. Gracias a todos exponer sus opiniones. Da gusto encontrarse gente como ustedes para seguir aprendiendo.

    – Objetividad con humildad ( no soy PM ) –

    Estoy de acuerdo en muchos de los puntos de vista aquí expuestos.

    Una de las metodologías que concuerda con «algunos» de los aspectos aquí mencionados es Extreme Programming. En algunas cosas se puede tomar el concepto como ejemplo. Programar probando primero. Esto responde a la comparativa entre: Predicción vs Anticipación. La efectividad está basada en la agilidad pero también en la anticipación.

    A mi me gustaría pensar en poder proponer una «metodología» que sea un mix bien realizado entre todas.

    Las más rígidas no son adaptables y las más ágiles carecen de «planificación». A mi me gusta pensar que un proyecto puede ser medianamente planificado con rango de demora previamente conocido pero no establecido de forma concreta. Podemos dejar al cliente medianamente tranquilo con estimaciones pero negociarle la confianza suficiente para que conozca y acepte la demora a la que un proyecto de ingeniería del software está asociado. Por otro lado el cliente debe conocer el valor añadido que le supondrá el desarrollo y la implantación de un buen proyecto informático. Debe poder verlo y contrastarlo, bien sea con ejemplos o bien sea forzándole a que realice el trabajo de recordar sus experiencias provocando así su implicación directa en el proyecto. Al final de esto debemos poder decirle “No somos baratos, pero nosotros no vendemos promesas, vendemos valor añadido nuestros clientes”. Con este planteamiento el cliente obtiene “números”, a medias, pero al final “números” en los que se puede sostener, pero, a la vez, también conoce el concepto de demora. No tan solo sabe que existe, sino que sabe que es real y que va a ocurrir si o si.

    Por qué no podemos pensar en proyecto basado en alguna de las metodologías (MSF, RUP), que proporcionen iteratividad sobre los aspectos funcionales, centradas en un mismo núcleo, que pueda ser prototipado como fase inicial de un proyecto, el cual el cliente pueda “tocar”, en el que se pueda implicar. En base a eso, podemos girar entorno al núcleo haciendo reingeniería sobre él, y construir el resto generando nuevas iteraciones que nos permitan adaptarnos a las situaciones cambiantes.

    Eso si, veo la necesidad de que esto esté guiado por un lenguaje común que todo el mundo entienda, un lenguaje que permita ver con claridad el sistema, los requisitos y las funcionalidades. Creo que UML es bastante imprescindible en todo ello. Obviamente sin ser purista al 100%, los extremos nunca son buenos, hay que centrarse en extraer los puntos clave de cada cosa y llegar al término medio.

    E aquí un pequeño resumen, de lo que, a mi modo de ver, y des de mi punto de vista de analista programador existe en cualquier proyecto informático. (P.D. ODIO la palabra programador. ¿somos o no somos ingenieros del software? ¿Nos interesamos o no en Best Patterns & practices, MSF, RUP, UML, herramientas CASE…? ¿Entonces, por qué se nos valora a todos así? )

    Consultora:

    – “Facturar, facturar, facturar…” Somos “pollos” que hay que recolocar cuando no son productivos. (Cosa que en algún caso, puede que llegue a ser cierto)
    – Sino hay, apuestas por nuevas tecnologías y una buena gestión de proyectos = Desmotivación total + “Horas, horas y más horas”.
    – No se puede contratar en base a certificaciones, ni a empresas ni a empleados. ¿Qué diferencia existe entre ser un MCSD o MCPD de Microsoft y tener una etiqueta de anís del mono? En la primera te has leído las preguntas del testking y en la segunda te has bebido la botella. Menuda diferencia. Siempre hay las personas como yo que se leen el temario, lo estudian, lo entienden e intentan aprobar los exámenes sin las respuestas antes de estudiárselos para el examen final. Pero no se pueden valorar a las personas por ello.
    – ¡¡¡Confección de un buen equipo!!! Esa si que es tarea de los Project managers, siento cargaros el muerto… jejejejejeje, pero es muy importante. Gente que esté capacitada y que pueda conjuntar bien. No colocar Ferraris para ir a 20 por la autopista (desmotivación) ni tampoco a seats panda para subir a los pirineos (horas, horas y mas horas = mas desmotivación y encima estrés.)
    – COMUNICACIÓN, entre todos los elementos del equipo. Es importantísimo. Si queremos se ágiles es muy importante que cualquier percepción de desviación, cambios etc… se comunique con rapidez y se organice el trabajo en base a ello.
    – ¿»Saber vender»? ¡No! Ser sincero y realista.

    ¿Quién está vendiendo qué?

    ¿El comercial? ¿Presales? ¿El ingeniero?
    CUÁNTO QUÉ CÓMO

    Esa tarea tiene que ser supervisada por todos a la vez. ¿Cuántos proyectos se venden sin saber? ¿Cuántas veces “el que vende” no tiene ni idea y cuela todo lo que puede para ganar el proyecto?

    Cliente:

    – El cliente: ¿Tiranosaurus rex? ¿O Homo sapiens? Hay que mostrarse seguro de sí mismo. ¿Quién es el experto aquí? ¿Quién decide entonces? No es quién paga, sino quien realiza. Es decir, la misma confianza que se ha generado para la planificación del proyecto es básica para proponer y elaborar un diseño, en base a nuevas plataformas con visión de futuro. ¡¡¡Se acabó el Cobol, VB6.0 etc…!!! Como mucho estudiemos herramientas de migración, o a las malas, integración. El cliente tiene que ser consciente de ello, por más ignorancia que tenga de la actualidad tecnológica. Ese también es nuestro trabajo.

    – El cliente dispone de dinero, solo quiere gestionar para obtener. Hay que recordar que para el cliente, la informática aun es un gasto, no una inversión.
    ¿Sabe el cliente realmente diferenciarlo? ¿Sabe qué valor añadido va a aportar nuestro sistema? Hay que explicárselo. Hay que saber contárselo y saber demostrárselo.

    Creo, desde mi punto de vista, que hay que centrar esfuerzos en generar la confianza del cliente. No nos conoce, necesita saber números. Démosle “números” si se puede, pero siempre concienciándolo de la demora y de la calidad con la que trabajamos. No vamos a permitirnos el lujo de entregar algo mal desarrollado. Además somos lo suficientemente ágiles como para captar los elementos conflictivos, cambios y demás con la suficiente rapidez para que sean solucionados en el mismo momento o clasificarlos para incluirlos en la demora posterior previamente conocida pero no estimada de forma concreta.

    Y en cuanto al proyecto, deberíamos ser capaces de extraer lo mejor de las metodologías y aplicarlas, pero siempre acompañadas por un lenguaje común, una documentación increíblemente accesible y especializada para cada cargo dentro del equipo de trabajo, un conjunto de tests unitarios e integrales, todo ello gestionar por herramientas también ágiles desde el punto de vista de seguimiento, organización y comunicación.

    Nada, un granito de arena más.

    ¡¡Gracias a todos!!!

    ¡¡Saludos!!

  18. Hola,

    He leido todos los posts y estoy de acuerdo en todos, pero a la vez no. Me explico. Rodrido, siempre dices que lko que hay que hacer es «establecer una relación de confianza y colaboración que permita abordar los proyectos de una manera diferente», palabras textuales. Y eso esta muy bien.

    ¿Pero cuando ya tienes todo eso y cada dos por tres el clientes te está cambiando la programación que habías expuesto desde un principio?
    Por mucha confianza con el cliente que tengas, lo que el cliente quiere ver siempre, son resultrados, chicha, carne, vamos que no le valen las cosas de palabra, que para eso nos pagan.

    Otra cosa que veo en los proyectos, tampoco soy PM, es el tiempo que se «pierde» en hacer las propuestas. Actualmente estopy en un proyecto por el cual se están analizando 7 escenarios diferentes para el mismo proyecto. Tienen a 7 personas diferentes, cada una con un escenario, haciendo una prueba piloto. ¿Esto es funcional? Desde el punto de vista de un simple desarrollador, no.

    Un saludo a todos,

  19. Como el titulo dice, Necesito alguna utilidad para la planificacion de iteraciones, he podido ver que el diagram de ganth lo realiza, pero no contiene por ejemplo el tamaño del trabajo que se le va a dedicar en dicha iteracion, sino que solo muestra los tiempos de cada tarea (iteracion), esto en MS project, necesito algo que muestre las fases VS disiplinas, que se ven de ejemplo en el propio libro RUP.

Responder a ilanda Cancelar respuesta

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