TDD

Metodología de pruebas bastante extendida cuyo acrónimo significa:

• Inglés: Test Driven Development.
• Español: Desarrollo guiado por pruebas.

Se utiliza generalmente para el desarrollo de pruebas unitarias y no es dependiente de ningún lenguaje. El proceso de desarrollo siguiendo esta metodología se compone de tres etapas diferentes:

1. Se escriben las pruebas y se comprueba que fallan.
2. Se implementa el mínimo código que hace que las pruebas se pasen exitosamente.
3. Se refactoriza el código escrito.

La idea de la metodología es que los requisitos de negocio sean transformados en pruebas asegurando de este modo que al final el desarrollo, todos los requisitos se cumplen. También es evidente que utilizando esta metodología, otro de los objetivos que se alcanzan es el de tener una amplia cobertura de pruebas en nuestros proyectos, ya que nunca se va a desarrollar nada para lo que no se hayan escrito sus pruebas previamente. Esto deriva en que en las siguientes iteraciones del proyecto, el desarrollador que quiere introducir nuevos cambios puede confiar en que el código que va a modificar o va a utilizar en su desarrollo funciona e implementa de forma correcta los requisitos de negocio.

A la hora de la implementación, se pretende que el código siga dos principios básicos y ampiamente conocidos como son:

• KISS: “keep is simple stupid”. Literalemnte traducido por “Mantenlo sencillo estupido”, aunque prefiero la traducción “Mantenlo estúpidamente sencillo”. Que nos viene a instar a mantener nuestros sistemas lo más simples posibles a través de buenas prácticas de diseño.
• YAGNI: “You aren´t gonna need it”. Literalmente traducido por “No lo vas a necesitar”. Este principio nos insta a no implementar cosas que no se van a utilizar, ni siquiera aunque pensemos que en un futuro quizás lo vayamos a hacer, porque en la mayoría de las ocasiones, ese futuro nunca llega.

Pero bueno, después de toda esta introducción teórica, vamos a implementar algo.

Primera Fase: Escribir las pruebas y comprobar que fallan.

public interface Calculator {
    int add(int a, int b);
    int subs(int a, int b);
    ....
}

public class MyCalculator implements Calculator {
    public int add(int a, int b) {
        return 0;
    }

    public int subs(int a, int b) {
        return 0;
    }

    ...
}

public class MyCalculatorTest {

    Calculator calc;

    @Before
    public void setUp() {
        calc = new MyCalculator();
    }

    @Test
    public void addTest() {
        assertEquals(2, calc.add(1, 1));
    }

    @Test
    public void subsTest() {
        assertEquals(1, calc.subs(2, 1));
    }

    ...
}

Segunda Fase: Implementar el mínimo código

public class MyCalculator implements Calculator {
    public int add(int a, int b) {
        return a + b;
    }

    public int subs(int a, int b) {
        return a - b;
    }

    ...
}

Tercera fase: Refactorizar nuestro código

En este caso, está tercera fase obviamente no tiene mucho sentido ya que el código se ha hecho lo más simple posible para que nos fijemos solo en el proceso de TDD y no en el código. Pero por si alguno no está familiarizado con el término refactorizar, os dejo el enlace de su definición: Refactorización

Tras esto tendríamos listo nuestro código con nuestras pruebas y la implementación de nuestra lógica de negocio, con lo que podríamos pasar al siguiente requisito.

Se que es una pequeña (muy pequeña) introducción al término de TDD pero creo que puede ser útil para aquellos que lo desconozcan o nunca lo hayan utilizado. Nos vemos.

Desarrollo Ágil (VI): Prácticas ágiles

Hoy vamos a hablar de varias practicas utilizadas en metodologías ágiles. Algunos de vosotros, quizás, al verlas pensaréis que son metodologías en si mismas pero no es así. Este pequeño equivoco se produce porque en muchas ocasiones solo se adoptan estas prácticas dejando de lado el resto de la metodología. Pero bueno, vamos a entrar en materia.

Desarrollo orientado a pruebas

También conocido como TDD (Test Driven Development). Esta técnica se utiliza en el desarrollo de software y consiste en diseñar e implementar las pruebas antes de empezar con el desarrollo del código. Estos test se implementan pensando en las pruebas necesarias a realizar para probar las nuevas funcionalidades o mejoras que se van a desarrollar en la siguiente iteración. Hay que destacar que no es solo una técnica enfocada a pruebas, sino que también es un método de diseño de software.

Esta práctica requiere que se creen pruebas unitarias automatizadas para definir los requisitos que se van a implementar a continuación, de este modo, al escribir el código se escribirá el mínimo para pasar los test evitando de esta forma escribir código innecesario. También y aunque parezca una tontería, con este método se nos obliga a tener pruebas implementadas de todas las funcionalidades implementadas porque, para que engañarnos, cuando uno se queda sin tiempo en un proyecto, lo primero que cae es la documentación, y después, la implementación de los test unitarios.

