Archive Page 2

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.

Anuncios

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 ex`licativas 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

Objetivos para el 2010

Tras leer los blogs de David Bonilla y Alberto Peña, con el meme de cada uno de objetivos para el 2010 me he decidido a apuntarme a esta línea de autoflagelación para ver a finales de año cuántas cosas no he conseguido cumplir, aunque espero que las que haya podido llevar a cabo sumen tal grado de satisfacción que supere la fustración de los fracasos.
Veamos cuáles son estos objetivos:

  1. Hacer más ejercicio, un clásico de mi vida que siempre me persigue y nunca cumplo, así me va cada año peor. Pero no tanto como pueda pensar la gente que es por presumir, sino ya pensando en mejorar mis niveles de azúcar y hacer que la diabetes no sea ese compañero silencioso que con el paso de los años se convierta en una carga para mi y las personas que me rodean y me quieren. Hay que quererse mucho más a uno mismo.
  2. Comprometerme mucho más con la escritura del blog. Soy un dejado, un vago para escribir, a veces porque pienso que no tengo nada que decir, a veeces porque no sé hacia donde quiero orientar el sentido del blog. Inicialmente quería hablar de Java, luego salió algún post más personal, luego un reflejo de noticias de las que me hacía eco…nada en concreto. Con el tiempo me he dado que no es tan difícil poner un par de lineas, no hace falta escribir un “libro” como entrada del blog. Me gustaría darle un enfoque mucho más práctico.
  3. A nivel técnico me he dado cuenta de las muchas carencias que tengo, lo que en un principio me dejó mal sabor de boca y ahora lo que tengo es muuuuchas ganas de aprender. Quiero enfocar este año en el aprendizaje / mejora de conceptos como: TDD, Tests unitarios, integración continua, Maven, Sonar, y por supuestos nuevos lenguajes que me pueden ayudar en un futuro como Python, Ruby, Groovy, Grails… deberé centrarme, ya empiezo a dispersarme 😉
  4. Aportar mi esfuerzo a la comunidad agil de España. Ha sido el gran descubrimiento de este año, en un momento en que muchas cosas ya me daban igual encontré un grupo de gente que consiguieron llamar mi atención sobre otra forma de ver el mundo del desarrollo software. Con el empuje del Agile Open Spain 2009 me lancé a movilizar a mis contactos para formar un grupo en Valladolid, ampliado de una manera muy alegre a Castilla y León, pero bueno, hay que tener grandes miras en el horizonte para llegar lejos. Con esto conseguí empezar a “evangelizar” el agilismo por mi tierra, pero lo mejor, conocer nueva gente que ya lo practicaba y yo sin saberlo :-(. Para este año hay que meter más caña al grupo, ser proactivo y ver hasta dónde llegamos y qué podemos hacer.
  5. Promover, perseguir y mejorar mi entorno de trabajo en la empresa en que trabajo, aportando mis ideas sobre agilidad, mejora continua y prácticas de XP. Quizá esto sea lo más difícil de todo, no tanto por mis ganas sino por la resistencia al cambio que aparece ante esas “cosas nuevas con que nos ha venido Jorge”. Algún día alguno se dará cuenta que ya va un año tarde en las nuevas tendencias del desarrollo software, en la mejora de nuestro sector y las prácticas que hacen un software de mayor calidad.
  6. Leer más libros técnicos. Ya basta de leer solo en verano novelas mientras estoy en la piscina. Hay que aprovechar todas las horas del día, de la semana para echar un vistazo a esos libros que ahora llaman mi atencion (principalmente Agile, TDD, JUnit, Patrones de diseño…) y realizar periodicamente una inversion en ellos, que a la larga será positivo para mi desarrollo profesional.

Al final creo que son ya unos cuantos objetivos bastante amplios. Esto como los mandamientos se podrían resumir en uno:

GESTIONAR MUCHO MEJOR MI TIEMPO, EMPLEAR GTD Y POMODORO

Tengo que reconocer que soy muy poco constante 😉

Manifiesto ‘En defensa de los derechos fundamentales en Internet’

Desde el blog de Manuel M. Almeida reproduzco este manifiesto que secundo al 100%:

Ante la inclusión en el Anteproyecto de Ley de Economía sostenible de modificaciones legislativas que afectan al libre ejercicio de las libertades de expresión, información y el derecho de acceso a la cultura a través de Internet, los periodistas, bloggers, usuarios, profesionales y creadores de internet manifestamos nuestra firme oposición al proyecto, y declaramos que…

1.- Los derechos de autor no pueden situarse por encima de los derechos fundamentales
de los ciudadanos, como el derecho a la privacidad, a la seguridad, a la presunción de inocencia, a la tutela judicial efectiva y a la libertad de expresión.

2.- La suspensión de derechos fundamentales es y debe seguir siendo competencia exclusiva del poder judicial. Ni un cierre sin sentencia. Este anteproyecto, en contra de lo establecido en el artículo 20.5 de la Constitución, pone en manos de un órgano no judicial -un organismo dependiente del ministerio de Cultura-, la potestad de impedir a los ciudadanos españoles el acceso a cualquier página web.

3.- La nueva legislación creará inseguridad jurídica en todo el sector tecnológico español, perjudicando uno de los pocos campos de desarrollo y futuro de nuestra economía, entorpeciendo la creación de empresas, introduciendo trabas a la libre competencia y ralentizando su proyección internacional.

4.- La nueva legislación propuesta amenaza a los nuevos creadores y entorpece la creación cultural. Con Internet y los sucesivos avances tecnológicos se ha democratizado extraordinariamente la creación y emisión de contenidos de todo tipo, que ya no provienen prevalentemente de las industrias culturales tradicionales, sino de multitud de fuentes diferentes.

5.- Los autores, como todos los trabajadores, tienen derecho a vivir de su trabajo con nuevas ideas creativas, modelos de negocio y actividades asociadas a sus creaciones. Intentar sostener con cambios legislativos a una industria obsoleta que no sabe adaptarse a este nuevo entorno no es ni justo ni realista. Si su modelo de negocio se basaba en el control de las copias de las obras y en Internet no es posible sin vulnerar derechos fundamentales, deberían buscar otro modelo.

6.- Consideramos que las industrias culturales necesitan para sobrevivir alternativas modernas, eficaces, creíbles y asequibles
y que se adecuen a los nuevos usos sociales, en lugar de limitaciones tan desproporcionadas como ineficaces para el fin que dicen perseguir.

7.- Internet debe funcionar de forma libre y sin interferencias políticas auspiciadas por sectores que pretenden perpetuar obsoletos modelos de negocio e imposibilitar que el saber humano siga siendo libre.

8.- Exigimos que el Gobierno garantice por ley la neutralidad de la Red en España, ante cualquier presión que pueda producirse, como marco para el desarrollo de una economía sostenible y realista de cara al futuro.

9.- Proponemos una verdadera reforma del derecho de propiedad intelectual orientada a su fin: devolver a la sociedad el conocimiento, promover el dominio público y limitar los abusos de las entidades gestoras.

10.- En democracia las leyes y sus modificaciones deben aprobarse tras el oportuno debate público y habiendo consultado previamente a todas las partes implicadas. No es de recibo que se realicen cambios legislativos que afectan a derechos fundamentales en una ley no orgánica y que versa sobre otra materia.

NOTA: Este manifiesto fue redactado conjuntamente por periodistas, bloggers e internautas, en una maratoniana sesión durante la tarde-noche de ayer. Si estás de acuerdo, difúndelo por todas las vías que puedas.

Lider de Proyecto.com / Identificar Stakeholders… ¿Por qué molestarse en esto?

Lider de Proyecto.com / Identificar Stakeholders… ¿Por qué molestarse en esto?

Shared via AddThis

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

,