Típicos tópicos erroneos sobre estimación ágil

open your eyesHace algunos días que al hilo de algunos post que hemos publicado sobre  estimación Lucas Ontivero y yo venimos manteniendo un debate interesante sobre técnicas de estimación. La estimación es un tema que he tratado de manera habitual en este blog. El defiende un enfoque más tradicional e ‘ingenieril’ y yo lo que creo que es un enfoque más ágil, posibilista y realista.

En mi último post sobre Planning Poker, una técnica que usan para estimar la dimensión de los proyectos una parte importante de los equipos que usan metodologías ágiles, Lucas Ontivero publica un comentario con ciertas críticas a esta técnica (que podrían ser extensivas a la estimación ágil en general) y que translucen, desde mi punto de vista bastante desconocimiento de porque funcionan las técnicas de estimación ágil. Este desconocimiento es generalizado y fruto de años de frustado enfoque ‘ingenieril’ y tradicional a la gestión de proyectos. Comentaré aquí porque esas críticas son infundadas y porque la estimación ágil funciona. Esto empezó siendo un comentario, pero creció hasta convertirse en un post. Pongo las críticas de Lucas, que son las de muchos otros, todo hay que decirlo, en cursiva y mi respuesta debajo.

«El Planning Poker es solo una única técnica de estimación y deberíamos usar varias. Usar Planning Poker con Wideband Delphi es comer pan con pan.»

Planning Poker y Wideband Delphi casi siempre van de la mano. En el caso del Planning Poker, la clave es que al usar las cartas todas las estimaciones se desvelan de manera simultanea lo que evita que unas estimaciones sesguen otras. Además las cartas siguen una serie inspirada en la serie de Fibonnacci: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, la idea es que es posible diferencia un requisito de 1 de una de 2 pero difícilmente cuando estimamos un requisito en 13 lo podemos distinguir de uno de 14 debido a las incertidumbres inherentes a toda estimación. La incertidumbre de la estimación crece de manera no lineal con el tamaño del requisito a estimar. Usar valores no continuos, sino los valores discretos de la serie planteada, se ha demostrado como una manera efectiva de considerar la incertidumbres que supone estimar requisitos de magnitud creciente.

En lo que se refiere a Wideband Delphi simplemente es un proceso orientado a construir consenso entorno a la estimación a base de compartir información y detectar dispersión en las estimaciones. Sin duda se tratan de dos técnicas complementarias y diferentes. Planning Poker y Wideband Delphi no asumen nada sobre como cada uno llega a su estimación: uno lo hará por descomposición, otro por comparación, otro usando datos históricos, otro simplemente basándose en su intuición… cualquier técnica que permita obtener un resultado rápidamente sirve.

«Las técnicas de estimación ágil necesitan la participación de todos y esto no siempre es posible. Si somos 21, como en mi proyecto, se complica un poco. Aunque sigue siendo factible.»

Esto no es cierto. Sobre todo cuando se trata de estimar requisitos que es cuando precisamente se usa Planning Poker. Sin duda es recomendable, pero no imprescindible, que todo el equipo participe en el proceso de estimación a nivel de requisitos, si que es imprescindible cuando estimamos tareas de desarrollo, pero no es este el nivel de granularidad que hoy me ocupa. En cualquier caso si seguimos una metodología ágil, nunca tendremos un equipo de 21 miembros, sino varios equipos con un menor número de miembros. Lógicamente en un proyecto de esta envergadura los requisitos se particionarán de alguna manera y cada equipo atacará un conjunto de requisitos. Se hace evidente que cada equipo podrá estimar el conjunto de requisitos que va a atacar. No hay nada que impida que todos participen.

«Se tiende a eliminar las opiniones extremas y la gente se cansa por lo que empieza una convergencia forzada hacia un valor que no siempre es compartido (en un proyecto de training perdimos 2 días discutiendo hasta que cuando nos cansamos convergimos mágicamente!)»

No se trata de ‘llevarse al gato al agua’. En un equipo ágil nadie va a defender sus estimaciones durante dos días. Simplemente es una cuestión de ego y el ego tiene poca cabida en los equipos ágiles. El objetivo es lograr una estimación compartida, consensuada y razonada, nunca tratar de imponer tu estimación sobre la de los demás. Todos asumimos que nuestra estimación puede ser errónea y que solo compartiendo y desvelando información la estimación mejorará. No hay margen para discutir dos días porque todos en un equipo ágil deben conocer que a partir de cierto punto dedicar más tiempo a realizar la estimación solo la mejora marginalmente. Hay una asíntota clara. A partir de cierto punto por más tiempo que pases estimando tu estimación solo será mínimamente más acertada, el esfuerzo no merece la pena.

