diciembre 29, 2009

Quinto cumpleaños

Hoy hace cinco añitos este blog. Casi abandonado y en la pobreza de posts sobrevive a mi poca dedicación al mismo. Pensaba que este año había sido el más triste en el mundo Najaraba, pero ahora he visto que el 2007 fue incluso más parco en la publicación de posts.
Así que solo saludo al personal que siga leyendo este blog, y que informo que sigo vivo :)
Aunque este año ha ido bastante activo en otras areas de "lo ágil", publiqué un par de artículos, en REICIS y en CES Navarra. Di una charla en la Navarparty, y sobre todo, he colaborado en la fundación de agile-spain y su primer evento. Así que aunque no me leais mucho por este blog, podeis verme por otros lados.
Por otra parte, me da rabia no haber terminado mi serie sobre Lean, y no poder dedicar más tiempo a leer y comentar mis experiencias en el desarrollo de software.
Este año incluso me abrí una cuenta de twitter :) , y sobre todo, intento dedicarle mucho más tiempo a mi hijo!!
¡Os deseo un feliz 2010!

octubre 25, 2009

Primer Agile Open Spain: Fabuloso #agileopenspain2009!

Pues finalmente llegó el Agile Open Space, y pasó rapidisimo de lo interesante que resultó.
Después de unas semanas de ajetreo con la organización, finalmente validamos nuestras expectativas. Afluencia masiva de los inscritos, y muchísimo nivel en las charlas organizadas el sábado.
El viernes, tras los últimos detalles de preparación del evento, empezó a llegar la gente hacia las 18:00, y a las 18:30 empezó la presentación del evento. Agustín Yagüe hizo de maestro de ceremonias, ya que se celebraba en "su casa", y Jose Manuel Beas y Xabi Albaladejo dieron unos pequeños discursos de presentación de Agile-Spain y la agilidad. Creo que Jose Manuel Beas estaba realmente emocionado de ver tanta gente congregada en este evento, y no era para menos.
Así que tras las presentaciones y un pequeño piscolabis -- gracias a los patrocinadores, de los cuales Biko era uno de ellos-- , se procedio a presentar los spaces que cada uno quería hacer. Aquí fue cuando realmente respiré tranquilo, y se vio que el evento iba a funcionar: una cola de gente para presentar y finalmente más de 50 sesiones ("únicamente" había 30 slots de tiempo disponibles). Tras preparar las sesiones para el sábado en el panel, se cerró el día.
La gente de la organización nos fuimos a cenar el viernes, me encantó volver a charlar con los que un día nos juntamos hace 7 meses para mover el tema de Agile-Spain, conocer a Carlos Ble y disfrutar de una cena muy agradable, aunque fuese de trabajo! :)

El sábado empezó con el desayuno en la UPM, para tomar fuerzas mientras podías repensar las sesiones a las que asistir mirando el panel. Se habían distribuido 6 sesiones simultaneas, durante 5 franjas temporales, 3 por la mañana y 2 más retrospectiva después de comer.
Las sesiones a las que asistí fueron muy interesantes y participativas. Además se respiraba camaradería y ganas de aprender. Nos movíamos rápidamente entre el panel para tomar las últimas decisiones de asistencia y las salas de los spaces. Se compartieron muchas experiencias, conocimientos y también muchas preguntas interesantes.
Las sesiones a las que asistí fueron:
  • Lean: Era una sesión propuesta por Robyn Dymond, que lamentablemente no llegó a tiempo. Pero X. Quesada condujo la sesión a buen puerto. Hablamos de los principios de Lean, y nos preguntamos cómo aplicarlos a la empresa.
  • El factor humano: Daniel Lopez (creo que era su nombre) nos habló de las personas, que son las que soportan las cabezas pensantes de los desarrolladores, y hay que tenerlas en cuenta. Hizo una dinámica muy divertida, como ejemplo del castigo contra el premio como forma de motivar a las personas.
  • Telefónica: Mónica Izquierdo y Carmen Lasa nos hicieron una presentación sobre la implantación de Scrum en Telefónica I+D. Muy interesante por que ciertamente va muy en paralelo con la implantación que estamos haciendo también en Biko, y charlamos un rato después durante la comida, y los problemas y retos son muy parecidos.
  • Agile Coaching: Se trataba de debatir sobre las funciones de un Agile Coach, y ciertamente lo que más claro quedó, es que no estaba claro. Había varias versiones sobre lo que se suponemos que hace un coach Agile, yo creo que se perdio un poco el rumbo de la sesión por que se mezcló con la idea de un coach personal o de marca propia.
  • Externalización y outsourcing: Angel Medinilla condujo una sesión para contar experiencias sobre proyectos de este tipo, sacando unas conclusiones finales.
