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

Tapar

Escrito el 11 de Mayo de 2008 a las 19:50 

Vaya. Que ocupado estoy y que poco escribo. Fin del apartado apologético. :twisted:

Escuchaba esta mañana en la radio de un taxi (uno de mis pocos contactos con la realidad cotidiana últimamente) que en Madrid, en un hospital, hay un pollo montado a cuentas de una colonia de bacterias asesinas en la UCI que se han llevado por delante a varias decenas de enfermos. Los profesionales sanitarios consultados han dicho que llevan meses denunciando esta situación ante los correspondiente órganos competentes del hospital y de la administración sanitaria y que no han recibido respuesta alguna a sus quejas.

Es más, me atrevo a postular que más que no recibir respuesta lo que han recibido ha sido la directriz de taparlo todo. Que no se sepa. Que no salga “la mierda”, que es el término técnico al que recurren habitualmente las empresas cuando se refieren a los problemas que no se solucionan. Lo juro, en casi todas las empresas por las que he pasado he llegado a escuchar lo de “que no salga la mierda a la luz”. O yo he tenido muy poca suerte, o esto ya es cultural.

Curiosamente, cuando uno estudia empresas excelentes, en el sentido de la búsqueda continua de la excelencia, se encuentra con que, instaurada en la cima de los principios, prácticas y valores corporativos, se encuentra la confianza absoluta en los equipos de trabajo y en su habilidad para resolver los problemas al ser los que mejor conocen el trabajo que desempeñan, así como la instauración de un proceso constante e inexorable que saque a la luz los problemas, no con ánimo de buscar culpables y cortar cabezas, sino con el objetivo de analizar las causas raices y proponer las líneas de acción que se encaminen a la erradicación permanente de dicho problema. Al fin y al cabo, el Kaizen, la mejora continua, no deja de ser simplemente eso: exorcizar demonios, para lo cuál lo primero es, como sabe todo buen exorcista, jugador de rol o aficionado a la literatura gótico-fantástica, nombrarlos.

Sin embargo, cuando nos dedicamos a “tapar la mierda”, el conjunto de valores y mensajes que estamos transmitiendo no ya a los empleados en cuestión, sino a toda la organización, es brutal. No te preocupes de estas cosas. Tu a lo tuyo. No valoramos tus sugerencias. No toques las narices. No te dediques a chinchar y señalar problemas. Estas cosas son así y punto. Siempre han sido así. No hay soluciones.

A corto plazo “tapamos la mierda”. Pero a la larga, este tipo de estrategias solo tienen consecuencias negativas. Al final las cosas salen, y magnificadas. Encima se sabe que los problemas eran conocidos pero no se ha hecho nada por solucionarlos. Y por el camino nos hemos cargado la confianza en las personas y la cultura corporativa. Sin contar con las pérdidas potenciales por las mejoras que no se instauraron en su momento y que llevarían tiempo cundiendo. Comentaba antes lo de las empresas excelentes, pensando precisamente en el Kaizen, la mejora continua nacida en el seno de Toyota. Pues bien, otro de los principios básicos de estas empresas es el foco constante en el largo plazo, incluso a costa de pérdidas en el corto. Otra de las cosas que no hemos interiorizado aun en según qué empresas y según qué entornos.

Y luego a estas organizaciones se les pide que instauren un proceso de innovación (porque, a ver si nos enteramos de una vez en este país, la innovación es un proceso y como tal debe ser gestionado) todo lo que se les ocurre es poner un “buzón de sugerencias” o hacer “concursos de ideas”. Pero a ver quién tiene ideas cuando, durante añós y de forma sistemática, nos hemos dedicado a machacar a todos los que han apuntado un área de mejora (buen principio para la innovación, por ejemplo). Y es que la cultura se acaba comiendo con patatas cualquier estrategia. Así nos luce.

Categorías: Gestión
Tags: ,,,,,,
6 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

Buscar:

Suscriptores:

Tags

Que se dice por aquí:

Qué se dice por ahí:

Twitter


Fotos

www.flickr.com
angel.medinilla fotos Más fotos de angel.medinilla
Cerrar
Enviar por Correo