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
   #Gu...
Sobre mí
Ingeniero de software desde 1999, experiencia en Java
He fundado algunos grupos de usuarios
  JavaUp.org, SpringH...
Agenda
Problemas comunes en el proceso de desarrollo
Algunas propuestas
Agile/Lean Software Development
Extreme Programmin...
Problemas comunes
Mal levantamiento de requerimientos
  No son entendidos
  El usuario no sabe lo que en realidad quiere
N...
Comunicación

Elemental
Muchos problemas pueden ser detectados y
corregidos
  Si son identificados a tiempo
  Si se comunic...
¿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 capt...
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 flojera-Falta compromiso
  No sabemos como expresar-Comunica...
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 trabaj...
Sobrecarga/Burocracia/Ceremonia



 Todo aquello extra cuyo valor es menor, al esfuerzo que
 es necesario realizarlo
 Much...
Agilismo

Empezó por el manifiesto Agil en Febrero 2001
Surge por la necesidad de mejores métodos para
construir software
L...
Principios

 Individuals and interactions over processes and tools
 Working software over comprehensive documentation
 Cus...
Los principios del manifiesto van
    encaminados a mejorar la
  comunicación, para mejorar el
proceso de desarrollo de sof...
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 car...
¿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 definidos o nebulosos
 Código innecesario
Extreme Programming (XP)


Conjunto de practicas sencillas
Es difícil su implementación si no hay compromiso
Su objetivo e...
Practicas en XP-FeedBack

Retroalimentación
  Programación en pares
  Juego de planeación
  Test Driven Development
    Es...
Practicas en XP-Proceso
Continuo
Procesos continuo
  Integración continua
  Refactoring
    ¿Rewrite?
  Liberaciones peque...
Practicas en XP-Codificación

