Andoni Arroyo : Metodología

“scrum” con minúsculas

Andoni Arroyo — Thu, 28 Oct 2010 06:00:00 GMT

Es muy interesante observar como ciertos paradigmas van calando en la comunidad de desarrollo. Raro es ver hoy en día alguien que no defienda un modelo ágil de trabajo, puesto que sus virtudes son evidentes.

Como siempre ocurre, sabemos donde queremos ir, pero en ocasiones el camino no es lo suficientemente claro para avanzar sin dudas. Muchos son los que se pierden por diversos motivos echando a andar sin tener correctamente interiorizados los principales valores innegociables. Una vez conseguidos los mismos, lo demás vendrá solo.

Te puedes quedar, como dice un amigo, “Buscando por donde le entra el agua al coco…”

Si no afrontamos la adopción de una nueva metodología con la importancia que se merece, podemos cometer algunos errores que nos condenen al fracaso, y esto de verdad que minará la posibilidad de mejora para una larga temporada…

Algunos de los errores más comunes que nos pueden llevar a tener un SCRUM sesgado y poco efectivo pueden ser:

No integrar los hitos heredados en la planificación del Backlog
Las empresas (aunque sea a golpe de ASM) hacen cosas en el día y a día. Asumen compromisos que deben cumplir. Un cambio en la metodología es una evolución, no una revolución. Deben contemplarse los hitos anteriores y encajarse en el nuevo modelo de manera natural. De nada (positivo) vale crear un sprint si el día 1 del siguiente mes debemos entregar la “master” y ese trabajo no se contempla en la planificación de Backlog.
Jugar con dos barajas con las prioridades
Las prioridades y urgencias son las mismas con y sin SCRUM. La nueva metodología no va a solventarnos por arte de magia los problemas, solo nos va a dar unas reglas para afrontarlos. De nada vale planificar algo para saltarlo, haciéndonos trampas al solitario y andar como pollo sin cabeza apagando fuegos.
Asumir de manera parcial o sesgada las reglas del juego
Una de las ventajas que tiene SCRUM frente a otras metodologías más predictivas, es su sencillez y empatía con el desarrollador. Estos al fin y al cabo son el motor de cualquier empresa de desarrollo de Software y colocarlos en el centro del tablero es una de los principales aciertos. Eso si, si te decantas por SCRUM implanta al menos las pocas reglas en conjunto para que la mecánica tenga sentido.
Presencia de roles satélites o heredados
Al ganar visibilidad inevitablemente afloraran roles a los que se les verá el cartón. Quedará patente lo poco que aportan a día de hoy y serán grandes enemigos del cambio. Supervivientes hay en todos los sitios y tirar de la manta no les va a hacer ninguna gracia. Debemos identificarlos y recolocarlos si es posible puesto que pueden hacer mucho ruido en contra y comprometer la estabilidad. Siempre es más fácil deshacer que hacer.
Permitir implantar la metodología sin conciencia Top-Down
Asumir una metodología (más siendo ágil) es un cambio profundo para una empresa. Afecta a todos los estratos de la misma y solo triunfará si se asume una conciencia global de la necesidad e implicación necesaria para el éxito. O jugamos todos o rompemos la baraja y no vale ir de farol ;)
Establecer un ámbito de actuación de la metodología reducido o para partes de los equipos
Todo lo que ganemos en agilidad, es un éxito, pero los avances se multiplican y crean sinergias muy positivas cuanto mayor es el dominio se implantación de la misma. Asumirla en equipo muy estancos obliga a realizar un esfuerzo titánico por parte de unos pocos y no fomenta el ROI de las inversiones.
Impedimentos de Hardware, limitación de inversiones
las herramientas no son parte de la metodología en si misma, sino la forma de implementar la misma. Olvídate de reinventar la rueda, existen herramientas muy poderosas que te permitirán a un coste asumible ser muy productivo. Con la aparición del Cloud Computing dichos costes pueden ser todavía más elásticos permitiendo a pymes y empresas con pocos recursos contar con las mismas herramientas que antes solo estaban al alcance de las grandes. SAAS de TFS es un buen ejemplo de este escenario.
Intentar implantar todas las best-practices a la vez
Es mucha la gente que piensa que un conjunto de best-practices relacionadas con el mundo del desarrollo del Software son parte de SCRUM. Esto no es así. Está claro que cuanto mejor desarrollemos, mayor ventaja competitiva tendremos. Esto es independiente de la metodología que empleemos. Tanto en CMMI , RUP o MSF realizar pruebas unitarias, builds automatizadas, patrones de diseño…son prácticas muy valoradas. Es verdad que en aspectos ágiles todavía son más relevantes puesto que el intervalo de entrega se acorta (valor solo entendido como Software potencialmente entregable) pero esto es la guinda del pastel.
Falta de paciencia y fe en los resultados
Como ya hemos comentado, no existe una varita mágica que nos resuelva los problemas. Solo con trabajo y esfuerzo llegarán los frutos. Es un proceso continuo, sin un fin definido. Siempre podremos ir mejorando y adaptándonos a las nuevas realidades que surjan por el camino. Si te decides a implantar SCRUM no esperes que al terminar el primer Sprint tu empresa se otra. Valora si es un poco mejor de lo que lo era antes. Evalúa la tendencia, no (solo) la foto y por supuesto, replantearte continuamente los procesos, identifica las acciones en cascada y disuélvelas con una integración más orgánica.

Estos son algunos de los puntos sobre los cuales debemos poner el foco a la hora de intentar implementar cualquier metodología en una empresa. Aunque son problemas comunes se acentúa aún más cuando deseamos trabajar con metodologías ágiles.

Por cierto, la palabra ágil no está empleada por que sí. Para que el conjunto sea ágil todos los componentes del mismo deben serlo. Esta necesidad nos obliga a identificar los puntos que no lo son y tratarlos como impedimentos (teoría de los cuellos de botella). Este proceso de mejora continua es el que nos permite adquirir agilidad puesto que los valores absolutos no tienen cabida en este marco.

SOA != Client Server + WCF

Andoni Arroyo — Mon, 26 Jul 2010 05:30:00 GMT

El panorama actual en el mundo de desarrollo del software nos brinda más oportunidades de las que nunca habíamos tenido (quizás ni siquiera imaginado). Entre otros escenarios, la aparición de Internet ha propiciado el crecimiento de los sistema distribuidos, la orientación a servicios, el SaaS...

Este nuevo "el dorado" plantea características donde todas las empresas desean desembarcar sus activos. Por supuesto estos destinos son tan interesantes que muchos deciden tomar atajos para llegar a lo que creen el mismo destino, pero cuidado,
que como siempre, no es oro todo lo que reluce.

