Fiasco Awards

Un día los Reyes Magos (que están ya como quien dice a la vuelta de la esquina) me trajeron un juego que aparentemente iba contra toda regla (esa era su regla): "MAD: El mundo al revés: quien pierde... ¡¡gana!!". Por ejemplo, las fichas avanzaban en el sentido contrario a las agujas del reloj, y no al revés como suele ser lo habitual. Todas las pruebas están orientadas a ganar dinero, y de hecho, lo peor que podía pasarte es que te tocara EL billete, uno por valor de un millón trescientos veintinueve mil sesenta y tres dolaracos. (sí, $1.329.063). ¿Verdad que es un tanto ridículo que quien pierde, gana?

Pues no tanto. El perder, el fracasar, siempre debe suponer una lección aprendida, una intención de no cometer de nuevo un error ya cometido. Ese es el único error que de verdad existe. Repetir, y no aprender. Es bien conocido que la "cultura" española no ve con buenos ojos los fracasos y los errores, al contrario de lo que sucede en Estados Unidos (que, es verdad, se van al otro extremo).

El caso es que un grupo de unas diez personas, organizadas por medio de una web 2.0, y vinculadas en su mayoría con el sector de las Tecnologías de la Información y las Comunicaciones (TIC), hartos de esa situación, decidieron durante la Nit de les Telecomunicacions promocionar un premio que valorara la cultura del fracaso. Como lo oyes.

La noticia la leí ayer en El Economista. En palabras de Antoni Brey, uno de los promotores del galardón, su objetivo era formar:

[un] pequeño club de reflexión y pensamos que era muy interesante fomentar el esfuerzo y la cultura del fracaso en España.

Ahí es nada. Y ojo: no cualquiera puede presentarse. Todos los proyectos presentados pasan por una fase de evaluación en la que deben demostrar documental y fehacientemente que su proyecto fracasó. Aparte de eso, las condiciones son pocas: entre otras, debe ser un proyecto concreto (no valen fracasos de empresas enteras), debe estar relacionado con las TIC, y debe presentarse un breve resumen de lo que se ha aprendido. ¡Esto último es el verdadero valor que la iniciativa tiene para mi! ¡Aprender del error!

(Inciso: ¿Os habéis fijado en el logotipo de los premios? La bombilla rota es un símbolo perfecto para lo que quieren transmitir)

¿Y vosotros? ¿Aprendéis de vuestros errores? ¿Examináis lo hecho y rediseñáis el futuro? Para hacerlo algo más concreto: ¿os presentaríais con algún proyecto laboral o personal en el que hayáis fracasado a los Fiasco Awards? ¡No me creo que no! :-)

 

Enlace | La noticia, en El Economista
Enlace | Página web de los Fiasco Awards

La foto del juego de Mad es de el seguidor del método.

Contratiempos en Scrum

Hace unos días mi jefe tuvo su demo con algunos de los esféricos implicados más o menos directamente en el sistema del que os he hablado álguna vez, sin que el equipo haya estado presente.

La verdad es que ésta es la última irregularidad de las que han sucedido en el último sprint. Desde que se cometió la primera de ellas, en el equipo nos hemos sentido como esos corredores que tras un pequeño tropiezo, con cada paso se desequilibran más y con cada paso intentan recuperar el equilibrio de nuevo.

Así por resumir, ésta es la lista de pasos tropezantes re-equilibrantes:

• Tras finalizar el segundo sprint, la demo se retrasó cerca de una semana (la demo debe celebrarse justo el día después del final del sprint).
• Aprovechando que había una semana de por medio, el product owner (el representante del usuario  en el proyecto) incluyó funcionalidad por motivos esencialmente políticos (o sociológicos, como dirían DeMarco y Lister), y no por el valor añadido al producto. El esfuerzo empleado en ello no ha sido visible ni en la estimación, ni en el burndown chart.
• La fecha de la demo cambió dos veces en el transcurso de cinco días, lo que influyó aún más en la desorientación del equipo.
• La demo se llevó a cabo por la tarde, lo que impidió realizar el retrospective a continuación (el retrospective debe realizarse justo después de la demo).
• Como consecuencia del punto anterior, el retrospective se tuvo que dividir en dos sesiones de una hora y media cada una (más descoloque).
• El sprint planning meeting se celebró un viernes, lo que redujo en tres horas el tiempo disponible para la estimación. El cuarto sprint empezó el lunes siguiente, pero sin tener todas las historias estimadas (hubo que hacerlo ese mismo lunes).
• La duración del tercer sprint (el que hemos acabado de terminar) se fijó en siete días laborales. Este tiempo, fijado una vez más por motivos político-sociológicos, nos ha resultado muy incómodo.

El caso es que con Scrum, hay que tener una cosa muy clara (y ahí estoy totalmente de acuerdo con Jeff Sutherland): el método es muy sencillo, con pocas normas para nada complicadas; pero si quieres hacer Scrum, debes seguirlas estrictamente. Mientras esto sucedió en nuestro proyecto, las cosas fueron estupendamente. El incumplimiento de una norma un día y las que vinieron después provocó que las cosas fueran empeorando. Seguir Scrum a medias no es hacer Scrum.