Las fases para cada ciclo de desarrollo serían las siguientes:

1. Añadir pruebas: Para cada modificación o nueva funcionalidad que se vaya a desarrollar. Para esto, obviamente, hace falta entender perfectamente los requisitos que se van a implementar. Ni que decir tiene, que la primera vez que pasemos estos test tras su implementación, deberían de fallar.
2. Validar las pruebas: Ejecutarlas para ver que efectivamente fallan con los nuevos requisitos.
3. Escribir el código de las nuevas funcionalidades. En esta fase, no es necesario que el código sea elegante o esté perfectamente refactorizado, para esto ya habrá una fase posteriormente.
4. Ejecutar las pruebas y ver que todas pasan con éxito para asegurarnos que todos los requisitos están correctamente implementados. Recordemos que los test de prueba nos deberían garantizar dicha implementación.
5. Refactorizar el código y volver a ejecutar las pruebas para comprobar que no hemos roto nada.

Por supuesto lo ideal sería hacer un ciclo completo por cada nueva funcionalidad o mejora para que no se den casualidades del tipo de romper algo y que otra modificación lo enmascare, de esta forma no perdemos control sobre nuestro código, pero en equipos de trabajo con varios desarrolladores, las exigencias temporales de los proyectos no suelen permitir esto.

Como para todo, esta práctica tiene sus ventajas y sus inconvenientes, así que deberíais ponderar vosotros mismo si esta práctica os va a beneficiar o no.

Integración continua

Entendemos por integración continua la compilación y la ejecución de pruebas del proyecto la cual nos ayuda a incrementar la velocidad de desarrollo. Dicho proceso de integración continua nos permite una constante comprobación de los cambios realizados por los desarrolladores. De esta forma podemos comprobar que dichos cambios no producen fallos en otras partes del proyecto, es decir, no producen problemas de integración con el código de nuestro proyecto.

Pero, ¿en que consiste un entorno de integración continua? Pues bien, esto no es más que un proceso automatizado de construcción del software desde los repositorios y despliegue de este en un entorno de integración en que se realizan las pruebas. Existen muchas acciones que pueden desencadenar que se lance este proceso automático de integración, por ejemplo: Una determinada hora del día (generalmente de noche), previamente a un pase entre entornos, y sin duda una de las más utilizadas, cada vez que se realiza una subida de código al repositorio. En general, cada equipo debe adaptar el sistema a su proyecto. No es lo mismo lanzar una compilación que tarda entre dos y cinco minutos que una que tarda dos horas. Igualmente no es lo mismo desplegar algo que solo tarda unos diez minutos que algo que tarda mucho más. De esta forma, quizás nos interese realizar la compilación cada vez que uno de nuestros desarrolladores realice una subida al repositorio y solo realizar el despliegue un par de veces al día. Como he dicho, estas son decisiones que habrá que tomar según el proyecto y entorno en el que nos encontremos.

La utilización de los sistemas de integración continua nos obliga a adoptar una serie de buenas prácticas o de prácticas recomendadas, entre las que se incluyen las siguientes:

• Utilización de repositorios de código: El utilizar la integración continua nos obliga a utilizar repositorios de código (CVS, SVN, GIT, …) y a trabajar de forma correcta con estos. Seguro que alguno está pensando que esto es básico, pero os sorprendería la cantidad de gente en el ámbito empresarial que no los utiliza.
• Construcción automática de nuestro sistema: Y cuando hablo de construcción no solo me refiero a la compilación, sino que incluimos también la generación de documentación, archivos distribuibles y el despliegue en un entorno clonado de producción. Es decir, todos aquellos elementos que nuestro proyecto posea. Y además, todo ello echo con una sola instrucción y de forma automática.
• Construir nuestro sistema asiduamente: Como ya he comentado anteriormente, una buena práctica es cada vez que se realiza una subida de código al repositorio, de esta forma podremos detectar rápidamente los fallos y problemas de integración y corregirlos. Existen muchas sistemas divertidos para darle un poco de competitividad sana a esto, por ejemplo, utilizar señales visuales si la build se rompe (Jenkins y Hudson, tienen plugins muy divertidos), un sombrero con orejas de burro para el que rompe la build. Y podéis encontrar prácticamente de todo, la gente tiene mucha imaginación, desde semáforos, lámparas de lava hasta vacas que mugen o robots que bailan.
• Disponibilidad de entregables: La construcción asidua hace que estén siempre disponibles entregables actualizados de la aplicación, en este sentido, se facilita que equipos de QA, documentación, marketing y otros relacionados con el proyecto, pero no con el desarrollo, puedan tener de forma fácil las últimas versiones.

