• Inicio
• Acerca de
• BlogLog
• Te invito a un café
• RSS
• Mi empresa

Charla “proyectos Ágiles” en Vitoria

Escrito el 19 de Febrero de 2010 a las 13:56 

Ayer tuve el privilegio de poder hablar un rato sobre la gestión Ágil de proyectos como parte de las charlas sobre innovación pública que está organizando el Gobierno Vasco, con el impulso de los incombustibles Alberto Ortiz de Zárate(@alorza) e Iñaki Ortiz, responsables de Atención al Ciudadano y Modernización de la Administración respectivamente y promotores desde hace tiempo del blog Administraciones en Red . El video lo podéis ver en Irekia, y la presentación que usé la tenéis en Slideshare:

Actualización: Wala! Si se puede incrustar el video de Irekia!

Montañas en la tierra media

Escrito el 4 de Febrero de 2010 a las 11:20 

Es descorazonadora la cantidad de gente que viene a mis cursos o charlas con hambre en los ojos, con necesidad de cambiar las cosas, angustiados, presionados, sobreviviendo en entornos corporativos agresivos, corruptos y desmoralizadores. Pero es igualmente descorazonador que mucha de esta gente, cuando se les presentan las raices y principios en los que se basan sus males y las herramientas y líneas de acción encaminadas a reducirlos o eliminarlos, responden sistemáticamente con el “Yapero”.

“Ya, pero es que nuestros proveedores nos engañan”. Pues controla a tus proveedores. O mejor, cambia de proveedores. “Ya, pero es que todo el mundo hace lo mismo”. No, todo el mundo no. Y si todo el mundo hace lo mismo, tendrás que cambiar el mundo. “Ya, pero es que no nos dejan cambiar de proveedores”. Insisto: cambia la forma en que trabajan tus proveedores. “Ya, pero es que no quieren”…

Lo gracioso es que luego vas a trabajar con esos mismos proveedores y se repite la historia. “Ya, pero es que el cliente nos cierra alcances, tiempos y dinero”. Pues diseña y gestiona buffers de proyecto. “Ya, pero es que ni con buffers cuadra el proyecto”. Pues entonces estás perdiendo dinero y no deberías coger ese proyecto. “Ya, pero es que si cogemos este proyecto, aunque perdamos, luego podemos coger otros más jugosos”. No creo que comenzar una relación de negocios con abusos de poder y pérdidas económicas establezca un buen precedente. “Ya, pero es que si no lo coge la competencia”. Si la competencia pierde dinero, mejor para tí. “Ya, pero es que entonces nosotros nos quedamos sin clientes”. Hay millones de empresas en todo el mundo. Sal de tu terruño y búscate la vida. “Ya, pero es que para eso hay que saber inglés”. Aprende inglés. “Ya, pero…”

Ya hablé de esto con la parábola del mago del método. Y ahí estamos todos. Con picos y palas a nuestro alcance, quejándonos toda la vida de la montaña que se alza en la tierra media entre clientes y proveedores. Pero nadie mueve un dedo. Nadie pica la montaña. Nadie se pone a cavar un tunel. Nadie.

O casi.

Equipos o cirujanos

Escrito el 25 de Noviembre de 2009 a las 11:16 

Me encuentro ultimamente con algunas organizaciones que han ido creciendo desde equipos pequeños de personas y, conforme han ido añadiendo miembros al área de desarrollo, han ido evolucionando hacia un modelo de un proyecto - una persona. Se trata (espero) de una adaptación del “paradigma del cirujano estrella” publicado por IBM en los 60-70, en el marco del desarrollo de OS360 (¿alguien ha leido The Mythical Man Month? ). Según este modelo, los proyectos más productivos que IBM había detectado eran aquellos en los que existía un “cirujano estrella” que tenía en su mente la arquitectura y el diseño y realizaba toda la programación rodeado por un equipo de ayudantes (documentadores, testers, administradores…). Según las mediciones de IBM, un programador estrella aportaba 10 veces la productividad de un programador medio. Pilar Jericó, en “Gestión del Talento” (citada por Juan Palacio en su libro, si no recuerdo mal) va más lejos y afirma que en el mundo tecnológico los mejores lo hacen entre 50 y 100 veces mejor que la media, y la cifra aumenta conforme la tecnología se hace más compleja.