En definitiva, una experiencia como conferencia. Podeis buscar más comentarios, fotos, etc. en la web de agile-spain. Pronto tomará forma la asociación, y ya estamos preparando nuevos eventos, así que no descansamos ;). Súbete al carro del agilismo, y únete a Agile-Spain!

octubre 15, 2009

Artículo en REICIS

Han publicado la revista REICIS --"Revista Española de Innovación, Calidad e Ingeniería del Software"--, y en este número me han incluido un artículo, titulado "Las metodologías ágiles como garantía de calidad del software". Espero que os guste!
Lo podeis encontrar en: http://www.ati.es/spip.php?article1328
Muchas gracias a Jose Manuel y Carlos, que me ayudaron a darle el toque final de calidad ;)

octubre 06, 2009

Charla sobre desarrollo de software ágil (2)

Aquí os dejo la charla que di el otro día en la Navarparty, junto con una breve descripción de lo que conté, sin entrar en detalles. Teneis el video disponible en la web de la Navarparty.



[2] Generalmente se presentan los típicos problemas en el desarrollo de software, en los que caemos una y otra vez, como razones para cambiar a lo ágil: clientes insatisfechos, equipos quemados, calidad insuficiente, fechas nunca alcanzadas,...
[3] pero aquí prefiero dar dos razones por las que creo que las metodologías ágiles se adaptan mejor.
[4] Por que creo que primero, el producto es equivalente al equipo que lo ha creado, y que el producto de un gestor de proyectos es crear un equipo, y que
[5] el software es un juego colaborativo. [6] Estos dos libros inciden en estas ideas.
[7] Así que ahora debemos elegir el nuevo camino, tomar la pastilla azul que ofrecieron a Neo (jope, ¿o era la roja?).
[8] Las metodologías ágiles más comunes fueron creadas en los 90,
[9] pero el manifiesto ágil les dio el espaldarazo definitivo.
[10-15] El manifiesto ágil condensan en cuatro frases los conocimientos y experiencias en gestión de proyectos de software de algunos de los mayores expertos en este mundo.
[16-22] Y los principios que se desprenden de ellos son las bases de estas metodologías.
[23] ¿cómo podemos llevar al terreno práctico estas ideas?
[24] Aplicando por ejemplo este esquema metodológico (como ejemplo, no olvidemos que hay muchas metodologías ágiles), que actua a nivel técnico, sobre el ecosistema software (prácticas de XP) , a nivel de gestión de proyecto (Scrum), y a nivel organizativo (aplicando los principios de Lean).
[25-35] XP nos da herramientas para garantizar una buena calidad e integridad de los desarrollos (TDD, Integración continua, Pair programming) , pero no debemos olvidar que puede ser tomada como una metodología de gestión completa. Lean nos da unos principios que buscan mejorar la organización en todos sus niveles. Y Scrum, la metodología "de moda", nos da el framework para gestionar los proyectos centrándonos en la entrega de valor al cliente y la mejora continua.
[37] Dos palabras básicas para ser ágiles: confianza y colaboración.
[38] ¡No olvides visitar agile-spain!

http://najaraba.blogspot.com/2008/02/el-producto-es-el-equipo.html
http://www.amazon.com/Software-Your-Head-Protocols-Maintaining/dp/0201604566
http://alistair.cockburn.us/Software+development+as+a+cooperative+game
http://agilemanifesto.org/
http://www.extremeprogramming.org/
http://www.proyectosagiles.org/que-es-scrum

http://poppendieck.com/
http://www.agile-spain.com