— Ok, Wil, pero seguro que hay algo positivo...

¡Por supuesto! Lo positivo es que:

• Todos esos asuntos aparecieron en el retrospective (como ya comenté) así que somos conscientes de ellos y estamos tomando las medidas para corregirlos.
• A pesar de las dificultades, seguimos fieles al método. Incluso la funcionalidad que fue inyectada fuera del sprint se trató como si hubiera estado incluida, llevando a cabo los daily scrum, estimando cada tarea, etc. Todos los miembros del equipo sentimos (y sabemos) que Scrum funciona, y luchamos por que continúe funcionando.
• Hemos aprendido que nuestra duración óptima de sprint se encuentra alrededor de las tres semanas (antes aprendimos que los sprints más largos son mejores al principio, para estabilizar el proyecto).

¡Estamos más animados que nunca! Buscando remedio a los problemas, enfocados en hacer avanzar el trabajo, pero de forma ordenada, no de cualquier forma.

Evento Blog España 2008 (Domingo)

La noche del sábado al domingo, cuando llegué al hotel, me dormí con el móvil en la mano, la hora de la alarma fijada, pero sin haber pulsado el botón Aceptar, así que me levanté tarde, aunque lo justo como para repostar y dirigirme al Barceló para navegar la última parte del río Ebe.

Asistí a las tres charlas de la mañana. La primera, Publicidad: viejos y nuevos formatos, enfrentó a las empresas convencionales de publicidad y a las de publicidad on-line, con las intervenciones de Javier Tallada, de TFM TAPSA, por las primeras, y de Olga Palombi, de Social Media, por las segundas. El Sr. Tallada fue valiente al defender su postura 1.0 en un foro 2.0, y supo desenvolverse bien. ¿Mi opinión? Que la pregunta no es "convencional u on-line", sino "cómo puede aprovecharse nuestro cliente de la sinergia entre ambas". El debate fue moderado por Juan Luis Polo, de Territorio Creativo.

La siguiente ponencia corrió a cargo de Luis Suárez, evangelista de tecnologías 2.0 de IBM, y le puso por título Servicios y tecnologías 2.0 en la empresa, de la que esperé más, quizá algo más práctico, y no una exposición de la manera en la que él asesinó su correo electrónico (o como poco lo dejo agonizante), y se empleó a fondo en otro tipo de herramientas 2.0 para sustituirlo y, en teoría, mejorar su colaboración con otros. De todas formas, me gusta ver puntos extremos, que es de donde más se puede aprender.

Sin embargo, la última pero desde luego para nada la menos importante, fue la brillante explicación por parte de Hernán Casciari de por qué los blogs están condenados a morir y con ellos los bloggers, y por qué ese paso a mejor vida significará el resurgimiento de la creación. Por qué no decirlo: aunque no soy más que un mindundi, el last monkey, en este mundillo doscero, me sentí orgulloso de ser blogueeeeero, aunque sea un insulto :-) Fue sin duda la perla más brillante de entre todas las de la corona Ebe. Gracias, Hernán.

Motivos de fuerza mayor no me permitieron despedirme de la gente que quería y como se merecían, pero no hay problema porque, uno, lo hago desde aquí (gracias), y dos, lo haré bien ¡el año que viene! ¡Nos vemos en el EBE 2009!

La foto de Hernán Casciari en el EBE'08 es de Pixel y Dixel.

El retrospective del segundo sprint

En el proyecto en el que estamos trabajando, una herramienta de planificación y evaluación de rendimiento de una serie de profesionales, no hacemos el programa de una vez y lo entregamos al cliente cuando todo ha terminado. En vez de eso, construimos el sistema poco a poco, de forma incremental, y se lo vamos mostrando al usuario de forma periódica. De esa forma conseguimos del usuario una valiosa información que nos permite valorar la adecuación del producto que se va construyendo, aparte de hacer visibles muy temprano en el proyecto fallos de concepto, de funcionalidad, de usabilidad, etc. y poder corregirlos a tiempo. Al fin y al cabo, los que mejor conocen el dominio del problema y los que en definitiva van a usar el programa son esos mismos usuarios.

Cada uno de estos periodos de tiempo, en los que aumentamos la funcionalidad del sistema, recibe el nombre de sprint, y las reuniones periódicas reciben el nombre de sprint review meetings, aunque nosotros las llamamos demos.

Detrás de cada demo, los miembros del equipo y el Scrum Master (o sea, el que suscribe) llevamos a cabo otra reunión en la que analizamos qué fue lo que hicimos bien (y alegrarnos), qué fue lo que no se hizo tan bien (observad el sutil efecto impersonal) y qué medidas vamos a tomar para corregirlas. A estas reuniones se les llama sprint retrospective meeting.

