direccion unicaEn el último viaje a San Francisco pude conocer a programadores de Google, de Apple y de proyectos más modestos. Todos tenían en común estas dos cosas: 

  1. Su forma de trabajar las prácticas y métodos dan forma a principios ágiles: trabajan con una visión conocida y compartida por todo el equipo que van dibujando y mejorando de forma continua o a través de iteraciones cortas. 
  2. Pasan de metodologías y dogmas ágiles.

Centrarse en las prácticas ágiles y no el fondo es como esforzarse en la caligrafía para lograr buenas novelas, o como fijarse en el dedo en lugar de la luna a la que señala. La agilidad sin flexibilidad es un dogma paradógico: definir las prácticas de gestión de los equipos "autoorganizados" (?). Es como aquello del "prohibido prohibir"

Me recuerda las conclusiones de Jared M. Spool en su conferencia de edui 2009:

  • Los mejores equipos no tienen una metodología ni siguen un dogma.
  • Los equipos con problemas a menudo intentan seguir una metodología, sin éxito.
  • Los mejores equipos exploran nuevas técnicas de trabajo de forma continua.
  • Los equipos con problemas tienen un repertorio de técnicas fijo y limitado.
Vídeo de la conferencia de Jared M Spool: Gourmet User Experience of Fast Food Budget.


(1) Artículo migrado de la versión anterior de navegápolis (navegapolis.net). Publicado originalmente el 16 de Enero de 2011

motivadores-¡Vaya! ¿Conque te han castigado?
Tom no se dignó a contestar. Seguía pintando entusiasmado, separándose de vez en cuando de la valla y observándola con mirada de artista.
Ben, que tenía en la mano una manzana muy apetitosa, se quedó con la boca abierta, pues no acertaba a comprender nada.
-Oye, Tom, me voy a nadar, ¿no quieres venir? ¿O es que tienes que trabajar?
-¡Hola, Ben! Estaba tan entusiasmado pintando la valla que ni siquiera te había visto.
-¡No dirás que prefieres trabajar a ir a nadar!
-Depende de lo que tú llames trabajo. A mi me encanta pintar la valla.

Mark Twain. Las aventuras de Tom Sawyer


Es posible que en otros sectores sea difícil contar con personas o equipos motivados, pero con programadores es, debería ser extraño. Por eso, las empresas de soft que se preguntan "Cómo motivar a los programadores" no suelen tener el problema en la plantilla, sino en la cultura de la organización.

Sin Semaforos¿Qué es mejor: gestión externa, o autogestión del propio equipo? ¿Es un criterio igual de válido, se trate de un equipo grande o pequeño? ¿Es esta una razón por la que la agilidad (equipos autogestionados) funciona mejor con equipos pequeños, y escala en arquitecturas fractales? ¿El criterio es también válido sea cual sea la cultura, o los valores del equipo? ...

Estas son algunas de las cosas en las que hace pensar este vídeo del experimento que se realizó en septiembre de 2009 en Portishead, un pequeño pueblo británico cerca de Bristol, al apagar los semáforos para dejar que se autoregularan los conductores.



BrújujaAplicar prácticas ágiles no siempre es agilidad, puede ser ingeniería concurrente.

"Scrum" y "Kanban" son prácticas de desarrollo incremental, las primeras basada en iteraciones y las segundas en el mantenimiento de un flujo continuo de tareas.

Cambiar las prácticas de gestión predictiva por prácticas ágiles con iteraciones cortas es Ingeniería concurrente: desarrollo gestionado (no autogestionado) basado en ingeniería de procesos más que en el talento del equipo, pero con solapamiento de las fases de desarrollo y entregas incrementales.

Normalmente decimos gestión ágil cuando quizá tiene más sentido hablar de gestión evolutiva...

Este es el mapa de conceptos que me sirve de brújula para no perderme en el laberinto de Scrum - Kanban - Scrumban - PMI Agile - Cascada - Gestión ágil etc. Aquí lo comparto para los que también le encontréis sentido.

Gestión de proyectos: diagrama de conceptos

 

Safe Creative #1306235311935

tio gilito

Como tengo instalado en la mesa de al lado al nuevo director de proyectos,(1) estoy viendo la presentación que prepara para aleccionar mañana a su equipo de gestores a "facturar". 

El título de la primera diapositiva es "¿Para qué existen las empresas?", y a continuación presenta con letra de gran tamaño, como remarcando que  "¡Toodo el mundo lo debería sabeeer porque es evideeente!: "PARA GANAR DINERO". 

Resulta tan obvio que acompleja no entenderlo. ¿Obvio?

¿En todas las empresas, es esta la meta de su emprendedor? Seguro que en muchas sí, pero también es seguro que otras han nacido para dar vida a proyectos ilusionantes por sí mismos.

