Resumen de sesiones en CAS2010 (día 2)

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:

• 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

Prácticas:

• 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.
  

5. Diez maneras infalibles de asegurar Scrum será un fracaso (Rodrigo Corral)

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.
  

Retrospectiva tras primer sprint

Por fin llegó el día de poder ver cómo ha ido este primer sprint.

Partimos de ciertas carencias asumidas como la falta de integración contínua, una buena política de definición de test unitarios...pero bueno, hay que ir dando pasitos cortos para avanzar un gran camino. Tras el periodo navideño donde nuestro Sprint 0 quedó un poco desdibujado, y sólo sirvió para establecer la arquitectura del proyecto y para avanzar con Scrum y conocer todos sus artefactos, roles y discutir el sentido de cada post-it y la gráfica de burn-down, por fin hemos empezado en serio ;-)

Al no ser yo un miembro del equipo he tendio que mantenerme a cierta distancia y sólo hacer tareas de coaching, formando al scrum master y orientando al equipo cuando había alguna duda. Pero debo reconocer que lo han hecho bastante bien para ser la primera vez.

Product Owner

Nuestro PO iba a ser una persona con contacto con el cliente externo, pero desde el prinicpio ya dijo que tenía muchas cosas que hacer y no siempre iba a estar disponible. Ante esta perspectiva el Scrum Master tuvo que hacerse cargo de ese rol. Esto es un error muy grande desde mi punto de vista y así lo hice notar en la retrospectiva, pero no se podía hacer de otra forma. Por lo menos el SM es lo bastante responsable y como es quien tien trato directo con el cliente, puede sacar cuáles son las historias que hay que hacer y preparar una pila de producto de una manera eficaz.

Sprint Meeting

Aquí tuvimos el primer contratiempo, yo les dí la formación adecuada (o eso esperaba) de como debían llevarla a cabo, pero tuve que ausentarme y no estuve presente. FAIL --> Se liaron con el tema de las estimaciones de la pila de producto y posteriormente de las tareas de cada historia. Debido a esto la reunión se alargó a dos días cuando en el primero debía haber bastado.

Daily Meeting

Muy bien realizado todos los días a una hora establecida, rápido y sencillo. Les ha gustado al equipo saber el estado del proyecto en cada momento, oo que hacía cada uno y tener un horizonte de trabajo conocido y seguro. Algún día le she tendio que dar un tirón de orejas al despistarse y empezar a contar batallitas del día anterior. También cogieron la costumbre de terminar la reunión y seguir de pie delante del tablero hablando de detalles técnicos del desarrollo.
En la retrospectiva les he dejado claro que eso lo pueden hacer en una sala sentados o en su propio puesto, pero que no lo asocien con el Daily Meeting.

Radiador de Información

Un problema: no tenemos un sitio donde colocarlo, lo cual no es muy cómodo para manejar. Parece que lo hacemos a escondidas. El equipo ha aprendido a manejar las tareas y hacer hacer que fluyan por el panel según van terminado y probando las tareas. Yo todos los días les sacaba el burndown y han reconocido que les gustaba ver la velocidad que llevaban y saber si iban bien o retrasados. El factor psicológico del panel da resultado. Les hace ser autoorganizados, responsables con sus tareas y meterles la pequeña tensión de ver cómo van sus compañeros y ellos seguir el ritmo.

Demo

Un caos!!!! Otro tirón de orejas en la retrospectiva. No funcionaba la demos por un problema de instalación en el servidor de demo. Es algo que se va a arreglar para el próximo sprint en que ya tendremos Integración Contínua (o eso me han dicho).

Retrospectiva

Dirigí la retrospectiva para que vieran todo lo que había observado durante el Sprint. Ellos sacaron algunos asuntos, siempre desde el lado positivo, pero yo incidí más en lo que había que mejorar, eso después de decirles que lo habían hecho muy bien y mejor de lo que esperaba para ser la primera vez.

