Barra Sup Mobile


La oficina de proyectos de informática
pmoinformatica.com

Páginas

lunes, 10 de diciembre de 2012

Test Driven Development (TDD): Como llevarlo a la práctica

Imagen de: IBM Rational Community

Se presenta a continuación un nuevo artículo sobre la serie dedicada al Test Driven Development (TDD), "Como llevarlo a la práctica".

En este artículo, primero se presentan dos requisitos previos a la adopción de TDD, contar con una metodología de pruebas unitarias que se esté aplicando y con herramientas de apoyo a pruebas unitarias, como por ejemplo JUnit o VBUnit.

Luego se describen los pasos a seguir en una hoja de ruta para la adopción de TDD, abarcando la formación, selección del marco de referencia, adaptación del marco y metodología a la organización, aplicar el método TDD, realizar mediciones, ajustar el plan de adopción a las mediciones e incrementar progresivamente el uso de la práctica.

El artículo fue elaborado con base en contenido de la Wiki de Eclipse (El más que conocido IDE gratuito), consulte la referencia para ver la fuente original.

Presentamos a continuación el artículo sobre Como llevar a la práctica el TDD.

¿Comenzando con TDD?, asegúrese de estar listo

Un requisito previo a la adopción del TDD es tener prácticas de pruebas unitarias implementadas, dado que de ser así, el equipo estará familiarizado no sólo con su trabajo de desarrollo de sistemas sino también con prácticas de diseño y ejecución de pruebas que necesitarán en TDD.

Con frecuencia, se observa que se cuenta con desarrolladores no entrenados como Analistas de Prueba (Testers) ni en pruebas unitarias. Si este es su caso, sería conveniente considerar la implementación de herramientas y procedimientos de pruebas unitarias bajo su metodología actual, y una vez logrado proceder con la adopción de TDD.

Otra de los requisitos es las herramientas para pruebas unitarias, contar con alguna es prácticamente obligatorio para adoptar TDD, como por ejemplo la familia Open Source de herramientas XUnit (Tales como JUnit y VBUnit).

Como adicional, el curso te ayuda a prepararte para las certificaciones de Professional Scrum Master I (PSM I), Professional Scrum Product Owner (PSPO I) de scrum.org o la certificación Fundamentos Agile / Scrum de EXIN.

Más cursos >>

Pasos a seguir para adoptar TDD

A continuación se presenta una hoja de ruta para la adopción de TDD, siguiendo una serie de pasos. Siéntase en libertad de añadir, cambiar o eliminar pasos de esta hoja de ruta, según sea necesario para la organización y entorno en el que se esté aplicando.

  • Proporcionar Formación al equipo: Utilizar presentaciones y artículos para impartir programas de formación internos. Asimismo, es de gran utilidad enviar al equipo de desarrollo a cursos sobre pruebas unitarias y sobre TDD.
  • Obtener Marco de Referencia: Para ello, existen múltiples fuentes, tanto en libros, wikis en la web, entre otros recursos. Proporcionar este material al equipo para su revisión. Un ejemplo de marco de referencia es la Práctica sobre TDD en la Wiki de Eclipse presentada como referencia en este artículo.
  • Adaptar el Marco de Referencia: Es recomendable no tomar al pie de la letra lo indicado en la metodología, en su lugar,es necesario adaptarlo a las restricciones y requerimientos de la organización, produciendo su propia metodología para documentar.
  • Identificar métricas: Permiten medir si la adopción de TDD está teniendo buenos resultados. Es recomendable que las métricas sean fáciles de obtener.
  • Comenzar con objetivos modestos: Fijar objetivos modestos al principio, por ejemplo  estableciendo un número determinado de pruebas por método implementado. El objetivo es tener éxito de forma progresiva, no adoptarlo todo desde el principio.
  • Hacer pruebas piloto: Seleccionar algún sistema o aplicación para comenzar a usar TDD, no comenzado con todas las aplicaciones y proyectos simultáneamente  esto ayudará a ver cuales prácticas dan resultado, cuales no dan resultado, aprender de los errores y reducir el impacto adverso del cambio.
  • Definir un plazo para la adopción: Debe ser lo suficientemente largo como para permitir que los nuevos hábitos se desarrollen en el equipo, pero corto para que los cambios se puedan implementar relativamente rápido. Lo recomendable es entre 2 semanas y 2 meses.
  • Comenzar a usar TDD: Tal como se describe en la práctica, primero se escriben las pruebas y luego se escribe el código de sistema.
  • Evaluar como va la adopción de TDD periódicamente: Esto con base a las métricas que definió al principio.
  • Hacer ajustes con base en esta evaluación periódica: Eliminando herramientas o características del método que prueben no ser efectivas e incrementando las que si han sido efectivas y han mejorado la calidad.
  • Incrementar progresivamente el uso de la práctica: En la medida en que se obtengan nuevos resultados, adoptar la práctica de escribir pruebas antes del código para cada vez más componentes y aplicaciones, hasta que sea adoptado en todos.
  • Continuar evaluando los resultados y haciendo ajustes: Identificar problemas, hacer seguimiento a las mejoras de calidad obtenida, tanto a nivel de equipo como individuales. Obtener más material de artículos y libros. Asimismo, continuar haciendo ajustes y extendiendo progresivamente el uso de la práctica.