La formula del título viene a decir eso, se podría leer como:

SOA != Client Server + WCF

No es lo mismo desarrollar Software orientado a servicio que colocar una capa de WCF en una aplicación Cliente Servidor. Definitivamente NO ES LO MISMO...

Pero como ya sabemos las cosas no cambian solas, debemos como desarrolladores hacer un esfuerzo por ser conscientes de las nuevas reglas de juego con las que deseamos que nuestras aplicaciones den la talla.

Revisando mi experiencia el respecto podemos identificar los errores más comunes a la hora de crear Software orientadas a servicios:

Los servicios (aunque no te lo creas) no están (solo) para ti.
Utiliza los recursos del servicio de manera razonable, piensa bien como y cuando realizar las llamadas evitando acaparar los recursos disponibles.
Al consumir otros servicios estas realizando una llamada remota, eres consciente?
No hagas 17 peticiones con sus 17 serializaciones para pintar una pantalla. No me digas que son las clases que usas como DTO y que te van para el pelo para tu ORM...
Todo el tiempo invertido en optimizar la comunicación tendrá un alto ROI, te lo aseguro.
Por supuesto recibir 26 millones de objetos (bien serializados) es un problema a nivel de diseño de la aplicación. (consolida la información, pagina, trabaja por bloques pero no tires por ese camino bajo ningún concepto...)
Siempre piensa en que la disponibilidad nunca es del 100%
Eso es así aunque algún comercial se empeñe en decir lo contrario.
Pregúntate que ocurre si el servicio no está disponible y dota a tu aplicación de la inteligencia necesaria para responder ante tal situación de manera digna. Siempre es interesante valorar la posibilidad de realizar las comunicaciones de manera asíncrona.
Ten en cuenta que no debes lanzar procesos que comprometan la estabilidad de los servicios, puesto que estos deben estar disponibles para los demás clientes.
(Recuerda que trabajar por bloques "casi nunca" es opcional y con determinado volumen de datos es obligatorio)
Piensa en la Alta disponibilidad, como hacer correr varias instancias en paralelo, clúster activo-pasivo antes de que te pille el toro...
Diseña un plan de contingencia y déjalo por escrito
Si no quieres que la gente que mantiene la aplicación te llamen a las 3:00 de la madrugada por que se ha parado el servicio, dales los mecanismos oportunos para que operen con autonomía. Ten un poco de empatía y piensa que ellos no pueden controlar todas las aplicaciones que están en producción como los que lo han desarrollado.
Escalabilidad no es solo una palabra más terminada en …idad
Creo que está de más decirlo, pero evitar mantener el estado en el servidor entre tus llamadas te permitirá escalar mejor. Tomate la molestia de planificar mecanismos de escalabilidad vertical y horizontal si no quieres morir de éxito. Corregir este tipo de problemas a posteriori siempre es traumático.
Ten en cuenta que todos los recursos son limitados, hasta el disco donde escribes el log se acaba si no tienes políticas de reciclaje. Piensa en que los servicios están diseñados para ejecutarse 24x7 y 365 días al año, en estos detalles debemos hacer especial énfasis.
La correcta gestión de excepciones te puede salvar la vida
En relación con la disponibilidad, es crítico gestionar de manera lo más eficiente posible las excepciones. La tecnología está ahí hace tiempo solo debes esforzarte en aplicarla correctamente. Una excepción en un servicio debe gestionarse correctamente para que no comprometa su estabilidad y disponibilidad. Trabajar sobre ello puede mejorar mucho la QoS y reducir el coste de mantenimiento.
Invierte tiempo en pensar bien tus contratos
Es importante ajustar el equilibrio entre la cohesion de los servicios y los clientes. Cuando desarrollamos orientado a servicio no debemos hacerlo ad-hoc a un cliente en particular. El servicio debe exponer una serie de funcionalidades bien definidas. Extendiendo esta característica conseguimos el correcto grado de cohesión.
Ahora tampoco hagas que usar tus servicios sea un infierno...
Piensa bien cual es la mejor manera de establecer la comunicación con tus servicios
La serialización y transporte de los objetos es una parte muy significativa del tiempo de procesamiento consumido. Piensa cuidadosamente la manera de exponer tus servicios al mundo. expón los endpoints que sean necesarios y afina los behaviors de los mismos para evitar matar moscas a cañonazos.

Como siempre, se hace camino al andar, así que la resolución de los problemas presentes en este tipo de escenarios también tenderá a converger (para estandarizarse más adelante) mientras todos maduraremos en el proceso.

Por supuesto surgirán nuevos problemas relacionados con llevar el mundo del desarrollo de software más allá, que para algo estamos aquí, no?

Sinergia D&T (developer + tool)

Andoni Arroyo — Fri, 12 Mar 2010 06:30:00 GMT

Siempre es importante aprender de los demás (sobre todo de los buenos ;)) pero en aspectos como la organización y la metodología lo básico está inventado. Nuestra tarea como desarrollador consiste, básicamente, en aplicar esas buenas ideas a nuestra realidad y hacer que se ajuste a la misma como un guante.

Por supuesto, esta idea es más sencilla de decir que de poner en practica. Se deben tener en cuenta muchos aspectos, sin descuidar ni uno solo de ellos, si queremos tener un “Jelled Team” como lo califican en Peopleware. En el proceso ALM podemos observar que contar con un buena herramientas nos puede facilitar mucho el proceso.

Cuando comenzamos con una metodología, la herramienta seleccionada nos brinda una gran ayuda poniendo a nuestra disposición todo el know-how analizado y sintetizado para generarla. Y esto no es poco. Nos ayuda a encauzar la energía y optimizar los esfuerzos sin dispersarnos en decidir como comenzar a caminar en la organización básica del complicado mundo del desarrollo del software.

En este punto es donde, ante el Team Foundation Server hay que quitarse el sombrero. Para ser una herramienta relativamente moderna ha sabido encajar las piezas con mucho acierto abriendo los puntos claves a diferentes metodologías para elegir nuestro sabor preferido. (MSF, SCRUM…)

Como muestra un botón. Cuando en el TFS2010 reportas un bug sobre un proyecto, el formulario correspondiente (y la Web del Team Web Access !!) nos aparece un botón con la leyenda Tools. Al desplegarlo, tenemos entre otras opciones, la de mostrar el diagrama de estados de la gestión de bugs definida por la guía de proceso seleccionada.

Dicho elemento se ve así con el SCRUM de Cochango:

Cualquier desarrollador de Software se puede dar cuenta que poco tenemos que inventar al respecto. Como mucho, tendrás que hacer algún ajuste personalizado para tus particularidades. Ahora imaginaros la cantidad de horas y energía que podíamos malgastar en intentar crear una gestión de bugs como esta desde cero (más el tiempo en crear el diagrama y mandarlo al departamento de calidad ;)). Aspectos como este, transmiten madurez por parte de la herramienta, generan confianza en su uso y crean una sinergia entre los desarrolladores y la herramienta que nos ayudan a ser lo más eficientes posible.

A ver quien se vuelve al Source Safe ;)

Scrum:IGTD (Scrum implementa el interfaz GTD)

Andoni Arroyo — Thu, 10 Dec 2009 07:00:00 GMT

Cada día están más en auge las metodologías orientadas a la productividad personal. Todos y cada uno de nosotros gestionamos recursos, al menos nuestro tareas en el tiempo, y es recomendable, por no decir necesario, organizar dichas tareas para ser los más productivos posible.

El ámbito de aplicación GTD no se limita al entorno profesional sino que cubre también los aspectos de organización personales, permitiendo aplicar pautas a todos los aspectos de nuestro comportamiento. Existen en la red toneladas de material al respecto y discutir las bondades de la metodología GTD y las implementaciones de las mismas quedan fuera de la intención de este post. Sin embargo, me gustaría analizar la relación que existe entre dos mundos íntimamente relacionados (aunque no de manera explicita) como son GTD y las metodologías ágiles. Como representante de dichas metodologías estudiaremos Scrum.

Si consideramos GTD como un interfaz o contrato, llamémosle IGTD, sus puntos serian:

Recopilar
Procesar
Organizar
Revisar
Hacer

Veamos como SCRUM implementa cada uno de los mismos…

Recopilar
El objetivo en GTD se define como “sacar” todo de nuestra mente y recogerlo en alguno de los elementos de almacenamiento para luego procesarlos.

Scrum define exactamente esta tarea identificando un rol para cubrirla, el responsable de producto o Product Owner. Entre las responsabilidades principales de dicho rol se encuentran la de identificar los puntos que más valor aportan al producto servicio que desarrolla el proyecto. Dicha recolección se realiza escuchando y tratando con los diferentes stakeholders. Este punto común de acceso permite crear una capa de protección y homogenización para el resto del equipo.
Otra tarea muy importante y a la vez menos visible que recae sobre esta figura, es la de rechazar las propuestas de los stakeholders que no interesa avancen por el flujo puesto que no son interesantes para el producto. Esto permite al equipo centrarse en lo que realmente aporta valor.
Procesar
Por supuesto, el trabajo de un buen Product Owner, no se limita a transcribir todo lo que escucha a los diferentes stakeholders. Debe realizar un proceso de análisis y diseño cuyo resultado se muestra como un conjunto de historias de usuario o Product Backlog. Dichas historias deben mantenerse consensuadas, consistentes y priorizadas puesto que conforman el material sobre las cuales trabajará la “apisonadora” que es el equipo.

Una buena regla para saber si tienes un buen Product Owner en tu equipo es preguntarse cuanto disminuiría la rentabilidad del producto si lo sustituyes por una regla de redirección de correo…
Organizar
El equipo, liderado por el Scrum Master y contando con la disponibilidad del Responsable de Producto, comienza en el Sprint Planning Meeting a digerir y desmenuzar ese producto Backlog. El resultado de dicho procesamiento son las tareas necesarias para cubrir las historias de usuario que el Product Owner ha recopilado.
Revisar
Scrum da gran importancia al proceso de revisión. En base al grano deseado realiza la tarea de revisión en dos maneras.

Todo el equipo se reúne una vez al día en el Daily Scrum comenta lo que ha realizado, lo que va a realizar en el día y los impedimentos que se ha encontrado por el camino. La verdad es que no se me ocurre una mejor forma de aplicar el concepto de revisión a grano fino.

Por otro lado, al finalizar cada sprint se realiza una revisión del mismo, Sprint Retrospective que permite a nivel de todo lo realizado en el Sprint, evaluar los aspectos positivos para potenciarlos y negativos para mejorarlos.

En GTD también existen dos tipos de revisiones, las diarias y las semanales (por Sprint para Scrum) así que en este punto la cosa encaja como un guante.
Hacer
Una vez que tenemos claro lo que hay que hacer el equipo lo desarrolla, lo mismo que en GTD. Ambas metodologías hacen hincapié en la satisfacción de hacer las cosas y poder marcarlas como hechas, quitándolas de la primera línea de batalla y permitiendo centrarnos en lo que falta por hacer.

La conclusión que podemos obtener de este análisis, es que ambos metodologías son recomendablemente compatibles. Encajan porque se basan en patrones comunes, haciendo hincapié en centrarse en lo importante, reducir el stress, simplificar el día a día.

Además son especialmente cuidadosas con evitar el cambio de contexto y fomentar la concentración, GTD vía controlando las interrupciones internas y externas y Scrum blindando a los equipo de los cambios durante los Sprints.

Metodología, motivación y otras hierbas…

Andoni Arroyo — Sun, 29 Nov 2009 21:00:00 GMT

No digo nada nuevo al afirmar que las empresas de desarrollo de software cuentan como materia prima para crear sus “productos finales” con la tecnología y conocimiento. Ahora bien, este conocimiento no reside en el aire, sino en las personas.

Los malos modelos directivos valoran los recursos solo en su aspecto cuantitativo sin valorar la calidad de los mismos. He oído a “grandes” gestores del sector de desarrollo de software, sacar pecho al decir que consigue dos “recursos” (por ejemplo programador) al precio de uno. Por supuesto, el cambio implicaba sustituir una persona con diez años de experiencia por dos becarios, pero desde su perspectiva el cambio de 2x1 implicaba el doble de trabajo al mismo coste…

Este mercado avanza, lentamente y en su proceso madura. Podemos decir que el ritmo al que madura el mundo del desarrollo del software es varias veces más lento que el ritmo al que avanza la tecnología, pero aun así, lo hace. Si hiciéramos un paralelismo con algún otro sector de desarrollo más maduro, supongamos la automoción, nadie se plantearía trabajar sin una metodología definida que permita a todos los miembros de los diferentes equipos conocer las reglas del juego. Aún así hay muchas empresas que no emplean ningún tipo de metodología explicita.

Pensemos un poco sobre como impacta la forma de trabajar en la motivación de los profesionales. Los músicos de una orquesta, por muy buenos que sean, necesitan una partitura compartida para tocar juntos. Es cierto que la partitura ya esta creada por un compositor (en muchas ocasiones genios) y esta no varía. Se repite de idéntica manera miles de veces y no se adapta a las demandas del que la escucha. Nuestra partitura es más compleja. Varía con el tiempo y no es conocida de antemano (aunque las metodologías predictivas se empeñen en decir lo contrario). Al empezar nuestra obra no conocemos la cantidad de violines o tubas que necesitaremos…

