El documento aborda el agilismo en el desarrollo de software, enfatizando la importancia de la motivación, la metodología ágil, y herramientas como Scrum y Extreme Programming. Destaca la necesidad de un equipo profesionalizado que gestione de forma eficiente los recursos y que implemente prácticas como el desarrollo iterativo e incremental, así como la validación mediante revisiones de pares. También se menciona la función del backlog en la priorización de funcionalidades, y la utilización de herramientas de control de versiones y gestión de issues.

1. #Agilismo (my way)
1. Métodos y Herramientas
Javier García Sogo
@jgsogo

2.  Motivación
 Agilismo
 Herramientas
 eXtreme Programming
 … a debatir
Contenido

3. #Motivación

4. Motivación

5. Motivación

6. Motivación
Imagen: http://blog.puntiel.com/
¿Somos baratos?
¿Somos rápidos?
¿Somos buenos?

7. Motivación
Imagen: http://blog.puntiel.com/
El cliente obtiene lo que
paga (tiempo y calidad).
El desarrollador cobra lo
que hace.
El gestor sabe cuánto
puede hacer su equipo.

8. Motivación - Objetivos
Desarrollo en equipo profesionalizado.
El equipo sabe cuánto se tarda en hacer las cosas.
El equipo sabe cuánto cuesta hacer las cosas.
La empresa gestiona sus recursos: mejores sueldos,
mejores productos y/o proyectos de innovación.

9. #Agilismo

10. Agilismo
Metodología Herramientas
Extreme Programming
Manifiesto ágil: refactoring,
tests, CI,…
Scrum
Roles, time-boxing, backlog,
sprints,…
Lean Development JIT, Pull System, Kanban,…

11. Agilismo - DISCLAIMER
Yo no sé.
Me suenan las cosas,
he ido a charlas,
he experimentado (poco).
Scrum Master es una profesión.
Quier-o/emos aprender y expermientar.
Si alguien sabe,
que lo diga;
o la empresa contrata a alguien que sepa,
¡welcome!

12. Agilismo – My way
Iterativo: cada X días se repite el proceso.
Incremental: si no aporta valor, no lo hago.
Entrega continua: NO significa “siempre”, significa cada iteración.
Historias de usuario: tareas/issues definen qué se hace, con qué
finalidad y cómo se va a evaluar la funcionalidad. También cuánto
esfuerzo implica y cuánto supone esa funcionalidad.
Peer review: nada entra en producción que no haya sido
validado por otro (pull request) y funcione (¡tests!).

13. Agilismo - @jmbeas

14. Agilismo – Backlog
El backlog contiene todas las
funcionalidades de la aplicación
ORDENADAS según prioridad del cliente.
En cada sprint se selecciona un conjunto
de items que son los que se van a
ejecutar y mostrar al final del sprint.
Un item candidato tiene que estar
perfectamente definido en funcionalidad
(puntos función) y por el equipo (story
points). ¡No puede haber dudas!
Imagen: http://www.informit.com/

15. Agilismo – Issues
Específica (¡no hay dudas!)
Medible en funcionalidad y tiempo.
Criterios de aceptación (¡nada subjetivo!)
Realizable (durante el sprint)
Hª de usuario –vs– Job stories

16. Agilismo – Scrumban
Imagen: https://www.crisp.se/gratis-material-och-guider/kanban
Sprint n Sprint (n-1)
Diagrama Kanban: lo ideal es un póster con post-its…
Sprint n-(k+1)Sprint n+k

17. #Herramientas

18. Herramientas – Pull Request
Cada issue (feature) se desarrolla en paralelo por una
persona durante un sprint.
Al terminarla hace un pull request (PR), petición para
incorporarla a la rama de desarrollo (dev).
Todo PR es validado mínimo por otra persona (peer
review) antes de incorporarse a la rama de desarrollo.
Imagen: https://mockupstogo.mybalsamiq.com/mockups/4191.png
Selected  Doing
Doing  Done
Done  Deploy

19. Herramientas – DVCS
Imagen: http://nvie.com/
+Info: http://nvie.com/posts/a-successful-git-branching-model/

20. Herramientas – DVCS
Control de VERSIONES: changelog, alfa, beta, release,…
Imagen: https://mockupstogo.mybalsamiq.com/mockups/4191.png

21. Imagen: http://nvie.com/
Ramas principales (origin):
 master: production-ready
 develop: integration branch
Pull requests
Compilaciones automáticas
Versiones
Herramientas – DVCS

22. Imagen: http://nvie.com/
Ramas de características (feature-):
 No existen en origin
 Son temporales (o se terminan o se
descartan)
Herramientas – DVCS

23. Imagen: http://nvie.com/
Ramas de lanzamiento
(release-):
 NO añaden nuevas features.
 Incorporan bug-fixes
Herramientas – DVCS

24. Imagen: http://nvie.com/
Ramas de revisiones (hotfix):
 SOLO bugs críticos.
 Incorporan bug-fixes
Herramientas – DVCS

25. #eXtreme Programming

26. Clean code
Complejidad ciclomática
Código duplicado
Tests: Unitarios, TDD, BDD
Analizadores estáticos de código

27. #Debatir

28. A debatir
Compromiso. Requiere esfuerzo e implicación.
¿Hasta dónde queremos llegar?
Necesitamos un proyecto para aplicar todo esto.
TDD: a qué nivel llevamos los tests.
Scrumban? Tamaño de iteración
Roles

29. A debatir - Tecnologías
DVCS: Git, Mercurial, Bazaar,…
Tests: Google Test, Boost Unit Test Framework,…
CI: Jenkins, Bamboo, …
Sistema de gestión de código: Github.com,…
Gestión de issues: Redmine, Trac, Github.com/Issues,…