Caso de éxito Tagus y cómo trabaja Autentia

Tu puedes decir lo buenas que son las metodologías ágiles, lo bien que crees que lo haces, pero yo creo que no hay nada mejor en esta vida, como que sean tus clientes los que lo digan, y más cuando son organizaciones y proyectos de relevancia.

Este primer caso de éxito se lo debemos agradecer a Casa del Libro. Gracias por su confianza y colaboración.

Gracias también a David Bonilla (@bonillaware), el reportero más dicharachero del agilismo. Sabía que no nos equivocábamos cuando le confiamos este trabajo.

Ya se cuentan por años los momentos en los que nos decidimos a implantar las metodologías ágiles en Autentia y desde entonces todo han sido alegrías. Los proyectos simplemente fluyen. Las sorpresas han «casi» desaparecido y hemos ganado lo que yo llamo «elasticidad».

En contra de lo que la gente se piensa, trabajar de un modo ágil, requiere mucha más disciplina que un método entendido como «tradicional». Hay una tensión mucho más homogénea desde el principio del proyecto lo que evita picos y prisas al final.

Los equipos tienen que estar motivados y formados para que esto funcione. Todo es más transparente: la mediocridad se ve y la excelencia brilla.

Cuando alguien me pregunta como trabajamos, lo suelo describir como lo haré ahora (en el caso de proyectos completos). El marco de referencia es Scrum para desarrollos previstos (por favor, que nadie me diga si esto es puro Scrum o no).

Seguro que me dejo cosas, es sólo para que os hagáis una idea. Ser ágil es adaptarse al entorno, pero con un marco de referencia de partida:

<br/

FASE DE OFERTA

————————–

– Un cliente nos llama para describirnos un proyecto, con un alcance normalmente muy grande. Esto es por la cultura de pedir: que me hagan lo máximo posible por el mínimo coste.

– En fase de oferta, con Google Docs escribimos una definición de las historias del proyecto (parecido a los casos de uso de toda la vida centrados en el actor). Es la pila del producto. Lo compartimos con ellos para tener solo un documento de trabajo válido. Lo que no está en ese documento no existe. Si no se prestan a colaborar definiendo mejor el proyecto, embarcarse en él no parece tener mucho sentido: ¡si es para ellos!.

– Procuramos hacer unos mockups (simulaciones pintadas como a mano alzada) de las pantallas involucradas en las historias para asegurarnos que entendemos lo que el cliente nos quiere decir. Siempre es mejor hablar alrededor de un tangible.

– Nos llevamos los títulos de las historias a una herramienta de gestión ágil llamada Pivotal Tracker (aunque estas cosas cambian en base al cliente). En ella, el equipo técnico, que luego tendría que hacer el proyecto, estima estas historias en base a 8 niveles de complejidad relativa entre ellas (del 1 al 8). Si hay algunas historias «épicas», que superan esa complejidad relativa, las tratamos de definir mejor y dividir en historias normales. Damos acceso a los clientes a su proyecto para que participen en la medida que lo deseen.

– En base a las estadísticas de los últimos proyectos terminados, hacemos la prueba de la estimación. Es decir, dividimos los puntos de estimación total de esos últimos proyectos entre el número de historias. Esto nos dará la complejidad media por historia estadísticamente. Póngase que sale 3 y pico.

– Multiplicamos las historias del proyecto en curso por esa complejidad. Si lo que nos sale en las dos estimaciones (estimando una a una y estadísticamente) es parecida, significa que no parece haber cosas raras (respecto a la norma). Luego uno de los socios también da una tercera opinión completamente subjetiva, sobre todo para estimar riesgos generales. Más sabe el diablo por viejo …

– Sabiendo los puntos de historia que una pareja de Autentia desarrolla de media, decimos al cliente los Sprints que tiene el proyecto (normalmente ciclos de 2 semanas) y por lo tanto el coste en base a nuestras tarifas estándar.

– Como normalmente el cliente ha metido todos los «deseables» dentro de la estimación del proyecto normalmente sale un coste más elevado del que tenían pensado.

– El cliente sensato empieza a cambiar la actitud y, siendo consciente que el método no tiene ni trampa ni cartón (como mucho pueden existir dudas de si se pueden desarrollar más puntos o menos en un Sprint pero el número gordo es el número gordo), si quiere que tenga un coste y plazo de entrega aceptable en una primera fase, tiene que acotar el número de historias, por lo tanto de Sprints (el coste) y priorizar con criterio.

