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.
Conjunto de preguntas y ejercicios que brindan la posibilidad de mejorar las oportunidades para que los proyectos software sean exitosos, haciendo que todos los implicados tengan los mismos objetivos en relación al proyecto.
Esta presentación incluye una introducción de Scrum en Proyectos que hemos realizado en tecnología Microsoft. Usando herramientas que nos permite llevar todo el ciclo de vida del proyecto con la metodología ágil como SCRUM. Herramientas como Visual Studio Team Services (VSTS) permiten facilitar el trabajo del equipo desde la planeación del sprint hasta la entrega del producto.
Agenda:
1. Manifiesto Ágil
2. Scrum
3. Valores Scrum
4. Roles Scrum
5. Actividades Scrum
6. Logros Scrum en iTS y proximos pasos
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.
Conjunto de preguntas y ejercicios que brindan la posibilidad de mejorar las oportunidades para que los proyectos software sean exitosos, haciendo que todos los implicados tengan los mismos objetivos en relación al proyecto.
Esta presentación incluye una introducción de Scrum en Proyectos que hemos realizado en tecnología Microsoft. Usando herramientas que nos permite llevar todo el ciclo de vida del proyecto con la metodología ágil como SCRUM. Herramientas como Visual Studio Team Services (VSTS) permiten facilitar el trabajo del equipo desde la planeación del sprint hasta la entrega del producto.
Agenda:
1. Manifiesto Ágil
2. Scrum
3. Valores Scrum
4. Roles Scrum
5. Actividades Scrum
6. Logros Scrum en iTS y proximos pasos
Las Pruebas de Software son todavía una de las áreas más desatendidas del desarrollo y espliegue de los productos de software. Las Pruebas de Software son predominantemente vistas como una actividad periférica, casi una formalidad, antes del espliegue del software. Un cambio de actitud y un buen programa de estudios como fundamento hacia las Pruebas de Software pueden reducir tremendamente los problemas normalmente asociados con el lanzamiento del nuevo software y minimizar el riesgo implicado. El programa de estudio del ISTQB (International Software Testing Qualifications Board) Probador Certificado (Certified Tester) ofrece el mejor
entrenamiento estandarizado del mundo para los probadores de software.
Este libro le proporcionará el conocimiento esencial para ser un profesional en Pruebas, que incluye:
Fundamentos de Pruebas
Pruebas a través del Ciclo de Vida de Software
Técnicas Estáticas
Técnicas de Diseño de Pruebas
Gestión de Pruebas
Soporte de las Herramientas de Pruebas
Adquisición de Herramientas y Software en General en una Organización
Más de 200 preguntas de examen de muestra con soluciones
Ejercicios prácticos y soluciones por cada tema cubierto
Caso real, resuelto, como ejemplo a lo largo de los temas
Dos exámenes de simulación del examen real
Estándares de Pruebas
Excelente Bibliografía
Cabe señalar que este libro no es sólo para los probadores sino también para quienes están encargados de la adquisición de software en general, gerentes de tecnología, gerentes del Aseguramiento de la Calidad/Control de la Calidad (QA/QC), gerentes de sistemas, jefes de proyectos de software, analistas, arquitectos, desarrolladores, estudiantes y profesores de TI.
Asimismo este libro está diseñado para el autoestudio. El contenido comprende el programa de estudios necesario para aprobar el examen de certificación nivel básico definido por el ISTQB versión 2011 (Syllabus 2011).
Ponencia de Scrum del evento "PMBOK vs Scrum" dada en UNMSM el 9 de noviembre del 2016, abordando historia de scrum y metodologías ágiles con un ejemplo practica de la facilidad que puede implementarse.
Las Pruebas de Software son todavía una de las áreas más desatendidas del desarrollo y espliegue de los productos de software. Las Pruebas de Software son predominantemente vistas como una actividad periférica, casi una formalidad, antes del espliegue del software. Un cambio de actitud y un buen programa de estudios como fundamento hacia las Pruebas de Software pueden reducir tremendamente los problemas normalmente asociados con el lanzamiento del nuevo software y minimizar el riesgo implicado. El programa de estudio del ISTQB (International Software Testing Qualifications Board) Probador Certificado (Certified Tester) ofrece el mejor
entrenamiento estandarizado del mundo para los probadores de software.
Este libro le proporcionará el conocimiento esencial para ser un profesional en Pruebas, que incluye:
Fundamentos de Pruebas
Pruebas a través del Ciclo de Vida de Software
Técnicas Estáticas
Técnicas de Diseño de Pruebas
Gestión de Pruebas
Soporte de las Herramientas de Pruebas
Adquisición de Herramientas y Software en General en una Organización
Más de 200 preguntas de examen de muestra con soluciones
Ejercicios prácticos y soluciones por cada tema cubierto
Caso real, resuelto, como ejemplo a lo largo de los temas
Dos exámenes de simulación del examen real
Estándares de Pruebas
Excelente Bibliografía
Cabe señalar que este libro no es sólo para los probadores sino también para quienes están encargados de la adquisición de software en general, gerentes de tecnología, gerentes del Aseguramiento de la Calidad/Control de la Calidad (QA/QC), gerentes de sistemas, jefes de proyectos de software, analistas, arquitectos, desarrolladores, estudiantes y profesores de TI.
Asimismo este libro está diseñado para el autoestudio. El contenido comprende el programa de estudios necesario para aprobar el examen de certificación nivel básico definido por el ISTQB versión 2011 (Syllabus 2011).
Ponencia de Scrum del evento "PMBOK vs Scrum" dada en UNMSM el 9 de noviembre del 2016, abordando historia de scrum y metodologías ágiles con un ejemplo practica de la facilidad que puede implementarse.
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.
El viaje agil comienza con la historia, la vivida y la que podemos escribir a partir de hoy. Scrumstudy certificador de clase mundial con el SBOK la guia de conocimientos de scrum
Versión de la presentación "La alternativa ágil" usada en la charla del mismo nombre durante el Uniencounter de Marzo de 2011
Como novedad incorpora la parte "El profesional", y habla de orgullo, habilidades y software craftmanship :)
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.
¿Agile PMO? - Agile Product Management as an Organization.
Ponencia originalmente realizada en Agiles Colombia 2017 y AgileDefender.org 2017.
Posteriormente articulo publicado en ScrumAlliance.org con base en feedback de ponencias realizadas:
https://www.scrumalliance.org/community/member-articles/2025
Republicado en mi blog: http://www.agilisters.org/2018/02/agile-pmo.html
Mediante este curso aprenderás desde cero la filosofía detrás de las metodologías ágiles, cómo es y cómo implementar con éxito SCRUM, qué diferencias hay con respecto a las metodologías tradicionales (Waterfall) y cómo convivir en entornos mixtos mediante Scrumfall. También haremos una breve introducción a otras metodologías ágiles, como TDD o XP (eXtreme Programming)
Razones para adoptar ágil, fallas y tips para hacerlo de forma correcta.
- Hasta la diapositiva 51, introducción a la agilidas
- de la 52 a la 80 por que los equipos ágiles son más "rápidos" y efectivos
- de la 81 a la 94 errores en la adopcion agile
- de la 95 en adelante mitos y tips en la adopción ágil
Se comparten varios tips que promueven al mejora del rendimiento de los equipos ágiles, es decir los que cumplen con el manifiesto ágil, tipo scrum, scrumban, xp, kanban
Hola a todos,
Mientras escribo el post, quisiera compartirles esta imagen, sobre lo que REALMENTE significa pruebas unitarias, he observado que el término es mál empleado por DESARROLLADORES, TESTER, GERENTES DE PROYECTO, SCRUM MASTER, AGILE COACHES.
Es un pequeño servicio social.
Esperando con el resolver muchas dudas al respecto.
Hola a todos
A finales del pasado tuve la oportunidad de brindar un Seminario-Taller sobre Transformación Ágil para una prestigiosa universidad de la ciudad de Medellín dirigido específicamente a una importante organización del sector energético.
Hoy quiero compartirles TODO el material que elaboré y trabajamos; sin restricciones.
Pero también he observado que por más bueno que sea el material, sin la explicación y heridas de guerra del experto, queda incompleto; por lo tanto, si estas interesad@ en ir más allá del material y participar en un Webinar que dictaré:
• Cuándo: en el mes de Julio de 2020
• Intensidad: 3 sábados
• Duración: 9 horas (3 horas cada sesión)
• Inversión: 90 dólares
diligencia el siguiente formato y te estaré contactando para los siguientes pasos.
https://docs.google.com/forms/d/e/1FAIpQLSfJkIU1LyJO3cCKIkgzXhAMNRJHNZpyeEBv148jKZEFeJ4zuA/viewform
Saludos ágiles
Jorge Abad.
Publicado en : http://www.lecciones-aprendidas.info/2020/05/diapositivas-seminario-taller-sobre-transformacion-agil.html
Conferencia "Agile marketing para hacer frente a los cambios"
Todo el mundo busca ser ágil. Ahorrar tiempo, minimizar recursos y duplicar los resultados. Sin embargo, ¿es algo que nace innato o se puede entrenar?
En la mayoría de los casos la agilidad puede trabajarse. Y en marketing en concreto, existe una tendencia que aporta las claves para hacerlo: el Agile Marketing.
En esta presentación se describen tips para que las PMO comiencen con sus pilotos ágiles y algunas estrategias para que se comience a agilizar el portafolio de proyectos y productos.
Escaneo y eliminación de malware en el equiponicromante2000
El malware tiene muchas caras, y es que los programas maliciosos se reproducen en los ordenadores de diferentes formas. Ya se trate de virus, de programas espía o de troyanos, la presencia de software malicioso en los sistemas informáticos siempre debería evitarse. Aquí te muestro como trabaja un anti malware a la hora de analizar tu equipo
Si bien los hospitales conjuntan a profesionales de salud que atienden a la población, existe un equipo de organización, coordinación y administración que permite que los cuidados clínicos se otorguen de manera constante y sin obstáculos.
Mario García Baltazar, director del área de Tecnología (TI) del Hospital Victoria La Salle, relató la manera en la que el departamento que él lidera, apoyado en Cirrus y Estela, brinda servicio a los clientes internos de la institución e impulsa una experiencia positiva en el paciente.
Conoce el Hospital Victoria La Salle
Ubicado en Ciudad Victoria, Tamaulipas, México
Inició operaciones en el 2016
Forma parte del Consorcio Mexicanos de Hospitales
Hospital de segundo nivel
21 habitaciones para estancia
31 camas censables
13 camillas
2 quirófanos
+174 integrantes en su plantilla
+120 equipos médicos de alta tecnología
+900 pacientes atendidos
Servicios de +20 especialidades
Módulos utilizados de Cirrus
HIS
EHR
ERP
Estela - Business Intelligence
6. jorge.abad@gmail.com
Causa de Fracasos en los
Proyectos
09/08/2014 6
• Cronogramas poco realistas
• Personal inadecuado
• Cambios en los requerimientos
• Trabajo de pobre calidad
• Creer en magia
Winning with Software: An Executive
Strategy. Watts S. Humphrey
10. jorge.abad@gmail.com
Los 12 Principios
1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega
temprana y continua de software con valor.
2. Aceptamos que los requisitos cambien, incluso en etapas tardías del
desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar
ventaja competitiva al cliente.
3. Entregamos software funcional frecuentemente, entre dos semanas y
dos meses, con preferencia al periodo de tiempo más corto posible.
4. Los responsables de negocio y los desarrolladores trabajamos juntos
de forma cotidiana durante todo el proyecto.
5. Los proyectos se desarrollan en torno a individuos motivados. Hay que
darles el entorno y el apoyo que necesitan, y confiarles la ejecución del
trabajo.
6. El método más eficiente y efectivo de comunicar información al equipo
de desarrollo y entre sus miembros es la conversación cara a cara.
7. El software funcionando es la medida principal de progreso.
http://agilemanifesto.org/iso/es/
11. jorge.abad@gmail.com
Los 12 Principios
8. Los procesos Ágiles promueven el desarrollo sostenible. Los
promotores, desarrolladores y usuarios debemos ser capaces de
mantener un ritmo constante de forma indefinida.
9. La atención continua a la excelencia técnica y al buen diseño mejora la
Agilidad.
10.La simplicidad, o el arte de maximizar la cantidad de trabajo no
realizado, es esencial.
11.Las mejores arquitecturas, requisitos y diseños emergen de equipos
auto-organizados.
12.A intervalos regulares el equipo reflexiona sobre cómo ser más
efectivo para a continuación ajustar y perfeccionar su comportamiento
en consecuencia.
http://agilemanifesto.org/iso/es/
12. jorge.abad@gmail.com
Valores
• Compromiso
• Enfoque y Foco
• Apertura y transparencia
• Respeto
• Coraje
09/08/2014
PLANIFICACIÓN Y GESTIÓN DE
PROYECTOS INFORMÁTICOS
ESPECIALIZACIÓN EN INGENIERÍA DE
SOFTWARE – UNIVERSIDAD DE
12
13. Cambio de Esquema de Negociación
Lacey, Mitch. The Scrum Field Guide: Practical Advice for Your
First Year (Agile Software Development Series)
21. jorge.abad@gmail.com
Estamos perdiendo la carrera
de relevos
Hirotaka Takeuchi and Ikujiro Nonaka,
“The New New Product Development
Game”, Harvard Business Review, January
1986.
“En enfoque de ‘carrera de relevos’ en el
desarrollo de productos ... puede entrar en
conflicto con los objetivos de máxima
velocidad y flexibilidad. En su lugar, un
enfoque holístico o estilo ‘rugby’ - donde un
equipo intenta ir a la distancia como una
unidad, pasando la pelota hacia adelante y
hacia atrás -pueden servir mejor a los
actuales requisitos competitivos".
22. jorge.abad@gmail.com
• Scrum es un proceso ágil que nos permite centrarnos
en ofrecer el más alto valor de negocio en el menor
tiempo.
• Nos permite rápidamente y en repetidas ocasiones
inspeccionar software real de trabajo (cada dos semanas o
un mes).
• El negocio fija las prioridades. Los equipos se auto-
organizan a fin de determinar la mejor manera de
entregar las funcionalidades de más alta prioridad.
• Cada dos semanas o un mes, cualquiera puede ver el
software real funcionando y decidir si liberarlo o seguir
mejorandolo en otro sprint.
Scrum en 100 palabras
23. jorge.abad@gmail.com
• Scrum es una framework metodológico para la
gestión de proyectos, expuesta por Hirotaka
Takeuchi e Ikujiro Nonaka, en el artículo The New
New Product Development Game[Harvard Business
Review Ene-Feb 1986] en el que ponen de
manifiesto que:
o El mercado competitivo de los productos tecnológicos,
además de los conceptos básicos de calidad, coste y
diferenciación, exige también rapidez y flexibilidad.
o Los nuevos productos representan cada vez un porcentaje
más importante en el volumen de negocio de las
empresas.
o El mercado exige ciclos de desarrollo más cortos.
SCRUM
24. jorge.abad@gmail.com
Orígenes de Scrum
• Jeff Sutherland
o Scrums iniciales en Easel Corp en 1993
o IDX 500 personas haciendo Scrum
• Ken Schwaber
o ADM
o Se presenta Scrum en OOPSLA 96 con
Sutherland
o Autor de tres libros sobre Scrum
• Mike Beedle
o Patrones Scrum en PLOPD4
• Ken Schwaber and Mike Cohn
o Fundaron conjuntamente la Scrum Alliance en
2002, inicialmente dentro de la Agile Alliance
25. jorge.abad@gmail.com
Scrum ha sido utilizado por:
•Microsoft
•Yahoo
•Google
•Electronic Arts
•High Moon Studios
•Lockheed Martin
•Philips
•Siemens
•Nokia
•Capital One
•BBC
•Intuit
•Intuit
•Nielsen Media
•First American Real Estate
•BMC Software
•Ipswitch
•John Deere
•Lexis Nexis
•Sabre
•Salesforce.com
•Time Warner
•Turner Broadcasting
•Oce
26. jorge.abad@gmail.com
Scrum ha sido utilizado para:• Software comercial
• Desarrollos internos
• Desarrollos bajo Contrato
• Proyectos Fixed-price
• Aplicaciones Financieras
• Aplicaciones certificadas
ISO 9001
• Sistemas Embebidos
• Sistemas con requisitos
7x24 y 99.999% de
disponibilidad
• Joint Strike Fighter
• Desarrollo de video juegos
• Sistemas críticos de soporte
vital, aprobados por laFDA
• Software de control satelital
• Sitios Web
• Software para Handheld
• Teléfonos portátiles
• Aplicaciones de Network
switching
• Aplicaciones de ISV
• Algunas de las más grandes
aplicaciones en uso
27. jorge.abad@gmail.com
Características
Equipos auto-organizados
El producto avanza en una serie de
“Sprints" de dos semanas a un mes de
duración
Los requisitos son capturados como
elementos de una lista de “Product
Backlog"
No hay prácticas de ingeniería prescritas
Utiliza normas generativas para crear un
entorno ágil para la entrega de proyectos
Uno de los “procesos ágiles”
30. jorge.abad@gmail.com
Sprints
• En Scrum los proyectos avanzan en una
serie de “Sprints”
o Análogo a las iteraciones en XP
• La duración típica es 2–4 semanas o a lo
sumo un mes calendario
• La duración constante conduce a un
mejor ritmo
• El product es diseñado, codificado y
testeado durante el Sprint
31. jorge.abad@gmail.com
Desarrollo secuencial vs.
superpuesto
Source: “The New New Product Development Game” by
Takeuchi and Nonaka. Harvard Business Review, January 1986.
En lugar de hacer todo
de una cosa a la vez ...
...los equipos Scrum hacen
un poco de todo todo el
tiempo
Requisitos Diseño Código Test
32. jorge.abad@gmail.com
No hay cambios en un
sprint
Planee la duración del sprint en torno a
cuánto tiempo usted puede comprometerse
a mantener los cambios fuera del sprint
Cambios
37. jorge.abad@gmail.com
Product Owner
Define las funcionalidades del producto
Decide sobre las fechas y contenidos de los releases
Es responsable por la rentabilidad del producto (ROI)
Prioriza funcionalidades de acuerdo al valor del
mercado/negocio
Ajusta funcionalidades y prioridades en cada
iteración si es necesario
Acepta o rechaza los resultados del trabajo del
equipo
39. jorge.abad@gmail.com
El ScrumMaster
• Representa a la gestión del proyecto
• Responsable de promover los valores y prácticas
de Scrum
• Remueve impedimentos
• Se asegura de que el equipo es completamente
funcional y productivo
• Permite la estrecha cooperación en todos los
roles y funciones
• Escudo del equipo de interferencias externas
40. jorge.abad@gmail.com
El Team
Típicamente de 5 a 9 personas
Multi-funcional:
◦ Programadores, testers, analistas, diseñadores, etc.
Los miembros deben ser full-time
◦ Puede haber excepciones (Ej.: Infraestructura, SCM,
etc.)
Los equipos son auto-organizativos
◦ Idealmente, no existen títulos pero a veces se utilizan
de acuerdo a la organización
Solo puede haber cambio de miembros entre los
sprints
43. jorge.abad@gmail.com
Sprint Planning meeting
Priorización
• Analizar y evaluar el Product
Backlog
• Seleccionar el objetivo del Sprint
Planificación
• Decidir como alcanzar el
objetivo del Sprint (diseño)
• Crear el Sprint Backlog (tareas)
en base a los temas del Product
Backlog (user stories / features)
• Estimar Sprint Backlog en horas
Objetivo
del
Sprint
Sprint
Backlog
Condicione
s del
Negocio
Capacidad
del Equipo
Product
Backlog
Tecnología
Producto
Actual
44. jorge.abad@gmail.com
Planificación del Sprint
• El equipo selecciona los temas a partir del Product
Backlog que pueden comprometerse a completar
• Se crea el Sprint Backlog
o Se identifican tareas y cada una es estimada (1-16
horas)
o Realizado colaborativamente, no solo por el
ScrumMaster
• El diseño de Alto Nivel es considerado
YO COMO planificador
de vacaciones, QUIERO
ver fotos de los
hoteles. PARA poder
mostrar diferentes
sitios a mis clientes
Codificar la capa intermedia (8
hs)
Codificar la interfaz de usuario
(4)
Escribir los test fixtures (4)
Codificar la clase foo (6)
Actualizar test de performance (4)
45. jorge.abad@gmail.com
Daily Scrum
• Parámetros
o Diaria
o Dura 15 minutos
o Parados
• No para la solución de problemas
o Todo el mundo está invitado
o Sólo los miembros del equipo, ScrumMaster y Product Owner, pueden
hablar
o Ayuda a evitar otras reuniones innecesarias
46. jorge.abad@gmail.com
Todos responden 3
preguntas
• No es dar un status report al Scrum Master
• Se trata de compromisos delante de pares
¿Qué hiciste ayer?
1
¿Qué vas a hacer hoy?
2
¿Hay obstáculos en tu camino?
3
47. jorge.abad@gmail.com
Sprint review
El equipo presenta lo realizado durante
el sprint
Normalmente adopta la forma de una
demo de las nuevas características o la
arquitectura subyacente
Informal
◦ Regla de 2 hs preparación
◦ No usar diapositivas
Todo el equipo participa
Se invita a todo el mundo
48. jorge.abad@gmail.com
Sprint retrospective
• Periódicamente, se echa un vistazo a lo
que funciona y lo que no
• Normalmente 1 hora
• Se realiza luego de cada sprint
• Todo el equipo participa
o ScrumMaster
o Product owner
o Equipo
o Posiblemente clientes y otros
49. jorge.abad@gmail.com
Start / Stop / Continue
• Todo el equipo se reúne y discute lo que les
gustaría :
Comenzar a hacer
Dejar de hacer
Continuar haciendo
Esto es sólo una
de las muchas
maneras de
hacer una
retrospectiva.
52. jorge.abad@gmail.com
Product Backlog
• Los requisitos
• Una lista de todos los trabajos
deseados en el proyecto
• Idealmente cada tema tiene
valor para el usuarios o el cliente
• Priorizada por el Product Owner
• Repriorizada al comienzo de
cada Sprint
• Se aplica PARETO (el 20% de las
historias de usuario cumplen con
el 80% de las necesidades del P.O.
Este es el product
backlog
53. jorge.abad@gmail.com
Product
Backlog
09/08/2014 53
Lacey, Mitch. The Scrum Field Guide: Practical Advice for Your
First Year (Agile Software Development Series)
• Existen técnicas de
priorización como:
o Visual Story Mapping,
o Minimal Market
Feature,
o Impact Mapping
54. jorge.abad@gmail.com
Ejemplo de Product Backlog
Backlog item Estimación
Permitir que un invitado a hacer una reserva. 3
Como invitado, quiero cancelar una reserva. 5
Como invitado, quiero cambiar las fechas de
una reserva.
3
Como un empleado de hotel, puedo ejecutar
informes de los ingresos por habitación
disponible
8
Mejorar el manejo de excepciones 8
... 30
... 50
56. jorge.abad@gmail.com
El objetivo del Sprint
• Una breve declaración de cual será el foco del
trabajo durante el sprint
Aplicación con B.Datos
Servicios Financieros
Ciencias Biológicas
Funciones de apoyo técnico
necesarios para estudios de
genética de poblaciones.
Soportar más indicadores
técnicos que la empresa ABC en
tiempo real y streaming de
datos.
Hacer que la aplicación se
ejecute en SQL Server, además
de Oracle.
57. jorge.abad@gmail.com
Gestión del Sprint Backlog
Los individuos eligen las tareas
El trabajo nunca es asignado
La estimación del trabajo restante es actualizada
diariamente
Cualquier miembro del equipo puede añadir,
borrar o cambiar el Sprint Backlog
El trabajo para el Sprint emerge
Si el trabajo no está claro, definir un tema del Sprint
Backlog con una mayor cantidad de tiempo y
subdividirla luego.
Actualizar el trabajo restante a medida de que más
se conoce
58. jorge.abad@gmail.com
Ejemplo de Sprint Backlog
Tareas
Codificar UI
Codificar negocio
Testear negocio
Escribir ayuda online
Escribir la clase foo
L
8
16
8
12
8
M
4
12
16
8
M J
4
11
8
4
V
8
8
Agregar error logging
8
10
16
8
8
60. jorge.abad@gmail.com
Seguimiento
• Es recomendable, que el propietario del
producto emplee una hoja de cálculo, alguna
herramienta similar, o el soporte de una intranet,
para guardar en formato digital la pila del
producto.
• Pero no es aconsejable emplearla como base
para trabajar sobre ella en la reunión
proyectándola sobre la pantalla de la sala.
• Es mucho mejor trabajar y manipular elementos
físicos; y usar una pizarra y fichas removibles
(adhesivas, con chinchetas o magnéticas).
68. jorge.abad@gmail.com
Escalabilidad
• Normalmente los equipos son de 7 ± 2
personas
o La escalabilidad proviene de equipos de equipos
• Factores a tener cuenta
o Tipo de aplicación
o Tamaño del equipo
o Dispersión del equipo
o Duración del proyecto
• Scrum se ha utilizado en múltiples proyectos
de más de 500 personas
75. 09/08/2014 75
Scrum = reglas + espíritu + buenas
prácticas
¿En resumen en qué
consiste scrum?
El espiritu de Scrum.
Alan Cyment
76. jorge.abad@gmail.com
La magia no existe
• Ken Schwaber: “En Scrum, un grupo en el que se
lleven mal entre ellos, no comprendan el negocio
del cliente y trabajen con malas herramientas...
también producirán incrementos periódicos... de
basura. ”
• Dan visibilidad y transparencia desde el principio,
aunque no resuelven todos los problemas.
• No ser extremista, usar lo que te funcione
• Se recomienda primero usar todo, luego hacer
modificaciones. Cuidado con “Scrum but…”
78. jorge.abad@gmail.com
Una lista de lecturas sobre Scrum
• Agile and Iterative Development: A Manager’s Guide by
Craig Larman
• Agile Estimating and Planning by Mike Cohn
• Agile Project Management with Scrum by Ken Schwaber
• Agile Retrospectives by Esther Derby and Diana Larsen
• Agile Software Development Ecosystems by Jim Highsmith
• Agile Software Development with Scrum by Ken Schwaber
and Mike Beedle
• Scrum and The Enterprise by Ken Schwaber
• User Stories Applied for Agile Software Development by
Mike Cohn
• Artículos semanales en www.scrumalliance.org
85. jorge.abad@gmail.com
El Manifesto Ágil – una
declaración de valores
Procesos y
herramientas
Individuos e
interacciones
sobre
Seguimiento
de un plan
Responder
ante el cambio
sobre
Fuente: www.agilemanifesto.org
Documentación
exhaustiva
Software que
funciona
sobre
Negociación de
contratos
Colaboración
con el cliente
sobre
86. jorge.abad@gmail.com
Algunos principios y
valores ágiles
• La prioridad mayor es la satisfacción del cliente haciendo
entregas continuas de software valioso para él
• Los cambios son bienvenidos siempre
• La medida principal de progreso es el software funcionando
• El gestor es un facilitador no un controlador
• Equipos auto-organizados y multidisciplinares
• Inspeccionar y adaptar
• Mejora continua
• Respeto, claridad y comunicación
• Ritmo sostenible
• La arquitectura y diseño emergen
89. jorge.abad@gmail.com
La magia no existe
• Ken Schwaber: “En Scrum, un grupo en el que se
lleven mal entre ellos, no comprendan el negocio
del cliente y trabajen con malas herramientas...
también producirán incrementos periódicos... de
basura. ”
• Dan visibilidad y transparencia desde el principio,
aunque no resuelven todos los problemas.
• No ser extremista, usar lo que te funcione
• Se recomienda primero usar todo, luego hacer
modificaciones. Cuidado con “Scrum but…”
91. jorge.abad@gmail.com
Poker Game
• Planificación de póquer es una variación del
método Delphi.
• Es simple, se burla y los resultados de estim
• Planificación de póquer se utiliza para estimar el
esfuerzo o el tamaño relativo de las tareas en el
desarrollo de software de manera fiable.
• Los miembros del equipo del proyecto se reúnen
y en unas pocas rondas mediante el Poker Game
llegan a un consenso sobre el tamaño de cada
tema o tarea.
92. jorge.abad@gmail.com
La baraja de Cartas
• Cada juevo de cartas incluye los
números 0, (0,5), 1, 2, 3, 5, 8, 13,
20, 40, 100, y, a veces, un café
tarjeta.
• Cada miembro del equipo
necesita una baraja de cartas
93. jorge.abad@gmail.com
La reunión de
planificación (1)
• Al comienzo de la planificación de póquer,
cada estimador se le da un mazo de cartas.
• Para cada Historia de Usuario o tema que se
va a estimar, un moderador lee la
descripción.
• El moderador suele ser el propietario del
producto o una analista. Sin embargo, el
moderador puede ser cualquier persona, ya
que no hay privilegio especial asociado con
el papel.
94. jorge.abad@gmail.com
La reunión de
planificación (2)
• El Dueño del producto (Product Owner) responde todas
las preguntas que tienen los estimadores.
• Después de todas las preguntas cada estimador
selecciona una carta de forma secreta e individual.
• Las tarjetas no se muestran hasta que todos hayan
hecho su estimación. Luego todos muestran al mismo
tiempo la carta elegida
• El grupo puede discutir la historia y sus estimaciones
durante unos minutos más. Principalmente se indaga a
las personas que están lejanas de la media que explique
su posición.
• Tras el debate se hace otra ronda de estimacion en
privado.
95. jorge.abad@gmail.com
La reunión de
planificación (3)
• Valores altos de tiempo implican
o Baja granularidad
o Alta complejidad
o se recomienda en lo posible dividir en tareas más pequeñas.
• Si sale (?) Implica que no se tiene idea de que se
esta hablando
• Si sale la taza de café, indica que la persona esta
casada.
96. jorge.abad@gmail.com
Resultados
• En muchos casos, las estimaciones convergen en
la segunda ronda. En caso contrario se debe
repetir el proceso.
• El objetivo es converger a una única estimación.
98. jorge.abad@gmail.com
Historias de Usuario
• Una historia de usuario es una representación de un
requerimiento de software escrito en una o dos
frases utilizando el lenguaje común del usuario. Las
historias de usuario son utilizadas en las
metodologías de desarrollo ágiles para la
especificación de requerimientos (acompañadas
de las discusiones con los usuarios y las pruebas de
validación). Cada historia de usuario debe ser
limitada, esta debería poderse escribir sobre una
nota adhesiva pequeña. Dentro de la metodología
XP las historias de usuario deben ser escritas por los
clientes.
99. jorge.abad@gmail.com
Historias de Usuario
• Las historias de usuario son una forma rápida de
administrar los requerimientos de los usuarios sin
tener que elaborar gran cantidad de documentos
formales y sin requerir de mucho tiempo para
administrarlos. Las historias de usuario permiten
responder rápidamente a los requerimientos
cambiantes.
100. jorge.abad@gmail.com
Características
• Independientes unas de otras: De ser necesario, combinar las historias
dependientes o buscar otra forma de dividir las historias de manera que resulten
independientes.
• Negociables: La historia en si misma no lo suficientemente explícita como para
considerarse un contrato, la discusión con los usuarios debe permitir esclarecer su
alcance y éste debe dejarse explícito bajo la forma de pruebas de validación.
• Valoradas por los clientes o usuarios: Los intereses de los clientes y de los usuarios
no siempre coinciden, pero en todo caso, cada historia debe ser importante para
alguno de ellos más que para el desarrollador.
• Estimables: Un resultado de la discusión de una historia de usuario es la estimación
del tiempo que tomará completarla. Esto permite estimar el tiempo total del
proyecto.
• Pequeñas: Las historias muy largas son difíciles de estimar e imponen restricciones
sobre la planificación de un desarrollo iterativo. Generalmente se recomienda la
consolidación de historias muy cortas en una sola historia.
• Verificables: Las historias de usuario cubren requerimientos funcionales, por lo que
generalmente son verificables. Cuando sea posible, la verificación debe
automatizarse, de manera que pueda ser verificada en cada entrega del
proyecto.
101. jorge.abad@gmail.com
Características
• Si bien el estilo puede ser libre, la historia de usuario
debe responder a tres preguntas: ¿Quién se
beneficia?, ¿qué se quiere? y ¿cuál es el beneficio?
Por ello, algunos autores[1] recomiendan redactar
las historias de usuario según el formato:
• Como (rol) quiero (algo) para poder (beneficio).
• Adicionalmente se debe plasmar los CRITERIOS DE
ACEPTACIÓN.
102. jorge.abad@gmail.com
Beneficios
• Al ser muy corta esta representa requisitos del
modelo de negocio que pueden implementarse
rápidamente (días o semanas)
• Necesitan poco mantenimiento
• Mantienen una relación cercana con el cliente
• Permite dividir los proyectos en pequeñas entregas
• Permite estimar fácilmente el esfuerzo de desarrollo
• Es ideal para proyectos con requerimientos volátiles
o no muy claros
103. jorge.abad@gmail.com
Limitaciones
• Sin pruebas de validación pueden quedar abiertas a
distintas interpretaciones haciendo difícil utilizarlas como
base para un contrato
• Se requiere un contacto permanente con el cliente
durante el proyecto lo cual puede ser difícil o costoso
• Podría resultar difícil escalar a proyectos grandes
• Requiere desarrolladores muy competentes
• Sin pruebas de validación pueden quedar abiertas a
distintas interpretaciones haciendo difícil utilizarlas como
base para un contrato
• Se requiere un contacto permanente con el cliente
durante el proyecto lo cual puede ser difícil o costoso
• Podría resultar difícil escalar a proyectos grandes
• Requiere desarrolladores muy competentes
104. jorge.abad@gmail.com
Un enfoque BDD (Behavior
Driven Development)
• Title (one line describing the story)
•
• Narrative:
• As a [role]
• I want [feature]
• So that [benefit]
•
• Acceptance Criteria: (presented as Scenarios)
•
• Scenario 1: Title
• Given [context]
• And [some more context]...
• When [event]
• Then [outcome]
• And [another outcome]...
•
• Scenario 2: ...
09/08/2014 104
Fuente: http://dannorth.net/whats-in-a-story/
105. jorge.abad@gmail.com
Ejemplo
BDD
• Scenario 1: Account has sufficient funds
• Given the account balance is $100
• And the card is valid
• And the machine contains enough money
• When the Account Holder requests $20
• Then the ATM should dispense $20
• And the account balance should be $80
• And the card should be returned
09/08/2014 105
• Scenario 2: Account has insufficient funds
• Given the account balance is $10
• And the card is valid
• And the machine contains enough money
• When the Account Holder requests $20
• Then the ATM should not dispense any money
• And the ATM should say there are insufficient funds
• And the account balance should be $20
• And the card should be returned
Story: Account Holder withdraws cash
As an Account Holder
I want to withdraw cash from an ATM
So that I can get money when the bank is
closed
• Scenario 3: Card has been disabled
• Given the card is disabled
• When the Account Holder requests $20
• Then the ATM should retain the card
• And the ATM should say the card has been retained
Fuente: http://dannorth.net/whats-in-a-story/
106.
107.
108.
109. jorge.abad@gmail.com
Aviso de Copyright
• Usted es libre de:
o Compartir- copiar, distribuir y trasmitir el trabajo
o Modificar- adaptar el trabajo
• Bajo las siguientes condiciones
o Atribución. Ud. debe atribuir el trabajo en la manera
especificada por el autor o licenciante (pero de ninguna
manera que sugiera que ellos aprueban su uso del trabajo).
• Nada de lo dispuesto en esta licencia
menoscaba o restringe los derechos
morales del autor.
• Para más información ver
http://creativecommons.org/licenses/by/3.0/
111. jorge.abad@gmail.com
Tomado de:
• Una introducción a Scrum - Ernesto Grafeuille.
• Enriquecido y Modificado por: Jorge H. Abad L. –
jorge.abad@gmail.com
o Blogs:
• http://lecciones-aprendidas.blogspot.com/
• http://ing-sw.blogspot.com/