Contratar a un consultor con experiencia en TDD también puede ayudar a facilitar la adopción de la práctica de TDD y evadir errores comunes a otras compañías e industria.

Próximas entregas

En próximas entregas de la serie de TDD, se describirá más en detalle la forma de adoptar la metodología de pruebas unitarias, herramientas disponibles para apoyar en las pruebas unitarias y como adoptar la práctica de Refactoring.

<< Artículo anterior: TDD ventajas y desventajas



¿Y tu? ¿Que opinas?

¿Que opinas de llevar el Test Driven Development (TDD) a la práctica?, ¿Lo has intentado?, ¿Cuales prácticas aplicaste primero?, ¿Que opinas de lo expuesto en este artículo?, ¿Parece factible?, ¿Que cambiarías o sugerirías?.

¿Buscas más información de metodologías ágiles?

¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y otros recursos de gerencia de proyectos y metodologías ágiles?, entonces presiona "suscríbete" a continuación.

Suscríbete a la lista de correo electrónico:


Vía FeedBurner, se abrirá una nueva ventana

Tambíen puedes seguirnos al Twitter @PMOInformatica o página de Facebook

¿Estás interesado en productos Amazon sobre Desarrollo Ágil de Software?













Kanban
Autor: David J Anderson
>> España (amazon.es)
>> Latinoámerica (amazon.com)
Código Limpio
Autor: Robert C. Martin
>>España(amazon.es)
>> Latinoámerica (amazon.com)
Gestión Ágil de Proyectos
Autor: Pablo Lledó
>>España(amazon.es)
>> Latinoámerica (amazon.com)
Diseño ágil con TDD
Autor: Carlos Ble Jurado
>> España(amazon.es)
>> Latinoámerica (amazon.com)



Acerca de otros artículos de esta serie

¿Desea obtener más información sobre TDD?, le invitamos a visitar también los siguientes artículos en el Blog “La Oficina de Proyectos de Informática”.

>> Test Driven Development (TDD): Ventajas y desventajas

>> Test Driven Development (TDD): 9 retos para su implementación y cómo hacerles frente

>> Test Driven Development (TDD): Desarrollo de software guiado por pruebas

Otros artículos de metodologías ágiles

>> Los 5 valores de la programación extrema

>> 5 Preguntas y respuestas sobre el Feature Driven Development (FDD)

>> Plantillas Scrum: historias de usuario y criterios de aceptación

>> Scrum de Scrum: Desarrollo ágil para grandes proyectos

>> 5 métricas de desempeño para proyectos de desarrollo ágil y Scrum

>> Herramientas de software para gestión de proyectos de desarrollo ágil

>> El Desarrollo ágil en un entorno de fechas y presupuestos predefinidos

>> Los Programas de Certificación del Scrum Alliance

>> Preguntas y respuestas sobre Scrum Alliance

>> Gestión de Proyectos PMI y el Desarrollo Ágil: ¿Que tienen en común?

>> Metodologías de desarrollo ágil

No hay comentarios :

Publicar un comentario