Autor: Bernadette Martínez Hernández Presentación en la Facultad de Ciencias de la computación. Benemérita universidad Autónoma de Puebla

1. Una mirada al desarrollo por
entregas continuas
Continuous Delivery
Bernadette Martínez Hernández

2. Sumario
✓ 1 Ingeniería de Software
✓ 2 Agile
✓ 3 Lean
✓ 4 Scrum
✓ 5 Kanban
✓ 6 Continuous Delivery
✓ 7 Peguntas

3. Ingeniería de Software
Desarrollo en cascada

4. Ingeniería de Software
Desarrollo en cascada

5. Ingeniería de Software
Desarrollo en cascada

6. Agile, Lean, Scrum y Kanban
Agile
Cuatro valores básicos (manifiesto Agile):
1. Los individuos y sus interacciones por encima de los procesos y las
herramientas (COMUNICACION)
2. Entregar software que funciona por encima de hacer la
documentación
3. Colaboración con el cliente por encima de la negociación de los
contratos
4. Responder al cambio por encima de seguir un plan
El desarrollo ágil no es una metodología. Es un término
incluyente que describe varias metodologías ágiles.

7. Agile, Lean, Scrum y Kanban
Agile
Los doce principios Ágiles son:
1. Nuestra mayor prioridad es satisfacer al cliente a través de la entrega
temprana y continua de software con valor.
2. Aceptamos requisitos cambiantes, incluso en etapas avanzadas. Los procesos
ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
3. Entregamos software frecuentemente, con una periodicidad desde un par de
semanas a un par de meses, con preferencia por los periodos más cortos
posibles.
4. Los responsables de negocio y los desarrolladores deben trabajar juntos
diariamente a lo largo del proyecto.
5. Construimos proyectos con profesionales motivados. Dándoles el entorno y
soporte que necesitan, y confiando en ellos para que realicen el trabajo.
6. El método más eficiente y efectivo de comunicar la información a un equipo de
desarrollo y entre los miembros del mismo es la conversación cara a cara.

8. Agile, Lean, Scrum y Kanban
Agile
Los doce principios Ágiles son:
7. Software que funciona es la principal medida de progreso.
8. Los procesos ágiles promueven el desarrollo sostenible. Patrocinadores,
desarrolladores y usuarios deben ser capaces de mantener un ritmo constante
de forma indefinida.
9. La atención continua a la excelencia técnica y los buenos diseños mejoran la
agilidad.
10. Simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es
esencial.
11. Las mejores arquitecturas, requisitos y diseños surgen de equipos que se
auto-organizan.
12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo,
entonces mejora y ajusta su comportamiento de acuerdo a sus conclusiones.

10. Agile, Lean, Scrum y Kanban
Lean
PIENSA EN GRANDE, ACTÚA EN PEQUEÑO, EQUIVÓCATE RÁPIDO; APRENDE CON RAPIDEZ
Los principios de desarrollo de software Lean (magro):
• Eliminar el desperdicio
• Ampliar el aprendizaje
• Manejar la incertidumbre tomando decisiones hasta el último momento.(Sin
evadir la planeación, sólo enfocarse en la adaptabilidad)
• Reaccionar tan rápido como sea posible
• Dar poder al equipo (Las personas no son recursos)
• Fomentar la integridad (Refactorización y automatización de pruebas)
• Tener una visión clara del „todo‟
• Puntos buenos: Enfoque en el „todo‟, autonomía del equipo (decide y ejecuta
los procesos que necesita)
• Puntos malos: Ignora la necesidad de dividir para analizar en proyectos
grandes, posponer las decisiones puede causar problemas.

11. Agile, Lean, Scrum y Kanban
Scrum
• Scrum es un marco de trabajo para el desarrollo de software
(herramienta que aplica el principio de divide y vencerás)
• Roles, sprint, el equipo crea un incremento de software
potencialmente entregable, backlog, reuniones planeadas.
• Un principio clave de Scrum es el reconocimiento de que durante un
proyecto los clientes pueden cambiar de idea sobre lo que quieren y
necesitan y que los desafíos impredecibles no pueden ser
fácilmente enfrentados de una forma predictiva y planificada.
• Scrum adopta una aproximación pragmática, aceptando que el
problema no puede ser completamente entendido o definido, y
centrándose en maximizar la capacidad del equipo de entregar
rápidamente y responder a requisitos emergentes.

