softwarearquitecto.com

No se pierdan el próximo mes la edición dedicada a mi de la revista Rolling Stone.

Excelente noticia, ya abrió la tienda en línea de Apple en México.

www.apple.com/mexicostore

Por lo que veo, está el catálogo completo de productos, los precios no son tan altos y casi todo tiene envío gratuito !!

Ya no mas andar buscando en los CompuDabos o en el Palacio las cosas durante meses para ver cuando ‘les llegan’.

Acabo de armar un par de maquinas virtuales de Windows 2003 Server para una prueba de concepto de Microsoft Operations Manager. Una máquina es un Domain Controller de Active Directory y la otra es un miembro del dominio.

Además de que la instalación de ambas fué bastante veloz, gracias a Parallels, no puedo dejar de admirarme del poder de mi MacBook Pro. Puedo usar sin sufrir de lentitud notable ambas maquinas virtuales y el Mac OS X. Digo, no estoy ejecutando aplicaciones super intensivas en memoria o procesador, pero definitivamente nunca habia tenido una computadora portatil en la que pudiera estar ejecutando un ambiente de este tipo sin que la máquina acabara arrastrándose.

Yo no soy muy partidario de los programas de certificación para desarrolladores, pero en esta ocasión me temo que haré una excepción.

Por fin, un programa de certificación de software que vale la pena.

Esto es tan cierto que da miedo:

Manufacturing is a popular metaphor for software development. One inference from this metaphor: highly skilled engineers design; less skilled laborers assemble the products. This metaphor has messed up a lot of projects for one simple reason—software development is all design.

– Eric Evans

Yo nunca he visto una “fase de diseño detallado” que no consista en una total pérdida de tiempo y generacion de modelos UML que nunca serán usados.

El problema es que creemos que podemos llegar a un nivel de detalle en el diseño en donde los desarrolladores que son “higly skilled” pueden dejarle la “construcción” a los desarrolladores “less skilled” (Aka Code Monkeys) y eso es una creencia totalmente ridícula e ingenua.

Triste pero cierto.

Uno de los features de Windows Vista Ultimate Edition, que Microsoft entrega como parte del ‘bundle’ llamado Ultimate Extras es DreamScene, que básicamente te permite poner wallpapers animados en tu desktop.

Suena bien, con el pequeño detalle de que tienes que desembolsar nada mas y nada menos que $ 399 USD por una licencia de Windows Vista Ultimate Edition.

Sin embargo, en este tutorial te voy a enseñar como lograr lo mismo sin tener que comprar una licencia de Windows Vista Ultimate Edition!!

Los 3 sencillos pasos de este tutorial son los siguientes:

1. Cambia tu pc por una Mac (se obtienen mejores resultados con una MacBook Pro)

2. Ejecuta el siguiente comando en una ventana de Terminal de OS X (en una sola línea):

/System/Library/Frameworks/ScreenSaver.framework/
Resources/ScreenSaverEngine.app/Contents/MacOS/ScreenSaverEngine -background

3. Enjoy

Y listo!!

Para que necesita uno ‘Extras de regalo’ para algo que viene por default con el sistema operativo?

Hablando en serio, es un truco sencillo para hacer que tu screen saver actual se presente directamente en tu desktop. Para desactivarlo, simplemente invoca el screen saver como normalmente lo haces y el desktop regresará a la normalidad. Sólo funciona en Mac OS X, por si no se entendió el sarcasmo

Ya era hora de que alguien ofreciera una descarga de todas las herramientas de Sysinternals.

Definitivamente, la mejor computadora para instalar Windows Vista es esta:

Acabo de instalar Windows Vista Ultimate Edition usando BootCamp en mi MacBook Pro (Core 2 Duo) y es impresionante. La pura instalación completa del sistema operativo no llevó mas de 40 minutos y la gran mayoría de los drivers del hardware fueron automáticamente reconocidos e instalados.

Por supuesto que obtuve todita la parte de Aero, incluyendo Glass y las animaciones de la interfaz de usuario.

Ahora sólo me falta probar si Parallels para Mac puede levantar la imágen de la partición de Windows estando dentro de OS X para no tener que estar reiniciando la máquina.

Mac OS X Tiger + XUbuntu + Apache + Php5 + MySQL + Wordpress 2.1 + TextMate + MarsEdit + YummyFTP + Fantastico

Son en resúmen todas las tecnologías con las que me tuve que pelear para poder postear esto.

Cuando pensabas que lo sencillo no podìa ser mas complicado…

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.