¿Bueno, pues hoy hemos tenido nuestro segundo retrospective. Y hemos salido muy contentos. Por lo pronto, es toda una novedad que echemos la vista atrás para poder analizar qué se hace mal y poner remedio cada tres semanas, que es nuestra longitud de sprint. Pero hacerlo dos veces, es un milagro ;-). Respecto al anterior retrospective, he notado que somos mucho más equipo, que nos conocemos mejor. Nos enriquecemos mutuamente con el intercambio de ideas, de sugerencias, de puntos de vista y de reflexiones. Para decidir qué medidas correctoras íbamos a aplicar durante nuestro tercer sprint, hemos escrito en PostIts de los grandes cada uno de los aspectos negativos. En una sesión de brainstorming, hemos ido apuntando en cada PostIt las posibles soluciones, mientras que íbamos agrupando las que estaban relacionadas (pruebas, estimación, método...). Luego, cada uno ha dado sus nominaciones: tres votos a repartir entre un máximo de tres aspectos negativos a resolver.

Pero ha sido la agrupación de los PostIts y la lista de los nominados lo que me ha hecho pensar. Le hemos dado muchísima más importancia a los temas relacionados con las pruebas que con la estimación. Por lo visto, preferimos asegurar la calidad del código frente a la calidad de la estimación. También es verdad que en la primera retrospective ya se acometió una mejora sustancial: las estimaciones ahora se hacen mucho más precisas, descomponiendo inicialmente las historias del usuario (las características que le aportan valor) en tareas más pequeñas antes de empezar el sprint, y no después. Y lo que ya me ha dejado descolocado es que una de los aspectos negativos que hemos detectado es que no hemos cumplido bien las normas del scrum. Y ahí soy yo el principal responsable, porque esa es una de mis responsabilidades... Sin embargo, estoy satisfecho. Está claro que el equipo cree en este método, si no fuera así, no le importaría que las normas hubieran sido vulneradas.

Ahora falta que la Dirección también acabe igual de convencida como nosotros. Creo que vamos por buen camino.

Imagen cortesía de Mountain Goat Software.

Déjà vu

¿No te ha pasado que estás en el curro y te preguntan...?

— ¿Conseguiste que el proyecto funcionara?
— Esto... no...
— ¿Lo hiciste como te dije que debías hacerlo?
— ¡Sí!
— ¿Dices entonces que estoy equivocado?
— ¡NO!
— ¿No que no estoy equivocado o no que no lo estás diciendo?
— Definitivamente, sí.

Y en ese punto ya no sabes qué decir ni ná de ná.

La tira es PhD, Piled Higher and Deeper.

No hacer nada

Estamos con las orejas rojas de oír que hay que ser proactivo, y adelantarse a los acontecimientos, y que hay que actuar y actuar y actuar y actuar.

Y pensamos que trabajar es hacer cosas. Y en ocasiones, trabajar bien es NO hacer ciertas cosas. Esto es especialmente cierto en temas de creatividad. Me ha venido por correo el boletín de la Fundación Neuronilla y saltando de link en link en la selva de links he caído en un artículo llamado "40 frases mortales para la creatividad". Estas son algunas de las más divertidas (y que he oído con mis propias orejas que se comerá la tierra):

• Es demasiado pronto/Es demasiado tarde.
• Hasta ahora nunca lo habíamos hecho.
• Esto implica mucho trabajo [¡Anda, claro!]
• ¡Demasiado teórico! [No habré oído veces ésta...]
• No es asunto nuestro.
• ¡Ya se intentó antes!
• Sí, pero... [Ay, ese pero eterno...]
• ¡Es una tontería! [Mi favorita... ¿Quiénes hacen tonteríaaaas???]

La lista completa podéis consultarla aquí.

Bonus: Cien formas de volver loco a un colaborador, via Vida de un consultor.

La oreja roja es de Glamhag.

Cazadores de mitos

Dan Pritchett (de Adding simplicity) escucha la televisión mientras hace otras cosas. Y escuchando la televisión se ha dado cuenta de que muchos programas tienen graves lecciones que los ingenieros del software podemos aplicarnos. Esta es la lección que podemos obtener de Cazadores de mitos.

I enjoy Mythbusters immensely. Yes, it is truly geeky fun. And they get to blow real things up, not just simulated explosions in mathematical models and 3D renderings. But what is a true joy to watch is how thoroughly methodical they are in solving problems. They research, design, and prototype. They fanatically analyze their results and make adjustments based on the data. Few programs have been bold enough to expose the analytical and development process so transparently. In fact, the boldest thing Adam and Jamie do is solve a problem in front of millions of people, knowing that they will receive hundreds of comments on the work they do. Think about it. Would you work on a problem in front of millions?

Mi "traducción libre":

Disfruto un montón con Cazadores de mitos. Sí, es realmente diversión geeky. Se las apañan para hacer saltar las cosas por los aires, no con explosiones simuladas en modelos matemáticos ni renderings en 3D. Pero lo que de verdad es alucinante es ver lo minuciosamente metódicos que son al solucionar problemas. Investigan, diseñan, y construyen prototipos. Analizan hasta el fanatismo sus resultados y hacen ajustes basados en esos datos. Pocos programas han sido tan audaces como para exponer de una forma tan transparente el proceso de análisis y desarrollo. De hecho, lo más audaz que [los presentadores/cazadores] Adam y Jamie hacen es solucionar el problema frente a millones de personas, sabiendo que recibirán cientos de comentarios sobre el trabajo que realizan. Piensa sobre ello. ¿Trabajarías en un problema frente a millones de personas?