Yo creo que es un equipo al que se le puede pedir más velocidad por eso me he comprometido a apretar el factor de ruido paraver hasta dónde pueden llegar.

Primeras lecturas para el 2010

Como comenté en la entrada anterior del blog, uno de mis objetivos de este año es la formación, tanto externa como propia de manera autónoma, de manera que en esta entrada aprovecho para seguir con dos puntos de mis objetivos para el 2010. El primero, ser más constante en escribir entradas en el blog, y el segundo, leer más libros técnicos.
Aquí va un avance de los libros que estoy leyendo y que voy a leer próximamente porque ya los tengo pedidos….siempre originales, encuadernados y como nuevos, que luego no venga la SGAE hablando de INTERNET = PIRATERÍA, que parece que los que nos dedicamos al consumo de la red vamos con un parche


Libros en proceso de lectura

Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin) by Robert C. Martin



Libro ya clásico y que debería ser de obligatoria lectura en la Universidad y en cualquier centro de estudios sobre desarrollo de software. Debo reconocer y asumir con vergüenza que hasta el año pasado no lo conocía, pero los meses que llevo con él me ha abierto lo ojos y me ha dado muchas ideas y buenas prácticas sobre el código que genero día a día. Es de fácil lectura y todo perfectamente ilustrado con ejemplos, donde se ve el paso de código que “huele” a código con mucha más calidad, claridad y mejor implementado. Reconozco que ahora sigo a Uncle Bob Martin como un iluminado más por sus ideas.
El libro se divide en tres partes. En el primero nos habla de principios, patrones y distintas formas de escribir código limpio. En la segunda parte trata mediante ejemplos de lo explicado en la primera, viendo lo que está mal y cómo arreglarlo. Finalmente en la tercera parte aporta unas heurísiticas y errores perfectamente conocidos y explicados.

Succeeding with Agile: Software Development Using Scrum (Addison-Wesley Signature) by Mike Cohn

Mi biblia en este momento. Tras leer mucho sobre Agile en Internet e introducirme en foros, mi entusiasmo e inquietud me llevó a buscar un libro de uno de los autores de los que iba leyendo referencias y de los que veía que habían escrito ya libros de calidad. Este proceso me llevó a descubrir a Mike Cohn y de sus diversos libros este iba a publicarse en unos días, pero en Amazon ya lo ponían a la venta y no me lo pensé dos veces. No me arrepiento de los días en que abría con ansia el buzón esperando haber recibido el aviso de llegada del paquete y la alegría cuando lo tuve en mis manos y empecé a leerlo con avidez. Fuera de la teoría ya conocida sobre scrum y sobre metodologías ágiles, este libro se centra en años de trabajo con este marco de trabajo y casos reales con los que este evangelizador de agilidad se ha encontrado en su trabajo, en sus labores de consultoría, apoyo y coahcing de empresas. Define perfetamente los problemas existentes y cómo haceles frente.
Debo reconocer que no se equivoca y en la tarea que tengo ahora de llevar a la práctica la gestion de un proyecto con Scrum me sirve de referencia para no cometer demasiados fallos (que algunos ya tengo identificados que cometemos, pero estamos aprendiendo).

The 4-Hour Workweek: Escape 9-5, Live Anywhere, and Join the New Rich by Timothy Ferriss

El regalo de Reyes de este año que apareció por sorpresa Este libró llegó a mis oidos de la mano de Angel Medinilla en el curso sobre Scrum que impartió en Madrid. Hizo un par de referencias al mismo que me calaron hondo, y no tanto por el mensaje del título, que parece que da a antender que hay que trabajar menos horas, sino por el mensaje de que si no te gusta lo que ahces quedarte sentado esperando a que cambie no es la solución, planteate si no eres feliz lo que debes hacer para conseguir serlo. Haz un balance de los pros y contras de cambiar tu vida para la búsqueda de la felicidad y planteate si compensa el riesgo o no. Seguramente compensará asumir el riesgo. La verdad es que es un mensaje que en mi vida he practicado en cierta manera, ya que cuando en un trabajo no estaba agusto, o perdía la ilusión no he dejado que me afectara al resto de mi vida y procuraba cambiar buscando mejores opciones de realización profesional y personal. Aunque puede haber personas que piensen que los cambios eran para mejorar económicamente puedo asegurarles que en algún caso no fue así, y en otros fui engañado con buenas palabras, pero eso nunca me paró. La verdad es que ahora con la crisis y la situación laboral de incertidumbre este libro me ha dado una pequeña sacudida en mi interior, junto con el haber conocido a gente emprendedora de Iniciador Valladolid. Puede que este año sea un punto de inflexión en mi vida, pero solo son ideas, quizás un poco fantasiosas, pero la ilusión nunca se pierde.