12. Agile, Lean, Scrum y Kanban
Scrum
• Puntos buenos: Metas pequeñas y fáciles de cuantificar, una
reunión mínima diaria, impulsa la formación de equipos.
• Puntos malos: Inflexible (grupos multitareas), demasiadas
reuniones de supervisión, no funciona bien en equipos inexpertos
y/o no familiarizados con Agile y/o con problemas internos de
confianza, requiere un excelente líder, se enfoca demasiado en lo
que los usuarios quieren, la productividad y las metas inmediatas,
ignora especializaciones (causa de stress), minimiza en exceso la
importancia de la documentación, las entregas terminales a
usuarios y los bloqueos.

13. Agile, Lean, Scrum y Kanban
Scrum

14. Agile, Lean, Scrum y Kanban
Scrum

15. Agile, Lean, Scrum y Kanban
Kanban
• Kanban es una herramienta visual de control y manejo de proyectos y procesos que ayuda a
administrar efectivamente el flujo de trabajo durante una iteración. Kanban es una
herramienta, y como cualquier herramienta, su propósito es resolver un problema... Lean
es una filosofía.
• Kanban Standups:
o ¿Tenemos cuellos de botella (cola con exceso de trabajo)?
o ¿Tenemos algo que bloquea la continuidad del proceso?
o ¿Estamos manteniendo nuestro límite de trabajos en progreso?
o ¿Tenemos las prioridades claras?
o ¿Qué se hizo ayer, qué hay que hacer hoy?
• Tablero o pizarrón Kanban se actualiza por lo menos una vez al día. El encargado de cada
reunión enumera trabajo, NO gente. Reglas de control de calidad para el movimiento de
tarjetas
• Principio de mejora continua. Preguntar ¿POR QUÉ? hasta que duela
• Gente con diferentes habilidades tiene que trabajar en equipo para terminar las metas.
• No desarrollar features que nadie quiere en este momento. No escribir más especificaciones de
las que se pueda desarrollar. No hacer pruebas en más software del que se planee instalar.
Descomposición de ideas en features redituables.

16. Agile, Lean, Scrum y Kanban
Kanban
• Puntos buenos: Los mismos de Scrum además de ser más
flexible (no hay iteraciones!) y proporcionar una manera de
controlar los bloqueos ,la sobrecarga de trabajo y no ignorar la
documentación ya que se vuelve parte del proceso. Apunta hacia
el desarrollo por entregas continuas.
• Puntos malos: Se enfoca demasiado a satisfacer lo que los
clientes quieren, la productividad y las metas inmediatas,
ignorando especializaciones (causa de stress) además de la
estimación y la planeación, el principio de mejora continua puede
cansar o presionar en exceso, requiere mucha disciplina.

17. Agile, Lean, Scrum y Kanban
Kanban

18. Agile, Lean, Scrum y Kanban
No hay herramientas ni filosofías perfectas, entonces lo mejor es combinar y ajustar.
Scrumban con un toque de sal, limón y chile

19. Continuous Delivery
Desarrollo por entregas continuas
El flujo de trabajo reforzado por Kanban apunta a
que un punto ignorado en el que nos debemos
enfocar es el perfeccionamiento del movimiento de
tareas en el flujo, independientemente de qué
tareas se estén procesando. Por ejemplo; al usar
Kanban se considera una falla el regresar tareas a
colas previas. Cuando la causa de esa falla, está
en el proceso, debemos eliminarla.
¿En tu organización, cuánto tiempo pasa para que
una línea de código llegue a producción?
¿Cuánta confianza tienes en tu producto?

20. Continuous Delivery
Desarrollo por entregas continuas
• Continuous Delivery significa que un producto es considerado
terminado desde el día uno del proyecto y puede ser dado a los
clientes, incluso si no todas las características y features han sido
implementados.
• Da prioridad a la retroalimentación para evitar:
– Retrasos en la compilación , documentación y construcción de instaladores
– Esperas largas de ejecutables adecuados par a efectuar tests
– Reportes de bugs y problemas semanas después de haber concluido un proyecto
– Identificación de problemas estructurales justo cuando el proyecto está a punto de
concluir
• Jez Humble y David Farley Continuous Delivery (Addison Wesley,
2010)
• ThoughtWorks lo usa y provee una herramienta gratuita (Go). Libro se
usa como texto en Oxford en la materia de Prácticas de Ingeniería Ágil.

