Mucho se habla de gestión de riesgos, ya sea en metodologías ágiles como en, cof cof, waterfall, y claro, mucho se colocan tablas y con una mayor o menor pericia se indican los impactos y probabilidades respectivas, hasta ahí "lo normal".

Lo usual es que por lo usual los criterios de experiencia que se toman están basados en el tipo de proyecto: ERP, almacén, web o desktop o también en el grado de complejidad del negocio, estado de las relaciones con el cliente, primera vez, time to market etc, nada fuera de lo habitual.

El problema es que muchas veces la visión "de negocio" logra opacar al criterio técnico en un factor muy importante: no todas las tecnologías tienen igual riesgo, y no, no me refiero al hecho de que por ejemplo un consultor de SAP cobre mas que un diseñador gráfico (llevándolo a extremos), sino que las diversas tecnologías tienen diferentes niveles de disponibilidad de recursos de aprendizaje, lo cual quieras que no, impacta en las previsiones que se requieren tomar para un proyecto.

En algunos casos es evidente que hay muchos mas recursos (ojo, en este blog nunca hablamos de personas como "recursos", ¿ok?) para SQL Server y Oracle que para Informix o Sybase, por lo cual el tiempo en que un equipo puede llegar a ser productivo en un proyecto con estas dos tecnologías "raras" es mayor, pero mal que bien se puede solventar con la experiencia previa en otros motores de base de datos, así que tenemos un riesgo ligeramente mayor, pero justificable.

Visto a este contexto debemos pasar a un diferente tipo de escenario, los frameworks o soluciones "listas para usar", productos que se espera que puedan ser usados directamente por un usuario final, "casi" sin necesidad de desarrollo, pero claro eventualmente terminan pidiendose personalizaciones y como la aplicación tiene una API en un lenguaje "conocido" como PHP, C# o Java pues se empieza el desarrollo tomando los mismo criterios que cualquier otro proyecto a medida y .. ahi empiezan los problemas.

En concreto estas aplicaciones (concretamente los CMS que son con los que he tenido experiencia) presentan dos problemas que los hacen "bestias" diferentes a cualquier desarrollo a medida:

1. Esfuerzo extra para configurar los entornos, tanto de desarrollo, como de producción, en el caso de SharePoint por ejemplo era muy complicado, tan así que no se podía trabajar contra un servidor compartido sino que cada desarrollador debía de tener una Maquina Virtual para tener un entorno de trabajo, todo lo cual involucraba un esfuerzo que no era trivial.
2. Cambio de paradigma respecto a como desarrollar y/o depurar, pues aquí no eres tu desarrollando una aplicación, estas intentando construir algo sobre los cimientos que alguien mas hizo, y que le puso reglas que pueden ser no usuales (y sobre todo contraintuitivas), pero necesarias para que el producto funcione, lo cual deriva en una necesidad de conocimiento (y tiempo de aprendizaje) mas allá de cuan experto uno crea ser en el lenguaje en cuestión.

Queda claro que estos dos factores tienen alta probabilidad de incidir sobre el tiempo que le puede tomar al equipo implementar la solución, por lo que seria un grave error asumir proyecciones sin tomar en cuenta el esfuerzo extra mencionado, si, es difícil acometer estas cosas que nos dejan productos como Magnolia, Vignette, o SharePoint, pero al final son retos técnicos que terminan siendo superados, a menos claro que la dirección asuma que ".net es .net" y no tome en cuenta detalles como estos en sus proyecciones, ahora que si a estas dos cosas, se le suma la poca experiencia local, o poca documentación actualizada en foros, asumimos grandes riesgos que no podemos dejar de informar de antemano, y créanme, en el caso de CMS (salvo que tengas miembros del equipo que actúen como pilares del resto) siempre pasa algo de lo mencionado, por lo que debemos estar alertas, regresando al titulo de este post, no todo tiene igual riesgo (técnico).

Antes cuando desarrollabas SW y se te planteaba el versionar tu código fuente algunos no tenían idea de lo que se hablaba, y en el otro extremo solo había dos opciones ampliamente usadas: SourceSafe y CVS, aparte claro de opciones chapuceras como: diskettes, carpetas fechadas compartidas y USB.

Ahora mucha agua ha corrido bajo los puentes, así que el que no versiona SW es porque ha vivido aislado de la realidad, o porque de alguna manera no ve la justificación económica de ello (hace poco me comentaron que una entidad crediticia sigue manejando sus desarrollos con carpetas fechadas y comprimidas y recién iban a analizar la viabilidad de usar SVN), por lo que el problema en estos momentos es decidir que repositorio usar y las implicancias de su decisión.

