La metodología ágil de Okkum

puenteHemos crecido profesionalmente rodeados de metodologías complejas que no nos han gustado, que hemos visto como reducían nuestra productividad sin un claro beneficio, al menos en equipos pequeños. Hemos visto nacer y expandirse a los procesos ágiles de desarrollo con cierto escepticismo. Hay metodologías para todos los gustos. En muchos casos el éxito de una empresa depende de trabajar con esa metodología que la hace diferente.

En este apunte Joel Spolsky comenta como las metodologías limitan el talento y como ello impide crear empresas talentosas de tecnología (o de cualquier otro tipo) de gran tamaño. El proceso que se sigue al programar es importante, es imprescindible tener una forma de trabajo consistente con los objetivos de la empresa y la cultura de la misma ¿Entonces es posible importar la metodología de otros en nuestra empresa? Pues en mi opinión no. Las grandes mentiras que nos enseñan en la universidad son:

  • Podemos controlar la variabilidad de los proyectos capturando perfectamente los requisitos funcionales.
  • Existen arquitectos, aparejadores y peones en el software.
  • El talento se puede trasmitir.
  • El talento lo soluciona todo.

La primera se ha debatido ampliamente en los últimos años y esta discusión ha dado como fruto las metodologías ágiles.

El segundo ha creado una separación inexistente entre los programadores, los analistas y los arquitectos, evidentemente dentro de un proyecto hay diferentes grados de responsabilidad sobre el éxito del mismo y para poder asumir mayor responsabilidad se requiere de mayores conocimientos, pero esto no implica que la naturaleza de muchas tareas a la hora de desarrollar software no sean similares para todos. Nadie puede diseñar una buena aplicación si no ve el código, si no conoce las pequeñas vicisitudes de la plataforma con la que trabaja, de la arquitectura que resultará del proyecto. Ningún ingeniero de caminos podrá hacer una carretera sin entender como se hace un plano, sin entender como se fabrican los materiales y como es el proceso de construcción.

El talento no se aprende, pero el trabajo sustituye al talento en el 95% de las tareas. Así que en una empresa es imprescindible el currante y es deseable el crack. Un programador excelente podrá marcar la diferencia con un producto, pero si no hay un equipo de grandes currantes no pasará de ser una gran idea (Silvio Rodríguez dice: los amores cobardes no llegan a amores).

Pero la más grande de las mentiras es decir que los requisitos son los planos del proyecto. Construir la carretera es instalar la aplicación en un servidor, ordenador, dispositivo, …, los planos es el proceso de crear el software, cada una de sus funcionalidades, documentación, APIs, etc. El paso a producción es la construcción, lo anterior es el plano.

Tal vez no estés de acuerdo con esta concepción y posiblemente sea porque cuesta entender que el mismo plano lo puedas usar cientos, miles o millones de veces. A los ingenieros les encantaría usar mil veces el diseño del mismo puente, pero los ríos no tienen la misma flexibilidad que los bits.

Un ingeniero, tiene a un delineante que dibuja el plano a partir de un esbozo suyo, varias reuniones y cientos de correcciones. Además un biólogo o un licenciado en ciencias ambientales, hará un estudio del impacto ambiental y un calculista, de la resistencia de los materiales, tal vez un arquitecto, si es una gran obra civil, revise criterios de usabilidad y estética. Cada uno de ellos realiza un trabajo muy libre bajo la supervisión y colaboración del director de proyecto.

Hemos implantado una forma de trabajo similar, tenemos un director de proyecto, que realiza un esbozo, trata con el cliente, supervisa el avance del proyecto y resuelve los atascos en el proceso; un equipo de desarrollo (delineantes) que traducen el esbozo a código fuente y una diseñadora gráfica que crea las interfaces con el usuario según sus características y el uso que hará de la aplicación. Y vamos incorporando roles nuevos a medida que crecemos y aprendemos.

Nuestra metodología de trabajo, se basa en la comunicación y en fijar puntos intermedios frecuentes en los que se revisa, primero internamente y después con el cliente, el avance del proyecto. Bebemos de fuentes como la Feature Driving Development, Scrum o RUP. Sobretodo hemos bebido del modelo de desarrollo de los grandes proyectos Open Source. Pero lo hemos adaptado a nuestro tamaño de empresa, a nuestro modo de ver el software y a nuestro carácter.

Anuncios

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