lunes, 28 de mayo de 2012

miércoles, 23 de mayo de 2012

¿Han muerto las metodologías ágiles?

Me siento culpable. Y me siento culpable porque soy de los que no les gusta aceptar las cosas porque sí. Necesito verificar criterios, y confirmar que realmente, las indicaciones recibidas y los objetivos, son coherentes.

Y no, no me acabo de levantar con resaca tras una noche de alcohol y desenfreno. Estoy hablando de la muerte de las metodologías ágiles. Y me siento culpable, porque soy muy crítico con posturas tipo “si es ágil es bueno” o también “con SCRUM siempre es mejor”.

Yo veo las metodologías ágiles, SCRUM y XP entre ellas, como los representantes de una gran promesa, un mito casi religioso que ha alcanzado su paroxismo en un cierto momento, y se ha creado una burbuja insostenible. Y la desgracia, será que cuando fallen los proyectos, la culpa se la van a llevar los de siempre: los programadores. Precisamente las metodologías que ponen por encima a las personas, van a ser las que usen a dichas personas como chivos expiatorios, tratando de justificar sus fallos. Y es que tienen fallos (son "humanas"), como me esfuerzo en demostrar con éste y otros mitos.

Y me siento culpable, porque me gustaría ver muchos más proyectos usando Scrum, XP, Lean, etc. Pero no a cualquier precio. No a costa de terminar sufriendo los mismos fallos que las metodologías pesadas y tradicionales nos han traído:
-       Retrasos en las entregas.
-       Spaguetti Code.
-       Deuda técnica.
-       Etc..
Echo la vista atrás y veo que ya hace unos cuantos años que muchísima gente se hace las mismas preguntas que yo:
http://www.infoq.com/news/2008/11/decline-of-agile
http://stackoverflow.com/questions/301993/is-agile-development-dead
http://practicalagility.blogspot.com.es/2008/11/agile-circling-drain.html
http://www.boost.co.nz/blog/agile/rules-of-improv-applied-to-scrum/
http://craignicol.wordpress.com/2011/05/16/agile-is-dead/
http://agilesoftwaredevelopment.com/blog/janusz-gorycki/agile-dead
http://myagileeducation.com/2011/long-live-agile-is-agile-dead/
http://blog.recursivity.com/post/934000041/why-agile-is-dead

Y son sólo unos pocos ejemplos.

Viendo los comentarios que la gente escribe en esos blogs, al final es lo de siempre. Es un flujo que se está cumpliendo con exactitud:
  1. Grandes promesas. En este caso, surge el manuscrito ágil.
  2. No hay pruebas de lo contrario, de que las metodologías no sean el nuevo "resuelve-todo", por lo pero se genera gran expectativa esperando éxito en los proyectos. Curiosamente, con un esfuerzo mínimo. Y además, contentando al colectivo al que se dirige la promesa: por fin los programadores encuentran una metodología que promueve sus aspiraciones y les da el control. ¿Porqué me suena esto extrañamente a la pastilla que todos los años aparece de forma milagrosa y que permite adelgazar sin esfuerzo?
  3. Conforme se añade gente, y un colectivo importante pasa a vivir de la formación, consultoría y porqué no decirlo: de apuntarse al carro y vivir del cuento y de la fama que se consigue con las metodologías ágiles, la burbuja se hace imparable.
  4. ¿Y ahora qué? Pues decepción, sensación de tiempo perdido, proyectos con problemas (los ya comentados retrasos, código spaguetti,...).
  5. ¿Y después? ¿Qué nos depara el futuro? Pues como siempre, adoptaremos las nuevas ideas, aunque esta vez sin verlas como una varita mágica, sino como lo que son: herramientas tan útiles como su adecuación al proyecto en curso, nuestra situación particular, etc...

No hay bola de cristal que nos solucione el punto 5. Ni siquiera tengo claro el que haya explotado aún la burbuja de las metodologías ágiles, a pesar de que muchos autores en la red así lo afirman. De momento, las metodologías “tradicionales” y “pesadas”, no han muerto tampoco. Siguen teniendo sus problemas, pero siempre encuentran un tipo de empresas o proyectos en los que ser de utilidad. En todo caso, evolucionan. Como espero que también evolucionen las metodologías ágiles, evitando convertirse en un elemento más de la cadena de palabras de moda:

·         2nd generation languages
·         3rd generation languages
·         CASE tools
·         UML
·         OOP
·         Java
·         CMM (and CMMI)
·         XML
·         Generics
·         Design patterns
·         .NET
·         Outsourcing/offshoring
·         Agile/Scrum
·         LINQ
·         TDD
·         Etc.

