Cita

Escrito el 13 de Junio de 2008 a las 10:12 

Cada vez que siento que tengo las cosas bajo control, se qué tengo un problema: no estoy en contacto con la realidad”

Xp2008, Katti Vilkki, Nokia Siemens Networks

Categorías: Citas, Gestión de Proyectos
Tags: ,,,,,,
2 comentarios | Compártelo

Cita

Escrito el 12 de Junio de 2008 a las 20:30 

- Hay quien dice que un buen programador puede aprender cualquier lenguaje en dos semanas y escribir buen código a partir de ahí, y eso no es cierto.
- Bueno, depende… Conozco gente que puede programar C en cualquier lenguaje”

Xp2008, Dave Snowden y Joseph Pelrine

Categorías: Citas
Tags: ,,,,
Deja un comentario | Compártelo

Just say no

Escrito el 12 de Junio de 2008 a las 12:16 

Es un tema con el que choco recurrentemente en los últimos tiempos, posiblemente porque estamos enfrascados en varios proyectos de implementación de Scrum y es algo que, por lo que he visto a lo largo de mi carrera y como confirma la literatura, ocurre constantemente en todas las industrias y en casi todos los equipos: no saben decir que no.

Típicamente comenzamos a diagnosticarlo cuando los gerentes, jefes de proyecto o dueños de producto encargan algún tipo de iniciativa de mejora. Puede ser la adopción de Scrum o la introducción de cualquier otro tipo de práctica o herramienta. El caso es que en muchas ocasiones, pasado el impulso inicial, se va abandonando la iniciativa. Cuando hacemos exploraciones retrospectivas e intentamos ver por qué se ha abandonado, los equipos se quejan: “los jefes nos marcaron otras prioridades“. Y efectivamente, el equipo está sobrecargado de trabajo y no tiene tiempo para mantener una pila de impedimentos, realizar retrospectivas o planificar sus sprints. Pero entonces suelo preguntar: “¿Os han pedido explícitamente que abandonéis estas prácticas?“. Y los equipos suelen reconocer que no, que no ha sido una petición explícita, pero que cuando te piden que atiendas urgentemente algo y que tienes que hacerlo para mañana no pueden hacer otra cosa que atenderla.

Dependiendo de la tolerancia al interrogatorio y la tortura del equipo :twisted: , prosigo con la exploración: “¿Avisásteis al Jefe que si teníais que atender estas tareas urgentes, debíais dejar de hacer el resto de cosas que os pidieron?“. “No…Pero se sobreendiende“. “No, no hace falta porque ya sabemos lo que nos diría“.

Y así, el equipo tiene su parte de culpa en la prolongación del esquema irreal de la carga de trabajo, lo que en Agile se conoce como “la creencia en la magia” (algo ocurrirá que hará que todo encaje en tiempo y presupuesto), simplemente porque no es capaz de decir que no. En algunos casos, pocos, que me haya encontrado, realmente no se le permite a los equipos decir que no, pero en otros muchos se trata de un problema de habilidad de comunicación, negociación y persuasión por parte de los equipos. Al fin y al cabo, predecible y comprensible: nadie se ha tomado su tiempo en enseñar a un programador a negociar, y de todas maneras muchos de ellos ni siquiera llegan a ver la utilidad de algo que no compile :twisted: . Por supuesto, esto no exime de culpa a los jefes que quieren todo hecho para ayer, ya hablaremos otro día de ellos. De hecho, probablemente ellos no han sabido tampoco decirle que no al cliente, al comercial que ha vendido la moto o a su propio jefe que pide las cosas acostumbrado a la “barra libre”.

Y así logramos lo que en Lean Software Development se conoce como Trashing. Es lo mismo que le ocurre a un ordenador por encima del 100% de carga: pasa más tiempo gestionando el intercambio de tareas que realmente ejecutando las tareas, y al final nada funciona. Solo que en el cerebro humano esto ocurre en cuanto superamos más o menos el 80% de capacidad, algo parecido a lo que ocurre en carreteras y autopistas. Al fin y al cabo, cuando hay un atasco o tráfico lento, en realidad cabrían más coches entre coche y coche, ¿No? Efectivamente, no hay que llegar al 100% para provocar un atasco.

