bitácora de uno

Hace más de un año escribí lo que es para mi hacer software y cómo explicárselo a tu peluquera.

Creo que sigo de acuerdo con aquello en las ideas centrales, aunque algunos conceptos han evolucionado o cambiado. Por ejemplo ahora estoy lo suficientemente calvo como para tirar de máquina y no ver mucho a peluqueras.

Alberto Martín, me pasa un enlace a frases famosas de programadores de las cuales me quedo con una de un tal Linus Torvalds.

Nadie debe empezar un proyecto grande.
Empiezas con uno pequeño y trivial y nunca debes esperar que crezca; si lo haces solamente sobre-diseñarás y generalmente pensarás que es más importante de lo que lo es en esta etapa. O peor, puedes asustarte por el tamaño de lo que tu esperas que crezca.
Así que empieza pequeño y piensa en los detalles. No pienses acerca de la foto grande y el diseño elegante. Si no resuelve una necesidad inmediata, seguramente está sobre-diseñado. Y no esperes que la gente salte a ayudarte, no es así como estas cosas funcionan.
Primero debes tener algo medianamente usable y otros dirán “hey, esto casi funciona para mí” y se involucrarán en el proyecto.

Hombre “nadie” me parece demasiada restricción, pero sí que estoy convencido de que salen mejor los proyectos pensándolos sencillos desde un principio. La complejidad en un proyecto grande es inherente a él, así que mejor que ayudes en ese sentido.

Mejor pensarlo todo sencillo, incluso renunciando a funcionalidad, e independiente.

Más de una vez hemos comentado que pará qué hemos parametrizado tal parte del código, si nadie la va a utilizar (¿nadie = 1%?) y haberlo hecho a pelo pero clarito nos hubiera llevado la décima parte del tiempo. Además hay veces en que tocar unas líneas en un código clarito es más fácil que retocar un componente supermega reutilizable.

Que lo mejor no sea enemigo de lo bueno. Feliz 2009.

Via | Alberto
Foto | http://www.sxc.hu

Hace un año empezamos a utilizar esta metodología ágil de desarrollo amiga del sentido común para ponerse acuerdo entre unos cuantos para realizar unas cualesquiera tareas.

Más allá de que nos vaya bien una u otra metodología, el peso de lo importante es para mi un buen equipo de trabajo. Siempre me han parecido mejor los equipos pequeños pero en alguna ocasión he visto buenos resultados cuando hemos sido 30.

Más allá de que el tamaño acompleja, creo que es una cuestión de:

• Cultura de liderazgo inverso: Más eres, más al servicio de los demás estás
• Egos satisfechos en otros lados: Efectivos más que efectistas. No nos demos la brasa, ni nos chupemos cosas.
• Respeto: Y si en algún momento falta, disculpas rápidas y sinceras. “Así no”.
• No perder el tiempo: Si hay reuniones se preparan, se terminan en X menor o igual que 45 minutos y que tengan conclusiones (incluída la de vaya mierda de reunión)
• Tiempo de inmersión: Hay que dejar que en el equipo nos sumerjamos suficiente tiempo en un entorno dirigido por las ideas anteriores.

Finalmente el éxito de un proyecto complejo es una cuestión de trabajo efectivo (líneas) y de trabajo de coordinación (gestión útil o inútil).

Un detalle que nos ha gustado de Scrum, son las reuniones diarias o esprints , que - ya lo sabéis - se trata de encuentros rápidos, incluso de pie, en los que cada miembro del equipo contesta a tres preguntas, respecto de una lista de tareas o “sprint back-log”:

¿Qué hiciste ayer?
¿Qué vas a hacer hoy?
¿Has tenido alǵun problema?

La tercera pregunta es importante porque debe llevar implícita la siguiente coletilla:

“… algún problema en el que te podamos ayudar, porque si no te podemos ayudar no nos interesa ahora mismo. Con cariño de amigo, pero no nos interesa”.

Es duro, pero el trabajo en equipo dirigido a alcanzar metas complejas (por la parte imaginaria sobretodo) en tiempos finitos es así.

Nosotros en este año hemos añadido dos preguntas, mejorando un poco nuestra sensación:

• ¿Cuántas horas llevas de retrasos?: Esto era un poco para no dejar pasar los retrasos de sprint en sprint sin ni siquiera mencionarlos.
• ¿Cuál es el ranking en SourceForge? Así no se nos olvida registrar la actividad en los foros y no perder ranking, y nos recuerda que hay gente que utiliza nuestro producto.

Ahí queda eso como experiencia y como arena en grano devuelta (si es que no predico en el desierto).

Por cierto: ¿Será posible que las metodologías ágiles con las que tanto pavo pavonéase, existan hace más de 75 años?
Si aplicamos sentido.. ¿por qué no?
Pistas: “Justo Hidalgo Innovar…”

Imagen | http://www.sxc.hu