4. #AgileAtWork Agile at
La crisis del Software
Work
En 1968 surge la Ingeniería del software
Un modelo industrial para la creación de Software
Se intenta estimar el tiempo y los costes
El modelo más popular es el modelo en cascada
5. #AgileAtWork Agile at
Work
1970: Modelo en Cascada (Royce)
6. #AgileAtWork Agile at
Work
Escasa participación de los usuarios
Requisitos y especificaciones incompletas
Cambios frecuentes en la especificación
Falta de recursos
Expectativas no realistas ¿Por qué no
Objetivos poco claros funciona?
Milestones irreales
7. #AgileAtWorkAgile at
Work
¿Soluciones de gestión?
Certificados de calidad del desarrollo Software
CMMi, ITIL, Spice...
Normativas de desarrollo
Metrica, PRINCE...
8. #AgileAtWork Agile at
¿Y a nivel técnico? Work
RUP: Orientación a Objetos
Fue diseñado como un sistema de desarrollo, diseño y documentación
Es la metodología más empleada en el desarrollo de aplicaciones a
terceros
Algunas evoluciones basan su éxito en el uso de herramientas (CASE)
9. #AgileAtWork Agile at
Work
Tenemos otro problema...
De las funcionalidades desarrolladas...
7% se usan siempre
13% se usan a menudo
16% “a veces”
19% pocas veces
45% NUNCA
Fuente: Standish Group
10. #AgileAtWork Agile at
Work
Y entonces llegan unos señores...
11. #AgileAtWork Agile at
Work
El manifiesto Agil
“ Estamos poniendo al descubierto mejores métodos para
desarrollar software, haciéndolo y ayudando a que otros lo
hagan. Con este trabajo hemos llegado a valorar...”
A los individuos y su iteracción por encima de los procesos y las herramientas.
El software que funciona por encima de la documentación exhaustiva.
La colaboración con el cliente por encima de la negociación contractual.
La respuesta a un cambio por encima del seguimiento de un plan.
No quiere decir que no valoremos los puntos señalados... quiere decir que los
valoramos en menor medida.
12. #AgileAtWork Agile at
Work
¿Soluciones de gestion?
Asumimos que la creación de Software es un proceso
de manufactura y no industrial.
Scrum (Takeuchi y Nonaka, Año 1986)
Lean (Poppendieck, Año 2000)
KanBan (Sistema empleado en Toyota en los 50's)
DevOps
13. #AgileAtWork Agile at
Work
¿Y a nivel técnico?
Integración y deploy continuo
Las ramas no nos dejan ver el bosque
Practicas extreme programming
TDD, BDD
Code reviews
Pair programming
14. #AgileAtWork Agile at
Un vistazo a Lean
Work
Ampliar el aprendizaje
Se profundiza más con iteracciones cortas.
Decidir lo más tarde posible
Cuanto más tarde, más contexto del problema conocemos
Reaccionar tan rápido como sea posible
La descomposición en tareas pequeñas nos ayuda a identificar antes los
problemas
Potenciar el equipo
Busca profesionales y deja que hagan su trabajo
Véase todo el conjunto
“Piensa en grande, actúa en pequeño”
18. #AgileAtWorkAgile at
Work
¿Qué nos aporta Scrum?
Divide la organización en equipos definidos pequeños
interdisciplinados y autoorganizados.
Divide el trabajo: Priorización y estimación.
Divide el tiempo en Iteraciones.
Optimiza el plan de entregas. Pila de producto priorizada.
Optimiza y ajusta el proceso tras cada ciclo con retrospectivas.
Adaptación al cambio entre iteraciones. Resistencia al cambio durante
la iteracción.
19. #AgileAtWorkAgile at
Work
¿Qué ha aportado a mi equipo?
Hemos adaptado Scrum a nuestro entorno, combiándolo con Kanban y
ajustándolo tras cada retrospectiva.
Nos ha permitido trabajar en múltiples productos.
Nos ha aportado transparencia.
Los equipos son auto organizados y el optimismo y la confianza ha
mejorado (Nombres de teams pequeños, etc.).
Hemos reducido el “Work In Progress” y ahora conocemos nuestro
Lead Time en bug fixing (Utilizamos Kanban para esto).
20. #AgileAtWork Agile at
¿Y Kanban?
Work
Es un sistema para visualizar y controlar el flujo de
trabajo con tarjetas en un tablero.
Sirve para limitar el WIP
Nos ayuda a medir el Lead Time
Conociendo el Lead Time hacemos los procesos pequeños y predecibles.
Optimización continua
No hay roles ni equipos definidos, los equipos son autogestionados.
Se puede trabajar de forma regular o bajo demanda
21. #AgileAtWork Agile at
Work Kanban
Similitudes entre Scrum y
Ambos son herramientas de proceso
Ambos incorporan principios de la filosofía Lean: Optimización
continua, respuesta al cambio...
Ambos son empiricos, se espera que los adaptes a tu entorno y las
retrospectivas son la herramienta para ello.
Ambos son empiricos, se espera que los adaptes a tu entorno y las
retrospectivas son la herramienta para ello.
Ambos permiten trabajar en multiples productos (pila de producto).
En ambos se trabaja con equipos auto organizados
22. #AgileAtWork Agile at
Work Kanban
Diferencias entre Scrum y
Scrum es más prescriptivo que Kanban
Scrum define roles y equipos definidos. Kanban no.
Scrum prescribe iteraciones, Kanban puede ser regular o bajo
demanda.
23. #AgileAtWork Agile at
Work Kanban
Diferencias entre Scrum y
Scrum nos permite predecir la estimación y la velocidad, Kanban el
Lead Time
Scrum define una pila de producto priorizada y agrupa tareas en
sprints con sus propios products backlogs y sus propias
priorizaciones. En Kanban hay una única pila de producto.
24. #AgileAtWork Agile at
Work
Ambos comparten cosas, pero...
Ambos limitan el WIP, pero...
- Kanban lo hace por estado en el flujo de trabajo.
- Scrum limita el WIP por Sprint.
Ambos utilizan un tablón para representar el estado, pero...
- En Scrum el tablón se limpia tras cada Sprint.
- En Kanban el tablón representa la naturaleza del flujo.
25. #AgileAtWork Agile at
Work
Entonces, ¿Scrum o Kanban?
¿Es un proyecto Grande?
¿Es posible esperar dos o mas semanas para tener lo que
estoy desarrollando en producción?
¿Se necesita un calendario o plan de entrega?
¿Es común tener tareas no esperadas y de alta prioridad?
¿Tenemos un Product Owner que ejerza como tal?
¿Hay que dar soporte a los clientes?
26. #AgileAtWork Agile at
Work
Entonces, ¿Scrum o Kanban?
Scrum
Pila de trabajo priorizada, pila por sprint, proyectos grandes con
entregas incrementales, equipo multidisciplinar...
Kanban
Tareas no esperadas, flujo constante de trabajo, se puede tener
equipos especializados o multidisciplinares...
28. #AgileAtWork Agile at
Work
Dev, dev, dev... ¿Y Operaciones?
Ellos no trabajan con sprints
Podrian usar Kanban, pero ¿Quien sabe cuanto
cuesta configurar un servidor en produccion?
Dev busca cambios, poner cosas en producción,
mientras que Ops busca estabilidad.
Hay poca coordinación entre Dev y Ops, solo les
damos una caja oscura y ellos la instalan en
producción.
29. #AgileAtWork Agile at
Work
Dev vs Ops
Dev no es consciente de sus impactos en
produccion, trabajan en base a test unitarios, etc.
El negocio requiere introducir cambios, pero los
cambios son la causa de la inestabilidad.
Ops intenta minimizar riesgos retrasando el
deployment a producción, y finalmente se acumulan
cambios y problemas.
30. #AgileAtWork Agile at
Work
Los fundamentos de DevOps
Implicar a Ops en el desarrollo.
Tratar la configuración como código.
Reutilizar metodos y herramientas: Code Review...
Abstraer la administración de la infraestructura.
Crear sistemas de provisionamiento de
infraestructura automatizado.
Compartir KPIs con Operaciones.
32. #AgileAtWork Agile at
Work
Chef: configuración como código
Sistema de provisionamiento de infraestructura.
Permite crear nuevos nodos de forma automática
Terminología: Cookbooks y Recipes
Basado en Ruby
36. #AgileAtWork Agile at
Conclusiones Work
Conocer el contexto en el que nos encontramos.
Conocer las fortalezas y defectos de las herramientas a
usar.
Decidir qué herramienta es mejor cuando.
Inspeccionar y adaptar la metodologia a nuestro entorno
Combinar el uso de distintas metodologias/herramientas
Aprender de esto: Retrospectivas, mejora continua.
La metodología no es el objetivo en sí.