Me he encontrado con empresas que tienen listas de 300 implementaciones o mejoras pendientes, cuando su capacidad de producción es de en torno a 3, 4 o 5 historias al mes, lo que significa que tienen una lista de trabajo de seis o siete años (verídico), y eso sin contar conque la lista sigue creciendo y actualizándose constantemente. Todo por no seguir una simple práctica: decir que no. Para aquellos que quieren conservar las peticiones a título informativo o como recurso de lo que al usuario le gustaría, basta con establecer una lista de “Nunca”, como sugería Mary Poppendieck en un seminario al que asistí esta semana.

Al fin y al cabo, cuando Google ofrece a los empleados un 15% de tiempo para asuntos libres y personales, en realidad hace algo de trampa. En realidad, todos dedicamos en torno a una hora al día a desayunar, ir al baño, mandar correitos chorra, leer un blog, chatear por el messenger con un compañero, revisar la cuenta del banco y demás asuntos personales. Una hora al día representa en torno a un 13% de tiempo. Lo único que Google dice es “esta bien, SABEMOS que hacéis estas cosas en jornada laboral y nos parece bien, siempre que el restante 85% lo dediquéis a esta compañía, y lo hagáis al máximo nivel”.

Otra de las cosas que Google hace, como muchos sabéis, es reservar otro 20% de tiempo para proyectos de innovación. Y este tiempo debe ser respetado. El riesgo de esta política es que los equipos se queden más tiempo del que les toca para atender a una demanda siempre creciente de tareas, incapaces de atenderlas todas en el 65% de tiempo que les queda para el desarrollo. Muchas de estas tareas, por cierto, caerán en ese 60% de funcionalidades que, según Standish y según mi experiencia directa y la de todos los desarrolladores con los que he trabajado hasta ahora, se usan rara vez o nunca. YAGNI. Quemar recursos, dinero y tiempo de la empresa y de las personas.

Así pues, dear teams in the way of Agilehood: Just Say No. No a más trabajo del que razonablemente se puede desarrollar. Y os prometo una cosa: cuando los equipos tienen responsabilidad y se les da cierta holgura en la dedicación, la productividad se dispara. Se escribe mejor código, más limpio, con menos errores que atender y corregir en los próximos meses. Hay tiempo para aprender mejores prácticas y nuevas tecnologías. Hay tiempo para refactorizar, implementar arquitecturas mejores, mejores herramientas… Y esto, junto con un equipo motivado por el avance, es el motor del aumento de la productividad en Agile. Implementar únicamente el scrum diario, un tablón y seguir sobrecargando al equipo no llega siquiera a atisbar las mejoras reales que pueden lograrse en una implementación completa de los principios que operan tras Scrum.

Y por hoy ya vale, que me está saliendo un ladrillo considerable.

Actualización: Ofú, meneado… Mejor voy cerrando los comentarios… :-D :-D :-D

Categorías: Gestión, Gestión de Proyectos
Tags: ,,,,,,,,
13 comentarios | Compártelo

Scrumsourcing

Escrito el 22 de Mayo de 2008 a las 15:57 

Me lanza Luís (al que añoro leer más a menudo, pero ando hasta arriba) un guante que recojo encantado esperando que pueda seros de utilidad. Luís describe la típica situación de un cliente que va descubriendo lo que en realidad necesita conforme va avanzando en el proyecto. Es la típica situación que los técnicos describen como “el cliente no sabe lo que quiere” y que los profesionales de Agile, Lean y Scrum describimos como “en un sistema de dimensión compleja, los requisitos son emergentes”. No es culpa del cliente (aunque de todo hay en la viña del Señor): es que no hay otra forma de asegurarse de acertar en el resultado de un proyecto que incrementar los ciclos de feedback cliente-proveedor mediante un desarrollo iterativo e incremental, con entregas de producto funcional y testable al final de cada iteración, algo que va en contra de lo que académicamente se ha postulado durante los últimos treinta años en el mundo de la gestión de proyectos software, que se ha basado típicamente en la aciaga herencia de los desarrollos industriales en cascada.

Hay soluciones basadas en Scrum que funcionan en entornos como el que comenta Luís (os lo aseguro), pero el cliente debe estar dispuesto a un modelo más colaborativo. Me ocurre con frecuencia que, cuando comento a un cliente la posibilidad de que contrate a sus proveedores en un modelo de “fixed time-fixed money” con funcionalidad variable (es decir, contrato al equipo por seis meses y a ver cuánto somos capaz de hacer) me dicen que estoy loco, que entonces el proveedor se dedicará a tocarse las narices todo ese tiempo y que no entregará casi nada al final del proyecto. Pero sin embargo cuando se lo comparo con los contratos de outsourcing o bodyshopping comienzan a verlo más claro: el principio es el mismo, y la forma de controlar el progreso es involucrarse en el mismo de forma diaria.

