Scrum y XP desde las trincheras
Escrito el 26 de Febrero de 2008 a las 19:51
Uno de los libros que más recomendamos para la gente que quiere aprender más sobre Scrum y, especialmente, cómo implementarlo de forma efectiva es el magnífico “Scrum&XP from the trenches” de Henrik Kniberg. En este libro Henrik no se dedica a profundizar en los conceptos teóricos de Scrum, su procedencia y su relación con las metodologías ágiles o las ventajas de este tipo de metodologías frente a los enfoques más tradicionales o pesados. En su lugar, Henrik pasa directamente al meollo de la implementación de Scrum con un enfoque eminentemente práctico y holístico: qué hemos probado, qué fue mal, que hicimos en su lugar, por qué nos funciona mejor…
El libro está disponible de forma gratuita en InfoQ, un magnífico recurso para los interesados en las metodologías ágiles y el desarrollo de software en general. Dada su naturaleza abierta, hace unos meses contactamos con Henrik y le contamos que utilizábamos gran parte de su libro en la preparación de nuestros cursos o en los proyectos de consultoría e implantación de Scrum en empresas, y como agradecimiento nos ofrecimos a traducirlo al castellano. Henrik nos ofreció su colaboración y visto bueno desde el principio, y fruto de dicho ofrecimiento queremos poner a vuestra disposición el primer borrador de Scrum y Xp desde las trincheras en castellano.
La URL por si queréis incluirla en vuestros blogs sería http://www.proyectalis.com/scrum-y-xp-desde-las-trincheras. Espero sinceramente que lo disfrutéis tanto como yo. ![]()
Certificación Scrum Master en Febrero - Madrid
Escrito el 30 de Enero de 2008 a las 19:37
Me comentan que todavía hay algunas plazas disponibles para el seminario de certificación Scrum Master que se celebrará los próximos días 14 y 15 de Febrero en Madrid. Creo que es una buena oportunidad para aquellos que estén empezando con Scrum o quieran perfeccionar sus habilidades como Scrum Master e intercambiar experiencias con otros profesionales. Razón aquí.
Por lo demás, si las fechas no os cuadran, Madrid os pilla mal o el inglés os supone una barrera, ya sabéis que en Proyectalis organizamos cursos similares para empresas en castellano y con una duración de dos días o tres tardes intensivas (fin de la cuña publicitaria
).
Para saber más sobre el CSM, mirad aquí o aquí.
Experiencias reales con Scrum
Escrito el 21 de Enero de 2008 a las 12:40
Como sabéis, el pasado mes de Noviembre estuve realizando un curso de Scrum para la empresa Peopleware. Es para mi una gozada leer hoy cosas como esta:
Scrum y Teletrabajo
Ya hemos terminado el primer apretón y estamos en el segundo, así que hay algunas conclusiones al respecto de trabajar con una metodología como Scrum, pero antes de nada, en líneas generales, el perfil del equipo de Osmius:
* Somos un equipo pequeño y no queremos crecer a más de 7 u 8. Preferimos dividir y tener otros equipos.
* Hay confianza: Tú sabrás cómo te organizas y cómo cumples tus compromisos con el resto.
* El dueño de producto es interno. No hay un cliente claro presionado aunque abrimos los requisitos además del código.
* En media nos conocemos y hemos trabajado juntos hace… unos diez años.
* Nos gusta un montón el proyecto. Pero tampoco nos importaría empezar otro en unos meses.
* En general preferimos tiempo libre a dinero.
* El equipo es partícipe de los beneficios del proyecto.
* Todos bailamos o cantamos fenomenalBien, pues resulta que además de meternos con Scrum hemos empezado con el teletrabajo, y algunas conclusiones han sido:
* Scrum nos ha metido presión. Sensación de ¡vamos, vamos, vamos!
* Somos más efectivos que antes. Cerramos más tareas y cuando lo ves no te lo crees.
* El teletrabajo es un lujo. Ahorro de tiempos, buenas sensaciones…
* Hay que tener contacto diario. El Scrum diario con Skype y las horas en la hoja de cálculo Google han sido fenomenales.
* Toda la semana en casa no mola. Nosotros quedamos en la ofi lunes y jueves. Menos es desagradable.
* Cada uno es responsable de sus tareas para bien y para mal, y los problemas son de todos… o nos vamos a la mierda.
* Hacemos demo en cada apretón y cada dos o tres apretones sacamos versión. Nos da sensación de avance.
Esta es la gráfica del Apretón de la alpha de Osmius 8.01. Según pasan los días vamos quitando trabajo siendo la idea estar con la línea roja por debajo de la línea azul de pendiente constante. En otra ocasión podemos comentar algunas obviedades según sean las panzas y el aspecto de la curva ¿no?
Por cierto el jueves 7 de febrero a las 20:30 hacemos demo en Peopleware. Pasaos sin más o si preferís escribidme a joseluis [puntito] marina [arrobita] peopleware [puntaco] es.
Así que ya sabéis: si queréis avanzar en vuestro camino hacia la productividad, la motivación y una vida personal y profesional más satisfactoria, Scrum puede ayudaros, y nosotros estamos a vuestra disposición.
Cita
Escrito el 17 de Enero de 2008 a las 23:52
There are (software development) organizations
that are more productive than others. ‘Luck’ is not the
whole story; you need to look for ways to improve.”
Myers, 1998, vía una presentación de Jeff Sutherland.
Manda webs…
Escrito el 19 de Diciembre de 2007 a las 10:58
Hace un par de semanas puse una oferta de empleo en Infojobs. Buscamos gestores de proyectos en el ámbito de las telecomunicaciones y las tecnologías de la información, con al menos tres años de experiencia y manejo del inglés con soltura, aunque las principales características que evaluamos son unas excelentes habilidades interpersonales, una alta capacidad de análisis y síntesis de los problemas y oportunidades observados en el desempeño de sus funciones, un conocimiento tecnológico adecuado a los proyectos en los que vaya a participar y algo de formación específica en las técnicas, metodologías y herramientas de gestión de proyectos. Se trata de un puesto orientado a trabajar en proyectos de nuestros clientes más que a engrosar la estructura interna de la empresa, eso sí, y buscamos titulados en Ingeniería Superior de Telecomunicaciones, Informáticas o con formación/experiencia equivalente. En el fondo, en realidad, lo que buscamos es gente con pasión y con talento, pero claro, eso es dificil de cuantificar en primera instancia.
Entre las cosas que ofrecemos están (cito) “la flexibilidad de horarios, el compromiso de formación interna y externa, las facilidades para el Teletrabajo, una filosofía OpenBusiness y la oportunidad de participar en un proyecto jóven con gran proyección de futuro“. Además de una banda salarial de entre 24.000 y 36.000 euros. Que digo yo que no está nada mal.
A la oferta han respondido 61 candidatos, de los cuales unos diez cumplían muy bien con las expectativas que tengo al respecto (al resto, gracias por el interés, y a los 21 que se han descartado por estar absolutamente fuera de nuestro área de interés…En serio, replanteaos la estrategia de apuntaros a todo lo que se mueva, que quema mucho, a vosotros y a nosotros). A los finalistas se les ha mandado un correo explicando mejor el proceso, el timing que estamos manejando, algunas características del puesto y pidiendo algo más de información sobre su situación actual, lo que les ha gustado de la oferta y de la empresa… No he mandado un correo similar a los 30 restantes más por falta de tiempo y de una utilidad en Infojobs que permita mandar un mensaje-tipo a una selección de perfiles (tendría que ir abriendo uno por uno y cogiendo las direcciones de correo…Señores de Infojobs, tomen nota, que esto es consultoría gratis). De todas maneras nos quedamos con estos perfiles para posibles necesidades en el futuro, ya que en general son interesantes.
Bueno, pues de los seleccionados y contactados el 75% ni siquiera me ha contestado al correo, y de eso hace ya una semana. Dicen algunos amiguetes que Infojobs tiene herramientas que te apuntan automáticamente a las ofertas en función del campo de conocimiento, salario, ubicación… Yo creo recordar que Infojobs te avisa de estas ofertas, pero dudo que te pueda suscribir directamente sin tu aprobación específica, y si es así me parece muy mal, sinceramente.
Volvemos a mis preguntas de siempre:
- Suponiendo que te arrepientes de apuntarte a la oferta, o que te han apuntado automáticamente y en realidad no te interesa, ¿Ni siquiera has considerado el poner un par de líneas a una persona que se dirige a ti respetuosamente y ofreciéndote la posibilidad de trabajar con ella?
- ¿Tan bien está el mercado de trabajo que la gente se permite estos lujos?
- Incluso tirándome piedras a mi propio tejado, porque me podría hacer perder algo de tiempo: suponiendo que no te interesa el puesto, ¿No es una buena oportunidad para practicar las entrevistas de trabajo, o simplemente para conocer gente que se mueve en el mismo mercado que tú?
- Suponiendo que se trate de un problema de salario ¿Cuánto hay que ofrecer para atraer perfiles? Y siendo así, ¿A cuánto habría que vender a los clientes, partiendo además de la base de que es raro que tengas al personal dedicado el 100% del tiempo, máxime cuando estás empezando? (Cuando ya tienes inercia en esto de la consultoría la cosa cambia, y hay muchas empresas que tienen a sus profesionales dedicados al 250%, o por lo menos eso se factura).
- Dado que no pienso que sea un problema de salario (o por lo menos, no exclusivamente), ¿Qué opciones hay para poder encontrar a la gente con talento y pasión?
PD: El proceso sigue abierto, por si algún lector se siente cualificado y con ganas… Hay otro puesto más estructural, peor pagado pero con mayor apego y responsabilidad en la empresa. Lamentablemente para vosotros, ese tiene novia hoy por hoy… ![]()
Calendario compacto 2008
Escrito el 6 de Diciembre de 2007 a las 13:52
Micropost: calendario compacto 2008 ya disponible. Razón aquí.
PD: Ya que váis de mi parte, portaos bien y no dejéis de visitar las 37 utilidades para GTD, productividad y gestión del tiempo. Alucinante.
Un comentario del blog
Escrito el 30 de Noviembre de 2007 a las 19:59
El scrum lo descubrí hace unos dos meses, a través de tu blog y me documenté un poco.
Hace un mes, en mi empresa ganamos dos proyectos idénticos que duraban 20 días. Yo lideré uno de ellos, y decidí aplicar un poquito de Scrum, sólo las reuniones matinales repasando qué hice ayer, qué voy a hacer hoy y qué necesito.
Situación inicial, un gerente liderando cada proyecto con una dedicación de 15 horas para los 20 días. Dos equipos idénticos con un jefe de proyecto cada uno, un analista funcional y dos analistas técnicos. Los resultados: el jueves de la semana pasada liberé un analista técnico, el viernes otro, el martes al funcional, y el miércoles al jefe de proyecto, cumpliendo exactamente los 20 días que habíamos planificado con reiteradas felicitaciones del cliente. Ni siquiera he llegado a dedicar las 15 horas.
El otro proyecto aún no ha terminado, terminará el miércoles de la semana que viene y sigue manteniendo todo el equipo.”
Sólo de pensar que hay gente que está encontrando formas mejores de hacer las cosas gracias a este blog, y que eso les está permitiendo llegar a lo que llamo el subidón de “puñeta, somos buenos“… En fin. Que me he emocionado, vaya.
Gracias, Ricard. Gracias de verdad.
Cosas que hacen que Scrum funcione
Escrito el 30 de Noviembre de 2007 a las 13:11
Que sí, que sí: que scrum es muy sencillo. Que se explica en cinco minutos. Que se lo puedo explicar hasta a mi abuela. Pero que algo más tendrá Scrum cuando en el último curso hemos estado dieciséis horas analizándolo (sin contar almuerzos) e incluso nos ha faltado tiempo.
Scrum es indudablemente más sencillo que los frameworks pesados para la gestión de proyectos como puedan ser el PMBOK o Métrica V3 (¡ergs!), e incluso más sencillo que las versiones “lite” que se han diseñado de los frameworks pesados, como puede ser Prince2. Pero eso no quiere decir que si echamos a andar los famosos tres procesos, tres artefactos y tres roles ya lo tengamos todo hecho. Hay muchos aspectos que son los que hacen que Scrum funcione, y la atención a estos aspectos marca la diferencia entre el 66% de empresas que consiguen implantar Scrum efectivamente y el 33% que abandona por el camino (datos de la Scrum Alliance).
Ahora que empieza el iweekend (que rabia habérmelo perdido) y sabiendo que Raúl está mirando metodologías ágiles para aplicarlas, me he decidido a escribir este post. En base a mi experiencia y a literatura existente (que la hay como para enterrar a un gran danés en papeles), las cosas que hacen que Scrum funcione son las siguiente:
- Scrum es sencillo, pero muy duro. Como un canto rodado, vaya. Si pensamos que Scrum no nos va a requerir un esfuerzo, es más que probable que la gente abandone cuando se de cuenta de que exige una importante dedicación, un proceso de gestión del cambio que puede llegar a ser muy complicado y un nivel de foco superior al que se habitualmente se tiene en las organizaciones. Aun así, los resultados que Scrum proporciona en términos de productividad, calidad, satisfacción, éxito y rentabilidad de los proyectos hacen que el esfuerzo merezca la pena.
- Scrum no es una bala de plata. Esto, junto con lo de las gallinas y los cerdos, es uno de los principios más citados de Scrum. Cuando la gente se sumerge en el mundo de las metodologías ágiles y ven lo que pueden llegar a conseguir siente la tentación de recetar “café para todos” (en palabras de Mario). Y eso no es así. Scrum tiene su territorio: proyectos complejos, con un requisitos cambiantes, organizaciones flexibles, implicación del cliente… En otros entornos es mejor usar otras cosas. Por otra parte, Scrum no va a solucionar todos los problemas de la organización. Si falta compromiso de la gerencia, si hay compañeros obstruccionistas., si el cliente es un explotador…Bueno, Scrum no va a solucionar todo eso. Si pensamos que sí y fallamos, sentiremos la tentación de abandonar Scrum. Por eso es importante recordar constantemente que Scrum no es una bala de plata.
- Scrum es iterativo e incremental. Repetid conmigo: iterativo e incremental. Iterativo e incremental. Eso quiere decir que liberamos código (o producto) frecuentemente, y cada liberación representa un incremento sobre la anterior. Pensad más en “Casa 0.1″, “Casa 0.2″ hasta “Casa 1.0″ que en “cimientos” seguido de “paredes” seguido de “techo”. No podemos liberar una casa sin techo, pero a lo mejor sí una casa con paredes de chapa y techo de uralita (version “chabola”… Todo tiene un mercado).
- El producto que funciona es la única medida del avance del proyecto. Si me tuviera que tatuar una frase sobre Scrum, sería esta. No cuántas horas hemos echado. No cuántos recursos llevamos consumidos. No cuántas tareas llevamos hechas. Producto que funciona. Si no hay producto que funciona, no avanzamos. Lease el punto anterior.
- Todo en Scrum tiene un límite de tiempo. Para esto me gusta mucho la expersion inglesa time-boxed, que lo expresa mejor. Nada de “alargamos la reunión un poco más”. Nada de “El lunes, tal vez el martes”. La reunión acaba a las cuatro, y trabajaremos con lo que tengamos al final de la misma. La entrega es el lunes, y entregaremos lo que tengamos el lunes. Scrum cambia el enfoque tradicional del PMBOK de recursos+funcionalidades deseadas = fecha de entrega y lo convierte en recursos + fecha de entrega = funcionalidades que podremos entregar. Si se nos cae una funcionalidad de la lista, vaya por Diox. Pero entregamos.
- Las entregas son productos potencialmente utilizables y/o comercializables. Shippable, que dicen los ingleses. Eso significa que nada de power point y nada de planos o documentos describiendo lo que hará la aplicación: queremos tocar, ver y usar algo, aunque sea un prototipo de la funcion de login.
- Definir qué significa terminado. Terminado puede querer decir “rula” o puede querer decir “rula, ha pasado los tes de calidad, se ha documentado, se ha añadido al repositorio y hemos formado a soporte técnico”. No es lo mismo. El trabajo no se acaba hasta que se acaba.
- Mantener Sprints de duración fija. Al principio es muy tentador andar tocando la longituds de los sprints para adecuarlos al producto, en vez de adecuar el producto a los sprints. Pero si hacemos lo primero nunca seremos capaces de obtener una sensación correcta en el equipo de cuánto trabajo podemos abarcar en un Sprint. Scrum es disciplina: quien piense que las metodologías ágiles on una especie de hacking institucionalizado, se equivoca.
- Realizar los Scrums diarios. Es una de la sprimeras cosas que se abandona, como decían en su día en el blog de chuidiang. Pero el Scrum diario es la unidad atómica de Scrum, y si empezamoscargándonos esto, no podemos esperar que los ladrillos se mantengan unidos. El Scrum diario es lo que consigue que podamos controlar a tiempo, que tengamos visibilidad efectiva, que el equipo sincronice sus tareas… Hay que protegerlo a capa y espada, y ser muy estricto con su celebración. Por eso lo de “todos los días en el mismo sitio, a la misma hora”. Si empezamos a cambiar las horas todos los días, acabaremos por no celebrearlo un día. Entonces pensaremos “anda, no ha pasado nada” y empezaremos a saltárnoslo cada dos por tres. Y entonces estaremos en la situación sobre la que nos previene el ScrumMaster Miyagi: haremos “Scrum supongo”.
- Hacer retrospectivas. Lo más importante de las retrospectivas es asegurarse de que se celebran. Las retrospectivas son lo que nos permite detectar impedimentos de alto nivel en el proceso y mejorar constantemente. Si nos enfocamos demasiado en los sprints y en producir y no nos paramos de vez en cuando a reflexionar, todo el enfoque empírico y adaptativo de Scrum se nos viene abajo. Como decían por ahi, “si siempre estás sprintando, en realidad acabarás haciendo jogging”.
- Respetar los roles: Sólo el Dueño de Producto puede tocar la pila de producto. Solo el euipo puede tocar la pila de Sprint. Permitid que los Jefes manoseen la pila de producto o que el dueño de producto trastee con la pila de sprint y acabaréis con unos equipos que mandarán Scrum a hacer gárgaras hartos de que no se les deje trabajar ni se confíe en ellos. Scrum es adaptativo, pero eso no quiere decir que todos los días peguemos volantazos: es más bien hacer pequeños movimientos de volante constantemente para mantener al coche en la carretera. Aquí es donde viene bien la historia de las gallinas y los cerdos: distingamos también entre miembros del proyecto y stakeholders.
- El Scrum Master no es un jefe. Es un “siervo-lider”. No le dice a la gente lo que debe hacer. No divide las tareas entre los miembros del equipo. No acepta o rechaza las funcionaldiades. El equipo es quien decide, y el dueño de producto el que evalua. El Scrum Master sólo debe preocuparse de que el proceso Scrum siga en marcha y de eliminar los impedimentos en el camino del equipo. Tiene más de Coach que de Project Manager.
- No interrumpir constantemente a los equipos durante los Sprints. Si no confiamos en los equipos y les dejamos trabajar, ¿qué estáis esperando que ocurra? Una terminación anormal de Sprint debería significar que algo muy gordo está pasando en la empresa o en el proyecto. Y si hay que hacer re-priorizaciones, que afecten al próximo sprint en la medida de lo posible, no al que está ahora mismo en marcha.
En fin, probablemente no estén todos los que son, pero son todos los que están. Espero que esta lista os sea de utilidad implantando Scrum, y vigilaré ansioso los twitter del iweekend este fin de semana. ¡Animo tíos!
PD: Para los supersiticiosos, cogéis el punto 11 y lo dividís en “solo el dueño de producto toca la pila de producto” y “solo el equipo toca la pila de sprint”…¡Voila! 14 puntos. ![]()
Los clientes opinan
Escrito el 29 de Noviembre de 2007 a las 20:54
¡Ay, estafadores del mundo! ¡Ay, consultores de pacotilla, gurús de papel mojado, expertos sin experiencia, toreros de salón! Arrepentíos, pecadores, el fin está cerca. Porque dentro de poco ya no seremos un porcentaje los que escribimos en Internet: será la norma. Y entonces todos podremos saber cuánto de verdad hay en vuestros discursos y en vuestra venta de burras.
En lo que a mi respecta, aplícome el cuento: aquí tenéis una referencia del curso impartido en Madrid a principios de esta semana. Vale, es cierto, invité a unos vinitos el lunes por la noche, pero quiero pensar que no ha tenido nada que ver
.
Por cierto, que la aplicación que han hecho de Google spreadsheets / Google docs para seguimiento de Scrum me ha sorprendido hasta a mi. Gente amable, simpática, agradecida, con ganas y con iniciativa. Así da gusto trabajar.
Certificación PMP
Escrito el 15 de Noviembre de 2007 a las 18:30
Recibo cierta cantidad de mensajes preguntando por los pasos necesarios y recursos disponibles para obtener la certificación PMP (os recuerdo que estoy en ello). Recuerdo que en su día ya me resultó algo confuso obtener información sobre la forma en la que solicitar el exámen, dónde hacerlo, el coste del mismo o cómo prepararlo. Ervin me ayudó en su momento a solucionar varias de estas dudas, así que os resumo a continuación lo que conozco al respecto:
- La certificación la expide el Instituto Internacional de Gestión de Proyectos (PMI). No es necesario ser miembro del mismo para obtenerla, pero lo recomiendo, ya que da acceso a bastante documentación, la revista e incluso a un descuento para hacer el exámen. Haceos miembros, haced el exámen y determinad en el futuro si queréis seguir pagando la cuota correspondiente. Lo que hoy por hoy no me ha merecido la pena aun es haberme apuntado a los grupos de interés de telecomunicaciones y administracion (GovSIG), así como al capítulo de Madrid (que, sinceramente, no ha hecho nada desde que soy miembro). Obviando los costes de estos tres grupos creo que la anualidad del PMI no llega ni a los cien euros, así que creo que es interesante para todos los que queráis hacer carrera en esto de la gestión de proyectos.
- Para poder optar al certificado hay que tener un mínimo de 4.500 horas de experiencia en gestión de proyectos si se cuenta con una titulación universitaria y 7.500 en caso contrario. Además, hay que haber recibido al menos 35 horas de formación específica sobre gestión de proyectos. Estos aspectos se declaran en la solicitud de certificación con bastante detalle, y a un porcentaje de los solicitantes se les requiere que aporten documentación que respalde la experiencia y la formación acreditadas.
- Para solicitar el certificado hay que acceder a la web del PMI a través de http://www.pmi.org/certapp. Necesitaréis crear un usuario válido.
- Una vez rellenada la solicitud, el PMI la estudiará y te dará el visto bueno o te pedirá más documentación en pocos días
- A partir de que se te considere apto, una vez pagadas las tasas del exámen (entre trescientos y pico y cuatrocientos y pico euros dependiendo de si eres miembro del PMI o no) puedes pedir cita en cualquier centro prometric para hacer el exámen (en España creo que hay uno en Madrid y otro en Barcelona). Se puede hacer el exámen en inglés o en español.
- Para prepararse exámen uno mismo el material básico es el marco de conocimiento de la gestión de proyectos (PMBOK) editado por el PMI. Al hacerse miembro recibes un CD con la última versión, aunque hay algunas disponibles para descarga gugleando un rato. Cuidado que sea la más reciente (2005, tercera edición), que tiene unas 400 páginas, frente a versiones más “light” anteriores.
- Existen varias empresas que dan formación específica para la preparación del PMP, así como algunos recursos on-line. Ervin me recomendó en su día el de Rita Mulcahy, que al parecer tiene muy buen material si Inglés no es un impedimento. Si os hacéis miembros del PMI, en la revista tenéis un montón de empresas que dan formación on-line, así como libros y más material.
Una vez obtenido el PMP hay que mantenerlo a lo largo del tiempo obteniendo PDU’s (Personal Development Units) a razón de unos 60 al trienio… Pero eso, amigos míos, es otra historia
¡Inter Project! (Y mucho material Scrum)
Escrito el 12 de Noviembre de 2007 a las 21:50
JO-ROBA, ya era hora…
La última vez que hablé de la situación de Inter-Project prácticamente me quejaba de la sensación de “calma chicha” que hay cuando termina un proyecto y esperas a que comience el siguiente. Esta vez realmente me empezaba a hacer falta, ya que ha coincidido un pico interesante de trabajo con que mi mujer se pusiera a todo trapo a preparar unas oposiciones y que me entrasen albañiles en la casa. Pero en fin, gracias a Diox nada que un buen Project Manager no pueda manejar con la mano izquierda…
Los últimos proyectos que he desempeñado han tenido mucho que ver con Scrum, tanto a nivel de desarrollo como en lo que respecta a consultoría y formación, por lo que la certificación me ha venido francamente bien para ponerme las pilas. Aunque sinceramente la certificación ha sido el punto de partida: desde el curso de Madrid, mi interés por Scrum aumentó considerablemente, y aunque ya había leido los clásicos sobre el tema y había utilizado Scrum, durante el último mes he incluido a la lista User Stories Applied, de Mike Cohn (mi nuevo heroe ágil), Peopleware, y varios estudios, artículos y presentaciones de la Scrum-Elite, verbigracia, el anteriormente mencionado Mike Cohn, Jeff Sutherland, Ken Schwaber y Boris Gloger. Entre estos últimos os recomiendo “The Scrum Papers”, disponible para descarga por cortesía de crisp.se, la empresa de Henrik Kniberg (autor de “Scrum y XP desde las trincheras”) y todo el material disponible en Mountain Goat.
Todo esto me ha venido de fábula, ya que de repente y para mi sorpresa y alegría recibí una petición de una empresa bastante grandecita (cotiza en el NASDAQ :-O ) para que les montase un curso de Scrum en un tiempo record (bendito AdWords). Afortunadamente tenía mucho material ya listo para el curso del 15 y 16 en Sevilla, así que entre esto y toda la anterior preparación que os comento creo que ha quedado un curso de fábula. Yo personalmente me lo he pasado en grande, y creo que finalmente hubo bastante inquietud por progresar con Scrum en el futuro. Seguiremos informando.
Siguiendo con los recursos Scrum, tengo pendientes dos cosas: una es este video que encontré ayer en YouTube, dentro de la serie de sesiones Google Tech:
Pues si, el que veis es el mismísimo Padrino del Scrum, Jeff Sutherland.
El otro es el libro (¡en castellano!) de Juan Palacio, posiblemente la persona que más ha hecho por popularizar Scrum en España. Tiene una pinta estupenda y prometo una revisión a conciencia en cuanto lo termine. Ante todo, muchas gracias, Juan
En fin, que aparte del tema Scrum, en el que estoy muy metido, las cosas van marchando francamente bien. He cerrado un bonito proyecto de desarrollo que parece apuntar a posibles ampliaciones en el futuro, comienzo en breve un proyecto de consultoría de un año, estoy con otro proyecto de gestión en paralelo que posiblemente me lleve a Munich dentro de un mesecito…Por cierto, el 26 y 27 estaré en Madrid impartiendo un curso de Scrum. Si alguna empresa quiere montar uno para el 28, 29 o 30… Me vendría muy bien de calendario, gracias…
Ah, y que volvemos a la carga con los blogs, que los tengo abandonados… ![]()
El Scrum Diario disfuncional (II)
Escrito el 11 de Octubre de 2007 a las 21:59
Escribí ayer sobre el video del Scrum Diario Disfuncional y resulta que hoy, documentándome para el curso de Scrum que damos en Noviembre, he encontrado el origen del video. Se trata de un ejercicio en el que cada uno recibe una carta y debe representar ese papel en el Scrum diario. El ejercicio permite a los participantes experimentar el peor Scrum diario del mundo, pero sobre todo les permite reflexionar después sobre lo que se debe o no se debe hacer y les ayuda en el futuro a identificar estos comportamientos y atajarlos cuanto antes. Los roles que se reparten son:
- Llegas tarde al Scrum
- Se muy vago sobre lo que hiciste ayer
- Intenta distraer a las personas que tienes al lado
- Se muy técnico sobre lo que hiciste o vas a hacer, de forma que nadie entienda lo que dices
- Llevas cinco días atascado en la misma tarea
- Intenta hablar lo máximo posible sobre lo que hiciste ayer o vas a hacer hoy
- Interrumpe constantemente al resto mientras hablan
- Eres el Scum Master. Debes conducir el Scrum Diario
Hay que ser muy malo para diseñar un ejercicio así, la verdad…Sólo un sádico lo emplearía en su curso…
Vía AgileSoft, web.mac.com
El Scrum Diario Disfuncional
Escrito el 10 de Octubre de 2007 a las 23:35
Una de las cosas más duras que tiene Scrum como metodología son los Scrum Diarios. Como sabéis, son reuniones rápidas que se realizan todos los días, idealmente en el mismo sitio a la misma hora, y en la que cada miembro del equipo comenta qué ha estado haciendo desde ayer, qué piensa hacer hoy y qué impedimentos encuentra en su tarea. El Scrum Master utiliza esta información para poder identificar y eliminar los riesgos que existan en el Sprint y para poder realizar un seguimiento del avance (aunque el equipo sigue siendo responsable de actualizar la pila de Sprint).
Como decía, esta es una de las partes más duras, y eso que se trata de dedicar cinco a quince minutos al día únicamente: parece un precio muy pequeño si con ello reducimos la carga de gestión, los informes que se deben generar cada dos por tres y a cambio ofrecemos una visibilidad superior sobre el proyecto, al tiempo que aprovechamos para reforzar la sensación de equipo y mejorar la comunicación. Pero la verdad es que pasada la novedad de los primeros días siemrpe surge quien no entiende la utilidad de estas reuniones, y las califica de un “esfuerzo” o una “pérdida de tiempo”. En otros casos comienzan a aparecer otras prioridades (”tengo una reunión con Marketing”, “mañana no puedo, que llegaré tarde”, “ahora mismo me pillas en medio de algo importante”)…
En este video tenéis a Stacia Broderick, de quien tuve el placer de aprender en el seminario Certified ScrumMaster de Madrid hace poco, interpretando con varios Certified Scrum Trainer lo que sería el “Scrum Diario del infierno”, en el que cada uno va por libre, se interrumpen unos a otros, llegan tarde, hablan por teléfono… Si vuestros Scrum diarios se parecen a esto o no los estáis haciendo en absoluto, cuidado: estáis caminando por la senda del desastre ![]()
Curso de Scrum en Sevilla
Escrito el 30 de Septiembre de 2007 a las 21:36
Los próximos días 15 y 16 de Noviembre Proyectalis (es decir, este que suscribe) imparte en Sevilla el curso “Scrum: metodología ágil de gestión de proyectos“. A lo largo del mismo se estudiarán todos los aspectos relacionados con Scrum y la mejor forma de adaptar e implementar esta metodología a las empresas.
SCRUM es una de las más conocidas metodologías ágiles, y se basa en un enfoque iterativo, donde cada iteración se denomina Sprint. La diferencia con las iteraciones en cascada es que al final de cada Sprint obtenemos un producto entregable que se va incrementando en sucesivos Sprints. El principio básico es que es muy difícil contar desde el principio con un catálogo completo de funcionalidades, ya que los requisitos van surgiendo conforme el propietario de la aplicación y los usuarios de la misma van haciendo sucesivas aportaciones. Así pues, SCRUM plantea el desarrollo de sucesivas versiones ampliadas, todas ellas plenamente usables y evaluables por el usuario. SCRUM es, además, una metodología especialmente indicada para pequeños equipos de desarrollo y se orienta a una entrega rápida de resultados y una alta flexibilidad.
Para más información podeis consultar la página del curso. Ah, y si os lo estáis pensando, no lo dudéis: nos lo pasaremos de fábula, lo prometo ![]()
Por un gobierno ágil
Escrito el 26 de Septiembre de 2007 a las 20:44
Desde que volví la semana pasada del seminario de certificación en Scrum estoy, lógicamente, mucho más sensibilizado y entusiasmado con todo lo relativo a las metodologías ágiles. Para los que no estéis familiarizados con el concepto de Agile, las metodologías ágiles se centran en dimensiones como la flexibilidad en la introducción de cambios y nuevos requisitos durante el proyecto, el factor humano, el producto final, la colaboración con el cliente y el desarrollo incremental como formas de asegurar los buenos resultados en proyectos con requisitos muy cambiantes o cuando se exige, como es habitual, reducir los tiempos de desarrollo manteniendo una alta calidad.
Los principios de las metodologías ágiles, tal y como se recogen en el “Manifiesto Ágil” creado en 2001 por la Agile Alliance, son los siguientes:
- La prioridad es satisfacer al cliente mediante tempranas y continuas entregas que le aporte un valor.
- Dar la bienvenida a los cambios. Se recogen los cambios para que el cliente tenga una ventaja competitiva.
- Entregar frecuentemente productos tangibles, que funcionen, desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas.
- Los responsables de negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.
- Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo.
- El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo.
- El producto que funciona es la medida principal de progreso.
- Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante
- La atención continua a la calidad técnica y al buen diseño mejora la agilidad. La simplicidad es esencial.
- Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí mismos.
- En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo, y según esto ajusta su comportamiento.
Aunque Agile y Scrum son términos que se suelen asociar con el desarrollo de software, ya que proceden de este sector, la verdad es que en absoluto se trata de disciplinas o principios exclusivos de este campo. Scrum, por ejemplo, se puede aplicar en cualquier situación en la que existe un equipo de desarrollo, una lista de tareas por hacer y un dueño o responsable del producto final. Y os aseguro que funcionan. Vaya si funcionan. No se trata de una “moda” de gestión, sino de una evolución natural hacia formas más eficientes y agradables de trabajar. Así de simple, así de poderoso.
Por eso me ha encantado encontrarme con esta entrada en el NODOs (no, en serio, aparte de la broma con el noticiario la verdad es que es “El Nodos”, un imprescindible de la blogosfera, y no tendría que recordaros el nombre completo ni su autor), entrada en la que comenta un interesante estudio realizado por un think-tank australiano sobre la aplicación de los principios ágiles al gobierno. El estudio realiza una serie de preguntas diseñadas para ser provocadoras, como por ejemplo cómo pueden conciliar los gobiernos el concepto de agilidad con los procesos inherentemente lentos y pesados bajo los que operan, cómo de preparados están los sectores públicos para adaptárse rápidamente a las circunstancias cambiantes o cuáles son las principales limitaciones de la administración para ser ágil y cómo podrían solucionarse.
El corolario es inmediato: ¿A qué se parece la empresa ágil, el management agil? .
¿Como de ágiles son vuestras empresas?