Todos ellos han sido útiles. Muchos de ellos se siguen usando. Pero han tenido su momento burbuja. La clave está en ser lo suficientemente inteligente en mirar atrás y darse cuenta de que al final, no son más que herramientas en nuestra mochila, y no constituye ninguna por sí misma una solución que elimine a las demás de un plumazo.

De todas formas, yo os recomiendo mirar con desconfianza cada vez que un supuesto gurú nos venda la nueva "pastilla milagrosa" en forma de metodología o herramienta.

Además, el uso de SCRUM y otras metodologías ágiles me recuerda a la teoría del caballo muerto que ya comenté en otro post. Se ha tratado de exprimir tanto y tanto a estas metodologías, llegando hasta sinsentidos, que en los casos en que realmente pueden ser útiles (que no son pocos), se genera desconfianza. Curiosamente, es lo mismo que ha pasado ya hace años con las metodologías tradicionales, el desarrollo en cascada, etc.

sábado, 19 de mayo de 2012

El coste de la calidad

La calidad cuesta. Y aquí es donde vais a empezar a pagar. Con horas extras. Uy no. No parece muy buena idea empezar este post parafraseando la frase de aquella serie de los 80 que se llamaba "Fama".

Y sin embargo es cierto: la calidad tiene un coste. Pero no hay que dramatizarlo. Como un compañero de trabajo cuyo nombre mantendremos en el anonimato me decía no hace mucho: "Pero esto de la calidad, ¿cuántas horas extra me va a costar a la semana?". Es curioso. Si se tratara de introducir en el proyecto una tecnología novedosa (aun cuando fuera totalmente irrelevante para el éxito del proyecto), no le importaría dejarse la piel en ello. Pero si se trata de aportar visiblidad, mejorar el número de defectos, introducir buenas prácticas, obtener un repositorio de componentes reutilizables....en ese caso, todo nos cuesta.

Esto me recuerda a cuando éramos niños pequeños: hay que ver cuánto nos costaba lavarnos los dientes. Y sin embargo, es una tarea que supone realmente un esfuerzo y tiempo ínfimos, y mucho más comparado con los beneficios que da. Pero claro, cuando tenemos 4 o 5 años no pensamos en los beneficios. Nos da todo igual.

El motivo de este post ha sido mi lectura reciente de un curso ofrecido por INTECO, en el que he aprovechado para ver si encontraba algo que o no conociera, o que al menos hacía tiempo de lo que no me acordaba. Y me he llevado la agradable sorpresa de un gráfico en el que se analiza el coste del proyecto. Vamos a recordar un poco estos conceptos:

1. Coste del Proyecto

Los costes del proyecto se dividen en Costes de Ejecución (lo que cuesta hacer las tareas productivas), y el Coste de la Calidad (básicamente, el resto)

1.1. Coste de Ejecución

Básicamente serían: la preventa, la planificación y el desarrollo.

1.2. Coste de la calidad

Se dividiría en:
  • Coste de la Conformidad
  • Coste de la No Conformidad

1.2.1. Coste de la Conformidad

  • Evaluación: Son las revisiones, pruebas y auditorías que se hacen para ver que todo está conforme planificado en cuanto a funcionalidad y calidad.
  • Prevención: Son las tareas adicionales de formación, documentación, toma y análisis de datos, etc., que permiten ayudar a que todo esté conforme en cuanto a funcionalidad y calidad.

1.2.2. Coste de la No Conformidad

  • Internos: es el coste de volver a escribir requisitos, rehacer el diseño funcional y técnico, reescribir el código, etc.
  • Externos: soporte técnico, gestión de quejas e incidencias, pérdidas de proyectos, reclamaciones, etc.
El coste de la calidad suele presentarse de forma gráfica de la siguiente forma (clic para ver más grande):
En esta gráfica se muestran los costes totales de la calidad como la suma de los costos de los fallos (lo que hemos llamado "Coste de la No Conformidad"), y los costes de prevención y evaluación (lo que hemos llamado "Coste de la Conformidad"). Vemos que existe un nivel óptimo en el que conseguimos mantener una cuota de fallos razonablemente baja, con un coste total mínimo.

lunes, 14 de mayo de 2012

Porqué nacieron las metodologías ágiles

Viendo todos los motivos anteriores  (ver mis post sobre el desarrollo en cascada) que justificaban (más o menos) la existencia en su momento de metodologías en cascada, y que éstos con el paso del tiempo, dejaban de tener sentido...fruto de aquella situación general de "indignación", nacieron las metodologías ágiles.