De hecho, los contratos “fixed time, fixed money, fixed functionality”, es decir, contratos basados en un supuesto conocimiento perfecto del futuro y la evolución del producto a lo largo de meses y meses de trabajo, son una aberración en un mundo de productos complejos como el software y los sistemas, de forma que lo que ocurre en realidad es que el cliente trata de trasnferir todo el riesgo tecnológico y de “mutación” al proveedor, y este se blinda metiendo más colchones que pikolin. Así expresado no parece muy colaborativo, ¿Verdad? Pues por eso no funciona. ;-)

Algunas fórmulas intermedias que suelo recomendar incluyen lo que llamo el contrato de “scrumsourcing”, en el que los objetivos se dividen segun MOSCoW (Must, Ought, Could, Wish) y se firma, por ejemplo, hacer un 100% de los Must, un 80% de los Ought y un 50% de los Could en un tiempo determinado por el proveedor. Cualquier funcionalidad o historia en el que no se haya empezado a trabajar puede ser cambiada en cualquier momento por otra de valor / peso similar. Y en caso de que el cliente esté satisfecho con el nivel alcanzado en cualquier punto del proyecto, o al contratio, piense que el proveedor no avanza al ritmo adecuado, puede cancelar el contrato en cualquier momento por un coste equivalente al 20% de lo que quede por hacer. Así, dividimos el riesgo entre todos.

La típica queja que suelen elevar los proveedores es que un enfoque de este tipo les obliga a diseñar el sistema de una forma altamente modular y flexible para soportar los cambios de funcionalidades futuras. Típicamente lo expresan como “no se puede”, pero el caso es que miles de empresas de todo el mundo trabajan así, o sea que se puede, pero requiere un esfuerzo y una disciplina. Y por otra parte, ¿no es más valioso para el cliente contar con una arquitectura modular y flexible que permita incorporar cambios y nuevas funcionalidades en el futuro? ¿No es incluso mejor para el proveedor, de cara a la recurrencia del cliente?

En este tipo de enfoques, lo ideal es comenzar contratando a proveedores para proyectos de bajo riesgo y corta duración, seleccionando a los que mejor funcionan para proyectos a mayor duración y con un impacto mayor en la compañía. Esto tiene dos ventajas: por una parte, como comentaba, podemos seleccionar a los proveedores que funcionan bien con un modelo ágil. Y por otro podemos comenzar a acostumbrarnos al proceso con proyectos de bajo riesgo e ir perfeccionando los mecanismos de control, visibilidad y feedback.

Que por cierto, para este tipo de cosas hay una consultoría que… O:-)

Categorías: Gestión, Gestión de Proyectos
Tags: ,,,,,
8 comentarios | Compártelo

Pair PowerPointing

Escrito el 27 de Abril de 2008 a las 10:44 

Hace unos días estuve preparando una presentación para el kick-off de un proyecto en el que colaboro con otra empresa. Faltaban tres horas para la reunión y aun no había terminado, así que el jefe de proyecto de esta empresa y yo nos sentamos ante el portatil y le dimos los toques finales a la presentación entre los dos.

Pues bien, no solo produjimos la que a mi juicio es una de las mejores presentaciones que he realizado hasta la fecha, sino que ambos aprendimos varias cosas sobre cómo realizar un power-point. Hoy mismo estoy haciendo otro y me he sorprendido utilizando intensivamente un par de herramientas y consejos que hasta ahora no había tenido en cuenta.

Al fin y al cabo, lo que estuvimos haciendo es el equivalente a la práctica de programación por parejas que describe XP (programación extrema) y, efectivamente, lejos de ser un desperdicio por tener a dos personas haciendo lo que en teoría podría hacer una, la inversión en calidad que supone tener cuatro ojos y dos cerebros revisando lo que se hace realmente paga cuando se revisa la visión global del proyecto. Item mas: el nivel de conocimiento del equipo aumenta drásticamente, ya que se produce una transferencia de mejores prácticas de forma natural.

A los que todavía no hayáis introducido prácticas de pair programming en vuestros equipos ágiles, os animo realmente a que empecéis a hacer algún experimento, porque estoy seguro de que si lo implementáis correctamente los resultados os van a sorprender mucho más allá de lo que pensáis.

actualización: me doy cuenta de que todavía no he referenciado en el sitio las estupendas “death by powerpoint” y “how to: visual effects in power-point”.