INFORMÁTICA PROFESIONAL. LAS REGLAS NO ESCRITAS PARA TRIUNFAR EN LA EMPRESA de Roberto Canales


Este libro llegó a mis manos posteriormente a mi asistencia al Agile Open Spain 2009. Cuando conocía a gente como José Manuel Beas, Xavi Albaladejo, Xavi Quesada y mejor paro de escribir porque me voy a dejar muuucha gente y no sería justo ya que todo el mundo aportó muchas experiencias, ideas y casos en las sesiones que se desarrollaron y que hicieron que volviera convencido de que hay otra realidad en nuestro trabajo (creo que elegi la pastilla correcta como Neo en Matrix, pero no diré el color porque nunca me acuerdo, jejeje).
El caso es que este libro está muy bien escrito, planteado desde el punto de vista de una personas que lleva años en esto y sabe de lo que habla, te ves reflejado en muchas de las historias que desarrolla y ves a gente con la que has compartido penas y glorias en tu historia profesional. Quizás le falte un poco más de perspectiva desde el punto de vista técnico, ya que no todos llegamos a tener una visión desde las alturas de la empresa, pero está bien ver todos los enfoques de la gestión de una empresa informática, incluso de los comerciales pre venta
El que venga con divertidas viñetas de comic explicativas de cada punto hace una lectura muy amena y rápida. Altamente recomendable y mi felicitación para Roberto y la gente de Autentia.

Libros pendientes de lectura (esperando que lleguen)

Diseño Ágil con TDD de Carlos Blé Jurado

Este libro me hace especial ilusión que me llegue. En primer lugar porque tuve la suerte de recibir los dos últimos borradores del mismo el año pasado y me pude adelantar a su lectura antes de ser publicado. En segundo lugar es mi compromiso de este año, aprender a utilizar TDD y llevarlo a la práctica en el día a día. Para ello espero poder asistir a alguno de los cursos que Carlos va a impartir este año y que tanto interés tengo en que se lleven a cabo cerca de mi lugar de residencia.
Aunque el libro es de  Licencia Creative Commons yo prefiero tenerlo impreso y encuadernado, que para eso me gustan los libros y también como agradecimiento al autor por el esfuerzo de un año de trabajo. También comentar la aportación de muchas personas en generación de capítulos y en la revisión del libro. Enhorabuena a todos.


Los dos siguientes libros son para aportar más calidad al trabajo diario en mi proyecto piloto con Scrum…espero que lleguen a tiempo, que el proyecto no es muy largo


User Stories Applied: For Agile Software Development (Addison Wesley Signature Series) by Mike Cohn
 



Agile Estimating and Planning (Robert C. Martin) by Mike Cohn

Entrenadores - ¿Liderar o no liderar?

He encontrado esta entrada en el blog http://www.bigvisible.com/gschlitz/coach-to-lead-or-not/ y me ha parecido interesante su contenido, de manera que lo he traducido para ponerlo a disposición de la comunidad hispana. No sé qué opinais sobre el liderazgo en el sentido clásico de las metodologías tradicionales y el liderazgo en las metodologías ágiles. Yo creo que la lectura de este texto puede ser útil, y además abrir un debate sobre el papel del coaching en las empresas que comienzan a utilizar scrum.

