Presentación de Raúl Herranz en el pasado Tenerife Lan Party en la que trató de las características de la gestión predictiva, la agilidad y la flexibilidad al aprovechar lo mejor de ambos enfoques.
vi@ Utópica Informática.
“Forosíntesis” Scrum Manager
De los temas de estos días en los foros…
Agile as Slogan
Daniel Ceillan abre el tema de la faceta de eslogan del término Agile.
“El desafío del Ser Agil, es convivir con gente no-Agil. Y no le queda otra!”
“El núcleo del agilismo: el Equilibrio. Todo se puede resumir a una cuestion de balance. Y balance no es purismo”
“El tema Agile por otro lado, ha alcanzado una gran polularidad, con lo cual, muchos sin leer nada de ello lo emplean ‘a su maner’, desvirtuandolo. Pero ya que es popular, vamos aprovecharlo, cualgan un panel de tareas a la enrtada y listo ”
“Si lo de moda es Agile, yo me pongo ese casco cuando salgo a vender.”
“que es lo que importa ? que tenga la certificacion , pues la obtengo.”
“Sin confianza no hay equipo y sin equipo no hay agilismo que valga.”
“Es importante no caer en la trampa de seguir al pie de la letra la metodologia. Ella esta para servirnos y no al reves.”
“Esperar que otros cambien para luego hacerlo nosotros, no es la solución. ”
¿Te gusta hacer muchas cosas al mismo tiempo?
Juan Manuel Garrido abre desde su post un tema interesante : “¿Interrumpir una tarea para tweetear o responder correos electrónicos es una simple distracción o es hacer varias cosas al mismo tiempo?.”
“el reto de los profesionales multitarea, la clave para cumplir esas exigencias está en optimizar el tiempo, además de establecer prioridades y horarios de actividades.”
Para compaginar varias actividades con eficiencia María Mora recomienda Pomodoro. Abul Martínez lo recomienda junto con GTD y un poco de disciplina. Raúl Herranz apunta un par de enlaces de Pomodoro y GTD en su blog. Manuel Rubio señala una técnica similar y derivada de GTD: ZTD (Zen To Done).
Un Project Management Socialmente Enredado
Anna Marra abre el tema planteando:
“Las redes sociales son una herramienta de comunicación o una herramienta de gestión?… ¿Puede ser un blog la plataforma para un proyecto? Yo creo que quizás ahora sea la más rápida y efectiva. ”
“¿Gestión de proyectos en ON’Gs en los que el equipo es una comunidad de voluntarios, no un equipo de trabajo.?
Se trataría de un gestor, que además de los “skills” de gestión de proyectos, necesita los de gestión de comunidad o “community management”
Daniel Ceillan por su experiencia en gestor de una ONG para desarrollo de software apunta los siguientes consejos:
- Hacer listas de objetivos priorizadas. Es crucial para evitar desperdicios y lograr objetivos rápidos
- Dejar que los grupos se auto-organicen
- la motivacion sigue siendo la clave
No hay gestión ágil sin comunicación!!
Vanessa Romano recomienda el episodio 162 de “Project Managers Podcast” en el que entrevistan a la autora del libro “Social Media for Project Managers“, Elizabeth Harrin.
Si a tu equipo le propones usar twitter para hacer un foro común sobre el proyecto ó proyectos en los que estén, lo van a tomar como algo más natural que el hecho de tener que adaptarse a las particularidades y formalismos que suelen ofrecer las intranets corporativas”
Scrum como patrón pedagógico para el aprendizaje basado en proyectos
No es fácil trabajar en un marco de Scrum con un equipo distribuido y es precisamente el tema que analiza Sergio Yazyi en su trabajo de Fin de Master en las TIC en Educación de la Universidad de Salamanca ”Una experiencia práctica de Scrum a través del aprendizaje basado en proyectos mediado por TIC en un equipo distribuido “.
El trabajo emplea para su análisis el taller que realizamos en Open Knowledge Scrum en el que participó el año pasado, y que fué dirigido por Claudia Ruata.
El documento compone una visión general y análisis, objetivo y riguroso tanto del aprendizaje basado en proyectos como de los retos del trabajo con equipos distribuidos.
“El aprendizaje basado en proyectos se presenta en varias disciplinas como una estrategia pedagógica óptima para ejercitar conocimientos a la vez que desarrollar habilidades, afrontando situaciones similares a las del mundo real no sólo en términos individuales sino también en la acción coordinada, al mismo tiempo que ofrece un escenario para facilitar la incorporacióntransparente de la tecnología dentro del proceso de trabajo, por sus virtudes para alcanzar el logro de los objetivos.”
“En contextos
donde los requisitos son estables, esto ha funcionado bien. Sin embargo, con la aceleración en el ritmo de evolución tecnológica de las últimas décadas, la aplicación de este enfoque en escenarios donde los cambios frecuentes no sólo son inevitables sino incluso deseables, y donde la capacidad de predecir el resultado y el momento es menos importante que
garantizar la producción de valor genuino en el proceso, el modelo tradicional en cascada, predictivo, se ha revelado insuficiente. En particular, en la industria del software se ha vuelto evidente que cuando las definiciones de los requisitos son más dinámicas, inciertas o inestables, este modo de desarrollar produce sistemáticamente retrasos, altos costos para los proyectos e insatisfacción en el cliente”
Entre las conclusiones del trabajo una particularmente interesante, que apunta una nueva dimensión de Scrum: en la formación.
“Se podría incluso considerar Scrum dentro del aprendizaje basado en proyectos como un verdadero patrón pedagógico, que sintetiza en un conjunto de reglas simples, los principios y buenas prácticas para permitir a un grupo de trabajo transformarse en un verdadero equipo de alto rendimiento, en contextos de incertidumbre e interdisciplinariedad.”
… continúa en: “Una experiencia práctica de Scrum a través del aprendizaje basado en proyectos mediado por TIC en un equipo distribuido”
Una experiencia práctica de Scrum a través del aprendizaje basado en proyectos mediado por TIC en un equipo distribuido
View more presentations from Sergio Yazyi
“Forosíntesis” Scrum Manager
Algunas citas interesantes de lo leído estos días en los foros de Scrum Manager sobre horario de trabajo, motivación del equipo y síntesis entre procesos y metodología ágil:
Horario flexible y teletrabajo
De la discusión iniciada por Miguel Sierra.
“la métrica de horas en la oficina no tiene sentido. La métrica es la velocidad.”
“El teletrabajo está tan de moda que es “casi” políticamente incorrecto decir algo en contra.”… ” La flexibilidad exige una altísimo nivel de autodisciplina, compromiso, respeto, etc., que por desgracia no todas las personas están dispuestas a asumir.”
“Hay mejores resultados cuando hay mayor flexibilidad”
“Pero el hecho principal y fundamental, es el avance. El proyecto tiene unos requisitos, unos recursos y debe de entregarse en una fecha.”
“Nadie se plantea si Norman Foster trabaja desde casa o si hace horario flexible.”
“El que es de escaquearse, lo va a hacer estando en una sala rodeado de gente ó desde su propia casa.”
“Los horarios inflexibles, las métricas de horas como medida de produccion, y no medida de esfuerzo… lo unico que logran es aumentar la ley de parkinson.”
“Mientras el negocio se base en facturar horas, lo proyectos se midan en horas/personas”… “abandonar el modelo de negocio de consultoría y reorientarse a un modelo de industria donde no se facturan horas si no productos o servicios. ”
La motivación del Equipo.
De la discusión iniciada por José Vazquez
“Lo mejor es crear un buen ambiente. La gente trabaja mejor cuando se divierte. Ser politicamente incorrecto, bromear, permitr que la gente diga lo que piensa, que se sienta valorada. Que se sienta corregida, pero que sea tenida en cuenta, son factores que ayudan mucho. Las recompensas materiales no lo tengo tan claro.” ¿Motivamos equipos o motivamos personas? ¿La motivacion en cualquiera de los dos casos debe nacer del equipo?”
“Tratar de encontrar, con el equipo, las posibles causas de tal desmotivación y, en función de las mismas, las posibles soluciones.”
“La motivación en el fondo es transmitir la visión. El equipo debería tener ganas e ilusión por hacer o mejorar el producto. El product owner tiene que transmitir y contagiar esas ganas. Un poco aquello de no encargar construir un barco, sino transmitir el deseo de llegar a la isla.”
“La motivación no es binaria, que dentro de la motivación siempre hay lugar a la mejora aunque en ese punto se fusiona con manejar expectativas y para cada persona, para cada equipo.”
Síntesis entre disciplina y agilidad
Síntesis entre Disciplina y Agilidad
“¿CMMI? ¿Agilidad? ¿Las dos a la vez?. Yo prefiero una síntesis continua: aplicar de forma flexible los principios de unos u otros que considero adecuados a mi circunstancia sabiendo que eso no es CMMI y que Scrum es un marco no una metodología.”
” Así, el sendero es un CMMI ágil, un ITIL ágil… y un Scrum como marco (Nonaka y Takeuchi), no como metodología (Schwaber y Sutherland), que es lo que, en mi opinión, se suele entender por el mismo.”
“Los que sepan moverse bien entre dos aguas, adaptándose al entorno que les toque (más o menos ágil o corporativo) y aplicando los mejor de ambos mundos, son los que yo veo que perdurarán. Tiempo después, la teoría de la evolución entra en escena: sólo sobrevivien los mejor adaptados, y los demás desaparecen. Ya tenemos servida la nueva tesis.”
“Hay que leer y estudiar de todo, tener contacto con mucha gente y estar siempre abierto a nuevas ideas sabiendo que lo que llegará mañana puede ser mejor que lo que tengamos o hagamos hoy.”
“Mi impresión es que las metodologías ágiles no son la antítesis de las formales de procesos. Básicamente, creo que las metodologías ágiles son la síntesis entre el caos y los procesos que tratan de ser la solución por sí solos.”
“Es verdad que algunos son explicados como una síntesis final de un proceso dialéctico, pero qué podemos decir de la rueda, del sistema heliocéntrico de Copérnico o de la teoría de la relatividad de Einstein,”
Agilizando CMMI
Presentción de José Manuel Navarro con los conceptos clave que empleó en Unkasoft para impmantar un marco de trabajo con la síntesis del conocimiento aportado por CMMI y Scrum.
Más información sobre el principio de Síntesis de Scrum Manager:
- Principios y características de Scrum Manager
- Los hippies se ponen la corbata
- Síntesis
- Síntesis entre agilidad y disciplina.
Estimación basada en tallas para el cálculo del esfuerzo de las Historias de Usuario
A raíz del post Estimación basada en tallas que publiqué ayer (06/07/2011) en el blog Utópica Informática, me he decidido a escribir y compartir con la comunidad el artículo Estimación basada en tallas para el cálculo del esfuerzo de las Historias de Usuario.
En este artículo se contextualiza y explica en detalle esta técnica, poniendo al desnudo un procedimiento que facilitará el trabajo a los equipos que quieran estimar las Historias de Usuario de sus proyectos aplicando esta técnica.
Scrum Distribuido
Muchas empresas buscan operativas ágiles con equipos físicamente distribuidos, para sumar a las ventajas de la deslocalización los beneficios de la agilidad.
Este es un escenario de gestión que por relativamente reciente, y cuenta con escasa experiencia y conocimiento. Fue por eso el tema de trabajo elegido para desarrollar un documento de información y referencia y en primer taller de investigación de Open Knowledge, que acaba de publicar la primera versión del documento de análisis.
El objetivo del documento es ofrrecer una primera información de las implicaciones de Scrum en un contexto distribuido. Para ello parte de las definiciones base, e identifica los retos más relevantes para un equipo distribuido, recopilandoy analizando la información para cada uno, con la propia experiencia profesional, así como la del trabajo realizado para la ejecución del estudio, que es precisamente el trabajo de un equipo distribuido.
Han compuesto el equipo de desarrollo de esta primera versión:
Dirección: José Miguel Vera y Sergio Yazyi
Autores: Raúl Herranz, Noel Mamoghli, Sergio Yazyi, José Miguel Vera, Edgar González, Daniel Matulis, Victor Ratón, Miguel Salas, Salvador Arauzo, Felipe Muñoz y Luis Farias.
Del curso en Alicante de la semana pasada
Algunos momentos del curso de la semana pasada en Alicante, impartido por el centro oficial XtremoByte en colaboración con el COIICV (Colegio Oficial de Ingenieros en Informática de Valencia).
Y algunos testimonios dejados en la evaluación de control de calidad de Scrum Manager:
(Valoración global del curso: 9,2 sobre 10 – alumnos asistentes: 12 – Valoraciones: 11)
El curso es muy interesante, me alegro mucho de haberlo podido realizar y a partir de aquí espero poder colaborar con el movimiento Agile y crecer en este mundo.
Me aprece extramadamente util para gestionar grupos de desarrollo de todos los tamaños y agilizar los procesos de empresas y organizaciones de todos los tamaños, incluso para la gestión personal me parece que es muy interesante.
Rubén Martínez
El curso ha cubierto mis expectativas con creces, obteniendo una visión global, completa y práctica de una gestión de proyectos ágil como Scrum. Los casos prácticos han ayudado mucho a afianzar los conocimientos adquiridos en las sesiones teóricas, como debe ser 
OpenKM – Product Manager
Da una visión general de la gestión agil de proyectos viendose las ventajas que se obtienen aplicando la metodología a todos y cada uno de los departamentos de la empresa en general y en el desarrollo de software en particular.
José Olcina – Gerente
En general, fue, con diferencia, de los mejores cursos que me han impartido.
Felicidades a José Antonio y a Xtremobyte
José Galiana – Director de proyectos
Testimonios dejados por los alumnos en la valoración de control de calidad del curso Gestión de Proyectos con Scrum Manager.
Casos de utilización de Ruck (Scrum abierto)
Scrum se viene utilizando con éxito en muchos proyectos de desarrollo de software y hay muchos case studies y buenas prácticas de utilización de Scrum. Sin embargo apenas hay información sobre Ruck (Scrum en entornos abiertos), la diferencia entre Scrum y Ruck radica en que Scrum se aplica en un entorno cerrado (melé cerrada) mientras que Ruck hace referencia a entornos abiertos (melé abierta).
Sobre Ruck he encontrado que en Microsoft lo están aplicando, de hecho tienen esta guía sobre como lo aplican:
Pincha aquí para ver la imágen original
Los desafíos a los que se han enfrentado para implementar Ruck han sido:
- Equipos virtuales y distribuidos
- Miembros de equipo a tiempo parcial
- Diferentes usos horarios
Para hacer frente a esos desafíos han desarrollado la guía de Ruck sobre 4 pilares:
- Transparencia
- Inspección
- Adaptación
- Colaboración
los mismos que con Scrum, pero aplicados a un entorno distribuido y virtual. Podéis acceder al artículo original aquí
Creo que cada vez más iremos viendo como Scrum se va a ir abriendo para poder gestionar proyectos en entornos abiertos, implicando a equipos en diferentes localizaciones, equipos de diferentes empresas de diferentes culturas, etc… ¿Tienes alguna experiencia en Ruck?, ¿utilizas Scrum en entornos abiertos?
Gestión de cambios en Scrum
El otro día me preguntaron en el evento E-TIC de Sevilla vía twitter (@emartos) por cómo podemos realizar una gestión de cambios desde Scrum. He creido que igual podíamos compartir la forma en que vemos la gestión de cambios desde la agilidad. Tomamos como partida mi contestación a @emartos
QUÉ ES UN CAMBIO?
Digamos que una modificación en el alcance de una o varias piezas de un proyecto.
Entendamos por pieza del proyecto tanto las historias de usuario como las tareas que las conforman. Los cambios pueden afectar a lógica del proyecto, funcionalidad, tecnología empleada, entorno del proyecto, etc…
No debemos considerar cambios a las incidencias, bugs, etc.. que nos aparecen a lo largo de todo proyecto. Aunque a la hora de tratarlos podamos seguir en parte la forma en la que los tratamos.
TIPOS DE CAMBIOS
Me voy a basar en los tipos de cambios que dice ITIL sin tener en cuenta los cambios estándar o pre-autorizados. Nos quedaremos pues, con dos tipos, cambios Normales y de Emergencia.
De forma resumida:
- Los cambios Normales, son aquellos que tienen que ser revisados por el conjunto equipo-Scrum Manager (ScrumMaster)-Product Owner. Pueden llegar en cualquier momento pero no implican acción inmediata.
- Los cambios Emergencia, son aquellos tan inesperados como los Normales pero que nos implican acción en el mismo momento en el que llegan.
Además en ITIL hay un responsable de autorizar los cambios. Es el Gestor del proceso. En nuestro mundo ágil ese responsable será el Product Owner.
IMPACTO DE LOS CAMBIOS
Otro aspecto que tenemos que valorar es el impacto del cambio en nuestro proyecto/Sprint.
- Sin Impacto destacable. El cambio no afecta de forma sustancial al objetivo del proyecto o Sprint
- Impacto sustancial. El cambio afecta de forma sustancial o al proyecto o al Sprint.
……
Bueno tenemos las piezas, arranquemos la gestión de cambios.
CAMBIOS NORMALES
Los cambios Normales, llegan en cualquier momento y se han de ‘encolar’ hasta la próxima reunión de preparación de Sprint donde habrá que tratarlos y ver si se aceptan y entran a formar parte o modifican de alguna forma el Product Backlog.
Recordemos que el propietario del Product Backlog es el Product Owner y el será, como hemos dicho, el responsable de autorizar la modificación, eso sí, asesorado por el Equipo
Creo muy recomendable dejar claro al inicio del proyecto, entre Product Owner y el Equipo la forma en la que se van a tratar los cambios y evitar que esos cambios Normales nos interrumpan el Sprint. Lo digo porque seguro que si has estado en cualquier proyecto te han llegado esos cambios ‘Normales‘ que hacen que des la vuelta al proyecto cada semana
CAMBIOS DE EMERGENCIA
Ahora los difíciles, los de ‘Emergencia’, alguno pensará que el 90% de los cambios que le llegan son de ‘Emergencia’ Si es tu caso, mal vamos .
Los cambios de Emergencia, como los Normales, llegan en cualquier momento, pero estos implican que tenemos que actuar.
Debe estar prefijado entre Product Owner y Equipo, QUÉ SON cambios de Emergencia o al menos QUÉ NO SON cambios de Emergencia, que permita determinar si algo realmente es susceptible de ser tratado en cuanto llegue o puede esperar a la finalización del Sprint.
Hay dos tipos de Cambios de Emergencia según su impacto, los de bajo/sin impacto y los de Impacto sustancial.
CAMBIOS DE EMERGENCIA SIN IMPACTO SUSTANCIAL
Para los primeros (bajo o nulo impacto) debemos tener un procedimiento preparado para asumir la llegada de ellos sin que nos distorsione mucho el flujo del Sprint:
- Si usas Kanban quizás dejar un camino para estos cambios y preparar el WIP limit de la columna ready para asumir ese extra. Esto te permitirá asumir las tareas derivadas del cambio.
- Otra cosa es calcular la velocidad de tu equipo en función del % de esfuerzo que te vayan a requerir estas acciones extraordinarias. En lugar de 40 Puntos por semana, igual solo puedes tener 30 puntos y sabes que 10 los vas a dedicar a estos cambios… Analiza tu historia en el proyecto o en tu entorno. Esto es semejante a como podemos tratar incidencias, bugs, etc…
Cada conjunto product owner + equipo usará el proceso que mejor encaje.
CAMBIOS DE EMERGENCIA CON IMPACTO SUSTANCIAL
El problema son los cambios Urgentes con Impacto sustancial.Creo que este tipo de cambios deben tratarse y resolverse en la reunión de planificación del Sprint. Así que cuando llega un cambio así hay que:
- Preguntar si el cambio puede esperar ya que no afecta al Sprint.
- Si la respuesta es SI. Terminar el Sprint y en la reunión de planificación del siguiente Sprint tratarlo y construir el siguiente Sprint.
- Si la respuesta es NO (por su alto impacto en el proyecto o porque si que afecta al Sprint). La acción es fácil. Interrumpir el Sprint y volver a la planificación. La decisión de la interrupción del Sprint la ha de tomar el Product Owner. Debidamente informado por el equipo y valorando el impacto que trae dicha interrupción.
Una última cosa. Los cambios mejor al principio de los Sprints
Y tu? Gestionas los cambios? Cómo?
