Bueno, ya son poco mas de 3 años usando Windows 7, así que como esencialmente me dedico a trabajar con tecnologías Microsoft el migrar a Windows 8 es un paso que eventualmente tendré que dar, por lo que faltando dos días para el vencimiento de la oferta decidí comprar el Windows 8 Pro a 40$, si no lo hiciste hasta el 31 de Enero, lastima, ahora toca desembolsar 160$.
Siendo que la disponibilidad del software ya no es un problema, toca hacer un planeamiento de los pasos necesarios antes de hacer la migración, saltando dos esencialmente:
- ¿Mi equipo actual aguantara Windows 8? Como comente la última vez (el 2009) que hice un gran cambio de hardware actualmente tengo la Asus P5E WS Pro, con un procesador Core2Duo de 2.13, siendo que a poco de regresar a Perú (si! Estoy usando la misma compu que tenía en España!) le puse 8GB de RAM en vez de los 4 que ya tenía. Oficialmente esta configuración sobrepasa los requisitos mínimos para la instalación de Windows 8 (*) por lo que no debería tener problemas, pero lamentablemente las pruebas de upgrade sobre Core2Duo se han hecho sobre chip de 2.6Ghz, por lo que los datos de performance no aplican totalmente para mi.
En ese sentido (con un procesador de mas de 6 años) se impone un upgrade de hardware, siendo la duda el si lo hare antes o después de instalar Windows 8, se supone que no debería haber diferencia, excepto a que no se si luego de cambiar la placa tendré que Activar Windows nuevamente, y de ser así, si estaré permitido de hacerlo o no, queda para la reflexión.
- En todo caso una duda que tenía desde que se anunciaron las primeras versiones de prueba de Windows 8 era sobre el destino del Windows XP Mode (en simple: una máquina Virtual de XP muy integrada con Windows 7), siendo que el soporte de Windows XP acaba el 2014 y que W8 retira a MS Virtual PC para adoptar la tecnología Hyper-V (existente desde Windows 2008 Server) Microsoft decidió descontinuar Windows XP Mode ofreciendo como única alternativa el poder recuperar los datos que hubiera en las Maquina Virtual existentes, y es aquí lo que me plantea el reto de tener algo listo para poder seguir corriendo mi Máquina Virtual y sus aplicaciones (y no solo acceder a sus archivos) cuando tenga Windows 8 instalado, y es en esto en lo que me enfocare en este post.
Repasemos el escenario, tengo un disco duro virtual VHD de 30GB Gigabytes+/-, el cual actualmente corre sin problemas en mi instalación de Virtual PC, este disco duro no podrá ser “levantado” por Hyper-V por lo que la alternativa es intentar correrlo en otro motor de virtualización, en mi caso particular he optado por VirtualBox, el cual debe instalarse previamente si es que no lo has hecho ya..

Al investigar en Internet me he enterado con dos problemas bloqueantes para lograr dicho propósito (que luego pude corroborar):
- Al intentar levantar el disco VHD desde Virtual Box se me informa que falta un disco maestro, upss
- Si de alguna manera se logra levantar la máquina virtual en Virtual Box, nomás iniciar sesión se requiere Activar la máquina virtual, esto debido a que ese Windows XP detecta que el BIOS de VirtualBox es diferente de Virtual PC, por lo que las alternativas en teoría son dos: usar una clave de Windows XP (hay una que viene con la instalación de XP Mode) para intentar la activación o hacer que la máquina virtual crea que el BIOS es el mismo, en concreto la única alternativa es la segunda, así que ni se esfuercen en intentarlo y vayamos a lo seguro, que es de lo que trata esta guía.

