No es fácil gestionar un equipo de trabajo, conseguir software de calidad, ser rigurosos con las pruebas, cumplir plazos con el cliente  y encima  que éste quede satisfecho.

Por eso cada vez más, se intentan introducir metodologías ágiles de trabajo (Extreme Programming, Scrum, Lean, Kanban … ) que ayuden a los equipos a ser más productivos y efectivos en sus tareas.

En mi experiencia laboral he pasado por distintas metodologías como Scrum o Kanban.

Con Scrum me sentía atada en muchos aspectos y con Kanban me sentía demasiado libre.  Por eso pienso que no es bueno ceñirse a una metodología en concreto, sino usar lo bueno de cada una y adaptarlo  a las necesidades del negocio.

He sacado buenas prácticas de cada una de las metodologías, que me parecen llamativas y  en algunos casos debatibles

1. Pair Programming

Es una de las 12 prácticas descritas en la programación extrema (Extreme Programming), una de las metodologías con más reglas y menos margen de maniobra.

La programación en parejas, como su nombre indica, consiste en que 2 personas trabajen juntas para resolver un mismo problema. Una de las personas toma el rol de controlador y el otro de navegador y cada cierto tiempo se turnan en sus funciones.

• controlador: es la persona a los mandos del teclado
• navegador: es la persona que observa

Lo están utilizando empresas como Facebook o Twitter.

Ventajas

• Compartimos conocimiento: Al estar 2 personas trabajando en la misma tarea, el conocimiento es adquirido por 2 personas a la vez, tanto técnico como de negocio.
• Islas de conocimiento: En muchas empresas ocurre, que el conocimiento de un área recae solo en 1 persona. Si esa persona enferma o se va de vacaciones, no hay nadie que pueda resolver problemas de ese área. Trabajando en parejas, siempre habrá al menos 2 personas con conocimiento en cada área.
• Calidad del producto: Con 2 personas trabajando a la vez, se generarán menos errores
• Mantenemos el foco : Cuando tienes una persona sentada a tu lado, te distraes menos con el movil, no te entran tentaciones de consultar redes sociales, no te distraes con tu correo personal … Ambas personas mantienen el foco en el problema que comparten.

Inconvenientes

• Aparente aumento de costes:  Hay 2 recursos para hacer una tarea que antes haría 1 único recurso. Sin embargo hemos reducido costes en futuros errores.
• Discrepancias entre desarrolladores: No siempre se suelen llevar bien los desarrolladores. Trabajar en parejas en estos casos, puede no ser efectivo.
• Horarios distintos: No siempre es fácil coincidir en la oficina, reuniones, distintos horarios, teletrabajo … Para estos casos, existen herramientas para realizar pair programming de forma remota (MotePair)

2. Mob Programming

Si la técnica de Pair Programming, crea diferencias de opinión, Mob Programming es más heavy. Utiliza la técnica de Pair Programming pero no con 2 personas sino con todo el equipo (unas 5 personas). Un único ordenador para todo el equipo. Para permitir la visibilidad de todos, se utiliza un proyector donde se muestra el código.

Todo el mundo aporta ideas, sin importar si eres junior o senior

A mi me cuesta imaginarme este modelo de trabajo en una empresa española. Parece que el método funciona en empresas nórdicas. Podeis leer ejemplos y experiencias en su web (MobProgramming)

3. Code Review

Las revisiones de código se realizan cuando un desarrollador ha terminado su tarea. El resto del equipo examina el código fuente buscando mejoras  y errores.

Las ventajas que ofrece son similares al PairProgramming. Para mi, una de las cosas más importantes del CodeReview es que si se produce un error en producción, la culpa no se focaliza en una única persona, todos revisaron el código antes de instalarse y todos pudieron detectar el error.

Un codereview se debe hacer desde el punto de vista objetivo e imparcial. Se suele hacer una lista de las cosas importantes a fijarse. Algunas de ellas se basan en principios de programacion.

• DRY (don´t repeat yourself): Reutiliza tu código y no dupliques funcionalidad
• SRP (Single responsability Principle): Métodos y clases deben representar una única cosa
• KISS (Keep it simple stupid): Código que sea simple y entendible por los demás
• Escalabilidad: El código debe ser lo más escalable posible
• Gestión de logs: El log generado debe ser claro
• Patrones de diseño: Intentar usar patrones de diseño en el código

Existen herramientas para facilitar las revisiones de código

• UpSource
• Crucible

4. Test Driven Development (TDD)

El desarrollo dirigido por pruebas, es una de las técnicas usadas en la programación extrema donde antes de empezar a desarrollar defines tus pruebas de test y orientas tu código en función de tus test. Vamos, al revés de como estamos acostumbrados.

Fue creado por Kent Beck (el padre de la programacion extrema y JUnit) y la forma que tiene de trabajar es siguiendo el ciclo rojo-verde-refactoriza

• Se escriben junto al cliente los requisitos del proyecto
• Se desglosan en tareas simples o «historias»
• Se convierten esas tareas en test unitarios
• Se ejecutan los test y comprobamos que la prueba falla
• Se escribe el código para conseguir pasar la prueba
• Se ejecutan los test y comprobamos que pasamos la prueba
• Refactorizamos el código y volvemos a empezar con el siguiente test

Ventajas

• Previene errores: Al realizar pruebas continuas durante todo el proceso, se reduce el numero de errores que llegan  a producción
• Diseño simple: Escribimos código que resuelva una prueba, por tanto el código será lo más simple posible
• Análisis previo: Al realizar antes los test que el código, estamos seguros se ha realizado un análisis previo del problema.

Inconvenientes

• Interfaz de usuario: Es muy dificil hacer pruebas unitarias sobre capas de presentación
• BBDD: Es dificil realizar pruebas unitarias que requieran el uso de base de datos
• Errores no identificados: No por el hecho de pasar todos tus test unitarios, tu aplicación está libre de errores.
• Curva de aprendizaje: La curva de aprendizaje es grande. Es dificil trabajar de esta forma. . La productividad al menos al principio tiene que bajar mucho

Conclusiones y opinión personal

El Pair Programming y el Mob Programming lo veo interesante y al mismo tiempo dificil de llevar a cabo. Me gustaría conocer la opinión de algún equipo que lo haya usado.

Code Review me parece muy interesante e indispensable en cualquier equipo que quiera mejorar. Sin embargo veo complicado incorporar Code Review a las estimaciones de tiempo de un proyecto. La mentalidad de muchas empresas, no dan cabida al Code Review

TDD lo veo dificil de usar en proyectos con con mucha interfaz de usuario. Hay que ser muy hábil escribiendo test para que esto sea efectivo.

Post By Rocio Muñoz (37 Posts)

Ingeniera Informatica. Dicen que todos los niños nacen con un pan debajo del brazo ... Yo creo que llevaba un ordenador. Trabajo como programadora en Cic en entornos Java. Apasionada del mundo web y la innovacion social.

Connect