– Cuando tenemos el proyecto más acotado, le damos al cliente una oferta con el alcance fijo de esas historias, el tiempo y el coste y asumimos el compromiso de desarrollar todas esas historias de un modo ágil, con entregas cada 2 semanas. Es más, asumimos el compromiso de intentar hacer más historias de las comprometidas inicialmente.

– Incluso les damos la opción de que introduzcan una persona en el proyecto: no es el cliente sino un programador más. Nosotros le formamos por lo que inicialmente nuestro rendimiento será más bajo pero luego tendremos más manos. No tenemos nada que ocultar sobre cómo trabajamos ni qué recursos dedicamos.

– El cliente normalmente pide presupuestos a más empresas y lo más habitual es que otras empresas digan que van a tener más gente trabajando y que se hayan preocupado bastante menos por lo que entra y no entra en el proyecto. Unas veces dan presupuestos muchos más caros y otras más baratos.

– Algunos clientes nos contratan y otros no. Pero también es una cosa verdad, muchos de los que no nos contratan inicialmente acaban volviéndonos a llamar. Cuando tienen roces, retrasos continuos, poca calidad, ninguna transparencia, tests automáticos inexistentes, nulas métricas de código .. recuerdan las advertencias que les dimos.

FASE DE EJECUCIÓN

——————————-

– Trabajamos en base a Sprints de 2 semanas con poca gente inicialmente y alguna más a mitad del proyecto. Si los procesos administrativos del cliente son largos, los ciclos son de 3 semanas para que nos puedan seguir.

– Todos los participantes son conocedores de la oferta: saben lo que hay que hacer y el tiempo para hacerlo, que está muy justo para ser competitivos.

– Un lunes por la mañana se realizan las reuniones de planificación donde se concretan las historias. El cliente debe traer los deberes hechos sobre las historias a discutir y alguna más de reserva. Se estiman de nuevo: el equipo tiene que aprender a ajustar las estimaciones y asumir su responsabilidad. Todos tendemos a subir y bajar el ritmo de nuestro trabajo para cumplir nuestros compromisos. Pero hay que recordar que se trabajan 8 horas y si un día se trabaja más, otro se debe trabajar menos.

– En cada ciclo hay que mejorar la velocidad y no ser conformistas. Además, como las historias están solo a medio definir, pueden saltar sorpresas. Mejor ir deprisa desde el principio.

– Las paredes tienen que estar pobladas de post-it y de gráficas de evolución al día, sobre todo si se está en casa de un cliente que no estén acostumbrados a métodos ágiles.

– Todos los días el equipo se reúne a las 11 de la mañana (o cualquier otra hora que convenga) con un tiempo acotado (time-boxing) para contar qué hizo el día anterior y qué va a hacer ese. No se discuten soluciones, eso se puede hacer luego.

– Todo el mundo trabaja con tres niveles claramente marcados: gestión de la configuración, metodología y arquitectura.

– La arquitectura del proyecto no la pueden decidir los miembros del proyecto por si mismos. Tienen que discutirla con otros compañeros no involucrados con el proyecto y convencerles: juicio de pares.

– No se programa lo que no se necesita: hay herramientas de generación de informes, programación de tareas, ETL, ESBs, BPM, gestión de contenidos, portales y miles de librerías de uso común que pueden darnos una base. Si las descartamos es porque las conocemos no porque las desconocemos. A los compañeros que las conocen mejor que nosotros hay que preguntarles pros y contras.

– No se improvisa ni se hacen experimentos descontrolados con tecnologías. Hay una estrategia global de innovación que tiene que sumar al conocimiento del colectivo.

– Se procura que en cada proyecto los riesgos técnicos, por meter una pieza nueva, sean acotados. Se pueden aprender muchas cosas pero se tiene que probar una a la vez: no sobre-tecnifiquemos.

– Lo último no es siempre lo mejor: no debemos inyectar a los clientes riesgos para cubrir nuestra necesidad de sentir que estamos con la beta de anoche.

– Hay que generar tutoriales con los avances no particulares de ese cliente y documentar en un wiki las cosas particulares. Los compañeros deben conocer qué sabes por si tienen ellos que hacer cosas parecidas. El conocimiento es demasiado amplio y profundo. Si no sabes quien sabe, llama al jefe que el sí suele saber qué se usó en cada sitio.

– Para desarrollar/diseñar se utiliza TDD. Al final del proyecto tiene que haber cientos/miles de test automáticos para lo que se usa junit, mockito y otras herramientas.

– Se utiliza un repositorio, los proyectos están «mavenizados» y está configurada la integración continua. Juegas con una red que te dice si haciendo una cosa rompes otra.