En este momento me pueden decir "¡Pero tu usas TFS, ya no tienes que decidir!", pues la verdad que no, hasta el 2010 no había que tomar muchas decisiones, pero en el momento actual también toca decidir como es que vamos a usar TFS, entonces.. vamos a ello, repasemos el escenario.

En este momento al crear un proyecto en TFS/VSO tenemos dos opciones de mecanismo de control de versiones:
 

TFVC: El mecanismo tradicional de TFS de toda la vida, heredando terminología de SourceSafe como "check-in" "check-out", pero mucho mas potente, todo almacenado en SQL Server, permitiendo gestión de branches y merges, aparte claro esta de la integración de tus changesets con una actividad determinada. Su modelo es Centralizado al igual que Subversión por ejemplo, con todas las implicancias que eso trae, que no vamos a discutir ahora.

Lo curioso es que si optamos por usar esta modalidad hay que tener en cuenta un detalle adicional: el tipo de Workspace ya que hasta TFS 2010 solo había el workspace en servidor, vale decir que el servidor de TFS llevaba un seguimiento de cual es el estado de cada una de las maquinas que se conectaban al repositorio, lo cual debemos reconocer no funcionaba muy bien, llegando al extremo de que en algún momento el usuario sabia que no estaba sincronizado, pero el servidor insistía en que no tu workspace esta bien, y arreglar eso, complicado.

Con los workspace locales, esos problemas ya no existen, aparte de que proveen una mayor flexibilidad para trabajar sin problemas cuando el servidor esta desconectado, pero de eso nos cuenta con mas detalle El Bruno, solo debo añadir que si se opta por TFVC solo hay un escenario en el cual tendría sentido usar workspace en el servidor: cuando tu IDE aun es VS 2010 o anterior, en cualquier caso es workspace locales, ahh la decisión se hace en el IDE no en el servidor.


Git: ya hemos hablado anteriormente de este recién llegado a las plataformas Microsoft, y creo sinceramente que debemos probarlo, intentar usarlo en nuestros proyectos, pues los DVCS han llegado para quedarse y Git ya es casi el estandar de facto, proveyendo muchas ventajas; dicho esto debemos ser conscientes que a la fecha (si alguien lee esto 2 años despues puede que se ria), si bien Microsoft ha integrado totalmente el "protocolo" backend de Git en sus productos aun no ha terminado de pulirlo en cuanto a interfaz (quiero creer que la próxima versión de VS tendrá una interfaz para Git que rivalice con SourceTree) y que de momento no podemos usar una herramienta tan potente como los Code Review integrados, a los cuales me acostumbre rápidamente cuando use por primera vez TFS 2012, ni tampoco los Gated Check in a la hora de hacer Integración continua (en breve: esta modalidad permite que un cambio no se añade al repositorio si la Build falla).

Conclusión: si no tienes una demanda muy fuerte de hacer uso de CodeReview o Gated Check In, usa Git, pero de la mano ve aprendiendo los comandos aun no disponibles desde el IDE, pues seran necesarios para sacarle el jugo. En otro caso (el Code Review si que puede ser un deal breaker en muchos casos) no temer y usar los workspace locales con TFVC.

A ver cual es la situación de aquí a un año, probablemente nuestro flujo cambie para entonces.

Durante el año pasado tuve la oportunidad de ser revisor de el libro de Marcus Hammarberg y Joakim Sundén: Kanban in Action.

Fue una gran oportunidad el poder ver los borradores del libro, y desde el inicio me engancho con su enfoque, un primer capitulo destinado a demostrar como es posible (mediante la ayuda del equipo ficticio Kanbaneros), partiendo de la situación actual, implementar un flujo de Kanban en tu organización o proyecto de manera sencilla.

El resto del libro nos ayuda a ir comprendiendo la teoría detrás de Kanban (metricas, clases de servicio, planificación, etc), el porque es bueno tener controlado el Work In Process, recomendaciones y alternativas para cuando nos encontremos con situaciones particulares (una emergencia que debe ser solucionada de inmediato, por ejemplo), de una manera muy clara. Para lograr esto en todo momento los diversos Kanbaneros aparecerán con preguntas y conversaciones para clarificar los puntos.

Definitivamente recomiendo la lectura de este libro, pues como digo en mi comentario en la contraportada es "A practical way to start with kanban … and learn the theory along the way", lo unico que lamento del libro es que al final no se incluyo el capitulo de Scrumban o el detenerse un poco mas en utilizar Kanban en procesos iterativos como.. si.. Scrum.

Pues nada, si quieren tener una buena introducción a como empezar a usar Kanban les recomiendo leer el capitulo 1. Ademas nuestros amigos de Manning nos estan regalando el capitulo 13, con diversos juegos para aprender Kanban de manera divertida.