«Consume más tiempo que los métodos paramétricos, que los que usan analogía y que los «ingenieriles»»

No comparto está afirmación. Múltiples estudios (me remito a la bibliografía de Steve McConnell) cita que uno de los motivos porque los métodos tradicionales de estimación no se llevan a cabo es porque se percibe que consumen demasiado tiempo. Las sesiones de estimación ágiles siempre están limitadas en el tiempo, no hay margen para la divagación. Es una práctica habitual en las metodologías ágiles establecer límites temporales claros e inviolables a toda reunión o proceso.

«Hace falta un buen moderador para llegar a buen puerto.»

No se suele necesitar un moderador. En equipos que tienden a divagar o a dispersarse, generalmente por no estar entrenados en la estimación, un simple reloj de arena es suficiente. Una vez consumido el tiempo se estima si o si. Insisto, no por más comentar un requisito o discutir una estimación vamos a obtener una mejor estimación. Si hay dispersión, se produce otra ronda. No he vivido nunca más de tres rondas de estimación y ayudo a estimar a muchos equipos a lo largo del año. En cualquier caso, creo que ser un buen moderador es una característica que todo gestor de proyectos eficiente debe poseer y un buen gestor de proyectos es algo que todo proyecto necesita, luego la estimación ágil, aunque la proposición que abre esta sección fuese cierta, no introduce ninguna exigencia nueva en nuestros proyecto: siempre necesitamos un buen moderador, a ser posible varios.

«Arroja mejores resultados mientras más expertos «verdaderos» sean sus participantes. Si no son expertos…»

No es cierto que la estimación de solo expertos sea mejor. Esto sería cierto si los expertos fuesen quienes realizasen luego la implementación . Es evidente que quien va a implementar una requisito es quien debe estimarlo. Esto es una máxima en estimación. La motivación es evidente, solo quien va a realizar algo puede estimarlo. Seguro que Miguel Induráin estimaría, como ciclista experto que es, que puede subir el Tourmalet en un determinado tiempo y seguro obtendría una buena estimación. Pero si él estima y soy yo quien sube sin duda se va a equivocar, por experto que sea.

En los proyectos de software, rara vez se conoce con certeza quien finalmente implementará un requisito, por eso tenemos que tender a dar voz a cuantos más implicados mejor, idealmente a todo el equipo. A menudo la gente más inexperta vislumbra incertidumbres o dificultades que los expertos tendemos a olvidar. Introducir gente menos experta en el proceso de estimación es una manera de asegurarte de que las estimaciones son validas en un espectro más amplio de situaciones no solo cuando contamos con desarrolladores expertos.

En cualquier caso, es necesario que todos los desarrolladores, expertos o no, puedan asumir las estimaciones como suyas. Es una cuestión de motivación. Si un desarrollador no asume una estimación como realista no trata de cumplirla. Steve McConnell habla de las estimaciones percibidas como no realistas como uno de los principales factores que dañan la motivación. La manera de asegurarte que las estimaciones se perciben como realista es basarlas en el consenso y construir las estimaciones con la participación de todos los implicados. Mi motivación para cumplir una estimación que yo acepte, en la que participe y a la que me comprometí es alta, mi motivación para cumplir una estimación que mi jefe acepto, en la que yo no participé y para la que él se comprometió seguro no va a ser tanta. En Peopleware, biblia de la gestión de proyectos con más de 25 años, se describe como la motivación es el principal factor impulsor de los proyectos de software.

En cualquier caso, desde un punto de vista de gestión de equipos de trabajo, es sano que todo el mundo tenga voz en algo tan importante como la estimación.

