Equipos vs. personas

Si algo me gusta de Scrum como metodología ágil es que intenta sacar el máximo potencial a los equipos. Entendiendo equipo no como un grupo de personas que trabajan juntas, si no como un grupo de personas que comparten una visión y una motivación que les une con lazos especiales.
La medición de métricas en Scrum está muy orientada al equipo: La velocidad y el burn-down son elementos a nivel de esta agrupación. Las personas son controladas por el mismo equipo de manera secundaria. Si en cada daily-scrum, se ve una persona que no avanza, hay motivos y datos para que el resto de personas le ayuden o le den un toque, pero el foco está puesto en el equipo.
Ya decía Alistair Cockburn que construir software es un juego cooperativo, que sin equipo no hay juego, o al menos no hay juego satisfactorio. Lean nos habla de la calidad en integridad conceptual, que se note que la calidad del producto por que aflora la integridad del equipo que lo realiza.
Ahora me pregunto yo cómo realizar métricas para evaluar el desempeño de las personas... por qué, ¿es necesario en un ambiente ágil? Las personas que no "funcionen" serán rápidamente detectadas por los equipos y no las querrán con ellos. ¿hay mejor métrica que esa?
Si las métricas personales dependen de las estimaciones, ratios de cumplimiento de sus tareas,... ¿es posible formar así un equipo con una motivación común? ¿no lo estaremos tensando demasiado? Supongo que debe haber un equilibrio, pero yo desde luego pondría má peso en el equipo. Nadie construye software solo.
En fin, más preguntas para Agile-Spain ;)

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.