Esto que suena tan convincente, no deja de ser una verdad a medias. Realmente, no han cambiado tanto los proyectos de desarrollo de software. Y tampoco han cambiado en todos los escenarios. Sin embargo, las metodologías ágiles si han presentado una opción 100% radical, lo cual ha presentado sus propios problemas (ver mi artículo sobre los defectos de SCRUM).

Lo que sí han surgido son necesidades de cambio. Los proyectos a finales de los 90, tenían problemas: altas tasas de fallos, retrasos en las entregas, funcionalidades impredecibles...

Lo que hicieron los autores del manifiesto ágil fue tratar de vender sus ideas. Y como la mejor forma de vender sus ideas era siendo radicales...lo fueron. Se trató de dar un volantazo al mundo del desarrollo de software, y se establecieron las bases de lo que hoy son los desarrollos ágiles. Ojo, esto que suena tan irreverente, al final, resultó un buen argumento de venta. Las metodologías ágiles presentaban muy buenas ideas, y aunque envueltas en un manto de "giro radical" y "oposición a lo existente" (como toda buena revolución, esté o no justificada), ha traído un más que necesario aire fresco al mundo del desarrollo software.

Incorrecciones habituales al hablar de estas cosas:

Voy a comentar algunas incorrecciones (desde mi punto de vista), que observo al leer sobre estos temas.
  • "El sistema en cascada para gestionar proyectos...". Waterfall, o Cascada, no habla de cómo gestionar proyectos. Gestionar proyectos no tiene nada que ver con cómo se estructura el ciclo de vida del software (SDLC). Cuando hablamos de estas metodologías, normalmente nos referimos al ciclo de vida (SDLC). No a la gestión, ni a otros procesos relativos a la construcción de software.
  • Se suele intentar asociar de forma forzada a las metodologías ágiles con la ingeniería del software. Eso no quiere decir que las metodologías ágiles sean opuestas a la ingeniería, a pesar de que tradicionalmente los defensores de las metodologías ágiles se han mostrado contrarios a los paradigmas de la ingeniería del software, más cercana (insisto, tradicionalmente), al control y disciplina de los métodos predecibles.
  • "En las metodologías ágiles se pueden realizar mantenimientos desde la primera entrega". La primera en la frente. O sea, que tengo un equipo de 5 personas realizando iteraciones. En la segunda iteración, quito a uno para que mantenga la primera iteración....en la tercera, quito a otro para ayudar al anterior a mantener las dos primeras...Para cuando lleve 5 iteraciones, ya no tengo avance: en lugar de añadir funcionalidades, tengo a los 5 del equipo, arreglando defectos, haciendo evolutivos...y sin añadir casi funcionalidad. O peor, conforme añado funcionalidad, tengo que corregir todo porque no se integra con todos los cambios que se hace sobre lo anterior. En fin.

miércoles, 2 de mayo de 2012

Defectos de CMMI

Aquí quiero contar los defectos de CMMI per-se, y por sus malas implementaciones en metodologías apresuradas o porque el único interés era conseguir "el sello de calidad".

Si has leído otros post, verás que no estoy a favor de defender metodologías porque estén de moda (como Scrum), sino solamente porque demuestren razonadamente beneficios. Para mi desgracia, sí que me gustan las metodologías ágiles, a pesar de mi resistencia a defenderlas “porque sí”. Eso me hace, por convicción, tener que evitar la tentación de venderlas constantemente y a ciegas. De hecho, suelo "darles caña", simplemente porque creo que en ellas está el futuro, pero requieren de disciplina y sentido común a la hora de implantarse, y sobre todo no olvidar que hay más cosas que "picar código" y que la empresa y el cliente necesitan que se lleven a cabo.

Vamos a razonar los defectos (que los tiene) que se suelen alegar en contra de CMMi.

Alcance.
Efectivamente, no se obtiene normalmente el CMMi para una empresa. Se obtiene con un alcance determinado (un departamento o unidad de negocio), varios de ellos, o un conjunto de proyectos relacionados de alguna forma. Ojo con esto, porque seguramente las empresas que afirman que son CMMi nivel X, en realidad suelen tener un alcance inferior al 100% de su  personal y proyectos. Basta que vayáis a la base de datos de empresas que han obtenido el nivel X de CMMi, y leáis los detalles del alcance. No es que se mienta, es la gente quien al desconocer estos detalles, se hace una idea equivocada. Es interesante decir también que en los resultados de la evaluación se hace mención explícita de los proyectos y personas evaluados. De esta forma, se da una idea porcentual del alcance de la certificación CMMi en la empresa.

