h1

Sobre “ágil”, gestión de riesgo tradicional y estimaciones

09/28/2011

Wizdoc [Icon By Buuf]  Tips & Tricks.

Este amigo que conozco, en su primera cita siempre anuncia su fecha de matrimonio, el número de niños que su esposa tendrá, su fecha de nacimiento… su nombre es Planificador de Proyectos Tradicional.

— Venkat Subramaniam, programador y autor Indio-Estadounidense. Vía Twitter

Hace poco menos de un año se desarrolló la quinta versión del “estado del desarrollo ágil“, patrocinado por VersionOne, una empresa dedicada a software de gestión de proyectos ágiles. Dicho estudio consistió en realizar una serie de preguntas a un público relativamente amplio de 4,770 participantes localizados en 91 países alrededor del mundo. Como resultado del trabajo, se encontraron una serie de tendencias referentes al uso de las metodologías ágiles, la motivación para emplearlas, así como los mayores retos que puede encontrarse un equipo que desea incursionar en XP, Scrum o alguno de los otros “sabores” existentes. Aunque el documento no es muy extenso pues en términos generales se limita a presentar una serie de gráficas, sí nos da una buena idea de los porqués y los cómos de esta manera de desarrollar software.

Son tres gráficas las que me parecieron las más significativas del documento:

• La primera consistió en definir cuál es la metodología ágil de mayor uso. La respuesta: el 58% de los equipos de desarrollo utiliza Scrum “puro”, mientras 17% emplea un híbrido entre Scrum y Extreme Programming; apenas un 3% utiliza Scrumban. Esto nos da un total de 78% o poco más de las tres cuartas partes de los equipos ágiles alrededor del mundo usando Scrum o algún híbrido de éste con otra metodología ágil de desarrollo de software.

Agile methodologies employed @ State of Agile Development 2010

Porcentaje de uso para metodologías ágiles. (Fuente: VersionOne)

• La segunda, relativa a las causas principales por las que fallan los proyectos ágiles. De acuerdo al reporte, 78% de los encuestados falló en alguna ocasión, siendo las tres principales causas la falta de experiencia con métodos ágiles (14%), la cultura o filosofía de la compañía contraponiéndose a los valores ágiles (11%) y una presión externa por seguir prácticas de cascada tradicionales (10%). Esto es muy significativo, pues indica que una buena parte de los proyectos falla debido a que upper management se niega a seguir los valores ágiles, prefiriendo utilizar el obsoleto modelo de cascada que bien sabemos, no funciona del todo.

• Finalmente, la principal preocupación de la gerencia al adoptar una metodología ágil. Las principales razones son pérdida del control administrativo (36% de los encuestados lo considera la mayor preocupación), eliminación de la planeación desde un principio (33% de los encuestados) y la oposición de la gerencia al cambio (32% de los encuestados). Es decir, los “patrones” se sienten incómodos si no ejercen el poder absoluto sobre quién debe hacer qué y resulta impensable ejecutar un proyecto que no tenga un plan de trabajo definido desde un inicio.

Las últimas dos estadísticas nos indican que las metodologías ágiles sí funcionan, siempre y cuando exista un seguimiento activo y no intrusivo por parte de la administración. Incluso en el mismo documento se mencionan los principales beneficios obtenidos por dicha implementación: mejora en la gestión de prioridades cambiantes (46% de los encuestados lo consideran como una mejora significativa), la visibilidad del proyecto (39% de los encuestados) y una mayor alineación entre IT y negocio (28% de los encuestados).

¿A que le temen?

Partiendo de este análisis, surge una interesante pregunta: ¿Por qué muchas empresas le tienen miedo a “ágil”? Si está demostrado que el uso correcto de estas metodologías incrementa muchísimo la calidad del software desarrollado y se entrega el valor de negocio que el cliente pide… ¿No deberían de hecho, optar por esta opción? Aunque la aversión al cambio tiene mucho que ver, la realidad es que le tienen pavor al riesgo, y creen que al tener un plan de trabajo “escrito en piedra” lo están mitigando activamente. Eso por supuesto, se encuentra completamente fuera de la realidad. Mike Cottmeyer, socio consultor y coach ágil de LeadingAgile, menciona en su blog:

[Para un esquema de autorización/autenticación basado en LDAP]



Terminamos trayendo una empresa de consultoría grande para ayudarnos… eran muy, muy buenos pero como era de esperarse, también eran muy caros. Decidí negociar un contrato con alcance fijo, precio fijo; bajo la suposición de que mitigaría mi riesgo. El objetivo era transferir el riesgo del desarrollo a la consultoría para que yo me asegurara de entregar mi proyecto en tiempo y presupuesto. De haber tenido un perfecto conocimiento de lo que era requerido, ésta podría haber sido una buena estrategia.