septiembre 23, 2009

El arte de la guerra

Tenía curiosidad hace tiempo por leer "El arte de la guerra", de Sun Tzu, un libro muy conocido que es un tratado sobre la estrategia de la guerra. No soy muy belicista, pero es sin duda un libro que merece la pena leer, curioso.
El caso es que he leido un par de versos que me han resultado similares a situaciones que se viven muchas veces en los proyectos:

Capitulo III: Estrategia Ofensiva
19
Existen tres caminos con lo que un soberano puede
llevar a su ejercito al desastre
20
Cuando ordena al ejército que avance o retroceda,
ignorando que es estratégicamente inadecuado. Esto se
describe como "maniatar al ejercito".
21
Cuando se inmiscuye en los asuntos militares sin el
conocimiento necesario. Esto confunde a los oficiales.

Sustituye soberano por político|director general|CEO, ejército por equipo, y oficial por jefe de proyecto... :D

septiembre 20, 2009

Charla sobre ágiles en la Navarparty

Este viernes, 25 de Septiembre de 2009, 17:30, estaré en la Navarparty, en Pamplona, dando una charla introductoria a las metodologías ágiles.

Las conferencias son de libre acceso para todo el público y se realizarán como el año pasado en la sala 04 (Fernando Remacha) del Edificio del Sario, anexo al Pabellon deportivo de la UPNA donde se celebra la Navarparty 7 (ver mapa )
La charla va a ser de introducción, contaré los principios ágiles, un poco de historia y algo de Scrum, lo típico para explicar en qué consisten, y por qué creo en estas metodologías. :)
Agradezco a la organización su confianza con su invitación, y espero veros por allí!

septiembre 10, 2009

Buscamos desarrolladores JAVA para Biko

En Biko estamos ampliando el equipo JAVA en San Sebastian (Guipuzcoa). Si quieres trabajar con nosotro, escríbemos a unete[at]biko2.com, referencia "desarrollo JAVA".

¿Qué hacemos? Desarrollamos productos con metodologías ágiles, intentamos mejorar tras cada retrospectiva, estamos en implantación de TDD, utilizamos integración continua,... nuestro ecosistema software es: Maven2 + SVN + Hudson + JIRA (GreenHopper). Y las herramientas de desarrollos, las más típicas, Spring e Hibernate, y el viejo Struts que pronto debemos migrar. (¿te atreves a venir a decirnos a cual y enseñarnos?)
Bueno, meto esta cuña publicitaria para encontrar (Septiembre 2009) gente que se venga a trabajar con nosotros. Nunca había comentado cosas en el blog de la empresa, pero quizás os interese este tema.

agosto 11, 2009

Ven al Agile Open Spain: 23 y 24 Octubre

Se va a organizar el primer evento a nivel nacional de Agile-Spain, os copio el texto que podeis encontrar en la propia web.

Con los objetivos de difundir las metodologías ágiles en España (Scrum, eXtreme Programming. Lean Software Development) y compartir experiencias, el viernes 23 de octubre por la tarde y el sábado completo tendrá lugar el primer Agile Open Spain en las instalaciones de la Escuela Universitaria de Informática en el Campus Sur de la Universidad Politécnica de Madrid. Ctra Valencia Km.7. 28031 Madrid (Localización Google Maps)

El Agile Open Spain es un evento sin ánimo de lucro organizado de manera muy participativa. Esta diseñado para compartir entre los asistentes sus experiencias, ideas, experimentos y retos sobre metodologías ágiles (despliegue, planificación ágil, retrospectivas, ingeniería, herramientas, gestión de producto, calidad, etc.), basándonos en el formato de Open Space, para promover la colaboración y que la conferencia se convierta en aquello que sus asistentes deseen. No existe una agenda fijada, sino que entre todos crearemos la conferencia, elegiendo temas y participando. Contaremos con algunas de las personas que más saben de metodologías ágiles en España, así que ten por seguro que la conversación será interesante.

Si quieres:

  • Compartir tus experiencias como experto o principiante en el uso de prácticas Ágiles.
  • Escuchar a algunas de las personas que más saben de metodologías ágiles en España.
  • Encontrar el futuro antes de que éste te encuentre a ti.

