Computación y Ajedrez

Ciertamente tengo el ajedrez bastante olvidado, y hace años -demasiados- que no juego ni una partida. Un día volveré a recuperarlo de mis aficiones, al menos para enseñarle lo básico a mi hijo. Pero el ajedrez y sus conexiones con la informática son bastante interesantes. Ya hace unos meses escuché la historia de Deep Blue de mano de uno de sus "entrenadores", Miguel Illescas, y resultó muy entretenido.
Ahora el CEIN, en Pamplona, organiza el Campeonato del Mundo de Ajedrez con Ordenadores y una Conferencia Internacional sobre Juegos y Computación -¿los ordenadores hacen deporte? :P - y lo arropa con varios eventos dignos de asistencia, os copio un extracto del anuncio en CES.

Tanto desde el BSC [¿Qué es la supercomputación? Una explicación orientada al mundo empresarial.] como desde el CESGA [Necesidades de supercomputación en la empresas españolas.] sólo nos ofrecieron facilidades para venir a contarnos a qué se dedican. Y lo mismo podemos decir de las empresas que vendrán a explicarnos cómo la aplican en su día a día.

¿Pero tan importante es el ajedrez en el campo de la computación? ¿Y realmente sirve para algo más que calcular miles, millones de variantes de una posición? La respuesta nos la dará Leontxo, el jueves 14 de mayo.
Y ya que CEIN anima el espíritu emprendedor, uno de ellos (editor, gran maestro, entrenador de un antiguo campeón mundial) nos contará cómo hay mecanismos que se aplican en las partidas de ajedrez que pueden aplicarse en un tema clave en la gestión empresarial: la toma de decisiones.

Espero veros por ahí!

Scrum y TDD

En realidad este post es solo dos anuncios ;)

• Hemos abierto un grupo para hablar de TDD en castellano. ¡Apúntate!
  
• Los afamados cursos de Scrum de Proyectalis vuelven.

Y os cuento, que nosotros estamos en fase de adopción de TDD, y ya trabajando con Scrum. La adopción de TDD no es sencilla, y actualmente estamos invirtiendo en mejorar nuestros desarrollos de testeo unitario, para después cambiar el chip-o más bien invertir- del orden de desarrollo. Pasito a paso, pero seguros.

No hablamos de programar, es del cliente!

Estaba echando un vistazo a la metodología ágil EVO (Evolutionary Project Management), una metodología no muy conocida por estos lares, creada por Tom Gilb. Básicamente contiene todos los principios recogidos en el manifiesto, pero llama la atención que esta metodología data de 1980. Es curioso como nos olvidamos, o se sumergen en el olvido, cuestiones que en su momento habrían sido de los más innovador. Es curioso como Scrum se ha tragado el resto de metodologías.
Por lo que veo, esta metodología va algo más alla de Scrum y XP y trata el negocio como un sistema completo. Es más probable que se asemeje un enfoque Lean, tratando de dar valor desde la concepción de un proyecto, gestionando temas que se salen de la parte de desarrollo puro para entrar en la gestión del negocio.
EVO se basa en 10 principios, con la idea general de los principios de las metodologías ágiles. El que me ha llamado la atención, me ha gustado, es:

Evo is holistic systems engineering - all necessary aspects of the system must be complete and correct - and delivered to a real stakeholder environment - it is not only about programming - it is about customer satisfaction.

No se trata de programar! si no de proporcionar valor al cliente. Muchas veces este es un punto dificil de transmitir a los desarrolladores; cuando nos gusta programar generalmente perdemos el enfoque en el cliente, y hacemos cosas complejas cuando no son necesarias por que son bonitas, o cuestiones que dejamos "a medias" por que son aburridas.
Tener en mente siempre al cliente, siempre - en cada linea de código- es muy duro. Pero sería realmente provechoso, realmente reduciríamos los desperdicios de nuestro proyecto. Muchas veces los desarrolladores se limitan a hacer lo que dicen las especificaciones, o lo que les pasa el analista, y sin embargo deberían tener también la visión del cliente. Exactamente igual que todo el resto del equipo.

La web de Gilb, que no conocía, me parece que tiene documentos bastante dignos de investigar, por si os interesa... ;)

Lean: Construir con calidad

Este principio -verdad subyacente que no cambia con el tiempo o el espacio-nos indica que debemos construir el código desde el principio con calidad suficiente, no testearla únicamente al final. Para asegurar la calidad puedes hacer dos tipos de inspección: después de que los errores ocurran, o para prevenirlos antes de crearlos.
La falta de calidad en la construcción genera deuda técnica -una deuda que se cobrará posteriormente sus intereses: falta de mantenibilidad, disminuirá la eficiencia, bugs insospechados-, que más tarde se convertirá en un problema. Además significará que tenemos trabajo a medias por hacer, así que hemos generado desperdicio en el proyecto.
No basta con estar preparado con buenas herramientas para llevar el control de defectos, listas de bugs. Todo eso es desperdicio, trabajo a medio hacer, por que significa que cada funcionalidad en la que has encontrado un error está a medio terminar realmente. La tarea de testeo debe prevenir los errores, no encontrarlos, participar en la mejora del proceso de creación de software. Las metodologías ágiles han desplazado muchas tareas tradicionalmente de equipos de testeo hacia los roles más de programación o desarrollo. Para ello algunas de las principales técnicas recomendadas en el desarrollo son:

• TestDrivenDevelopment: Crea primero los tests, escribe código, comprueba más tests, refactoriza y vuelve a empezar. Por cierto, acabamos de crear un grupo en castellano para hablar de TDD.
  
• Integración Continua: Complemento perfecto para las pruebas unitarias, ayuda a la integración entre código de distintos desarrolladores y versiones.
  
• Refactorización: Básicamente es cambiar el código fuente sin modificar su comportamiento. Permite mejorar la estructura del código, por mantenibilidad, rendimiento,... para permitir un crecimiento adecuado y sostenible de las aplicaciones.
  

Pero los Poppendieck identifican un concepto más alla de lo que comunmente entendemos como calidad -en su versión más típica de comprobación de defectos-, y es la integridad del producto software:

• Integridad percibida: Se refiere a que el producto logra un balance entre la funcionalidad entregada, usabilidad, estabilidad y economía que emociona al cliente.
  
• Integridad conceptual: Indica que el los conceptos principales del sistema colaboran juntos como un todo cohesionado de manera fluida. La integridad conceptual es un prerrequisito de la percibida, puesto que si el sistema no dispone de una manera consistente de presentar los temas, el tratamiento de datos o las metáforas, la percepción del usuario no podrá ser completamente favorable.

La clave para mantener la integridad es una buena comunicación entre todas las personas implicadas. Es muy típico que en proyectos medianos o grandes, no se compartan la visión de la globalidad del producto, lo que conduce a problemas de integridad conceptual. A veces hasta es dificil conseguirlo con tres o cuatro desarrolladores! :\

El cambio mental es que la calidad no solo se debe controlar, sino que se debe construir. No basta con recolectar métricas, si no que hay retroalimentar el sistema para disminuirlas.

Agile-spain

El sábado me fui a Madrid a la "refundación" del grupo agile-spain. Este grupo intenta promover las metodologías ágiles de desarrollo en España, un elemento de la ingeniería del software poco practicado por estos lares. La reunión fue realmente amena, y podeis vernos en acción en unas cuantas foticos que Xavier Quesada ha colgado.

De Reunión refundacional

Ciertamente compartíamos la idea de que estas metodologías son un paso adelante en la mejora del mundo del desarrollo de software, y estuvimos mirando pasos a dar para reforzar la comunidad y dar a conocer esta faceta en la que otros paises nos llevan un par de años de ventaja. Así que nos podeis ver en la fotos jugando con los post-it, sacando y priorizando ideas. Pronto contaremos con más detalle qué se nos ocurrio, así que no olvides suscribirte a agile-spain, y sobre todo ¡a la comunidad!
Para ponerte en contacto con la comunidad agile-spain lo mejor es que te des de alta en el grupo de Google en el que comentamos cualquier tema relacionado.

Actualizacion: Una verdadera exposición de los hechos, por Jose M. Beas

Lean: Crear Conocimiento

Este principio -verdad subyacente que no cambia con el tiempo o el espacio- trata sobre la importancia del aprendizaje. El desarrollo de software es radicalmente distinto a los procesos de producción. La creación de software es un ejercicio de descubrimiento, mientras que la producción intenta limitar las variaciones entre elementos. Para mejorar este ejercicio debemos maximizar el aprendizaje en cada etapa.
Las herramientas propuestas para maximizar el aprendizaje son:

• Feedback: Cualquier ciclo que termina con una evaluación de su desarrollo y resultado proporciona una oportunidad inmejorable para el aprendizaje. Las metodologías tradicionales plantean pocos puntos para el feedback, por que parece que cuestionan la planificación o el saber-hacer de la gestión de proyectos.
• Iteraciones: Las iteraciones permiten aprender poco a poco sobre el proyecto, de manera incremental, probando y desarrollando sobre lo que se va aprendiendo.
• Sincronización:Es imprescincible una buena sincronización entre las partes involucradas en desarrollos complejos. Se debe fomentar compartir el conocimiento entre las personas. Muchas metodologías ágiles comparten la idea de la propiedad del código compartida.
  
• Desarrollo basado en conjuntos: Para aprender bien las cosas debes probarlas, hacerlas, ofrecer un rango de soluciones que podrían funcionar. Hay que ser capaz de desarrollar un conjunto de pruebas que muestren qué hipótesis eran las correctas sobre la solución de un problema.
  

El aprendizaje por tanto puede ser visto desde dos puntos de vista: el equipo que aprende a desarrollar software cada vez mejor, y el equipo que aprende cada vez más sobre el proyecto (funcionalidades, lógica) que está construyendo. Es importante que se crea en el concepto de mejora continua, de lo contrario, estas tareas de retrospectivas, feedback,... puede acabar quemando a gente que hubiese preferido un entorno más conocido (¿hay de esos por ahí?). Debe ser una situación gradual, de aprendizaje continuo, pero relajado.

Lean: Eliminar la basura

Este principio -verdad subyacente que no cambia con el tiempo o el espacio- trata sobre la necesidad de eliminar los elementos que producimos y que no son realmente necesarios para crear el producto software que necesitamos hacer, que no le añaden valor.
El primer punto por tanto es averiguar qué es lo que da valor y lo que no. Identificar los procesos, artefactos o tiempos que no añaden nada a lo que el cliente necesita. Algunos ejemplos [1] de basura dentro de un proyecto pueden ser:

• Requerimientos que no se van a utilizar. Recordemos siempre la regla de Pareto. El 20% de las funcionalidades proporcionarán el 80% del valor del producto.
  
• Complicaciones de diseño/interfaz que no eran necesarias.
  
• Esperas entre etapas:
• Tiempo desde que se obtiene la información hasta que se usa.
• Tiempo desde que alguien necesita información hasta que la obtiene
• Tiempo desde que se crea un error hasta que se detecta/corrige.
• Otro tipo de esperas muy peligrosas, las producidas por la multitarea (o la procrastinación)
  
• Escribir demasiado código. Puede estar relacionado con el tema de la complejidad, o quizás simplemente es que no se supo hacer de una manera más sencilla. Pero si algo lo puedes hacer con la mitad de código, estás creando basura.
• Trabajo a medio hacer, sin terminar. Equivalente al inventario en sistemas de producción.
• Errores, cada bug creado en el desarrollo es un desperdicio. Suena obvio, pero a veces ponemos más enfasis en encontrar la basura que en no generarla.
• Actividades de gestión. Estas actividades no aportan valor directo a los productos, y aunque obviamente son muy importantes para el correcto funcionamiento de organizaciones y equipos, hay que vigilarlas para que no se conviertan en focos de desperdicio. Lo más típico: la burocracia.
  

Uno de las dificultades de este principio es discernir qué factores se pueden reducir o aligerar para eliminar basura. Identificar qué pasos en los procesos no producen valor para el cliente. No siempre valen las mismas conclusiones para todos los entornos. En algunos proyectos algunos tipos de documentación pueden ser un desperdicio, pero en otros, que por ejemplo ya sabes que después los vas a ceder a otro equipo o van a tener un mantenimiento muy prolongado, puede ser vital documentar exhaustivamente.
La herramienta propuesta por Lean[2] para la identificación de la "basura" es la creación de mapas de cadenas de valor, para analizar el flujo de aporte de valor de los procesos utilizados por el equipo para la creación del producto, desde su concepción hasta que llega al cliente. Los mapas ayudan a visualizar los tiempos que se pierden de manera gráfica.
Debes trabajar para poder ver las pérdidas de tiempo en un desarrollo de software. Determinadas veces serán obvias (burocracia, procesos de documentación que generan artefactos que nadie usa ni usará,...), pero otras no son tan claras, o lo que es peor, pueden no ser bien aceptados los cambios que necesitarías llevar a cabo para eliminarlos. La burocracia y las costumbres pueden ser dificiles de erradicar por que dan (falsa) seguridad y confianza[3].
Por lo tanto, ¿es este principio beneficioso para el desarrollo del software? Sin duda. Aporta mejoras en dos de las areas que comentamos en el primer post sobre Lean:

• Mejora la productividad de la "tubería-desarrollo". Hacemos más eficaz los equipos y la organización por que dejamos de realizar tareas que no aportan valor al cliente, que al final, es quien determina nuestro éxito o fracaso.
• Mejora las interacciones entre desarrollo y el resto de la organizacion. Recordemos que Lean se centra en la organización global. No debes dibujar un mapa de creación de valor para el departamento de desarrollo, si no para la organización completa! Seguro que salen muchas ineficiencias interdepartamentales.
  

Bibliografía:
[1] Implementing Lean Software Development
[2] Lean Software Development: An Agile Toolkit
[3] Eliminando obstáculos
[4] Gestionando la recesión con Lean, Agile y Scrum
[5] Los Poppendieck

Tres preguntas

Acabo de leer un post sobre Agile: ¿la evolución de las metodologías tradicionales? En general hace una comparativa sobre los métodos tradicionales y los ágiles de desarrollo de software. Expone algunos problemas que tienen las metodologías ágiles desde su punto de vista, que me han resultado interesantes por la experiencia en testeo del autor.
Pero lo que me han interesado han sido las tres preguntas con las que acaba el post:

• ¿Existe la evolución de las metodologías Agiles?
  
Aquí creo que el autor se refiere a preguntar por si las siguientes generaciones de metodologías ágiles van a ser más formales, con un enfoque más tradicional. Creo que podrá haber dos evoluciones hasta que llegue la revolución. La primera, miles de equipos adaptando sus propias metodologías, y variantes de las definidas actualmente. Y la segunda, las que provengan basadas en el concepto de Lean Development. Estas evoluciones especificadas más formalmente basadas en Lean, proveerán el marco más ágil visto nunca para el desarrollo de software, plasmando los principios en procesos.
Después vendrá la revolución en el desarrollo de software, pero de eso todavía no tengo pistas.