Desde hace dos semanas ha causado cierto revuelo en las comunidades de desarrollo este articulo de David Heinemeier Hansson, creador de Ruby on Rails, donde básicamente apunta que él seguirá usando Unit Test pero que TDD (entendido como programar los tests antes de codificar) ya esta muerto y que no tiene beneficios, de ahi me quedo con esta porción:

The current fanatical TDD experience leads to a primary focus on the unit tests, because those are the tests capable of driving the code design (the original justification for test-first).
I don't think that's healthy. Test-first units leads to an overly complex web of intermediary objects and indirection in order to avoid doing anything that's "slow". Like hitting the database. Or file IO. Or going through the browser to test the whole system. It's given birth to some truly horrendous monstrosities of architecture. A dense jungle of service objects, command patterns, and worse.

Y si, se podría decir que había mucho de fanatismo en esto, expresiones como "código legado es código sin tests", "WebForms es malo pues pues no deja testear", "elabora una arquitectura evolutiva basada en tus tests" y similares estaban a la orden del día en blogs y conferencias, de hecho cuando publique este post sobre si los nuevos patrones (inducidos por TDD) ayudaban o no a la legibilidad del código un guru dijo que yo había "missed the point".

No se me entienda mal, yo creo que los tests son necesarios y salvadores de tiempo... en algunas circunstancias, por ejemplo hace un tiempo vi a un QA probar una aplicación que calculaba ciertos valores, para hacer esto iba a su Excel, copiaba los parámetros en la aplicación, y si la aplicación devolvía el valor esperado que estaba anotado en el Excel, estaba Ok, y claro, como es usual si la aplicación era actualizada, estos tests deberían ejecutarse de nuevo para verificar que no hubiera una regresión, este es un caso muy evidente como batería de Unit Test con diversas combinaciones de valores ayudaría a reducir los tiempos de prueba, garantizando la calidad de la aplicación en cuestión, como siempre digo, ¡si en una aplicación de cálculos matemáticos o financieros no le metes Unit Test no te puedes fiar de la calidad para nada!.

Personalmente creo que en este caso opero mucho el "principio de autoridad", eran pocas las voces quienes cuestionaban de que el modelo de TDD (y la compleja arquitectura a la que podria derivar) sea totalmente valido, y era necesario que alguien con cierto peso dijera "el emperador esta desnudo".

Como era de esperar, algunas respetadas voces han respondido al manifiesto de DHH, destacando Robert Martin con este articulo, y luego un debate online entre DHH, muy interesante.



Creo que el debate continuara un buen rato, pero lo bueno es que ha permitido que quienes teníamos reparos al fundamentalismo del TDD podamos salir de nuestros agujeros sin ser abucheados.

Cuando trabajamos en despliegue de proyectos de desarrollo, y aun no hemos pasado a procesos de Integración Continua en algún momento tenemos a escuchar la frase "en mi maquina funciona" cuando se apunta que no se puede desplegar la aplicación o que estando desplegada no funciona como se esperaba.

Como indico en el titulo el que esa expresión aflora es un síntoma de que algo no esta bien dentro del ciclo de vida de la aplicación, lo mas sencillo podría ser suponer que no hay proceso de Integración y Entrega Continua, y en ese caso la alerta nos debería empujar a organizar uno (de eso trataremos en futuras entregas), no hay vuelta que darle, el tiempo que pierdes en hacer despliegues manuales es desperdicio y sujeto a grave riesgo de errores de los que "en mi maquina funciona" puede ser el menor de ellos (imagínate hacer que la aplicación grabe en la BD de otro entorno).

El problema mas serio es cuando habiendo esos procesos aun se escuche esa justificación, en este caso debemos plantearnos las siguientes preguntas:

• ¿Los miembros del equipo son conscientes (o han sido educados) de la necesidad de contribuir frecuentemente código sano? No es raro que algo que compile en local falle en IC porque algún fuente no se subió.
• ¿Se tiene una estructura que efectivamente permita hacer un despliegue de todo lo ultimo con un clic?
• ¿La cobertura de pruebas unitarias es razonable?
• ¿Hay una cultura (a falta de mejor nombre) de revisar y entender los logs cuando ocurre un problema en el servidor de Integración Continua?

Estas preguntas y otras que vayan surgiendo tienen que caer de alguna forma en las retrospectivas del equipo para alcanzar el grado de madurez que nos permita hacer unos despliegues exitosos y sin dolor; y claro, recordar que si bien la tecnología nos ayuda a automatizar nuestros procesos el factor humano es indispensable para que el ciclo funcione adecuadamente.