Desde luego, sin dinero la empresas no tienen oxígeno, pero la diferencia es que en las primeras es el objetivo, y para las segundas, la consecuencia.

Quizá sea porque no sé de "bisnes",  pero me gustan más las segundas, y me da la sensación de que las primeras confunden el medio con el fin.

Hace poco me aconsejaba el director de negocio de la software factory en la que trabajo:(1) "El cliente no sabe lo que quiere. Copia y pega este informe que hice yo hace unos peses para Fulanitez, cambia los datos y ya tenemos facturado el estudio"  ¡?!

No le entendía, y sin duda él no habría entendido por qué yo no le entendía a él. Seguramente las dos visiones tienen razón: la una, en una empresa cuyo fin es facturar, y la otra en una empresa cuyo fin es construir soluciones.

Se me ocurre hacer un paralelismo con  la finalidad por la que algunas personas deciden ser médicos. Seguro que las hay que quieren alcanzar un nivel social y económico alto, y ven en la medicina una profesión adecuada para su objetivo, y seguro que las hay también que sencillamente, quieren curar enfermos.

Los primeros tienen que curar pacientes para ganar dinero, los segundos ganan dinero porque curan enfermos. Puede parecer lo mismo, pero hay mucha diferencia.

----

(1) Nota: Este es uno de los post que por "entrañables" estoy trasladando aquí desde el anterior navegapolis.net donde fue publicado el 31 de marzo de 2005. Hace ya algunos años que dejé de trabajar en la empresa aludida ;-)

edadSe dice que son necesarias 10.000 horas de trabajo de programación para alcanzar el nivel de experto, pero una vez llegado a él, ¿cuál es la evolución? ¿Se mantiene? ¿Continúa mejorando? ¿Retrocede?

Aunque hay diversas opiniones, posiblemente la más habitual considera que la edad desgasta la capacidad para adoptar y absorber nuevos conocimientos, por lo que al avanzar va transvasando a puestos comerciales, de gestión, de asesoría, o incluso a otras actividades. 

Como la demanda de software continúa creciendo, y en el medio plazo no es probable un cambio de tendencia, se empieza a cuestionar si la preferencia de candidatos jóvenes, o la percepción del "demasiado mayor" tiene sentido o puede ser un comportamiento inducido por una falsa lógica.

Patrick Morrison y Emerson Murphy-Hill del departamento de Ingeniería del Software de la Universidad de Carolina del Norte, han realizado un estudio pionero en esta línea, basándose en el análisis de los datos de la comunidad de programadores de stackoverflow.com (edad, reputación en la comunidad, tecnologías tratadas).

El objetivo de su primer estudio en esta línea es identificar si se aprecia algún tipo de correlación entre edad y nivel de programación, antes de profundizar con posibles correlaciones entre la "inteligencia fluida" o capacidad para identificar relaciones complejas y sus inferencias, y la "inteligencia cristalizada" que refleja la amplitud de conocimiento, comprensión juicio y sabiduría adquirida por la experiencia".

La conclusión a la que llegan los autores es que sí que existe una correlación entre la edad y la reputación de los programadores en stackoverflow.com, que parece indicar que se puede mantener un nivel de programación alto en los 50 y los 60, y que los usuarios más veteranos de stackoverflow se encuentran al día y adquieren sin problemas los nuevos conocimientos en las tecnologías que ha examinado este estudio.

Este es el documento del estudio: Is Programming Knowledge Related to Age? que presentarán los autores el 18 de mayo en el eventop "10th Working Conference on Mining Software Repositories" en San Francisco.

satisfaccion thumb"Un problema de los equipos de programación con importante impacto económico es la alta rotación de personal. La relación entre insatisfacción y rotación es una evidencia contrastada. El estudio (Comparative Analysis of Job Satisfaction in Agile and Non-Agile Software Development Teams) investiga si existe una relación entre la satisfacción laboral y el método de desarrollo empleado, y encuentra una correlación positiva moderada entre el nivel de satisfacción y el uso de metodologías ágiles..." (1)

satisfaccion laboral en equipos ágiles y no ágiles

 "El análisis comparativo entre equipos ágiles y la media general de profesionales TIC, ha revelado tasas significativamente más altas de satisfacción en los miembros de equipos ágiles. Además no sólo en los trabajadores, sino también en los administradores se da mayor satisfacción con sus empleos. Este es un claro indicador de que los métodos ágiles no son un movimiento orientado sólo a los programadores".

El informe completo y todas tablas comparativas del estudio en:

(1) Melnik, G., & Marurer, F. (2006). Comparative Analysis of Job Satisfaction in Agile and Non-agile Software Development Teams. Extreme Programming and Agile Processes in Sotware Engineering, 32-42.