Como habrán deducido, estos amigos sabían mucho más acerca de contratos y cómo implementar soluciones LDAP que yo. Imagino que se anticiparon a la necesidad de servicios no especificados en el contrato, pero también sabían que no podía excederme en presupuesto y estoy seguro que ellos deseaban hacer negocios. Cuando lo inevitable sucedió y nos dimos cuenta que requeríamos servicios no especificados en el acuerdo original, ellos crearon un documento de control de cambios… en realidad muchos de ellos… por lo que tuve que reunir fondos adicionales para realizar el trabajo extra.

Mientras yo fallaba al intentar mitigar mi riesgo con un contrato de precio fijo, alcance fijo, tiempo fijo, ellos tenían éxito mitigando su riesgo al tener una gestión de contratos muy agresiva, dejándome como responsable por cualquier cosa que no estuviese explícitamente descrita en nuestro acuerdo original. Al final del día, ¿quién absorbió el riesgo? Fuimos yo y mi compañía, sólo que no lo sabía en el momento porque estaba seguro de que había solicitado todo lo que necesitaba desde un inicio. No fue sino hasta que empezamos con la construcción de la solución que me di cuenta que estaba equivocado.

— Mike Cottmeyer, Who Owns the Risk?, leadingagile.com.

Así pues, en un proyecto complejo de ingeniería de software es muy poco probable que un estimado inicial sea 100% certero. Por ello muchos deliveries presentan desviaciones en su presupuesto, tiempo o alcance: por sencillos que parezcan, muchos requerimientos no consideran todas y cada una de las tareas necesarias para su completa implementación. Adicionalmente, la gran mayoría de los clientes cambia los requerimientos o las prioridades sobre la marcha. Y esto nos lleva de nueva cuenta a un plan de trabajo y estimación de tareas que en algunos casos, son incluso considerados una pérdida de tiempo: si al realizar el esfuerzo de estimación siempre obtenemos un plan de trabajo que se desviará del 50 al 100% sobre el estimado, ¿por qué perdemos nuestro tiempo desde un principio? Michael Dudakov, del Agile Development Blog nos proporciona cinco razones por las que deberíamos dejar de estimar historias de usuario (o casos de uso, o puntos de función según sea el caso):

1. No perderemos el tiempo estimando.

2. No tendremos que explicarle a upper management por qué estamos tardando tanto – Enfocándonos mejor en explicar los problemas y cómo los solucionaremos en vez de comparar contra un estimado.

3. No haremos promesas que no podremos cumplir – De todas formas, nadie cree en los estimados de un “técnico”.

4. No pondremos presión adicional sobre el equipo de trabajo.

5. Nos enfocaremos en lo verdaderamente importante – Entregar lo que sea más importante de acuerdo al cliente o product owner.

Aunque es algo divertido, es ingenuo pensar en que podemos desechar la estimación, ya que muchos proyectos, especialmente aquellos que son desarrollados por empresas de consultoría, son aceptados o rechazados en base al costo y tiempo que tomarán en ser completados. Por ello, metodologías como Scrum no utilizan medidas discretas como horas o puntos de función para estimar el tiempo que llevará realizar un entregable, sino que se basan en “niveles de esfuerzo” representados de manera abstracta. Por ejemplo (y no me lo estoy inventando), razas de perros donde un Chihuahua significa algo sencillo mientras un San Bernardo es algo muy complicado. Esto permitirá en base a las primeras iteraciones encontrar la velocidad a la que se mueve un equipo: por ejemplo, por cada iteración se puede entregar el equivalente a cinco Chihuahuas, dos Pastores Alemanes y un San Bernardo. Así, conforme el equipo madure, la estimación será cada vez más precisa.

Planning poker cards

Un mazo de cartas del planning poker, usando los números de Fibonacci para definir el esfuerzo necesario al implementar historias de usuario. La carta “0” significa un esfuerzo de algunos minutos, mientras “13” podría significar “un par de semanas por dos integrantes del equipo”. La carta comodín (“?”) Significa “no tengo idea de cuánto pueda llevar” y se utiliza para definir investigación o pruebas de concepto. La taza de café significa “dejemos esto para después” y la carta infinito (“∞”) significa un impedimento que el equipo no puede resolver. Las cartas con los números 21, 34 o 55 no deberían usarse con regularidad, pues implican mayores esfuerzos que deberían desmenuzarse en tareas más pequeñas. (Fuente: gedpro.com)

Si después de todo esto el cliente necesariamente requiere de un plan de trabajo y estimación iniciales, podremos hacerlo apoyándonos en un líder técnico o arquitecto que sepa de lo que está hablando; agregamos un porcentaje de riesgo de acuerdo a la dificultad que presente el proyecto (entre el 15% y el 33%) y amarramos todo esto en un bonito contrato que defina un duro control de cambios, donde tan sólo agregar un acento implique que el cliente deba pagar por ello.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: