Entendiendo la Deuda técnica

Más de una vez nos ha pasado de estar en la encrucijada de tener que decidir si resolvemos una funcionalidad de la forma más rápida pero no tan ordenada o elegante - aún sabiendo que en algún momento habrá que modificarlo , o hacerlo más ordenado y prolijo pero sabiendo que llevará más tiempo en terminarse.

Cualquiera de las dos opciones tiene sus consecuencias pero podríamos decir que en muchas oportunidades la urgencia del cliente tiene mucho peso y terminamos decidiendo por el camino más corto.

Ese tipo de soluciones - que trasladan al futuro cambios que pueden ser más costosos que haberlos implementado en el momento -  pueden considerarse deudas técnicas y las mismas pueden resultar en altas tasas de defectos, baja velocidad de respuesta, baja calidad del producto, baja productividad, problemas de mantenimiento, entre otros. Y no debemos olvidar los costos en el presupuesto.

Las deudas técnicas pueden estar relacionadas con distintos aspectos del desarrollo: algunas pueden ser debido al código (código repetido, complejo, difícil de entender y mantener, etc.), al entorno de desarrollo, la plataforma usada, el diseño, testing automatizado y demás.

Ward Cunningham utilizó una metáfora comparando este tipo de problemas del desarrollo de software con una deuda financiera. Es decir, queremos pagar la deuda con sus intereses en el futuro o pagamos el costo completo en el presente?

Esta metáfora también "justifica" que en determinadas circunstancias la elección de la solución rápida puede ser la adecuada cuando, por ejemplo, se quiere aprovechar una oportunidad de mercado, lo que en el desarrollo de software podríamos traducir como llegar a una fecha límite.

Creo que el mayor dilema en estos casos es saber cómo administrar las deudas técnicas y tratar de determinar a qué tipo de deuda nos estamos enfrentando para tener idea de la gravedad de la misma.

Algo que puede ser útil para esto es el Cuadrante de la deuda técnia creado por Martin Fowler.

Este cuadrante podría usarse para decir qué tipos de deudas son aceptables o no y usar esta información para establecer tácticas que nos permitan prevenir conductas o patrones inaceptables.

Fowler dice que, en realidad, la gran elección no es si tener o no deudas ténicas, sino que la decisión está en tomar Deudas Prudentes o Deudas Imprudentes. Además de determinar si son Deliberadas o Inadvertidas.

Una deuda Prudente y Deliberada se da cuando el equipo sabe que está incurriendo en esa deuda y supone una evaluación del costo futuro vs. el costo actual. Este tipo de deuda se considera "positiva" y su administración se hace más simple.

Las deudas Prudentes pero Inadvertidas suelen darse en casi todos los proyectos, dado que a medida que se va desarrollando los miembros del equipo van haciendo un aprendizaje que les permite darse cuenta que hay cosas que podrían haberse hecho mejor. Mucho más se da este fenómeno si el equipo cuenta con miembros menos experimentados. En estos casos lo importante es "pesar" si vale la pena corregir lo ya hecho o qué cosas puntuales sí deberían modificarse, según el impacto que puedan acarrear.
Para Fowler este tipo de deudas son inevitables y desde el inicio del proyecto todos deberían estar advertidos de su posible aparición.

Las deudas imprudentes suelen ser tomadas por equipos que desconocen las prácticas de diseño dado que no tienen la capacidad de evaluar cuál será el costo futuro.

Una deuda imprudente y advertida puede ser un caso muy peligroso. Se da cuando el equipo, aún teniendo conocimientos de buenas prácticas, decide que escribiendo un código más limpio no puede cumplir con los tiempos requeridos. Son muchos los factores que pueden llevar a tomar esta decisión:

• mala gestión, 
• presiones innecesarias, 
• problemas en el equipo interno, etc..

Acumular este tipo de deudas implica que la calidad del producto va a ser muy baja.

Por otro lado, el creer que escribir un código desprolijo es más rápido que hacer un código limpio es un error.
La aplicación de las buenas prácticas tienden justamente a que el desarrollo sea, a la larga, más rápido y el código mucho más confiable.

Las deudas imprudentes no deberían ser, además, inadvertidas porque la acumulación de las mismas llevaría al fracaso del proyecto. En general este tipo de deudas salen a la luz por inexperiencia o falta de conocimientos del equipo o de los responsables.
Ocurre en general cuando los desarrolladores no tienen noción de las implicancias de cambiar una parte del código. Este tipo de deudas deben ser administradas con mucho cuidado.

Srinath Ramakrishnan en su artículo Managing Technical Debt sugiere la utilización de herramientas como pair programming, code reviews, integración continua, testing automatizado, etc.:

"La clave para administrar deudas técnicas es estar constantemente vigilante, evitar usar atajos en el código, usar diseños de aplicaciones lo más simple posible, hacer refactoring frecuente. "


Artículos de interés:

Managing Technical Debt
When code is considered Technical Debt
Technical Debt
Deuda Técnica
Uso de técnicas agile para pagar la deuda técnica
La mala calidad del software al final se paga

Twittear        Seguir a @3p_ar

Leer más...

Por qué los rituales son importantes en Agile

Cuando leí este artículo de Len Lagestee sobre los rituales en Agile recordé una reunión de equipo que tuvimos hace algunos años donde revisábamos nuestra práctica de Scrum cuando recién empezábamos. Una de las conclusiones a las que llegamos en ese momento fue que los rituales de Scrum, en nuestro caso, son tan pocos y tan simples que no tiene sentido querer "darles una vuelta" o tratar de adaptarlos. Scrum es eso y cualquier cambio que se le quiera agregar lo convierte en otra cosa. Y lo mismo aplica a cualquier otro método ágil.

Con el tiempo y hablando con gente de otros equipos noté que eso que nosotros intentábamos (tal vez cierta resistencia inconciente?) es bastante común entre quienes empiezan con un cambio de metodología: queremos hacer una "adaptación libre" o una versión ajustada de la práctica. Es por eso que me pareció interesante resumir los conceptos de Len Lagestee sobre la importancia de respetar y mantener los rituales en de las metodologías ágiles.

Según Lagestee, una de las primeras dudas o quejas que despierta la práctica de metodologías ágiles es "la cantidad" de reuniones, dependiendo dle método las típicas son: planificación, daily stand-up, revisión del sprint o demostración, retrospectiva, revisión del backlog. El sólo hecho de pensar en tantas reuniones lleva a decir que "no habrá tiempo para trabajar". En estos casos es donde el autor subraya justamente la importancia de mantener estas prácticas: el tiempo que un equipo comparte junto, con un ritmo recurrente y consistente, es donde se fomentan las bases de los rituales de ese equipo.
En este punto Lagestee resalta una definición de wikipedia al respecto:

"los rituales hacen a la tradición de una comunidad"

http://milindageorge.files.wordpress.com/2013/03/scrum-team.png

Continúa diciendo Lagestee en su artículo que concretamente la importancia de los rituales está dada porque los mismos refuerzan las tradiciones de:

• Reconocer el pasado: las retrospectivas permiten aprender de la experiencia pasada en un sano entorno de "comunidad". El equipo es el que aprende a corregir su propio rumbo. 
• Marcar nuevos comienzos: más allá de las conclusiones sacadas para el sprint pasado, la planificación de un nuevos sprint permite a la "comunidad" (es decir, al equipo) centrarse en lo que viene por delante.
• Tomar decisiones: la reunión de planificación y el timeboxing establecen la tradición de las "decisiones" => "podemos como equipo completar estas historias en este sprint o no?"
• Desatar movimiento: las reuniones diarias sirven para poner en movimiento al equipo, trabajando mancomunado desde el inicio del día. Según nuestra experiencia, la reunión diaria establece el espacio explícito donde sabemos que contamos con los otros para darnos una mano cuando estamos complicados con algo.
• Crear conexiones: compartir las reuniones diarias asegura que todos los días haya un punto de conexión entre todo el equipo. Y cuando alguien no esta, se siente la ausencia.  Len Lagestee compara esta práctica con el ritual de la cena en familia: es el momento en que todos se juntan para contar cómo les fue en el día. Puede parecer aburrido o sin sentido hacerlo con tanta frecuencia, pero la realidad es que cuando no se hace, sentimos que algo falta. En la experiencia particular de Tercer Planeta es casi imposible pensar en arrancar el día sin la reunión diaria.
• Celebrar con los demás: las sesiones de revisión del sprint son los momentos donde el equipo puede reconocer y valorar realmente los logros del trabajo en conjunto.

Algo que aclara el autor es que es absolutamente normal al principio sentir que tenemos los días llenos de reuniones, pero al persisitir con el equipo en lograr un punto de verdadera comunidad, estas reuniones se vuelven más y más efectivas y se adoptan naturalmente porque se ven sus beneficios.

Desde nuestra experiencia podemos asegurar que esto es así, nos ha pasado de tener las mismas dudas mencionadas respecto de "tanto tiempo" destinado a reuniones pero hemos comprobado que el tiempo invertido en ellas deja ver sus frutos en la velocidad de producción y en la calidad del producto terminado, entre muchas otras ventajas que nos dan estos rituales.