Más sobre la influencia de Colombo, Monk y Maravillas modernas (Modern mavels) en Television for software engineers.

 

PS: Ya, ya... Es verdad, no traduje geeky, ni rendering. ¿Sugerencias?

Fallar

Todos conocemos Amazon. Todos sabemos de dónde salió y dónde ha llegado. Me pregunto a dónde porras llegará... ¿Cómo lo hacen?

He encontrado esta cita de Jeff Bezos, el CEO de Amazon (o sea, el capo di capi) en un post de Enrique Dans:

Our willingness to be misunderstood, our long-term orientation and our willingness to repeatedly fail are the three parts of our culture that make doing this kind of thing possible.

Que traduce libremente como:

Nuestra disposición a ser incomprendidos, nuestra orientación al largo plazo y nuestra tolerancia a fallar de manera reiterada son las tres partes de nuestra cultura que hacen posible que hagamos las cosas que hacemos.

Creo firmemente en una orientación a largo plazo, para mí una señal de madurez, de ceder al beneficio inmediato por uno mayor en el futuro. Con el tiempo, aprendí (sigo aprendiendo) que ser incomprendidos no está tan mal, sobre todo si lo ves desde el punto de vista de pertenencia a una élite esotérica que liderará el mundo cuando se acabe el petróleo ;-)

Pero, ¿y la tolerancia a fallar de manera reiterada?

De manera reiterada, ¿sí?

Fallar, ¿vale? Equivocarte.

Tolerancia; tolerancia a fallar; de manera reiterada... Lo leo y lo releo...

 

Y sobre todo si así, sin anestesia ni nada, te preguntan: ¿y qué pasa si fallas? ¿qué pasa si te equivocas?

Eso... ¿qué pasa?

Reflexionando...

 

Aviso de higiene mental: Si no has leído "Fallar" y has leído otra cosa, o has pensado en otra cosa distinta, en fin... bueno, no pasa nada :-)

La foto del Café "No puedes fallar" (que tiene página web y está en Emeryville, justo al norte de Oakland, en California) es de pbo31.

El movimiento se demuestra andando

Raúl comenta en su blog lo difícil que lo tiene para explicar a sus potenciales clientes lo bueno que es:

Siempre he sido muy pudoroso. No es falsa modestia: creo que tengo algunos puntos fuertes relevantes (y tampoco tengo empacho en reconocer mis puntos débiles). Pero siempre me ha gustado que el movimiento se demuestre andando, que la gente descubra esos puntos fuertes al cabo del tiempo. El problema es que si quiero convencer a un potencial cliente, tengo que ser el que dé el primer paso para atraer su atención y conseguir que me dé la oportunidad de demostrar mi valía.

Me vi reflejado, y quise compartirlo (siempre encuentro más fácil señalar las palabras de otro que elegir las mías, tarea más ardua).

Vía Vida de un consultor

Razones para seleccionar la peor solución

[En un proyecto de desarrollo en problemas] Los consultores, usualmente con la ayuda de los empleados "de las trincheras" emplearían su tiempo, esfuerzo y experiencia en analizar el sistema en desarrollo o ya en producción. Alcanzarían un solución limpia, llevadera y esencial —técnica, arquitectónica, metodológica, organizativa, lo que sea. Dicha solución se presentaría a la alta dirección... En cuyo caso, la alta dirección (o la dirección del proyecto) diría: "No, no podemos hacerlo".

En ocasiones, no darían un motivo concreto por el que la solución no era aceptable. En otras, dejarían claro que esa no era la solución que querían o que pensaban que sería aceptable. Si llegaran a explicar el rechazo, con frecuencia sería en términos presupuestarios o políticos.

Entonces, el equipo investigador regresaría y buscaría una solución alternativa (y menos óptima). Si se llega a una, se rechazaría de igual manera, y así sucesivamente, habitualmente hasta la solución menos deseable. Barry [Glasco] dijo que él y otro colega, Chuck McCorvey habían pasado por estas situaciones tantas veces con un cliente que bromeaban con presentar primero, sencillamente,  la peor solución, dado que normalmente era la única solución que aceptaría el cliente.

Webster, Bruce F., Resistance to the Right IT Project Solution, Baseline (traducción propia).

El artículo de Webster continúa explicando los motivos, en su opinión, de este comportamiento, a todas luces paradójico. Según él, son tres las razones: política interna (la solución propuesta debe satisfacer a más de un grupo de interesados en el proyecto, con necesidades en conflicto), presupuesto (la dirección tiende a favorecer una solución de pequeños gastos sucesivos en vez de un único y gran gasto inicial, aunque la acumulación de aquellos supere con creces éste último), y miedo u orgullo (los fallos no suelen recompensarse, y los que se cometen son difícilmente reconocidos).

