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.
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.
Presentación de Introducción a las metodologías Ágiles de la comunidad Agile Aragón (@AgileAragon)
Contenido original creado por María Berenguer y Pedro Lafuente
El contenido de esta presentación es libre de ser difundido/modificado/reusado para uso no comercial
Creative Commons Attribution-NonCommercial-ShareAlike
* Mindset Agile: de dónde venimos
* Historia: el desarrollo de software antes de Agile y comparativas
* Desarrollo Iterativo Incremental
* Equipo: definición de equipo, y nuevos roles
Información General de Scrum
A mediados de los 80, Hirotaka Takeuchi y Ikujiro Nonaka definieron una estrategia de desarrollo de Producto flexible donde el equipo de desarrollo trabaja como una unidad para alcanzar un objetivo común. Ambos describieron un enfoque innovador para el desarrollo de Producto al que ellos llaman un enfoque holístico o "rugby", "donde un equipo intenta llegar hasta el final como una unidad, pasando el balón hacia atrás y hacia delante”. Ellos basan su enfoque en los estudios de casos de diversas industrias de fabricación.
Ken Schwaber y Jeff Sutherland utilizan Scrum al desarrollo de software durante una presentación en la conferencia Object-Oriented Programa ming, Systems, Languages & Applications (OOPSLA) en 1995 en Austin, Texas. Desde entonces, varios practicantes, expertos y autores de Scrum han seguido perfeccionando la conceptualización y metodología de Scrum.
Join BostonPHP and Michael Bourque as he presents the concept of Scrum and shows why so many people are now deploying scrum to their development projects. Michael will take us through the process and talk about how his company, Parametric Technology Inc. (PTC) , is successfully applying Scrum.
Agile methodology is a framework for modern software development.
What is the philosophy behind Agile?
How does it differ from traditional project management strategies like waterfall?
What are the stages, meetings, tools, and team roles?
What is Scrum?
Presentación de Introducción a las metodologías Ágiles de la comunidad Agile Aragón (@AgileAragon)
Contenido original creado por María Berenguer y Pedro Lafuente
El contenido de esta presentación es libre de ser difundido/modificado/reusado para uso no comercial
Creative Commons Attribution-NonCommercial-ShareAlike
* Mindset Agile: de dónde venimos
* Historia: el desarrollo de software antes de Agile y comparativas
* Desarrollo Iterativo Incremental
* Equipo: definición de equipo, y nuevos roles
Información General de Scrum
A mediados de los 80, Hirotaka Takeuchi y Ikujiro Nonaka definieron una estrategia de desarrollo de Producto flexible donde el equipo de desarrollo trabaja como una unidad para alcanzar un objetivo común. Ambos describieron un enfoque innovador para el desarrollo de Producto al que ellos llaman un enfoque holístico o "rugby", "donde un equipo intenta llegar hasta el final como una unidad, pasando el balón hacia atrás y hacia delante”. Ellos basan su enfoque en los estudios de casos de diversas industrias de fabricación.
Ken Schwaber y Jeff Sutherland utilizan Scrum al desarrollo de software durante una presentación en la conferencia Object-Oriented Programa ming, Systems, Languages & Applications (OOPSLA) en 1995 en Austin, Texas. Desde entonces, varios practicantes, expertos y autores de Scrum han seguido perfeccionando la conceptualización y metodología de Scrum.
Join BostonPHP and Michael Bourque as he presents the concept of Scrum and shows why so many people are now deploying scrum to their development projects. Michael will take us through the process and talk about how his company, Parametric Technology Inc. (PTC) , is successfully applying Scrum.
Agile methodology is a framework for modern software development.
What is the philosophy behind Agile?
How does it differ from traditional project management strategies like waterfall?
What are the stages, meetings, tools, and team roles?
What is Scrum?
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.
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.
Prácticas Ágiles en entornos hostiles de desarrollo (Parte 2)Luis Mulato
Parte2: De lo prescriptivo a lo adaptativo
Agilidad / Manifiesto Ágil / Métodos Ágiles vs Rup / eXtreme Programming / Scrum / Métodos Ágiles / El Universo Ágil / Retrospectiva.
Jornada de Sensibilización sobre el Uso y Manejo de las Redes Sociales en San...Emergya
Slides de la jornada sobre redes sociales organizada por Andalucía Compromiso Digital he impartida por Pilar Choza y María José Santos de Emergya, empresa mecenas del proyecto
SIG libre en aplicaciones de gestión de emergenciasEmergya
Comunicación presentada como colaboración entre Telefónica Soluciones y Emergya en las VI jornadas de SIG libre de Girona
http://www.sigte.udg.edu/jornadassiglibre2012/programa/jornadas
Planificación y optimización de rutas con Software LibreEmergya
Exposición durante las jornadas de innovación opensource en la empresa .
http://eoi.es/portal/guest/evento/1557/jornada-innovacion-open-source-en-la-empresa
Interacción escritorio-web para la movilidad del autónomoEmergya
El salto que supuso al autónomo y a la micropyme el correo electrónico en el móvil se está viendo complementado por nuevos servicios que repiten el modelo sobre la ubicuidad de la información: en cualquier dispositivo, en cualquier momento. En esta presentación se destacan herramientas de software libre que nos ayudan a llevar siempre con nosotros contactos, ficheros, notas y tareas.
Orca: A screen reader sailing into uncharted waters Emergya
Orca, the screen reader of the GNOME Desktop, is moving into previously-uncharted territory: giving computer users who are blind -- and the developers of the assistive technologies they use -- a single tool which is more tightly integrated within the platform and designed to access multiple desktop environments, including KDE.
Orca, the screen reader of the GNOME Desktop, is moving into previously-uncharted territory: giving computer users who are blind -- and the developers of the assistive technologies they use -- a single tool which is more tightly integrated within the platform and designed to access multiple desktop environments, including KDE.
This session will take a brief look back at the history of Orca and screenreaders in general and bring audience up to speed on screen reading technologies. With this foundation laid, the current and future development of Orca will be presented, including the team’s efforts to further eliminate access barriers for people with visual impairments.
(PROYECTO) Límites entre el Arte, los Medios de Comunicación y la Informáticavazquezgarciajesusma
En este proyecto de investigación nos adentraremos en el fascinante mundo de la intersección entre el arte y los medios de comunicación en el campo de la informática.
La rápida evolución de la tecnología ha llevado a una fusión cada vez más estrecha entre el arte y los medios digitales, generando nuevas formas de expresión y comunicación.
Continuando con el desarrollo de nuestro proyecto haremos uso del método inductivo porque organizamos nuestra investigación a la particular a lo general. El diseño metodológico del trabajo es no experimental y transversal ya que no existe manipulación deliberada de las variables ni de la situación, si no que se observa los fundamental y como se dan en su contestó natural para después analizarlos.
El diseño es transversal porque los datos se recolectan en un solo momento y su propósito es describir variables y analizar su interrelación, solo se desea saber la incidencia y el valor de uno o más variables, el diseño será descriptivo porque se requiere establecer relación entre dos o más de estás.
Mediante una encuesta recopilamos la información de este proyecto los alumnos tengan conocimiento de la evolución del arte y los medios de comunicación en la información y su importancia para la institución.
Es un diagrama para La asistencia técnica o apoyo técnico es brindada por las compañías para que sus clientes puedan hacer uso de sus productos o servicios de la manera en que fueron puestos a la venta.
3Redu: Responsabilidad, Resiliencia y Respetocdraco
¡Hola! Somos 3Redu, conformados por Juan Camilo y Cristian. Entendemos las dificultades que enfrentan muchos estudiantes al tratar de comprender conceptos matemáticos. Nuestro objetivo es brindar una solución inclusiva y accesible para todos.
Índice del libro "Big Data: Tecnologías para arquitecturas Data-Centric" de 0...Telefónica
Índice del libro "Big Data: Tecnologías para arquitecturas Data-Centric" de 0xWord escrito por Ibón Reinoso ( https://mypublicinbox.com/IBhone ) con Prólogo de Chema Alonso ( https://mypublicinbox.com/ChemaAlonso ). Puedes comprarlo aquí: https://0xword.com/es/libros/233-big-data-tecnologias-para-arquitecturas-data-centric.html
7. Problemas clásicos en el
Desarrollo
▪ Cambios de contexto y de alcance
▪ Aparecen retrasos => No hay tiempo para pruebas
▪ Planificaciones poco realistas
▪ Cliente poco involucrado
▪ Falta de comunicación
▪ Equipo poco motivado
▪ No hay flexibilidad
▪ El resultado no es lo esperado por el cliente
Resultado: Equipo y cliente insatisfechos. Tiempo y dinero perdido.
8. Un poco de
Historia
1986
En EEUU y Japón surge el
concepto debido a la
necesidad de salir al
mercado muy rápido con
requisitos muy novedosos.
1993 - 1995
Se documenta y formaliza
el primer documento de
Scrum para desarrollo ágil
de software.
2001
Las personas más
relevantes del desarrollo
ágil escriben el Manifiesto
Ágil donde se recogen sus 4
principios.
… Antes de todo esto
A finales del S. XIX ~ principios del S. XX surge el concepto Lean Manufacturing de la mano
de Toyota.
9. Principios de Lean
- Calidad. Detección de problemas
al principio
- Eliminar lo que no aporte valor
- Mejora continua
- Producir lo necesario
- Flexibilidad
- Compartir información
TOYOTA - Lean Manufacturing
The Seven Wastes
- Sobreproducción
- Tiempo de espera
- Transporte
- Exceso de procesado
- Inventario
- Movimiento
- Defectos
10. “ Individuos e interacciones sobre procesos y herramientas
Manifiesto Ágil
Software funcionando sobre documentación excesiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
12. Desarrollo en Cascada
▪ Poco flexible. No se puede ir atrás
▪ Muy estricto. No permite cambios de alcance
▪ Pequeños errores causan grandes problemas
▪ No se entrega valor hasta el final
▪ Mucha documentación inservible
16. “ Se dedica mucho esfuerzo a
alcanzar objetivos que aportan
muy poco valor.
Dinero perdido + tiempo perdido = Cliente insatisfecho
17. El gran enemigo
Los cambios
Cambios en el
alcance
Cambios de
funcionalidad
Cambios de
tecnología
18. Otros errores
Típicos
▪ No medir el avance o medirlo mal
▪ Añadir más personas creyendo que se irá más rápido
▪ No hacer pruebas desde el principio
▪ Creer que estamos construyendo una casa en vez de software
▪ No tener una visión global del estado actual
▪ Poca implicación del cliente
▪ Estimaciones sin técnicos
▪ Pérdida del foco
▪ No decir no
▪ No obtener feedback
▪ Herramientas inadecuadas para planificar
21. Beneficios
Metodologías Ágiles
Calidad
Realizando pruebas desde el
principio e iterando sobre el
producto tras recibir el
feedback.
Resultados
Entregando algo tangible y
que aporte valor desde la
primera iteración.
Flexibilidad
Permitiendo cambios de
alcance, estimando y
planificando de manera ágil.
Mantenibilidad
Creando un software de
calidad, con casos de prueba
y una documentación
asumible.
Eliminación de riesgos
Validando cada entrega en
sprints cortos y asegurando
la calidad con casos de
pruebas.
Motivación
Trabajando de manera
conjunta con el cliente,
viendo crecer el producto
final tras cada iteración.
25. Casos de uso
Descripción de todos los pasos
que se deben llevar a cabo para
realizar una acción.
Especificación de interacciones
entre los actores y el sistema.
Casos de uso vs
Historias de usuario
Historias de usuario
Definición corta de una
funcionalidad, que debe poder
escribirse en una nota adhesiva.
Lenguaje sencillo de entender
por el equipo y el cliente.
27. Historias de
Usuario
▪ Siguen el patrón: “Cómo - Quiero - Para”
▪ Sirven para especificar requisitos
▪ Son independientes unas de otras
▪ Son pequeñas
▪ Se pueden estimar
▪ Se pueden verificar una vez implementadas
▪ Son flexibles
▪ Son entendibles y fomentan la comunicación
28. Jefe vs
Líder
▪ Desaparece el jefe autoritario por el
líder con conocimientos que guía al
equipo.
▪ Soluciones vs problemas
▪ Confianza vs miedo
▪ Convencer vs imponer
www.upadpsicologiacoaching.com
31. Qué es
Scrum
▪ Marco de trabajo para desarrollos ágiles
▪ Desarrollo incremental vs planificación y ejecución completa
▪ Equipos auto organizados
▪ Paralelización de las fases de desarrollo vs fases secuenciales
▪ Priorización de los requisitos que más valor aporten
▪ Mejora continua
33. Glosario
Scrum
Product Backlog
Listado dinámico, público y
actualizado con todos los
requisitos del producto.
Debe estar priorizado. Es de
alto nivel, no entra en
detalles de implementación.
Sprint Backlog
Listado de requisitos que se
van a abordar en el sprint.
Cada historia de usuario se
desgrana en tareas
asumibles y se estiman.
Gráfico Burndown
Gráfico que muestra la
cantidad de requisitos
pendientes al comienzo del
sprint junto a los requisitos
completados. Da una visión
global del estado.
Sprint
Iteración de entre 1 y 4 semanas (normalmente 2). Al final del sprint se realiza una entrega
al cliente con las nuevas funcionalidades. Entrega continua de valor.
34. Roles en
Scrum
Product Owner
Participa en la
definición del
producto. Representa
al negocio y prioriza
historias de usuario.
Nexo de unión entre
los implicados. Debe
maximizar el valor del
producto.
Scrum Master
Encargado de que se
cumplan las reglas de
Scrum. Resuelve
posibles conflictos.
Motiva y protege al
equipo. Su tarea es
facilitar el trabajo al
equipo.
Development Team
Equipo
multidisciplinar
autoorganizado
(desarrolladores, QA,
diseño, UX,
arquitectos…)
Encargado del
desarrollo del
producto.
35. Ceremonias de
Scrum
Daily Scrum
Reunión diaria donde sólo los involucrados
pueden hablar. Se responden 3 preguntas:
- ¿Qué hiciste ayer?
- ¿Qué vas a hacer hoy?
- ¿Tienes algún bloqueo?
Sprint Review
Al final del sprint. Se revisa el trabajo que se ha
completado y el que no se ha terminado. Se
hace una demostración y se obtiene feedback.
Sprint Planning
Al inicio de cada sprint. Se selecciona el
trabajo que se va a hacer en este sprint y
se estima.
Sprint Retrospective
Al final del sprint. Se reunen todos los implicados
para analizar qué se ha hecho bien y se debe
seguir haciendo y qué se ha hecho mal y se debe
cambiar.
36. La importancia de
Priorizar
▪ Es una responsabilidad del Product Owner
▪ Se debe priorizar por el valor que aporta cada historia
▪ No se debe priorizar por la complejidad para desarrollarlas
▪ Existen muchas técnicas, como por ejemplo:
▫ Modelo Kano:
▸ Requisitos obligatorios (Básicos)
▸ Requisitos deseados (Esperados)
▸ Requisitos no esperados (Inesperados)
▸ Indiferentes (No aportan valor)
▫ MoSCoW: (Must, Should, Could y Won’t)
37. La necesidad de
Estimar
▪ Es una responsabilidad de todo el equipo
▪ Todas las tareas deben ser estimadas
▪ Estimación basada en el conocimiento y en la experiencia
▪ Estimar en puntos y conocer la velocidad del equipo
▪ Planning Poker:
▫ Se utiliza la secuencia de Fibonacci
▫ Se explica la historia y se resuelven dudas
▫ Se busca unanimidad y consenso
39. Qué es
Kanban
▪ Término japonés: Tarjetas visuales 看板
▪ Proporciona un flujo de trabajo para dividir el proceso en fases
▪ Complementario con Scrum
▪ Los 4 principios básicos de Kanban:
▫ Empieza con lo que haces ahora
▫ Acepta el cambio
▫ Respeta el proceso actual, roles y responsabilidades
▫ Liderazgo en todos los niveles
41. Tablero
Kanban
▪ Se usa para organizar las tareas del sprint en curso
▪ Se puede adaptar a las necesidades
▪ Se van moviendo las tarjetas por las diferentes columnas
▪ Sirve para tener una visión global del estado actual del sprint
DoD: Definition of Done
Antes de empezar es necesario definir qué
significa que una tarea está terminada.
44. Qué es
XP
▪ Metodología ágil de desarrollo software basada en la flexibilidad
▪ Se considera que los cambios de requisitos son un aspecto natural
▪ Valores de XP:
▫ Simplicidad
▫ Comunicación
▫ Retroalimentación
▫ Valentía
▫ Respeto
45. Técnicas y características
XP
TDD
Desarrollo guiado por
pruebas. Antes de
programar se deben escribir
las pruebas que validen cada
funcionalidad.
Pair Programming
Técnica en la que dos
programadores comparten
el mismo ordenador para
desarrollar a la vez.
Integración con cliente
Se recomienda que al menos
una persona del cliente
trabaje de manera conjunta al
equipo de desarrollo.
Refactorización
Sobreescribir ciertas partes
del código para mejorar su
legibilidad y mantenibilidad
sin modificar su
funcionamiento.
Propiedad compartida
Se promueve que todos los
miembros del equipo
puedan tocar cualquier parte
del código.
Simplicidad
Cuanto más simple sea el
sistema que se construya más
fácil será comprenderlo y añadir
nuevas funcionalidades.