21. Continuous Delivery
Implanta
Desarrolla
Define

22. Continuous Delivery
Poner en acción las mejores prácticas en tres áreas principales
dentro de una organización
Procesos Personas Herramientas

23. Continuous Delivery
Principios
• Implantación (deployment) repetible y confiable
• Repetición de procesos difíciles hasta que sean entendidos,
simplificados y/o automatizados
• Automatizar TODO
• Versionar TODO (junto con la compilación y corrida automática de tests
compone Continuous Integration)
• Terminado = Considerado en ambiente de producción (aunque no
siempre se haga público para que pueda ser instalado como sucede en
el paradigma de Continuous Deployment)
• TODOS son responsables de proceso de emisión del software
(release)
• Calidad desde la primera emisión del software.
• Mejora continua.

24. Continuous Delivery
Prácticas
• Compilar el producto una sola vez
• Usar el mismo mecanismo de implantación para todos los
ambientes
• Correr test preliminares (no exhaustivos)
• Cualquier falla hace que la línea de producción se detenga.
• Desarrollo en la Tubería de Montaje
– Equipo de desarrollo y entrega → Control de versiones → Tests de
compilación y unit tests → Tests de aceptación automatizados →
Tests de aceptación del usuario → Release
– Esto no es nuevo, es simple y llano método científico
(Planteamiento del problema, formulación de la hipótesis,
experimentación, ley)

25. Continuous Delivery
La Tubería de Montaje (Deployment Pipeline)
• Cada que se salva código en el sistema de control de versiones se activa una
corrida de la tubería y el software se compila, se corren los tests y si todos ellos
son satisfechos el software puede publicarse.
• Ventajas:
– Método probado que permite crear, verificar y montar sistemas complejos de gran
calidad a un costo y riesgo menor. Confianza en el producto (test, test, test)
– Evitar el “en mi maquina funciona” vía tests en entornos parecidos a los de
producción (VM, Plataform As A Service [cloud])
o Test de aceptación automáticos
o Test de aceptación de los usuarios
o Test de capacidad
– Recibir noticia inmediata de errores y regresiones además de proveer una aplicación
terminada tan pronto y tan frecuentemente como sea posible
– Incrementa la visibilidad del nivel de terminación del producto ya que hay
retroalimentación temprana cada vez que hay una nueva versión.
– Facilita el montaje de versiones especificas

26. Continuous Delivery
Problemas que pueden ocurrir
• Paralelización insuficiente
• Mal diseño de la tubería de tal suerte que ciertos tests
no se pueden saltar o reordenar, no se le puede dar
prioridad a ciertas versiones o el proceso es muy lento
• Falta de herramientas que permitan alternar entre
ambientes “en vivo” y “en proceso de testing” (staging)

27. Continuous Delivery
Conceptos importantes
• Adecuado para Kanban
• Principios clave para la Tubería:
– Construir ejecutables una sola vez, almacenarlos en el repositorio de productos y mandarlos a la Tubería
– Promover únicamente las versiones que pasen todos los unit tests y los tests de aceptación
– Los ambientes de desarrollo, corrida de tests (automatizados y de aceptación) y staging deben ser lo más
similares posible al ambiente de producción.
• Automatizar TODO: compilación, configuración y tests. Los seres humanos tienden a cometer errores
en procesos repetitivos.
• Versionar TODO, incluida la configuración del sistema operativo, infraestructura y equipo de red. Para
el versionado de la Base de Datos
– Versionar la base de datos y usar una herramienta para manejar los cambios
– Compatibilidad hacia adelante y hacia atrás con respecto a la base de datos
– Cambios aditivos solamente
– Tests adecuados que creen solo los datos necesarios
– Evitar integraciones entre aplicaciones vía base de datos
• Continuous Integration (SVN, GIT)
• Continuous Deployment (Cloud Foundry)
• Switch para features
• Staging

28. Continuous Delivery
Más información
• Capítulo 5 sobre la Tubería:
http://ptgmedia.pearsoncmg.com/images/9780321601919/samplepage
s/0321601912.pdf
• http://www.infoq.com/presentations/Continuous-Delivery
• http://www.infoq.com/interviews/jez-humble-agile2011
• http://www.infoq.com/articles/humble-farley-continuous-delivery
• http://continuousdelivery.com/
• http://continuous-delivery.thoughtworks.com/
• http://www.slideshare.net/jmcgarr/continuous-delivery-8341276
• http://www.davefarley.net/