Esta complejidad es una razón más para contar con una poderosa herramienta como la metodología que nos guie por el camino. Esta nos aporta:

Evitar desgastarnos en definir y redefinir procesos implicados en el día a día.
Aplicar cierta “objetividad” a la forma de trabajar y a la valoración del trabajo de los miembros del equipo.
Ganar en visibilidad al definir roles y responsabilidades asociadas.
Alinear los objetivos de los diferentes miembros del equipo.
Tener una base que adaptar y mejorar para los siguientes proyectos.

Cualquiera de estas características son básicas a la hora de motivar a los profesionales, sobre todo a los buenos. He tenido experiencias al respecto y es un autentico fenómeno a estudiar como cambia la aptitud de los miembros de un equipo que trabajan sin ninguna metodología explicita, al implantar una metodología (especialmente las ágiles). Muchos de ellos tienen la sensación de que su trabajo no se valora porque no es visible, lo cual acaba implantando un “comunismo” asesino de la eficiencia.

Podemos decir que los buenos profesionales necesitan visibilidad y que la metodología aporta visibilidad…así que la cosa está clara.

Permitiendo la colaboración TFS a través de plataformas heterogéneas

Andoni Arroyo — Mon, 09 Nov 2009 22:42:54 GMT

Microsoft anunció ayer que comprará los activos relacionados con Teamprise de SourceGear LLC. Este software permiten a los desarrolladores usar el IDE de Eclipse (que opera en varios sistemas operativos, incluyendo UNIX, Linux y Mac OS X...), para construir aplicaciones que se comunican con Microsoft Visual Studio Team Foundation Server. Esta combinación permitirá a los desarrolladores utilizar una única herramienta para la gestión de ciclo de vida de proyectos con independencia de la plataforma de desarrollo.

Seguro esta característica va a permitir a muchos desarrolladores de mundos tan “separados” comenzar a unificar esfuerzos, reducir la brecha que nos separa y de paso hacer TFS más potente. Estoy deseando hablar con algunos Javeros muy interesantes que conozco a ver si les convenzo para probarlo.

Más información por aquí

¿Qué hace un tecnólogo como tú en una crisis como ésta?

Andoni Arroyo — Wed, 16 Sep 2009 07:14:00 GMT

Estamos en lo que parece el ecuador de la crisis económica mundial. Los que ya peinamos alguna que otra cana ya hemos pasado por esto antes y probablemente pasaremos por alguna más. Ya conocemos como se comporta el mercado y os apuesto lo que queráis a que, aunque pase la dichosa crisis, el tiempo de reacción de las empresas de tecnología hacia sus currillos (y la de los clientes hacia las empresas) se estirará lo más posible.

Nos guste o no tenemos que mover ficha. De hecho, tenemos que hacer ajustes para corregir un problema que ni hemos creado ni podíamos haber evitado... Con el fin de adecuarnos a la situación, debemos ser especialmente cuidadosos en algunos aspectos de nuestro día a día, sobre todo, con los directamente o indirectamente relacionados con los (escasos) presupuestos que manejamos.

Ajusta y maximiza más que nunca los recursos
Puede ser un momento interesante para transmitir al cuadro directivo la necesidad de introducir/mejorar la metodología a emplear en los desarrollos. Argumentado las ventajas de la misma, las empresas suelen estar más receptivas a las mejoras, sobre todo si estas implican poca (o nula) inversión. Mantener una buena visibilidad es un aspecto clave para que los stakeholders analicen mejor que nunca en que se invierten los recursos.
Céntrate en lo importante
No es nada nuevo, lo deberíamos hacer siempre y las metodologías ágiles se cansan de repetirlo. El riesgo de que los proyectos se trunquen a medio camino es más alto en época de inestabilidad. Los presupuestos se aprueban para los diferentes ejercicios y puede ocurrir que un proyecto se paralice o cancele.
Priorizar las funcionalidades que más valor aportan, así como evaluar con detalle aspectos de más difícil R.O.I. (Creación de Frameworks, metalenguajes, diseñadores…) siempre es importante, pero ahora se vuelve crítico.
Tomate tiempo para apoyar a la fuerza comercial
Vender siempre es difícil, vender Software o servicios de I.T. siempre es muy difícil, pero es que en épocas duras se convierte en una acción titánica. Los comerciales e ingenieros comerciales involucrados en las acciones de preventa necesitan justificar y explicar más claramente que nunca porque el cliente debe invertir en el servicio que ofrecemos.
No escatimes en apoyar con argumentos tecnológicos las soluciones ofrecidas, puesto que cada venta es una batalla y todas las justificaciones que tengamos a mano serán muy apreciadas.
Valora la posibilidad de emplear soluciones estándar
Potencia el R.A.D. Intenta recortar los tiempos de desarrollo evitando en la medida de los posible los desarrollos a medida desde cero. Probablemente existan soluciones, bien creadas por Microsoft o terceros, para la mayoría de problemas a solucionar. Esto te permite centrarte en la funcionalidad que realmente aporta valor. Es increíble la cantidad de funcionalidad común que está a mano y no empleamos por no tomarnos el tiempo en evaluarla...
Re-evalúa las infraestructuras
Probablemente el súper C.P.D. diseñado en los momentos de vacas gordas pueda ser sustituido (antes de realizar la inversión a poder ser ;)) por un sistema en Cloud que reduzca el coste total del proyecto de manera significativa. O quizás explicando en detalle el coste que supone cierto grado de disponibilidad de una funcionalidad, esta no le parezca tan importante al cliente…
Revisar aquella certificación para la que nunca tenias tiempo
Si tienes un poco más de tiempo de lo habitual, ten en mente que las crisis no son eternas, pasan y cuando se levante el telón los mejor preparados podrán aprovechar el tirón para reclamar los mejores puestos que vuelva a ofrecer el mercado.

Lo que nunca debemos hacer es caer en el desánimo, estamos en esto porque es nuestra profesión y además porque nos gusta, que se note!

La historia del zapatero de Ikea y la perspectiva del proyecto

Andoni Arroyo — Thu, 10 Sep 2009 23:53:48 GMT

La historia que os voy a contar está basada en hechos reales. Aprovechando que tengo unos días libres antes de salir de viaje me he dispuesto a acabar con la fila india de zapatos que tengo por casa. Así que ni corto ni perezoso me fui al Ikea y me cogí un zapatero de esos tan apañado que te montas en casa.

