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.

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/