Why the rituals of agile matter  (por Len Lagestee)

Otro artículo que puede resultar también interesante: La importancia del respeto los rituales  (en Agilmática)


Twittear    Seguir a @3p_ar

Leer más...

SCRUM, problemas en la reunión diaria: qué podemos hacer al respecto?

Internamente muchas veces nos preguntamos si las reuniones diarias están cumpliendo el objetivo que realmente tienen y al leer blogs y foros sobre metodologías ágiles descubrí que muchos equipos tienen los mismos problemas que detectamos puertas adentro.

Revisar objetivos

Para comenzar es bueno recordar cuál es el objetivo y qué debe hacer cada miembro del equipo en una típica reunión diaria.


La reunión diaria tiene como fin el facilitar la transferencia de información y la colaboración entre los miembros del equipo para aumentar su productividad, al poner de manifiesto puntos en que se pueden ayudar unos a otros.


Cada miembro del equipo participa del trabajo que el resto está realizando (dependencias entre tareas, progreso y problemas) para luego de finalizar la reunión poder hacer las adaptaciones que permitan cumplir con las historias que el equipo comprometió para el sprint en curso.

Cada miembro del equipo debe responder las siguientes preguntas en un tiempo estipulado de como máximo 15 minutos:

• ¿Qué he hecho desde la última reunión diaria? ¿ Pude hacer todo lo que tenía planeado? ¿Cuál fue el problema?
• ¿Qué voy a hacer a partir de este momento?
• ¿Qué problemas tengo o voy a tener para cumplir con este sprint y en el proyecto?

Como apoyo a la reunión, el equipo cuenta con la lista de tareas del sprint (sprint backlog) donde se actualiza el estado y el esfuerzo pendiente para cada tarea. 

Con esto se ponen en evidencia los beneficios y restricciones que tiene cada equipo en realizar sus tareas. 

(Para quienes quieran profundizar recomendamos leer "Scrum y XP desde las trincheras")

¿Problemas? ¿Qué problemas?

Si bien la práctica descripta en el párrafo anterior puede ser muy clara y parecer muy simple, nos pasa que, con el correr del tiempo notamos que hay cosas que empiezan a fallar o a sacarnos del eje de lo que indican los libros. ¿Cuáles son esas cosas? Aquí listamos algunos ejemplos de situaciones que pueden presentarse en las reuniones diarias y que pueden ser tratadas durante la misma, así como también recomendaciones recopiladas entre experiencia propia y de otros:


1. Algún miembro del equipo se queda sin tareas dentro del sprint

• Que él mismo elija qué cosas puede hacer para ayudar al equipo (test, documentación, scripts, etc.)
• O decidir entre todos que ayude con otros tipos de tareas, por ejemplo que sea el cadete del grupo. 

2. Falta tiempo para corregir código o hacer una corrección que no produce historias válidas dentro del sprint.

• Bajar el rendimiento del equipo, para poder dedicarle el tiempo suficiente a las tareas de mejoras o correcciones, es decir, plantearse hacer menos historias para el sprint.

3. Ante un proyecto grande con muchos desarrolladores

• Cuando la cantidad de personas en un proyecto es grande, se dispersa mucho la información, lo ideal es armar varios grupos más pequeños de entre 3 y 10 desarrolladores.
• Si hay varios equipos en el mismo proyecto , lo más recomendado sería, un solo project owner (dueño del proyecto), sprint sincronizados para que las demos sean el mismo día, la planificación unificada para repartir las historias y luego cada equipo hace su propia planning poker. Hacer en diferentes horarios las reuniones diarias, para que el project owner esté en todas. La gran ventaja de esta experiencia es que cuando termina cada sprint los miembros del equipo pueden ser intercambiados, o reorganizados minimizando así las dudas y/o problemas. 

4. Llegadas tarde a la reunión diaria

• Elegir una hora buena para todos ( en la generalidad de los casos, se toma como horario de la reunión diaria, entre 15 y 30 minutos posteriores al horarios de inicio de la jornada).
• Si los retrasos son habituales se puede "llenar la alcancía", "traer algo para compartir para todos". Ante la reincidencia eligen hacer que duela un poco más el bolsillo y así tratar de evitar llegar retrasado.  
• Llegar tarde se puede deber al desinterés, con lo cual es válido plantear como alternativa que el propio implicado en los sucesivos retrasos puede exponer sus propias explicaciones ante el grupo y/o alternativas de participación para aumentar su interés. 
• Contar o no qué paso en la reunión o a los que no estuvieron presentes, depende de dos puntos de vista, el interés de escribir en una breve "minuta" sobre lo hablado por el project owner y el otro punto de vista el interés del integrante retrasado en interiorizarse en lo sucedido en la reunión diaria. 