Me puse manos a la obra y decidí seguir las instrucciones que tan amablemente incluyen los suecos a modo de ”paso a paso”. Tras una revisión previa combinada con mis nulos conocimientos en bricolaje y ebanistería, me decidí a seguir los pasos indicados al pie de la letra. El resultado, os lo podréis imaginar, un zapatero impresionante con una de las tablas del frontal colocada al revés, es decir, un precioso acabado en madera virgen…

Me ha dado por pensar los motivos de este pequeño desastre y la analogía de los mismos en los proyectos de desarrollo de Software. Podemos decir que yo he sido el programador currillo que he recibido una serie de pequeñas tareas bien definidas. Estas tareas fueron creadas por un gran analista sueco como resultado de un diseño basado en el análisis de la funcionalidad a cubrir.

Por supuesto, no tengo ninguna duda de que el señor analista sueco creó las tareas de manera correcta en su contexto y en su momento. Lamentablemente en el proceso de “codificación” de mi zapatero se han dado algunas circunstancias inesperadas.

Errores humanos
Tras comprobar de nuevo las instrucciones observo que no se especifica explícitamente el lado que debe dar hacia el frontal y cual no. Obviamente mi decisión no fue la correcta.
Falta de comunicación
La verdad es que el analista sueco no me pillaba lo suficientemente a mano para completar las dudas que me surgían sobre el manual mientras avanzaba el desarrollo del proyecto.
Falta de perspectiva e interiorización del alcance global del proyecto

Falta de revisiones
Una pequeña revisión al finalizar cada paso o conjunto de pasos podría haber evitado la desviación. Esto me habría limitado la cantidad de pasos a deshacer para recolocar el maldito madero y por lo tanto, el esfuerzo (dinero en proyectos reales) malgastado en problemas que yo mismo me he buscado.

En el mundo del Software tanto las especificaciones como los entregables son más abstractos. Si no comprendemos bien las necesidades del cliente, (las que nos transmite y las que ni él mismo ha identificado aún!) podemos llegar a las oficinas del cliente con un software que le produzca mas enfado que satisfacción. Dichas necesidades en la mayoría de ocasiones nos son totalmente ajenas y desconocidas puesto que no conocemos profundamente el sector del cliente (Al menos en los primeros proyectos tipo!).

Sin trabajar este proceso de interiorización apoyado en la empatía, podemos entregar el zapatero al cliente sin enterarnos de que tenemos el madero al revés aunque lo estemos mirando con todo detalle...

Así que dicho queda, me voy a por la caja de herramientas de nuevo…

Desarrollador con calidad vale por dos (o más...)

Andoni Arroyo — Sun, 30 Aug 2009 20:05:00 GMT

Las metodologías ágiles nos recomiendan centrar nuestros esfuerzos en aportar valor al cliente. Dicho valor se traslada a través de los entregables que el equipo va liberando en las diferentes iteraciones. En el mundo del desarrollo de aplicaciones informáticas, el más importante de todos los artefactos que entregamos es el Software. Y este software se genera desde el código que generan los miembros del equipo.

Bueno eso este claro. Y que menos se puede pedir al equipo que se aplique al máximo con el código que genera? Como desarrollador de software el código es tu producto final, y este debe ser desarrollado con la máxima calidad que nos sea posible.

Algo que todos (los que entendemos como funciona el negocio del desarrollo de software..) tenemos claro, es que es más rentable asegurar al calidad de nuestros desarrollos desde las primeras etapas del proceso en vez de corregir los errores más tarde. El impacto de los errores crece exponencialmente cuanto más tarde se descubren.

Por lo tanto, como desarrolladores profesionales que somos, debemos poner especial hincapié en mantener presente la calidad en nuestros proyectos. Es fácil de decir, pero como a menudo, no tan fácil de conseguir…

Existen algunos grupos de problemas comunes que podemos identificar como focos problemáticos:

Comunicación pobre y malas interpretaciones
La capacidad de comunicación del ser humano es uno de los factores que le diferencia del resto de las especies. El grado de abstracción que podemos aplicar a la misma es muy alto. Esta característica, nos permite transmitir mucha información de manera muy efectiva.

Por ejemplo, si yo te digo, singelton, grano fino, o capa de servicios y ambos tenemos un conocimiento equivalente en la materia, hemos conseguido transmitir una serie de conceptos más o menos complejos de manera optimizada.

Es una herramienta potente, pero que debemos cuidar para evitar desviaciones igual de potentes. La comunicación debe ser clara y fluida, asegurando que el receptor ha comprendido el mensaje en la misma dimensión que deseamos emitirlo. No se debe escatimar en comunicación funcional, técnica, recabar feedback del equipo y aplicar un poco de psicología (la empatía puede ser la clave). Colaborar en este juego es parte de la tarea de cualquier miembro de un equipo.
Errores de programación
Las personas escriben código y las personas comenten errores. Ergo…el código tiene errores (ahora no abusemos del mismo para hacer chapuzas diciendo es intrínseco el error en la persona...)

Escribir buen código no es fácil. Debemos tener en cuenta aspectos como seguridad, rendimiento, localización, mantenibilidad... y en tiempo record!

Aunque apoyarnos en el CLR ayuda, siempre existirán bugs que tendremos que corregir y realizar mantenimiento sobre el mismo. Y esto ocurre haciendo las cosas todo lo bien que podemos, esforzándonos al máximo como desarrolladores. Imagínate si no lo hacemos así…
Falta de realimentación de pruebas
Escribir pruebas unitarias es un trabajo que (casi) no aporta visibilidad. Lleva tiempo y no es código fácil de reutilizar. Aunque los desarrolladores sabemos que debemos escribirlas y esforzarnos y alcanzar la cobertura d código marcada por los parámetros de calidad del proyecto, a menudo nos enfrentamos a desincentivos que tientan a no realizarlas. Pero lo que es seguro, es que sin un buen conjunto de pruebas, (no tiene que ser muchas pero si bien diseñadas) es muy fácil cambiar código y no descubrir los efectos secundarios no deseados hasta demasiado tarde. (vamos creando un coladero…)
Versión distorsionada
Gracias a la metodología al principio, y a las herramientas de control de código fuente, más adelante no se han producido millones de asesinatos entre los desarrolladores. Aún así existen archivos y configuraciones de puestos que no son propios del código fuente cuyas diferencias producen errores que son difíciles de diagnosticar. Cuantas veces hemos oído eso de "En mi máquina funcionaba!".
Falta de transparencia
Para desarrollar un proyecto con éxito hace falta todo. Como una de las piezas falle o no se comunique adecuadamente todo el proyecto se puede venir abajo como un castillo de naipes. Tradicionalmente, han sido mundos diferentes (e inconexos!!) aspectos como la infraestructura de desarrollo, el sistema de gestión del proyecto, el trazado de requisitos/errores, métricas...(Intenta sincronizar el s.v.n. con el Visio que se sacó tu gerente de la manga...;))
En esta situación, el equipo tiene poca visibilidad respecto al estado global del proyecto. (aparte de los odiados y poco fiables informes de estado...)