SlideShare | View | Upload your own
SlideShare | View | Upload your own
Categorías: Gestión del Tiempo
Tags: ,,,,
13 comentarios | Compártelo

Orcos a las puertas

Escrito el 19 de Abril de 2008 a las 10:52 

Reflexionaba esta semana, junto con los jefes de proyecto de una de las empresas con las que estamos trabajando actualmente, respecto al problema histórico de comunicación entre las áreas de negocio y las áreas técnicas, tantas veces reflejadas, por ejemplo, en los chistes de Dilbert. Es un problema comprensible: las motivaciones muchas veces están enfrentadas (el área de negocio quiere más cosas en menos tiempo, el área de sistemas quiere más tiempo para dedicar a menos cosas) e incluso los lenguajes y el bagaje personal y profesional son tan difererentes que lo raro es que surja una buena comunicación.

Scrum, como sabéis, establece un artefacto (la pila de producto) que permite a la gente de negocio (Dueños de Producto) manejar a la gente técnica (Scrum Master y equipo). Sin embargo, uno de los problemas típicos que nos encontramos en las implantaciones de Scrum en las que trabajamos es el de involucrar a la gente de negocio en el proceso. La implantación de Scrum suele surgir por iniciativa de los técnicos, cosa rara si pensamos que la gente de negocio debería tener una formación y un foco más “humanista” y deberían haber sido los primeros que planteasen formas de colaborar y comunicarse con las áreas de producción (notese el matiz respecto a “áreas productivas”, que esas deberían ser todas, negocio y sistemas).

Al surgir desde el área técnica, las áreas de negocio tienden a veces a considerarlo “cosas de frikis” y pasar muy mucho del tema. Por eso nuestro enfoque de implantación conlleva muchas acciones dirigidas a las áreas de negocio. El objetivo final es que las áreas de negocio nombren un determinado número de Dueños de Producto que sean los que canalizacen y prioricen las peticiones de todos los interesados, clarificando al equipo lo que deben hacer en cada momento. Con eso evitamos también el bombardeo de peticiones “no oficiales” a las que típicamente se ven sometidos los equipos de desarrollo, peticiones cuya prioridad no está clara y que la mayor parte de las veces ni cuentan con una justificación de negocio sólida ni computan luego en la productividad del equipo, ya que se hacen “de tapadillo”.

Lamentablemente, el enfoque de envagelización y colaboración no siempre funciona, y los equipos de desarrollo se enfrentan a peticiones y negociaciones que les llueven por todas partes. Es como enfrentarse a un enemigo muy superior en número y recursos. ¿Y qué podemos hacer en una situación así?

Reflexionabamos sobre esto, como os decía, y tratando de explicar el enfoque que nosotros proponemos como siguiente nivel de presión hacia el cambio corporativo se me ocurrió la metáfora de los “orcos a las puertas”: La batalla del abismo de Helm.

Abismo de Helm

En la batalla del abismo de helm, los humanos se parapetan en un fortaleza que cuenta con un único punto de acceso: un estrecho puente que obliga a los miles de orcos que los asedian a formar casi de uno en uno, con lo que en las puertas de la fortaleza se monta lo que los KODT llaman una “conga de la muerte”, una estrategia perfecta para lidiar con un enemigo muy superior en número y que ya fue utilizada por los 300 espartanos en el paso de las termópilas.

¿En qué consistiría la estrategia “orcos a las puertas”? En primer lugar, en blindar el área de sistemas. Kniberg lo describe muy bien en su libro. Esto se puede hacer a un nivel organizativo o discilplinario, aleccionando a todo el mundo para que no atiendan peticiones de ningún tipo que no vengan del Dueño de Producto de Sistemas, o incluso físicamente, co-alocando a todo el equipo y dejando pocas vías por las que los extraños puedan acceder y pulular. Incluso sentar al Dueño de Producto de Sistemas al lado de la puerta para que actue como guardián del área.

El segundo paso es precisamente ese: nombrar a un Dueño de Producto de Sistemas encargado de lidiar con los orc…Digooo…Con la gente de negocio. Nada fácil, os lo aseguro. En la mayoría de los casos una estraegia pasivo-agresiva como esta suele acabar en el despacho del CEO, pero a veces es precisamente esto lo que hace falta. Por eso es también muy importante preparar documentación sobre todos los intentos previos que se hayan hecho para que el área de negocio asuma la responsabilidad y la competencia que le toca sobre la definición y priorización de los proyectos. Eso nos permitirá justificar el movimiento defensivo.