5. Equipo distribuido geográficamente

• Skype, o cualquier vía de comunicación on line conectado permanentemente, reunión diaria del equipo completo, comunicación lo más fluida posible (skype, cámaras web, mail, de ser necesario palomas mensajeras!!!)

En forma anecdótica podemos decir, que en Tercer Planeta, hemos intentado varias de estas recomendaciones, algunas con funcionamiento óptimo y otras en vías de mejoras seguras. 

La más importante que hacemos es la de realizar una reunión diaria del grupo completo, ya sea que pertenezcan o no al mismo proyecto, contándonos en qué estamos cada uno y pidiendo todos los S.O.S. necesarios, esto permite que ninguno de los proyectos quede estancado, reconociendo que no todos sabemos todo. Además de poder contar con ayuda, podemos saber en qué estado está cada uno. A esta reunión diaria grupal general, muy cortita, le siguen las reuniones diarias específicas de cada proyecto en concreto (reuniones de avance). 

Personalmente, la primer reunión diaria es la más saludable y a veces hasta la más esperada por todos, nos permite entender el estado de cada uno, estar al tanto de temas generales del equipo y temas más sociales. Es una manera de mantener la comunicación "viva", más allá de los detalles particulares que presente cada proyecto. 

Twittear Seguir a @3p_ar

Leer más...

¿Se aplica "testing ágil" con metodologías ágiles?

Todos sabemos de qué estamos hablando cuando decimos “proyectos ágiles”. Ahora, ¿Cuándo hablamos de testing, decimos también “testing ágil” ?

Es sabido que ya sea que apliquemos metodologías de trabajo tradicionales o ágiles, los procesos de desarrollo de aplicaciones requieren tareas básicas, a grandes rasgos: análisis, construcción, pruebas, corrección de bugs, implementación. Pero uno de los puntos distintivos en las metodologías ágiles es la velocidad de respuesta frente a los cambios, característica no menor.

Las metodologías ágiles se caracterizan por la obtención de resultados hacia el cliente en el menor tiempo posible. Esto implica un cambio permanente en el software, y esto transforma el testing en ágil, lo que a su vez implica un cambio en la estrategia de testing y la vuelve fundamental ya que aporta uno de los valores primordiales en un proyecto de software ágil.

Más allá de las herramientas que se puedan aplicar para las tareas de testing y de gestión de los defectos, lo que quiero puntualizar en este artículo es la importancia que debe tomar el tester dentro de un equipo. 

Si bien es fundamental elegir las herramientas de apoyo a las tareas de testing desde el inicio del proyecto, tiendo a pensar que la mejor herramienta para un equipo ágil es el conocimiento, la confianza y el valor que tiene el aporte de cada uno. Lograr el fortalecimiento y la fluidez de las relaciones entre los integrantes del equipo, principalmente entre los desarrolladores y testers, es una de las claves para alcanzar con éxito los resultados esperados.

Tomo para ello algunos consejos que leí en este artículo . Cuando los desarrolladores y testers colisionan que me parecieron básicos pero muy interesantes, y que transcribo aquí porque pueden ser de utilidad:

• Dilucidar juntos los requisitos de los clientes
• Construir historias y pruebas unitarias juntos 
• Consensuar cuándo una tarea está lista para pasar a testing para evitar “desencuentros” entre desarrollo y prueba
• Definir entre todos claramente cuándo una tarea se considera como “Done”

Si bien puede sonar algo difícil de poner en práctica, en Tercer Planeta podemos dar fe que este tipo de acuerdos dentro del equipo hacen más fluida la forma de trabajo y con el tiempo se incorporan a un ritmo natural que favorece la relación entre los miembros.
 
Desde mi punto de vista, el "Testeo Ágil", está enteramente relacionado con el conocimiento y aprendizaje de la aplicación por todo el grupo, y fundamentalmente de la confianza que todos los integrantes del mismo le tengan al tester. Además de ser fundamental definir desde el comienzo y entre todos cuál va a ser la estrategia de testing a aplicar y elegir las herramientas que mejor se adapten a cada tipo de proyecto.

El test es una pata MUY importante en el desarrollo de software, vale la pena estar atentos a la evolución del mismo.

Otro artículo recomendado: ¿Como testear un proyecto ágil?

Twittear Seguir a @3p_ar

Leer más...