Como todo, este tipo de práctica también tiene sus desventajas, pero en mi opinión salvo casos muy específicos, en son depreciables frente a las ventajas que nos ofrece. Algunas de estás desventajas serían, por ejemplo, favorece la realización de un menor número de subidas al repositorio por miedo de los desarrolladores a romper la build, se necesita mantener un entorno clonado del de producción con el gasto que esto conlleva y se requiere que cada vez que haya cambios que afecten al método de despliegue del proyecto, estos haya que automatizarlos, lo que en general provoca un mayor tiempo de mantenimiento del sistema.

Pair Programming (Programación por parejas)

Una de las técnicas más controvertidas sin lugar a dudas. Principalmente consiste en que dos programadores trabajen juntos en un mismo ordenador escribiendo código de forma simultanea, de forma que mientras que uno de ellos escribe código y se preocupa de la parte técnica, el otro revisa lo que se va escribiendo y se encarga de generar ideas de mejora. Ambos roles son conocidos como “driver”, el que escribe el código, y “Observer” el que lo revisa. ¿Por qué digo que es una de las más controvertidas? Pues principalmente, por razones obvias, son dos personas trabajando en un ordenador, lo que inicialmente se percibe como que se va a realizar la mitad del trabajo. Esto unido a entornote de outsourcing donde se cobra por programador/hora pues no da inicialmente una sensación de productividad y de aprovechamiento de recursos. Pero dejando estás opiniones a un lado, tiene sus ventajas y sus inconvenientes como todo.

Sobre las ventajas podríamos decir que:

• La transferencia de conocimiento entre programadores y la formación de estos se realiza de un modo más fácil y controlado. Siendo una gran ventaja emparejar a un programador novel con una veterano, el programador novel aprenderá rápidamente conceptos técnicos y de negocio.
• Mejor código, desde el punto de vista técnico, de optimización y de claridad. El código se escribe para que ambos programadores lo entiendan y programadores con más experiencia pueden aportar muy buenas ideas a programadores menos expertos.
• Mejora la capacidad de enfrentamiento a los problemas, ya que como siempre se ha dicho, dos cabezas piensan mejor que una. Muchas veces, y seguro os ha pasado a todos, basta con discutir algo con alguien en voz alta para que os llegue la solución a algo con lo que llevabais varias horas lidiando.
• Reducción de errores. El hecho de que el código sea escrito y supervisado de forma simultanea, hace que se solventen muchos errores que de otra forma saldrían más tarde generando costes adicionales al proyecto.
• Trabajar con alguien siempre es más ameno y divertido, o cual hace afrontar el trabajo con una mentalidad más positiva. Además, saber que tienes a otra persona en la que apoyarte, da más moral y confianza a la hora de afrontar retos difíciles.
• Evitamos distracciones como por ejemplo leer el correo, consultar redes sociales, blogs, navegando por Internet ya que nuestro compañero nos está mirando por encima del hombro. Esto favorece una mayor disciplina de trabajo.
• Evita interrupciones externas. Es más difícil que vayan a molestar a dos personas que están discutiendo sobre algo o simplemente trabajando juntas que a una persona que trabaja aislada.
• Y una evidente, necesitamos menos ordenadores.

Como todo también tiene sus desventajas:

• El principal, como ya he dicho, es que dos personas están realizando el trabajo de uno. Y esto no cambia hasta que de verdad empieza a funcionar bien y la eficiencia se duplica.
• Por lo general muchos desarrolladores prefieren trabajar solos. Nuestros casos, nuestra música y nuestro teclado. Esto puede resultar a veces difícil de cambiar.
• Roces entre desarrolladores por diferentes hábitos. Desde tabulaciones, hasta nombre de variables, pasando por nombres de funciones, distribución del código, etc… Lo mejor, tener todo esto definido de antemano. Formateo de código automático, patrones para nombrar funciones, variables y paquetes; y esquema de paquetes de la aplicación. Y sobretodo, el ego, algo muy extendido entre los desarrolladores.
• –       Problemas de intimidación por parte de desarrolladores sin experiencia al emparejarlos con desarrolladores experimentados, o a la inversa, problemas de desarrolladores experimentados que encuentren tedioso la autorización de un desarrollador novel.

En mi opinión, quizás en el día a día no sea necesario utilizar siempre esta programación por parejas, pero tiene momentos en los que es de muchísima utilidad. Por ejemplo, a la hora de afrontar nuevos retos en tecnologías que se desconocen, a la hora de afrontar proyectos en áreas de negocio poco conocidas, y sobre todo de cara a introducir a nuevos desarrolladores en un proyecto. No hay que estar todo el día con ellos, pero un par de horas de programación por parejas, sobre todo ante retos técnicos o zonas de negocio complicadas si que me parece muy útil.