Salvando el primero de los motivos, me parece que los dos últimos tienen que ver más con cierta madurez, ya no profesional, sino personal, de los implicados por un lado, y con la prevalencia de la intuición sobre el razonamiento. ¿Seguiremos alentando soluciones de mínimos que suponen un beneficio inmediato, frente a mejores soluciones, más costosas inicialmente, pero más rentables a largo plazo? ¿Seguiremos pensando que cometer un error en el trabajo conlleva ineludiblemente un castigo? Y aunque así fuera, ¿qué mejor castigo que arreglar el problema causado? Con una política o cultura que castiga los errores (de los que el camino de la exploración está jalonado) sólo se conseguirán dos cosas: que los fallos se oculten o que se "transfieran" a otro. Ninguna de las dos es buena.

Y por favor, si has cometido un error en tu trabajo, acepta tu faceta humana (errare...) y gasta tus energías en encontrar una manera de solucionar el problema, y más aún, en evitar que dicho fallo vuelva a repetirse. Nota al margen para los demás que ven que alguien que ha cometido un error, lo acepta (y en particular para sus jefes): echadle una mano, que criticar es muy fácil, pero estar en lo correcto no. Además...

Cuando el hombre abre la boca, se juzga a sí mismo.

Ralph W. Emerson

Presentaciones de Kniberg sobre Scrum

Henrik Kniberg, el autor del libro electrónico Scrum and XP from the Trenches, ha publicado en su blog tres presentaciones que ha impartido en Agile 2008, celebrado este año en Toronto. Os las enumero a continuación y aporto mis impresiones.

Bootstrapping Scrum and XP in a crisis (pdf)
La url del post da un error

Pistas y consejos para arrancar Scrum y XP. Kniberg y Farhang muestran su experiencia en la implementación de Scrum por primera vez en su empresa. Deja caer varias pistas, aunque la mayoría viene ya en su libro.

Que el arranque de Scrum tenga éxito o no, creo que depende en gran medida de la cultura que sobre los defectos y la manera de tratarlos tenga la empresa. Scrum levanta ampollas porque Scrum hace muy visibles los defectos. Y hay que ser culturalmente maduro para acometer correctamente esos defectos y no disparar al mensajero.

Ten ways to screw up with Scrum and XP (aquí)

A la hora de acometer un proyecto, tan importante es saber qué debe hacerse, como lo que no debe hacerse. Esta presentación expone 10 formas de joderhundir un proyecto a pesar de seguir Scrum y XP.

Las diez maneras giran alrededor de conceptos clave de Scrum y XP: definición de "hecho", velocidad, retrospectivas, trabajo en equipo, deuda técnica, product backlog, product owner, y sprint backlog.

¿Mi opinión? Que todas se resumen muy bien en una regla: observa y adáptate. Mira qué cosas te funcionan y cuáles no y por qué, y trata de arreglarlas o de adaptarte a ellas. Quizá la experiencia no es conocer las reglas, sino saber cuándo se deben ignorar.

Technical debt - How not to ignore it (aquí)

El concepto de deuda técnica es una metáfora ideada por Ward Cunningham. Es el coste de arreglar algo que se hizo rápido y mal (quizá buscando un beneficio inmediato), más los intereses provocados por esa deuda (dificultades en la mantenibilidad y modificabilidad del software, por ejemplo).

Como en cualquier empresa, la deuda es un mecanismo de financiación como cualquier otro, pero a nadie se le ocurriría basarse en él y no asumir sus consecuencias, es decir, devolver el capital y pagar los intereses... Excepto en el desarrollo de software. Esta charla define el concepto de deuda técnica y ofrece sugerencias para tratar con ella desde una perspectiva Scrum/XP.

Aún siendo un término que los tecnicoles pueden entender, me temo que todavía pesa más en sus molleras el beneficio inmediato y las pérdidas futuras que el beneficio a largo plazo y pérdidas pasajeras (estos dos último síntomas propios de personas maduras —otra vez la madurez, hmmm—).

---

Enlace | Blog de Henrik Kniberg
Enlace | Scrum and XP from the Trenches (libro electrónico)
Enlace | Agile 2008 (Toronto, Canada)
Enlace | Ward Cunningham
Sobre deuda técnica | Martin Fowler
Sobre deuda técnica | Steve McConnell
Sobre deuda técnica | Primera aparición del concepto (OOPSLA'92)
Sobre deuda técnica | La complejidad como como deuda
Sobre deuda técnica | Deuda técnica (en WardWiki)

Arrastrar y soltar

Jejejeje

Visto en Punto Geek, via un tweet de tonic

De anticuario

Llevo parte de la tarde revisando papeles, libros, carpetas y otras cosas intentando hacer sitio, que hoy por hoy es un lujo. Y me he encontrado mirando por ahí mi carpeta de los primeros años de Facultad.

Si no fuera por lo escrito en ellas, hubiera ido directamente a la basura. Parece que haya pasado por encima un batallón de apisonadoras, los bordes de los separadores están desechos, y la humedad ha puesto su granito de arena en todo el fregao.

¿Y qué hay escrito? Pues mira, esto:

Si un hombre no se contradice, será porque nunca dice nada

Miguel de Unamuno

Haller soñe
Vendita Hilusion
Ke haprovava por fin
La dichosa relijion (o kimika)

Anonimo

Un día quiso Lord Finchley
la luz el mismo arreglar.
Y tal chispazo le dio
Que muerto cayó
¡Bien le está!
Es misión del millonario
Dar trabajo al operario

Hilaire Belloc

Sane sicut lux se ipsam et tenebras manifestat, sic veritas norma sui et falsi est.

"Así como la luz se manifiesta a sí misma y a la oscuridad, la verdad es la norma de sí misma y de lo falso".

Espinoza, Ética, P. II, prop. 43)