A veces lo que ocurre es que el área de negocio está encantada con tener un interlocutor único en sistemas, y la estrategia “orcos a las puertas” se convierte en una mejor práctica corporativa. Pues estupendo. De hecho, no se vive tan mal en el abismo de Helm, siempre que uno tenga un puesto calentito, dos buenas pantallas TFT y unas cuantas herramientas de desarrollo… ;-)

Categorías: Gestión de Proyectos
Tags: ,,,,,,,,
2 comentarios | Compártelo

Cosas curiosas que llevar en la mochila (The Agile Coach Toolkit)

Escrito el 15 de Abril de 2008 a las 20:12 

Podéis considerarlo un meme si queréis, me encantaría cotillear en vuestras mochilas ;-)

Ah, sí… Y el portatil con su cargador, claro… ¿Que si pesa? Como un palet de ladrillos, la condenada… :-D

Categorías: Gestión de Proyectos
Tags: ,,,,,
7 comentarios | Compártelo

Varias novedades

Escrito el 2 de Abril de 2008 a las 11:41 

Y aquí seguimos para Bingo. La creación de la SL, la oficina, el proceso de selección que tengo en marcha, varios proyectos, viajes… He tenido que utilizar el enfoque de Agile cuando los proyectos comienzan a salirse de madre por la introducción de nuevos requerimientos, cambios e incertidumbre y he optado por renegociar el scope… Jejeje… Que friki que soy :twisted:

En cristiano: que he empezado a centrar, priorizar y abandonar aquellas labores que menos me aportan. Y en la criba se ha caido mi colaboración con El Blog Salmón. Ohhh…Lazzztima. Justo ahora que se incorporaba Enrique era un buen momento, aunque sinceramente me hubiera apetecido trabajar con él una temporadita, aunque fuese en “asíncrono”. ;-)

Alguna novedad más: me he apuntado a XP 2008. Dado que cada vez tengo más porcentaje de negocio ligado a Agile, Scrum, Lean y todo el mundillo de los nuevos enfoques estratégicos y productivos en la industria del software, creo que es una buena oportunidad para pulsar un poco lo que se está haciendo en otros países y por donde tira el mercado. Por cierto, ni un ponente Español en el evento, ¡shame on us! Si alguien se está planteando asistir, que se ponga en contacto conmigo y haremos lobby ;-)

Más cositas: me planteo asistir al Iniciador de la semana que viene, pero coincide con la feria de Sevilla y no se qué tal andarán los AVE’s. Tengo una entrevista pendiente con una empresa de Madrid y podría aprovechar para hacer seguimiento de un par de oportunidades que tengo languideciendo por allí… No se, no se. Tomaré la decisión en el último momento responsable (¿se nota que estoy repasando Lean? ;-) )

Por lo demás, uno de los objetivos en la purga de labores que he hecho es dedicarme un poco más al blog, ya que los últimos artículos han despertado bastante interés, pero la frecuencia de publicación está sufriendo demasiado. Espero que sigáis atentos los próximos días, que tengo un montón de temas pendientes ;-)

Nos leemos…

Categorías: General
Tags: ,,,,,,,
6 comentarios | Compártelo

Testing

Escrito el 18 de Marzo de 2008 a las 13:40 


MWAA-HAHAHA!! ROTFLASTC!! :-D :-D :-D :-D

Vía Sebastian Bergmann, encontrado en Flickr buscando “Agile Software Development”.

Categorías: Gestión de Proyectos
Tags: ,,,,,,,
Deja un comentario | Compártelo

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

Categorías: Gestión de Proyectos
Tags: ,,,,,
3 comentarios | Compártelo

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

Categorías: Formación, Gestión de Proyectos
Tags: ,,,,
Deja un comentario | Compártelo

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 fenomenal

Bien, 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.

Categorías: Gestión de Proyectos
Tags: ,,,,
Deja un comentario | Compártelo

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.

Categorías: Gestión, Gestión de Proyectos
Tags: ,,,
3 comentarios | Compártelo

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

Categorías: Blogs, Gestión de Proyectos
Tags: ,
1 comentario | Compártelo

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. :twisted:

Categorías: Blogs, Emprendedores, Eventos, Gestión de Proyectos
Tags: ,,,
10 comentarios | Compártelo

Más antiguos →

Buscar:

Suscriptores:

Tags

Que se dice por aquí:

Qué se dice por ahí:

Twitter


Fotos

www.flickr.com
angel.medinilla fotos