Monos y máquinas de escribir, vaya. Quien no se crea estas cifras, que meta a 100 programadores promedio en una sala y a Alan Cox en la otra, y a ver quién termina antes con la pila TCP-IP del núcleo de Linux .

Pero antes de que despidáis a toda vuestra plantilla de programadores promedio (a mi entre ellos, jejejeje) y salgais al mercado a buscar programadores estrella, preguntaos por qué el modelo fue abandonado.

Even though, que dicen los ingleses: suponiendo que el modelo sea válido en todos los casos, el problema es que lo que me suelo encontrar en las empresas con las que trabajo son programadores my buenos, estupendos, con talento… Pero seamos francos y humildes: no somos Alan Cox .

Así que ya tenemos el primer problema de este modelo: encontrar a estas “estrellas” que hacen de todo, que son capaces de enfrentarse a todo tipo de proyectos y productos. Y pagarles. Y fidelizarles. Y que no se conviertan en “Prima Donnas” tecnológicas a la primera de cambio.

Pero incluso obviando el tema de las estrellas, el enfoque de un proyecto - una persona (a veces en relación muchos a uno, jejeje) tiene una serie de problemas considerables, que es por lo que en Agile consideramos los equipos como los bloques de construcción básicos de proyectos, procesos y empresas. Y ojo, que un conjunto de personas que se sientan juntas no es lo mismo que un equipo. Un equipo es una forma de pensar ante todo, y el espacio que comparten no puede ser únicamente físico.

A lo que ibamos, que parezco una abuela divagando. Problemas del enfoque de un proyecto - una persona:

• Escalabilidad: el modelo funciona cuando tenemos cinco o seis personas, puesto que, para ver el estado del portfolio de proyectos, no tengo más que hacer una ronda por estas personas y que me cuenten como va todo. Es el Scrum Diario de Scrum o el stand up meeting de XP. Pero cuando la empresa empieza a ir bien y a crecer el modelo no tarda en colapsarse. Cuarenta personas, todas contándonos el estado de su proyecto (o sus proyectos) todos los días, o todas las semanas… Imposible. No hay más remedio que multiplexar. Cinco grupos de ocho personas, y un responsable por cada equipo. Con eso puedo volver a mis rondas diarias con cinco personas que me resumen el estado de todo. Mejor. Cada proyecto sigue asignado a una persona concreta (por ahora), pero hemos resuelto el problema de la escalabilidad… Formando grupos de personas (aun no equipos).
• Robustez: ok, tengo ya grupos de personas, pero de repente se va Paquito, y hay que traspasar sus proyectos. Como es el único que los conoce, estos proyectos van a sufrir considerablemente. Y lo que es peor: el año que viene nos piden que repasemos algunos proyectos de Paquito y nadie sabe nada de ellos. Relexionamos: en el futuro sería interesante que tuvieramos estándares de como hacer las cosas y documentásemos bien los proyectos para que podamos solucionar estas situaciones de una forma mejor. Pero el problema es que por mucho que le decimos a la gente que documente, como siempre vamos hasta arriba, al final siempre se queda la documentación por hacer. Quizás si las personas estuvieran un poco más al tanto de lo que hacen sus compañeros… Pero es muy dificil, muy dificil. Seguimos haciendo las cosas como siempre y obteniendo los mismos resultados.
• Flujo de conocimiento: cuando alguien comete un error, típicamente lo tapa, lo corrige y listo. Mañana otra persona, en la otra punta de la oficina, cometerá el mismo error. Y pasado otra. Y cada uno da soluciones diferentes. Por otra parte, un día alguien encuentra una solución ingeniosa a una necesidad habitual de los proyectos. Pero nadie se entera. Entonces reflexionamos y decimos que hay que montar un sistema de gestión del conocimiento, y desarrollamos una intranet, un blog, un wiki… Pero nadie los usa. Si hubiera una forma de que las personas se contasen unas a otras sus problemas y soluciones, y que unos revisasen el trabajo de otros… Bah, muy dificil.
• Duplicación: al igual que ocurre con los errores, los desarrollos comienzan a duplicarse. Un día nos encontramos con que dos personas, en dos esquinas de la oficina, han desarrollado dos librerías idénticas para el mismo problema. Vaya por Diox. Si hubiera una forma de sincronizar a todo el mundo…
• Incorporaciones: cuando reclutamos a juniors, sería interesante que pudieran ir aprendiendo de los seniors. Pero los seniors están muy liados con sus proyectos como para andar enseñando a la gente. Sí, ya dijimos antes que deberíamos tener estándares de códificación, sistemas de gestión de conocimiento… Pero no se hacen. Si pudieramos organizar a la gente en equipos, equipos de verdad, no solo grupos de personas, que se sincronicen a diario, compartan tareas y proyectos, programen por parejas de vez en cuando, hagan retrospectivas de grupo frecuentemente, analicen todos los proyectos juntos, distribuyan la carga según ellos mismos convengan… Así sería mas rápido y sencillo que una persona recién incorporada fuera pillando el ritmo y el estilo del equipo.
• Flexibilidad: si una persona está muy cargada y queremos reforzar su proyecto con más personas, significa que esas personas deben coger el proyecto desde el principio y adaptarse al enfoque que el primero ha dado al desarrollo. Si de alguna forma se hubieran hecho revisiones breves del proyecto desde el principio en equipo, no solo se habría podido ir incorporando el feedback de todo el mundo al enfoque del proyecto (¿Crowdsourcing anyone? ), sino que sería más fácil incorporarse al proyecto.
• Estandarización: antes hemos dicho que sería bueno contar con estándares para facilitar el trabajo en equipos, pero los estándares son buenos per se, no solo como herramienta. Permiten, como hemos visto, que las personas que se incorporan se adapten más rápidamente y nos permiten analizar de una forma coherente y estándar el rendimiento de los procedimientos para buscar las mejores soluciones y difundirlas entre los equipos.
• Tribus: asumidlo, los seres humanos somos tribales. Los que no lo eran se extinguieron en la última edad de hielo, muertos de hambre o devorados por los tigres dientes de sable, es una cuestión puramente evolutiva. Y a todos nos gusta pertenecer a una tribu, no ser guerreros cubiculares aislados, por muy romántica que nos parezca la idea del “justiciero solitario”. El problema es que cuando formamos una tribu, lo primero que buscamos es otra tribu a la que declarar la guerra. Y si nuestra tribu es “desarrollo”, le declararemos la guerra a “QA”, a “Infraestructura”, a “Diseño”… Es mejor crear la “tribu equipo”, donde todos colaboramos para sacar adelante los proyectos. E independienteemente de si nuestros equipos son multidisciplinares o no, el pertenecer a una tribu aumenta la motivación, la la motivación aumenta la productividad (quien no crea firmemente en esto debería de reflexionar largo y tendido sobre temas más fundamentales que equipos si / equipos no)

Y se me ocurren varias más, pero entonces este artículo se haría insufrible. ¿Como lo véis vosotros?

PMBOK 4 - Con extra Agile!

Escrito el 30 de Marzo de 2009 a las 8:44 

Me entero con algo de retraso del alumbramiento de la cuarta versión del PMBOK: el estándar en gestión de proyectos del Instituo Internacional de Gestión de Proyectos y posiblemente la obra de referencia en esto del project management. Malas noticias para los que estáis preparando ahora mismo el PMP, nenes…

Lo más llamativo de esta nueva versión es que, a pesar de que conceptos como el Rolling Wave Planning que defienden la planificación en detalle de los eventos cercanos y una planificación más difusa de los bloques de trabajo a largo plazo ya estaban presentes en ediciones anteriores del PMBOK, en esta edición se introduce un especial énfasis en la planificación iterativa de proyectos. Kudoz for Agile Teams.

Hay algunos otros cambios, como una mayor profundidad en el concepto de la documentación de proyecto, mayor consistencia con los estándares de gestión de programas y portfolios de proyectos… Espero poder estudiarlos con más detalle en cuanto encuentre la forma de descargarlo, porque está accesible para miembros del PMI pero a través de un odioso applet que pega un casque bastante feo cuando intento imprimirlo en PDF… En fin, tocará pasar por caja…

Los resultados de un curso - hablan los clientes

Escrito el 10 de Febrero de 2009 a las 10:05 

