Libro de experiencias

Hace un tiempo que vengo dando vueltas a la idea de escribir un libro de experiencias de desarrollo de software. Seria una especie de compendio de casos de estudio cada uno de ellos escrito en primera persona. No es una idea novedosa, de hecho el año pasado gente de una univesidad de Colombia intentó hacer algo similar, pero hasta donde supe no prosperó.

La semana pasada mientras compraba mi pasaje para el Agile Open Camp tuve una idea para para concretar este libro: proponer una sesión en el open space para escribirlo. La idea seria aprovechar que estaremos 3 dias y dedicar un tiempo fijo cada día de cara a llegar el final de evento con una primera versión del libro. Puede parecer complejo pero en realidad no lo es, básicamente quienes tengan un caso para compartir, deberan sentarse y escribirlo, sin dar muchas vueltas la idea tener el caso contado aunque sea a grandes rasgos, luego se le podremos iterear para agregar detalles y correcciones. El último dia del evento tomamos todos los casos y generamos el libro utilizando la plataforma LeanPub. A partir de ahí, el manuscrito queda en un repositorio Git para que podemos ir puliendo los capítulos, ajutando estilo, agregando imágenes, etc, etc.

Al mismo tiempo, yo como promotor de la idea tomaré la responsabilidad de revisar y unificar estilos (acepto colaboración también para estos temas).

Más aún, podría ser interesante llevar al evento con algunos casos ya escritos y aprovechar alguna sesión del open space para trabajar en cuestiones de revisión y unificación de estilo. ¿Que tal si escribes tu caso durante el viaje? (salvo los patagónicos, el resto de los asistentes tendrá al menos 2 horas de viaje, tiempo más que suficiente para volcar la idea en un mail).

Imagino todos los casos siguiendo una misma estructura:

  • Título
  • Tags
  • Contexto
  • Desafío
  • Solución
  • Conclusión

Para tener una idea más concreta de mi idea de caso, pueden ver este que escribí el año pasado.

Para mi es clave es llegar el final del evento con una primera versión del libro, pues ya he participado en proyectos de escritura/traducción con varios involucrados y resulta verdaderamente complejo lograr compromiso y dedicación cuando uno tiene otras responsabilidades.

Bien, la invitación está hecha,  espero que contar con el apoyo suficiente para terminar el evento con la primera versión del libro.

 

La calidad no es inyectable, parte 2

Hablando sobre calidad no inyectable es inevitable recordar el aporte de Joseph Juran con su idea de Quality by Design. Esta idea hace referencia a que la calidad puede ser planificada y que muchos de los problemas de calidad se deben a la forma en que la calidad es planificada. En el post anterior comenté sobre el enfoque de planificar la calidad en una etapa tardía del proyecto, posterior a la finalización de la etapa de construcción. Quisiera ahora compartir otro enfoque más integral que planifica la calidad como actividades llevadas a cabo a lo largo de todo el proceso de construcción.

Y no, no voy a hablar de métodos ágiles, no todavía. Quiero referirme ahora a un enfoque duro y puro de ingeniería de software. No puedo dejar de asombrarme cuando escucho profesionales del software hablar como si antes de los métodos ágiles hubiera sido todo desorganización. No es cierto, entre la era de la desorganización y la aparición de los método ágiles ha habido muchas ideas, técnicas y prácticas muy valiosas, entre las que destaco:

  • Desarrollo iterativo e incremental
  • Revisiones de código
  • Arquitectura basada en componentes
  • Automatización de pruebas
  • Gestión de la configuración

Si bien estas prácticas estan descritas en diversos libros de ingeniería de software, personalmente me gusta el libro de Calidad en el desarrollo de Software de Guillermo Pantaleo, el cual está escrito en castellano, está enfocado específicamente en cuestiones de calidad, fue publicado en 2011 y esta escrito con la visión mixta de alguien con mucha experiencia académica e industrial como es el caso de Guillermo.

Continuará…

 

 

La calidad no es inyectable

No puedes construir un producto y luego inyectarle calidad, por una simple razón: la calidad no es inyectable.

Si quieres un producto de calidad, debes construirlo con calidad desde el vamos. Esto implica que la calidad de tu producto está directamente relacionada al proceso de construcción del mismo. Por ello tu proceso de construcción debe incluir actividades y prácticas de calidad. Y nada de esto es particular de la construcción de software.

Curiosa y contrariamente a esto, durante mucho tiempo muchas organizaciones de la industria del software han insistido (y algunas lo siguen haciendo)  en separar las actividades de construcción de las actividades de calidad, delegándolas incluso en distintos equipos que trabajan sobre el producto en distintos momentos, generalmente en forma secuencial. Un equipo de técnicos construye el producto y una vez terminado lo entrega al equipo de calidad, como si este pudiera inyectarle calidad, pero realidad ese equipo en el mejor de los casos solo mide la calidad del producto haciendo pruebas. Dependiendo del resultado de esas pruebas, el equipo de construcción vuelve a tomar el producto para “mejorar” su calidad. Esta dinámica de ida y vuelta se repite hasta que el producto alcanza el nivel de calidad deseado (o hasta que se acaba el presupuesto o hasta que se llega a una fecha límite).

¿Es posible generar un producto de calidad de esta forma ? Si, es posible. Pero no es la única forma y posiblemente tampoco sea la mejor para todos los casos. Entonces, ¿cómo seria una mejor forma de hacer esto? ja!, eso es tema del próximo post 😉