Y otras... He dejado las fotos en mi galería de Flickr (que por cierto, he convertido en Pro).

Implicación de los stakeholders

El otro día estuvimos hablando el Product Owner y yo un poco sobre la demo. Lo más destacable de la charla fue que uno de los stakeholders había decidido ir ocasionalmente a ellas. y que algunos de los implicados podrían no llegar a ser ni siquiera convocados. Ignoro los motivos de tal decisión, pero creo que no es acertada. Es necesario que el equipo sienta que los interesados estén... interesados precisamente :-) Al fin y al cabo, esa es su labor (ya sabéis la diferencia entre los comprometidos y los implicados, ¿no?).

Sé que todavía es pronto para hablar de la demo cuando todavía no hemos llevado a cabo ni siquiera el primer Sprint Planning Meeting, pero es un punto que deberemos tener en cuenta. ¿Cómo solucionar un problema como este si no se entienden los motivos para no estar implicado?

Creo que la solución está en buscar un punto intermedio, reconocer que los stakeholders tienen sus motivos, aunque no se comprendan, y buscar, si no una implicación ideal del 100%, sí al menos un punto intermedio, algo así como una Escala Wituki de Implicación de los Implicados (EWII), entre 0 y 5 (0 significa que no está implicado para nada). Es decir, el objetivo no es obtener el 100% de implicación, el objetivo es obtener la máxima implicación posible.

Antes decía que el equipo debe sentir que los implicados lo son. El objetivo de la demo no es que vaya un "jefe" para que el equipo sienta la presión. La presión viene ya auto-impuesta desde el mismo momento en que el equipo se compromete con una pila de sprint. Por eso no vale cualquier jefe. Los asistentes deben ser precisamente los stakeholders, porque son ellos los que podrán evaluar adecuadamente si el desarrollo está tomando el rumbo que ellos necesitan, el rumbo que les da más valor. Por eso una demo con el Product Owner, el Scrum Master y el equipo no es lo ideal (aunque se puede hacer).

Lo que no quisiera es que todo ello acabe significando que estamos haciendo Scrum al 60%. Debo ser flexible con las reglas, pero debo saber en qué punto pueden dejar de romperse. Y sobre todo, lo que no me gustaría es que a base de ir saltándoselas, el resultado no sea el esperado y se llegue a pensar que Scrum no nos ha servido.

Seguiremos informando.

Presentación de Scrum

Bueno, pues ya está hecho. Esta mañana he presentado a mis compañeros la metodología Scrum, que vamos a emplear en un proyecto piloto para ver sus bondades y sus maldades. La verdad es que empecé un poco trastabillado, pero luego la cosa ha ido a mejor, y de hecho me ha parecido que la gente ha salido muy ilusionada con el número método (todo gracias al método, no a mi ;-)

A parte de la presentación en sí, uno de los objetivos que perseguía era ver qué dudas suscitaba el método en mis compañeros, en ese momento muchísimo menos contaminados que yo con toda esta historia.

Han salido preguntas muy interesantes:

- ¿Cuántas personas debe tener un grupo? ¿Deben tener alguna formación específica? ¿Cómo escala el método a equipos más grandes?

- ¿Sabemos de alguien que esté implementando este mismo método?

- ¿Eso significa que vamos a tener que entregar nuestras aplicaciones en 20 días? ;-)

- ¿Cómo se determina realmente lo que va en el Product backlog?

- ¿Cómo se va a conjugar una aproximación iterativa orientada a la funcionalidad con el código de infraestructura necesario para darle soporte?

Los comentarios de pasillo después me han confirmado en la idea de que la gente ha salido muy ilusionada con el tema. Ven claramente que es un método que les da libertad suficiente para hacer bien aquello que saben hacer bien, que fomenta la comunicación entre los implicados en el proyecto, y que hace las cosas muy visibles. Sobre todo, parece divertido :-).

Los primeros retos con los que nos vamos a enfrentar son sin duda:

- Decidir qué va en el product backlog y de qué manera.

- Formar a la gente en procesos de estimación (aquí McConnell volverá a ser de gran ayuda).

- Aunque parezca una chorrada, encontrar un buen sitio donde celebrar los Daily Scrums, y prepararla adecuadamente el entorno para organizar otras reuniones del equipo, el Scrum Master y el Product Owner...

En fin, que queda mucho trabajo que realizar, pero estoy super-ilusionado con ello. A medida que vaya encontrando dificultades, las iré poniendo por aquí, con la solución que pueda haber encontrado o que hayamos desarrollado (para resultados buenos, la blogosfera está llena ;-)