Herme se autodefinía como informático vocacional (a pesar de ser “teleco”), que defiende el aspecto artístico (yo prefiero decir artesanal) de nuestra profesión. Y efectivamente, se le ilumina la cara cuando me explica algunos problemas que durante estos años le han surgido y que quedan lejos del típico CRUD (”altas, bajas, modificaciones y listados”) al que desgraciadamente solemos empujar a los usuarios de nuestras aplicaciones. También me comentó cómo después de asistir al curso de Scrum que impartió Ángel Medinilla en Barcelona, dieron la vuelta “como un calcetín” a un proyecto y consiguieron que fuera todo un éxito. Escucharon a los usuarios y se dieron cuenta de que el enfoque “ingenieril” era inadecuado. Escucharon a los usuarios y consiguieron enfocarse hacia el éxito del proyecto.”

Vía el blog de JM Beas.

Encuesta a los lectores

Escrito el 20 de Diciembre de 2007 a las 12:25 

La pregunta es:

Si en vuestra empresa contratasen a Proyectalis, ¿Para qué pensais que sería? “

Venga, hay casi 500 suscritos al blog, no me seais perros y contadme algo en los comentarios. Prometo análisis y conclusiones

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…

Responsabilidad Social Corporativa

Escrito el 3 de Diciembre de 2007 a las 19:25 

Micropost: La junta directiva de Proyectalis en pleno, con su Consejera Delegada Ejecutiva al frente, ha decicido donar un 1% de la facturación del año a una ONG o proyecto que merezca nuestra aprobación y solidaridad (no os emocionéis, que son cuatro duros, pero si nosotros podemos con el 1% el estado ya debería poder con el 0,7%, digo yo, más ahora que hay superavit). Hemos estado a un trís de optar por Intermón Oxfam, ya que hasta antes de ayer estabamos muy por la labor del comercio justo y la cooperación para el desarrollo, pero la lectura de El Economista Camuflado ha cambiado ligeramente mi visión al respecto (lo justo para que por lo menos indague y me documente antes de apoyarlo) . Ya colaboramos personalmente con Médicos sin Fronteras, y ando barruntando que a la raza humana le está bien empleado lo que le pasa y que quizás debería tender hacia la causa ecologista, pero sinceramente no los veo muy centrados ultimamente. Así que andamos algo perdidos. Como esto siga así, lo invertimos en árboles y ya veremos dónde los plantamos. Sugerencias bienvenidas. Religiones abstenerse.

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:

1. 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.
2. 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.
3. 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).
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.
9. 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”.
10. 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”.
11. 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.
12. 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.
13. 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.

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

Bienvenido



Presión Blogosférica es un blog en el que almaceno mis reflexiones sobre negocios, empresas, emprendedores, gestión de proyectos, Internet... Pero también es un espacio plural en el que discutir sobre dichas ideas. Puedes dejar un comentario o contactar conmigo en angel.medinilla (arroba) presionblogosferica.net. También puedes seguir el blog a través de su Feed RSS

¿Un café?






• Artículos recientes

  • Semana de formación Madrid 2012
  • Llenando el día
  • LeanCamp Barcelona
  • Felicitación Navideña
  • Jornada para Business Angels
  • Uno por ciento
  • De vuelta por mis fueros…
  • Presentaciones XP2011
  • Recursos del curso de Coaching de Equipos Ágiles
  • El Rol de Scrum Master / lider de equipo

• Categorías

  • Eventos
  • General
  • Gestión
    • Citas
    • Creatividad
    • Gestión de Proyectos
    • Gestión del Tiempo
    • Marketing
  • Internet
    • Blogs
    • Herramientas
  • Negocios y empresas
    • Emprendedores
    • Formación
    • Ideas de negocio
    • Libros

