User profile page

Ágil es una palabra de moda en el mundo del desarrollo de software si bien, esta metodología como tal, no viene diciendo nada nuevo.

Varios evangelistas y gurús se han alzado como portadores de esta “nueva” manera de construir software y diversas técnicas han surgido al rededor de este movimiento (con certificaciones y todo), afirmando ser la solución para todos los males.
En mi humilde opinión todo esto es (o debiera ser) mucho más simple.

Este es el primero de una serie de posts que voy a escribir a cerca de cómo entiendo la metodología ágil para el desarrollo de software.

Quiero dejar claro que no me considero ningún evangelista, ni ningún gurú, pero considero que puede resultar interesante y que cojones, me gusta hablar del tema

Todo este buzz de desarrollo ágil viene inspirado por este manifiesto:

• Valorar más a los individuos y su interacción que a los procesos y las herramientas
• Valorar más el software que funciona que la documentación exhaustiva
• Valorar más la colaboración con el cliente que la negociación contractual
• Valorar más la respuesta al cambio que el seguimiento de un plan

Lo cual fue tan revolucionario porque se da de lleno con las prácticas habituales en el desarrollo de software.

Recuerdo poco antes de salir de la universidad, cuando comencé a hacer prácticas para sacarme de encima esos créditos de libre configuración, que me llevé un severo desencanto en lo referente a mi futura profesión.
No había nada de planificación, todo se hacía deprisa y corriendo. A nosotros los becarios nos dejaban a nuestro libre albedrío, con poco más que un manual de actuación, unas pocas charlas sobre lo que necesitaban y una máquina para trabajar.
Ah!, y todo tenía que estar listo en 2 semanas.
No importaba como, no importaba la calidad y sobre todo no importaban las personas. Si te tenías que quedar haciendo horas extra (siendo becário!!!) pues te quedabas y punto.

A lo que voy es que generalmente, las llamadas “Empresas de Consultoría de Software”, en la mayoría de los casos no entendían el Software. Eran expertos en hacer dinero con el software (habitualmente subcontratando personal) dando lugar al llamado “Mercado de Carne“, en donde no importa lo que hagas, ni si estás bien o no. Lo único que importa es la diferencia entre:

a) El dinero en el que podamos venderte
y
b) El dinero que te damos a ti.

Si a - b es lo suficientemente lucrativo, entonces te contrataban. Si no entonces es que no habías pasado las pruebas psicotécnicas y demás…

Podría contar mil historias relacionadas con el mercado de carne madrileño, pero no viene al cuento.

Lo importante es que la llamada “revolución ágil” hacía una llamada al cambio.

Las personas son más importantes que los procesos y las herramientas.

Hazle entender esto a cualquier jefe de proyecto de la consultora Fulanez…

Ágil significa que un equipo de desarrollo de software, es el principal activo y como tal, las personas que conforman dicho equipo son lo primero. Todo lo demás viene a consecuencia de dichas personas. Y eso creo que nunca será suficientemente matizado:

Los programadores programan!

Si tu compañía vende “código”, ya sea en forma de servicios o de productos o de lo que sea… cuida de la gente que genera ese código.
Tiene sentido no?

Como ya escribí anteriormente, es difícil enseñarle trucos nuevos a un perro viejo, y es que como se suele decir “bad habits die hard”

En grandes compañías de software hay toda una serie de jerarquías, estándares y procedimientos establecidos que, en mi opinión, sólo sirven para mantener las cosas a raya.

Si nos abstraemos un poco y nos enfocamos en lo que es la estructura a nivel de corporación, es difícil percibir la diferencia entre una compañía que genera sofware y otra que vende lavadoras.
Y esto no sería grave si el software fuera como una lavadora, pero afortunadamente no lo es.

Según lo veo yo, el software es algo vivo. Algo que uno crea pero que, llegado el momento, cobra vida propia y comienza a demandar cosas en las que jamás habríamos pensado inicialmente. Y lo genial del Software es que podemos proveer soporte para esas necesidades de manera relativamente sencilla!
Una lavadora podrá tener más o menos programas, pero no dejará de ser una lavadora.

Esta diferencia fundamental radica que el software es, por así decirlo, un “producto” que reside más en el plano de las ideas, que en el plano físico, y tratar de controlar este tipo de productos usando viejas metodologías bien conocidas en otras industrias, en mi humilde opinión es un craso error.

Os diré qué es el infierno para mi:

• Programar algo usando especificaciones escritas en piedra.
• No poder mostrar tu trabajo al cliente a medida que lo desarrollas para saber si es eso lo que quiere.
• Después de haber trabajado en algo durante meses, que el jefe de turno me diga que hay que tomar otra alternativa.
• No poder avanzar en un proyecto porque “los jefes y el cliente” se encuentran discutiendo re-negociando los términos del contrato.
• No poder programar algo chulo y que sé que le va a proporcionar valor agregado al cliente, porque no se encuentra en el documento de especificación.
• Asistir a aburridas reuniones en las que los “los jefes y el cliente” se la pasan discutiendo quién tiene la culpa del retraso en el proyecto.
• Que el manager de turno nos diga que tenemos que trabajar más horas porque “vamos” con retraso.
• Tener que llevar traje y corbata al trabajo

Si alguno de vosotros ha trabajado en un proyecto de este estilo seguro que entiende a lo que me refiero, los que no… no importa como trate de explicarlo, nunca podré llegar a expresar con palabras el estrés y sobre todo la frustración que eso genera.

Por qué uso una metodología ágil?

• Puedo participar en el diseño de manera directa, dando mi opinión y modelando las tareas que van a terminar dando forma al proyecto.
• No más Proveedores vs Clientes. Prefiero Proveedores + Clientes, mucho mejor.
• Puedo enseñar periódicamente lo que estoy haciendo al cliente, de manera que él puede decidir si vamos por el buen camino o no, y sobre todo, puede inspirarse y darse cuenta de lo que realmente quiere.
• Si la cosa no funciona, si hemos escogido un camino que resulta no ser el bueno, es mejor caer cuanto antes (el principio “fail fast”). Si lo que estoy haciendo no es lo que el cliente quiere, prefiero haber gastado una semana a varios meses de trabajo.
• Prefiero pactar un número de iteraciones con el cliente, que un contrato escrito en piedra y lleno de cláusulas. Si mi trabajo gusta a mi cliente, y si ve el avance en el proyecto, acordamos más iteraciones. Si no, es mejor buscar otro proyecto u otro cliente, que establecer una relación de “te odio pero te necesito”.
• Puedo colaborar con un cliente ofreciéndole ideas y opciones en las que él no había pensado y enseñárselas en un pequeño demo. Si le sirve y si le gusta, podemos pasar esas ideas a la lista de cosas que hacer en sucesivas iteraciones.
• Mi cliente puede usar su producto, aquello por lo que está pagando, desde el primer momento! Y creo que esto, desde el punto de vista de alguien que está invirtiendo un montón de dinero en algo es fundamental.
  Ofrecer la posibilidad de “jugar” con el producto a mi cliente desde el final de la primera iteración y desde ese momento recibir su feedback, es algo impagable.

El desarrollo ágil ofrece diversas técnicas para llevar a cabo estas y muchas otras prácticas, generando unos resultados bastante menos estresantes, menos frustrantes y sobre todo más divertidos y con el tiempo iré contándoos las que yo uso para trabajar.

Escrito por Cal Henderson, uno de los creadores de Flickr (una de mis aplicaciones web favoritas), este libro es una verdadera joya para cualquiera que se dedique a hacer cualquier cosa relacionada con la web.
Ya seas un diseñador, un programador o un arquitecto, manager, etc… Este es uno de los libros que deben ser de obligada lectura, ya que nos da una visión bastante global y acertada de lo que es una aplicación web.

En lo personal lamento no haber leído este libro antes, creo que es una fuente de “terrorífica” inspiración. Y digo terrorífica porque cuando realmente descubres todo lo que late bajo una aplicación web, las cosas que se deben tener en consideración y los diversos factores a tener en cuanta de cara a “escalar” tu website, puede llegar a dar vértigo.

Este libro me ha ayudado a re-descubrir cosas que pensaba obvias, y que en la practica resultan no serlo tanto. Y sobre me ha ayudado a robustecer ciertos aspectos de mis aplicaciones a la hora de dar el salto del entorno de desarrollo a un entorno de producción real.

Una gran fuente de inspiración, técnicas y trucos que recomiendo sin duda alguna.