entonces, inscríbete aquí (notar que el evento es gratuito pero las plazas son limitadas).

julio 22, 2009

¿somos ingenieros los del software?

Seguro que ya te has enterado del revuelo que se ha armado con el artículo en IEEE de Tom diMarco, sobre su cambio de parecer con el control y métricas en los proyectos de software.

Las métricas que inicialmente expuse en mi libro Controlling Software Projects: Management, Measurement and Estimation, han definido la forma en la que muchos ingenieros construian el software y planificaban el trabajo. Con un ánimo de estado reflexivo, ahora me pregunto: ¿Fué correcto el asesoramiento en métricas? ¿Sigue siendo pertinente? y ¿creo todavía que las métricas son una necesidad para el éxito de cualquier desarrollo de software?. Mis respuestas son no, no y no. [*]
Yo no creo que sea un cambio en el parecer de Tom, no tienes más que leer PeopleWare escrito 20 años más tarde que el tema de control y métricas en los proyectos de software, para darte cuenta de su evolución.
El post que más me ha gustado sobre este tema ha sido el de Juan Palacios, y coincido en gran medida con lo que explica en él. El verdadero bombazo ha sido otro post de coding horror, preguntando si la ingeniería del software está muerta, y entronca con el nuevo movimiento que defiende al mundo del desarrollo de software como "artesanía". No sé, quizás debería ser una ciencia experimental -Conocimiento ordenado y, generalmente experimentado, de las cosas- de manera que vayamos aprendiendo posibilidades de hacer bien las cosas...
Cuando salía de la carrera, siempre recalcaba que no era informático, si no -ingeniero- informático. Ahora, aunque esté mal visto, siempre digo que me gusta programar, pero que hay que saber las bases matemáticas y conceptuales necesarias para hacerlo bien. La respuesta a esto muchas veces suele ser: "¿pero los ingenieros seguís programando tras 10 años de experiencia? (sic)
  • La ingeniería entendida como un conjunto de procesos plausibles y realizables para solventar un problema, no existe -todavía!- en la informática. Algunos pensaron que CMMI-5 lograba eso, pero se equivocaron.
  • La ingeniería civil trasladada al control de proyectos de software no es lo adecuado para todos los proyectos. El "rebote" de las metodologías ágiles así lo confirman.
  • Las métricas están sobrevaloradas en los proyectos de software, y sus equipos. Forman parte de una burocracia que genera poco valor cuando se abusa.
  • No se trata -o no debería tratarse- de una guerra entre bandos. Somos niños con un juguete nuevo, y cada uno cree que se usa de una manera diferente. Debemos aprender.
  • Hay una parte de "juego cooperativo", de "problemas sociológicos" que se ha olvidado en la gestión de proyectos tradicional.
  • Las metodologías ágiles resuelven algunos problemas, pero no tardarán en salirles puntos débiles, debemos auncar esfuerzos para seguir mejorando.
Finalmente, cada proyecto es diferente. No solo por que el resultado deba ser diferente, si no por que se va a realizar con equipos diferentes. Quizás todos los proyectos del mismo tipo podrías gestionarlos igual, pero nunca gestiones igual equipos diferentes. Debes estudiar personas, perfiles, intereses,... y eso es dificilmente medible. Ignoro si CMMi, por ejemplo, tiene un area de trabajo sobre este tema, la creación de verdaderos equipos de trabajo. Un libro sorprendente en este area, que me recomendó Mario, es Software for your head. Se supone que habla de desarrollo de software, y "solo" ¡de gestión de equipos!

PD: Seguiré con mis posts sobre Lean que prometí, pero ha sido una temporada dura!

mayo 19, 2009

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 ;)

abril 26, 2009

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í!

marzo 25, 2009

Scrum y TDD

En realidad este post es solo dos anuncios ;)

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.

marzo 19, 2009

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... ;)

marzo 16, 2009

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.

marzo 03, 2009

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

febrero 26, 2009

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.

febrero 16, 2009

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


febrero 10, 2009

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" ;)

febrero 08, 2009

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:
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

febrero 02, 2009

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.