Mi opinión es contraria a este texto, yo creo que el coaching debe ayudar pero no interferir en el proceso de integración de técnicas ágiles en un equipo. Debe facilitar el trabajo, orientar, pero no liderar, porque se corre el riesgo de malinterpretar los papeles de cada personaje dentro del equipo. De acuerdo que al principio puede ser complejo el llevar a cabo todas las actividades por la inexperiencia, pero con el erro se aprende y sobre todo se mejora en una evolución constante de los equipos de trabajo. También creo que de forma natural aparecerán las personas con más capacidad para el liderazgo...saber lo que hay que hacer no implica liderar al equipo. Yo puedo saber aplicar scrum y trabajar con ello, pero puede que mi personalidad esté muy distante de lo que se espera de un lider como referencia o punto de apoyo en un momento dado.

A menudo oigo diferentes opiniones sobre lo que los entrenadores pueden o no pueden hacer: Un ejemplo es si pueden o no liderar. Una opinión común es que los entrenadores no son líderes.

Mi opinión puede ser un poco controvertida.

Creo que un entrenador es lo que él/ella necesite ser para ayudar a sus equipos a avanzar de nivel. Creo que buenos entrenadores son también buenos líderes, aunque no cumplan papeles de liderazgo sobre aquellos a los que entrenan.

Algunas organizaciones están en tal estado que necesitan alguien para demostrar liderazgo para comenzar a entender lo que un lider hace en su contesto y en ese caso no hay nadie disponible para realizarlo. En ese momento, ninguna cantidad de preguntas Socráticas, diálogo, facilitar recursos, u otras técnicas de ayuda les llegará en un tiempo razonable. En ese momento, imagino a aquellos con un papel estricto de entrenador declarando "no están preparados para <afrontar x>". Yo realizaría una aproximación diferente - Yo temporalmente me haría cargo del papel de líder para demostrar cómo hacerlo y entonces dejar el papel a un miembro del equipo

Consideraciones importantes cuando asumes el liderazgo siendo un entrenador

Cuando haces esto, te quitas tu sombrero de entrenador y te pones un sombrerlo de liderazgo prestado. Fija las expectativas claramente:

• esta es una situación temporal, breve, con objetivos especificos incluidos la demostración y nombramiento posterior
• un objetivo principal de este esfuerzo es entregar el liderazgo tan rápido como sea posible a un miembro del equipo
• un objetivo principal es recuperar el gorro de entrenador tan pronto como sea posible y romper las dependencias del entrenador como lider

Si eres un entrenador, puedes haber actuado como lider anteriormente

¿Facilitas reuniones pronto en un compromiso, tales como descubrir talleres u otras cosas? Estás actuando como un líder en ese momento. Como describo más abajo, es un esfuerzo con un tiempo límite con expectativas muy claras. Pero esto es liderar. Cuanto más explícito y responsable sea el papel de liderazgo que estás tomando, más resbaladiza es la pendiente que sigue, pero con una gestión cuidadosa de las expectativas y un plan claro para la transición del papel a un miembro del equipo, los equipos se pueden beneficiar de tu experiencia y liderazgo.

¿Hacerles cambiar?

Algunos creen que el papel de entrenador es muy explícito y que hay límites muy claros, y esas personas no están "preparadas para ser ayudadas".  Yo no lo creo. Yo creo que "trabajo sobre /con la persona que está enfrente de mi", entre los problemas que tienen y esass reglas a veces necesitan ser cambiadas para ayudarles de la mejor manera. Si quieren cambiar y mejorar, haré lo que sea necesario para ayudarles.

Un ejemplo

Un equipo era el primero en su empresa (una gran empresa) en probar scrum. El equipo es uno de cuatro que trabajan en un gran proyecto. Nadie en los cuatro equipos tienen experiencia con scrum, y la cultura hasta ahora era la de multi tareas, diversos jefes ("tengo cinco jefes, Bob, cinco"), y miedo de estrellarse contra las rocas o exponer información. Hay un liderazgo poco claro.

