Las 10 (ó 9) dimensiones

ó la versión reducida de supercuerdas.

Honores de la traducción MalaCiencia, el original Aquí

Seguramente el lector esta acostumbrado ha ver su mundo bajo el concepto de alto, largo y ancho, es decir, 3 dimensiones.
Sin embargo algunos cientificos se dan a la tarea complicarnos un poco más la existencia ó tratar de explicar lo complicado de esta.
Para este ejemplo necesitamos que el lector piense en un punto (.), si un punto, el cual no tiene ningúna dimension (no es de un alto, ancho o profundidad medible) en si un absoluto.
Suponga el lector que existe el mundo ó mejor dicho la dimensión punto donde sus habitantes solamente pueden estar donde estan, es decir, sin pueder moverse.
Ahora imagine una dimensión igual y trace una línea entre ambos punto, ahora tenemos una dimensión y los habitantes de los puntos pueden mover para atras y hacia adelante.
Repita el procedimiento con 2 puntos totalmente diferentes y cuya linea cruce la que ya estaba hecha anteriormente, acaba de crear la segunda dimensión y sus habitantes tienen largo y alto, y pueden moverse de arriba a bajo y adelante y atras.
Por supuesto la gente de los puntos a un existe y cualquiera puede viajar no solo en su línea sino en la línea que los cruza en el punto de intercepción aunque no pueden ver a las personas que viven en la segunda dimensión.
Ahora ¿Que pasa si alguien en punto desea viajar a otro sin tener que pasar por el punto de intercepción?, Sencillo, si han estado dibujando este ejercicio ahora escojan 2 puntos y doblen la hoja, ahora nuestro amigo puede viajar a donde desea gracias a nuestro pliege (lo cual también aplicaría si lo hicieramos para las lineas o nuestra 2da dimensión), pero también abremos creado profundidad entre las 2 dimensiones por lo cual acabamos de generar una 3ra dimension.
Obviamente aquí habitan seres de 3 dimensiones (gente como nosotros), ok, hasta aquí sabemos de tenemos puntos conectados y que estos puden plegarse para generar varias dimensiones, correcto, Ahora conviertan estas 3 dimensiones en un punto, (si de aquí deriva la deducción ó el truco llamenlo como deseen).
Al igual que al principio solamente estaríamos presentes sin poder movermos algo así como la pintura de un paisaje se ven los arboles que estan cercas y las montañas a lo lejos pero nada se mueve. Al igual que al principio crearemos otro punto y los uniremos con otra línea, ahora nuestros objetos tienen movimiento gracias a nuestra 4ta dimensión, el tiempo.
La 5ta dimension se aplica como lo que se vió en Volver al futuro 2 (:Publicidad subliminal: Disponible en BlockBoster :/Publicidad subliminal:) donde Martín y el Doc se encuentran atrapados en un presente diferente del que vinieron pero real para todo el mundo debido a que el malo del futuro se entrega a si mismo (malo del pasado) información para volverse millonario (el malo del presente). En la representación que hizo el Doc ellos habian ido al futuro desde su realidad atraves de su línea de tiempo y al regresar al presente callerón en esta la línea del tiempo.
Estas lineas del tiempo serían las que hicimos cuando creamos la 2da dimension (esta sería la 5ta dimensión) he igualmente si el Doc y Martin desean regresar a su linea deben pasar por donde se cruzan las líneas ó encontrar un punto donde se pliegue las líneas o los puntos en el tiempo y saltar a su linea (lo cual nos daría la 6ta dimensión).
Ok, que tenemos hasta ahora mundos de 3 dimensiones con su propia historia, desiciones y sucesos que pueden estar unidos en diferentes puntos gracias a los cruces entre las líneas y los pliegues que hagamos. Muy bien parece que hemos cubierto todo, correcto, pero la verdad es que todas estas líneas tiene un punto de creación común.
Pero supongan que existierón diferentes creaciones y cada una con sus diferencias así que cada una de estas diferentes creaciones son puntos y que podemos viajar a estos universos atraves de una línea (7ma dimensión) y que estas líneas a su vez se cruzan en algún punto (8va dimensión) ó que se tuerce la dimensión para saltar entre universos y dimensiones (9va) y que todo esto es un punto (10ma)
De acuerdo, podemos continuar, pues, aparentemente no; ¿por que no podemos hacer otro punto y otra línea?, yo pregunto ¿como? ya abarcamos todo lo que es posible, diferentes mundos, diferentes tiempos, diferentes creaciones y universos no es posible avanzar más pero segun supercuerdas aún no llegamos a las 23 dimensiones posibles. Para la programación es facil, solo debemos hacer un int[a][b][c][d][e]...n; Expliquen esto en primer semestre el primer día que vean arreglos en programación y fijense cuantos descertan xD.

Scrum (Estilos de programación)

He agregado descripción al principio para evitar que pensasen que habla de comida europea (struddent ó como sea que se escriba). Por cierto es Copy-Paste de un correo.

Agile = More Work

Agil.

Que bonito suena. Sólo de escuchar esa palabra siente uno la suave brisa en el rostro y el radiante sol bronceando nuestra piel al mismo tiempo que el canto de los pajaritos nos anuncian la llegada de la libertad.

"ah!!, que a todo dar.. nada de documentación, nada de UML o diseño, ya no haríamos planes, no hacer estimación!...sin juntas de avance, directo a programar!... hay que adoptar eso en la empresa!!"

Sabemos que ni de chiste nuestros clientes ó directores nos dejarían trabajar de esa forma. Pero lo que nos intriga es que hemos escuchado que existen equipos de desarrollo que trabajan así. ¡Suertudos!. Sin UML, sin diagramas de casos de uso, piñas coladas junto al teclado, sandalias y pantaloncillos cortos, sin el líder de proyecto encima con su fastidioso '¿como vamos?' cada día. Llegar a trabajar a las 11 y salir a las 4. Después de todo no hay deadline. Las cosas saldrán cuando tengan que salir, que no presionen.

El problema, por supuesto, es que todas esas son nociones totalmente equivocadas de lo que es trabajar siguiendo una disciplina ágil.

Cualquiera que crea que el desarrollo ágil es más conveniente para los programadores que para los managers, esta un poco equivocado. Mucha gente que practica este tipo de disciplinas han descubierto que:

es mucho mas arduo el trabajo diario para los programadores cuando sigues una disciplina ágil

y que, por el contrario, las ventajas que ganan los clientes y stakeholders son enormes. Como lo dice Tim Ottinger de Object Mentor:

I remember when I first started reading about eXtreme Programming. The theory then was that it was going to make programmers happy, but that management would never go for it. Now we find that the argument is that it's great for managements, but that it is harder for programmers? Why the 180-degree turn? Have we sold it more successfully to managers than to programmers?

¿Sorprendente?

En IT Conversations hay una sesión muy interesante con Ken Schwaber (creador de Scrum) en donde explica la razón de este fenómeno.

Ken describe cómo el ejecutar un proyecto con Scrum requiere completa entrega de cada uno de los desarrolladores en cada uno de los días del proyecto. Llevar Scrum es bastante más difícil e intenso que hacer software 'de la manera clásica'. Requiere un compromiso especial y total de cada uno de los integrantes del equipo.

Por lo mismo, una de las principales dificultades para adoptar Scrum, ó cualquier otra disciplina ágil, es que no todo mundo está dispuesto asumir ese tipo de compromiso. Todos seguramente conocemos algún developer que suele pasar días haciéndo como que trabaja y luego poner pretextos para justificar que no ha avanzado. Nuestra cultura ha permitido que ese tipo de personas puedan pasar años y años en un puesto de desarrollo sin mucha dificultad. En particular, escuché de un equipo que después de adoptar Scrum, instituyeron el 'Wally Award', en honor del personaje de Dilbert, premio que es asignado por todo el equipo al mas flojo de los desarrolladores después de la junta scrum diaria. Esa es presión que no todo mundo soporta.

En un equipo que sigue un modelo ágil todos están expuestos permanentemente a una visibilidad mucho mas grande. Las cosas son mas 'transparentes'. El avance (o la falta de) es mas evidente.

"No es cierto, en mi empresa el líder de proyecto checa diario los avances con cada uno. No se necesita Scrum para eso"

Ok. Hay una enorme diferencia entre tener a un project manager revisando el avance todos los días y llevar una disciplina como Scrum. De hecho, cualquiera que conozca Scrum sabe que la manera de ejecutar la planeación y revisión de avances es casi el 90% de lo que la 'metodología' te especifica.

Como lo describe Ken Schwaber, la forma de trabajar de Scrum tiene como objetivo eliminar tres grandes errores de la disciplina 'tradicional' de administración de proyectos de software:

1. Asignar trabajo en forma de tareas es mala idea

El project managemente 'tradicional' consiste en asignar tareas a los desarrolladores, muchas veces una larga secuencia de ellas, y en ir revisando que las ejecuten en el tiempo y secuencia establecidos por el plan.

Mala idea

Por mas empeño que le ponga el project manager a especificar "cada una de las tareas necesarias", siempre ocurre, tarde o temprano, que el programador se va a encontrar con que faltan y sobran tareas.

¿Cuantas veces no nos han asignado una serie de tareas que luce mas o menos así?:

• Tarea T00341: 2 horas, Elaborar diseño de clases de negocio de caso de uso de cargo a cuenta
• Tarea T00342: 1 hora, Construir alta de registro de caso de uso de cargo a cuenta
• Tarea T00343: 2 horas, Construir eliminación de registro de de caso de uso de cargo a cuenta
• Tarea T00344: 2 horas, Construir busqueda de registro de de caso de uso de cargo a cuenta
• Tarea T00345: 1 hora, Construir modificación de registro de de caso de uso de cargo a cuenta
• Tarea T00346: 1 hora, Construir componente de interfaz de usuario de caso de uso de cargo a cuenta
• Tarea T00347: 2 horas, Construir elemento de menu de caso de uso de cargo a cuenta
• Tarea T00348: 4 horas, Pruebas del componente de caso de uso de cargo a cuenta

ARGGHHH!! además de que simplemente mirar el plan de trabajo hace mas daño a los ojos que el salir a ver el sol directamente por un par de minutos, en cuanto el programador descubre que para hacer el cargo a una cuenta se necesita, no se, digamos, un método que sabe redondear los montos de acuerdo a reglas del negocio complejas y que nadie conoce, entonces surge desde las mas profundas entrañas del infierno un mounstro por todos temido conocido por los eruditos en temas macabros como 'la tarea no planeada'.

Este engendro de satanás, la 'tarea no planeada', representa con su malevola existencia un retraso al plan de trabajo que desestabiliza todo el proyecto y que causa miradas de odio contra el programador que la descubrió por 'poner trabas' al avance. En el caso de que el valiente y temerario project manager se decida a enfrentarla, la 'tarea no planeada' le abriá nuevamente aquella úlcera que creía olvidada por el simple hecho de obligarlo a abrir de nuevo el archivo de Microsoft Project que le llevó 4 noches enteras ajustar a la fecha de entrega prometida y que ahora tendrá que modificar con el mismo cuidado (posiblemente con y los mismos resultados) que implicaría retirar el 3 de diamantes de la base de un castillo hecho con naipes.

En la mayoría de los casos, sin embargo, la 'tarea no planeada' es ignorada por todos con la esperanza de que, empujada por el rechazo e indiferencia, vuelva despúes de un rato a arrastrarse de vuelta hacia las entrañas del averno, dejando tranquilos al equipo y a su plan de trabajo, que después de todo ya había sido 'bendecido' por 'el ser supremo', y eso es signo de perfección.

Además de la infame 'tarea no planeada', el programador se va a encontrar como muchas tareas que si fuéron planeadas, pero que son tareas inútiles, duplicadas y sin sentido. Pero, ah!, cuidado con que caiga en la casi herética desobediencia de no reportar avances sobre ellas por que todos sabemos lo que puede pasar si hacemos la observación de que 'esa tarea no aplica' (para el que no esté acostumbrado a la jerga del profesional de sistemas, el término 'esa tarea no aplica' es en muchos lugares el término técnico para 'yo soy un holgazán que no quiero trabajar y el project manager es un imbecil y su virilidad y ética profesional son de bastante dudosa naturaleza').

Scrum, por el contrario, está diseñado a partir de un pequeño conjunto de aventuradas premisas (que tal vez en algún futuro algún grupo de iluminados científicos podrán comprobar o refutar):

• Que desarrollar software es un poquito más complejo que poner ladrillos en una construcción.
• Que los programadores tienen habilidades de análisis y solución de problemas un poco mas elevadas que las de un obrero de línea de ensamblaje de una fábrica.
• Que un equipo de desarrollo está formado por profesionales (aqui es desgraciadamente donde luego se viene todo abajo, pero eso es otro tema).
• Que los profesionales de cualquier ramo son los más indicados para determinar cómo hacer su trabajo para llegar a los resultados .

Obviamente lo de 'premisas aventuradas' es sarcasmo. En fin, el punto es que:

La asignación de trabajo basada en tareas no funciona.

Es como ir con el mecánico a que repare tu auto y en vez de pedirle que 'cambie el aceite', decirle 'mira, primero levantas el auto con el gato hidráulico, luego tienes que usar una llave inglesa para quitar la tuerca del depósito, luego vas por una cubeta y dejas que salga el aceite que actualmente está en el motor, etc. etc.'.

Suena ridículo, pero si sabemos que es estúpido querer dar a cualquier profesional (incluso a un mecánico de autos, que se pudiera calificar como un oficio no profesional) una lista detallada de tareas que le digan cómo hacer su trabajo ¿por que demonios queremos que eso suceda en el desarrollo de software?

El más indicado para determinar que tareas realizar en una actividad compleja es el experto. El profesional. Sobre todo porque en cualquier actividad compleja (creo que es evidente que el desarrollo de software es una de las tareas mas complejas que existen) hay incertidumbre. El experto es quién mejor puede decidir cuáles son las tareas necesarias cuando se encuentra con un problema durante la ejecución.

En vez de usar 'tareas', Scrum asigna trabajo en forma de elementos que representan entregables con valor funcional para el cliente. Por ejemplo, en vez de la lista de tareas detalladas, tendríamos algo como:

"Un comercio puede hacer un cargo a la cuenta del cliente a través del sistema"

El equipo tendrá que decidir si puede o no estimar esa funcionalidad (tal vez es de muy alto nivel y se necesita descomponer en fragmentos de funcionalidad mas pequeños para poder estimarla), decidir si es posible terminarla para la próxima iteración, investigar los detalles de cómo debe funcionar, organizarse para trabajar en ella y asegurarse de que funciona correctamente. El equipo tiene que determinar cómo y cuándo ejecutar cada una de estas actividades. Todo como profesionales que saben entregar resultados y lograr objetivos de beneficio para el cliente.

Por eso trabajar al estilo 'Agile' significa más trabajo para el desarrollador, pues esto impone un grado de responsabilidad mayor sobre todos los integrantes del equipo. Nadie puede cómodamente sentarse en su cubículo el día entero y limitarse a cumpilr una tras otra con las tareas asignadas por su project manager.

El segundo error que Scrum busca eliminar es:

2. Revisar el avance de cada programador por un supervisor y de forma aislada es mala idea

En un projecto 'tradicional' de desarrollo de software, cada programador ya tiene una lista de tareas asignada. En el caso típico de revisión de avances, tenemos el siguiente escenario entre el project manager (PM) y el desarrollador (DEV):

El PM se acerca sigilosamente al programador con una impresión del archivo de Project en la mano.

PM: Que onda, ¿cómo vamos con lo de cargo a cuentas?

El DEV siente el frio correr por su espalda y piensa para si mismo mientras sigue tecleando simulando estar muy concentrado para contestar:

"vamos?? me suena a muchos!! como voy, querras decir, maldito! ¿a ver, pues enseñame tú que has hecho, digo, además de este adefesio de plan de trabajo?!"

pero finalmente contesta:

DEV: "ehh.. ahh.. lo de cargo a cuentas... ehh.. si.., ya prácticamente está listo. ya nomas faltan unas cosillas"

DEV: (terminarlo y que funcione), piensa.

PM: Acuerdate que de acuerdo al plan eso tenía que estar para ayer. Nos estamos retrasando.

DEV: Ehh... ahh.. eh.. si. Es que tuve que hacer la parte del guardado de la configuración.

PM: Hmmm.. Ok.

DEV: ...

PM: Oye, ¿Configuración para qué??

DEV: Pues para lo del combito del catalogo de cuentas.

PM: Hmmm.. ok.. si, ya entendí.. Oye, pero si eso ya estaba, no?, es la tarea T004355, aqui lo tengo en el plan como terminado.

DEV: Pero es que el componente que había lee la configuración de una base de datos, yo tuve que hacer un componente que guardara la configuración en un XML pues del lado del cliente no hay base de datos.

PM: Pero eso lo tenía que haber hecho el que hizo el componente de configuración. Se supone que la tarea del componente de configuración ya esta 100% terminada.

DEV: Es que le pregunté si ya lo había hecho, pero me dijo que no sabía que tenía que haber soporte para XML en el componente de configuración.

PM: Bueno, ¿pero por que te tomó tanto tiempo si ya casi estaba?. ¿Nada mas necesitabas hacer copy-paste del código del otro componente, no?

DEV: ¿copy-paste de ASP a C++ ?

PM: Pues si, no?

DEV: no.

PM: Ok. Hmm.. Hijole.., es que esto 'ya nos esta pegando en los tiempos'

DEV: piensa: (pues si, y? ...que quieres que yo haga?)

PM: En que te puedo echar la mano? Pasame el código para ver en que te puedo ayudar.

DEV: piensa: (Ni lo intentes, desgraciado. Alejate de mi código)

DEV: No, gracias, ahorita en nada, ya casi está.

PM: Orale. Ahi cualquier cosa me dices. ¿Si crees poder empezar hoy con la tarea T0043829 ? Esa tenía que estar para hoy. Es que si no si 'se nos mueve' todo el plan.

DEV: Ok... si.. Deja veo. Yo creo que si, esto ya casi queda.

PM: Sale. No se te olvide reportar tus horas.

Este escenario muestra los problemas típicos de este tipo de seguimiento al avance:

• Falta de comunicación entre el equipo. Pueden pasar semanas enteras sin que un programador se entere de lo que están haciendo los demás.
• Falta de flexibilidad para resolver problemas conforme se van descubriendo.
• Falta de conocimiento de quién elabora el plan de trabajo acerca de cómo deben hacerse las cosas (puede no ser el caso general, pero es frecuente).

En Scrum, el avance no lo evalúa el project manager. Sino todo el equipo de desarrollo. Todos juntos. Todos los días.

Es mas. En Scrum el project management lo lleva el equipo de desarrollo.

El rol de Scrum Master (lo mas parecido a un project manager que tiene Scrum) se encarga de facilitar al equipo de desarrollo las condiciones propicias para que puedan trabajar. Pero no lleva la administración del proyecto como tradicionalmente se conoce.

La forma en que el avance se planea y se evalúa (sprint planning, daily scrum meetings, sprint review) es simple, pero no es sencilla. Es decir, aunque las reglas son pocas y simples, se requiere de mucha participación e interés de cada uno de los miembros del equipo para hacerlo bien.

¿La ventaja? el equipo es quién decide qué se debe hacer y cómo. Y cuándo cambiar esa decisión.

No 'alguien' desde 'arriba'.

Por último, pero a mi parecer el error mas importante que Scrum busca eliminar:

3. Que la secuencia de tareas no refleje las prioridades del negocio es mala idea