29. Development
Production
Test Planning
Development
Cycle
Done and ready for deployment.
QA

30. Development
Development cycle: TDD
Write a test or a
set of tests
according to the Code passes
specification and all the tests.
check they fail.
Some tests fail or
some code can be
improved.
Fix code so all previous
tests pass or improve
the quality of the code or
its efficiency.

31. Development
Production
Why:
1. If a task goes back into the cycle is
Scrumban because the requirements
changed, not because somebody
understood them wrong, didn‟t
have them at all, or unexpected
things got broken.
TDD 2. TDD + Scrumban enforces
discipline and quality.
3. Eventually, iteration and
retrospectives blend in, creating an
atmosphere of continuous
production.

32. Altienban
All items To Do
Ideas, breakdown features, tasks ready for
Definition development
Prioritized backlog, test planning, development
Development cycle, QA, done, extra, urgent
Waiting for installer, test installer, needs
documentation
Deployment
Waste

33. Altienban
Kanban

34. Altienban
Details
• If there is nothing to take on my usual queue and I cannot start or continue more work in other queues without
passing the WIP limit of any queue maybe it is time for a standup. Board may be inaccurate or I can do something
to unblock a currently blocked item but I may not know about it. The following guidelines can be useful to help in
this situation:
– Can you help progress an existing Kanban? Work on that.
– Don‟t have the right skills? Find the bottleneck and work to release it.
– Don‟t have the right skills? Pull in work from the queue.
– Can‟t start anything in the queue? Is there any lower priority to start investigating?
– There is nothing lower priority? Find other interesting work.
• Stop the Line for special cause problems. Retrospectives with Operations Reviews for common cause problems
and reassess the whole value stream
• If requirements are not complete at the definition state, it is OK, we only need to get as much info as possible at
that point. Be creative to do that (e.g. drawings and simulations). Requirements may change later, but at least we
avoid waste on things that could have initially avoided.
• Development cycle requires developer to run the feature test and all the relevant tests. QA does the wrap-up of the
tests and checks nothing is missing before declaring it done. M may do the more complex or manual tests.
Possibly check their interaction with other finished work.
• Minimal requirement is that the code is decent enough for someone to take over. If not perfect at least
documented or with references of who to ask.
• Test planning: write or get a problem or task specification. Write a test, check if the test fails. Write tests easy to
maintain. Initial tests should not break the encapsulation!
• Documentation should be easy to draw from cases if all examples and explanations are there.

35. Altienban
En este momento….
• Mejora de la integración continua por medio de una serie de reglas y monitoreo
además del uso de GIT como método suplementario de integración continua.
• Manufactura de la documentación ha mejorado considerablemente gracias a que
los casos son especificados de mejor manera.
• Parte de los tests están automatizados (número de unit tests se ha
incrementado) y cada que se salva código en el sistema de control de versiones,
se corren test básicos (continuous integration)
• La compilación y construcción de los programas de instalación ha sido
automatizada en su mayoría, aunque aún requiere una persona a cargo que
supervise y dos o tres pasos manuales.
• Bases de datos están versionadas y con un método bastante seguro y
establecido de adición de cambios.
• Reducido el tiempo de entrega de producto de tres-seis meses a un mes si es
necesario, teniendo varios RCs entre periodo y periodo.

36. Altienban
Mayores retos
• Cambio de actitud
– Garantizar tiempo para efectuar las mejoras
– Continuidad
– Disciplina y participación de todas las esferas de la organización
– Importancia de la implementación y ejecución de tests
• Lidiar con los contras de CD
– Dificultad de implementar al 100% en una sola iteración, lento proceso de mejoras continuas que
puede exasperar
– Implementación de la tubería completa demanda muchísima dedicación y tiempo que es difícil de
conseguir en una compañía de tamaño pequeño.
• Planes futuros:
– Automatización completa de la compilación, construcción de programas de instalación e
implantación
– Reducción del ciclo de producción y mejora del diseño de la Tubería de Montaje (permitir staging)
– Implantación automática en maquinas virtuales que ejecuten series de tests automáticamente
– Mejora de tests: más DSLs, mejor TDD y usar Selenium además de VM para la instalación y
corrida automática de tests.
– Herramienta de manejo y tests automáticos para las bases de datos usadas por el producto.

37. ¡Gracias!
¿Preguntas?