– Sonar va sacando los informes de calidad de software y fundamentalmente importan 3 indicadores inicialmente: porcentaje de código duplicado, porcentaje de código cubierto por pruebas automáticas y números de errores de cada nivel de severidad.

– Al final de cada Sprint, el segundo viernes, se hacen las demostraciones a las historias y se cierran las aceptadas completamente. Se registran los fallos/cambios para corregirlos en el ciclo del proyecto. El equipo aprende tanto técnicamente como de las preferencias del usuario desde el principio, lo que evita sorpresas al final.

– Se hace una retrospectiva del proyecto a nivel de empresa e incluso, dependiendo de la velocidad y riesgos, se deja tiempo para taller: mejorar la técnica del equipo.

– Pivotal Tracker va cantando la velocidad del desarrollo. Si no mides no gestionas. Las historias nuevas que van apareciendo se van añadiendo al IceBox. Si no gestionas luego hay sorpresas con el alcance: transparencia.

– Si la velocidad está siendo mayor de lo esperada, algunas historias adicionales y cómodas de construir en el Sprint en curso se llegan a incorporar. Si la velocidad es baja, tendrán que esperar para otra fase. No es cuestión de ver quién engaña más a quién sino de dar el máximo flujo de valor continuo mientras dure el proyecto.

– El personal de Autentia es todo de plantilla. Están acostumbrados a trabajar juntos. Unos tienen más nivel que otros. Unos saben más que otros, esto es normal. Somos personas únicas con diferentes grados de experiencia para que los costes sean razonables. Desde hace años, a todos les ha costado demostrar su valía en el proceso de selección para entrar en la empresa.

– Programan por parejas periódicamente para realizar una transferencia de conocimiento según trabajan.

– Está prohibido atascarse: hay muchos compañeros que saben, en la oficina o a una llamada de distancia. Es incluso mejor que una persona que no está en el proyecto y sepa hacer algo necesario, que se incorpore puntualmente y haga/enseñe a hacer una cosa específica. Los clientes se sorprenden por ver caras nuevas.

– Si no hay tráfico de conocimiento entre proyectos ¿somos una empresa o simplemente un grupo de personas que ocasionalmente se juntan para hacer un trabajo? ¿qué más da entonces de qué empresa fueran?

– Si alguna vez nos equivocamos en una estimación, que puede pasar, otra persona de otro proyecto de I+D, en fase inicial o con buena velocidad puede incorporarse al retrasado porque hay que procurar cumplir compromisos. Que trabajen más horas no remuneradas los miembros del proyecto no es la solución: ni práctica ni ética. Somos muchos y con una línea de conocimiento común: Spring, hibernare, jQuery, JSF, JPA, Seam, etc. es fácil mover gente.

– Sólo trabajamos en lo que sabemos de verdad: frameworks/herramientas Java, no hacemos de todo. Como muchos nos extendemos a desarrollos en dispositivos móviles iPhone/iPad o C++ para hacer extensiones del núcleo principal.

¿Acaso esperabais una explicación corta y sencilla? Trabajar así, con grupo de más de 20 personas, lleva años (es que hacerlo tu solo como que tiene menos gracia).

También os digo la verdad, gente que entra en esta dinámica ya construida en pocos meses tiene un rendimiento espectacular.

¿Todo es tan bonito y sale siempre perfecto? Pues no. Las profesiones intelectuales se basan en personas y sus interacciones. No somos robots pero tenemos voluntad de mejorar. Incluso no a todo el mundo le gusta esta «factorizacion del trabajo» y prefiere más la libertad individual de hacer las cosas a su manera.

Para gente de negocio

——————————

Todo esto puede haber tenido sentido para los técnicos, pero puede haber significado poco para la gente de negocio que necesita un resumen ejecutivo y puede no haber llegado hasta aquí.

Hay una explicación inequívoca: en estos momentos de crisis tenemos a clientes contentos y vamos a cerrar el año 2011 siendo económicamente el mejor de nuestra historia tanto en facturación como en beneficios.

Nuestra competencia no es el que trabaja así de bien, que hay muy pocos. Nuestra competencia es el que trabaja muy mal, tira el mercado y degrada el valor del sector quitando importancia a la profesionalidad. El consuelo es que somos pocos y solo necesitamos unos pocos clientes al año que sepan qué y cómo lo quieren 🙂

¿Todavía os quedan algunas dudas? Siempre las podéis preguntar. Ya sabéis que somos fáciles de encontrar tanto aquí como en ferias del sector…

Enlaces de interes:

• Saber más de @rcanalesmora …