• ¿Surgieron por si solas o son adquiridas y formadas en reacción a la complejidad propuesta por las metodologías tradicionales?

Yo no tengo duda que actualmente se han formalizado como reacción a las tradicionales, pero que no han surgido en su concepto de ellas. Antes se empezó a desarrollar software, cada uno haciendo las cosas como podían. Una serie de gente formalizó los procesos de creación de software basándose en las teorías clásicas de gestión de proyectos industriales, y de ahí surgieron las metodologías formales. El resto estuvieron callados hasta que vieron que la presión de las mismas era demasiado negativa. Y volvieron a los orígenes.


• ¿Las metodologías Agiles de alguna nueva generación no serán en si mismas las adaptaciones y evoluciones de metodologías tradicionales?

No lo creo. Puede haber una síntesis de las mismas, de las dos corrientes, que quizás nos lleve a un mejor sitio del que nos encontramos ahora, o quizás no. Pero los principios en los que cree cada tipo de metodologías son básicamente contrarios. Se podrían reconciliar prácticas o procesos, pero reconciliar principios que das como intrínsecamente ciertos es más dificil.

Un saludo a Javo, me ha gustado mucho su blog. No todo va a ser leer bonanzas sobre "las ágiles" ;)

Desarrollo software Lean

Uno de los temas en los que estoy más interesado ultimamente en este mundo del desarrollo de software es el "Lean Development". Es un conceto que surgio de la adaptación del modelo de Toyota de fabricación al software. Orginariamente parece que fueron "los Poppendieck" los inventores del término, en un par de libros que no te puedes perder:

• Implementing Lean Software Development: From Concept to Cash.
  
• Lean Software Development: An Agile Toolkit. Este lo tengo hace unos meses y me parece muy bueno. Enfoques diferentes para problemas tradicionales.

Lo importante de Lean, es que se basa en unos principios, adaptados del TPS. Y esto es una de las claves para su futuro éxito, que no son herramientas, no son pasos a dar o procesos a seguir. Son principios cuyo valor reside en su aplicabilidad independientemente del "estado del arte" en el que te encuentres. Las medidas las decides tú, los cambios guiados por principios son efectivos si los principios son adecuados. Así que llegamos a la cuestión, ¿son los principios Lean acertados para lograr un mejor desarrollo de software? (Ahí es nada, definimos mejor como de mejor calidad, mejor satisfacción del cliente, mejor ganancias para el proveedor,... mejor lo que quieras!)
¿Cuales son estos principios? (el orden no importa)

• Eliminar la basura
  
• Crear conocimiento
• Construir calidad inherente en el producto
• Retrasar el compromiso
• Entregar rápidamente
• Respetar a las personas
• Mejorar el sistema global

Iremos viendo cada uno, intentando adivinar si son beneficiosos para el desarrollo de software. (!me acabo de obligar a escribir al menos 7 posts!).
Otra pregunta que te sueles hacer cuando empiezas a conocer Lean es su relación con las metodologías ágiles. Básicamente creo que hablan de lo mismo, pero Lean está un paso por encima a nivel organizativo. Las metodologías ágiles (XP y Scrum al menos, que son las que más conozco, no olvidemos que existen otras) se focalizan en el equipo que desarrolla un proyecto. Lean complemente esa visión con principios aplicables a la organización que soporta los equipos, y que debe gestionar un portfolio de proyectos y equipos. Hay cuatro cuestiones que se deben lograr:

• Seleccionar las cosas adecuadas en las que currar (Lean Management). ¿te interesan todos los proyectos?
  
• Ajustar la carga de trabajo a la capacidad. Muchas veces ni siquiera conoces tu capacidad.
  
• Mejorar la productividad de la "tubería-desarrollo" (Lean-Scrum). Aumentar la capacidad del sistema.
  
• Mejorar las interacciones entre desarrollo y el resto de la organizacion. Recordemos que Lean se centra en mejorar el sistema global.
  

Recapitularemos tras ver los principios, y volveremos sobre estas cuatro cuestiones. Si quieres ir adelantando las ideas, aquí tienes una pequeña recapitulación de los principios.

P.1 Eliminación de la basura.
P.2 Creando conocimiento
P.3 Construir con Calidad

Aprendizaje como mejora continua - Retrospectivas

Las retrospectivas son una de cuestiones en las metodologías ágiles más útiles. Una pieza clave en la mejora continua que se espera de un equipo ágil (bueno, se esperará de cualquiera, ¿no?). Pero lo realmente fundamental es el aprendizaje continuo, que lleva a una evolución mucho más profunda que una simple mejora de los procesos.
La rotación de las personas que asimilan el aprendizaje continuo entre diferentes equipos, puede enriquecer cada uno de los diferentes proyectos en los que participen. Es dificil elevar los procesos entre diferentes equipos, cada uno puede mejorar a su ritmo, o ir en direcciones diferente. Pero el conocimiento se queda en cada una de las personas que participan. Esa es la mejor manera de que la organización adquiera el conocimiento en la creación de software. Puedes crear wikis, blogs y usar twitter para registrar toda la información, pero nunca podrás replicar la experiencia de haber participado en un proceso de mejora continua, de ver los porqués de los procesos, de los cambios, de las ideas.

Cuatro años y feliz año nuevo

No todos estos últimos años he celebrado el cumple de este blog. Pero este año es (debe de ser) diferente.
Hace cuatro años ya que empecé a escribir: 200 posts, aunque no es mucho, este es un blog modesto :) . Empecé hablando de software libre, para dar a conocer mi tesina sobre ello. Después pasé a temas más de programación y que leía por otros blogs, pasando por temporadas de muy pocas publicaciones, y últimamente hablo especialmente de gestión de proyectos: me ha invadido el "gusanillo ágil". El año que viene espero seguir con un ritmo un poco constante de publicaciones, ahondando en este tema del desarrollo de software. Quizás entre todos podamos encontrar la nueva síntesis surgida de las metodologías ágiles y formales.
Así que aprovecho para felicitaros el nuevo año a todos, y desearos que descubrais el mejor camino a seguir!!

Retrospectiva anual

Dos libros me tienen enganchado últimamente: "Software for your Head", y "Agile Retrospectives: Making good Teams Great". Y con estos, he preparado una retrospectiva anual, basándome en algunos conceptos y actividades interesantes que plantean.
Ya decía anteriormente que un concepto muy importante de las metodologías ágiles es la comunicación de banda-ancha entre los miembros del equipo. Sin duda, "Software for your Head" es uno de los libros que más te puede aportar en ese sentido.
Las retrospectivas en las metodologías ágiles son una práctica muy útil para la mejora continua de los procesos de desarrollo, del equipo, de las metodologías. Así que ahora que vamos introduciendo poco a poco metodologías ágiles en el desarrollo, se me ocurrio hacer una retrospectiva no ligada a una iteración o un proyecto, si no al año que termina. Una retrospectiva anual para establecer objetivos de mejora por el equipo para el año siguiente.
Y por si a alguien le interesa, estos pueden ser unos buenos pasos para hacerse la suya en casa (al menos creo que a nosotros nos han sido útiles), basados en el libro de Derby.

1. Set Stage:
   Actividad 1: Check-in. Los participantes comentan su estado de ánimo.
   
   Introducción a la retrospectiva: Objetivos: Aprender y mejorar.
   Actividad 2: ECRP (Decide your role in this retro: Explorador/Consumidor/Relajado/Prisionero)
   
   
2. Gather Data:
   Actividad 3: Timeline. Se desglosan por equipos los eventos/hechos ocurridos el año 2008 en el equipo, pintándolos sobre una linea temporal.
   
   
3. Generate Insights:
   Actividad 4: Brainstorming. Desglose de cosas que podemos mejorar. En resumen, y sin orden de importancia, todo lo que salga.
   
   
4. Decide What To Do:
   Actividad 5: Definir objetivos SMART. Decidir qué hacer. Objetivos para el 2009 de todo el equipo, como equipo.
   
   
5. Close:
   Actividad 6: +/Delta. Retrospectiva de la retrospectiva. ¿les ha gustado?

Esto es simplemente un esquema, los libros están realmente detallados. Se podrían hablar de muchas cosas de cada punto o actividad, pero me gustaría que me contaseis si haceis vosotros este tipo de cosas en vuestras empresas, o si creeis que sería interesante. ¿Haceis retrospectivas a todos lo niveles?

Actualización (30/12/2008): Acabo de descubrir que han hecho un pequeño resumen del libro sobre Retrospectivas en castellano. Utilísimo como referencia una vez que te has leido el libro! Gracias Juan por tu trabajo!

El declive y caida de lo ágil

Un reflexión de tic-tac (sobre una frase: "El hombre que actúa con métodos, ignorando los principios, es seguro que tendrá problemas.") me hace pensar en la carga de profundidad que tiene este otro artículo de James Shore: The Decline and Fall of Agile.
Habla sobre los problemas que está dando la proliferación de implantaciones que se están haciendo del método Scrum, pero haciendolo sin preocuparse de los principios que lo sustentan.

"These teams say they're Agile, but they're just planning (and replanning) frequently.. ""Agile is hard, and you can't master it by sitting through a two-day course."

Ciertamente hay una serie de cuestiones que escapan al "método Scrum", que deben ser parte fundamental de una metodología ágil. En el mismo artículo comenta algunas:

• shared workspaces: La comunicación en espacios compartidos fluye mejor, es más fácil compartir una visión y el trabajo.
  

• high-bandwidth communication: El equipo debe mantener en todo momento un canal de comunicación de alta capacidad. No hay excusas para guardarse información, no preguntar, o no compartir.

• on-site customers: Es muy importante la disponbilidad del cliente cuando sabemos que los requerimientos van a evolucionar, y el equipo necesita aclaraciones en cualquier momento.