• Archivos

  • Marzo 2012
  • Febrero 2012
  • Enero 2012
  • Diciembre 2011
  • Octubre 2011
  • Mayo 2011
  • Abril 2011
  • Marzo 2011
  • Febrero 2011
  • Noviembre 2010
  • Octubre 2010
  • Septiembre 2010
  • Agosto 2010
  • Mayo 2010
  • Abril 2010
  • Marzo 2010
  • Febrero 2010
  • Enero 2010
  • Diciembre 2009
  • Noviembre 2009
  • Octubre 2009
  • Septiembre 2009
  • Agosto 2009
  • Julio 2009
  • Junio 2009
  • Mayo 2009
  • Abril 2009
  • Marzo 2009
  • Febrero 2009
  • Enero 2009
  • Diciembre 2008
  • Noviembre 2008
  • Octubre 2008
  • Septiembre 2008
  • Agosto 2008
  • Julio 2008
  • Junio 2008
  • Mayo 2008
  • Abril 2008
  • Marzo 2008
  • Febrero 2008
  • Enero 2008
  • Diciembre 2007
  • Noviembre 2007
  • Octubre 2007
  • Septiembre 2007
  • Agosto 2007
  • Julio 2007
  • Junio 2007
  • Mayo 2007
  • Abril 2007
  • Marzo 2007
  • Febrero 2007
  • Enero 2007
  • Diciembre 2006
  • Noviembre 2006
  • Octubre 2006
  • Septiembre 2006
  • Agosto 2006

• Blogroll

  • Desencadenado
  • Diario de un director de TI
  • Externalidades
  • Think in Blog
  • Tik&Tak
  • Vida de un Consultor

Buscar:

Suscriptores:

Kisei Dojo Aikido

Pastafari!

Tags

2.0 3G actitud Agile Agile Management agile spain apple autentia autonomos bancos barcelona Biko2 blog Blogs burocracia business angel C++ calidad cambio CEIN charla charlas clientes coaching colaboración comentarios comunicación conciliación conferencia congreso consejos consultoras consultores consultoría contactos contratos contratos ágiles control corporate culture costes Creatividad crecimiento crisis crédito CSM cultura cultura corporativa curriculum curso curso de scrum curso madrid cursos curso scrum diversión dueño de producto EBE07 economía einstein ejercicios empleados empleo Emprendedores empresa empresarios empresas encuesta equipos España estrategia estudiantes Eventos exito externalización facturas feedback financiación finanzas flickr ford Formación fracaso funcionarios funky business fábulas gente GMail Google GTD horarios ideas impuestos inglés Iniciador innovación IT iweekend jefe de proyecto Jeff sutherland jornada laboral kaizen Kanban karma lean Libros liderazgo Linus Linux liquidez Madrid Marketing Matrix mejora mercado mercado laboral mercados metodologías microsoft mision mochila motivación muebles málaga navidad negociación negocio networking oferta ofertas oficina oficinas ONG Open Space outsourcing pagos pamplona pareto paro perseverancia personal personas plan de negocio planificación estratégica PMBOK PMI PMP power point precios presentaciones presentación proactividad problemas productividad producto programación programadores project management proveedores proyectalis proyectos pruebas rendimiento rentabilidad retrospectivas riesgo salarios scrum scrumban Scrum Master selección sevilla silicon valley sistemas SL Slideshare social software start-up startup subvenciones tecnología teletrabajo tests TI tiempo tim ferris toyota transparencia twitter usuarios VC ventas venture capital viajes video videos vision wii xp xp2008 zona de confort

Que se dice por aquí:

• Francisco Jofre: Me parece una excelente fabula. Coincido con Borja Prieto, en que no hay nada de malo en...
• Antonio de las Nieves: Joder Sergio, vaya anécdota. Casi más que estuvieras de ruta en un camión de aceite.. Muy...
• Chidiac Entrepreneur: If you desire to increase your knowledge simply keep visiting this site and be updated with the...
• Sonia: Disculpad mi ignorancia (estoy aprendiendo poco a poco), cuando dije metodologías tradicionales estaba...
• Sonia: Buenas tardes Ángel, he visto en on-line tu curso “Contratos ágiles: Vendiendo Scrum a tus...

Qué se dice por ahí:

• april 2nd: april 2nd...
• La Pastilla Roja: Devops
• Jefe de Proyectos: Funciones del Jefe de Proyectos (II)
• Muñoz, Consultor SEO: Lo mejor de los feeds
• El Canasto: Te invito a una cerveza...

Twitter

Fotos

www.flickr.com Más fotos de angel.medinilla

• del.icio.us
• Digg
• Google Bookmarks
• Yahoo! My Web
• Technorati
• Barrapunto
• Meneame
• Fresqui
• Favoriting
• BlogMemes
• Chido
• Webeame
• Blinklist
• Neodiario
• Enchilame
• Mr. Wong