Advertencia: Llegados a este punto debo indicar que en algunos foros se comenta que bajo Windows 8 ya no tenemos la licencia para ejecutar XP Mode, que esta solo es válida bajo Windows 7, así que habrá que estar atentos a lo que diga Microsoft de manera oficial al respecto, pero en ese sentido lo que mas me preocupa es que para el 2014 ya se acaba oficialmente el ciclo de vida de Windows XP.
Como medida de seguridad es imprescindible copiar el archivo del disco duro virtual ( .vhd) a un lugar seguro por si por a o b algo nos sale mal; hecho esto nuestro primer paso es crear un nuevo disco duro virtual que si pueda ser levantado por VirtualBox, para lograr esto debemos iniciar nuestro XP Mode y una vez dentro instalar y ejecutar el Disk2VHD, este programa nos permitirá crear un disco duro virtual “sin problemas”, como se ve en el gráfico.

Nótese que el nuevo archivo lo estamos creando en una ruta \\tsclient\d\... que es la ruta mediante la cual podemos acceder desde nuestra maquina a los archivos y unidades alojados dentro de la maquina anfitriona (nuestro Windows 7) , en esta etapa sugeriría que antes de iniciar el proceso se desinstale los componentes de integración (Virtual PC Integration Components) pues harán algo complicado el proceso de inicio en su nuevo sistema anfitrión, en mi caso no lo hice aunque al final todo quedo bien como comentare luego.
Este proceso puede tomar como 20 minutos o mas, no hay problema, podemos esperar.
Ya con el nuevo disco duro virtual (oh sorpresa, pesa solo 15GB en comparacion de los 30 del original!) procedemos a crear la máquina virtual desde VirtualBox, nótese que debemos indicarle que vamos a hacer uso de un disco duro ya existente.

 IMPORTANTE: una vez creada la máquina virtual no iniciarla aun.

Bueno, ya tenemos la máquina virtual creada, ahora lo que toca es preparar nuestro VirtualBox para que provea a nuestra Maquina Virtual con un Bios compatible con Virtual PC, para esto debemos bajar este archivo, desempaquetarlo y ejecutar esto en una línea de comandos con privilegios administrativos:
VBoxManage.exe setextradata el-nombre-de-tu-mv "VBoxInternal/Devices/pcbios/0/Config/BiosRom" "c:\vmlite-bios\pcbios.bin" (en lugar de C:\vmlite-bios... usar la ruta donde se haya desempaquetado el archivo pcbios.bin)

Y listo… ahora si podemos iniciar nuestra máquina virtual, en este punto deberemos (si no lo hicimos desde Virtual PC) desinstalar las extensiones de integración de Microsoft para poder instalar las que nos provee VirtualBox, esto podrá requerir algunos reinicios hasta que quede estable, pero como ven ya tengo básicamente bajo VirtualBox la misma Maquina Virtual que tenia bajo Virtual PC.

Espero que esto haya sido de utilidad para poder seguir trabajando con nuestras máquinas virtuales de Windows XP Mode bajo VirtualBox y por ende luego bajo Windows 8.
Referencias:
TOPIC: VMLite XP Mode Plugin for VirtualBox and Virtutal Box 4.0
Windows XP Mode for VirtualBox 4
(*) se supone que si una maquina corre W7 deberia correr Windows 8 igual o ligeramente mejor.

Quienes me conocen personalmente saben que me encanta Team Foundation Service como herramienta ALM y de Integración Continua, pero a veces toca que por diversas razones no podamos contar con esta solución que out of the box nos ofrece muchas cosas, en este caso el stack con el que teníamos que trabajar era Subversion y Hudson, por las referencias que tenia ya varios proyectos habían utilizado el plugin de Hudson con MSBuild (y no estaba dispuesto a experimentar con Nant ;) ), pero nuestro caso era diferente, iba a ser en Visual Studio 2012, por lo que se configuro de manera habitual (conexión de Hudson con SVN y configuración del MSBuild), nada fuera de lo habitual excepto que los builds fallaban.

Bueno, el primer error que pude ver en el log era que de alguna manera el MSBuild instalado “no entendia” la nueva versión de archivos .sln de Visual Studio 2012, investigando pude encontrar un caso similar, concretamente cómo hacer para que un Agent de TFS 2008 pudiera ser capaz de compilar soluciones de Visual Studio 2012, la solución que se planteaba era instalar los Agents de Visual Studio 2010, así que por analogía supuse que había que instalar los Agents de Visual Studio 2012 sobre nuestro servidor de integración, y si, eso era… el formato de VS 2012 ahora sí que era entendido por el MSBuil de nuestro Hudson.

Pero a pesar de eso la build seguía fallando, y al revisar nuevamente el log descubrí que era porque no se encontraba el Assembly System.Web.Mvc y otros mas , upss, asi que toco volver a Visual Studio y comprobé que a pesar de que había hecho un “update-package” para actualizar todas las referencias del Nuget (si no sabes de que estoy hablando revisa este interesante articulo) por ahí se me habían colado unas referencias a las librerías instaladas en mi sistema y no a las que estaban en la carpeta “packages” (que como recordaran es gestionada por Nuget), en este caso fue mas

sencillo, borrar las referencias e instalar las referencias en los proyectos respectivos:
En todo caso, la moraleja de esta etapa es “NuGet es tu amigo, si NuGet puede manejarlo, no lo hagas tu a menos de que estés seguro que no puede hacerlo (como puede ser una librería comercial”).
A estas alturas ya estábamos mas confiados en que saldríamos de esta, la build seguía fallando, pero esta vez el mensaje de error se encontraba al final del log:

error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

La búsqueda me derivo a este artículo, que si bien era enfocado a TFS nos daba una sugerencia totalmente valida: copiar esa carpeta de una máquina que tenga una instalación completa de Visual Studio 2012 (recordemos que la idea es nunca tener que instalar todo el VS en el servidor de Integración Continua, solo lo mínimo necesario), se hizo eso y.. listo!

Build succeeded.

    0 Warning(s)

    0 Error(s)

Time Elapsed 00:00:01.41

[DEBUG] Skipping watched dependency update; build not configured with trigger: xxxxxxx #16

Finished: SUCCESS

Bueno problema resuelto, ahora tocara ver que se puede hacer para que compile en el .Net Framework 4.5 ya que cuando coloco uno de los proyectos como 4.5 obtengo este hermoso error…

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(983,5): warning MSB3644: The reference assemblies for framework ".NETFramework,Version=v4.5" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.

Espero que les sea de utilidad si por a o b tienen que usar un servidor de IC no hecho en .Net ;)

Si algo se me ha pasado es compartir esta presentación con la que introduje Team Foundation Service en el ultimo Agile Open Lima, así como a algunos compañeros de trabajo
En este tiempo lo que ha cambiado es que TFS ya es RTM, por lo cual ahora si que se tienen los planes de licenciamiento, y algo muy interesante, ahora esta integrado con GIT. No queda sino animarlos a probar Team Foundation Service, el cual es gratis para equipos de hasta 5 personas y por supuesto seguir los blogs de El Bruno y Jersson, que siempre nos estan informando novedades sobre esta potente herramienta.

Todo esto empezó cuando publique este twitt:

Era una idea que me había estado dando vueltas por la cabeza desde hace tiempo, y mas cuando en reuniones con la persona a cargo de un proyecto (a la que trataba de introducir en las bases de las metodologías ágiles) hacia referencias a que "en el proyecto se necesita mas recursos de nivel X y no de nivel Y" "tenemos que estimar la capacidad de los recursos disponibles", y claro el uso de ese lenguaje me repateaba (al margen del convencimiento de que se podría tener una estimación confiable "desde arriba" pero esa es otra historia) ya que como se ha conversado en varios sitios el llamar "recurso" a una persona equivale a cosificarlo, a ponerlo a nivel de una maquinaria o herramienta.

Y esa deshumanización del personal tiene de la mano no solo el aspecto de valorar a la persona como algo prescindible y fácilmente reemplazable, sino una visión errónea que puede a llegar a inducir que conceptos como el de "pool de programadores" son validos, que si que se nos dirá que la visión de negocio es tratar de reducir los costos fijos y moverse con costos variables, que con una adecuada metodología se puede dar una documentación que fácilmente puede ser convertida en código útil, etc, etc.. lo cual a estas alturas del partido deberíamos tener claro que es un engañamuchachos.

Entonces... ¿a que debemos tender? la respuesta nos la da el Manifiesto Agil en uno de sus items: "Individuos e interacciones sobre procesos y herramientas" (recordemos que llamar a la persona "recurso" lo pone a nivel de una herramienta), siendo asi a lo que debemos apuntar es tender a la construcción de equipos y mejorar la capacidad de estos y claro esta la colaboración entre sus miembros, así que podríamos hablar de "el equipo A tiene que ser reforzado en ...." "la performance del equipo se ha mantenido...", y claro no olvidarse que los miembros de los equipos son personas, con sus habilidades y debilidades, no una maquinaria.

Como anécdota en cuanto a un uso del lenguaje, me acuerdo de cuando mi empleo de entonces me subcontrato a un consultora mucho mas grande, entonces la responsable de RRHH tenia que darme instrucciones para iniciar mis labores en el cliente y me dijo "tendrás que hablar con XXX del Departamento de Compras.... si.. suena fatal", es que si, suena fatal que el trato con la gente que va a colaborar en un proyecto de responsabilidad sea caracterizador al igual que.... ¿las sillas?

Pero al pensar en este caso me acorde de otro escenario de cuando el lenguaje utilizado traslada algo detrás que podría ser contraproducente de cara a la cohesión de los equipos, no fue así el caso pero creo que se corrió un riesgo y desaprovecho una oportunidad, me explico: como ya he comentado lo usual para los informáticos es no ser considerado como core dentro de las organizaciones, siendo que la mayoría de los desarrollos se encargan a terceras empresas (con dispar resultado, la verdad sea dicha, pues bien.... cuando una vez me toco trabajar directamente para una "empresa cliente final" (el santo grial de los informáticos en España) me llamo la atención como el responsable del proyecto nos motivaba haciendo alusión al "cliente" y como había que tenerlo contento, lo cual si bien podría transmitir cierta deformación profesional, no dejaba de ser una oportunidad perdida para hacer que el equipo se sintiera mas parte de la cadena de valor del negocio y por ende mas identificado y comprometido con los resultados, motivación que puede estarse perdiendo cuando en las grandes empresas se pasa a ver que tu trabajo ya no es tu trabajo sino tu cliente.

Así que nada es casualidad, aun el uso inconsciente de ciertas formas del lenguaje tiene un significado detrás que debe valorarse para lograr lo mejor posible de los equipos.

Por si no lo saben, el próximo domingo 26 de Agosto se viene el VI Agile Open Lima, asi que por si no te has apuntado ya te estas demorando demasiado :), este evento es peculiar pues por primera vez se hace en domingo y en las afueras de Lima (si, aun mas lejos que Surco o La Molina) concretamente en Ñaña en la sede de Universidad Peruana Union, lo cual permitirá realizar algunos juegos agiles al aire libre. Para esta ocasión estoy proponiendo las siguientes sesiones:

•  Team Foundation Service: Gestionando nuestro proyecto ágil desde la nube! 
•  Conversatorio: ¿Mi cliente (o proveedor) esta en el otro lado del mundo! ¿Que hago? 

 Estoy muy entusiasmado con estas sesiones, llevo varios meses probando la versión Beta de Team Foundation Service, y me ha sorprendido gratamente sus capacidades para llevar a cabo integramente la gestion del Ciclo de Vida de las Aplicaciones, desde la toma de requerimientos y gestion del Backlog hasta la automatización del despliegue (y por supuesto haciendo la Build en la nube), si creías que TFS es solo un "source safe mas potente"... esto te hara pensar ;).

Sobre la segunda charla, intentare replicar un estilo "reality show" que pude ver en acción por parte del maestro Angel Medinilla en el Agile Open Spain del 2009, compartiendo las experiencias que hayamos tenido trabajando con equipos distribuidos, ya sea como cliente o como proveedor, en un momento en que el desarrollo de proyectos offshore esta creciendo en nuestro país, sera algo muy interesante para ver como mejoramos nuestra forma de desarrollar esta clase de proyectos desde un enfoque agil.

Así pues cuento con ustedes en este nuevo Agile Open Lima y en particular con sus votos para poder llevar a cabo estas sesiones :), ¡nos vemos en Ñaña!!.

He estado pensando en escribir este post desde hace unas semanas cuando empecé una reflexión sobre que tan rígidos somos (o debemos ser) al intentar aplicar metodologías agiles, y todo empezó con este dialogo con un amigo que trabaja fuera de Perú:
Amigo: tudo bem?
Yo: tranqui...tratando de introducir Scrum por aqui...
Amigo: estas mismo scrum master? aca estamos en la iteracion 18
Yo: estoy mas bien haciendo coaching, explicando a la gente y tratando de armar nuestro tablerito
Amigo: revisa vxzs111.com ahora y vuelve en junio.... y me das los comentarios de los cambios q ves.
Yo: ok
Amigo: va a haber una nueva version del website
Yo: ese es tu cliente?
Amigo: oui
Yo: ook
y... usan planning poker para estimar?
Amigo: no idea....
hay jefes de proyecto en varios niveles....no se como hacen sus pronosticos del tiempo.
Yo: pero ... hacen retrospectivas?

Amigo: no tengo vision global

Yo: me refiero, retrospectivas a nivel de equipo
Amigo: t refieres a feedback?
Yo: luego de cada sprint el equipo se reúne y dice como le ha ido y como se puede mejorar
Amigo: no hay psicología, siempre adelante.
lo q tu dices es la teoria
Yo: uhmm.... entonces no estan aplicando scrum
hacen daily meetings frente al tablero?
Amigo: bueno... antes habia tu mini reunion casi diaria,con tu tablero eetc etc luego se fueron espaciando, y espaciando. hasta todos los viernes
Yo: entonces dejaron de hacer scrum y estan aplicando algo iterativo
Amigo: pero en todo caso... todo desarrollo estaba en un solo lugar.
bueno, es un scrum flexible....o como lo quieras llamar, para un purista, no aplica
Yo: pero... alguna vez el equipo hizo retrospectiva? veamos... hay cosas en q si puedes ceder y cosas en que no...las reuniones y retrospectivas son mandatorias. claro q tambien es cierto q la regla de "nada interrumpe" al sprint a veces tiene que saberse gestionar si hay q corregir cosas de emergencia
Amigo: la negociacion de q se hace o q no se hace... eran del jp con el cliente, ahora... tu puedes indicar cuanto t puede tomar....y en base a eso el jp... trata de decir si va o no va... o si va, cuanto les va a costar.
Yo: veamos.... se negocia el orden del backlog y siempre hay repriorizaciones...
Amigo: para eso esta el jp
Yo: veamos... tu JP esta fungiendo de Scrum Master o Product Owner?
Amigo: hay un jp de desarrollo, hay otro jp, sobre el jp de desarrollo, y el cliente, tiene otros jp
Yo: de acuerdo... pero esos cargos como se mapean hacia los roles q plantea Scrum?
Amigo: desde el punto de desarrollo, el product owner es el jp de desarrollo, el prioriza en gral. q se hace...etc
el jp, del jp de desarrollo, seria el scrumMaster... mas politico, no tecnico.
Yo: ok
Amigo: y ademas hay una asistente de este ultimo, (que me parece jp en formacion)
Yo: y una vez q han definido el alcance del sprint... este permanece inamobible?
Amigo: todo depende del jp de desarrollo....el evalua en que casos se pueden hacer cambios
Yo: uhmm... los cambios deben hacerse al pasar de un sprint a otro, existen excepciones.. cuando hay q apagar un incendio....
Amigo: no hay nada q hacer.... q eres un purista

Purista…. esa es la palabra que se me quedo grabada, y me puse a pensar que si todo lo que le estaba “reclamando” a mi amigo era efectivamente purismo, o simplemente el querer establecer unos minimos respecto a como trabajar de manera agil.

Entonces tratemos de imaginar los contextos que pueden derivar a querer aplicar "Scrum" en un proyecto:

1. Queda bien de cara al mercado decir que se usa
2. Hay una necesidad de mejorar la manera de hacer software (problemas de tiempos, alcance, calidad o todo junto)
3. Se escucho en alguna conferencia y se decidió ir por ello, o algún "guru" que paso por ahí lo recomendó
4. Se desea mejorar la organización y se pensó que Scrum seria un buen componente dentro de ese proceso

No conozco mas detalles, pero si bien cualquiera de esas razones puede llevar a la situación planteada, solo las "pares" dan un punto de partida razonable, pero aun así son incompletas si no tienen como base el asumir la "filosofía" detrás del Manifiesto Agil, y se paso directamente a querer implementar la "metodologia" y luego a "adaptarla".

Adaptar... interesante, valido y a la vez arriesgado, hace pocas semanas un JP me indicaba "uno no tiene porque amarrarse a una metodología, sino coger lo mejor de cada una y adaptarlo a la realidad de la organización", lo cual tendría todo el sentido del mundo si detrás de ello hay un respeto a la filosofía base, respeto que llevaría a entender el porque los artefactos de Scrum son importantes: las reuniones diarias porque así se da prioridad a las personas e interacciones sobre los procesos y herramientas, el backlog como mecanismo que facilita la respuesta al cambio y la colaboración con el cliente. Es que claro, conceptos de "equipos autoorganizados" o "propiedad colectiva" del código son difíciles de aterrizar en ciertas jefaturas, pero el resto es tratar de llegar a ellos y emprender ese camino.

Como es evidente, poco de eso ha sido tomado en cuenta en esta implementación de Scrum, quedando solo las iteraciones, pero lo peor es que no ha sido asimilado por el Equipo, el cual puede llegar a ver todo lo demás como "purista", y si, caer en el purismo a rajatabla es un riesgo, por lo cual hay cosas que se pueden ajustar en cierto punto como el mapeo de roles a algo mas cercano a la realidad organizacional,

Ahora bien, esto de querer ser ágil (o implementar Scrum, o ya puestos... Kanban) no es un destino al cual llegar rápidamente, sino un camino de largo plazo en el cual las tentaciones de salir están a la vuelta de la esquina, pero de nuevo... lo importante es asumir la filosofía que esta detrás, y sobre todo no hacer las cosas de golpe, aplicar "baby steps" como nos recuerda Hiroshi; que si, que no sera Scrum lo que se tenga en un primer momento, pero si queremos aplicar mejora continua e involucramos al equipo (no, no se puede ser ágil con una imposición vertical de tareas) en llegar a un objetivo (de nuevo, propiedad colectiva del código, escuchar y no imponer plazos, etc), se lograra la meta y ahí si se podrá presumir de Scrum y de agilismo.

Y de nuevo, el purismo tampoco es la respuesta, en ese sentido me gusta mucho el ejemplo que da Angel Medinilla en un escenario de Scrumban, si, una mezcla pragmatica de Scrum y Kanban pero que era necesaria debido a la realidad del equipo/proyecto (leerlo, es imprescindible) pero que gracias al equipo se logra sacar lo mejor de la situación para lidiar con un escenario en el que no era posible cumplir lo exigido por Scrum de "nada interrumpe el  Sprint".

Entonces, queda claro que si bien la evolución hacia el agilismo involucra concesiones temporales, ese tradeoff no debe darse en nada que sacrifique el que el equipo "compre" la idea y abrace el cambio y entre eso están elementos claves como: daily meeting, retrospectivas, backlog visible.... lo cual lamentablemente no era el caso de mi amigo por mas que lo llamara "scrum flexible".

Y uno al leer el título podría pensar que se esta incurriendo en un desprecio hacia el cliente que nos ha encargado el desarrollo de un software, pero nada más lejos de la realidad, la reflexión viene a algo que aun sigue siendo mal entendido por quienes estamos involucrados en el desarrollo de software.

No cuento nada nuevo que tradicionalmente (modelo “cascada”) el desarrollo de software tiene un historial de fracasos totales o parciales, ya sea en funcionalidad incompleta, sobrecostos de tiempo y dinero, lo cual lleva como consecuencia en que los aun medianamente exitosos tengan la presión por conseguir entregar “lo que se pide” “a tiempo”, y claro muchas veces sin importar el “cómo” que es a lo que nos lleva el título de este post, el cómo la obsesión por entregar algo que el cliente pueda usar hace que se pierda la perspectiva global del problema.

Y el problema (deuda técnica) ya es conocido: métodos de más de 400 líneas de código, código muerto y/o duplicado, lo cual deriva en poca mantenibilidad, bugs como consecuencia de la extensión de la funcionalidad, pobre performance, etc; síntomas que hacen que el que hereda un código desee ir corriendo tras el que hizo el código originalmente, (y un cliente pagando resignado los costos de implementar un parche o una mejora menor).

En este punto se nos podría decir que esto ocurre porque el equipo de desarrollo no aplicó un buen patrón de diseño, que no siguió los principios S.O.L.I.D., lo cual si bien tiene algo de cierto no es sino la segunda capa de un problema mayor que veremos en breve.

Se pensaría que con la irrupción de las metodologías ágiles la situación ha estado cambiando, pero no, la realidad no es tan hermosa, pues si bien ahora tenemos más visibilidad sobre los elementos (historias de usuario) que se están desarrollando no debemos de olvidar que las metodologías imponen un proceso de priorización, en el cual lamentablemente las historias funcionales (si, las que “dan valor”) toman precedencia siempre sobre las técnicas, las cuales tienen que rogar para hacerse un lugar en el sprint o en el flujo del Kanban, y muchas veces nunca logran entrar por la sencilla razón de que “no hay como justificar ante el cliente algo que no se ve que le reporte valor”. Así pues, se cumple con la entrega de funcionalidad continuamente, pero seguimos acumulando deuda técnica pues, a pesar de seguir perfectamente el proceso, sólo nos estamos enfocando en entregar un software que funcione sin fijarnos en qué es lo que hay detrás de este software que se entregó perfectamente en plazos pues lo importante es que funcione, ¿no? ¿qué hay deuda técnica? tranquilos, eso lo solucionamos con una refactorización circunstancial (léase: arreglamos cuando podamos y no nos quite mucho tiempo).

Recomiendo leer este interesante articulo de Lucas Ontivero donde nos cuenta como las cosas han seguido yendo mal en el lado técnico a pesar del agilísimo.

Adicionalmente tenemos el factor del QA (Quality Assurance), uno podría creer que en empresas grandes este equipo tendría una visión integral de la calidad del producto, lo cual debería incluir tanto la verificación de la mantenibilidad y calidad del código como de la validación de la arquitectura, pero no, al parecer su visión va sólo al lado funcional, o sea a lo “visible” del gráfico anterior, siendo que temas como la mantenibilidad “lo ve el equipo de desarrollo”, así pues por un lado se exige un cumplimiento funcional (muchas veces sin entender las razones por las que “la gente de desarrollo” opto por implementar de una manera diferente a como QA lo pensaba) estricto pero por otro lado se omite la validación de la calidad de lo técnico, pues claro… no es lo que ve el cliente de manera directa, por más que este sea el que luego tenga que pagar los “intereses” de la deuda técnica(*). No se ustedes pero si un equipo que se supone se encarga de la “calidad” durante el ciclo de desarrollo ignora la parte técnica de la implementación (¿alguien dijo auditorías?) , le esta haciendo un flaco favor al proyecto y al cliente.

Así pues mucho del problema viene dado por la importancia que se le quiere dar al elemento técnico del proyecto, el cual viene tradicionalmente es relegado por debajo del administrativo, siendo que muchos profesionales hacen gala de haber tocado muy poco los elementos correspondientes a la programación en su formación profesional, lo cual en mi opinión generalmente (he conocido excepciones) ocasiona que no se sepa (debido a que a veces no se entiende) el impacto de una decisión técnica que se tome en cualquier etapa del desarrollo, razón por la cual prime el componente funcional/visible a la hora de definir prioridades en el desarrollo.