Bueno, hasta aquí esta serie de artículos sobre el desarrollo ágil. Espero que os haya servido de algo y os decidáis a incorporar algunos de los puntos o todos, recordemos lo que ya hemos dicho con anterioridad, “no nos tenemos que ajustar a las metodologías y prácticas ágiles, estás se tienen que ajustar a nuestras necesidades”, de está forma adaptaremos aquello que realmente nos pueda beneficiar tanto económicamente como para mejorar como desarrolladores y equipo. Nos vemos.

Desarrollo Ágil (V): SCRUM

La siguiente metodología ágil en nuestra lista es SCRUM. Al igual que Extreme Programming es una de las más conocidas y probablemente hayáis oído hablar de ella con anterioridad pero, vamos a darle un breve repaso. Además de ser otra de las más conocidas, yo diría por lo que he visto en los diferentes proyecto y empresas por las que he pasado, que es una de las más adoptadas. Quizás no en su totalidad, pero si al menos una parte de  la metodología. Ni que decir tiene que cada uno coge lo que mejor se adapte a su entorno de trabajo, al tipo de proyecto en el que está implicado y a la gente con que trabaja. Pero bueno, sin entretenernos más, vamos a entrar en materia.

Scrum como ya hemos comentado es una metodología ágil utilizada para  gestionar proyectos complejos de “software” utilizando prácticas iterativas o incrementales. ¿Por qué he puesto las comillas alrededor de la palabra software? Porque aunque actualmente este es el campo en el que más se utilizan este tipo de metodologías, no es excluyente con ningún otro campo, uno puede usar Scrum en cualquier tipo de proyecto, ya hemos dicho que no hace falta seguir a rajatabla toda la metodología, uno puede seleccionar aquellas partes que más le interesan y le benefician. Pero bueno, que me vuelvo a ir por las ramas, volvamos con lo que estábamos.

A partir de este momento, quedémonos con estas tres palabras: rol, iteración e implicación.

En Scrum tenemos varios roles bien definidos y con funciones concretas y conocidas. Pero no penséis en una estructura piramidal tipo “Jefe de proyecto, analista, analista-programador, programador”, pensad en algo más fluido. No os preocupéis, vamos a tratar de explicarlo.

En primer lugar tenemos un Scrum Master que será la persona que se ocupa de que el equipo pueda trabajar sin distracciones o problemas, y en caso de haberlos (siempre los hay) los intentará solucionar para que estos afecten lo menos posible al equipo de trabajo. Además, este se asegurará de que se sigan de forma correcta los procesos asociados a Scrum.

En segundo lugar tenemos al Product Owner que será la voz del cliente en el equipo, este será el encargado de resolver todas las dudas del equipo sobre el negocio, preparar las historias de usuario, priorizar estas según necesidades del cliente y estar disponible el mayor tiempo posible para solucionar cualquier duda y dar feedback sobre el proyecto.

Finalmente, tenemos al equipo de desarrollo que son los encargados del desarrollo del producto. Muchos estaréis pensando que esto no es un rol, y tenéis razón teóricamente, pero desde el punto de vista práctico, en un equipo de desarrollo Scrum todos los miembros deben estar preparados para hacer cualquier tarea, análisis, diseño, desarrollo, pruebas, documentación, etc… Además, cualquiera de ellos debe conocer el código y poder modificar cualquier parte.

Volviendo a las tres palabras que teníamos que recordar, una vez abordados os roles, vamos a pasar a las iteraciones. Como ya hemos dicho, Scrum es una metodología iterativa, pero ¿qué significa esto? Pues significa que el avance del proceso se va haciendo en sucesivas fases compuestas de las mismas tareas. En Scrum se planifican iteraciones, a partir de aquí sprints de entre 2 y 4 semanas, obviamente los podemos adaptar a nuestras necesidades, pero este tiempo es el recomendado. Para cada sprint, se definen las tareas a realizar basándose en las prioridades indicadas por el Product Owner, y a partir de este momento, no se pueden modificar, lo que significa que todos aquellos requisitos incluidos en el sprint ya no se pueden cambiar y quedan congelados.

Finalmente la última de las palabras a recordar era la implicación. Scrum persigue la creación de equipos autogestionados y fomenta la comunicación verbal entre los miembros del proyecto. Recordemos que el Product Owner forma parte del proyecto, por lo que se está fomentando la constante comunicación con el cliente también. Está promoción de la integración y comunicación se materializa en la definición de varios tipos de reuniones. La primera de ellas es el daily scrum (scrum diario). Esta reunión se lleva a cado diariamente, y debería tener una duración de unos quince minutos. En ella cada miembro del equipo informa de lo que ha hecho el día anterior, lo que va a hacer ese día y si hay algo que le bloquea o impide el desarrollo de su tarea. De esta forma, dichos bloqueos pueden ser solucionados con la mayor brevedad posible por el resto de miembros del equipo.

