Roles
Product Owner
Es la voz del consumidor del
producto.
Define requerimientos.
Prioriza.
/* Puede haber varios
involucrados relevantes en un
proyecto ágil pero solo uno es el
Product Owner*/
Scrum Master
Enfoque en la productividad del
equipo. (Desarrolladores +
Product Owner)
Asegura transparencia de
información para asegurar que
se entregue valor.
Apoya en la eliminación de
obstáculos.
Custodia los principios de Scrum
y guía sobre su cumplimiento.
Scrum Developers
Estiman el trabajo a realizar.
Crean los entregables ya que
cuentan con las habilidades &
experiencia para convertir los
requerimientos en
entregables.
Estos NO son los únicos roles
de un proyecto ágil, son los
roles de la célula Scrum y
conviven con los otros roles
naturales del desarrollo: DBAs,
Testers, Analistas,
Infraestructura, etc.
Conceptos
Product Backlog
Es una lista que recoge todos los
requerimientos que necesita el
producto para satisfacer las
necesidades de los consumidores.
Sprint Backlog
Es un subconjunto de elementos del
Product Backlog seleccionados
a abordar en el Sprint.
Increment
Se trata del resultado del Sprint, de
su entregable. Un entregable
“Terminado”, utilizable y
potencialmente desplegable.
User Story
Son descripciones cortas y simples
de una funcionalidad, escritas desde
la perspectiva del usuario: Como X
quiero hacer Y con el objetivo de Z
con las condiciones abcdef
Story Point
Un Story Point es una medida que
engloba: complejidad (esencial y
accidental), tamaño, incertidumbre
y habilidad/conocimiento sobre el
requerimiento planteado.
Burndown Charts
Un gráfico de trabajo pendiente a
lo largo del tiempo muestra la
velocidad a la que se está
completando los
objetivos/requisitos.
Ceremonias Proceso
Sprint Planning Etapa Comercial.
Se trabaja con la lista de elaboración del Anteproyecto
requerimientos ya priorizados.
Business Case & épicas
Se seleccionan los requermientos
a completar. Preparación:
Se realiza estimación conjunta. Sprint 0
Historias de usuario base,
El equipo se autoasigna el trabajo. Identificación de requerimientos
técnicos críticos y dependencias
Scrum Daily Meeting con otros equipos/procesos
Reunión diaria de máximo 15
minutos. Durante el Sprint, Sprint planning
De pie. mientras los Scrum
Developers
Cada miembro del equipo dice:
desarrollan, el
-Lo que hizo ayer Scrum Daily
-Lo qué va a hacer hoy Product Owner y el
Scrum Master van Meeting
Sprint
-Impedimentos
refinando las
Sprint Review historias de usuario
Desarrollo &
Demo del Sprint con duración de 2 a 4 o creando más para
estar listos para el Pruebas
horas.
Participa la célula completa Scrum Sprint Planning del
Siguiente Sprint.
(Product Owner, Scrum Master, Scrum
Developers) También se pueden
ir avanzando en Sprint Review
El Scrum Master modeara la sesión.
Cada Scrum Developer muestra su actividades de (Demo)
avance. coordinación
Retrospective necesarias para el
Reunión de análisis de lo sucedido Sprint Release
Aún no
durante el Sprint con duración de 1 a 2
Se realizan tareas para poner
horas.
el software en producción.
El Scrum Master modera y participa la ¿Subimos a
célula Scrum y se habla de: Ejemplos: generación de
SI producción?
-Lo que se hizo bien scripts de recuperación,
-Lo que no se hizo bien gestión con equipo de
-Lo que se debe de hacer más infraestructura, tareas Sprint
-Lo que se debe de hacer menos relacionadas a bases de
datos productivas, pruebas de Release
-Lo que se debe de dejar de hacer
-Lo que se debe comenzar a hacer estrés, etc.
Business Analysis
El Análisis de negocio es el
conjunto de tareas y técnicas
utilizadas para trabajar como
enlace entre los stakeholders
con el fin de entender la
estructura, políticas, y En la reunión se acuñó el término “Métodos Ágiles” para definir a los
operaciones de una
organización, y para
recomendar soluciones que
permitan a la organización
alcanzar sus metas.
Implica entender cómo las
organizaciones funcionan para
alcanzar sus metas y definir
las capacidades que una
organización requiere para
proporcionar los productos y
servicios a los stakeholders
externos.
Los analistas de negocio
deben analizar y sintetizar la
información proporcionada por
un gran número de personas
que interactúan con la
empresa, tales como clientes,
empleados, profesionales de TI
y ejecutivos. a menudo
desempeñan un papel central
en la adaptación de las
necesidades de las unidades
de negocio con las
capacidades que ofrece la
tecnología de información, y
pueden servir como un
“traductor” entre esos grupos.
Scrum
Scrum nace de un estudio en 1986 sobre los
nuevos procesos de desarrollo utilizados en
productos exitosos en Japón y los Estados
Unidos que estaban realizados por equipos de
desarrollo que partían de requerimientos muy
generales e innovadores y tenían que salir al
mercado en un tiempo mucho menor que el
usado en proyectos anteriores.
En 1993 se realizó el primer Scrum para
desarrollo de software y se formalizó en 1995.
Basado en las entregas parciales y regulares
del producto final, cuyos requerimientos se
priorizan por el beneficio que aportan al
cliente. Recomendado para proyectos en
entornos complejos donde se requieren ver
resultados de manera temprana y cuyos
requerimientos son cambiantes o están
pobremente definidos.
Sus principios son:
Equipos auto-organizados
Flexibilidad ante el cambio
Entregables con valor para el cliente
Diálogo y comunicación
Trabajo iterativo
Delimitación de roles
Identificación de riesgos de manera
tempran y constante
El nombre de Scrum se tomó de una jugada
de Rugby, la cual es un medio de reiniciar el
juego en el Rugby después de una detención
causada por una infracción menor y sirve para
concentrar a todos los forwards y a los medio
en un lugar del campo de juego brindando la
oportunidad para que los backs armen un
ataque.
Manifiesto
El 17 de febrero de 2001, 17 críticos de los modelos de mejora del
desarrollo de software basados en procesos, se reunieron para tratar
sobre técnicas y procesos para desarrollar software.
métodos que estaban surgiendo como alternativa a las metodologías
formales a las que consideraban excesivamente “pesadas” y rígidas por
su carácter normativo y fuerte dependencia de planificaciones detalladas
previas al desarrollo.
Los integrantes de la reunión resumieron los principios sobre los que se
basan los métodos alternativos en cuatro postulados, lo que ha quedado
denominado como Manifiesto Ágil.
Manifiesto por el Desarrollo Ágil de Software
Estamos descubriendo formas mejores de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros. A través de este trabajo hemos
aprendido a valorar:
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha,
valoramos más los de la izquierda.
Aclaración: Los agilistas SI contamos con procesos y herramientas, solo que nos
enfocamos más a los individuos y como interactuamos. Claro que hacemos
documentación, pero aquella que genere valor y apoye para la generación de un buen
software, NO documentación por trámite, no justificamos avances con documentación
sino con software funcionando en entregas frecuentes. Si tenemos contratos pero lo
más importante es genera una relación de confianza donde el cliente sea colaborador.
Si tenemos planes, pero no exhaustivos, no en Gantts y no inflexibles.
 Guión de una entrevista efectiva:
¿Qué necesitas? Título
15 de junio 2017
Dimensionamiento funcional

Requerimiento de negocio
¿Cómo lo necesitas? ¿Para qué lo
necesitas? Requerimiento de negocio

Otras técnicas para levantamiento de Requerimiento de negocio

requerimientos

Encuestas

Focus Groups Agrupados/ Reqs Reqs

Observación
categorizados Reqs usuario

Investigación usuario usuario

Característica de una Historia de Usuario Conversación


Independiente 1) Hechos

Reqs funcionales
Reqs funcionales
Reqs funcionales

Reqs funcionales
Reqs funcionales

Reqs funcionales
Reqs funcionales
Reqs funcionales
Reqs funcionales
Reqs funcionales
Reqs funcionales

Valiosa 2) Exploración

Estimable 3) Opciones

Que se pueda probar 4) Decisión
TIPS PARA NEGOCIAR
• Menciona (recuerda) los objetivos estratégicos del área o del
proyecto o del negocio o del cliente.
• Preguntar: ¿Por qué es tan importante? ¿Cuáles son las
opciones?¿Qué recomienda?
• Saber “decir NO” ofreciendo alternativas.
– Preguntar: ¿Qué sucede si _______? Reqs
• “Siendo así, redireccionemos juntos la estrategia” técnicos
• “Yo me comprometo a _________ si tú te comprometes
a__________”
• “Te pido tu ayuda para ______________” Reqs de
• “Quiero escucharte, dime lo que piensas” transición
• “¿Qué te preocupa?”
• Lo puedo hacer mañana y le garantizo que…..”
• “Si hago eso entonces sucedería _________”
 Talleres de requerimientos / Mesas de Trabajo
• Priorización a 3 columnas
• Compra de requerimientos
• Matriz de criterios por historia User Journey: Diagrama que muestra los pasos
extremo a extremo que sigue tu cliente al relacionarse
con el software que desarrollarás para él.
Criterios de decisión
• Alineado a Objetivos estratégicos (Requerimientos de negocio)
• Orden de importancia (Escalas de requerimientos)
• Hechos o creencias (¿Hay indicadores del problema que se va a
solucionar?)
• Impacto por ausencia

Complementos:
User story Mapping: Representar al Product Backlog en
más de una perspectiva.
Visión concentrada del proyecto que permita dimensionar y
tomar decisiones.

Backbone

Iteraciones / Versiones
Dimensionamiento funcional
/ Alcance /
User story mapping