Tradicionalmente, es común que las tareas de un 'plan de trabajo' (entiéndase diargrama de Gantt de Microsoft Project) se acomodan de acuerdo a las dependencias entre componentes de infraestructura del producto, y no necesariamente de acuerdo a la prioridad de la funcionalidad del negocio.

Esta claro que si uno pone el cuidado suficiente, se puede lograr un Gantt que tenga las tareas prioritarias para el negocio al inicio. Sin embargo inevitablemente el pensar en 'tareas' llevan al equipo a pensar en desarrollo de componentes primero y funcionalidad en segundo término. Por ejemplo, es típico que la primer tarea de construcción en un proyecto tenga que ver con algo relacionado al 'framework de acceso a datos' o 'framework de aplicación'. Después de todo, los demás componentes dependen de esas piezas, no?

Pues si, totalmente cierto. Pero ese es uno de los motivos por el cual 3 meses ya entrados en el proyecto todavía no tengamos nada que mostrarle al cliente. Y seamos sinceros, de todos modos siempre tenemos que regresar a hacer 'ajustes' al 'framework' una vez que iniciamos la construcción de componentes 'funcionales', pues es muy dificil predecir exactamente cómo quieres que se comporte tu framework si no sabes aún como son los componentes que lo van a utilizar.

¿Quiere esto decir que Scrum te indica que hagas primero las 'capas de arriba' y luego 'las de abajo'?

Claro que no. Scrum no te dice eso. Sería como si tu fueras un mecánico y Scrum te llevara su auto a que le cambies el aceite y te quisiera dar instrucciones detalladas de cómo acerlo.

Scrum sabe que eres un profesional y que sabes que necesitas hacer para entregar la unidad de trabajo asignada, que es un fragmento de funcionalidad útil para el cliente. Si eso significa que harás primero 'las capas de arriba' para luego ver como haces 'las capas de abajo', adelante. Si eso significa que vas a ir armando tu framework poco a poco al mismo tiempo que tus 'capas de arriba', adelante. Si quieres terminar totalmente el framework primero, adelante y suerte al negociar tus primeras iteraciones con el cliente en donde no vas a tener nada que mostrarle.

Y esta es la tercer razón por la que el trabajo en Scrum es mas dificil. El compromiso es entregar funcionalidad útil. No cantidades de líneas de código de infraestructura, que por si solas, no sirven para nada relevante.

Conclusión

¿Quieres trabajar usando una disciplina ágil como Scrum?

Entonces prepárate para trabajar más. No más tiempo. Sino con mayor intensidad. Más involucrado en el proyecto y sus metas, con más entrega, con mas responsabilidades. Preparate para trabajar duro.

¿Le quita esto el atractivo a las disciplinas ágiles? Claro que no.

Yo creo que es preferible estar en un equipo de desarrollo que se dedique a trabajar al 100% durante 8 horas todos los días y tener metas alcanzables, claras, compartidas, realistas, pensadas para lograr rápidamente beneficios para el cliente y que exigen de tu creatividad como profesional, que tener que trabajar 14 horas todos los días en una serie fija de tareas, concretas pero muchas veces mal planeadas, que no 'encajan', que te exigen muchos teclazos en vez de mucho talento como profesional del desarrollo de software.

Disclaimer

Como todas las herramientas, estoy totalmente conciente de que Scrum no es aplicable a cualquier situación (proyectos de outsorcing remoto/offshoring son especialmente dificiles de llevar con Scrum). Sin embargo lo interesante es que mucha gente piensa que disciplinas como Scrum sólo funcionan en proyectos 'sencillos'. Se cree que para proyectos 'complejos' tienes que empezar a usar técnicas mas 'tradicionales'.

Eso es totalmente falso. Al contrario. Si tu proyecto es realmente sencillo, tan sencillo que puedes preveer con anticipación exactamente como va a ocurrir todo, puedes contratar 'coders' y hacerlos seguir instrucciones precisas. En ese caso sigue usando tu archivo de Microsoft Project. Pero espero que tu proyecto sea realmente sencillo.