Estrategias ágiles para incrementar calidad al construir y probar software
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Estrategias ágiles para incrementar calidad al construir y probar software

on

  • 4,205 views

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, ...

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.

Statistics

Views

Total Views
4,205
Views on SlideShare
3,834
Embed Views
371

Actions

Likes
5
Downloads
90
Comments
1

3 Embeds 371

http://www.springhispano.org 252
http://springhispano.org 78
http://www.slideshare.net 41

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />

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

  • 1. Construir software Estrategias ágiles para incrementar calidad al construir y probar software
  • 2. Twitter Si usan Twitter pueden encontrarme en @domix Comenten sobre mi charla con el hashtag #testGulev2KX #Gulev2KX
  • 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. Agenda Problemas comunes en el proceso de desarrollo Algunas propuestas Agile/Lean Software Development Extreme Programming Testing Conclusiones
  • 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. 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. ¿Somos buenos comunicandonos?
  • 8. Mala comunicación Usuario reporta un error en un sistema
  • 9. Mala comunicación Usuario reporta un error en un sistema Cuando ingreso a la pantalla de captura, me saca de internet
  • 10. Mala comunicación Desarrollador reporta un problema en el código
  • 11. Mala comunicación Desarrollador reporta un problema en el código El servidor no levanta
  • 12. ¿Es difícil dar mas información? ¿Es mucho pedir? Nos da flojera-Falta compromiso No sabemos como expresar-Comunicación
  • 13. Realidad El proceso de desarrollo de software no es una actividad de/para robots
  • 14. Humanos Procesos diferentes Entender Sentir Comunicar Muchas, muchas, muchas otras “complicaciones” mas
  • 15. Comunicación Es necesario mejorar la comunicación y su proceso Ello implica Estar consciente de ello Ponerse a trabajar
  • 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. 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. 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. Los principios del manifiesto van encaminados a mejorar la comunicación, para mejorar el proceso de desarrollo de software mediante la adaptación.
  • 20. Métodos Agiles Lean SCRUM Crystal Clear Extreme Programming
  • 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. ¿Como adoptar ágil?
  • 23. Seria una irresponsabilidad mía decirles como. En ágil no hay un como absoluto.
  • 24. Pero si les puedo platicar de algunas cosas (estrategias) que he usado en diversos proyectos
  • 25. No Planear “predictivamente”
  • 26. Adaptarse a los hechos y micro planear
  • 27. Ser disciplinado
  • 28. Ser critico, evaluar siempre
  • 29. Trabajar en equipo
  • 30. Juntas efectivas
  • 31. Lean Software Development
  • 32. Eliminar desperdicio Burocracia Comunicación Interna lenta Requerimientos no definidos o nebulosos Código innecesario
  • 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. 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. Practicas en XP-Proceso Continuo Procesos continuo Integración continua Refactoring ¿Rewrite? Liberaciones pequeñas
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. Integración continua-Bamboo
  • 46. Integración continua-Bamboo Pruebas de unidad
  • 47. ¿Solo las pruebas ayudan?
  • 48. Hay que apoyarse de cobertura de código. La cobertura de código te indica cuanto código estas probando
  • 49. Reporte de cobertura Se observa cuanto código pruebas realmente
  • 50. Cobertura Gráficamente vemos que código no se prueba
  • 51. Integración continua-Hudson Pruebas y cobertura
  • 52. Notificación visible
  • 53. Visual management
  • 54. Visual management
  • 55. Conclusiones
  • 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. Gracias domingo.suarez@synergyj.com Twitter: @domix
  • 58. Créditos de las fotos http://www.flickr.com/photos/crystaljingsr/sets/72157622354789320/