Siguiente con el post anterior:
Día 2
1. Ser ágil en España, un caso real con equipos de trabajo en remoto (Enrique Amodeo y Antonio David Fernández Reyes)
No voy a ser pelota de nadie, pero para mi una de las mejores sesiones. ¿Por qué? Porque laguien se atrevió a poner encima de la mesa lo difícil que es trabajar con metodologías ágiles, los intentos que ahces, los problemas que te encuentras y cómo te adaptas para mejorar. Y la mejora no se hace de un día para otro, hay mucho trabajo por detrás, muchas decisiones y mucho trabajo de comercial o psicólogo para convencer hacia arriba de que ese es el camino y al final se demuestran con hechos los beneficios.
Algo a destacas de la CAS2010 ha sido la presencia de casos reales como esta sesión y la siguiente. Y hay que ser valiente para pnerte delante y decir: empezamos así y nos equivocamos, y cambiamos y mejoramos.
Dejémonos de historias de éxito sin contar porqué es difícil, dejemos la teoría que muchos ya la han puesto en libros. Si yo quiero empezar con Scrum quiero saber qué problemas voy a tener y cómo solucionarlos, sabiendo que cada caso tendrás sus cosas.
En este caso la complejidad residia en tener un equipo distribuido, cn muchos kilómetros de distancia de Madrid. Entre los primeros puntos que nos hablaron estuvieron la experiencias previas, la implicación del equio y sobre todo la dificultad de la visibilidad del avance. Aquí entraron a explicar las diferentes herramientas que evaluaron.
Tras esta fase detectaron una serie de fallos, como que el Scrum Master estaba en Madrid, la estimación se hacía a mano alzada...
En esta segunda aproximación detectaron que los sprints no se respetaban por el número de incidencias urgentes que alargaan el sprint, no exitía el Definition of Done lo que provocaba malentendidos...los pases de entorno se volvían imposibles.
La solución que aplicaron fue TDD, SM en el equipo remoto, optimizar builds y dependencias con el uso de Maven, Hudson+Sonar y Sprint inamovibles, para ello se contó con un Product Owner más involucrado en el proceso.
Y como en todo este proceso late la mejora continua, tras estas fases siguen plantenado cambios para mejorar, queriendo incluir Kanban, Repositorios distribuidos (Git), Pair Programming, optimizar el tiempo de entrega, no de recursos...
La presentación la podéis encontrar en esta dirección.
2. One year of software developments to win a world racing championship (Luca Minudel)
¿Sabíais que los grandes equipos de Formula 1 trabajan en sus departamentos de Software con metodologías ágiles? Increible ver esta charla de Luca como miembro del equipo de Ferrari y que nos dijo que en McLaren también lo hacían y en Renault también...hasta que se han quedado sin presupuesto, porque eso de hacer release que luego tenías que tirar o modificar no lo puede hacer todo el mundo...sin dinero.
Trabajan en la nueva temporada sin esperar a que termine la actual, sin conocer la nueva regalmentación y a tope para poder ir sacando mejoras de su actual sistema. Cuando llega la regalmentación tienen que adaptarse y cambiar y mejorar, cuando llegan las carreras tienen que comparar resultados con los rivales y volver a mejorar. La verdad es que el nivel de incertidumbre y de cambio hace que las iteraciones sean una locura pero con Scrum consiguen tener release tempranas y adaptarse a los cambios que el entorno tan agresivo les empuja a tener.
3. Probando tu TDD (Juan Gutiérrez y Carlos Blé)
No tenía en mi hoja de ruta esta sesión, pero estando Juan y Carlos en ella me dejé llevar por mis compañeros de Agile-CyL allí. Tras una buena comida y con cierto sopor me encontré con que tenía que programar. Fue una sesión muy muy interesante y con un mensaje final bastante adecuado a lo que estábamos haciendo: cuando haces TDD, la documentación son los tests. Este mensaje obliga a implementar correctamente los tests, a definirlos y diseñarlos de manera adecuada para que su mantenimiento y revisión sean adecuados y sencillos.
Sólo voy a comentar que nos pusieron en grupos de 4, 2 parejas. Cada pareja con un problema distinto y que debían desarrollar mediante TDD...y hasta ahí puedo leer. Me gustaría guardar el mecanismo de la sesión para poder llevarla a cabo alguna vez en la comunidad local de agile-cyl, o en alguna empresa que quieran empezar a trabajar con TDD.
Si alguien quiere saber de qué iba que se ponga en contacto conmigo para explicarle el procedimiento en privado.
Lo recomiendo.
4. Prácticas recomendadas para la relación Cliente-Equipo en el desarrollo ágil de software (Juan Garbajosa y Agustín Yagüe)
De esta sesión me esperaba otra cosa, pero fue un acercamiento a la relación cliente-proveedor desde un punto de vista académico y Con la IEEE detrás de todo esto. Juan nos contó los avances de la IEEE para establecer un contrato marco avalado por la IEEE para la relación indicada anteriormente.
Bajo este contexto nos estuvo describiendo los diferentes puntos que sacaron, pero lamentablemente no llegaron a una conclusión final y una firma del borrador, quedando sin acabar. Juan hizo un llamamiento a quien quiesiera colaborar ya que era un trabajo desde instituciones académicas, IEEE y grandes corporaciones de diferentes paises.
Puntos Comunes:
Rodrigo es un gran comunicador, hace la charla amena y simpática, recalcando el mensaje que quier dar con ejemplos sencillos y directos.
En esta sesión nos explicó conceptos que hacen que falle Scrum. Algunos de los que nombró fueron:
Día 2
1. Ser ágil en España, un caso real con equipos de trabajo en remoto (Enrique Amodeo y Antonio David Fernández Reyes)
No voy a ser pelota de nadie, pero para mi una de las mejores sesiones. ¿Por qué? Porque laguien se atrevió a poner encima de la mesa lo difícil que es trabajar con metodologías ágiles, los intentos que ahces, los problemas que te encuentras y cómo te adaptas para mejorar. Y la mejora no se hace de un día para otro, hay mucho trabajo por detrás, muchas decisiones y mucho trabajo de comercial o psicólogo para convencer hacia arriba de que ese es el camino y al final se demuestran con hechos los beneficios.
Algo a destacas de la CAS2010 ha sido la presencia de casos reales como esta sesión y la siguiente. Y hay que ser valiente para pnerte delante y decir: empezamos así y nos equivocamos, y cambiamos y mejoramos.
Dejémonos de historias de éxito sin contar porqué es difícil, dejemos la teoría que muchos ya la han puesto en libros. Si yo quiero empezar con Scrum quiero saber qué problemas voy a tener y cómo solucionarlos, sabiendo que cada caso tendrás sus cosas.
En este caso la complejidad residia en tener un equipo distribuido, cn muchos kilómetros de distancia de Madrid. Entre los primeros puntos que nos hablaron estuvieron la experiencias previas, la implicación del equio y sobre todo la dificultad de la visibilidad del avance. Aquí entraron a explicar las diferentes herramientas que evaluaron.
Tras esta fase detectaron una serie de fallos, como que el Scrum Master estaba en Madrid, la estimación se hacía a mano alzada...
En esta segunda aproximación detectaron que los sprints no se respetaban por el número de incidencias urgentes que alargaan el sprint, no exitía el Definition of Done lo que provocaba malentendidos...los pases de entorno se volvían imposibles.
La solución que aplicaron fue TDD, SM en el equipo remoto, optimizar builds y dependencias con el uso de Maven, Hudson+Sonar y Sprint inamovibles, para ello se contó con un Product Owner más involucrado en el proceso.
Y como en todo este proceso late la mejora continua, tras estas fases siguen plantenado cambios para mejorar, queriendo incluir Kanban, Repositorios distribuidos (Git), Pair Programming, optimizar el tiempo de entrega, no de recursos...
La presentación la podéis encontrar en esta dirección.
2. One year of software developments to win a world racing championship (Luca Minudel)
¿Sabíais que los grandes equipos de Formula 1 trabajan en sus departamentos de Software con metodologías ágiles? Increible ver esta charla de Luca como miembro del equipo de Ferrari y que nos dijo que en McLaren también lo hacían y en Renault también...hasta que se han quedado sin presupuesto, porque eso de hacer release que luego tenías que tirar o modificar no lo puede hacer todo el mundo...sin dinero.
Trabajan en la nueva temporada sin esperar a que termine la actual, sin conocer la nueva regalmentación y a tope para poder ir sacando mejoras de su actual sistema. Cuando llega la regalmentación tienen que adaptarse y cambiar y mejorar, cuando llegan las carreras tienen que comparar resultados con los rivales y volver a mejorar. La verdad es que el nivel de incertidumbre y de cambio hace que las iteraciones sean una locura pero con Scrum consiguen tener release tempranas y adaptarse a los cambios que el entorno tan agresivo les empuja a tener.
3. Probando tu TDD (Juan Gutiérrez y Carlos Blé)
No tenía en mi hoja de ruta esta sesión, pero estando Juan y Carlos en ella me dejé llevar por mis compañeros de Agile-CyL allí. Tras una buena comida y con cierto sopor me encontré con que tenía que programar. Fue una sesión muy muy interesante y con un mensaje final bastante adecuado a lo que estábamos haciendo: cuando haces TDD, la documentación son los tests. Este mensaje obliga a implementar correctamente los tests, a definirlos y diseñarlos de manera adecuada para que su mantenimiento y revisión sean adecuados y sencillos.
Sólo voy a comentar que nos pusieron en grupos de 4, 2 parejas. Cada pareja con un problema distinto y que debían desarrollar mediante TDD...y hasta ahí puedo leer. Me gustaría guardar el mecanismo de la sesión para poder llevarla a cabo alguna vez en la comunidad local de agile-cyl, o en alguna empresa que quieran empezar a trabajar con TDD.
Si alguien quiere saber de qué iba que se ponga en contacto conmigo para explicarle el procedimiento en privado.
Lo recomiendo.
4. Prácticas recomendadas para la relación Cliente-Equipo en el desarrollo ágil de software (Juan Garbajosa y Agustín Yagüe)
De esta sesión me esperaba otra cosa, pero fue un acercamiento a la relación cliente-proveedor desde un punto de vista académico y Con la IEEE detrás de todo esto. Juan nos contó los avances de la IEEE para establecer un contrato marco avalado por la IEEE para la relación indicada anteriormente.
Bajo este contexto nos estuvo describiendo los diferentes puntos que sacaron, pero lamentablemente no llegaron a una conclusión final y una firma del borrador, quedando sin acabar. Juan hizo un llamamiento a quien quiesiera colaborar ya que era un trabajo desde instituciones académicas, IEEE y grandes corporaciones de diferentes paises.
Puntos Comunes:
- Colaboración sobre negociación contractual: hay un problema legal si no está escrito, pero la confianza debe estar por encima del contrato.
- Creación de valor: El suministrador aporta valor, pero el cliente se compromete a facilitarlo. Este punto es clave, pero estamos lejos de conseguirlo.
- Adaptabilidad
- Mejora contínua
- Contratos: existe, pero en cualquier momento se puede romper por cualquiera de las partes. Se puede porque en cada sprint se aporta valor. Describe cómo trabajar juntos mejor que impoener multas o penalizaciones.
- Requisitos: base del producto. Las necesidades del cliente son cambiantes, pero el cliente debe priorizar. La priorización no debe cambiar el contenido de entrega del sprint.
- Prácticas de gestión
- Planificación: gestión de riesgos
- Ciclo de vida iterativo: timebox "sagrado", romperlo afecta a la gestión de recursos.
- Documentación: acordar la necesaria (mínima).
- Testing: Introducir el concepto de DoD (Definition of Done) y definición de hecho-hecho.
- Delivery: Verificar que el producto coincide con los requisitos. Si el cliente lo rechaza debe explicarlo muy bien.
Rodrigo es un gran comunicador, hace la charla amena y simpática, recalcando el mensaje que quier dar con ejemplos sencillos y directos.
En esta sesión nos explicó conceptos que hacen que falle Scrum. Algunos de los que nombró fueron:
- No tengas equipos
- Sprint review de mentira: el equipo no tiene compromiso si le asignan tareas. El cliente no sale del Sprint Review hasta que haya dado feedback del producto.
- Haz de tus retrospectivas un valle de lágrimas: se hacen para hacer algo, no para desahogarse. Hay que revisar las últimas retrospectivas y buscar los puntos repetidos, esto garantiza un éxito seguro.
- En las prácticas de ingeniería del software hay valor, no importa la metodología.
- No usar métricas para castigar el equipo, sino para animarlo.
- Ojo con los detalles: evitar flexibilizar scrum. Se adapta scrum una vez que funciona, y mejoramos nuestra gestión.
1 comentario:
This piece of writing will assist the internet users for building up new weblog or even a blog from start to end.
Publicar un comentario