Una aproximación que funcionó verdaderamente bien en esta situación en diversas empresas para mi fue tomar el papel de lider durante un periodo de tiempo fijado, con objetivos explícitos de transferir el papel a un miembro del equipo tan rápido como fuera posible. Tomando el papel de scrum manager para unos pocos sprints me permitieron - alguien con la pequeña necesidad de romper con la tradición - facilitar decisiones, reglas de desafío, exponer elefantes y demás. Los miembreos del equipo vieron que todas aquellas cosas acabaron de manera exitosa, y un scrum manager natural emergió y tomó el papel, permitiendome centrar en el entrenamiento puro.

Mientras muchos equipos empezaron a probar scrum, apareció un nuevo salto de liderazgo - a nivel de programa. Asumí de nuevo el papel de scrum master- otra vez por un periodo breve de tiempo con objetivos expecíficos de transferir el papel a alguien del equipo tan pronto como fuera posible. Los resultados se repitieron - esta vez a nivel de programación - y los resultados fueron equipos que funcionaron de manera efectiva como un programa agil.

Asumir estos papeles fue un riesgo...es un terreno resbaladizo comenzar a asumir papeles de liderazgo responsable. Sin embrago, en algunos lugares, debe tener lugar un aprendizaje drástico, y en esos sitios, alcanzar algunas respuestas a través del cuestionamiento y facilitación podría llevar una cantidad de tiempo cuestionable. En esto sitios, demostración y tutelaje pueen ser combinados con entrenamiento para encontrar la luz. Más sobre este asunto en mi post coaching courag.

Agile Open Spain en Madrid - 23-24 octubre 2009

Hace tiempo que no actualizo el blog y algunas personas ya me lo han hecho notar, de manera que aquí va mi pequeña actualización.
El tema es sobre metodologías agiles que es un tema que últimamente me está llamando la atención. Quizás sea otra "moda" más sobre la forma de abordar los proyectos / trabajos de nuestra profesión, pero que tiene un fondo que con el paso de años me doy cuenta que es una verdad como un puño: lo importante es el producto final, es algo que interesa tanto a cliente como a desarrolladores. Y en esto radica que se haga frente a todos los problemas que conocemos cuando se hacen las cosas mal, no se tiene la información necesaria, el cliente espere algo distinto a lo que entregamos por no haberse especificado correctamente. Y antes de lamentarnos mejor solucionarlo.
El hecho de que el cliente, o propietario del producto esté involucrado en el desarrollo me parece esencial. Es tan responsable como nosotros de la finalización y entrega de un producto perfectamente validado por él. Nosotros por nuestra parte debemos conocer toda la informacion posible de lo que quiere el cliente y tenemos que irle ofreciendo nuestro trabajo en peridoso coros de tiempo para poder validar nuestro trabajo con el y sobre todo: poder solucionarlo a tiempo. No hace falta malas planificaciones ni mala coordinación, no hay que hacer horas de más en la medida de lo posible.

Para aprender un poco más y empezar a ver lo viable que puede ser en el equipo en que trabajo voy a asistir al Agile Open Spain (siempre y cuando me acepten, jejeje...a ver si puedo aportar algo). En la página comentan esto:

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

Agenda

Viernes

18:00 – 18:30: Bienvenida con aperitivo y networking.
18:30 – 19:15: Presentación del agilismo, de Agile-Spain y del Open Space.
19:15 – 20:00: Identificación y selección de sesiones por parte de los asistentes para crear la agenda del sábado.

Sábado

09:00 – 18:00: Open Space.

Cada sesión tendrá 1 hora de duración. Habrá un espacio de 15 minutos entre sesiones y una hora para comer (coste a cargo de patrocinadores). En total podrán haber hasta 30 sesiones. Se podrá proponer una sesion de 2 horas que ocupe dos bloques de tiempo.

Aunque me tendré que poner al día para saber de qué hablan estos chicos y no ir de paleto por allá.

Agile, Scrum