Otro tipo de reunión es la de planificación del la iteración, en ella se define sobre que se va a trabajar durante la iteración y se estiman las diferentes tareas a llevar a cabo. El sistema es muy curioso, en ella participan todos lo miembros del equipo, cada uno de ellos posee unas tarjetitas con cifras para duraciones (1, 2, 3, 4,…) y dos especiales, una con un café y otra con una interrogación. Para cada tarea los miembros del equipo sacan una carta de forma simultanea y se trata de alcanzar una consenso entre todos ellos, normalmente los valores extremos explican el porque de su elección. Las dos cartas diferentes sirven para pedir una pausa o descanso, el caso del café; representar que la tarea no está bien definida o que hay que profundizar más en ella, en el caso de la interrogación.

En resumen, los puntos a tener en cuenta scrum son:

–       Iteraciones: hacen que el cliente vaya viendo el avance del proyecto y se puedan ir corrigiendo y/o adaptando cosas conforme pasan las iteraciones. También nos permiten estimar a largo plazo (intentar nunca más de 6 meses) ya que tras 4 o 5 iteraciones tendremos una media de el trabajo realizado por iteración.

–       El cliente se convierte en parte del equipo: A través del Product Owner, al cual lo ideal sería tener a disposición ocho horas al día.

–       Rápida visibilidad de los problemas: Se consigue a través de las reuniones diarias.

–       Conocimiento del proyecto por parte de los desarrolladores: lo cual mitiga posibles reemplazos en el equipo, ya que una sustitución solo implicará bajar el ritmo de una iteración y no una perdida de conocimiento difícilmente salvable.

–       Una excelente monitorización del proyecto.

Bueno, hasta aquí la metodología de hoy. Aunque ha quedado un poco largo espero que no se os haya hecho muy pesado. Nos vemos.

Desarrollo Ágil (IV): Extreme Programming (XP)

La metodología que nos ocupa hoy es la de Extreme Programming (XP). Probablemente sea una de las metodologías de las que más hayáis oído hablar ya que sin duda alguna es una de las más conocidas.

Como todas las metodologías anteriores, esta también pone más interés en la adaptación que en la previsión. Si esto es bueno o malo daría para llenar libros y libros, de hecho lo hace. Los defensores de este método lo defienden apoyándose en la idea de que los requisitos y especificaciones de los sistemas que se están desarrollando habitualmente son cambiantes, ya sea por unas razones o por otras, y opinan que la aproximación de adaptación es mejor o al menos más realista que la de tratar de predecir todo de antemano.

La metodología XP se centra en potenciar las relaciones interpersonales considerando estas clave para el éxito de un proyecto. De esta forma, promueve el trabajo en equipo, el aprendizaje y el buen ambiente de trabajo. Otro de los factores más importantes es esta metodología es la comunicación tanto entre los participantes en un proyecto con el cliente. Y por supuesto, la preparación técnica del equipo involucrado en el desarrollo.

En general, la metodología XP se considera especialmente adecuada para proyectos con requisitos imprecisos y/o muy cambiantes.

Los elementos de la metodología serían los siguientes:

– Historias de usuario: Se trataría de “tarjetas” donde el cliente especifica requisitos funcionales o no.  Dichos requisitos deberán ser entendibles e implementables en unas pocas semanas. Cada tarea, terminará siendo una tarea de programación asignada a un desarrollador durante una iteración.

– Roles XP: Los roles habituales que componen un equipo XP serían:

· Programador: Escribe código y realiza pruebas unitarias.

· Cliente: Obvio, encarga el trabajo, escribe las historias de usuario y prioriza tareas.

· Tester: Escribe pruebas funcionales junto al cliente y, ejecuta y difunde los resultado de las pruebas regularmente.

· Tracker: Realiza el seguimiento de las distintas iteraciones, estimaciones frente a tiempo real, para poder afinar las estimaciones.

· Coach: Es el responsable del equipo XP, se encarga de que este siga el proceso correctamente.

· Consultor: Miembro externo experto en algún tema concreto al que acudir en caso de problemas.

· Gestor: Unión entre el cliente y el equipo de desarrollo. Sus labores son de coordinación principalmente.

Proceso XP:

El proceso XP consta de las diferentes fases que se deben ejecutar en cada iteración.

1. Definición de requisitos a implementar

2. Estimación del programador.

3. Desarrollo del requisito.

4. Vuelta al paso 1.

Por otra parte, se considera que un ciclo de vida XP ideal son 6 fases: exploración, planificación de la entrega, iteraciones, producción, mantenimiento y muerte del proyecto.

Elementos  a poner en práctica:

– Jugando con la planificación: La comunicación frecuente entre el cliente y el equipo hace que el equipo produzca estimaciones de requisitos y que el cliente elija el ámbito y tiempo de entrega de cada iteración.

– Entregas pequeñas: Menores en todo caso a 3 meses. No tiene por que ser una funcionalidad completa, pueden ser pequeñas versiones operativas que formarán un todo después.

– Metáfora: Yo puse la misma cara al leerlo la primera vez. A mi entender sería algo como un diccionario de datos que comparten cliente y equipo para asegurarse de hablar el mismo idioma.

– Diseño simple: Se apostará siempre por la solución más simple.

– Refactorización: Se harán continuas refactorizaciones de código para evitar duplicidad, mejorar legibilidad, hacer más fácil futuros cambios, etc…

– Programación por parejas: El desarrollo por parejas evita errores y produce un mejor diseño. Ya sabéis, aquello de “cuatro ojos ven más que dos”.

– El código es de todos: No hay partes que solo toque uno u otro desarrollador, todo el mundo puede tocar todo.

– Integración continua: Cada parte de código terminada se integrará en el sistema, con lo cual será integrado, construido y probado varias veces al día con toda probabilidad.

– 40 horas semanales: Si necesitamos trabajar más horas, algo está yendo mal.

– Cliente accesible: El cliente tiene que estar disponible y a ser posible presente para que el equipo pueda resolver sus dudas.

– Seguimiento de estándares: Debido a la poca documentación que se genera, el código debe servir de comunicación, por lo cual, es muy importante seguir estándares definidos.

Principios:

Lista de principios básicos que persigue la programación extrema:

– Simplicidad: Un diseño simple, un código simple y unas soluciones simples. Esto ayudará a facilitar el mantenimiento, las modificaciones y el desarrollo de nuevas funcionalidades. Esto se consigue a través de los estándares, la programación por parejas y las auditorias de código colectivo, permitiendo que todos los desarrolladores conozcan y puedan entender de forma fácil el código.

– Comunicación: La comunicación entre los desarrolladores se realiza a través del código ya que los comentarios pueden quedar rápidamente desfasados. Ojo, esto no implica no poner comentarios. Los casos de pruebas también sirven como forma de comunicación. Además, los desarrolladores se comunican de forma constante gracias a la programación por parejas. Por otra parte, como el cliente forma parte del equipo, también existe una comunicación fluida con él.

– Feedback: Tanto por parte del cliente como por parte de los desarrolladores. Del cliente sobre el estado del proyecto. De los desarrolladores sobre los resultados y estimaciones. Una parte importante de este feedback nos lo dan también los casos de pruebas que nos ayudan a mantener nuestro código en forma.

– Coraje o valentía: Para ceñirse al proceso y no caer en tentaciones o malas prácticas, y sobre todo para ponerlo en práctica.

Actividades:

En la metodología XP se describen cuatro actividades que se llevan a cabo dentro del proceso de desarrollo:

– Codificar: La mayoría de defensores de esta metodología defiendes que el código es al final lo que importa, que sin él no hay nada. El código sirve para comunicar, discutir, en caso de duda implementar varias versiones para decidir y además, cualquier desarrollador puede proponer sus ideas con una pequeña modificación sobre el código de otro. En definitiva, el código es claro, conciso y no da lugar a interpretaciones.

– Probar: Nadie implementa nada a la primera y todo funciona perfectamente, ¿o si? Y en ese caso, ¿cómo lo demuestra? Mediante las pruebas. De tipo unitario para probar el funcionamiento de nuestro código en particular, y de tipo funcional para validar la correcta implementación de los requisitos del cliente. Vamos, lo que viene siendo “Validación y Verificación”.

– Escuchar: Escuchar al cliente para entender sus necesidades e implementar un software adecuado a su negocio, no a lo que creemos entender de su negocio. Por mucho que un desarrollador sepa, raro es que sepa más que el propio cliente sobre su negocio.

– Diseñar: Una parte muy importante es el diseño, ya que a medida que el sistema crece se pierde visibilidad sobre dependencias y sobre las diferentes partes del sistema. Para evitar esto, lo mejor es un buen diseño.

Bueno, y hasta aquí XP. Si tenéis alguna duda o algo no ha quedado claro animaros a preguntar. Nos vemos.

Desarrollo Ágil (III): Comparativa entre métodos

Un pensamiento generalizado es que los métodos ágiles no son ni disciplinados ni planificados, y a pesar de que esto es totalmente erróneo es difícil, en muchas ocasiones, quitarles esta etiqueta. Lo cierto, es que los métodos ágiles pueden ser desde adaptativos a predictivos con el amplio abanico de puntos intermedios que esto conlleva. De hay que den esa impresión en ocasiones, si los miras desde fuera, de que son un poco caóticos.

