Como está en inglés y es un poco larga, voy a tratar de hacer un pequeño resumen.
La artesanía consiste en:
- tomar responsabilidades
- aprender continuamente
- rechazar la especialización
- enorgullecerse del trabajo bien hecho
- transmitir el conocimiento
- cumplir con los estándares de la profesión
En particular, cuando habla de estándares, Dillman se refiere a aquellas técnicas y buenas prácticas reconocidas por todos (como TDD, integración continua, patrones de programación, etc).
Dillman propone un camino para introducir la creación artesanal del software en las empresas, frente a la “presunta” creación industrial que creen hacer ahora. Este camino consiste en tres pasos fundamentales:
- Evaluar
- Educar
- Medir
Lo primero es conocer con qué “materia prima” se cuenta antes de proponer ningún cambio. Para ello se proponen entrevistas con los líderes técnicos, cuestionarios para los desarrolladores (para saber qué conocimiento y prácticas -buenas o malas- tienen) y establecer métricas a partir del proceso de integración continua. Me gustaría destacar que Dillman propone guardar estas métricas en base de datos para así poder aplicar técnicas de “business intelligence” para sacar conclusiones más ricas que las que podamos tener de los informes más bien simples que podamos obtener de un CruiseControl, p.ej.
La parte que más me ha interesado es la educativa. Dillman propone una serie de iniciativas que se pueden crear en una empresa con el objeto de mejorar las habilidades de los desarrolladores:
- Programación en pareja
- Recursos centralizados (como wiki, foros, bibliotecas, etc.)
- Sesiones educativas
- Craftsmanship Day (algo así como “El Día de la Artesanía”)
- 10% del tiempo
- On-team mentoring (algo así como “Ponga un mentor en su equipo”)
Las sesiones educativas me han interesado especialmente y voy a listaros varias de las propuestas que hace Dillman:
- Teasers (que se traduce por bromas o rompecabezas), y que se trata de breves consejos (más o menos prácticos) que idealmente caben en una página.
- Lightning talks (o “charlas relámpago”) que, en apenas media hora, deben introducir un tema muy por encima.
- Tech talks (o “charlas técnicas”) son presentaciones de una hora en las que se explica con algo más de detalle un tema, pero sin llegar a profundizar “hasta el fondo”.
- En los Workshops (o talleres) se trabajan los conceptos en la práctica.
- Un Coder’s Dojo (es como un gimnasio de programación) donde se aplica el lema “Para mejorar debes practicar”. El concepto de “code kata” es realmente interesante (aunque no es nuevo) puesto que consiste en poner a prueba nuestras habilidades como desarrolladores (desde el análisis y el diseño hasta la programación) mediante sesiones cortas en las que se trata de resolver un problema muy concreto y acotado.
El “Craftsmanship Day” es un día que se puede dedicar a una combinación de las anteriores sesiones educativas, a fomentar la participación en la creación de contenidos comunitarios, etc.
El concepto de “10% Time” consiste en que los desarrolladores tienen un porcentaje de su tiempo para emplearlo libremente en cualquier iniciativa personal. A Google, que dedica un 20%, no le va nada mal porque muchos de estos proyectos personales terminan llegando al público.
Finalmente, la idea de los “Test Mercenaries” (que podéis ver en la presentación “Agile@Google“) me parece muy buena puesto que consigue distribuir el conocimiento práctico. Es una forma de “mentorizar” de una manera muy ordenada y productiva.
En fin, he tratado de sintetizar todo lo que he podido. Espero que os sea útil.