• work in cross-functional teams: Los equipos multidisciplinares deben estar intrgrados en la solución del proyecto, deben ser un equipo al completo, no una serie de grupos de personas que resuelven cada uno su papel. Así se pierde enseguida la visión compartida.

• let alone deliver releasable software: El avance de los proyectos se mide por producto terminado.

• use good engineering practices: El concepto de deuda técnica aclara muy bien este punto. Si te hipotecas tecnicamente, el futuro del software no será sostenible.
  

Pero, ¿realmente son necesarias todas estas prácticas anteriores para ser ágil? Pues... ¡quizás no! Hay que conocer los principios, y aplicarlos para cada problema, que necesita una respuesta adaptada. En un comentario del grupo de Yahoo de lean-agile-scrum, la genial Mary Poppendieck lo dice en una respuesta muy interesante:

It sounds to me like you are taking the Scrum recipe much too seriously. If you want to be successful, you have to spend some time thinking creatively about what will work in your world. Lifting recipes from others and expecting them to work in your environment doesn't have a good track record of success.

Creo que por aquí estamos bastante lejos de pensar en el declive de Scrum, cuando no me parece que esté demasiado implantado por estas tierras. Pero si podemos llegar a la lección antes de qué nos peguemos con los problemas, eso que habremos ganado.

Libros de desarrollo de software

Creo que este es el primer post que recupero "bajo demanda". Me acabo de fijar que tenía empezado uno con el mismo título desde mayo... ¡del año pasado!.
En fin, que ya me he decidido a haceros un listado con algunos de los últimos títulos que tengo en mi biblioteca relacionados con el desarrollo/gestión de software. He seleccionado algunos y los he ordenado más o menos por lo que me han resultado de interesantes o productivos. De todas maneras, sigo con una lista interesante de libros por comprar, esto no se acaba nunca! :)

• Peopleware : Productive Projects and Teams, 2nd Ed.. Si no lo tienes, compralo. NO lo dudes. Es un clásico, pero no ha dejado nunca de tener vigencia.
  
• Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers,... Joel Spolsky es otro de los que no te puedes perder. Y no hace falta comprarse sus libros por que todos los artículos están en su web. Habla la voz de la experiencia, y mucho sentido común. En algunas cuestiones es de la vieja escuela, pero tiene grandes ideas.
• Leading a Software Development Team: A Developer's Guide to Successfully Leading People and Projects: Todo lo que cuenta este libro lo aprendí primero de uno de mis jefes -en una vida anterior-. Desde un enfoque tradicional de gestión de proyectos, repasa las estrategias y actitudes para gestionar los equipos y proyectos. Recomendado sobre todo si acabas de ganar responsabilidades de liderazgo de equipos o proyectos.
• Lean Software Development: An Agile Toolkit (The Agile Software Development Series): Un libro genial. Hablá de técnicas que se pueden aplicar en los proyectos, sin centrarse en metodologías. Basado en el concepto de Lean, que tanto éxito ha tenido en procesos industriales.
• Software for Your Head: Core Protocols for Creating and Maintaining Shared Vision. Un libro curioso, al principio me decepcionó, pero luego te das cuenta del valor que aporta. Podía haberse llamado "Gestión de equipos", o prácticamente no relacionarlo con el desarrollo de sw. pero la cuestión es que son prácticas y patrones obtenidos de equipos de desarrollo. Cuestiones como la visión compartida, el compartir las emociones o el sistema de toma de decisiones son expuestas en este revouvionador libro. Todavía estoy por aplicarlas en serio.
• The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition: Otro de los clásicos junto Peopleware. Hay que leerlo, pero me decepcionó un poco, aunque simplemente por que cuando cayó en mis manos ya había leido tantas referencias a él, que ya no me sorprendio. Te lo recomiendo para asentar conocimientos.
• A Practitioner's Guide to Software Test Design. Conocí al autor -Lee Copeland- en el hotel de las jornadas de Valencia sobre testeo de software, allí todo el mundo le tenía como un gurú, así que le compré el libro posteriormente. Una buena recopilación de métodos de testeo, muy interesante para tener una idea general o si vas a empezar a montar un dpto. de QA.
• Agile Retrospectives: Making Good Teams Great. Numerosas técnicas para esta parte tan importante de la mejora continua de las metodologías ágiles como son las restrospectivas. Muy práctico.
• Beautiful Code: Leading Programmers Explain How They Think (Theory in Practice (O'Reilly)): Simpatico libro, únicamente si de verdad te gusta programar. Hay que leerlo con paciencia, pero se disfruta. Solo por vicio :)
• Interface Oriented Design: With Patterns (Pragmatic Programmers): Para principiantes, es el único libro técnico que me he comprado en mi vida (¡gracias Google!), y me arrepentí, por que es bastante básico. No me suele gustar comprar libros para mi biblioteca personal que tienen fecha de caducidad.
  

Otros libros que no son propiamente de desarrollo de software, pero que he comprado ultimamente, relacionados con lo que yo creo que es el mundo de la gestión de equipos:

• Marcapropia: El mejor libro en castellano explicando el concepto de marca personal, por Andrés. El año pasado presté un libro a cada persona de mi equipo a la que hacía la gestión por competencias de la empresa, pensando en sus labores a desempeñar. Este año había pensado regalarles a todos una copia de este libro. (otra cosa es que ya no lo vaya a hacer en vista del poco éxito de la iniciativa pasada :( )
• My Job Went to India: 52 Ways to Save Your Job (Pragmatic Programmers). Relacionado con el concepto de marca personal, cualquier momento es bueno, para este libro pero sobre todo si no tienes muy claro por donde ir en tu carrera profesional relacionada con el software.
• Certain to Win: Un libro sobre estrategia empresarial, pero basado en las estrategias militares de John R. Boyd. Viene a insitir en la idea de la agilidad y los ciclos de PDCA.
• Fearless Change: Patterns for Introducing New Ideas: Otro libro de patrones, pero esta vez dedicados a la introducción de cambios en organizaciones. Es interesante ver como muchas situaciones las puedes reconocer en determinados elementos de la empresa.
• Behind Closed Doors: Secrets of Great Management (Pragmatic Programmers): Introducción a la gestión de equipos, cuando debes asumir esa responsabilidad. Me parecio un poco simplón, pero me gustó que te da ideas concretas para realizar.
  

Bueno, estos son algunos de los libros que he adquirido estos últimos dos años, posiblemente los que más me han impresionado o enseñado. Eso sí, todavía tengo que poner muchas cosas en práctica, que es con lo que de verdad se aprende... :)
Lamentablemente, ahora me fijaba lo poco que se traduce al castellano de todos estos temas. Me pregunto si es que no habría suficiente demanda para la traducción de un número mayor de libros.

Calidad testeada vs calidad creada

La calidad de un producto software se puede medir, ahora bien, lo dificil es escoger la métrica adecuada. Pero además, también puedes tener la impresión de que se ha hecho con calidad, si se han seguido unos procesos correctos, el equipo ha cuidado sus diseños técnicos, se han seguido patrones de diseño,...
Desde que estuve en la jornada de testeo de software tengo la idea en la cabeza de como comunicar el mundo del testeo y el del desarrollo (eso claro, si cuentas con un equipo propio de QA, que no conozco muchos).

• Los testeadores no se pueden quedar unicamente en encontrar fallos, además deben dar ideas desde su posición provilegiada de cómo mejorar el desarrollo del software.
  
• Así mismo los desarrolladores no deben unicamente desarrollar, deben comprometerse con la realización cada vez más exhaustiva de pruebas y cómo facilitarla.

Podemos tener dos aproximaciones poniendome en el lugar de una empresa que desarrolla muchos proyectos de medio tamaño:

• Equipo de testeo independiente de los equipos de desarrollo: Esta opción es la que nos contaron la gente de Google en las jornadas de testeo de sw. Podría existir un equipo que valide cada resultado de los sprint, realizando pruebas de caja negra sobre el sistema. Los posibles defectos encontrados, retrasarían la velocidad en el siguiente sprint del equipo de desarrollo.
  
• Gente de QA integrada en el equipo: Los testeos más formales se realizarían dentro del sprint mismo de desarrollo, estas personas podrían realizar tanto testeo de caja negra como "blanca".

Pero una de las cuestiones más interesantes, y que en las jornadas de Valencia me parecio un mundo aparte, es la integración entre los dos equipos. Cuando hablamos de "Equipo=software", debemos incluir a todas las personas implicadas. Cada especialista puede aportar una visión muy importante al resto del equipo, que hace mejorar exponencialmente el trabajo en equipo.
Actualmente muchas pruebas se han trasladado a los desarrolladores, no solo por que no existen muchisimas veces equipos de QA, si no por que técnicas como el testeo unitario, se ha trasladado la responsabiliad del equipo de testeo a los desarrolladores.

Framework, o esa palabra maldita

¿Qué piensa un desarrollador cuando le dicen que tiene que utilizar un framework inventado por la consultora MAJITICA SA para su nuevo proyecto web?

- J***d*r,... la que me ha caido... con la de frameworks libres que existen por el mundo y ahora tengo que usar uno que no tendrá más de 500 horas de pruebas y que no puedo ni ver su código.

Y es que mira que nos empeñamos en reinventar la rueda. Una cosa es desarrollar un API orientado al negocio, y otra sobreescribir el MVC de moda pegándole un IoC para que parezca que hemos hecho algo. ¿Cuantos de estos conoceis?

¿Es SCRUM una ventaja competitiva en una empresa de servicios?

Como ya sabeis, estamos "tonteando" con Scrum en la empresa. Puede ser que sea un idilio largo o no. El otro día nos dieron un curso francamente bueno, fue la empresa Proyectalis. Podeis echar un ojo al blog de Angel Medinilla, quien nos impartio el curso de dos días, muy bien planteado e interesante.
Lo que ahora me pregunto es hasta qué punto Scrum puede ser una ventaja competitiva frente a las demás empresas proveedoras de servicios en este mundo del desarrollo de software. Tengo claro que no debemos de tratar únicamente de cumplir con los requisitos del cliente cerrados en el contrato y punto final, si no asegurarnos que esos requerimientos son los que hacen "feliz" al cliente. En esa filosofía, la base de las iteraciones ayudan: el cliente pone el foco en lo que quiere realmente mucho antes.
Sin duda Scrum en estos momentos puede suponer una diferenciación en el mercado actual. Pero eso sí, posiblemente especializandose en determinado tipo de cliente. La estrategia ganadora no puede ser en este momento una diferenciación para todo el mercado, sino una especialización en un nicho muy concreto de clientes. ¿Aceptarían todos los clientes un desarrollo "Scrum"? ¿podrías competir con grandes consultoras en mega-proyectos? ¿puedes dar servicio a administraciones públicas que te piden METRICA3 (o 2)?... ¿interesa hacer todo esto?

Esta es solo una entrada de dudas/preguntas, pero mi opinión es que SCRUM es el buen camino, hacia el "norte verdadero" que nos decía Angel en su curso.

El círculo proceso-persona

Leyendo esta entrada sobre la idea recurrente de que lo más importante para hacer software son las personas, me ha venido a la cabeza una reunión de hoy que hemos tenido en Biko. Las mejoras en el desarrollo de software no se acaban nunca, y cuando tienes a medio hacer algo (podeis echar un ojo al documento libre sobre la implantación de técnicas ágiles con CMMI) ya estás pensando en lo siguiente.
Como decía, el post referenciado, me recordaba lo que hacemos cuando intentamos mejorar las cosas. En la mente tienes que lo importante son las personas, pero lo más facil ¿qué es? ¡¡Definir procesos!! Te pones a pensar: si hacemos las cosas así, o de esta otra manera, y luego nos sale esta otra situación, entonces lo que hay que hacer es... definimos cómo se debe hacer esto, para que después se haga igual...

Así que nos hemos ido a los procesos y parecería que nuestra intención es implantar CMMI nivel 4 o 5. (uf, y por cierto, no os olvideis de la encuesta, gracia). Yo siempre acabo diciendo que lo mejor es usar el sentido común, conociendo bien las herramientas disponibles y con la experiencia, se pueden tomar decisiones acertadas que son totalmente diferentes en el marco de un proyecto u otro. Pero siempre parece que tiras a definir los procesos, más que a pensar que la gente que tenga que resolverlos ya sabrá hacerlos, o que precisamente, a los que no sepan les vas a formar.

Es una dialéctica complicada, la de procesos contra personas planteada en el manifiesto ágil. Y cuesta romper. Supongo que tenemos hecha la cabeza de una manera (dura) que es dificil de cambiar la forma de pensamiento.
Todo esto está relacionado con lo que ya he comentado en otras ocasiones: ¿buenas prácticas o procesos? Al final, depende de la gente, a unos los puedes matar de aburrimiento siguiendo procesos muy formales, y a otros perderlos por el camino si no les pones las luces de aterrizaje bien claras.

Encuesta sobre CMMI

A raiz de este post que menciona que hay 85 empresas más en España este año que han obtenido una certificación CMMI, me ha picado la curiosidad, yestoy montando una pequeña encuesta con intención de recoger información de aquellas personas que trabajen en una empresa con certificación CMMI. He reducido bastante el número de preguntas que quería hacer, para que no se haga pesada (que es lo que a mi me suele echar atrás para rellenarla, sobre todo, ;) si como en este caso no hay premio por hacerlo).

Si te apetece, aquí tienes el enlace: Encuesta sobre CMMI.

Y si conoceis a gente que pueda encajar en el perfil para rellenarla, por favor, me encantaría que les distribuyeseis el enlace.
Obviamente, después publicaré los datos y la información que pueda extraer de ellos en esta misma página. ¡GRACIAS!

Dos cosas

Ayer recogí del correo el libro de Andrés Perez sobre MarcaPersonal. Me hizo mucha ilusión ver mi dedicatoria escrita en papel "de verdad". Me imagino que será como volver a leer de nuevo su blog, que ahora estaba pensando, es uno de los primeros que sigo desde el tiempo que llevo leyendo blogs. !Gracias Andrés, eres un crack!
No deberíais dejar de echar un vistazo al blog de Andrés, sobre todo si ahora en época de crisis os encontrais dudando sobre vuestras opciones profesionales.

Por otro lado, otra conexión con el mundo real por el blog, me invitan !por fin! a escribir un post a cambio de dinero. :D Bueno, a cambio de una suscripción a GTDagenda, que la verdad, tiene buena pinta, pero de momento me quedo con lo que tengo, ya que necesitaría dedicar un rato que ahora no tengo para probar el sistema. Bastante tengo perfeccionando mi implementación de GTD... Si alguien lo usa sí que me gustaría conocer sus comentarios, a mi de momento RTM me funciona bastante bien, con su buena integración con GMail.