Professional Documents
Culture Documents
Fuente Wikipedia
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.
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.
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.
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:
La ficha adjunta incluye una descripción sinóptica del proceso y sus elementos que
son:
◦ Roles: Propietario del producto, Gestor o Manager del Scrum, Equipo e Interesados.
◦ Componentes del proceso: Pila del producto (Product Backlog), Pila del sprint (Sprint Backlog),
Incremento.
◦ Reuniones:
Planificación del sprint, Revisión diaria, Revisión del sprint.
◦ Sprint
Orígenes de Scrum
Jeff Sutherland
◦ Scrums iniciales en Easel Corp en 1993
◦ IDX 500 personas haciendo Scrum
Ken Schwaber
◦ ADM
◦ Se presenta Scrum en OOPSLA 96 con Sutherland
◦ Autor de tres libros sobre Scrum
Mike Beedle
◦ Patrones Scrum en PLOPD4
Ken Schwaber and Mike Cohn
◦ Fundaron conjuntamente la Scrum Alliance en 2002,
inicialmente dentro de la Agile Alliance
Scrum ha sido utilizado por:
por :
•Microsoft •Intuit
•Yahoo •Nielsen Media
•Google •First American Real Estate
•Electronic Arts •BMC Software
•High Moon Studios •Ipswitch
•Lockheed Martin •John Deere
•Philips •Lexis Nexis
•Siemens •Sabre
•Nokia •Salesforce.com
•Capital One •Time Warner
•BBC •Turner Broadcasting
•Intuit •Oce
Scrum ha sido utilizado para:
para:
Software comercial • Desarrollo de video juegos
Desarrollos internos • Sistemas críticos de soporte
vital, aprobados por laFDA
Desarrollos bajo Contrato
Proyectos Fixed-price
• Software de control satelital
Aplicaciones Financieras
• Sitios Web
Aplicaciones certificadas ISO
• Software para Handheld
9001 • Teléfonos portátiles
Sistemas Embebidos • Aplicaciones de Network
switching
Sistemas con requisitos 7x24
y 99.999% de disponibilidad • Aplicaciones de ISV
Joint Strike Fighter • Algunas de las más grandes
aplicaciones en uso
Características
Es una de las metodologías ágiles
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”
Nivel de ruido de un proyecto
Lejos de
Acuerdo
Anarquía
Requisitos
Complejo
Acuerdo
Cerca de
Certeza
Lejos de
Certeza
Tecnología
Scrum 24 horas
Sprint
2-4 semanas
Objetivo del Sprint
Sprint
Incremento del producto
Return Backlog
potencialmente entregable
Gift wrap
Cancel
Product
Backlog
Poniendo todo junto
Imagen disponible en
www.mountaingoatsoftware.com/scrum
Sprints
En Scrum los proyectos avanzan en una serie
de “Sprints”
◦ Análogo a las iteraciones en XP
La duración típica es 2–4 semanas o alo
sumo un mes calendario
La duración constante conduce a un mejor
ritmo
El product es diseñado, codificado y testeado
durante el Sprint
Desarrollo secuencial vs.
superpuesto
2
¿Qué vas a hacer hoy?
3
¿Hay obstáculos en tu camino?
No es dar un status report al Scrum Master
Se trata de compromisos delante de pares
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
Sprint retrospective
Periódicamente, se echa un vistazo a lo que
funciona y lo que no
Normalmente 15 a 30 minutos
Se realiza luego de cada sprint
Todo el equipo participa
◦ ScrumMaster
◦ Product owner
◦ Equipo
◦ Posiblemente clientes y otros
Start / Stop / Continue
Todo el equipo se reúne y discute lo que les
gustaría:
Comenzar a hacer
Dejar de hacer
Esto es sólo una
de las muchas
maneras de Continuar haciendo
hacer una
retrospectiva.
Scrum framework
Roles
•Product owner
•ScrumMaster
•Team Reuniones
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artefactos
•Product backlog
•Sprint backlog
•Burndown charts
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
Este es el
product backlog
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
3
una reserva.
Como un empleado de hotel, puedo ejecutar
informes de los ingresos por habitación 8
disponible
Mejorar el manejo de excepciones 8
... 30
... 50
Ejemplo de Product Backlog
El objetivo del Sprint
Una breve declaración de cual será el foco del
trabajo durante el sprint
Ciencias Biológicas
Funciones de apoyo técnico
necesarios para estudios de
Aplicación con B.Datos
genética de poblaciones.
Hacer que la aplicación se
ejecute en SQL Server, además
de Oracle. Servicios Financieros
50
40
30
Hours
20
10
0
Mon Tue Wed Thu Fri
Escalabilidad
Normalmente los equipos son de 7 ± 2
personas
◦ La escalabilidad proviene de equipos de equipos
Factores a tener cuenta
◦ Tipo de aplicación
◦ Tamaño del equipo
◦ Dispersión del equipo
◦ Duración del proyecto
Scrum se ha utilizado en múltiples proyectos de
más de 500 personas
Expansión a través de Scrum de
scrums
Scrum de scrums de scrums
Scrum of Scrums / Meta-
Meta-Scrum
Scrum
EL JUEGO DE LA
ESTIMACIÓN
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.
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
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.
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.
La reunión de planificación (3)
Valores altos de tiempo implican
◦ Baja granularidad
◦ Alta complejidad
◦ 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.
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.
Donde seguir?
www.mountaingoatsoftware.com/scrum
www.scrumalliance.org
www.controlchaos.com
scrumdevelopment@yahoogroups.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
Aviso de Copyright
Usted es libre de:
◦ Compartir- copiar, distribuir y trasmitir el trabajo
◦ Modificar- adaptar el trabajo