16 comentarios sobre “Típicos tópicos erroneos sobre estimación ágil”

  1. ¿qué métodos presentaba como más ingenieriles? ¿basados en puntos función, por ejemplo?
    Creo que en las metodologías ágiles hay otra ventaja, y es la repetición de esas estimaciones en cada sprint, eso da un aprendizaje, basada en una experiencia inmediatamente sucedida (el sprint anterior), y en un futuro muy predecible (el siguiente sprint), que va haciendo afinar considerablemente las siguientes estimaciones.
    El problema, tanto para un método como otro, es en realidad cuando debes estimar con unos requerimientos muy flojos, para poder cerrar un contrato con el cliente… y luego ya verás… 🙂

  2. Rodrigo, en un par de horas postearé mi respuesta en mi blog para extenderme un poco más.

    Joserra, quería comentarte que yo no he presentado nada muy ingenieríl, solo he demostrado matemáticamente las ventajas de estimar por rangos. Un post similar y mucho más ameno (más corto y más tonto en realidad) que el mio es «Agile Estimating – Estimation Approaches» de Mike Griffith. Te dejo la url: http://www.pmhut.com/agile-estimating-%e2%80%93-estimation-approaches. Leelo y poder también leer el mio: http://geeks.ms/blogs/lontivero/archive/2008/03/12/Estimaciones-y-Scheduling-Avanzado.aspx.

    Saludos!

  3. Estoo, lo que has puesto no es la serie de Fibonacci, aunque se le parezca. La serie de Fibonacci comienza por 0,1,1,2,3,5,8,13,21,34,55…

  4. Alberto, efectivamente no se trata de manera estricta de la serie de Fibonacci. Se trata de una variación inspirada en ella.

    Ya lo he corregido en el post.

  5. Lucas ya leí tu respuesta. Uff… habría tanto que discutir…

    Sinceramente que solo estimen los expertos es aberrante, ya explique el porqué. Si tu eres un experto tu estimación no vale si la implementación la va a realizar finalmente alguien menos experto.

    Efectivamente WD y PP consumen tiempo, pero no solo dan una estimación sino que sirven para clarificar los requisitos. De todos modos, Cohn lo dice claro, no son técnicas para usar con tareas sino con requisitos. En Scrum en 4 horas estimas el trabajo de 8 personas de un mes. No me parece que consuma mucho tiempo…

    Por último todas las citas que usas para revatir mis argumentos son del siglo pasado, muchas cosas se están moviendo en la ingeniería del software, aunque mucha gente no se está enterando.

    Efectivamente el optimismo inherente al desarrollador hace que sea optimista. Pero es optimista en lo que se refiere al tiempo, no tanto en lo que refiere a la magnitud. Por eso en las metodologías ágiles primero estimamos magnitud y luego tiempo de desarrollo, de manera separada.

    En este post insistes en los argumentos que yo rebatí pero no veo para nada nuevos arguementos a parte de un motón de citas de expertos en gestión de proyectos de la ‘vieja escuela’. Yo también bebí en las aguas del gran Steve McConnell pero sinceramente su libros se publicaron hace una eternidad…

    Leyendo tu post queda claro que no conoces a fondo los fundamentos que guian las metodologías ágiles y la estimación ágil, así que es muy dificil que comprendas lo que digo. Nunca le darás importancia a cosas que son vitales para mí, como por ejemplo que todo el mundo sienta que tuvo voz en la estimación, que todos sientan las estimaciones como suyas…

  6. Llevo siguiendo con auténtico interés el debate se ha planteado entre Rodrigo y Lucas los últimos días. Y quiero poner mi granito de arena.

    Llevo años gestionando proyectos y he leído a fondo a Steve McConnell y a otros autores de los tradicionales. Se puede decir que hasta hace poco gestionaba los proyectos de manera clásica, guiado por un plan, descomponiendo en tareas… unas veces con más exito y otras con menos, pero en un tema que fallaba sistematicamente era en la capacidad para estimar. Fuese por lo que fuese, e intentase la tecnica que intentase, el proceso de estimación nunca daba los resultados esperados, consumía mucho tiempo, la gente no se sentia cómoda estimando etc… Ni siquiera después de leer Destimitifiying the black art of stimating de McConnell logre mejorar.

    Luego empece a leer a Rodrigo y sus post sobre estimación y sobre Scrum y le pedí que viniese a formarme y a formar a mi equipo. Puedo asegurar que lo que propone funciona de manera excelente. Por primera vez en mucho tiempo como gestor de proyectos logro tener estimaciones que el equipo cumple. Y la verdad, eso a cambiado mi forma de gestionar proyectos de manera radical.

    Saludos a todos. Rodrigo, sigue así después de conocerte se que existe otra manera mucho más racional de gestionar los proyectos.

    Firmo como ánonimo para que Rodrigo no tome esto como peloteo… 😉

  7. Anónimo, creo que se quien eres… no deberías estar de fiesta, hoy es el patrón de tu tierra si no me equivoco 😛

    Un saludo y gracias por lo alagos… pero yo no inventé nada!!!

  8. Ya estoy cansado. Ni usando los autores que me recomiendas reconoces que tus errores. La postura de negar lo aprendido hasta ahora es ilógica. Habrá que desechar todo entonces y cree solo en tu palabra porque solo te citas a ti mismo como fuente del saber.
    No hablé de scrum ni en una sola oportunidad. Eso de intentar a toda costa acusarme de «ingenieril» es una chicana similar a acusarme de hereje en el medioevo o de comunista durante la guerra fria. No sirve. Yo siempre he planteado mi postura muy pero muy clara: los extremos están equivocados y vos como extremista no colaboras al conocimiento de la comunidad en lo más mínimo.
    Este comentario que me haces parece estar dirijido a una horda de ignornates, no son los ágiles los que estiman tamaño y luego esfuerzo, simplemente así se hace.
    Tampoco cito fuentes antiguas, Agile Estimating and Planning (by Mike Cohn) es bastante nuevo y me lo recomendaste vos mismo.
    Sinceramente queda claro que tu postura o es demagógica o es de una profunda ingorancia que le hace muy pero muy mal a la profesión.

    Yo también terminé esta discusión.

    Saludos.

  9. Al igual que Anónimo, vengo siguiendo esto desde que comenzó. Y creo que hay un problema sistemático en todo este debate.

    Primero, se sigue sin entender lo que Lucas escribió al principio de todo esto. Y por el otro, Rodrigo, me parece que estas en un extremo.

    Ojo, en ningún momento digo que los métodos ágiles de estimación sean incorrectos, ni que los «formales» (por llamarlos de alguna forma), son los correctos.

    Sigo la línea de pensamiento de Lucas. Los extremos son malos.

    Ahora, lo que veo, es que, Rodrigo, estas cayendo en una actitud falaz al hablar. O sea, tratas de denigrar los comentarios y pensamientos de Lucas, para sustentar los tuyos.

    Ojo (De nuevo), en ningún momento estoy diciendo que no sepas ni tengas conocimientos, pero solo estas hundiendo algo para sacar a flote lo tuyo.

    Como bien dice Lucas, las referencias que uso son sacadas de aquellos lugares que, en una actitud paternalista, hiciste referencia como fuente de conocimiento y demostración de superioridad.

    Lamentablemente, esto ya parece una pelea entre usuarios de FireFox e Internet Explorer, o Linux vs. Windows, o un largo etc.

    Básicamente, el post inicial hacia referencia a una interpretación de la lectura de autores y discusiones de café, con una mezcla de experiencias personales. Y que, curiosamente, parece funcionar. Tal vez tanto como el método que planteas.

    Nuevamente, me parece que una actitud paternalista, haciendo uso de falacias, no demuestra conocimientos, solo demuestran arrogancia.

    En mas de una ocasión, simplemente trataste de ignorante a Lucas, por lo que, al compartir una idea, lo sentí personal. Así como muchos otros que comparten la misma idea.

    Posiblemente, en un futuro, seria excelente que quites del medio este tipo de palabras que pretenden, una vez mas, denigrar a alguien o a una idea para simplemente apuntalar una no tan fundamentada como la que planteas.

    Como nota al pie, cuando digo, no fundamentada, me refiero a que no vi, en esta «pelea», argumentos sólidos por tu parte, lo que no quiere decir, en ningún momento, que la idea y la metodología no sirvan.

  10. No sé quién de los dos tiene razón, si es que alguno la tiene, pero veo una cierta incoherencia en parte de tus razonamientos sobre las referencias bibliográficas. Citas a McConell en tu artículo y después lo tachas de desfasado, criticando que las referecias que aporta Lucas son antiguas, para después mencionar «Peopleware, biblia de la gestión de proyectos con más de 25 años.»

  11. Veo que no soy el único que ha leído con atención los post de Lucas y Rodrigo… pero de verdad no entiendo los comentarios de Lucas y de Matias… ¿Cómo

    pueden acusar a Rodrigo de extremista? ¿Cómo le pueden acusar de falaz? Es como el mundo al revés…

    Argumenta Lucas, usando numerosas referencias sacadas de contexto en contra de Rodrigo con el único afán de dejarlo en evidencia:

    «Participants in planning poker include all of the developers on the team. Remember that developers refers to all programmers, testers, database engineers,

    analysts, user interaction designers, and so on. On an agile project, this will typically not exceed ten people. If it does, it is usually best to split into

    two teams.
    Each team can then estimate independently, which will keep the size down.»

    Perfecto, pero esto es exactamente lo que Rodrigo dice:

    «Sin duda es recomendable, pero no imprescindible, que todo el equipo participe en el proceso de estimación a nivel de requisitos, si que es imprescindible

    cuando estimamos tareas de desarrollo, pero no es este el nivel de granularidad que hoy me ocupa.»

    Y también:

    «En cualquier caso si seguimos una metodología ágil, nunca tendremos un equipo de 21 miembros, sino varios equipos con un menor número de miembros.

    Lógicamente en un proyecto de esta envergadura los requisitos se particionarán de alguna manera y cada equipo atacará un conjunto de requisitos.»

    Si Lucas hubiese hecho algo más que buscar frases sueltas sacadas de contexto para rebatir a Rodrigo quizás sabría que el propio Mike Conh en la obra citada

    por Rodrigo propone que cuando se está estimando un proyecto para el que aun no este formado el equipo se tire de quien este disponible, aunque evidentemente

    esto no es lo deseable.

    También dice Rodrigo:

    «En cualquier caso, creo que ser un buen moderador es una característica que todo gestor de proyectos eficiente debe poseer y un buen gestor de proyectos es

    algo que todo proyecto necesita, luego la estimación ágil, aunque la proposición que abre esta sección fuese cierta, no introduce ninguna exigencia nueva en

    nuestros proyecto: siempre necesitamos un buen moderador, a ser posible varios.»

    Cita Lucas de nuevo para rebatir a Rodrigo:
    «For each user story or theme to be estimated, a moderator reads the description. The moderator is usually the product owner or an analyst.»

    Rodrigo dice:
    «Las sesiones de estimación ágiles siempre están limitadas en el tiempo, no hay margen para la divagación. Es una práctica habitual en las metodologías

    ágiles establecer límites temporales claros e inviolables a toda reunión o proceso. »

    Y Lucas lo trata de rebatir con:

    «Because Wideband Delphi requires a meeting, it burns a lot of staff time, making it an expensive way to estimate. It is not appropriate for detailed task

    estimates»

    Pero Rodrigo ya habia dejado claro que no se usa Wideband Delphi para estimar tareas sino requisitos…

    Y el colmo es lo del «pan con pan»… Rodrigo lo rebate argumentando y Lucas solo viene a decir: es pan con pan porque yo lo digo y punto… ¿?:
    Lo que queda claro leyendo lo que Rodrigo explica es que no es pan con pan, que son dos técnicas complementarias… y que cada uno puede usar para construir su estimación la técnica que quiera basada en su opinión, la analogía o la disgregación…

    Y así podría seguir… Vamos me suena a que desde el desconocimiento de lo que habla Lucas necesita escudarse en la autoridad de otros para tratar de

    desacreditar la postura de Rodrigo. Y puede que haya convencido a alguien…

    Yo por suerte, al igual que Anónimo, he tenido el pacer de haber recibido formación de la mano de Rodrigo (y su compañero Unai Estebanez) en el curso que

    dieron el año pasado en Santander y sé positivamente que sus conocimientos sobre este tema son enormes. Se que conoce tanto CMMI, RUP, y la gestión clásica

    de proyectos como las metodologías ágiles y que si algo no es es extremista. De hecho me encanto su frase de cierre del cursos «Intentad diferentes cosas,

    quedaros con lo que os funcione, no hay balas de plata»

    Mi conclusión (que no tiene por que ser cierta): Rodrigo no se escuda en citas sino en conocimientos y experiencia propia a la hora de defenden su postura, la argumenta y muestra tener ideas claras sobre el tema… sinceramente Lucas no me da la sensación más que de haber leído mucha teoria pero de la teoria a la realidad va un trecho… por ejemplo ignora sistematicamente algo que es central: que la gente asuma como suyas las estimaciones.

  12. Los post de Lucas son abrumadores. Llenos de datos, referencias y citas…El enfoque de estimación que comenta y defiende response a una visión tradicional del mundo de software mientras Rodrigo defiente una visión más moderna de estimación, basada en metodologías y equipos ágiles.

    Me consta que Rodrigo conoce las dos pero no conozco si Lucas conoce las metodologías ágiles y tiene experiencia en ella. Si no es así, sin echar mas leña al fuego, deberías conocerlas para poder añadir mayor calidad a tus post y poder opinar sobre ambos métodos.

    En algún punto de la discusión es verdad que se ha perdido el norte y ambos han podido caer en los extremos. Lucas, tu ultima respuesta tampoco es muy adecuada y si criticas a Rodrigo por la forma de contestar también deberías criticarte a tí mismo.

    Yo os hablaré desde mi experiencia personal, experiencia que he tenido en ambos enfoques, el tradicional y el ágil.

    Mis mejores experiencias son trabajando con metodologías ágiles ya que con éstas he obtenido los mejores resultados.

    Las metodologías tradicionales suelen quedar muy bien en los libros y para vendérselo a los gerentes o responsables de desarrollo, pero son tb las que durante años han fracasado por no tener en cuenta cosas básicas como el equipo, la motivación o la persona como parte clave del proceso de desarrollo. A nivel teórico prácticamente cualquier alternativa se puede defender porque siempre podrás dar datos y citas que puedan ir a tu favor…podríais estar años y años discutiendo.

    Debo decir, que creo fundamental que todos los miembros del equipo intervengan en las estimaciones.Esto lo he realizado en varios equipos de desarrollo y los resultados obtenidos son muy buenos. Y sí, gente con menos experiencia también participa, se involucra y se siente parte activa del equipo. La motivación es mucho mayor.

    He obtenido mejores resultados estimando en equipos ágiles que estimando yo desde mi mayor experiencia e imponiendo éstas estimaciones.

    No conozco todos los libros que mencionáis, pero está claro que es importante tener en cuenta cuándo se han escrito estos libros y el contexto en el que se escribieron. El mundo del software ha cambiado mucho y han salido muchas cosas desde hace 25 años. Yo tb he leído a Steve McConell y tengo claro alguno de ellos habría que revisarlo y que no todo lo que comenta sigue vigente hoy en día, al menos, en mi opinión.

    En cambio, otro libro como Peopleware puede ser el mismo durante otros 25 años más..¿ por qué? Porque los temas que tratan siguen siendo los mismos hoy en día que hace 25 años…que esto del software va de personas!!! Leyéndolo me veía reflejado en infinidad de situaciones que describían….Muchos de los problemas que se describen en este libro son debidos al enfoque tradicional del desarrollo del software y a olvidar algunos principios básicos.

  13. Marcos… bonita historia, pero de verdad si no sabes de lo que hablas mejor que no escribas…

    Las metodologías ágiles usan métricas.
    Yahoo, Google, Microsoft son algunas de las ‘pequeñas empresas’ que usan metodologías ágiles.

    Precisamente los que más valoran los desarrolladores de las metodologías ágiles que no se buscan culpables. Además el desarrollador quiere tener voz y poder establecer sus compromisos.

    Cada vez más y más clientes descubre que CMMI no es garantia de nada y cada vez más y más clientes piden que se usen metodologías ágiles, sudamerica y europa van un poco más a la zaga, pero en EEUU las metodologías ágiles están creciendo de manera espectacular. En cualquier caso tanto RUP como CMMI se encuentran en franco retroceso.

    Hay mucha gente viviendo de vender la moto de CMMI una moto grande, cara, bonita para la galería pero no ha arrancado en dos décadas…

    Yo he vivido el mundo CMMI y el mundo ágil y de verdad a mí no me van a volver a engañar. He visto los resultados de uno y otro modelo… Prefiero a mis desarrolladores desarrollando que rellenado memorandums para tener ‘evidencias’. No hay más evidencia que el software que funciona y el cliente satisfecho y desde que en mi empresa hemos abandonado CMMI esto a mejorado.

    Quizá no sepa cuanta sea esa mejora pero existe y es espectacular: menor rotación de personal, desarrolladores integrados en el proceso de gestión no luchando contra su burocrácia, clientes más satisfechos (lo medimos con encuestas), menores trabajos intermedios sin valor para el cliente, por solo citar algunas mejoras…

    Lo mejor de todo es que aunque CMMI fue un autentico fracaso en nuestro caso seguimos teniendo el sellito… ¡podemos seguir presumiendo de maduros!. De risa vamos…

  14. Solo para mi descargo. Ya que Juan me incluye en su comentario.

    Primero, creo que ninguno leyó mis comentarios en el principio de todo esto. Si así fue, no entendió un «soto» (Como decimos por acá), o, obviamente, no lo leyó.

    Si lo hubiera leído, vería que, tanto Lucas como yo, tocamos temas relacionados a la motivación de los integrantes de un equipo y como comúnmente, las metodologías «formales», taladran el éxito del proyecto.

    Por otro lado, como segundo descargo, al decirle a Rodrigo que usa la falacia para apuntalar sus ideas, es porque, al mismo tiempo, desde el principio de todo esto, Rodrigo sale con los «botines en punta» (Como también se dice por acá) en su primer comentario en el post de Lucas. Simplemente descalifica cualquier idea de Lucas, asignando ignorancia y desconocimiento a la persona, y no, simplemente, mostrando la otra cara de la moneda.

    Después de un ida y vuelta, Rodrigo asume su error. Pero a los pocos días saca este y otro post con un título bastante directo. Digo, no deja nada librado al azar o a la imaginación. Una vez más, Rodrigo, atacas sistemáticamente una idea. Que de nuevo, parece que nadie entiende nada. Es una propuesta que elimina, o apoya la idea de que los datos históricos, y acumulación de horas de proyectos mal cargadas lo único que te darán serán otros números tan errados que no podrás llegar a buen puerto nunca.

    Definitivamente no se que es lo que no se entiende.

    Entonces, definitivamente, todo esto esta logrando «calentarme los coturnos», y que a Lucas ya se les achicharraron, es en la simple insistencia por parte de Rodrigo de prevalecer como la única posibilidad y fuente de conocimientos.

    De nuevo, el método propuesto por Lucas, es algo que, cualquier gerenton adoctrinado en métricas historias aborrecería. Este método dice, entre otras tantas ideas: Si vamos a usar datos falsos, entonces, tiremos los dados. Probabilisticamente tenemos más chances de sacar una mejor estimación mediante la simulación que por medio de datos falsos.

    Ahora, trabajo en una empresa con certificación CMMi 5, y conozco esto por dentro. Cuando una serie de proyectos fallaron, mi primer aporte fue sugerir la aplicación de Scrumm. Se me rieron en la cara, y hasta logre ser plausible de lapidación por tomatazos; diría que el Cipotegato no hubiera sufrido tanto como yo. Mi revancha llego hace unos 6 meses cuando, los mandos superiores bajaron la línea de que: CMMi no va, la posta es Scrumm.

    Al mismo tiempo, trabaje en empresas netamente ágiles, y me toco reorganizar una, donde por supuesto, opte por esta «metodología» (Puedo decirle así? Pregunto por las dudas)

    Ahora, volviendo al tema de la falacia, y de nuevo desde el principio de todo esto, Rodrigo cae en la aplicación de «Argumentum ad hominem», por lo que a Lucas no le queda otra alternativa que recurrir a las mismas fuentes para defenderse.

    La descalificación del otro por simple creencia de superioridad de conocimientos es arrogante, entonces, chicos (acto paternalista por mi parte 🙂 ), antes de aseverar que alguien no sabe, sería bueno saber con quien se discute (acto de arrogancia por mi parte 🙂 ).

    Si bien, la mitad de la línea anterior debería ser tomada en broma. Podrás ver, Juan, que en mis comentarios nunca descalificaron a Rodrigo en sus conocimientos, sino, que le dije claramente que sea menos arrogante, menos paternalista, y que, por favor, no caiga en el uso de la falacia, ya que, como Rodrigo sabe, al igual que yo lo se, o Lucas lo sabe, ninguno de nosotros somos el «faro único de conocimientos». Aceptar las ideas de otros, y mostrar nuestros puntos de vistas en discusiones no tribales o radicales, es la alternativa valida para sacar algo en limpio.

  15. Yo por más que leo y releo lo escrito por Rodrigo no le veo arrogancia ni parternalismo alguno. Más bien veo un tono pedagógico y ganas de enseñar.

    Rodrigo dijo algo, se disculpo por el tono. Luego Lucas, con que seguía con el cuchillo entre los dientes aprovocho un post de Rodrigo sobre otro tema para ‘ar leña’ y Rodrigo respondio con argumentos claros a la crítica infundada, a mi modo de ver, de Lucas.

    De todos modos… insisto, el único de vosotros que ha argumentado algo es Rodrigo. Relean sino…

    No veo porque decis que Rodrigo quiere prevalecer… parece retirado de las discursión desde hace tiempo…

Responder a anonymous Cancelar respuesta

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