Feed aggregator
Agile Open Spain 2010
Ya está aquí de nuevo el Agile Open Spain 2010, esta vez en Barcelona (campus de La Salle, C/ Quatre Camins, 30) el 12 y 13 de Noviembre de 2010 (en jornada de viernes tarde y sábado completo).
¿Que qué es el Agile Open Spain?, es la segunda edición (mira aquí si quieres saber más sobre la primera edición) de un evento organizado por voluntarios dentro y fuera de Agile Spain que será en formato Open Space. ¿Qué significa esto?, que el programa lo haces tú.
Muy brevemente, en un Open Space los asistentes se auto-organizan proponiendo los temas y programando una serie de reuniones (viernes tarde) que van a tener lugar justo a continuación (todo el sábado). Las reuniones pueden tener lugar simultáneamente y los asistentes son libres de decidir a qué sesiones quieren asistir y de cambiar de reunión en cualquier momento.
Será una excelente oportunidad para aprender y compartir experiencias. ¡No os lo perdáis!
Construyendo un laberinto de nombres para perdernos.
En los 80 se nos decía: 
"Cuanto antes empecéis a programar, más tarde terminaréis. ¿Cómo os ponéis a programar, sin analizar antes el problema, diseñar la solución y planificar el trabajo?. Empezáis sin
tener ni una página de requisitos, ni un análisis y una planificación
de los trabajos, y sus tiempos. ¿Os imagináis que un arquitecto hiciera
lo mismo?".
Aprendimos a hacer requisitos del sistema, especificaciones de
requitisos del software, planes de proyecto, gestión de riesgos,
matrices de trazabilidad. Y desde entonces nuestros clientes no pueden darnos planes de productos estables y nos piden re-inventar sus productos de forma continua.
Construyendo un laberinto de nombres para perdernos.
En los 80 se nos decía: "Cuanto antes empecéis a programar, más tarde terminaréis. ¿Cómo os ponéis a programar, sin analizar antes el problema, diseñar la solución y planificar el trabajo?. Empezáis sin
tener ni una página de requisitos, ni un análisis y una planificación
de los trabajos, y sus tiempos. ¿Os imagináis que un arquitecto hiciera
lo mismo?".
Aprendimos a hacer requisitos del sistema, especificaciones de
requitisos del software, planes de proyecto, gestión de riesgos,
matrices de trazabilidad. Y desde entonces nuestros clientes no pueden darnos planes de productos estables y nos piden re-inventar sus productos de forma continua.
Getting to Yes
Son incontables las ocasiones en las que tener bu
enas aptitudes de negociación puede ayudar a mejorar el resultado esperado: pedir un aumento de sueldo, facilitar determinados tipos de reuniones, vender una casa, vencer la resistencia al cambio, etc.
“Getting to Yes. Negotiating Agreement Without Giving In” es un libro que trata sobre cómo negociaciar y qué actitudes tomar en estas situaciones. Es un libro muy sencillo de leer con multitud de ejemplos que ayudan a entender los conceptos y, sobre todo, a poner al lector en situación.
No es que el libro diga nada asombroso que no sepamos de antemano o que se salga del sentido común, sin embargo, lo que hace muy bien es poner todo este conocimiento e ideas en contexto y explicar las razones para actuar una manera u otra en distintos contextos y escenarios.
Me ha parecido un libro interesante y entretenido que, creo, puede ayudar a mejorar las aptitudes de negociación de todo aquel que lo lea.
Scrum Manager, alternativa hispana y sin complejos
Scrum Manager da una visión de scrum amplia y flexible, la original de Nonaka y Takeuchi, que es diferente a la implantación concreta de la Scrum Alliance.
Scrum Manager y Scrum Alliance no son lo mismo. Las características de flexibilidad, globalidad, y síntesis entre la agilidad y el conocimiento anterior (CMMI, 15504...) así como la difusión abierta, y condicionada a la calidad son aportaciones de Scrum Manager, o cuando menos, otra forma de interpretar los entornos de trabajo que Nonaka y Takeuchi llamaron "campos de scrum(1)" hace 25 años, y de compartirlo y difundirlo.
Convencidos de que es un error monopolizar el concepto de campo de scrum. De que se encorseta y se empobrece al trocar los principios básicos(2) por prácticas determinadas de sprints, backlogs y reuniones; y de que se podían aportar mejoras sustanciales a lo carísimo del modelo "comercial" de formación scrum, y al criticado certificado scrum master, Claudia y el que suscribre nos decidimos a no sólo hablar de alternativas, sino a construirlas.
Y como, "¿Cuál es la diferencia con Scrum Alliance?" o "¿Qué aporta?", son preguntas frecuentes, cuando no críticas, :-( estas son, contadas con brevedad y objetividad, las razones de Scrum Manager:
1.-
AREA DE MEJORA DETECTADA: El enfoque de Scrum en el área de gestión de
proyectos está bien, pero un "campo de scrum" implica también al área de
programación o desarrollo de producto y también a la gerencia y
dirección de la organización. RESPUESTA: Scrum Manager contempla tres
áreas de conocimiento: Proyecto, Producto y Gerencia.
2.- AREA
DE MEJORA DETECTADA: El enfoque de la formación de Scrum Master sólo
muestra las prácticas scurm de la Scrum Alliance. RESPUESTA: Scrum
Manager presenta una síntesis de conocimiento entre procesos y agilidad:
un enfoque objetivo mostrando la agilidad como antítesis de los
procesos y las posibilidades que la síntesis de los dos conocimientos da
a un gestor: como "criterios de gestión" en lugar de "recetas de actuación".
3.- AREA DE MEJORA DETECTADA: La formación de Scrum
Alliance tiende a hacer olvidar el concepto original de campo de scrum y
monopolizar scrum como las prácticas que ella misma define,
empobreciendo las posibilidades de implementación de cada campo de scrum
de la forma más adecuada a cada organización. RESPUESTA: Flexibilidad.
Es un principio de Scrum Manager: adecuar las prácticas ágiles a la
empresa, y no al revés.
4.- AREA DE MEJORA DETECTADA: Los
certificados de la Scrum Alliance se obtienen sólo por pagar los 1.000 o más que vale el curso de 2 días. Puede acudir una persona sin entender inglés
a un curso scrum manager dictado en inglés, no entender nada y sin ningún examen ni comprobación lograr la certificación Scrum Master. RESPUESTA: Un modelo enfocado en la
formación, que permita incluso lo contrario: poder aprender y obtener un
certificado acreditando que se sabe, de forma gratuita. (http://www.scrummanager.net/ok).
Los certificados de Scrum Manager requieren un examen y actualmente un
20% de los presentados los suspenden y no obtienen la certificación.
5.-
AREA DE MEJORA DETECTADA: Servicios profesionales presenciales
(franquiciados) centrados en el negocio,que exigen una tasa de franquicia para dar formación, generando como
consecuencias: a)encarecimiento de los costes normales de un curso
presencial, b) formadores más centrados en el negocio que en los
resultados de los alumnos. RESPUESTA: modelo partnership de Scrum
Manager sin canon de entrada ni cuota de mantenimiento. Concesión otorgada y mantenida por la valoración de calidad de los cursos (http://scrummanager.net/qa).
Consecuencia: los formadores tienen como principal interés ofrecer
formación de calidad, (la valoración media de los cursos presenciales
actualmente es > 8 ) y el modelo garantiza que un formador que no
ofrece calidad no puede trabajar con Scrum Manager.
6.- MODELO
DE CERTIFICACIÓN "PARCO": Me explico: con dos días de formación, (aun
suponiendo que sea de calidad y con examen) ya se es "ágil certificado" (?),
sin marcar ningua apreciación de grado. Un profesional puede,
además de conocer el "scrum clásico" saber también de gestión de
equipos, producto, recursos humanos, cultura ágil, o de prácticas de
programación ágiles: integración continua, TDD, etc... Decir que una persona es Scrum Master, no es decir mucho de cuánto sabe de agilidad.
RESPUESTA: Modelo de certificación con puntos de autoridad. La
certificación Scrum Manager va vinculada a un grado de autoridad, que
es proporcional a las áreas de conocimiento acreditadas.
He
intentado sintetizar, y escribiendo un poco a vuela pluma. Seguro
que me dejo cosas, pero creo que en conjunto este es el mapa general de
razones y diferencias entre Scrum Alliance y Scrum Manager.
(1) "Moving the Scrum Downfield" - The New New Product Development Game. (Hirotaka Takeuchi and Ikujiro Nonaka. 1986)
(2) Built-in instability - Self-organizing project teams - Overlapping development phases - Multilearning - Subtle control - Organizational transfer or learnig.
5 factores ágiles en la capacidad de respuesta de Facebook
Robert Johnson, director de software de Facebook, afirma que de los 7
principios clave que han hecho posible al equipo de programación dar
respuesta al ritmo de crecimiento del proyecto, 5 tienen que ver con las
personas y su cultura de trabajo en equipo.
Estos son los números de Facebook a fecha de hoy:
- 500 millones de usuarios activos.
- 100 mil millones de hits diarios.
- 50 mil millones de fotos.
- 2 trillones de objetos cacheados, con cientos de millones de peticiones por segundo.
- 130 TB de logs diarios.
Y estas citas de su nota: Escalando Facebook hasta 500 millones de usuarios y más allá:
Respuesta rápida.
"La mejor manera para lildiar con las sorpresas continuas es tener equipos de ingeniería y operaciones que sean flexibles para poder resolver los problemas rápidamente. La capacidad de respuesta rápida también nos permite pobar muchas cosas para ver cuáles funcionan realmente en la práctica. Hemos encontrado que el mantenimiento de esta flexibilidad es mucho más importante que cualquier decisión técnica".
Cambios incrementales.
Este principio va más allá del principio de evolución de producto ágil: iterativa e incremental. Se refiere también al despliegue y puesta en producción:
"Tratamos de desplegar de forma incremental. Esto puede significar para unos pocos usuarios, o para una pocas máquinas a la vez, o incluso la construcción de un nuevo sistema en su totalidad en paralelo con el antiguo, y desplazar el tráfico poco a poco, mientras medimos los efectos".
Equipos pequeños e independientes.
"Tenemos tres personas que trabajan en fotos. Cada una de ellas conoce todo lo relativo a fotos perfectamente y puede tomar decisiones al respecto, así que cuando hay que cambiar algo relativo a fotos lo podemos hacer rápidamente y bien".
Control y responsabilidad.
"Ninguno de los principios anteriores funciona sin equipos de ingenieros capaces de trabajar y resolver problemas, juntos y sin problemas. Esto es mucho más fácil de decir que de hacer, pero tenemos un principio general que es tremendamente útil: La persona responsable de hacer un trabajo debe tener control sobre él".
¿Quién es responsable de la calidad?
(Este artículo parte de los comentarios realizados en un hilo del foro de Agile Spain)
El equipo es el responsable de proporcionar un producto de calidad, no se puede escudar en etapas posteriores de verificación de calidad o en las pruebas de aceptación del cliente (Product Owner) para no garantizar la calidad del producto que ha construido.
Profundizando en base a la terminología de la ISO9126 de calidad de producto en ingeniería del software:
- La calidad en uso (satisfacción del usuario, efectividad, productividad, seguridad) es un aspecto a verificar por el Product Owner que, además de ser representante de los usuarios finales, también debe asegurar que el producto cumpla con las necesidades del negocio y estratégicas de los stakeholders del proyecto.
- La calidad externa (funcionalidad, usabilidad, eficiencia, mantenibilidad, fiabilidad, portabilidad) en algunos aspectos es más difícil de verificar por el Product Owner.
- La calidad interna no suele poder ser verificable directamente por el Product Owner.
Como comenta Xavier Quesada en el mencionado hilo, “[allí donde la calidad externa e interna no es observable] el equipo tiene una obligación básica de desarrollar un producto, un software, de calidad, o sea el Product Owner no debe convertirse en el Tester/QA del equipo”.
Si es necesario, el Product Owner se puede servir de diversos mecanismos de apoyo para verificar la calidad externa e interna del producto como, por ejemplo, una auditoría experta. En el caso de desarrollo de software, se trataría de una auditoría del código fuente, patrones arquitectónicos utilizados, trazabilidad entre requisitos (o historias de usuario) respecto a los casos de prueba de aceptación (condiciones de satisfacción) y otros modelos o entregables, etc.
Según se indica en la guía oficial de Scrum, “el Scrum Master entrena y guía al equipo para que sea más productivo y entregue productos de mayor calidad”. Al ser el responsable de la calidad en el proceso, el Scrum Master guía al Product Owner y al equipo para conseguir que:
- El Product Owner (re)priorice en función del valor aportado al negocio (y el coste de implementación).
- El equipo cumpla con la definición de hecho que ha sido consensuada con el cliente.
- El Product Owner revise el producto al final de cada iteración, en la reunión de Demostración de los requisitos completados.
- El equipo tome consciencia del producto que está entregando (si cumple con las expectativas del Product Owner, si se está degradando la calidad externa e interna y se está introduciendo “deuda técnica” que dificulte su crecimiento sostenido) y guiarlo para que reaccione si hay problemas (como menciona Xavier Quesada), especialmente en las reuniones de retrospectiva al final de cada iteración. Agilidad es reaccionar ante los impedimentos, problemas, equivocaciones o errores y tomar acciones correctoras, no “mirar a otro lado”, como diría Ángel Medinilla.
Enlaces relacionados
Kanban como herramienta para Scrum
Presentación de Kanban como una herramienta, para entornos ágiles: definición y explicación de un posible ejemplo de uso: kanban boxes.
He tenido una idea: “Una historia exquisita”
Realizando un sueño: Scrum Manager
Nos gustan mucho los campos de scrum, y para aportar un modelo de formación asequible y una certificación que no se logre sólo por pagar, que pueda conseguirse incluso gratis, pero que realmente acredite el conocimiento, nos pusimos manos a la obra, ahora hace sólo un año: Primer Año de Scrum Manager .
Gracias a todos por vuestro apoyo. :-)
Las cuatro inteligencias
El objetivo es seguir la menor cantidad de reglas
Tres principios de liderazgo
Las 18 lecciones de liderazgo de Colin Powell son frecuentes en textos de gestión, management(?) o liderazgo. Dejando de lado consideraciones sobre "consejos-receta", si tuviera que elegir las tres que más me gustan, serían, por este orden, y con esta traducción:
1.- Lección 8: La Organización no es la que consigue los logros. Los planes y las teorías de gestión no sirven de mucho. La gente es la que hace triunfar o fracasar a las empresas. La mayoría de los gerentes afirman que su mejor activo es su gente, pero en realidad ¿cuántos son los que se preocupan por crear ambientes que atraigan y retengan a los más capaces, creativos y productivos, donde se les permita dar rienda suelta a su creatividad e ingenio sin ataduras?. En la economía de hoy lo realmente importante, por encima de modas administrativas o teorías gerenciales es la gente que realiza los proyectos. Sólo los líderes que atraen a los mejores logran los mejores resultados.
2.- Lección 11: No busque los estereotipos. Deje de ir a la caza de las modas de gerencia. No exsiste el modelo o la filosofía administrativa para asegurar el bienestar general de una empresa. Seguir las teorías de gerencia de moda, no sólo es peligroso por los cambios que pueden presentar, sino que produce desconfianza en la dirección y rigideces en la visión y la acción. Los líderes deben ser flexibles, comprender que los modelos de gestión no son lámparas de aladino, sino recursos de cierta utilidad a las que se puede acudir en determinadas situaciones.
3.- Lección 14: Los buenos líderes son casi siempre buenos simplificadores, que pueden atajar debates, dudas y discusiones ofreciendo una solución que todos puedan entender. Tienen respuestas claras, sin ambigüedad, y con firmeza que transmiten al grupo, dando credibilidad e integración en la organización. Los buenos líderes mantienen las cosas sencillas. No se complican.
Me recuerdan:
1. Preferimos el valor de las personas al de los procesos...
2.- Flexibilidad
3.- Lean Management, KISS...
La estrategia del emprendedor ágil en cuatro citas de Kasparov
Haciendo collage con estas 4 citas de Garry Kasparov ("Cómo la vida
imita al ajedrez ") veo la estrategia de un emprendedor ágil. Esto es obsesivo ;-)
LA VISIÓN
"El estratega empieza con un objetivo para un futuro lejano y trabaja retrocediendo hasta el presente."
LA TÁCTICA
"Si jugamos sin objetivos a largo plazo, nuestras decisiones se convierten en exclusivamente reactivas y nos vemos jugando el juego de nuestro oponente, no el nuestro. Mientras saltamos de una cosa nueva a la siguiente, acabamos por perder el rumbo, impelidos por lo que tenemos delante, en lugar de por los logros que necesitamos."
ITERACIONES Y RETROSPECTIVAS ESTRATÉGICAS
"Evalúa cuál será el resultado de su posición y establece una meta. Luego va paso a paso hasta conseguir su propósito."
"Los objetivos intermedios son esenciales, son los ingredientes necesarios para crear condiciones favorables para nuestra estrategia."
Cas 2010 - Día 2
Para empezar, uno de los platos fuertes de la conferencia: una mesa redonda de expertos donde se debatiría sobre el actual estado de las metodologías ágiles en España. Con participación de representantes de la industria, de la universidad y con algunos conocidos agilistas de la comunidad (Ángel Medinilla, José Manuel Beas y Xavier Quesada), lo que pretendía ser un apasionado debate, se quedó en algo un poco más descafeinado, debido a la poca controversia y diferencia de opiniones entre los ponentes. Por otra parte,me sorprendió gratamente ver que desde la Facultad de Informática de Madrid (FIUPM), teniendo en cuenta que la universidad es una institución eminentemente waterfall, se está apoyando y se está colaborando fuertemente en diferentes programas y de diferentes formas las metodologías ágiles.
En cuanto a las sesiones, igual que el primer día todas fueron de un gran nivel. En esta segunda jornada me centré más en sesiones a nivel de gestión o metodología y no tan centradas en prácticas de ingeniería, asisitiendo a Gestión de Ágil de Equipos e Itinerario de Implementación Ágil en la Empresa( Angel Medinilla) , Gestión ágil de requisitos (José Luis Soria), Prácticas recomendadas para la relación Cliente-Equipo... (Juan Garbajosa y Agustín Yague) y Diez maneras infalibles de asesinar Scrum (Rodrigo Corral).
Todas ellas excelentes, aunque me quedé con ganas de asistir a la sesión de Fórmula-1 y a la de TDD, pero la imposibilidad de dividirme en 2 personas, me obligó a tener que elegir unas y descartar otras!
Para finalizar, una sesión de retrospectiva, donde los asistentes podíamos decirle a la organización aquellas cosas que considerábamos se podían mejorar, aquellas que no nos habían gustado y claro está, las que se habían echo bien!! Una gran manera de involucrar a los asistentes a la vez que de intentar mejorar para futuras ediciones!
Como conclusión final, una gran conferencia, que ha sido todo un éxito tanto de asistencia como de contenidos (a mi juicio). Es estimulante saber que hay mucha gente que comparte las mismas inquietudes profesionales que tú, y es de esperar que eventos de este tipo ayuden a difundir el mensaje de que las metodologías ágiles pueden ayudar a las empresas que desarrollan software, no sólo, a ser más productivas y competitivas, sino a hacer del trabajo algo mas sostenible, motivador y ¿por qué no? , divertido!!
Un saludo!!
CAS2010. Todo un éxito
El pasado jueves y viernes se celebró la primera conferencia sobre prácticas y métodos ágiles en España, la CAS2010.
Como uno de los organizadores, estoy muy orgulloso de lo que hemos hecho y del resultado aunque haya habido errores y haya cosas que mejorar para próximas ediciones. Lo mejor, sin duda, los participantes que son quienes han hecho que la conferencia haya sido un éxito. En total se han superado los 250 participantes entre asistentes, ponenetes, patrocinadores, etc. Además, y muy a nuestro pesar, tuvimos que dejar cerca de 50 personas fuera por la limitación de las instalaciones.
Creo que hay que destacar el buen ambiente, la posibilidad de conocer a mucha gente, el buen nivel de la mayoría de las sesiones y talleres y el empujón que se ha dado a la comunidad y a las nuevas comunidades locales. Personalmente, me he perdido muchas de las sesiones a las que tenía intención de asistir debido a tareas organizativas (habilitar la wifi, impresos de última hora, indicaciones, etc.) como, por ejemplo, el juego de simulación de Teresa Oliver (Pragmatic) o la sesión “One year of software developments to win a world racing championshi” de Luca Minudel.
Sin embargo, poco a poco iremos poniendo videos de algunas sesiones (como la key note de Henrik Kniberg, la mesa redonda y algunas otras), las presentaciones, fotos y podcast para todos aquellos que, como yo, no han podido atender a las sesiones. Ahora mismo se están agregando a http://groups.google.es/group/agile-spain/web/agilespain2010 si queréis hechar un vistazo.
Muchas gracias de nuevo a todos los participantes y a los patrocinadores, sin ellos, la conferencia no hubiera sido posible.
Finalmente, como agradecimiento a todos los organizadores y voluntarios que han trabajado mucho en esto, han puesto mucho esfuerzo y tiempo de sus horas libres, dejo este video. Que lo disfrutéis.
CAS2010: Preparativos y “networking” from Agile-Spain on Vimeo.Así es el campo de Scrum en el que trabaja frogtek
NOTA: CAMBIO DE FECHA Organizado por Agile Spain Zaragoza , con la iniciativa de Teresa Oliver , el próximo jueves, 17 de junio de 6 y media a 8 y media de la tarde Frogtek presentará su forma de trabajar.
¿Donde?. En el edificio del ITA (Instituto Tecnológico de Aragón) en María de Luna, 8, Zaragoza.
Para ir haciendo ganas:
MODIFICACIÓN (15-Junio): Teresa anuncia que se cambia la fecha al lunes 21, también a las 18:30.
Prácticas ágiles según el análisis semántico de Google
Aún está bastante tierno esto de cribar la red con criterio semántico, pero empieza a tener su gracia. Si le preguntas a Google Squared por prácticas ágiles, la respuesta en el momento de escribir este post es:
- Integración continua
- TDD
- Scrum
- Refactorización
- XP
- RUP
- Flirting
- Programación en parejas
- Testing
- Historias de usuario
Nota: No darle más valor del que tiene como curiosidad. A mi por ejemplo RUP me chirria un poco como ágil, y con Flirting no se está enterando muy bien. Allá cada uno :-)
Agente de Cambio: Introducción (I)
En nuestra empresa hemos usado Scrum... y ¡ no funciona !
¡
Lo he probado, y no funciona!.
Esta es
la razón por la que el director de proyectos de una empresa argentina,
afirmaba que prefería CMMI, porque Scrum, simplemente no funciona. Comentándolo con Claudia, nos recordaba este vídeo de formación de Scrum Manager, y lo comparábamos con alguien que acostrumbrado a tocar con pianola, sentenciara: Mucho mejor las pianolas. Yo he probado también con pianos... y no funcionan. :-)
