• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Una mirada al desarrollo por entregas continuas
 

Una mirada al desarrollo por entregas continuas

on

  • 516 views

Autor: Bernadette Martínez Hernández

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

Statistics

Views

Total Views
516
Views on SlideShare
516
Embed Views
0

Actions

Likes
0
Downloads
14
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

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
  • "Desarrollo ágil" es un término derivado del Manifiesto Ágil (Agile Manifesto), escrito en 2001 por un grupo que incluía: a los creadores de Scrum, Extreme Programming (XP), DynamicSystemsDevelopmentMethod (DSDM) y Crystal; un representante de desarrollo controlado por características; y otros coordinadores diversos del pensamiento en la industria del software. El Manifiesto Ágil (Agile Manifesto) estableció un conjunto común de valores y principios dominantes para todas las metodologías ágiles individuales en el momento. Detalla cuatro valores básicos para habilitar equipos de alto rendimiento.Los valores básicos se sustentan en 12 principios, que puede encontrar en el siguiente sitio web: Manifestofor Agile Software Development.Estos valores no son sólo algo que los creadores del Manifiesto Ágil (Agile Manifesto) pensaban encomiar y, a continuación, olvidarse. Son valores que funcionan. Cada metodología ágil individual enfoca estos valores de una manera ligeramente diferente, pero todas estas metodologías tienen procesos y ejercicios concretos que fomentan uno o más de estos valores.
  • My experience has shown that Scrum works well for new product development, while Kanban works very well for continuous delivery situations such as sustained engineering. This is not to say you can't use Kanban for new product development, or Scrum for sustained engineering; you can. I often find that undisciplined teams benefit from starting with Scrum, and then once they get into the habit of producing high quality software in iteration-sized batches, the obvious optimization is to remove the batches and get continuous flow (migrate from Scrum to Kanban). In fact, I often refer to Kanban as 'iteration-less Scrum.'
  • Continuous delivery is about putting the release schedule in the hands of the business, not in the hands of IT
  • Bret Pettichord: Testing is about feedback. Most agile practices are valuable because they create feedback loops that allow teams to adapt. The reason Agile teams can do with less planning is because feedback allows you to make sure that you are on course. If you don’t have meaningful feedback then you’re not agile. You’re just in a new form of chaos.Elizabeth Hendrickson: Speed requires discipline. Compressing the schedule, throwing out the documentation, coding up to the last minute is not Agile. Testing is not a phase, on agile teams, testing is a way of life. Continuous testing is the only way to ensure continuous progress. Eliminate the bottleneck: everyone tests. Takes a tremendous internal discipline to fix bugs as they are found. Otherwise it takes longer to wade through the mess. You can think of the QA person as the “quality coach” for the team instead of the person doing all of the quality work. QA people might not always be the one creating the automated tests or running them, but they are one of the main forces guiding the direction of the creation of those tests, and making sure the customer’s interests are represented.The QA role is elevated from gathering and writing documentation plus manually executing tests to being the expert on quality and the representative of the customer on the team.

Una mirada al desarrollo por entregas continuas Una mirada al desarrollo por entregas continuas Presentation Transcript

  • Una mirada al desarrollo porentregas continuasContinuous DeliveryBernadette Martínez Hernández
  • Sumario✓ 1 Ingeniería de Software✓ 2 Agile✓ 3 Lean✓ 4 Scrum✓ 5 Kanban✓ 6 Continuous Delivery✓ 7 Peguntas
  • Ingeniería de SoftwareDesarrollo en cascada
  • Ingeniería de SoftwareDesarrollo en cascada
  • Ingeniería de SoftwareDesarrollo en cascada
  • Agile, Lean, Scrum y KanbanAgile 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.
  • Agile, Lean, Scrum y KanbanAgileLos 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.
  • Agile, Lean, Scrum y KanbanAgileLos 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.
  • Agile, Lean, Scrum y KanbanLean PIENSA EN GRANDE, ACTÚA EN PEQUEÑO, EQUIVÓCATE RÁPIDO; APRENDE CON RAPIDEZLos 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.
  • Agile, Lean, Scrum y KanbanScrum • 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.
  • Agile, Lean, Scrum y KanbanScrum • 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.
  • Agile, Lean, Scrum y KanbanScrum
  • Agile, Lean, Scrum y KanbanScrum
  • Agile, Lean, Scrum y KanbanKanban• 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.
  • Agile, Lean, Scrum y KanbanKanban • 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.
  • Agile, Lean, Scrum y KanbanKanban
  • 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
  • Continuous DeliveryDesarrollo 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?
  • Continuous DeliveryDesarrollo 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.
  • Continuous Delivery Implanta Desarrolla Define
  • Continuous DeliveryPoner en acción las mejores prácticas en tres áreas principalesdentro de una organización Procesos Personas Herramientas
  • Continuous DeliveryPrincipios • 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.
  • Continuous DeliveryPrá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)
  • Continuous DeliveryLa 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
  • Continuous DeliveryProblemas 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)
  • Continuous DeliveryConceptos 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
  • Continuous DeliveryMá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/
  • Development ProductionTest PlanningDevelopment Cycle Done and ready for deployment. QA
  • DevelopmentDevelopment 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.
  • DevelopmentProduction 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.
  • Altienban All items To Do Ideas, breakdown features, tasks ready for Definition development Prioritized backlog, test planning, developmentDevelopment cycle, QA, done, extra, urgent Waiting for installer, test installer, needs documentationDeployment Waste
  • AltienbanKanban
  • AltienbanDetails • 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.
  • AltienbanEn 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.
  • AltienbanMayores 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.
  • ¡Gracias!¿Preguntas?