Estupor en la FSF

De piedra se han quedado en la Free Software Foundation tras leer un borrador remitido con la intención convalidar como libre un nuevo tipo de licencia denominado OBU (Open But Unintelligible) y cuya principal novedad es distribuir el código fuente abierto pero encriptado. Sinergiaximcontrol ha tenido acceso en exclusiva al preámbulo de dicho borrador:

La licencia OBU no impone ningún límite a las libertades de los usuarios en lo que se refiere al uso del software. Cualquier software bajo licencia OBU puede ser ejecutado, copiado y distribuido libremente por los usuarios. Asi mismo cualquier usuario puede libremente estudiarlo y modificarlo. Para esto último es posible que necesite adquirir previamente algunos conocimientos y habilidades sobre ingenieria inversa, pero eso no afecta a su esencia Open, pues el código está realmente a la vista del usuario, completamente accesible.

Por el momento se desconoce la autoría del borrador aunque algunos testigos hablan de un tipo calvo y otro con barba que murmuraban “A ver si así nos colamos en la junta”. Ante rumores de que la nasa y google podrían adoptar este tipo de licencia en algunos de sus desarrollos, Richard Stallman ha decidido dirigir personalmente la investigación en busca de sus autores.

Tratando al cliente como dios manda

A punto de comenzar un nuevo proyecto nuestro CIO nos alecciona con este ilustrativo vídeo acerca del trato que debemos dar al cliente.

A iterar que son dos días

“Scrum ya no nos vale”. Así de rotundo se manifestó ayer a la muy taurina (o furbolera) hora de las 5 de la tarde el Project Manager de una compañía con aspiraciones, que no perspectivas, de dominar el valle del Sillicon y el del Ganges si se tercia. El individuo en cuestión nos cuenta en exclusiva cuales han sido los principales inconvenientes a la hora de adoptar Scrum en su organización y como a partir de su particular deconstrucción de esta metodología el ChaosKrun va tomando forma. El gran problema que nos plantea Scrum es su pobre definición del concepto de tarea, ¿qué es una tarea? ¿donde empieza? ¿donde acaba?, Scrum no establece métodos fiables para calcular los límites y dimensiones de una tarea. Nosotros, con ChaosKrun hemos salvado este inconveniente adoptando el concepto de “tarea atómica” definido por David Allen. Pero a la hora de decidir qué es una tarea atómica surgen nuevas dudas, ¿donde están las fronteras del átomo? ¿cuales son sus dimensiones? ¿es igual de gordo un átomo de Hidrógeno que otro de Uranio?, me da a mi que no, ¿qué átomo tomar pues como patrón?. Nuestro Product Owner, persona de estudios e ideas imaginativas encontró la solución: lo lógico es que nuestro átomo patrón sea la propia ficha de Scrum, de manera que todo lo que quepa en la ficha forma parte de su atomicidad. Derivado del anterior surge otro inconveniente, ¿como proceder cuando el equipo estima que la atomicidad (o duración según el Scrum clásico) de una tarea excede el número de story points del sprint? La solución por parte del ChaosKrun es recurrir a la propia esencia iterativa de Scrum de forma que, lo que no dé tiempo, se deja para después. Al fin y al cabo eso es iterar. Ante rumores de que la Nasa y Google están estudiando adoptar estas mejoras miembros fundadores del Agile manifesto se plantean ayunar y recorrer a pie los caminos para difundir su auténtico mensaje, evangelizar a cuanto pagano encuentren y revelar al mundo su Buena Nueva.

Iterando a partir de la nada