Los métodos predictivos son aquellos que se centran en las planificaciones a futuro y en que estas sean lo mas detalladas posibles de forma que puedan en cualquier momento saber que tendrán que hacer a lo largo de toda la duración del proyecto. Desafortunadamente, estos planes de proyecto se basan en la definición inicial de este, con lo cual todos los cambios de dirección o alcance que puedan acontecer durante su transcurso serán difícilmente incorporables y requerirán de un esfuerzo extra para cambiar el rumbo del proyecto, por no mencionar, de que en ocasiones parte del trabajo hecho puede ser descartado para adaptarse a la nueva dirección.

En contraposición a esto, tenemos los métodos adaptativos. Métodos en los cuales, aunque no se podrá explicar con claridad las tareas a futuro, si que son altamente adaptables a cambios. Es decir, un equipo adaptativo podrá explicar con toda claridad que va a hacer la semana que viene, podrá explicar las características planificadas para dentro de un mes, pero como mucho, podrá hacer solamente una declaración de intenciones para dentro de seis meses.

Pues bien, como se ha comentado antes, los métodos ágiles pueden alojarse en cualquier punto entre ambos extremos.

Como ya se ha comentado anteriormente, los métodos ágiles se enmarcan dentro de los métodos iterativos ya que ambos se fijan el mismo objetivo de la liberación de software en cortos periodos de tiempo. La principal diferencia entre unos y otros, es que mientras que los métodos iterativos suelen medir estos periodos por meses, los métodos ágiles lo hacen en semanas. Además, en estos últimos, el trabajo se realiza de forma colaborativa.

Otro de los métodos más habituales es el de cascada que basa toda su fortaleza en la planificación y separación de todas las fases del proyecto: toma de requisitos, análisis, diseño, codificación y pruebas, cada una de ellas con unos entregables específicos para poder medir y controlar el correcto desarrollo del proceso. El principal problema que representa este modelo, es la dificultad de adaptarse a los cambios que se producen tras en inicio del proceso de desarrollo. Por este motivo, el modelo en cascada no se debería utilizar si no están claramente especificados los requisitos o se sospecha que en algún momento del proyecto estos pueden cambiar.

En una metodología ágil, este problema no se da, ya que al realizarse la planificación cada pocas semanas, la adaptación al cambio no es demasiado compleja.

Aún así, como para todo, hay opiniones que defienden unos y otros métodos.

Otro de los métodos es al que yo llamo ASM (A Salto de Mata) y que en ocasiones lo he visto también etiquetado como “cowboy”.Este método se basa en que los desarrolladores hacen lo que creen que es correcto, avanzando allí por donde pueden y solucionando los problemas como, en su opinión, creen que es correcto. En este tipo de proyecto se caracteriza por una comunicación de forma verbal, ausencia de documentación y reevaluaciones del proyecto.

Algunas de las características de los métodos ágiles concuerdan en ocasiones con esta última metodología, por este motivo, se desconfía de las metodologías ágiles.

Pero la verdad dista mucho de esto. Es cierto que la comunicación en los métodos ágiles, en muchas ocasiones en verbal y no genera documentación, pero no nos equivoquemos, esta comunicación es periódica, estricta, disciplinada y rigurosa, lo cual la diferencia sin duda del método ASM.

No vemos.

Eligiendo una metodología ágil

Como habréis visto, últimamente, hemos empezado en el blog una serie de artículos sobre “Desarrollo ágil”. A raíz de esto, el otro día leyendo GenbetaDev (podéis ver el enlace en el Blogroll) encontré un artículo interesante con una mini-guia de preguntas para elegir una u otra metodología ágil. Así que, aunque aún no hemos llegado a la explicación sobre dichas metodologías, me parece interesante poner el enlace a dicho artículo.

Test de metodologías ágiles, ¿Qué metodología es mejor: Scrum, Kanban o Scrumban?

Espero que os sirva de algo. Nos vemos.

Desarrollo Ágil (II): Características

Las metodologías ágiles se encuentran dentro de las conocidas como metodologías “iterativas” o “incrementales”. Por así decirlo, se las puede considerar un subconjunto de estas. Para el que lo desconozca, aunque no es ámbito de esta serie de post (es posible que los tratemos con posterioridad en otra seria), este tipo de metodologías basan su trabajo en la realización de diferentes ciclos sobre las etapas del desarrollo de software para intentar paliar las debilidades de los métodos “tradicionales” poco adaptativos a los cambios. Así un esquema rápido de cómo sería un proyecto de este tipo sería:

–  Planificación inicial

     =  Iteración 1..N

          ◦  Requisitos

          ◦  Análisis y diseño

          ◦  Implementación

          ◦  Pruebas

          ◦  Evaluación

–  Despliegue

Como he dicho es un esquema rápido y muy simple, pero bueno, para que os hagáis una idea creo que bastará.

