April 6, 2011 Escribiendo Historias de Usuario Kane Mar, 7 de setiembre, 2006 Traducido por Víctor Bustamante.

Slides:



Advertisements
Presentaciones similares
Como crear y usar una rúbrica
Advertisements

IDENTIFICAR NECESIDADES, PROBLEMAS U OPORTUNIDADES
Gestión de requerimientos
Pruebas de Diseño Diplomado en Calidad en el Software NOTAS
Pruebas de Requerimientos
Ingeniería de Software
Selección y Evaluación de Proveedores
DIRECTRICES PARA EL PERFIL DE LA EVALUACIÓN INFANTIL
Herramientas Automáticas de Estimación
Aprendizaje de Microsoft® Access® 2010
GRUPO 8 WEB Designers. I ntegrantes Equipo Natalia Almodóvar Arlene Acosta Irvin de la Paz Yamiretsy Pagan Ovidmary Bayron Barón Zapata Patrocinador:
IEEE-std Práctica Recomendada para la Especificación de Requerimientos de Software Fuente: IEEE Recommendad Practice for Software Requirements.
Modelo de Desarrollo XP
Aspectos Avanzados de la Tecnología de Objetos
ANÁLISIS Y DISEÑO DESDE UNA PERSPECTIVA ORIENTADA A OBJETOS Alan Vargas.
Ingeniería de Software Orientada a Objetos
Lineamientos de Pruebas Integrales del GRP Financiero
Determinar a que se le va a hacer Benchmarking
TIPOS DE DISEÑO EN LA PRUEBA DE MECs CON ESTUDIANTES La prueba de un MEC puede hacerse de varias maneras, dependiendo de lo que se desea establecer y el.
Gestión del Tiempo del Proyecto
DISEÑO DE SOFTWARE 1ª. Parte
Fundamentos de Ingeniería de Software Facultad de Ingenieria Universidad Distrital Francisco José de Caldas ESPECIFICACIÓN Y MANEJO DE LOS REQUERIMIENTOS.
Gestión de Proyectos Informáticos Sesión N° 5 Ciclo de Vida de un Proyecto Roberto Jijena I.
Problems, solutions and programs
Ingreso y asignación de cursos en SRC Registro y Control de Personal Contratado Septiembre 2011.
INGENIERIA DE SOFTWARE
Selección/Adquisición de Sistemas Computacionales ¿ Qué son los requerimientos? Una condición o capacidad necesaria para resolver un problema o alcanzar.
Metodología para solución de problemas
Preparación del equipo: Preguntas que los Entrenadores deben hacer antes de empezar un proceso de Estándares Abiertos ¿Están las capacidades mínimas listas.
CASOS DE USO Ing. Sonia Godoy H..
Análisis de Requerimientos
Ingeniería de Software
SICSTRA Sistema de Información para el control de solicitudes de tramites jurídicos Ministerio de Justicia y Seguridad Pública.
Estableciendo los objetivos preliminares SMART
Extreme Programming Diego Rincón Sebastian Miranda.
COSAS CON LAS QUE TRABAJAMOS: LOS ALFAS
Poker Planning Juan Carlos Olivares Rojas MSN:
Clase 3 complementaria Tecnología de la Comunicación I Estrategias de búsqueda.
INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE
Universidad Metropolitana Introducción a la Computación
Christian Monrreal Gonzalez Daryl Silverman Aguilar Gone
Comercio Electrónico Parte 5 “E-Service” - Medición y Control - Nuestras medidas en la mente del consumidor… - 10 formas de obtener información sobre las.
El rol de SQA en PIS.
UNIVERSIDAD DE CARTAGO SEDE DE PANAMÁ POSTGRADO EN GERENCIAS DE SERVICIOS DE SALUD COMUNICACIÓN GLOBAL PRESENTADO POR: ANNA GABRIELA NÚÑEZ SAMUEL.
Diseño de Sistemas.
Laboratorio Informática II
Gestión Ágil de Proyectos Colaborador: Anónimo
Ingeniería de Requerimientos
Introducción al proceso de verificación y validación.
Administración Integral del Proyecto
Estimación de proyectos de software
Microsoft Office Project INTRODUCCIÓN A LA GESTIÓN DE PROYECTOS Microsoft Office Project 2010.
Proceso de Diseño de Interfaces
Estructurar tus ideas para hacerlas realidad
UNIDAD 2: “Características del Modelado UML” CONTENDIDO Elaborado por: Ingeniero Harold Cabrera Meza Actualizado por: Ingeniero Nilson Albeiro Ferreira.
Determinación de Requerimientos
AceSchool Daniel Labra Fernando Figueroa ¿Qué Hicimos? -Refinar Causa-Efecto -Elección Metodología -Esquema de la Solución -Resultado Encuesta -Refinar.
Taller de desarrollo de proyectos II Presentación Inicial.
Un requerimiento es una condición o capacidad a la que el sistema (siendo construido) debe conformar [ Rational ]. Un requerimiento de software puede.
MODELOS CONDUCTUALES.
Actividad 12. Estimación en los proyectos de software. M.C. Juan Carlos Olivares Rojas Syllabus May, 2009.
REUNION INICIAL DE PROYECTO DE SOFTWARE Nombre del Proyecto: SISTEMA DE CONTROL UNIVERSITARIO Tipo de Proyecto: DESARROLLO DE SOFTWARE A LA MEDIDA 7 de.
Especificación del Problema Partimos del hecho de un programador no puede resolver un problema que no entiende. Por esta razón, la primera etapa en todo.
Identificación de entradas, salidas y herramientas de procesos de gestión del PMI Jairo A. Orozco L.
Autor: Reinozo Cuesta Christian Marcelo
Procesos de Planeación
Es una metodología ágil diseñada para el desarrollo de software, basada en la calidad y el monitoreo constante del proyecto. Consiste esencialmente en.
GESTIÓN DE PROYECTOS.
4. Definición del proyecto. Qué tan difícil es manejar un proyecto? ◦Dependerá del tamaño del mismo ◦De los costos ◦De los plazos ◦Del nivel de dificultad.
Estado del proyecto Nombre del proyecto Nombre del Orador Lugar y fecha Esta presentación llevará probablemente a un debate con la audiencia, lo que generará.
Transcripción de la presentación:

April 6, 2011 Escribiendo Historias de Usuario Kane Mar, 7 de setiembre, 2006 Traducido por Víctor Bustamante

April 6, 2011 El problema con los usuarios… … es que ellos siempre quieren algo!!! Los requerimientos son un problema de comunicación entre los aquellos que tienen un problema y quienes pueden darle una solución.

April 6, 2011 Negociación sobre contratos “Puesto que los usuarios no saben como resolver sus problemas, tenemos que dejar de preguntarles… y en lugar de ello involucrarlos” - Mike Cohn

April 6, 2011 Agenda Escribiendo historias de usuario Descomponiendo Epics Escribiendo criterios de aceptación

April 6, 2011 Qué es una historia de usuario? “La promesa para una conversación futura” - Ron Jeffries

April 6, 2011 What is a Story not? Las historias no son: –“mini” Use Cases –Una especificación completa –Un contrato –Destinadas a ser interpretadas sin un Product Owner

April 6, 2011 Plantilla para Historias de Usuario. “Como un quiero de modo que ” Ejemplo: Como Tesorero, quiero ser capaz de retirar fondos de mi cuenta corriente, de modo que pueda realizar la compra de materiales.

April 6, 2011 ¿Qué es un Epic? Son por lo general historias compuestas, que pueden dividirse en historias mas pequeñas y centradas. Pueden involucrar algunos Sprints de trabajo (iteraciones)

April 6, 2011 Algunas guías para escribir buenas historias de usuario Testable. Pruebas de aceptación tangibles pueden ser escritas contra cualquier entrega de software. El alcance de la historia de usuario es lo suficientemente manejable para que el equipo pueda proporcionar una estimado Independientes y no depender de otras historias. De tamaño apropiado. Significar un nivel de esfuerzo de modo que el equipo la pueda terminar cómodamente en la duración de una sola iteración.

April 6, 2011 Agenda Escribiendo historias de usuario Descomponiendo Epics Escribiendo criterios de aceptación

April 6, 2011 Algunos sitios donde considerar dividir Epics En los limites de CRUD En los limites de un sistema donde 2 sistemas necesitan una interfaz En los limites de Happy-Path / Exception-Path

April 6, 2011 En los límites de CRUD: Esta solución se utiliza comúnmente en entornos que interactúen con una base de datos Ejemplo: Como tesorero, quiero abrir una cuenta corriente… Como tesorero, quiero depositar un cheque en mi cuenta corriente… Como tesorero, quiero visualizar el balance actualizado en mi cuenta corriente…

April 6, 2011 En los limites del sistema: Se Utiliza donde hay un gran número de sistemas legados Puede ser utilizada: –Cuando hay una separación clara entre 2 sistemas –Donde la interfaz entre los 2 sistemas esta bien entendida Una advertencia: tenga cuidado de crear dependencias entre 2 proyectos diferentes

April 6, 2011 En los límites de Happy-Path / Exception-Path: Utilizado cuando estamos haciendo la transición desde casos de uso El escenario happy-path puede necesitar descomposición. Descomponer casos de uso puede significar mucho trabajo… es mejor comenzar utilizando historias de usuario

April 6, 2011 Agenda Escrinbiendo historias de usuario Descomponiendo Epics Escribiendo criterios de aceptación

April 6, 2011 ¿Qué es un criterio de aceptación? Son las expectativas del propietario de producto sobre las cuales será entregado el producto Los criterios de aceptación incluyen: –Funcionalidad que el sistema debe realizar –El look and feel de la interfaz –La documentación necesaria (ejemplo documentación de cumplimiento de SOX)

April 6, 2011 Algunas guías para escribir buenos criterios de aceptación Sea explicito –“El sistema mostrará la fecha.” … –¿En qué formato? Es “2006, Abril 1 st” aceptable? Proveer ejemplo para clarificar –“La fecha del sistema será mostrada en el formato 13/4/06” Listar cualquier suposición que el equipo puede no tener presente

April 6, 2011 Algunas guías para escribir buenos criterios de aceptación Incluya lo que espera que el sistema haga … –“El balance de la cuenta será actualizado con la cantidad ingresada por el usuario.” … y donde haya ambigüedad, lo que se espera que el sistema no haga –“No se espera en este momento que se realice la conciliación con la cantidad de fondos depositados.”

April 6, 2011 Referencias “Users Stories Applied”, Mike Cohen “Agile Estimating and Planning”, Mike Cohen