Una nueva metodología de desarrollo comienza a captar la atención de la comunidad. Por ahora sólo la utilizan una minoría de iniciados, pero los analistas del tema apuntan que va a ser unas de los elementos tecnologícamente más disruptivos desde el descubrimiento del transistor y su aplicación a la retransmisión de los partidos de furbo. ChaosKrun o método iterativo a partir de la nada es su nombre y en palabras de su creador y máximo gurú Yon Pokopago su potencia está en que "pone a los developers en la misma tesitura de Dios justo en el momento de la Creación". Las claves de esta nueva metodología son las siguientes:
- No existen requisitos.
- Dichos requisitos inexistentes pueden variar en cualquier momento del desarrollo.
- Puede que no haya demo.
- No está claro en qué consiste la demo.
- Las fechas de comienzo y final del sprint no sólo son difusas sino además movibles.
- Cualquier miembro del equipo de desarrollo puede desaparecer en medio del proceso.
- Al final todo debe funcionar correctamente.

"La imaginación de los developers se desborda hacia límites cuánticos cuando a partir de una pizarra emborronada les planteas crear algo difuso" continúa Yon Pokopago. La primera iteración del ChaosKrun se denomina conflictiva, "es lógico, la creación del Universo tuvo que serlo" los developers no tienen muy claro que camino tomar, hacia donde orientar sus impulsos, surgen conflictos en el equipo y la gente llega por la mañana con caras raras. Pero tras una primera demo en la que nada funciona correctamente, los esquemas mentales se sincronizan y el fluir de ideas converge en la misma dirección. La segunda y sucesivas iteraciones del ChaosKrun mejoran los resultados exponencialmente hasta el punto en que, después de cinco iteraciones, es posible que el formulario de login se auntentifique correctamente.

"La NASA y Google siguen de cerca la evolución de esta nueva metodología" asegura Yon Pokopago.

Cómo hacer una subida de código a producción para que termine en fracaso absoluto

En mi corta pero intensa vida profesional he seguido muchos métodos, utilizado muchos trucos y pasado mucha tensión para que la subida de código de un proyecto sea exitosa o al menos no parezca eso las fallas de valencia ;)

Pero no es esa la filosofía de este post, sino más bien la contraria, la que un juan-cojones nos hace seguir, así es que si quieres que tu subida de código sea un fracaso absoluto, no tienes más que seguir estos sencillos pasos, te asegurará un intenso cabreo con tu equipo, con el cliente y con toda persona implicada en el proceso.

1.- Deja la subida para un viernes, eso asegurará un nivel de stress en el equipo que no podrías obtener de ninguna otra forma, además de que si el cliente ve algún fallo tendrá 3 días por delante para disfrutarlo completamente.

2.- No testees en absoluto, que sea el propio equipo el que haga los test mientras desarrollan que es lo más rápido. No tiene sentido que una persona externa al desarrollo haga los test y menos si esa persona es la que enseñará el producto.

3.- No le menciones al cliente que ese día se va a subir algo, se ambiguo, así el cliente no sabrá que esperarse, tener a todo el mundo informado en todo momento es tu peor enemigo.

4.- Las empresas quieren contratar brazos, pero no a sus cerebros, desoye todas las quejas de tus empleados cuando te critiquen por llevar esta metodología, es más, evita todo contacto con ellos, entra por otra puerta a tu oficina para evitar ser visto para desconcierto de todo el mundo.

5.- Una vez realizada la subida, simplemente evalúa el resultado por lo que el cliente esperaba que se le subiera, aunque eso no coincida con lo acordado con tu equipo, por lo que sean cuales fueran tus órdenes si el cliente está cabreado, transmítele tu enfado al equipo, si puede ser vía terceras personas o "perros guardianes", esa administración fascista asegurará que el nivel de stress se mantiene alto en todo momento.

6.- Si pese a todo, algo sale bien, limítate a mandar un correo de felicitaciones, un premio como una compensación de horas tiraría por tierra todos tus esfuerzos por mantener la tensión.

Esto te asegurará el más rotundo y absoluto fracaso y si no lo consigues no te preocupes, las cosas no siempre salen a la primera, estudia que es lo que ha salido bien y piensa como lo podrías empeorar, no hay que darse nunca por vencido.