Una cosa más: el chiste del cerdo y la gallina sonará muy bien en inglés, pero en castellano el éxito ha sido cero. Menos mal que he conseguido levantarles una sonrisa al final :-)

Formalmente ágiles

Por fin somos oficialmente ágiles.

En nuestro equipo de desarrollo habíamos seguido en mayor o menor medida, aunque a veces sin mucha conciencia de ello, ciertos comportamientos ágiles, cogidos con pinzas de aquí y de allá. A pesar de todo ello, no éramos un equipo (oficialmente) ágil.

Ahora, con el apoyo de la dirección, podemos decir que oficialmente nos hemos decantado por Scrum. Lo hemos visto fácil de explicar, sencillo y muy claro. Sin embargo, somos conscientes de que, igual que en cualquier faceta técnica, llevar la teoría aunque sea poca a la práctica implicará muchas decisiones y dificultades.

Scrum probablemente no sea el método definitivo, como no lo es ninguno, pero sí que es una base sobre la que elaborar el nuestro propio. No somos racistas, así que aceptaremos de buena gana cualquier idea que sea compatible con los principios ágiles, sin embargo, en mi opinión deberán aceptarse poco a poco (los cambios bruscos, todos lo sabemos, no son buenos). Tenemos ahora lo que necesitábamos: un marco, un esqueleto sobre el que construir el método que nos vaya bien.

Probaremos el método utilizando como plataforma de pruebas un nuevo proyecto que está ahora mismo en las fases iniciales de definición. Todavía nos queda preparar unas charlas para informar al equipo de lo que pretendemos, profundizar un poco más en los principios ágiles que sustentan el método

Decía antes método, y no metodología, porque metodología es otra cosa. De la Wikipedia:

Método es el procedimiento para alcanzar los objetivos y la metodología es el estudio del método.

Voy a utilizar el blog como medio de reflexión, de registro y con vuestra colaboración, espero que también de debate. No recuerdo quién decía que la inteligencia no es patrimonio de la mente, sino de la combinación de muchas, que las buenas ideas emergen de una red pensante, no de una cabeza preclara.

Y como la situación lo merece, amig@s, nueva categoría: ágil ;-)

Un libro para entender un artículo de 36 páginas

Lo que son las cosas. Si hace unos días compartía algunas notas sobre el trabajo de Alan Turing, hoy leo en un post de Coding Horror que Charles Petzold (sí, el de Programming Windows) ha publicado un nuevo libro llamado The Annotated Turing: A Guided Tour Through Alan Turing's Historic Paper on Computability and the Turing Machine. (Turing comentado: Una visita guiada a través del histórico artículo de Alan Turing sobre computabilidad y la máquina de Turing, me da la sensación que el autor ha querido jugar con tour y turing ;-)

El libro intenta hacer más fácil el estudio del artículo seminal en el que Turing introdujo los conceptos de computabilidad y de la máquina que lleva su nombre. Puedes descargarte el documento original de Turing desde el History of Computing Project (pdf, 500kb).

¿Qué hago? ¿Me lo compro ahora en inglés o espero a la traducción (si llega ;-)?. Luego pienso que tengo una buena pila de libros pendientes, así que no sé qué hacer...

Razones para irse

Computerworld ha publicado un artículo (Eliminate reasons for IT staffers to leave their jobs) en la que comenta los motivos que podría tener una persona para abandonar su actual puesto de trabajo. ¿Crees que es gratis? Si sumas el sueldo de la nueva persona, la formación y el tiempo que tarda en pillar el ritmo, más el conocimiento perdido, el trabajo de más y el daño a la moral del resto de los empleados, según el artículo, el coste asciende a un 150% del salario de un empleado (las empresas que lo saben hacen lo posible por cuidar a sus empleados. Su rotación: 7%).

El artículo enumera a continuación algunos de los motivos que pueden provocar una salida "voluntaria":

• Aburrimiento
• Falta de formación
• Carrera profesional en una calle sin salida
• Falta de vida personal

¡Vaya! Tres de cuatro...

— Capitán Roger a torre de control, solicito permiso para despegar, roger.
— Roger, permiso concedido, pista 36...

Destilado de Singletons

He querido recopilar información sobre uno de los patrones más conocidos y a la vez de los peor usados: el Singleton. Recogido en el ubicuo libro de la Pandilla de los Cuatro (no los de la cadena de televisión, los otros), se ha dicho de ellos que favorecen el acoplamiento, la creación de dependencias invisibles, que hace difícil las pruebas unitarias (precisamente por esas dependencias) y otras lindezas. Otros sin embargo defienden que (bien usado) puede ser un magnífico aliado.

Si tienes prisa o no mucho tiempo para estudiar los inconvenientes de este patrón, yo empezaría por una página de Google relacionada con un "Detector Google de Singletons", que parece casi uno de los chismes del Coyote en sus correrías tras el Correcaminos. Es un resumen muy claro sobre los problemas ocasionados por los singletons. Además, da acceso a otros dos muy buenos.