Codificación
  Pruebas de unidad
  Optimizar el código al final
  No horas extra (40 horas a la...
Practicas en XP-Pruebas
Pruebas
 Pruebas de unidad para todo
 Pruebas de integración
 Deben funcionar todas las pruebas an...
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
prueb...
Pruebas de unidad

Se prueban los componentes aislados
Generalmente se usan Mocks o Stubs
Se usan verificaciones “asserts” ...
Pruebas de integración

Sirven para probar los componentes involucrados en
un flujo
Validan el trabajo de varios desarrolla...
Impacto de las pruebas

El tener una buena batería de pruebas, nos permite
entre otras cosas:
  Validar nuevos requirimien...
Faltan mas pruebas¡¡
Pruebas de Stress
Pruebas de Performance
Pruebas de Integración de Sistema
Pruebas de Aceptacion
Prue...
Automatización de pruebas

Usar alguna herramienta para el build del proyecto
Las pruebas deben ser
  Repetibles
  Autónom...
Integración continua
 Es el proceso de que cada cierto tiempo o cambio en
 el código (commit en el repositorio), se constr...
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áficamente vemos que código no se prueba
Integración continua-Hudson
Pruebas y cobertura
Notificación visible
Visual management
Conclusiones
Agil

 Adoptar ágil funciona
 No funciona para todos
 En mi experiencia ha sido muy satisfactorio
 Cada equipo debe trabaj...
Gracias
domingo.suarez@synergyj.com
Twitter: @domix
Créditos de las fotos



 http://www.flickr.com/photos/crystaljingsr/sets/72157622354789320/
Estrategias ágiles para incrementar calidad al construir y probar software
Upcoming SlideShare
Loading in...5
×

Estrategias ágiles para incrementar calidad al construir y probar software

3,085

Published on

Construir software es duro y difícil, hacerlo con calidad es aun mas difícil. En nuestra joven industria han existido muchas ideas acerca de como podríamos desarrollar software con eficiencia, muchas metodologías han emergido, casi todas ellas han fallado. El movimiento ágil, fundamentado por el Manifiesto Ágil, propone principios simples, basados en humanos y sus interacciones y no en procesos o herramientas; es esencial el factor humano.

En esta charla abordaremos rápidamente los problemas comunes al desarrollar software y como podemos minimizarlos a través de sencillos principios basados en Agile Software Development. Ademas de los principios veremos como el uso de algunas practicas tomadas de Extreme Programming pueden mejorar significativamente el proceso de desarrollo de software.

Published in: Education
1 Comment
5 Likes
Statistics
Notes
No Downloads
Views
Total Views
3,085
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
97
Comments
1
Likes
5
Embeds 0
No embeds

No notes for slide
























































  • Transcript of "Estrategias ágiles para incrementar calidad al construir y probar software"

    1. 1. Construir software Estrategias ágiles para incrementar calidad al construir y probar software
    2. 2. Twitter Si usan Twitter pueden encontrarme en @domix Comenten sobre mi charla con el hashtag #testGulev2KX #Gulev2KX
    3. 3. 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 Certified Scrum Master
    4. 4. Agenda Problemas comunes en el proceso de desarrollo Algunas propuestas Agile/Lean Software Development Extreme Programming Testing Conclusiones
    5. 5. 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 suficiente Pésima administración de recursos Mala negociación Falta de COMUNICACION
    6. 6. Comunicación Elemental Muchos problemas pueden ser detectados y corregidos Si son identificados a tiempo Si se comunican a las personas adecuadas Si se realiza alguna acción al respecto
    7. 7. ¿Somos buenos comunicandonos?
    8. 8. Mala comunicación Usuario reporta un error en un sistema
    9. 9. Mala comunicación Usuario reporta un error en un sistema Cuando ingreso a la pantalla de captura, me saca de internet
    10. 10. Mala comunicación Desarrollador reporta un problema en el código
    11. 11. Mala comunicación Desarrollador reporta un problema en el código El servidor no levanta
    12. 12. ¿Es difícil dar mas información? ¿Es mucho pedir? Nos da flojera-Falta compromiso No sabemos como expresar-Comunicación
    13. 13. Realidad El proceso de desarrollo de software no es una actividad de/para robots
    14. 14. Humanos Procesos diferentes Entender Sentir Comunicar Muchas, muchas, muchas otras “complicaciones” mas
    15. 15. Comunicación Es necesario mejorar la comunicación y su proceso Ello implica Estar consciente de ello Ponerse a trabajar
    16. 16. Sobrecarga/Burocracia/Ceremonia Todo aquello extra cuyo valor es menor, al esfuerzo que es necesario realizarlo Muchas veces se hace para cubrir superficialidades
    17. 17. Agilismo Empezó por el manifiesto 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
    18. 18. 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
    19. 19. Los principios del manifiesto van encaminados a mejorar la comunicación, para mejorar el proceso de desarrollo de software mediante la adaptación.
    20. 20. Métodos Agiles Lean SCRUM Crystal Clear Extreme Programming
    21. 21. Enfoque ágil... Software que funciona-Satisfacción del cliente Adaptar el proceso continuamente Comunicación cara a cara A veces dificil Excelencia técnica Simplicidad Auto organización
    22. 22. ¿Como adoptar ágil?
    23. 23. Seria una irresponsabilidad mía decirles como. En ágil no hay un como absoluto.
    24. 24. Pero si les puedo platicar de algunas cosas (estrategias) que he usado en diversos proyectos
    25. 25. No Planear “predictivamente”
    26. 26. Adaptarse a los hechos y micro planear
    27. 27. Ser disciplinado
    28. 28. Ser critico, evaluar siempre
    29. 29. Trabajar en equipo
    30. 30. Juntas efectivas
    31. 31. Lean Software Development
    32. 32. Eliminar desperdicio Burocracia Comunicación Interna lenta Requerimientos no definidos o nebulosos Código innecesario
    33. 33. 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
    34. 34. Practicas en XP-FeedBack Retroalimentación Programación en pares Juego de planeación Test Driven Development Esto es diseño mas que pruebas
    35. 35. Practicas en XP-Proceso Continuo Procesos continuo Integración continua Refactoring ¿Rewrite? Liberaciones pequeñas
    36. 36. 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) :)
    37. 37. 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
    38. 38. 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
    39. 39. Pruebas de unidad Se prueban los componentes aislados Generalmente se usan Mocks o Stubs Se usan verificaciones “asserts” para probar Son confundidas con Pruebas de integración Pruebas de caja blanca
    40. 40. Pruebas de integración Sirven para probar los componentes involucrados en un flujo Validan el trabajo de varios desarrolladores Pruebas de caja negra Pueden ser automatizados, simulan la interacción con el usuario
    41. 41. 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
    42. 42. 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
    43. 43. Automatización de pruebas Usar alguna herramienta para el build del proyecto Las pruebas deben ser Repetibles Autónomas De ejecución rápida
    44. 44. 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 Notificación de errores
    45. 45. Integración continua-Bamboo
    46. 46. Integración continua-Bamboo Pruebas de unidad
    47. 47. ¿Solo las pruebas ayudan?
    48. 48. Hay que apoyarse de cobertura de código. La cobertura de código te indica cuanto código estas probando
    49. 49. Reporte de cobertura Se observa cuanto código pruebas realmente
    50. 50. Cobertura Gráficamente vemos que código no se prueba
    51. 51. Integración continua-Hudson Pruebas y cobertura
    52. 52. Notificación visible
    53. 53. Visual management
    54. 54. Visual management
    55. 55. Conclusiones
    56. 56. 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 :)
    57. 57. Gracias domingo.suarez@synergyj.com Twitter: @domix
    58. 58. Créditos de las fotos http://www.flickr.com/photos/crystaljingsr/sets/72157622354789320/

    ×