Como ya habréis deducido, los métodos ágiles se basan en la realización de iteraciones llamadas timeboxes, las cuales tendrán una duración de entre 1 y 4 semanas. Por cada una de estas iteraciones se realizará un ciclo completo de desarrollo que terminará liberando una versión estable del producto pero sin tener necesariamente que ser liberable al mercado. En general, se necesitarán múltiples iteraciones para liberar un producto nuevo o nuevas características de un producto ya existente. Este tipo de sistema permite al proyecto adaptarse a cambios muy rápidamente y, que estos cambios sean bien recibidos y no un gran problema.

La composición de equipos en un entorno ágil suele ser multidisciplinar y suele dar poca importancia a los roles o jerarquías corporativas ya que cada uno de los miembros del equipo es responsable de las tareas que tiene asignadas y de cómo llevarlas a cabo para que al final de la iteración estén completadas de forma correcta.

En este tipo de metodologías, se prima mucho más la comunicación cara a cara que la generación de documentos escritos. En general los equipos de desarrollo ágil no suelen ser muy grandes, entre 5 y 9 personas, lo cual facilita esta comunicación. Esta comunicación, en la mayoría de métodos ágiles se hace de forma rutinaria en forma de reunión diaria para informar de los progresos del día anterior, el planning del día y los problemas encontrados. En general, a este tipo de reuniones asiste el equipo de desarrollo y un representante del cliente.

Al final de cada iteración, dicho representante del cliente revisará el progreso del desarrollo y reevaluará las prioridades de negocio y retorno de inversión para, en caso de ser necesario, redirigir en la siguiente iteración el desarrollo del proyecto hacía los intereses del cliente.

En los métodos ágiles el progreso de un proyecto se mide por el software operativo generado hasta el momento, ya que por ejemplo, al existir la comunicación diaria y cara a cara, le generación de documentación es mucho menor que en otros proyectos.

Desarrollo Ágil (I): Introducción

Todo aquel que se dedique al desarrollo de software sabrá que no es un campo ni fácil ni simple y, que en cuanto un proyecto empieza a tomar grandes dimensiones el hacerlo en modalidad ASM (a salto de mata) no es viable. Es más, en cualquier tipo de empresa, este método es inviable ya que se deben perseguir unos plazos fijos, no superar unos costes establecidos y, por supuesto, entregar un producto de calidad.

Cuando hablamos del desarrollo de software y de todos los procesos implicados en él, hablamos de algo complejo y difícil de manejar salvo que se tenga algún tipo de metodología. Por esta razón, desde que se empezó con el desarrollo de software, se han intentado crear diferentes métodos, algunos más afortunados que otros, para manejar todas las complejidades que se dan en el proceso de desarrollo de software.

Inicialmente, la mayoría de los métodos que aparecieron estaban o bien enfocados a la documentación y generar entregables ajenos a la tarea de desarrollo para poder controlar en mayor o menor medida la evolución del desarrollo, o estaban enfocados en que los desarrolladores siguieran de forma rígida ciertos procesos que no siempre se adaptaban al tipo de desarrollo y hacían a veces, más compleja o desesperante la tarea del desarrollador.

Frente a estos métodos “tradicionales” o “pesados”, en los últimos años están surgiendo una serie de métodos “ágiles”, que tratan de flexibilizar todos los procesos asociados al desarrollo de una aplicación sin ser el desarrollo propiamente dicho. Estas metodologías ágiles, tratan de centrarse en cuatro puntos básicos:

–       Individuos e iteraciones frente a procesos y herramientas.

–       Software funcionando sobre documentación excesiva.

–       Colaboración con el cliente sobre negociación contractual.

–       Respuesta ante el cambio sobre seguir un plan.

Para el que quiera más información sobre esto, os dejo el enlace al Manifiesto para el desarrollo ágil del software.

Los métodos “tradicionales” han demostrado ser efectivos  y necesarios en proyectos de gran tamaño tanto temporal como a nivel de recursos, pero no son el enfoque más adecuado cuando se trata de proyectos más pequeños y en entornos o sistemas muy cambiantes. La utilización de estos métodos tradicionales en este tipo de entornos provocaba que, en muchas ocasiones, se dejaran de lado las buenas prácticas de ingeniería de software asumiendo con ello riesgos innecesarios. En este tipo de escenarios y situaciones, es donde tienen cabida las metodologías ágiles.

Ejemplos de estas metodologías ágiles son:

–       Scrum

–       Crystal Clear

–       Extreme Programming

–       Adaptative Software Development

–       Feature Driven Development

–       Dynamic Systems Development method

Nos vemos en la próxima entrega.

[Nota] La idea de esta serie de post, será la de introducir lo que es el desarrollo ágil y comentar algunas de sus metodologías.