El primero de ellos es la discusión en el conocido wiki de Ward Cunningham sobre este patrón (además de ser un tremendo repositorio de charlas entre algunas de las mejores mentes del diseño software, en este wiki encontrarás el Repositorio Portland de Patrones). La información no está tan ordenada como en la página de Google, pero seguir la discusión es un buena forma de captar cómo ha ido evolucionando este tema (hace muchos años que se discutió, pero estoy convencido de que sigue de rabiosa actualidad que no de popularidad).

El segundo es el artículo publicado en IBM developerWorks por J. B. Rainsberger, un tipo muy bueno en metodologías ágiles que sigo más por sus artículos en el IEEE Software. Como suele ser habitual en él, presenta el problema de forma muy clara, concisa y amena y ofrece algunas alternativas para evitar los problemas ocasionados por los Singleton. Es de los pocos artículos en los que se comentan las bondades del patrón (como si estuviera diciendo: un Singleton no es ni bueno ni malo, sino que lo usas bien o lo usas mal; ¡me encantan estos argumentos!)

Sin duda es el wiki de Cunningham el que ofrece un tratamiento más amplio del tema. En particular, puedes encontrar la discusión acerca de uno de sus efectos indeseados: la de inyectar estado global a tu aplicación; en otras páginas puedes aprender por qué son buenos para unos y malos para otros, o averiguar formas de reemplazarlos o refactorizarlos. Dado que son clases muy difíciles de probar, encontrarás algún consejo para hacerlo. Ya como curiosidad, tienes a tu disposición implementaciones de este patrón en Visual Basic, Ruby, Python, PHP, Perl, Java y C++.

(No pierdas el tiempo leyendo esta página, tiene que ver con una discusión acerca de la manera en la que habría que organizar el contenido de esta otra página que argumenta por qué los singletons son malignos, que sí es útil).

Termino ya esta recopilación con dos artículos que me han llamado especialmente la atención. En Patterns I Hate #1: Singleton, Alex Miller explica por qué es el patrón que más odia, las alternativas para evitarlos, insinúa cómo refactorizarlos, y da algún consejo si a pesar de todo quieres seguir usándolos. A lo largo de mi viaje por estos territorios, he comprobado que somos muy viscerales con este tipo de cosas, porque en pocas ocasiones leerás que el patrón es apropiado o inapropiado, o bien que es adecuado usarlo en tal circunstancia guiado por cierta solución de compromiso, sino que más bien leerás que alguien lo odia o que es maligno. Mu pofesional ;-).

Steve Yegge es famoso, aparte de por haber trabajado en Amazon, trabajar en Google y por haber migrado Rails a JavaScript, decía que es famoso por publicar entradas tremendamente largas, pero se las apaña para mantener tu atención, a la vez que hace la lectura amena y divertida (aunque más complicada de leer en inglés, precisamente por eso). Cómo no, también ha escrito sobre singletons, pero más que odiarlos o quererlos, piensa de ellos que son... estúpidos ;-) En Singleton considered stupid también los estudia, pero esta vez desde un punto más "psicológico", más "social", más... no sé, mira: échale un looking, diviértete, y luego me cuentas.

Y vosotr@s, ¿qué opináis de Singleton? ¿Es un ángel caído o en nuevo santo que canonizar? ¿Comentarios? ¿Experiencias? ¿Críticas? ¿Algún billete suelto de 50 €? ¡Di algo! Si no, creeré que siempre tengo razón ;-)

Comentario a "La Pastilla Roja"

Acabo de leer el post "Cobrar lo que se pueda a quien se pueda", de La Pastilla Roja, y no he encontrado la manera de realizar un comentario. Como no sé si están habilitados o no he sido bendecido con la habilidad de publicar comentarios ;-) publico esta entrada con la esperanza de que aparezca en la lista de trackbacks.

El artículo trata sobre el concepto de segmentación, y en particular de su aplicación al software. La segmentación se explica mejor con un ejemplo. Una compañía láctea envasa la misma leche (o para el caso, de calidad similar) con dos marcas distintas, una de ellas con un precio sensiblemente superior a la otra. Las personas con cierto poder adquisitivo tenderán a comprar la marca más cara (por prestigio, por calidad, porque son el target de la campaña de marketing o simplemente porque pueden), mientras que los más ahogados, económicamente hablando, cuidarán de su bolsillo comprando la más barata. ¿Motivo? Con una única marca y un solo precio perderían los ingresos provenientes de los que  pueden pagar más, y también los ingresos por parte de aquellos que no podrían pagar ese precio.

El caso es que recordé que todo esto lo había leído yo antes, junto con algunos comentarios acerca de por qué esta estrategia puede llegar a fallar, y es justo esta última parte la que quería aportar al post al que me refiero. Como digo, todo esto lo leí en un artículo llamado Camels and Rubber Duckies, en uno de los blogs tecnológicos más importantes y más divertidos, Joel on software, por Joel Spolsky.

(Ahora acabo de caer en la cuenta de que los que busquen el artículo de Spolsky, también encontrarán gratis el post de La Pastilla Roja ¡Larga vida a Internet! ;-)