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
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
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 
, 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 . 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… 
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:-)
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”.
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.
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…
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
- Una barra de limpiador de gafas, muy util cuando uno se confunde y pinta con rotulador indeleble en una pizarra velleda (por cierto, ¿¿¿no os da mil patadas que la gente las llame pizarras villeda??? )
- Una navajita mulitusos (deshauciada desde que empecé a coger más aviones)
- Cuaderno tamaño cuartilla
- Post-its… Lot’sa post-its
- Rotuladores, en sus variedades: marcador fluorescente, edding de escribir post-its, edding indeleble para papelógrafos, ikea para velledas (punta fina) y bic para velleda (punta gruesa)
- Papel celo y blu-tac (moco/chicle adhesivo, vaya)
- Kleenex
- Cámara de fotos digital
- Reproductos MP3 cargado de audiolibros y algunas canciones de las de conducir (niños, no lo hagáis en casa ).
- Ocasionalmente, un proyector LG y un trípode de cámara digital
- Un limpiador de pantalla de portatil (pequeño artefacto con un borde de gamuza retractil)
- Marcapáginas adhesivos (utiles para realizar votaciones en ausencia de sticky dots)
- Montones de tarjetas de visita, profesionales y del blog
- Una mini-linterna de leds
- Un peine… Lo siento, pero a veces va uno con la moto a ver a un cliente y si no se atusa un poco al quitarse el casco parece el primo treintañero del neng de castefa
- Ocasionalmente, latas de caramelos del LIDL
Ah, sí… Y el portatil con su cargador, claro… ¿Que si pesa? Como un palet de ladrillos, la condenada…
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
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…
Testing
Escrito el 18 de Marzo de 2008 a las 13:40
MWAA-HAHAHA!! ROTFLASTC!!
Vía Sebastian Bergmann, encontrado en Flickr buscando “Agile Software Development”.
FUD
Escrito el 17 de Febrero de 2008 a las 23:33
Aunque son las mil de la noche (a mi todo lo que pase de las diez me parece madrugada) me voy a obligar a escribir aunque sea un par de líneas, que tengo esto abandonaico… Como viene siendo habitual de estas páginas, cuando no publico muy a menudo es que me he vuelto a meter en berenjenales, cosa buena por otra parte ya que significa crecimiento, que es el lema de este año. De hecho el Martes tengo un AVE, a ver si saco un rato para contaros como va todo (va bene, va bene).
A lo que iba: tuve la idea hace unas semanas de registrar la marca “Proyectalis” por lo que pudiera pasar en el futuro. Ya tuve la precaución de solicitar al registro mercantil central el certificado de denominación negativa para cuando me diese por montar la SL, cosa que creo que ha merecido la pena, así que este también era un paso lógico (además me dió la idea Javi, de Loogic, un día por el twitter…Para que luego digan que no sirve para nada).
Así que entré en la página web de la Oficina Española de Patentes y Marcas con IE (ya que con Firefox casi todo lo que hace la administración acaba petando, mire usted que cosas, ya les vale con tanta accesibilidad, tanto apoyo al software libre y tanta gaita), me pelee un rato con los formularios de rigor, pegué un visazo de unos 120 euros más o menos y tralará, a esperar no se cuantos meses a que te digan si vale o no vale el registro (musica de pasodoble suena de fondo: “Que viiiiva, Ep-pañaaaa…”. Por si alguien no conoce mi otra cuita con la e-administración, que lea El Blog Salmón).
A lo que voy (hoy estoy disperso, parece que haya pasado por un barato de paréntesis). Que el caso es que al mes empiezan a llegar a mi casa una serie de cartas de empresas que, por el módico precio de diez veces la citada cantidad (es lo que le pidieron a un amigo mío, lo juro) se ofrecen a desarrollar todas las gestiones posteriores de “seguimiento” de la solicitud. Porque una vez que la solicitud aparece en el correspondiente boletín (al que todas estas empresas están lógica y convenientemente suscritas) podía ocurrir que alguien objetase contra el registro, en cuyo caso habría que realizar un seguimiento personalizado del caso y no se qué historias más.
Entre estas cartas las hay muy educadas y profesionales, pero hay una preocupante porción que recurren a la nada sutil amenaza, y con mayúsculas ademas: EL SEGUIMIENTO DE ESTAS ACCIONES DEBE LLEVARSE A CABO POR UN PROFESIONAL CUALIFICADO, y cosas de ese estilo. En plan “se te va a caer el pelito por listo”. que ya me explicarán a mi la cualificación necesaria y dónde se estudia, pero en fin, entiendo que la cosa puede llegar a tener su miga y su ciencia.
Me ha recordado a los tiempos en los que en las tecnológicas imperaba la política comercial del FUD: miedo, incertidumbre y duda. IBM fue, según la Santa Wikipedia, abanderada de esta política en sus tiempos, ya ves lo que son las cosas, con lo que apoyan ahora el software libre con tal de vender más máquinas y apreciar un poco sus servicios profesionales siendo precisamente el software libre uno de los principales objetos de FUD hoy en día. Incertidumbre al enfrentarse a productos tecnológicamente complejos. Miedo de (digamoslo llanamente) cagarla al contratar un servicio por el que nadie ha apostado antes o que no es “el estándar” (de allí la famosa frase “a nadie le despiden por comprar un IBM“). Dudas sobre las capacidades de unos u otros.
Y cuando al conejo le alumbran los faros del camión, no salta ni a un lado ni a otro. Se queda pasmado en medio de la carretera. Telefónica sabe bien eso: durante un tiempo creó tal marasmo de “planes claros” que los consumidores ya no sabían si les merecía más la pena pillarse un plan tercera edad, un plan estudiantes, un plan telepizza o un plan con plan. Y se quedaban como estaban, que al final es de lo que se trata.
Pues lo siento, nosotros no creemos en eso. Me critican muchas veces mis colegas empresarios y consultores que nos vendemos baratos. Que regalamos conocimiento. Que le solucionamos al cliente en una mañanita y sin cobrar lo que, adornado con un documento de trescientas páginas y alargado unos cuantos mesecitos, podría habernos dado un dinerito curioso. Pero que le voy a hacer. Seré un romántico, un gilipuertas o tendré muy claro que los días del FUD se han terminado y se abre ante nosotros una era de empresas Ágiles. El tiempo lo dirá.
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.
Una de Scrum
Escrito el 26 de Julio de 2007 a las 11:23
Me encanta Scrum. Me parece elegante en su simplicidad, pero que nadie se lleve a engaños, es un framework muy poderoso siempre que se respeten a rajatabla sus reglas. En este sentido, ocurre como decía el ScrumMaster Miyagi:
Tu Scrum “sí”…Vale. Tu Scrum “no”…Vale. Tu Scrum “supongo”, tarde o temprano…¡Chof! Aplastado como uva.”
Supongo que eso fue lo que le ocurrió a Chuidiang en su fallido intento por implementar Scrum. Tal como comenta Rodrigo Corral en el más que recomendable blog sobre programación “La masa, el ladrillo, la bota, el bocadillo…“, nadie dijo que Scrum no requiriese un esfuerzo. Y es que uno lee cosas como Scrum en cinco minutos o explicando Scrum a mi abuela y parece que esto es coser y cantar, pero no se debe confundir simplicidad con inmediatez: si uno se aventura por las aguas de Scrum sin contar primero con la experiencia necesaria en gestión de proyectos se puede acabar convirtiendo en el Scrum Master Jar Jar Binks (lectura MUY recomendada a la que llegué vía Navegápolis, igualmente recomendable).
Y no quiero decir que los documentos anteriores no sean estupendos (yo los tengo guardados y los uso). Pero no es lo mismo leer un artículo sobre física cuántica que ponerse a acelerar partículas al frente del CERN. En este sentido, a los que queráis profundizar en el uso y ventajas de Scrum os recomiendo fundamentalmente dos lecturas (aunque posiblemente no descubra nada a los que ya estáis metidos en el ajo): Agile Project Management With Scrum de Microsoft Press es el clásico, y tiene una definición muy concisa de los procesos y reglas de Scrum. No obstante, la parte relativa a las anécdotas y experiencias implementando Scrum es un poco oscura para mi gusto, quedándose en la superficie del proceso y no entrando en los detalles del día a día. En ese sentido es muchísimo más revelador el documento Scrum and XP from the trenches que, además, podéis descargar grauitamente.
Este último es sin duda magnífico, ya que está imbuido de la misma simplicidad que destila Scrum pero además te muestra al detalle cómo implementaron Scrum en una organización real, justificando cada una de las decisiones. Por ejemplo, comentan que sus Sprint duran tres semanas, y explica que es la longitud óptima a la que llegaron después de hacer varias pruebas, en las que comprobaron que si los sprint eran muy cortos, como prefieren los dueños de producto, se conseguían más entregas, más ciclos de realimentación pero también un mayor costo en términos de gestión (más reuniones de sprint, más documentación). En cambio, si los sprints eran muy largos, como prefieren los desarrolladores, había más tiempo para desarrollar, documentar y probar, además de tener menor carga de gestión, pero a cambio los desarrollos eran menos ágiles. Al final, comentan, la longitud del Sprint es un compromiso entre desarrolladores y dueño del producto, y ellos llegaron al compromiso de las tres semanas. Finalmente recomienda que, una vez escogida una longitud de Sprint, esta se mantenga inalterable para todos los equipos, de forma que se vaya formando a los mismos y acostumbrándolos a trabajar en esos plazos. Así es más fácil estimar qué se puede hacer en el Sprint y qué se saldría de las capacidades reales del equipo.
Bien, eso es gestión de proyectos en estado puro. Es incluso más, entra en el ámbito de la cultura corporativa y la madurez de las organizaciones en la gestión de proyectos. Y todo ello sin complejas fórmulas, tremendas herramientas ni farragosas burocracias. Además está mucho más justificado que el “los sprints duran 30 días y uno debe mantener el plazo” del libro de Microsoft. A lo largo del libro explican desde “trucos” para gestionar las reuniones de sprint hasta los campos que debería tener una lista de tareas de sprint o de producto, pasando por cómo mantener un “cuadro de mandos” físico del proyecto y como interpretarlo a simple vista. Genial.
Otra cosa que me encanta de este último documento es el uso que hacen de los paneles en las paredes, las tarjetas adhesivas y las pizarras. A lo largo de mi experiencia como gestor de proyectos, he encontrado que una pizarra en blanco y un taco de post-its son de las herramientas más poderosas con las que uno puede contar, y no estoy exagerando. Lo que pasa es que, y de nuevo entroncamos con Scrum, su elegante simplicidad hace que muchos no se las tomen en serio y piensen que uno está jugando a los consultores y perdiendo el tiempo cuando encierra al equipo a cal y canto y entre todos se dedican a pegar post-its por todas las paredes como si quisieran cambiar la decoración del edificio.
En cualquier caso, ¿Está Scrum orientado sólo a los desarrollos de software? ¿Podría usarse Scrum como método de productividad personal, en una especie de “Scrum de a uno“? ¿Son equivalentes el perfil de ScrumMaster y el del ProjectManager? ¿Merece la pena la certificación ScrumMaster? Creo que son preguntas interesantes a las que iré dedicando algo de tiempo en el futuro.
-
Artículos recientes
-
Categorías
-
Archivos
-
Blogroll
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.m (arroba) presionblogosferica.net. También puedes seguir el blog a través de su Feed RSS
¿Un café?
Buscar:
Suscriptores:
Tags
2.0 3G 2008 actitud Agile andalucía apple artículos asesor aspecto atrevete autoayuda autonomo autonomos ayuda backup Blogs blogueros Boris Gloger buddha burbuja business angel business plan C++ calendario cambio capital carrera cerveza cervezas clientes colaboración comentarios comunicación conciliación consultoría contactos conversaciones covey crack Creatividad CRM CSM cultura curriculum curso customer care David Allen diodo diseño EBE07 economía efectividad einstein ejercicios empleo emprendesur empresa empresarios empresas encuesta equipos estadísticas estrategia Eventos facturable facturas feedback flickr Formación freelances FUD funky business futuro garajes gente Gestión GMail GNU Google GTD guy kawasaki hábitos henrik kniberg Herramientas horarios IBM independencia financiera infojobs infoq ingenieros Iniciador innovación inversores ishikawa iweekend java jefe de proyecto Jeff sutherland jornada laboral kaizen karma Ken Schwaber lean liberlabor Libros Linus Linux málaga Madrid mailing manifiesto Marketing mente mercado laboral micropost microsoft miedos Mike Cohn mision mochila motivación muebles navidad negociación negocio negocios networking objetivos ofertas oficina oficinas ONG pareto pathsync peopleware personas php pizarra plan de negocio planhq PMBOK PMI PMP positivismo proactividad problemas productividad producto programación programadores proyectalis proyectos proyecto vital rails rentabilidad responsabilidad social reuniones richdadclub riesgo ruby scrum scrum & xp from the trenches ScrumMaster Scrum y XP desde las trincheras servicios sevilla sistemas SL social start-up startup Stephen Covey suerte SugarCRM tecnología Telefónica teletrabajo tema tercer sector tiempo time tracking toyota transparencia twitter VC ventas venture capital viaje viajes video videos vision web wii wordpress wozniak xp yahoo zona de confort
Que se dice por aquí:
- danieltellez: Eso es como el “just say no” pero del lado contrario, no ? … (es broma)
- danieltellez: Yo necesito un tatuaje de esos también… :$
- Jose Luis de la Rosa: Por dios!!! No estoy solo en el mundo… es desalentador encontrarse con ese tipo de...
- Rafa: Aytorn Senna (uno de los más grandes pilotos de Formúla 1) dijo: “Si tengo todo bajo control, es que no...
- Jordi Bufí: Voy a tatuarme este post en la barriga (pero al revés, para poder leerlo cada mañana cuando me...
Qué se dice por ahí:
- externalidades: Don Patrón
- Negociando los plazos: información | Presión Blogosférica En Pymes y Autónomos | La importancia de la liquidez y...
- ChemaHoyos.es: Me interesa (6)
- Presión Blogosférica: Felicidad de 9 a 5
- lboisset’s Ruminations: Y más y más tareas
Fotos
www.flickr.com
|
