La presentación cubre:
-Pequeño repaso sobre el desarrollo de software siguiendo la metodología waterfall
Agile y Lean Startup
- Los pilares de Scrum;
---- Roles: Product Owner, Scrum Master y Equipo de Desarrollo.
---- Eventos: Planning Meeting, Daily Stand-up, Grooming/Refinement, Demo y Retrospectiva.
---- Herramientas: Product Backlog, Historias de usuario, Definition of Done, Sprint Backlog, Sprint Dashboad.
---- Informes: Fin de Sprint, Inicio de Sprint, Burn-up/Burn-down, Informe de producto.
SCRUMBAN aplicado a equipos de Soporte y MantenimientoJorge H
Charla presentada en Ágiles 2014 (Medellín, Colombia) acerca de como enfrentar los retos del trabajo no planeado de forma ágil desde la experiencia de un equipo de soporte de tecnología.
La presentación cubre:
-Pequeño repaso sobre el desarrollo de software siguiendo la metodología waterfall
Agile y Lean Startup
- Los pilares de Scrum;
---- Roles: Product Owner, Scrum Master y Equipo de Desarrollo.
---- Eventos: Planning Meeting, Daily Stand-up, Grooming/Refinement, Demo y Retrospectiva.
---- Herramientas: Product Backlog, Historias de usuario, Definition of Done, Sprint Backlog, Sprint Dashboad.
---- Informes: Fin de Sprint, Inicio de Sprint, Burn-up/Burn-down, Informe de producto.
SCRUMBAN aplicado a equipos de Soporte y MantenimientoJorge H
Charla presentada en Ágiles 2014 (Medellín, Colombia) acerca de como enfrentar los retos del trabajo no planeado de forma ágil desde la experiencia de un equipo de soporte de tecnología.
Sesión 3 del curso Metodologías Ágiles de Desarrollo de Software de la Universidad de Alicante (http://www.dccia.ua.es/dccia/inf/asignaturas/MADS/2013-14)
Hace años un grupo de expertos escribieron el manifiesto ágil en respuesta de que el fracaso de proyectos es la incertidumbre comenzando así las metodologías ágiles y scrum como el más representativo.
Workshop de gestión ágil de proyectos, haciendo foco en Scrum y otras metodologías para maximizar la productividad y la eficiencia de equipos de trabajo.
Presentación de la capacitación cátedra SCRUM en la UMNG (@lamilitar). Con recomendaciones a herramientas tecnológicas de metodologías ágiles y startups.
Una presentación del marco de trabajo de Scrum. Apunta a establecer en breves imágenes los roles, procesos y artefactos necesarios para la agilidad de proyectos de desarrollo de software o tecnologías de información.
Sesión 3 del curso Metodologías Ágiles de Desarrollo de Software de la Universidad de Alicante (http://www.dccia.ua.es/dccia/inf/asignaturas/MADS/2013-14)
Hace años un grupo de expertos escribieron el manifiesto ágil en respuesta de que el fracaso de proyectos es la incertidumbre comenzando así las metodologías ágiles y scrum como el más representativo.
Workshop de gestión ágil de proyectos, haciendo foco en Scrum y otras metodologías para maximizar la productividad y la eficiencia de equipos de trabajo.
Presentación de la capacitación cátedra SCRUM en la UMNG (@lamilitar). Con recomendaciones a herramientas tecnológicas de metodologías ágiles y startups.
Una presentación del marco de trabajo de Scrum. Apunta a establecer en breves imágenes los roles, procesos y artefactos necesarios para la agilidad de proyectos de desarrollo de software o tecnologías de información.
Metodología, roles, actividades y artefactos que componen el modelo de proceso ágil SCRUM en el desarrollo de software y cómo lleva a maximizar el retorno de la inversión en la empresa (ROI).
Acercamiento a las metodologías Ágiles desde un enfoque práctico. Introducción a Agile, Scrum, Kanban y visual Management.
Charla en el AUGBarcelona - Abril 2013
Agile tools- Caja de herramientas ágiles - Open Space AOC Bariloche 2016Rose Restrepo
Caja de herramientas ágiles... Será que si caben en una sola caja?
Presentación en Agile Open Camp Bariloche 4 Marzo 2016
Rose Mery Restrepo @RoseAgile
Webinar: Integrar la analítica en Metodologías ÁgilesIEBSchool
Alberto Ambrosio nos explica cómo integrar la analítica en metodologías ágiles en este nuevo webinar de IEBS.
Las nuevas tecnologías nos permiten analizar y obtener resultados en un periodo de tiempo reducido. Las organizaciones tienden a modelos en los que se mejora la productividad de forma rápida y a métodos de gestión que permiten una mayor flexibilidad, tales como metodologías de gestión de proyectos ágiles.
La analítica debe ser nuestro pilar fundamental para la toma de decisiones, de forma que ayude a mejorar nuestro impacto en el negocio, cliente y mercado. Es importante integrar la cultura analítica dentro de los procesos internos de la compañía y basarnos en datos cuantitativos que nos permitan dirigir nuestras decisiones directamente a ámbitos que mejoren el negocio.
Similar a Una mirada al desarrollo por entregas continuas (20)
La identificación de tareas es una primera etapa necesaria para definir los requerimientos de Software. De la Mano de entender el Contexto de Uso en el que se va a usar el Software.
Emcoiones para el diseño interactivo son fundamentales. En esta presentación se hace un recorrido breve lo que son y cómo se puede sacar partida de ellas.
Los métodos de Usabilidad son diversos y según el tipo es la forma de usarlos en tus proyectos. Desde la concepción de software hasta su evaluación presentamos una guía básica de algunos de estos métodos.
En esta charla se revisa los retos actuales de las plataformas educativas para lograr un enfoque más centrado en el alumno.
Es parte de las UX Nights, sede Puebla, en su Vol. XXVI. Diseño De Experiencia Educacionales
ACERTIJO DE CARRERA OLÍMPICA DE SUMA DE LABERINTOS. Por JAVIER SOLIS NOYOLAJAVIER SOLIS NOYOLA
El Mtro. JAVIER SOLIS NOYOLA, crea y desarrolla ACERTIJO: «CARRERA OLÍMPICA DE SUMA DE LABERINTOS». Esta actividad de aprendizaje lúdico que implica de cálculo aritmético y motricidad fina, promueve los pensamientos lógico y creativo; ya que contempla procesos mentales de: PERCEPCIÓN, ATENCIÓN, MEMORIA, IMAGINACIÓN, PERSPICACIA, LÓGICA LINGUISTICA, VISO-ESPACIAL, INFERENCIA, ETCÉTERA. Didácticamente, es una actividad de aprendizaje transversal que integra áreas de: Matemáticas, Neurociencias, Arte, Lenguaje y comunicación, etcétera.
Instrucciones del procedimiento para la oferta y la gestión conjunta del proceso de admisión a los centros públicos de primer ciclo de educación infantil de Pamplona para el curso 2024-2025.
ROMPECABEZAS DE ECUACIONES DE PRIMER GRADO OLIMPIADA DE PARÍS 2024. Por JAVIE...JAVIER SOLIS NOYOLA
El Mtro. JAVIER SOLIS NOYOLA crea y desarrolla el “ROMPECABEZAS DE ECUACIONES DE 1ER. GRADO OLIMPIADA DE PARÍS 2024”. Esta actividad de aprendizaje propone retos de cálculo algebraico mediante ecuaciones de 1er. grado, y viso-espacialidad, lo cual dará la oportunidad de formar un rompecabezas. La intención didáctica de esta actividad de aprendizaje es, promover los pensamientos lógicos (convergente) y creativo (divergente o lateral), mediante modelos mentales de: atención, memoria, imaginación, percepción (Geométrica y conceptual), perspicacia, inferencia, viso-espacialidad. Esta actividad de aprendizaje es de enfoques lúdico y transversal, ya que integra diversas áreas del conocimiento, entre ellas: matemático, artístico, lenguaje, historia, y las neurociencias.
Today is Pentecost. Who is it that is here in front of you? (Wang Omma.) Jesus Christ and the substantial Holy Spirit, the only Begotten Daughter, Wang Omma, are both here. I am here because of Jesus's hope. Having no recourse but to go to the cross, he promised to return. Christianity began with the apostles, with their resurrection through the Holy Spirit at Pentecost.
Hoy es Pentecostés. ¿Quién es el que está aquí frente a vosotros? (Wang Omma.) Jesucristo y el Espíritu Santo sustancial, la única Hija Unigénita, Wang Omma, están ambos aquí. Estoy aquí por la esperanza de Jesús. No teniendo más remedio que ir a la cruz, prometió regresar. El cristianismo comenzó con los apóstoles, con su resurrección por medio del Espíritu Santo en Pentecostés.
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.
9.
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.
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.
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.
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
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.
"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.