Cada una de estas cinco categorías son un foco potencial de problemas que afectan directamente a la calidad del código realizado. Esto implica que el mecanismo que el cliente emplea para evaluar el valor aportado, tiene problemas que afectan, directamente, a las sensaciones que transmitimos. La aparición de herramientas que nos permiten gestionar todos los aspectos relacionados con el desarrollo de manera orquestada vienen a facilitarnos la vida, y conocer sus posibilidades es un esfuerzo con seguro retorno de inversión.

Por nosotros que no quede...

Dulce introducción al Kanban!!

Andoni Arroyo — Wed, 12 Aug 2009 12:23:00 GMT

Bueno, parece que SCRUM ha puesto la pica en Flandes y se ha convertido en una metodología ampliamente conocida y respetada. Pues ya está, no? ya tenemos metodología ágil para cualquier tipo de proyecto y para siempre…

Muy confiado tienes que ser para creerte eso…

En mi trabajo hemos desarrollado un producto aplicando SCRUM con unos resultados muy satisfactorios. Dicho producto, se ha comenzado a implantar y ahora entra un equipo de soporte a mantener la primera versión del mismo y comienza una nueva rama de desarrollo de la siguiente versión.

Estaba planteándome como organizar el equipo de soporte y no acababa de encajar SCRUM sobre la naturaleza de su trabajo (la verdad que esta y cualquier otra metodología…). Es muy difícil organizarse para planificar incluso un pequeño Sprint, puesto que no se conocen las tareas de antemano. Por lo tanto, llegué a la conclusión de que necesitamos para este tipo de proyectos (que no son pocos) algo todavía más adaptable que SCRUM…

Tomando un café con el gran (aunque javero) Jorge Prieto me comentó algo sobre Kanban y comencé a tirar del hilo para ver si me podía cuadrar eso que sonaba a pescado crudo…

Así que vamos a aprovechar este post para explicar que es eso de Kanban compararlo con SCRUM e identificar sus conflictos potenciales. Antes que meternos en harina vamos a dejar las cosas claras, haciendo un pequeño resumen de SCRUM y Kanban

SCRUM (en pocas palabras)

Divide su organización en pequeños equipos auto-organizados y multidisciplinares.
Divide el trabajo en una lista de pequeños elementos muy concretos.
Ordenar la lista por orden de prioridad y estimar el esfuerzo relativo de cada elemento.
Dividido en iteraciones cortas de longitud fija (normalmente con entrega o demostración después de cada iteración.)
Optimizar el plan de liberación y actualizar las prioridades en colaboración con el cliente, sobre la base de conocimientos adquiridos por la inspección de la entrega después de cada iteración.
Optimizar el proceso por tener una retrospectiva después de cada iteración.

Resumiendo el resumen:

Pasamos de “Muchas personas haciendo algo muy grande” a “Pocas personas haciendo cosas pequeñas que se integran con regularidad para ver el conjunto.”

Kanbas (en pocas palabras también)

Visualizar el flujo de trabajo
Dividir el trabajo en trozos escribir cada uno de los elementos en una tarjeta y poner en la pared.
Usar el nombre o columnas para ilustrar en que estado se encuentra cada elemento dentro del flujo de trabajo.
Límitar WIP (Work In Progress)
Asignar límites explícitos obre cuantos elementos pueden estar en cada uno de los estados del flujo de trabajo.
Medir el tiempo
Contar el tiempo promedio para completar un tema, a veces llamado "tiempo de ciclo" y, como es obvio, optimizar el proceso para que el tiempo tan pequeño y previsible como sea posible.

Podemos observar que Kanban es todavía menos prescriptivo que SCRUM.

Prescriptivo significa “reglas para seguir”. 100% prescriptivo implica que no tienes que usar el cerebro, ridículo verdad?…) y en este apartado vemos que SCRUM aporta mas reglas “out-of-the-box” como por ejemplo encajar en un tiempo los Sprints cosa que Kanban no hace.

Para hacernos una mejor composición podemos observar la escala de “prescriptividad” (toma ya!) de forma gráfica:

Como siempre podemos decir que la mejor opción es no limitarse a un herramienta en concreto. Probablemente la solución nuestros problemas se encuentre en una combinación de varias. Muchos equipo Kanban realizan una reunión diaria a primera hora (típica liturgia de SCRUM). Algunos equipos de SCRUM que he conocido, escriben su Backlog como Casos de Uso (típico de RUP) o limitan el tamaño de las colas (típico de Kanbas).

Así que como siempre “haz las cosas como mejor te funcionen”, ya os contaré el resultado de aplicar esta forma de trabajo con el equipo de soporte.

Para terminar os cito a Miyamoto Musashi que los japoneses algo saben de todo esto:

“No desarrolles ninguna dependencia de arma o escuela de lucha”

¿Por que iterar?

Andoni Arroyo — Sun, 09 Aug 2009 22:14:29 GMT

Aplicando el patrón C.S.P. (Common Sense Pattern…) en nuestros desarrollos, observamos que debemos cumplir con las necesidades del cliente. Acto seguido, descubrimos, que estas cambian más que los nos gustaría (ouchh!). Por lo tanto, se crea la necesidad de ir ajustando el avance del proyecto a las necesidades reales (y cambiantes) del proyecto.

¿Pero como…?

La respuesta que nos aportan las metodologías agiles es sencilla, iterando. Partiendo el desarrollo de la aplicación en pequeños entregables que el usuario pueda probar e ir enriqueciendo. Suena lógico, pero vamos a hacer un esfuerzo de plasmar negro sobre blanco las principales ventajas que esta forma de trabajar nos ofrece:

Gestión de riesgos
Asumámoslo, el resultado deseado no es concebible por adelantado. Existen riesgos, algunos ya identificados y otros por identificar. Para gestionarlos correctamente debes demostrar o refutar tus requisitos y diseñar las suposiciones implementando incrementalmente elementos que son objetivos del sistema, empezando con los de más alto riesgo.
Económicos
En un ambiente de negocio incierto (~~casi~~ todos los proyectos lo son !!) es clave optimizar los esfuerzos en las mayores prioridades del proyecto. Debemos manejar cada iteración como un conjunto de fichas de juego a apostar por un conjunto de funcionalidad que se pueda entregar, probar y que funcionen.
Enfoque
Solo podemos mantener una cantidad limitada de elementos en la mente. Trabajando con pequeños lotes de trabajo podemos focalizar nuestros esfuerzos con un conjunto de funcionalidades que comprendemos y somos capaces de encajar y entender.
Motivación
No existe un mecanismo mejor de motivación de acción prolongada (el dinero solo motiva en un espacio reducido de tiempo!!) para un profesional que comprobar como su creación se usa, es efectivo y valorado por los usuarios.
Control de la teoría
Las iteraciones nos permiten controlar mejor las desviaciones, reduciendo el impacto de los errores en las estimaciones y crear un mecanismo de retroalimentación sobre los planes del proyecto.
Implicación de los interesados
Los patrocinadores (clientes, usuarios, dirección…) pueden observar los resultados más rápidamente (cumpliendo así con la visibilidad, requisito fundamental de cualquier desarrollo) y así aportar mayor compromiso, implicación y financiación.
Aprendizaje continuo
Todos los actores del proyecto aprenden en cada iteración. Los miembros del equipo adquieren conocimiento funcional y aportan mejoras desde la prospectiva tecnológica y los funcionales comprenden las implicaciones de automatizar los procesos empresariales. Todos aportan y el proyecto crece rápido y mejora.

Ya tenemos un conjunto de argumentos para convencer a los stakeholders más peleones acerca de las bondades de trabajar en pequeñas iteraciones, ahora el que quiera entender que entienda…

Reflexión "reposada" sobre las metodologías ágiles

Andoni Arroyo — Wed, 05 Aug 2009 08:04:00 GMT

A lo largo de los años de experiencia que tengo en el sector de la informática he visto pasar muchas tendencias de largo. Algunas eran buenas ideas mal planteadas, (otras malas directamente) que simplemente no consiguen hacerse un hueco en la comunidad de stakeholders implicados.

En ocasiones han fracasado porque cargaban la balanza de un único lado dejando fuera a la otra parte del negocio. Nos guste o no, estamos obligados a entendernos puesto que en esto que este negocio de la informática tan importante es vender como desarrollar. Como una de las dos partes de la ecuación se sienta fuera del juego nunca una metodología podrá cuajar a alto nivel.

Hace ya un tiempo que estamos oyendo hablar de las metodologías ágiles y con la perspectiva que nos da el tiempo, podemos decir que estas tienen algún que otro as en la manga que las pueden hacer triunfar donde otras fracasaron. (Es verdad que la cosa es más fácil cuando el vecino ya se ha pelado la barba…)

Podemos decir que las cosas están cambiando y más rápido de lo esperado.

Poco a poco, el sector del desarrollo del software se va haciendo un hombrecito. Desde luego este proceso no se ha pospuesto por falta de esfuerzos. La industria, cual madre concienciada, haciendo palanca a través de la Ingeniería del Software ha intentado estandarizar de muchas maneras el “artístico” proceso de crear software. Algunos de estos intentos han sido más forzados que otras (UML, CMMI, Métricas de calidad… ), pero casi todos, por diversos motivos, han demostrado la misma poca efectividad. (Por cierto el VS2010 incluye soporte para los 6 documentos principales de UML!!)

Dichos intentos “encauzadores” de mamá industria han quedado a medio camino por la misma razón, partían de un axioma equivocado:

Todas las metodologías predictivas asumen el resultado del proceso de análisis y diseño como verdades inmutables que constituyen los cimientos sobre los que edificar el resto del proyecto.

Centrando sus esfuerzos en conseguir un terreno firme en el que apoyarse, la realidad, obstinada, nos demuestra que realmente lo hacían sobre arenas movedizas. No por que el resultado de tales esfuerzos estuviera mal hecho (existen toneladas de documentación sobre como optimizar el proceso de toma de requisitos…) sino por simplificar en exceso el contexto (desestimando el factor cambiante) de cualquier proyecto de Software.

¿Cuantas veces nos ha ocurrido al terminar un proyecto que si lo volviésemos a empezar lo atacaríamos de otra forma…? En relación a otras ciencias (y entornos productivo-económicos) el desarrollo de software avanza muy rápido obligándonos a descartar metodologías de éxito en otros ámbitos por la naturaleza de nuestro negocio.

Alcanzar esta velocidad de crucero implica que hay mucho que mejorar y obliga al sector a reinventarse continuamente. La tecnología, los modelos de negocio, el alcance de la funcionalidad de las aplicaciones, la automatización de procesos, la integración y orquestación de unidades de negocio… todo está en ebullición. Como todos sabemos, no se puede estandarizar lo que no deja de cambiar, por lo que los intentos realizados se han ido quedando anticuados antes de alcanzar su madurez.

Pero en ese reinventarse ha cambiado la perspectiva…

Un buen día nos damos cuenta de que estamos peleando contra la realidad. Nos liberamos y dejemos de atacar y evitar el cambio como un enemigo. Es una actitud provocada por el convencimiento que surge desde dentro de que no hay otra opción. Debemos asumir (cuanto antes mejor) el cambio como algo que está ahí, nos guste o no, no podemos evitarlo. ¡¡Todo cambia!!

En las metodologías predictivas se destinan gran parte de los recursos a ser capaz de predecir lo que se va a desarrollar en los próximos años. Por muy concienzudo que sea dicho estudio, el contexto varía, las necesidades del cliente cambian, surgen nuevas oportunidades y riesgos. El que mayor capacidad de cambio demuestre, contará con una ventaja competitiva significativa.

Por lo tanto, permitir que nuestro cliente marque el siguiente paso a dar (o mejor dicho, pasito…) nos permite alinear el camino a recorrer con las necesidades del cliente que sobre la marcha surjan, aportando un mayor valor al software y satisfacción al cliente, que es (o debería ser) nuestro objetivo.

8 maneras de cargarte la metodología de un plumazo!!

Andoni Arroyo — Thu, 23 Jul 2009 08:02:00 GMT

No es fácil implantar una manera común de desarrollar proyectos de Software. Cada maestrillo tiene su librillo y no siempre nos es fácil adaptarnos al mínimo común necesario para trabajar en equipo de manera orquestada.

Por contra, lo que sí que es realmente fácil , es dinamitar el camino andado. Hace falta muy poco para saltarse alguna que otra regla y echar abajo lo ganado con tanto esfuerzo. Existen algunos puntos claves en los que los equipos somos especialmente propensos a ceder, veamos algunos…

(*Hablando en SCRUM)