El viernes pasado se celebró el día del programador. No es que hubieran grandes desfiles por las calles pero al menos es bueno saber que hay un día del calendario dedicado a nosotros.
Para celebrarlo la rama estudiantil IEEE de la Universidad Tecnológica de Panamá organizó una serie de charlas, talleres y concursos bastante interesantes a los cuales asistí.
En general me gustó el evento, se habló de varias cosas interesantes, en especial me gustó la charla sobre Grails dictada por Gerardo Núñez, si bien Grails como tal no me acaba de convencer del todo, y la charla sobre desarrollo ágil dictada por Stephan.

Gerardo dando a conocer las bondades de Grails

Stephan practicando algo de terrorismo mental con los estudiantes

También hubo un curioso concurso de programación donde había que resolver diversos problemas usando varios lenguajes que me trajo varios recuerdos de mis días universitarios….

En general me gustó ver que hay interés en aprender cosas nuevas, no sólo lo que se enseña en la universidad, y particularmente me llamó la atención ver la enorme presencia que las corporaciones como Microsoft y Cisco tienen en las universidades de aquí, imagino que invierten bastante dinero en mantener a los estudiantes “adoctrinados”.

Sea como sea me gustó el evento y me invitaron a participar como expositor para la próxima reunión que vayan a organizar para hablar de Rails y TDD.

Va a ser divertido

El viernes Caimito Technologies lanzó al aire la versión de evaluación de Caimito One Team.

Es un proceso curioso ver evolucionar una idea a través del tiempo, y finalmente darla a conocer al gran público, y como colaborador indirecto debo decir que es emocionante.

El momento en el que esa idea, producto, etc salta de esa especie de Sandbox que es tu entorno de desarrollo, ese lugar “seguro” donde puedes jugar a tu antojo con los diversos aspectos de la aplicación a un entorno real, siempre produce cierto cosquilleo.

Qué es One Team? Podríamos definirlo como una herramienta que ayuda a los equipos de desarrollo ágil a trabajar de manera deslocalizada en un entorno que provee soporte para las diversas prácticas ágiles.
Lo más curioso es que One Team se ha desarrollado usando One Team! (siguiendo el principio de “Eat your own dog food”), de manera que a lo largo de las diversas etapas de su desarrollo, los programadores han sufrido “en sus carnes” las carencias del producto y las han refinado hasta producir una herramienta bastante potente en mi opinión.

One Team ayuda a los equipos ágiles a mantenerse ágiles, y ayuda a aquellos equipos que quieren librarse del lastre de la cascada, a dar sus primeros pasos hacia el desarrollo en iteraciones (AKA Programar como dios manda )

Desde aquí os recomiendo que si tenéis la oportunidad os descarguéis la versión de evaluación y lo probéis. Y sobre todo, no os cortéis en enviar el feedback que consideréis oportuno. El objetivo es crear una herramienta que resulte útil a los programadores y que realmente ayude a trabajar mejor.

Ayer tuve una llamada de una persona interesada en hablar conmigo para formar parte de un proyecto que tienen en mente.
No tengo muchos detalles del proyecto y tampoco es el punto de este post, es solo que hubo algo en la conversación que me llamó la atención y es que esta persona, antes de “poder” hablarme de los detalles de su proyecto quería que firmara una declaración de confidencialidad.

En un principio me pareció razonable que alguien ilusionado con su proyecto quisiera “proteger” su idea mediante algún tipo de documento legal o algo así, a fin de cuentas la competencia es competencia. Pero como la cosa quedó pospuesta para otro día no tuve que dar ninguna respuesta inmediata.
Pensándolo con más calma y hablándolo me dí cuenta de que tratar de proteger una idea en el mercado de software es absurdo, porque una idea, de por sí, no tiene ningún valor.
Comunidades sociales, o aplicaciones web las hay a patadas, muchas similares, otras vulgares copias que tratan de copiar no solo el modelo de negocio, si no el mismo formato. Muchas parten de un mismo concepto y lo desarrollan de maneras diferentes, adaptándose a necesidades peculiares de los clientes/comunidades que las consumen.
Por eso opino que en el entorno del desarrollo de software, tratar de proteger una idea legalmente no tiene mucho sentido.

Lo que le da valor a una idea es la voluntad y los medios de llevarla a cabo, eso si tiene valor!

A fin de cuentas, cuantas ideas similares a facebook habrá habido anteriormente?
El verdadero valor de facebook (sin contar los millones que generan) reside en el equipo que ha llevado a cabo brillantemente una idea, no en la idea de crear una comunidad social.

Asi que no creo que firme ningún documento de confidencialidad