Afortunadamente hay caminos de solución, uno de ellos es tratar de entender qué es lo que ha derivado en la creación del Manifesto for Software Craftsmanship como una evolución del Manifiesto Agile (esto lo explica muy bien Edson en esta presentación); y por otro lado, dentro del marco de las metodologías ágiles, reconocer de manera visible el rol que deben de jugar los componentes técnicos, en ese sentido me sorprendió muy gratamente como en su reciente conferencia "Lean from the Trenches" Henrik Kniberg indicó claramente cómo dentro de su proceso ágil (basado en Kanban) había reservado, dentro de su tablero, el espacio necesario para las historias técnicas, de esta manera

Es que como Henrik dijo, en un mundo ideal sólo habría historias de negocio, pero no estamos en un mundo ideal, los problemas técnicos existen y no podemos pretender seguir ignorándolos, o creer ingenuamente que efectivamente lo “solucionaremos después”, o ya en el lado extremo seguir en la ilusión de que cualquier programador podrá implementar algo si le damos una especificación funcional completa y detallada.

Entonces, regresando al título de este post, creo que debe de quedar claro que no es que no tengamos como meta el entregar funcionalidad y software, sino también validar el cómo llegamos a ese entregable, procurando (entre otras cosas):

• Dar el espacio a las historias técnicas cuando corresponda, y no relegándolas a cuando “haya tiempo”.
• Sospechar del programador que defiende una mala implementación con un “pero funciona”.
• Ser consciente de los riesgos que significa ir por el camino rápido en aras de entregar la funcionalidad pedida.
• Que todo el equipo (y no sólo el que implementa) sea consciente de lo que hay en la implementación (arquitectura, algoritmos, etc) y de como eso condiciona los tiempos de desarrollo, especialmente cuando se trata de agregar una nueva funcionalidad.
• Valorar el factor técnico, procurar la mejora de las habilidades técnicas de los desarrolladores: mentorship, revisión por pares, dojos, etc.

Claro que mucho de esto tendría que ir de la mano con un reconocimiento dentro de las organizaciones al rol que juegan las TI en su crecimiento como negocio, pero por ese lado la cosa esta bien complicada.

(*) Se entiende como “intereses” de la deuda técnica al hecho de que conforme pasa el tiempo será más difícil corregir las malas decisiones o malas implementaciones de código, ya sea porque el desarrollador que implementó algo de manera críptica ya no se encuentra en el equipo, porque nueva funcionalidad superpuesta generó más dependencias o simplemente porque por el tiempo que pasó ya es más difícil acordarse el porque se tomó esa decisión que “parecía buena en su momento”.

Durante un tiempo he estado siguiendo entusiastamente las metodologias agiles, y recientemente he practicado algo de Kanban, y si bien me han terminado gustando algunos de sus enfoques me he sentido frustrado por la impedancia entre el hecho de que el backlog se manejara por un lado usando un Excel y por otro la visibilidad de las tareas en progreso (WIP: Work in progress)unicamente mediante postit's en la pizarra.



Si a esto le sumas el hecho de que el TFS solo se usa como repositorio de código fuente y no como la herramienta de ALM que es la decepción es mayor, pero en este caso se puede entender los reparos si es que no se incluye de entrada un soporte para el modelo Kanban, como si que lo incluye para CMMI y SCRUM.

Al parecer esto va a cambiar pues gracias a Ulises me vengo a enterar de que en CodePlex los Visual Studio ALM Rangers estan desarrollando la Practical Kanban Guidance con Team Foundation Server y Visual Studio, dentro de este proyecto (para TFS 2010 y el inminente TFS 2012) se incluye la nueva plantilla Microsoft Kanban 1.0 Process Template así que con esto se abre un nuevo capitulo para consolidar el uso de TFS en las diversas metodologías ágiles, tratando de demostrar que su uso incrementa (y no reduce) el ancho de banda en la comunicación del equipo.

Queda ver si es posible usarlo desde la nube via TFS Preview