CMMi no cubre todo
CMMi deja de lado diversas áreas de la empresa, como pueden ser las contrataciones, motivaciones, y en general todos los temas relacionados con las personas. Bien, al respecto hay que decir que CMMi-DEV es un modelo de madurez del desarrollo de software, no de la gestión de personas. Para eso, existe un People CMMi. Si alguien quiere tener en cuenta a las personas, puede certificarse en ambos. O si sólo quiere certificarse en la gestión de personas…pues ahí está. De todas formas, en mi empresa, lo que se evalúa es la metodología, y en nuestro caso incluía gestión de recursos, formación a nivel corporativo, etc. Vamos, los típicos procesos de training, staffing y recruiting. Y esos procesos fueron revisados durante el SCAMPI, como parte de la metodología. De hecho, al final del SCAMPI, se obtienen “puntos fuertes” que son buenas prácticas más allá del mínimo que exige el modelo.

Es una foto parcial de la empresa en un momento, pero el título es para siempre.
Bueno, los resultados de un SCAMPI tienen validez de 3 años. Si ANTES de ese tiempo no se ha hecho una nueva evaluación igual o superior, se pierde ese nivel de madurez. Lo que sí es cierto es que es una foto parcial de la empresa. Los proyectos pasado el SCAMPI, pueden descontrolarse, y perder todas esas buenas prácticas, pero claro, si es así, ya se pasará factura si se trata luego de renovar el nivel de madurez. Mi experiencia es que si las metodologías implantadas son ligeras, y se hace contando con la gente, su uso es suficientemente beneficioso para que los proyectos lo mantengan por sí mismos.


CMMi no reconoce ciclos de vida (SDLC) como parte del modelo.
A ver, CMMi es un modelo. Recopila paquetes de actividades que se consideran básicas, y dentro de cada una, se puede tener un nivel u otro de madurez. Los ciclos de vida son parte de las metodologías, pero CMMi deja libertad a ciclos en cascada, iterativos, ágiles, etc. Yo comprendo que hay gente que quiere que CMMi les resuelva la vida. Y no lo va a hacer. CMMi dice lo que se necesita hacer en todo proyecto, pero es el buen juicio y el sentido común de los creadores de las metodologías, los responsables de que se haga trabajo de más, o de que a un proyecto de 3 personas acabemos pidiendo documentación fuera de lugar.

Burocracia.
Bueno, de esto ya hablé en el mito de la burocracia. No le daré más vueltas. Puede efectivamente convertirse en un grave defecto si no sabemos adaptar y aligerar las metodologías a los proyectos. Sin embargo, lo veo más una excusa para evitar involucrarse en CMMi, con la errónea creencia de que va en contra de los métodos ágiles.

Proyectos de distinto tipo a los que han pasado la evaluación de madurez CMMi.

Efectivamente, puede ser que todos los proyectos que pasen CMMi fueran Oracle, de desarrollo, y con ciclo de vida iterativo. ¿Qué pasa ahora? Pues nada, los proyectos que no sean así, dependerán de si la metodología también se adapta a ellos, y de un montón de cosas más. ¿Qué cómo contempla esto CMMi? Pues no lo contempla. Por eso existe un alcance.

CMMi no es una certificación.
A pesar de que llevo ya varias frases utilizándolo aposta (a ver si alguien dice algo), en realidad no puede decirse “la empresa X está certificada CMMi nivel…”. Lo que se hace es una evaluación de madurez, pero en ningún momento el SEI (Software Engineering Institute) proporciona certificado de ningún tipo, al contrario de por ejemplo ISO-9001 que sí emite certificados que pueden enmarcarse o presentarse. Podemos leer en las páginas del SEI:
- SEI no certifica los resultados de niveles de madurez de ninguna evaluación
- SEI no certifica organizaciones. SEI solo licencia a consultores asociados para realizar evaluaciones. Ni SEI ni ninguna otra organización es una autoridad de certificación de los resultados de estas evaluaciones.
CMMi es responsabilidad del SEI, y no emite certificaciones. Lo que sí es posible es que se emita un informe por parte del consultor evaluador o de la empresa certificadora, justificando el alcance y resultados. Pero nada más.

CMMi no asegura la calidad.
Siguiendo el hilo del anterior, el haber pasado un SCAMPI y obtener el nivel de madurez tal o cual, no asegura nada. Por eso no pueden publicarse como “certificados”. La evaluación CMMi es para la empresa, para que sea consciente de su estado de madurez en las condiciones establecidas. Pero no garantiza nada, ni el SEI ni la consultura que hace la evaluación, se hacen responsables de la calidad de los productos (salvo la propia empresa evaluada).