Clase Práctica #9

Vamos a ver con un poco más de detalle algunos de los conceptos de la clase pasada.

Integración Continua: es una práctica de desarrollo de software en la que cada miembro del equipo integra su trabajo de manera frecuente (en general por lo menos una vez al día). Esta práctica responde a la necesidad de lograr entregas periódicas e incrementales, permitiendo trabajar de forma más fluida y reduciendo los problemas a la hora de integrar las funcionalidades nuevas con las ya existentes.
Al integrar de forma continua cada cambio que hacemos, reducimos los problemas a la hora de unir nuestra versión del código con la de los demás y logramos detectar los problemas de compatibilidad de manera más rápida. Para esto vamos a necesitar primero contar con un sistema de control de versiones (ver: subversión, git, BitKeeper, perforce, SourceSafe, CVS, etc). También será recomendable lograr automatizar los pasos del ‘Build’, la compilación del código, la ejecución de las pruebas y los pasajes de ambientes (ver: Ant, CruiseControl, Hudson, etc).

Refactoring: Esta es una práctica que plantea reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Solemos convivir con sistemas complejos, difíciles de mantener y modificar. Muchas veces nos preguntamos, como llegamos a tener este sistema? En el video de Ken, posteado en el TP #7, se explica bastante bien esta situación.
Seguimos reutilizando estos sistemas inmantenibles porque de alguna forma funcionan y en general nadie quiere modificar un sistema que está funcionando. Lo importante a tener en claro es que el planteo de refactoring no es meramente una cambio cosmético con fines de seguir un estándar de desarrollo, el planteo pretende lograr mantener la simplicidad a lo largo de la vida del sistema, cuando eliminamos la redundancia, eliminamos funcionalidades no utilizadas y mejoramos los diseños obsoletos; simplificamos la integración de nuevas funcionalidades, ahorramos tiempos y aumenta la calidad del sistema, logramos mantener el diseño simple evitando el desorden y la complejidad innecesaria, la coordinación del equipo y la transferencia de conocimiento mejora.
La principal barrera de refactoring es lograr asegurarse de no introducir errores al aplicar una modificación o mejora, para esto debemos tener un equipo de testing muy grande o un conjunto de pruebas automatizadas asociadas al código que estamos modificando (ver siguiente punto TDD y Unit Test). Si no contamos con formas eficientes de probar la aplicación es probable que no hagamos refactoring, hasta llegar al punto en el que es más fácil reescribir todo el sistema que modificarlo.

TDD y Unit Test: Este es un enfoque evolutivo en el que diseñamos las pruebas y vamos modificando el desarrollo en función de estas. Las pruebas unitarias son uno de los conceptos centrales de XP, lo que se plantea principal mente es que cada porción del código tenga un conjunto de pruebas asociadas y que estas puedan ser ejecutadas de forma automatizada (ver xUnit, jUnit, nUnit).
Esto nos permitirá cierta libertad a la hora de tener que modificar el código, incluso teniendo que modificar una funcionalidad desarrollada por otra persona o equipo (permitiendo la Propiedad del código compartida)
En general cuando nos presionan con los tiempos de entrega, solemos reducir la calidad. Una de las principales áreas impactadas es esta, al tener código con menor porcentaje de testeo, podría implicar software con mayor porcentaje de errores y por ende esto implicará más trabajo en el futuro reparando esos errores.

Scrum: Ken Schwaber plantea que scrum es un framework que define algunas pocas reglas y roles y compara esto con el juego de ajedrez; las reglas de este juego son pocas y bastante simples, sin embargo las estrategias existentes para jugarlo son muy numerosas. Además destaca que las prácticas de XP son compatibles con SCRUM.

Burndown Chart: es una representación gráfica del trabajo por hacer en un proyecto en el tiempo. Usualmente el trabajo remanente (o backlog) se muestra en el eje vertical y el tiempo en el eje horizonal. Es decir, el diagrama representa una serie temporal del trabajo pendiente. Este diagrama es útil para predecir cuándo se completará todo el trabajo. Aquí podremos apreciar la velocidad del equipo y tener una visión clara del status del proyecto y de la estimación de fin.

User Story: Las User Stories describen funcionalidades de un sistema de software que aportan valor al usuario/cliente. Debería incluir los objetivos y motivaciones, a fin de entender porque es necesaria esta funcionalidad. Se diferencia de un caso de uso ya que este es normalmente más grande que una user story. Por ejemplo, cada camino dentro de un caso de uso podría ser una user story. En general las user stories van a estar compuestas de una descripción/nombre, la importancia (definida por el usuario -PO-), la estimación (definida por el equipo de desarrollo), el detalle de las pruebas de aceptación y las notas (que son aclaraciones, por ejemplo: se necesita un diagrama de actividad).

Planning Poker: La idea de esta técnica de estimación es lograr que todos los miembros del equipo den su opinión sin influenciar a los demás. Para esto cada uno cuenta con un grupo de cartas, se presentan los requerimientos a estimar uno por uno haciendo una descripción de los mismos, se procede a discutir aquellos detalles más relevantes o que no hayan quedado claros. Tras este periodo de discusión cada uno de las personas implicadas en el proceso de estimación elije de su mazo de cartas la carta que representa su estimación del trabajo que implica implementar el requisito que se está discutiendo. Las estimaciones son privadas hasta que todo el mundo cuenta con una estimación. En ese momento, todas las estimaciones se hacen públicas. Si la dispersión entre las estimaciones es grande, se vuelve a discutir y cada uno da su opinión sobre porque piensa que esa historia debería durar mas o menos, esto sirve para aclarar las historias. Luego se realiza una segunda ronda esperando que la dispersión sea menor.

Fuente / Articulos relacionados:

“Continuous Integration” Martin Fowler
“Evolutionary Database Design” Martin Fowler
“SCRUM Guide” Ken Schwaber (Mayo 2009)
“Release Burndown Analysis” (video)
“Source code control the way it was meant to be” Linus Torvalds at Google Tech Talks
“A Visual Guide to Version Control”
“What Is a Good Test Case?” Cem Kaner
“Scrum and XP from the Trenches” Henrik Kniberg (version ingles)(version español)
“Kanban vs Scrum” Henrik Kniberg