Estrategias ágiles para incrementar calidad al construir y probar software

Construir software Estrategias ágiles para incrementar calidad al construir y probar software

Twitter Si usan Twitter pueden encontrarme en @domix Comenten sobre mi charla con el hashtag #testGulev2KX #Gulev2KX

Sobre mí Ingeniero de software desde 1999, experiencia en Java He fundado algunos grupos de usuarios JavaUp.org, SpringHispano.org, grails.org.mx Colaboro en algunos proyectos OpenSource Trabajo en @SynergyJ Adopte los métodos ágiles desde 2005 de manera “parcial” Tengo año y medio usando Scrum Certiﬁed Scrum Master

Agenda Problemas comunes en el proceso de desarrollo Algunas propuestas Agile/Lean Software Development Extreme Programming Testing Conclusiones

Problemas comunes Mal levantamiento de requerimientos No son entendidos El usuario no sabe lo que en realidad quiere No se tiene la capacidad técnica Se aceptan los proyectos sin pensar lo suﬁciente Pésima administración de recursos Mala negociación Falta de COMUNICACION

Comunicación Elemental Muchos problemas pueden ser detectados y corregidos Si son identiﬁcados a tiempo Si se comunican a las personas adecuadas Si se realiza alguna acción al respecto

¿Somos buenos comunicandonos?

Mala comunicación Usuario reporta un error en un sistema

Mala comunicación Usuario reporta un error en un sistema Cuando ingreso a la pantalla de captura, me saca de internet

Mala comunicación Desarrollador reporta un problema en el código

Mala comunicación Desarrollador reporta un problema en el código El servidor no levanta

¿Es difícil dar mas información? ¿Es mucho pedir? Nos da ﬂojera-Falta compromiso No sabemos como expresar-Comunicación

Realidad El proceso de desarrollo de software no es una actividad de/para robots

Humanos Procesos diferentes Entender Sentir Comunicar Muchas, muchas, muchas otras “complicaciones” mas

Comunicación Es necesario mejorar la comunicación y su proceso Ello implica Estar consciente de ello Ponerse a trabajar

Sobrecarga/Burocracia/Ceremonia Todo aquello extra cuyo valor es menor, al esfuerzo que es necesario realizarlo Muchas veces se hace para cubrir superﬁcialidades

Agilismo Empezó por el maniﬁesto Agil en Febrero 2001 Surge por la necesidad de mejores métodos para construir software La construcción de software DEBE considerar diversos tipos de pruebas

Principios Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

Los principios del maniﬁesto van encaminados a mejorar la comunicación, para mejorar el proceso de desarrollo de software mediante la adaptación.

Métodos Agiles Lean SCRUM Crystal Clear Extreme Programming

Enfoque ágil... Software que funciona-Satisfacción del cliente Adaptar el proceso continuamente Comunicación cara a cara A veces diﬁcil Excelencia técnica Simplicidad Auto organización

¿Como adoptar ágil?

Seria una irresponsabilidad mía decirles como. En ágil no hay un como absoluto.

Pero si les puedo platicar de algunas cosas (estrategias) que he usado en diversos proyectos

No Planear “predictivamente”

Adaptarse a los hechos y micro planear

Ser disciplinado

Ser critico, evaluar siempre

Trabajar en equipo

Juntas efectivas

Lean Software Development

Eliminar desperdicio Burocracia Comunicación Interna lenta Requerimientos no deﬁnidos o nebulosos Código innecesario

Extreme Programming (XP) Conjunto de practicas sencillas Es difícil su implementación si no hay compromiso Su objetivo es mejorar la calidad del software y responder a los cambios en los requerimientos

Practicas en XP-FeedBack Retroalimentación Programación en pares Juego de planeación Test Driven Development Esto es diseño mas que pruebas

Practicas en XP-Proceso Continuo Procesos continuo Integración continua Refactoring ¿Rewrite? Liberaciones pequeñas

Practicas en XP-Codificación Codificación Pruebas de unidad Optimizar el código al final No horas extra (40 horas a la semana debe ser suficiente) :)

Practicas en XP-Pruebas Pruebas Pruebas de unidad para todo Pruebas de integración Deben funcionar todas las pruebas antes de liberar Si surge un error (bug), deben escribirse las pruebas para replicarlo. Un bug es una prueba que olvidamos escribir

XP no es moneda de oro Programación en pares No hay diseño detallado Se cree que la documentación es nula, pero las pruebas automatizadas son la documentación de los requerimientos Control de cambios

Pruebas de unidad Se prueban los componentes aislados Generalmente se usan Mocks o Stubs Se usan veriﬁcaciones “asserts” para probar Son confundidas con Pruebas de integración Pruebas de caja blanca

Pruebas de integración Sirven para probar los componentes involucrados en un ﬂujo Validan el trabajo de varios desarrolladores Pruebas de caja negra Pueden ser automatizados, simulan la interacción con el usuario

Impacto de las pruebas El tener una buena batería de pruebas, nos permite entre otras cosas: Validar nuevos requirimientos Medir el impacto de los refactorings Documenta el proyecto Permite mejorar el diseño

Faltan mas pruebas¡¡ Pruebas de Stress Pruebas de Performance Pruebas de Integración de Sistema Pruebas de Aceptacion Pruebas de Sistema Pruebas no funcionales Pruebas Funcionales

Automatización de pruebas Usar alguna herramienta para el build del proyecto Las pruebas deben ser Repetibles Autónomas De ejecución rápida

Integración continua Es el proceso de que cada cierto tiempo o cambio en el código (commit en el repositorio), se construye el proyecto automaticamente. Este proceso realiza: Compilación Ejecución de pruebas Generación de reportes Notiﬁcación de errores

Integración continua-Bamboo

Integración continua-Bamboo Pruebas de unidad

¿Solo las pruebas ayudan?

Hay que apoyarse de cobertura de código. La cobertura de código te indica cuanto código estas probando

Reporte de cobertura Se observa cuanto código pruebas realmente

Cobertura Gráﬁcamente vemos que código no se prueba

Integración continua-Hudson Pruebas y cobertura

Notiﬁcación visible

Visual management

Conclusiones

Agil Adoptar ágil funciona No funciona para todos En mi experiencia ha sido muy satisfactorio Cada equipo debe trabajar en como adoptar ágil en su empresa Siempre pueden volver a cascada :)

Gracias domingo.suarez@synergyj.com Twitter: @domix

Créditos de las fotos http://www.ﬂickr.com/photos/crystaljingsr/sets/72157622354789320/

http://www.springhispano.org	207
http://springhispano.org	59
http://www.slideshare.net	41

Estrategias ágiles para incrementar calidad al construir y probar software

by Domingo Suárez Torres

Accessibility

Categories

Upload Details

Usage Rights

3 Embeds 307

Statistics

Estrategias ágiles para incrementar calidad al construir y probar software Presentation Transcript