No preparar suficiente Product Backlog para que el equipo adquiera prespectiva del proyecto.
Aunque parezca mentira a los desarrolladores nos gusta saber qué leches estamos programando. De hecho las mejores propuestas de mejora de las aplicaciones surgen, al menos en las primeras fases del proyecto, del propio equipo de desarrollo. Para poder aprovechar toda esa energía/sinergia los desarrolladores deben poder hacerse una idea global del proyecto.
No profundizar lo suficiente el el Sprint Planning Meeting por cansancio o falta de concrección en la exposición del Product Owner.
La reunión previa en cada sprint permite al equipo hacerse una idea lo más concreta posible de las funcionalidades que más valor aportan al proyecto. Nos permite alinearnos con las necesidades del cliente de tal forma que todos aunemos esfuerzos en la misma dirección. También permite mitigar los riesgos e identificar sorpresar antes de asumir un compromiso. Un buen hábito que no siempre se realiza es el de poner una meta al sprint ( por ejemplo “Disponer del sistema de automatización de informes” ) que identifique la situación ideal al final del mismo y ayude al desarrollador a responder preguntas que le “tienten” por el camino. (¿Es esto importante para la meta del sprint?)
Falta sistemáticamente al Daily Scrum o no respetar sin aviso las pocas liturgias que especifica SCRUM.
Una de las características que hace a SCRUM “medio” bala de plata tan demandada por los desarrolladores, es las pocas imposiciones que propone. De éstas, una de las más importantes, es la de realizar una pequeña reunión diaria en al que cada miembro del equipo explica que ha hecho el día anterior, que impedimentos se ha encontrado y que pretende hacer en el mismo día de la reunión. Este Daily Scrum es el que da jabón al equipo y permite que todo el mundo este al día del avance, evitar duplicar batallas…
Estancar conocimiento asumiendo un mismo desarrollador todas las Sprint Backlog Item de un Product Backlog Item.
Es importante que nadie sea imprescindible. Que todos los miembros del equipo desarrollen tareas de todos los Product Backlog Items permite evitar que se creen “Reinos de Taifas” y estandariza el código. Además los equipos de desarrollo con un poco de verguenza torera se igualan por el mejor, lo que permite que se produzca aprendizaje por el camino, mejorando la calidad final del proyecto.
Inventarse tareas sobre la marcha o modificar las existentes bajo demanda.
Cuando un equipo de SCRUM asume un compromiso con el cliente a través de un sprint, dicho compromiso es inmutable por ambas partes. Es por esto que los sprints son tan cortos, para permitir reorientar el proyecto entre sprints.
Intentar esconder las desviaciones o sufrir el “sindrome del investigador“.
Si existen desviaciones, lo mejor es saberlo y ser consciente de las causas que las han provocado. En la mayoría de ocasiones dichas desviaciones se pueden justificar y son el argumento principal para mejorar los procesos del equipo. Otro de los aspectos que debe afrontar cualquier metodología es lograr una adecuada visibilidad. Esta característica es la que debe permitir permite que los StakeHolders conocozcan la situación del proyecto. Adoptar una visibilidad adecuada permite detectar las desviacioes de manera temprana así como planificar las acciones orientadas a corregirlas. Como equipo debemos ser capaces de justificarlas y transmitir los motivos a los StakeHolders adecuados, así como las acciones y planes creados. Suele ser un buen hábito, especificar a nivel de Product Backlog Item las condiciones de aceptación, en las cuales se especifican las poscondicones necesarias para que una historia pueda darse por terminada. Por supuesto, deben cumplirse todas para que se pueda dar por finalizada.
No retroalimentar Sprint Backlog Items después de realizarlos.
Es verdad que siempre vamos con prisa, que existen muchas tareas y todas las excusas que quieras poner, pero para poder decir “Hecho” (y hecho es hecho!!) cada desarrollador debe actualizar como parte de la tarea el estado de los Sprint Backlog Items asociados. Mantener al día dicha información nos permite, analizar las desviaciones y observar la tendencia del sprint y el producto. Colateralmente nos ayuda a ganar y mantener la visibilidad del proyecto manteniendo a los diferentes StakeHolder lo más al día posible.
Evitar las Sprint Retrospective o demostrar falta de compromiso.
En SCRUM la unión y el compromiso del equipo es clave puesto que todos los miembre del mismo interactuan ampliamente con los demás. El Sprint Retrosprective es la liturgia clave para recibir feedback del mismo y aumentar la unión y sentimiento de grupo. Estas reuniones pueden mejorar mucho los procesos afinando el día a día del equipo, identificando los posibles cuellos de botella y planificando como evitarlos.
Como siempre, la clave es la constancia, no ceder al desaliento y aplicar las técnicas espartanas de confianza en tus compañeros de equipo. Solo así se puede lograr el “milagro” de echar a andar y mantener una forma de trabajo metodológica.

Como siempre, la clave es la constancia, no ceder al desaliento y aplicar las técnicas espartanas de confianza en tus compañeros de equipo. Solo así se puede lograr el “milagro” de echar a andar y mantener una forma de trabajo metodológica.

Como incluir un fichero en el resultado de una prueba unitaria en Visual Studio 2008

Andoni Arroyo — Wed, 22 Jul 2009 15:28:00 GMT

Existen ocasiones en las que nos puede interesar que una prueba unitaria incluya un determinado recurso. Esto ocurre cuando el código que deseamos testear cuenta con la existencia , por ejemplo, de un determinado fichero de texto, una hoja de cálculo o una Service-based Database (.mdf)

Como sabeis, el resultado del proceso de test genera una nueva carpeta (TestResults) donde incluye el resultado de cada generación. Si dicho resultado cuenta con una referencia relativa (la mejor manera de hacerlo) hacia un recurso pues ya la tenemos liada...

Pero como siempre (o casi) la solución es más facil de lo que parece. Existe un decorador especialmente creado para esta necesidad. Basta con colocar sobre el método que deseamos incluya el recurso el item de despliegue de la siguiente manera:

[TestMethod()]
[DeploymentItem(@".\fichero.xls")]
public int EjemploTest()
{
...

(.\ si está en la raiz claro...)

Por supuesto los más inquietos ya se estan preguntando como evitar tener que incluir este decorador en todos los métodos (especialmente interesante si se trata de una Service-based Database (mdf)).

Pues para esto también existe una facil solución. Basta con incluir el recurso en el ficheroLocalTestRun.testrunconfig dentro del elemento Deployment con la siguiente sintaxis:

\[Nombre del proyecto]\[Nombre del recurso]

y ya podemos quitar el decorador.

Por cierto, si deseais incluir un fichero Service-based Database (mdf) en una prueba unitaria y referenciarlo con una cadena de conexión del estilo: "..AttachDbFilename=|DataDirectory|.." necesitais tenerinstalado el SP1 de VisualStudio 2008. Sin este, la referencia se realiza directamente contra en .Net Framewok y no encontrará el recurso.