RESUMEN ENFOQUE LEAN ÁGIL

INTRODUCCIÓN
Antes que nada, vamos a responder la siguiente pregunta: ¿Qué es una metodología?

Una metodología es la ciencia que estudia los métodos. Gestionar un producto ≠

Gestionar un proyecto.

¿Y que es gestión de producto? – por ejemplo, cuando hacemos un CU, DDS

aplicar un enfoque/framework no significa sacar un producto de calidad

PPA1 - SOFTWARE
Software: set de programas de computación que corre sobre una plataforma de
hardware y documentación que lo acompaña. Existen 3 tipos básicos de software:

●​ System software: conjunto de programas que sirven para interactuar con el

sistema
●​ Utilitarios: programas que son diseñados para realizar las actividades
específicas para las que fueron diseñados
●​ Software de aplicación: software de alto nivel, ayuda a personas u
organizaciones con un objetivo

Un software es mas que codigo o un programa que corre sobre una plataforma, hay
informacion alrededor del mismo que tiene que ser gestionada y también forma parte
de el, es decir que toda la info y conocimiento que se genera al crearlo es también
parte del sistema. Para lograr un producto de software de calidad tenemos que tener
una visión amplia del mismo ósea que debemos entenderlo

PODEMOS ENCONTRAR SOFTWARE EN TODOS LADOS, POR ESO ES

IMPORTNANTE HACERLO DE LA MEJOR CALIDAD POSIBLE

¿Por qué no se compara desarrollo de software con manufactura?

●​ El software es menos predecible
●​ No hay producción en masa
●​ No todas las fallas son errores
●​ El software no se gasta
●​ El software o esta gobernado por las leyes de la fisica

Los enfoques agiles nos permiten lograr un producto de calidad teniendo en cuenta
todas estas complejidades.

Algunos problemas con el desarrollo de software

●​ La versión final del producto no satisface las necesidades del cliente
●​ No es fácil extenderlo y/o adaptarlo
●​ Mala documentación
●​ Mala calidad
●​ Mas tiempos y costos que los presupuestados

Cuando nos va bien Cuando nos va mal

 Involucramiento del usuario Requerimientos incompletos
Apoyo de la gerencia Falta de involucramiento del usuario
Enunciado claro de los requerimientos Falta de recursos
Planeamiento adecuado Expectativas poco realistas
Expectativas realistas Falta de apoyo de gerencia
Hitos intermedios Requerimientos cambiantes
Personas involucradas competentes

El problema está cuando aceptamos un trabajo con un bajo presupuesto prometiendo una cosa
y entregamos otro peor acorde a ese presupuesto. Intentar nivelar lo que el cliente se imagina
y lo que obtiene al final del proceso.
Saber programar NO es suficiente: aunque haya que saber programar software de
calidad no solo alcanza con eso

ingeniería de software: es la aplicación de un enfoque sistemático, diciplinado y

cuantificable al desarrollo, operación y mantenimiento del software

❖​ Principales diciplinas:

Ing. en software vs Ing. en sistemas: la ingeniería de software esta comprendida

dentro de la de sistemas, sistemas es mucho más amplio
 PPA2 - PROYECTOS
Proceso: secuencia de pasos dispuesto con algún tipo de logica que se enfoca en
lograr algún resultado especifico. En el contexto del desarrollo de software hablamos
de un conjunto de personas, estructuras de organización, reglas, políticas, actividades
y sus procedimientos. Los procesos se usan para obtener un producto/servicio.

Pueden ser:

●​ Definidos: esta todo bien estipulado, orden de fases, que entra y que sale,
puedo estimar resultados. Tienen marcadas para cada una de las etapas que lo
integran los roles, intervienen artefactos que se generan. Se espera lograr
cierta responsabilidad ahí es donde difiere con los otros procesos. EJ: PUD
●​ Empíricos: Se basan en la experiencia. ¿pero de quién? Asumo una situación,
rápidamente construyo algo para mostrar y con eso obtengo realimentación del
cliente y saber si voy bien, que cambiar y empiezo el ciclo otra vez. Se va
ganando experiencia como equipo, deben generar su propia experiencia. Lo
que me paso antes no es una garantía de lo que va a suceder en el próximo
proyecto.

Proyecto: esfuerzo temporal que se lleva a cabo para crear un producto,

servicio o resultado único.
Ciclo de vida del proyecto y del producto: el ciclo de vida del proyecto es la
forma de ir estructurando las actividades que pasa un proyecto. Por otro lado El
producto (software) tiene también un ciclo de vida, pero con otras etapas distintas. El
ciclo de vida de un producto es más grande que el ciclo de vida del proyecto. El ciclo se
repite hasta que se saca de uso el software.
AGIL: No es una metodología o proceso es una ideología con un conjunto definido de principios que
guían el desarrollo del producto, de todos modos, el hecho de usar ágil no nos garantiza que
sepamos hacer un producto. Los agilitas dicen que hacen esto y no hacemos esto otro, siempre se
estan comparando, trata de equilibrar lo que antes no se hacía, trata de poner procesos SOLO
donde hace falta, no en todos lados
¿Qué significa AGIL entonces?

●​ Balance entre ningún proceso y demasiado proceso. La diferencia inmediata es

la exigencia de una menor cantidad de documentación, sin embargo, no es eso
lo más importante.
●​ Los métodos ágiles son adaptables en lugar de predictivos.
●​ Los métodos ágiles son orientados a la gente en lugar de orientados al proceso
Administración de proyectos: La disciplina que administra los recursos e integra
las mejores personas posibles para lograr el resultado es la disciplina de
administración de proyectos. Tiene un momento de planificación y uno de seguimiento
y control. Hay que planificar con frecuencia, no todo sale como queremos. La realidad
es compleja y cambiante, es difícil anticiparte. La forma de gestionar un proyecto está
directamente relacionada con el tipo de proyecto que vamos a hacer.
administración de proyectos es la aplicación de conocimientos, habilidades,
herramientas y técnicas a las actividades del proyecto para satisfacer los
requerimientos del proyecto

La restricción triple:
●​ Objetivos de proyecto: ¿que está el proyecto tratando de alcanzar?
●​ Tiempo: ¿cuánto tiempo debería llevar completarlo?
●​ Costos: ¿cuánto debería costar?
Es responsabilidad del Líder de proyecto balancear estos tres objetivos

Cuando no se tiene control de ninguna de las 3 sale software de mala calidad. Tenes
que tener algo para negociar, por ejemplo, el cliente te pide un determinado tiempo
pero te libera los otros recursos. Necesitas tener control en al menos una de las
variables.

Rol del líder del proyecto:

El líder de proyecto es quien queda
con la responsabilidad de
planificación, seguimiento y control
del proyecto. El líder asume un rol de
liderazgo jerárquico, asigna el trabajo
al equipo, le dice que tiene que hacer,
cuándo y cómo. Además, se relaciona
con los demás interesados:
stakeholders, jefes, clientes,
contratistas; según lo que necesite.

En un enfoque tradicional: Asume el rol de liderazgo jerárquico. Hablamos de un

proyecto basado en procesos definidos, procesos con enfoques tradicionales. Nos va
dando todas las directivas, el líder le dice al equipo que hacer, como, cuando, quien.
Ese líder en esta gestión de proyectos tradicionales tiene una gran carga de trabajos,
en el sentido que tiene a cuestas toda la supervisión, seguimiento del proyecto,
planificar y el control de monitoreo de toda esa planificación.

En un enfoque ágil: Empieza a priorizar el equipo como autogestionado, motivado,

capacitado, que no tiene sobrecarga de trabajo, que trabaje bien. No necesita ese líder
jerárquico que le diga que es lo que tiene que hacer, por eso es autogestionado.
Desarrollan sinergia para trabajar.

Equipo del proyecto: Es un grupo de personas comprometidas en alcanzar un

conjunto de objetivos de los cuales se sienten mutuamente responsables

Características de un equipo de proyecto

●​ Diversos conocimientos y habilidades

●​ Posibilidad de trabajar juntos efectivamente / desarrollar sinergia
●​ Usualmente es un grupo pequeño
●​ Tienen sentido de responsabilidad como una unidad
Plan de proyecto: Es el resultado de la planificación del proyecto. Un plan es a un
proyecto lo que una hoja de ruta a un viaje. Planificar un proyecto de desarrollo implica
una serie de cosas. El plan de proyecto tiene la intención de trazar una ruta a seguir.
El plan de proyecto documenta:
●​ ¿Qué es lo que hacemos?
●​ ¿Cuándo lo hacemos?
●​ ¿Cómo lo hacemos?
●​ ¿Quién lo va a hacer?

¿QUE IMPLICA LA PLANIFICACIÓN DE PROYECTOS DE SOFTWARE?

●​ Definición del alcance del proyecto.

●​ Definición del proceso y ciclo de vida.
●​ Estimación.
●​ Gestión de riesgos.
●​ Asignación de recursos.
●​ Programación de proyectos.
●​ Definición de controles.
●​ Definición de métricas.

Definición de alcance:

​ Alcance del producto: son todas las caracteristicas y funciones que

caracterizan al producto, servicio o resultado
​ Alcance del proyecto: es todo el trabajo que debe hacerse para entregar
el producto o servicio con todas las características y funciones
especificas
¿Cómo se mide?

●​ El cumplimiento del Alcance del Proyecto se mide contra el Plan de Proyecto (o

Plan de Desarrollo de Software).
●​ El cumplimiento del Alcance del Producto se mide contra la Especificación de
Requerimientos

Definir un ciclo de vida: Los proyectos se dividen en fases. El conjunto de esas fases
se conoce como ciclo de vida del Proyecto. ciclo de vida define como voy a ejecutar el
proceso, que tanto de cada fase voy a hacer. Debemos elegir el ciclo de vida y adaptar
el proceso que elegimos a las características del proyecto. El PUD recomienda el ciclo
de vida iterativo e incremental, pero puede tomar el PUD y usar un ciclo de vida en
cascada.
Estimaciones de software:
Una estimación es una predicción que se hace respecto a una característica del
proyecto. La problemática de los requerimientos es compleja debido a que hay que
comunicarse con el cliente y entender que quiere, las estimaciones se basan en esos
requerimientos por lo tanto también es complejo hacerlas. Implica estimar lo siguiente
en el orden determinado:
●​ Tamaño: Tamaño del producto que se va a construir, el problema es que el
software es intangible. Tomamos los requerimientos y les damos un “peso”. Se
elige una unidad para estimar el tamaño. La primera unidad elegida eran líneas
de código, pero es muy arbitrario. Se pensó en estimar con algo más cercano a
los requerimientos ej.: en puntos de objetos, cantidad de métodos en las
clases, etc. De ahí se estima el tamaño del producto. ¿Qué voy a construir? Lo
más complejo de desarrollar software es decidir qué software se quiere hacer.
El 80% de los fracasos de software, es por problemas de requerimientos.
●​ Esfuerzo: Medidas de horas persona lineales, son horas ideales, lo que
significa que se considera el escenario feliz, sin interrupciones, sin descansar.
Cuantas horas necesita una persona para hacer una cosa, el esfuerzo es la
“bola” de horas. ¿Cuánto trabajo significa ese qué?. Se deriva del tamaño.
●​ Calendario: ¿Cuándo tendré el producto? Se sestean condiciones, cuantas
personas trabajan, cuantas horas, que dependencias hay entre las tareas. Se
ponen las horas en un calendario. La herramienta más utilizada es gamp y
Microsoft Project. Se deriva del esfuerzo.
●​ Costo: Se deja para el final porque puede cambiar, capaz se necesite horas
extra, etc. Si quiero algo rápido sale mas caro, pero hay tiempos que no se
pueden adelantar.
●​ Recursos Críticos: Se asume que no tienen la disponibilidad que uno espera.
No siempre es necesario. Cosas que escasean. Ej.: controladores fiscales de
afip, se lo pide prestado al cliente, el cual te lo presta cierto día. Licencia de
software, ancho de banda. El pc no es un recurso crítico

Gestión de riesgos
¿Qué es un riesgo? – posible ocurrencia de un problema, problema
esperando a suceder, para encarar el riesgo hay diferentes formas
RIESGO es un evento o condición incierto que, si ocurre, tiene efecto en al menos un
objetivo del proyecto

Gestión Proactiva: ocuparse para prevenirlos, si se presenta hay que estar

preparados. Primero se deben identificar que problemas puedo tener con el
cumplimiento del objetivo, se analizan, se dimensiona el impacto, y se elige de cuales
se van a ocupar. No es posible ocuparse de todos, elegimos los que nos conviene
hacerles seguimiento. (Grafico de arriba)
Gestión Reactiva: ocuparse de los riesgos cuando ya se presentaron.
Monitoreo y control: Se ocupa de que sigamos la planificación inicial. Se encarga de
tratar de llegar lo más cercano posible a lo que se planificó. ¿Cómo se atrasa un
proyecto? De a un día por vez. Cuando no gestionamos los proyectos estamos
condenados a fracasar.
Curva que marca el avance del proyecto, el
estado actual del proyecto. Algunas tareas
se terminan antes, otras después de lo
planeado.

Gráfico de líneas con lo que tendría que

estar terminado al día de hoy o no. El
estado actual del proyecto depende de la línea que se forme. Lo ideal es una
oscilación de 20% para atrás o para adelante. No debemos subestimar ni
sobreestimar.

Factores para el éxito de un proyecto

●​ Monitoreo & Feedback
●​ Tener una misión/objetivo claro
●​ Comunicación

Causas de fracasos en proyecto

●​ Fallas al definir el problema
●​ Planificar basado en datos insuficientes
●​ La planificación la hizo el grupo de planificaciones
●​ No hay seguimiento del plan de proyecto
●​ Plan de proyecto pobre en detalles
●​ Planificación de recursos inadecuada
●​ Las estimaciones se basaron en “supuestos” sin consultar datos históricos
●​ Nadie estaba a cargo
Todo lo anterior era gestión de procesos tradicional, ahora vamos a ver el enfoque de
los procesos empíricos.

PPA3 – REQUERIMIENTOS AGILES

Cultura y filosofía AGILE: Estos procesos son del tipo empíricos, se basan en la
experiencia que generamos nosotros mismos como equipo en cada instancia de
desarrollo. Cada instancia es una instancia única e irrepetible la cual genera
experiencia y se toma como base para mejorar. Se generan entregas del producto al
cliente lo antes posible, y se obtiene retroalimentación del cliente, la cual se usa para
mejorar y ajustar tanto el producto como el proceso

●​ Primera etapa:

o​ El agilismo hace el foco en el valor.(valor del negocio)

o​ Usar el valor para construir el producto correcto

o​ Los requerimientos tienen micho que ver con el objetivo del cliente, con
el valor de negocio.
o​ Como en el manifiesto ágil, dice que hay que dejarlo contento al cliente
por sobre la documentación extensiva. se valora mas el software
funcionando antes de la documentación extensiva. es decir, dejar
contento al cliente entregándole software que funcione.
 o​ ¿Tenemos que pensar para que el cliente quiere lo que quiere?, par qué
lo quiere?, cual es el valor de negocio que nosotros en nuestro producto
le va a generar al cliente.
●​ Segunda etapa:

o​ Usar historias y modelos para mostrar que construir.

o​ Para retroalimentar rápido, usamos algo para poder mostrar algo para
minimizar la brecha entre saber que es lo quiere el cliente y lo que
nosotros pensamos qe el cliente necesita. Todo lo que haya se utiliza.
utilizamos ciertos modelos.
●​ Tercera etapa:

o​ Determinar que es ¨solo lo suficiente¨, lo mínimo y necesario, construirlo

e implementarlo. implementación rápida y frecuente para poder ir
validando lo que vamos haciendo.
o​ Tenemos que empezar a pensar con que tenemos que empezar a
trabajar. con lo que haga falta, no más ni menos.

Costo tradicional BRUF:

Los productos exitosos también tienen

funciones que no se usan nunca. El 20% de
las características del producto juntan el
80% del valor del producto

●​ Hay que evitar el síndrome del bruf. se evita tratando de no desarrollar el 100%
de los requerimientos con anticipación. Cumplimentar lo justo y necesario.
●​ Dice que evitemos desarrollar para especificar el producto completo, y después
no usarlo, es un desperdicio.
●​ Uno de los puntos a ver es cómo desarrollar lo suficiente

●​ ¿Cuándo empezamos a hacer algo? cunado tenemos lo mínimo que el cliente

quiere, ahí empieza la producción.
●​ Así evitamos el síndrome de parálisis por análisis.

Gestión AGIL de requerimientos:

●​ ¿Como hacemos nosotros para ver que es lo que tenemos que entregarle al
cliente y que no?
●​ Tenemos que elegir por cual vamos a empezar, ahí entra en juego la
priorización.
 ●​ Como no la podemos hacer todas juntas, viene eso de la priorización

●​ Empezamos primero por lo que le de mas valor al cliente. El cliente es el que

va a decir que es( no olvidar que el cliente es miembro del equipo),es quien va
a estar al mando de esa priorización.
●​ El cliente va a ir agregando o sacando características. y nosotros vamos a ir
desarrollando.
●​ Son aquellas de valor, que esta dentro de ese 20%

●​ Tenemos un conjunto de cosas para construir y debemos determina por dónde

empezar, ya que no se puede hacer todo junto. El cliente decide con el criterio
del valor de negocio que es más importante.
●​ Se trata de armar una cola donde las más importantes se ubican más arriba, el
cliente tiene la libertad de cambiar las prioridades, mover características,
agregar, modificar y eliminar

Just in time: Surge en la industria automotriz. La idea era tener la materia prima en
la punta de la línea de la producción. debemos tener en el momento que
quisiéramos/que lo necesitemos, la materia prima. Si lo llevamos al software. analizar
lo necesario, los requerimientos que vamos a tratar, los que van a entrar en desarrollo
son los que vamos a especificar. no los vamos a especificar a todos. Especificar los
requerimientos en el momento en el que se lo necesito. en el momento. no especificar
todo de antemano. Evitamos desperdicio. Hay que ir encontrando de alguna manera
que es lo suficiente y con eso arrancar, y con eso solucionamos y vamos iterando
(iterativo e incremental)

Tradicional vs AGIL
Ágil da vuelta la historia del enfoque
tradicional, no sigo un plan porque no
sé qué requerimientos voy a tener.
Damos vuelta el triángulo, dejamos
fijo el tiempo (duraciones de iteración
fijas) y los recursos fijos (eligiendo y
trabajando con un equipo fijo). Lo
variable son los requerimientos,
acuerdo con el cliente cuantos
requerimientos le puedo entregar en
este tiempo con estos recursos. Si no
se tiene un cliente que quiera hacer
ágil es muy difícil.

Tipos de requerimientos:
User Story: Una User story es una necesidad que tiene el product owner. No es un
requerimiento de software. Están en un nivel más alto que los requerimientos y están
escritos en términos del negocio. El enfoque apunta a gestionar requerimientos, no a
especificarlos. El usuario nos cuenta sus necesidades. Una US tiene 3 partes, algunas
son más visibles que otras. Las 3 C (Card, conversation, confirmation). La más
importante de las tres es la conversación, y esta no queda en ningún lado.

¿Cómo es?
TARJETA/CARD:
Contenedor de un recordatorio
de esa reunion/conversacion
que tuvimos con el product
owner, donde hablamos y el
cliente conto su historia. como
una toma de nota.
en la card reflejamos las
partes mas importantes de esa
conversaciones.
lo as importante de la card es
que refleja el VALOR.

CONVERSACION: ES LA MAS IMPORTANTE PORQUE AHI ES DONDE

OBTENEMOS EL VALOR. la tarjeta y la confirmacion salen de la conversacion.
Dialogo entre nuestro cliente y lso desarrolladores aerca de algo, de na historia que el
necesite que el producto realice. se habla sobre cuestiones del valor o el resultado que
se espera del producto. enfocamos a eso
CONFIRMACION: Es un pacto entre el product owner y el equipo de desarrollo para
saber si esta completa. es un acuerdo que se hace si esa user esta completa o no. se
fijan todas las caracteristicas para saber si la user esta completa. nos especifica o
detalla los criterios que sirven p que usan para determinar cunado la user storie esta
completa. al momento de realizar la entrega del producto al cliente, consideramos qie
cumple con todos los criterios que la user tiene que terner para que este completa.
pruebas de aceptacion que nosotros vamos a ejecutar y diseñar las pruebas para
corroborar que se cumplan. El dueño del producto prioriza las historias en el producto
backlog: si no le escribis el valor al user, no podes priorizarlo.

Las User Stories son multipropósito:

Las historias son:
●​ Una necesidad del usuario, expresiones de intención
●​ Una descripción del producto
●​ Un ítem de planificación
●​ Token (recordatorio) para una conversación
●​ Mecanismo para diferir una conversación
NO es una especificación de requerimientos porque NO tiene detalle

El dueño del producto prioriza las historias en el product backlog

Product backlog: Cola de

historias. Es una cola priorizada
de características del producto,
las de arriba tienen más
prioridad. El Product Owner
puede moverla como quiera.
En el product backlog puede
haber user stories, pero puede
haber otras cosas, granularidad
más gruesa. Puede haber
defectos también.
Genéricamente a cada
elemento del product backlog
se le llama ítem de product
backlog (PBI).
Posiciones verticales: Se dice que son porciones verticales, porque no se le
puede entregar valor de negocio al cliente si se corta horizontalmente. Se tiene que
hacer un poco de cada cosa de forma vertical (un poquito de presentación, de
persistencia, y lógica de negocio) para que se pueda utilizar.

Modelado de roles: Tengo que conocer quién va a trabajar con el software. Se

apunta a definir cuál es el perfil del usuario con el que vamos a interactuar, para lograr
que el usuario se sienta cómodo. No puedo tener un solo usuario que se llama
usuario. No se pueden definir roles, características si hacemos esto. Para las US
tengo que pensar quien es el rol que se va a desempeñar ahí y hacer una descripción
para conocerlo. Describir vínculo con la tecnología, como se desarrolla en su espacio
de trabajo.
●​ Personas: no habla de un rol genérico (ej.: docente), sino de una persona
concreta. Persona es: sol vive en villa maría, tiene 2 hijos, espera que el
sistema de la gestión de la facultad le permita cargar la nota de los alumnos,
etc. Es bueno hablar con quienes usaran el producto para ver que producto
necesitan, cuando son muchos se eligen algunos.
●​ Personajes extremos: busca perfiles de usuarios no comunes. Esto nos
ayuda a derivar características, después se eligen cuales tener en cuenta o
cuando incorporarlas. Ejemplo: un ladrón, el papa.
Usuarios representantes (Proxies):
●​ Gerentes de Usuarios
●​ Gerentes de Desarrollo
●​ Alguien del grupo de marketing
●​ Vendedores
●​ Expertos del Dominio
●​ Clientes
●​ Capacitadores y personal de soporte
No son ideales como los usuarios verdaderos, EVITELOS.

Criterios de aceptación de las User Stories: Un criterio de aceptación es el

criterio por el cual se define si una historia de usuario fue desarrollada según la
expectativa del Product Owner (como representante de los criterios del cliente) y si se
puede dar como hecha.

Son condiciones de satisfacción. Los criterios de aceptación es un agregado que

ayuda a saber si la user va a ser aceptada por el producto owner o no. Ayudan a saber
si la US va a ser aceptada por el cliente o no. Dicen pautas de cómo debe funcionar el
producto para que el cliente diga si está de acuerdo o no. Pueden estar involucrados
requerimientos no funcionales. Además, ayudan a escribir las pruebas de aceptación
de atrás.

¿Qué definen?

●​ Definen límites para una user story (US)

●​ Ayudan a que los PO respondan lo que necesitan para que la US provea valor
(requerimientos funcionales mínimos)
●​ Ayudan a que el equipo tenga una visión compartida de la US
●​ Ayudan a desarrolladores y testers a derivar las pruebas.
●​ Ayudan a los desarrolladores a saber cuándo parar de agregar funcionalidad en
una US
¿Cuáles son buenos?

✔​ Definen una intención, no una solución. Ej.: El usuario debe elegir al menos
una cuenta para operar
✔​ Son independientes de la implementación
✔​ Relativamente de alto nivel, no es necesario que se escriba cada detalle

Pruebas de aceptación:
De los criterios de aceptación se derivan las pruebas de aceptación. Son las confirmaciones. Hay
que identificar que pruebas de usuario se deben hacer para que en función de estas el usuario
acepte la implementación de la user story. No se prueba todo lo que se debería porque el
testing exhaustivo es muy costoso.
Se debe poner si las pruebas son positivas o negativas, ver qué pasa cuando el usuario hace
algo que no se supone que debe hacer. Pensar en ambos tipos de escenario.

●​ Expresan detalles resultantes de la conversación

●​ Complementan la User Story
●​ Proceso de dos pasos:
o​ Identificarlas al dorso de la US.
o​ Diseñar las pruebas completas
El caso de prueba se diseña a partir de pruebas de aceptación.

Definición de listo: Un acuerdo que se construye en el equipo ágil para

determinar si la US está en condiciones de ser desarrollada, si ya tiene el nivel que el
equipo espera para que entre en una iteración de desarrollo. No hay un estándar, para
cumplir con DoR debe respetar el modelo INVEST. Son medidas de calidad.
Modelo INVEST:
●​ Independiente: calendarizables e implementables en cualquier orden. Se busca darle
la libertad al producto owner de elegir el orden en el que quiere que se desarrollen las
historias. Puedo implementar (construir y programar) las users en cualquier /revisar/
momento u orden?.
●​ Negociables: el “qué” no el “cómo”. Poder discutir que es lo que el usuario quiere, no
como lo quiere. No puede poner en la user indicaciones de como diseñar y construir la
solución.
●​ Valor de negocio (valuable): debe tener valor para el cliente. El para que de la US.
Debe tener valor para el cliente (valor de negocio), lo que me ayuda a priorizar.
●​ Estimable: para ayudar al cliente a armar un ranking basado en costos. Debe tener
valor para el cliente tengo que poder asignarle un peso a la US, sino no puedo imaginar
cuan compleja es, cuanto tiempo necesito, que riesgos tiene. Si no es estimable no
podemos comprometernos.
●​ Pequeña (Small): deben ser “consumidas” en una iteración. Pequeña es que yo la
pueda empezar y terminar en una iteración. Pero esto es bastante relativo, depende del
equipo y la duración de la iteración. Ahí empezamos a tener conflicto entre unas y
otras, entre debe tener valor para el cliente y poder terminarla en una iteración.
●​ Testeable: demostrar que fueron implementadas. Que se pueda probar, puedo mostrar
y demostrar que la implementé y hace lo que tiene que hacer.
Definición de hecho: se usa a fin dela iteración. son criterios que va a uiitlizar el
equipo para saber si el trabajo esta hecho, sie l trabajo esta terminado. si cumple con
el definition of done, entonces el trabajo esta hecho. es para saber hasta cuando
tenemos que trabajar. Teminamos la user cunado cumplimos con todo esto

Diferentes niveles de abstracción:

Cuando una user es muy grande que
no la puedo trabajar en una iteración
(ya sea porque el quipo es muy chico,
o porque no me da el tiempo, o
porque no puedo definir que tan
grande es), tenemos una EPICA (la
epica es cuando abarca mucho) A la
épica la podemos dividir y hacer
varias user y resolver esa épica

SPIKES: Tipo especial de historia,

utilizado para quitar riesgo e incertidumbre de una User Story u otra faceta del
proyecto. Debemos ver si una US tiene cierto nivel de incertidumbre, si no se puede
estimar y tiene mucha incertidumbre se convierte en una spike. Hay riesgos asociados
a las spikes. No cualquier inconveniente pequeño transforma una US e un spike.

Pueden utilizarse para:

→​ Inversión básica para familiarizar al equipo con una nueva tecnología o

dominio.
→​ Analizar un comportamiento de una historia compleja y poder así dividirla en
piezas manejables.
→​ Ganar confianza frente a riesgos tecnológicos, investigando o prototipando
para ganar confianza.
→​ Frente a riesgos funcionales, donde no está claro como el sistema debe
resolverla interacción con el usuario para alcanzar el beneficio esperado.
Estimaciones agiles: Difiere con la estimación tradicional. Las agiles buscan
certeza y no precisión, las estimaciones son relativas, porque mejores haciendolas,
somos buenos estimando en comparación con otras cosas. Es mejor comparar que
decirla en términos absolutos.

En los equipos Agile, las features/stories son estimadas usando una medida de
tamaño relativo conocida como story points (SP). Las medidas relativas no son
absolutas. Story Points no es una medida basada en tiempo.

Son relativas y NO absolutas porque como humanos somos mas hábiles dando
medidas relativas(Este es mas alto que este, realizamos comparaciones) estimamos
con bastante certeza en el ambiente de la estimación.
medida basada en tiempo. medida que utilizamos en los enfoques agiles para
determinar con bastante certeza que tan grande o que tan compleja, es decir, para
estimar el tamaño de una user, de una características. hay ciertos conceptos que
tenemos que usar para definir e tamaño de la user, de una característica.
Como las personas en si por su naturaleza somos más hábiles haciendo
comparaciones, entonces el agilismo se basa en eso, utilizan la forma de medir el
tamaño de una característica por esa comparación y estimaciones relativas.
Tamaño En este contexto no tenemos que pensar en tamaño como se pensaba antes
que era en líneas de código.

Hay 3 puntos a tener en cuenta:

●​ Cuan compleja es.

●​ Que tanto esfuerzo es requerido. independizar de alguna manera el tamaño y
esfuerzo
●​ Otra variable para determinar le tamaño de una user es la incertidumbre.
(siempre hay incertidumbre) que nivel de incertidumbre tiene la user para poder
ser desarrollada

Tamaño en el software: Grupo de factores a analizar para poder determinarlo. No

tenemos un valor directo de tamaño como generalmente lo tenemos en la vida real,
(este perro es 50 cm mas grande que este por ejemplo.) en el software es mucho más
complejo

no podemos asignar una medida directa de la calidad ni del tamaño del software. (por
ejemplo: no se puede medir en litros o en metros, no hay una unidad de medida) por
eso exige todo esto para estimar el tamaño.

Tamaño vs esfuerzo: Son conceptos diferentes No es fácil separar el tamaño del

esfuerzo, el tamaño es netamente inherente a la user y el esfuerzo es inherente a las
personas que realizan el trabajo. El esfuerzo está totalmente ligado al trabajo que hay
que realizar para el producto. En el software para determinar el esfuerzo tenemos que
tener muy en claro las habilidades del equipo ( a equipos diferentes les va a llevar
esfuerzos diferentes) y así poder separar esfuerzo de tamaño.

¿Y qué hacemos con el tamaño?

Al trabajar en ámbito de la certeza y no de la precisión. Se utilizan las siguientes
unidades de medida:

●​ Tamaño por numeros

●​ Talles de remeras.
●​ Serie 2n: 2,4,
●​ Fibonacci

una vez que elegimos la escala no debemos cambiarla porque si se cambia

cambiamos el metro patrón
Story Point: Es una unidad de medida específica (del equipo) de, complejidad,
riesgo y esfuerzo, es lo que “el kilo” a la unidad de nuestro sistema de medición de
peso.
Story point da idea del “peso” de cada story y decide cuan grande (compleja) es. La
complejidad de una story tiende a incrementarse exponencialmente.
Siempre se debe buscar una escala exponencial, no lineal porque no acompaña a la
complejidad del software. Recomendado serie de Fibonacci.
Toma en cuenta tres dimensiones:
●​ Complejidad: que tan complejo será lo que tenemos que construir
●​ Esfuerzo: horas de trabajo necesaria
●​ Duda: nivel de incertidumbre

En base a estas 3 dimensiones se determina la estimación. Las tres dimensiones

combinadas nos darán el peso de la user, y en base a esa se le asigna un tamaño.
Velocidad: Es una métrica de progreso. La velocidad nos da un reflejo para
determinar si el equipo esta estimando bien o no. Por ejemplo si el equipo se
comprometía a entregan 15 puntos de historia, y después entregaron 5, algo pasó ahí.
Fiel reflejo que nos muestra cómo esta estimando el equipo, para el próximo sprint va
a aprender (pilares del empirismo: se inspecciona, se adapta). La velocidad termina
corrigiendo esos errores de estimación

¿Y como hago con un proyecto?: ¿Si estimo User Storys cómo hago para
estimar un proyecto? La duración de un proyecto no se “estima”, se deriva tomando el
número total de story points de sus US y dividiéndolo por la velocidad del equipo. La
velocidad nos ayuda a determinar un horizonte de planificación apropiando. La
estimación en story points separa completamente la estimación de esfuerzo de la
estimación de la duración.

Metodo de estimación: Poker Planning: Es una propuesta de método de

estimación La estimación la hace el quipo de trabajo que va a resolver el trabajo. El
experto es el equipo mismo (no hay un líder para hacer esto). los participante son los
desarrolladores, las personas mas competentes en resolver la tarea. Se utilizan user
stories que son pequeñas, que tienen pocos puntos de historia. Generalmente se
busca user que tenga 1 punto de historia para hacer el poker planning. las demás
stories se compara con esta, con la canon. En base a la canónica se le asignan puntos
de historia a otra, consensuado por el equipo. y así con todas las user stories. Si no se
ponen de acuerdo, hay algo que está mal en la user story, hay que verla de nuevo,
capaz le faltan detalles o no se entiende.
Pasos
1.​ Debemos elegir US canónica, esa se usa para comparar con las demás, los
menos expertos buscan la más sencilla y se le ponen el valor de 1. Algunos
trabajan con una canónica de 2, para dejar el espacio de que aparezca algo
más sencillo.
2.​ En base a esta se comparan las otras y se asignan los valores de
estimación. Se presenta la user, si no se puede estimar se asigna ? y es un
spike. Sino cada integrante estima con su carta (no se muestra hasta que todos
terminen de elegirla)
3.​ Los que tienen valor mayor o menor empiezan a explicar porque llegaron a ese
valor y así todos los demás, porque deben llegar a un consenso. Se repite la
estimación varias veces hasta llegar a un consenso.
4.​ Con tres iteraciones se debería llegar a un consenso, si no se llega se puede
elegir el que más aparece o se determina con promedios.

Decodificación de las estimaciones

→​ ?: Spike

→​ Café: están cansados.

→​ 0: Quizás ud. no tenga idea de su producto o funcionalidad en este punto.

→​ 1/2, 1: funcionalidad pequeña (usualmente cosmética).

→​ 2-3: funcionalidad pequeña a mediana. Es lo que queremos.

→​ 5: Funcionalidad media. Es lo que queremos.

→​ 8: Funcionalidad grande, de todas formas, lo podemos hacer, pero hay que

preguntarse si no se puede partir o dividir en algo más pequeño. No es lo
mejor, pero todavía
→​ 13: Alguien puede explicar por qué no lo podemos dividir?

→​ 20: Cuál es la razón de negocio que justifica semejante story y más fuerte aún,
por qué no se puede dividir?.
→​ 40: no hay forma de hacer esto en un sprint.

→​ 100: confirmación de que está algo muy mal. Mejor ni arrancar.

La recomendación es tener US de 2, 3 y 5, como mucho 8, si es más grande hay

dividir la US.

PPA4 – GESTION DE PRODUCTOS

Gestión de productos:

¿Por qué creamos productos?

●​ Para satisfacer necesidades de los clientes

●​ Para tener muchos usuarios logueados
 ●​ Para obtener mucho dinero
●​ Realizar una gran visión, cambiar el mundo, mejorar la sociedad.

La mayoría de las características que tiene un producto de software no se usan. 80%

del valor de un producto está situado en el 20% de las características de este.

Valor vs desperdicio: Tenemos que pensar en un producto de software que

entregue valor al cliente. Todo lo que no genera valor es desperdicio. Tenemos que
unir los esfuerzos para entender al cliente, descubrir que es lo que realmente necesita
y no suponerlo.

MVP: Producto mínimo viable (Minimal viable product): Tiene la idea de aprendizaje,
en entender y determinar si estamos construyendo el producto correcto, apunta a eso,
a realizar un análisis para encontrar las características mínimas del cliente, son las
que primero deben salir. nos sirve para validar si el producto que estamos haciendo es
el correcto en el sentido que nos ayuda a determinar si va a haber un inversor que
quiera poner dinero para desarrollar o determinar si los clientes usan la aplicación o

no, es una forma de aprendizaje

MVP vs MMF o MMP: errores comunes
●​ Confundir a un MVP, que se enfoca en el aprendizaje, con Característica
Comercializable Mínima (MMF) o con Producto Comercializable Mínimo (MMP),
ambos se enfocan en “ganar”.
●​ El riesgo de esto es entregar algo sin considerar si es lo correcto que satisface
las necesidades del cliente.
●​ Enfatizar la parte mínima de MVP con exclusión de la parte viable. El producto
entregado no es de calidad suficiente para proporcionar una evaluación precisa
de si los clientes utilizarán el producto.
●​ Entregar lo que consideran un MVP, y luego no hacer más cambios a ese
producto, independientemente de los comentarios que reciban al respecto.
¿Y donde esta el valor?
●​ El éxito no es entregar un producto, el éxito se trata de entregar un producto (o
característica de​
producto) que el cliente usará.
●​ La forma de hacerlo es alinear los esfuerzos continuamente hacia las
necesidades reales de los clientes.
●​ Para crear MVP se recomienda: The Build-Experiment-Learn feedback loop
permite descubrir las necesidades del cliente y alinearlas metodológicamente.
Fase - construir MVP: Se debe hacer rápido, invertir poco, con pocos recursos
tratar de lanzar un producto mínimo viable, Esto hace foco a la oportunidad, llegar
antes que otros al negocio.

Fase - experimentar MVP: Completar

Ejemplo: Facebook, se lanzo la idea con algo mínimo y a la semana tuvo un monton
de usuarios registrados

Supuestos saltos de FE: Los elementos más riesgosos del plan / concepto de un
startup (es decir, las partes de las que todo depende) se denominan supuestos de
salto de fe.

Trabajamos con dos premisas en el ciclo. Apunta a fiarse de una hipótesis que da la
viabilidad de que va a ser comprado. Están sustentados en dos hipótesis:
Hipótesis del valor
●​ Prueba si el producto realmente está entregando valor a los clientes después
de que​
comienzan a usarlo.
●​ Una métrica de prueba: tasa de retención. Compre el celular, por ejemplo, y lo
uso o no lo uso. Si lo compras y no te dura mucho no supera la tasa de
retención. Otro ejemplo: si descarga una app, la uso 15 minutos y la desinstalo.
Facebook en cambio, mucha gente ya no lo usa pero lo sigue teniendo
instalado.
Hipótesis de crecimiento
●​ Prueba cómo nuevos clientes descubrirán el producto
●​ Una métrica de prueba: tasa de referencia o Net Promoter Score (NPS).
Cuantos usuarios tengo usando el producto, cuantos quiero tener y cuantos
voy teniendo a lo largo del tiempo.

PPA5 – SCRUM
FRAMEWORK PARA GESTION AGIL DE PROYECTO. no es una metodologia. es un
framwork, un marco dd trabajo, un enfoque. le falta mucho para ser una metodologia.
Scrum se basa en el:

→​ Empirismo: afirma que el conocimiento proviene de la experiencia y la toma

de decisiones basadas en lo que se observa.
→​ Pensamiento Lean: reduce los desperdicios y se centra en lo esencial.

Scrum emplea un enfoque iterativo e incremental para optimizar la previsibilidad y

controlar el riesgo.

Scrum combina cuatro eventos formales para la inspección y adaptación dentro de

un evento contenedor, el Sprint. Estos eventos funcionan porque implementan los
pilares empíricos de Scrum: transparencia, inspección y adaptación.

Pilares del empirismo:

 ●​ Transparencia: El proceso y el trabajo deben ser visibles para aquellos que
realizan y reciben el trabajo. Los artefactos que tienen poca transparencia
pueden conducir a decisiones que disminuyen el valor y aumentan el riesgo. ​
La transparencia permite la inspección. La inspección sin transparencia genera
engaños y desperdicios
●​ Inspección: Los artefactos de Scrum y el progreso hacia objetivos acordados
deben ser inspeccionados con frecuencia para detectar varianzas o problemas
potencialmente indeseables. Para ayudar con la inspección, Scrum proporciona
cadencia en forma de sus cinco eventos. ​
La inspección permite la adaptación. La inspección sin adaptación se considera
inútil. Los eventos de Scrum están diseñados para provocar cambios.
●​ Adaptación: Si algún aspecto de un proceso se desvía fuera de los límites
aceptables o si el producto resultante es inaceptable, el proceso que se está
aplicando o los materiales que se producen deben ajustarse. El ajuste debe
realizarse lo antes posible para minimizar la desviación adicional. La
adaptación se vuelve más difícil cuando las personas involucradas no están
empoderadas o no poseen capacidad para autogestionarse. Se espera que un
equipo de Scrum se adapte en el momento en que aprenda algo nuevo por
medio de la inspección.

Valores de Scrum:

Principios:
●​ Desarrollo iterativo: Adherimos a ciclos de vida iterativos porque queremos
generar la experiencia en entregables que se le dan al cliente. No se puede
hacer scrum con cascada.
●​ Time-boxing: el tiempo es fijo, pero no solo para el sprint, se aplica a todas las
ceremonias de scrum.
●​ Auto-organización: es requerida para que
funcione esto de no tener un jefe para que diga
que debo hacer, que hacer primero, porque eso
al equipo lo resuelve solo. Al líder lo eligen los
compañeros, el líder emerge, al jefe lo elige la
 empresa. El que asumen de scrum master no siempre va a ser la misma
persona. Puede ir cambiando.
●​ Colaboración: si tengo un problema debo tener la libertad de comunicarle al
resto.
●​ Priorización basada en el valor: es un proceso de ordenamiento, estamos
ordenando con criterio de que lo más importante es el valor para el cliente. Se
pregunta cómo hacer para darle más valor al cliente. El encargado de priorizar
es el product owner, porque es el que conoce el negocio, es el que mejor va a
poder priorizar.

Responsabilidades de Scrum: Dentro de un equipo de Scrum, no hay

sub-equipos ni jerarquías. Es una unidad cohesionada de profesionales enfocada en
un objetivo a la vez, el objetivo del Producto.

Características
●​ Auto -organizado: internamente deciden quién hace qué, cuándo y cómo
●​ Funcionalmente Transversal
●​ Multifuncional: los miembros tienen todas las habilidades necesarias para
crear valor en cada Sprint.
●​ Habilidades en forma de “T”: Cada uno puede tomar una US y empezarla y
terminarla.
●​ Muy buena comunicación
●​ Tamaño correcto: suficientemente pequeño como para permanecer ágil y lo
suficientemente grande como para completar un trabajo significativo dentro de
un Sprint. Entre 7+-2. Que el grupo se puede conformar en un equipo y
mantenerse en el tiempo, por eso habla de larga vida. Los equipos más
pequeños se comunican mejor y son más productivos, si se vuelven demasiado
grandes, se debe considerar la posibilidad de reorganizarse en varios equipos
Scrum cohesionados.
●​ Focalizado y comprometido
●​ Larga vida
●​ Trabajo en clima de paz sostenible
Actitud de Mosquetero: funcionamos como equipo

Responsabilidades: Cambios con respecto al anterior: no se habla más de roles,

sino de responsabilidades, las agrupa en categorías de responsabilidades. Sacaron rol
porque en muchas organizaciones igualaron roles con cargos.

En el manifiesto ágil trabajan juntos:

●​ Técnicos (informaticos)
●​ No técnicos (producto owner)
Product Owner: Es responsable de maximizar el valor del producto resultante del
trabajo del equipo de Scrum. Puede representar las necesidades de muchas partes
interesadas en el trabajo pendiente del producto. Para que los Propietarios de
Productos tengan éxito, toda la organización debe respetar sus decisiones.

Scrum Master: El scrum master se ve como un líder que emerge del equipo, tiene un
rol técnico porque si es necesario trabaja
Sprint: El sprint tiene que asociarse a un objetivo y este objetivo debe estar alineado
al producto. Lo que nos comprometemos al inicio del sprint es lo que vamos a realizar,
no cambios! Dentro del sprint no se modifica nada. Se recomiendan que sean cortos
por la retroalimentación temprana, ir reduciendo errores y hacerlos mas controlables,
es mas facil planificar porque son caracteristicas mas reducidas. Son de duracion fija
por el timeboxing (tiempo fijo, tiempo en una caja) lo ideal es que el equipo logre
definir una cantidad fija de dias del sprint, y que esta sea para todos los sprints. si el
tamaño de todos los sprints es igual, al cliente le genera más confianza. al equipo
tambien le beneficia porque le permite al equipo ir midiendo sus avances. Lo que se
mueve es el alcance. puede suceder que le asignemos menos puntos de historias de
lo que realmente le correspondia a una user, la subestimamos. Cuando el equipo ve
que no llega…
El equipo no deberia permitir que el cliente agregue mas caracteristicas cuando el
sprint está corriendo. El equipo entrega lo comprometido.

Sprint de corta duración:

●​ Fácil de Planificar
●​ Realimentación rápida
●​ Error Acotado
●​ ROI mejorado
●​ Excitación renovada. Renovamos el entusiasmo
●​ Puntos de Control frecuentes. Si nos equivocamos tenemos retroalimentación
para corregirlo
Sprint Planning: Inicia el Sprint estableciendo el trabajo que se realizará para el
mismo. Este plan resultante es creado por el trabajo colaborativo de todo el equipo de
Scrum. El equipo de Scrum también puede invitar a otras personas a asistir a la
planificación del Sprint para proporcionar asesoramiento. El Sprint Planning tiene una
duración máxima de ocho horas para un Sprint de un mes. Para sprints más cortos, el
evento suele ser más corto.

Temas que aborda

Daily Scrum:
 ●​ Propósito: inspeccionar el progreso hacia el objetivo del Sprint y adaptar el
Sprint Backlog si es necesario. Sincronización, para ver que necesidades y
objetivos hay en ese dia.
●​ Misma hora y lugar, todos los días hábiles
●​ Para desarrolladores
●​ Duración: 15 minutos máximo
●​ Si PO y SM trabajan activamente en IPB’s, participan como Desarrolladores. Si
el SM y el po tienen asignaciones de trabajo, SM trabajo de desarrollador, van
a la daily, sino no van.
Beneficios:
-​ Mejora la comunicación
-​ Elimina necesidad de otras reuniones identifica y remueve obstáculos
-​ Promueve toma de decisiones rápidas
-​ Mejora el conocimiento

Sprint Review: Es la penúltima actividad del sprint. Le mostramos al PO el producto

y el puede aprobar o no ciertas caracteristicas. Si acepta todo, el equipo tiene
velocidad=a la suma de los puntos de historias desarrolladas durante el sprint. Si no
acepta todo, la velocidad disminuye. solo sumamos los puntos de las historias
aprobadas y terminadas. La velocidad se calcula, la capacidad se estima. Al finalizar el
trabajo del sprint hacemos el sprint review y adaptamos el producto

Sprint Retrospective: El equipo genera su propia experiencia para ir mejorando el

proceso. que cosas hizo bien, que cosas puede mejorar o no seguir haciendo.

Product Backlog Refinement: No es obligatoria, no tiene un momento

determinado para realizarla, Se hace cuando se necesita refinar el product backlog

Artefactos:

●​ Sprint Backlog
Puede tener tareas o
no. Tablero básico: to
do, doing, done.
Las user se estiman en
puntos de historia y las
tareas en horas
ideales, esfuerzo.
Significa que no tienen
interrupción, se saca el
tiempo que almuerzo,
que voy al baño etc.
Dos US pueden tener
los mismos puntos de
historia no significa que
tengan las mismas horas ideales. Cada persona que toma una user puede
necesitar esfuerzos distintos para hacer el trabajo.
 Una de las entradas es la velocidad promedio, y, si no la tengo, se estima la
capacidad, es recomendable hacerlo igual, aunque tenga velocidad. Se les
pregunta a los miembros cuanto tiempo van a tener disponible y se tienen en
cuenta situaciones particulares, la capacidad es una métrica de trabajo
disponible, mide cuanto trabajo puede el equipo completar en una iteración, se
estima
A cada US se las descompone en tareas, y a las tareas se las estima en horas
ideales. Al final obtengo la cantidad de horas necesarias para cumplir todas las
tareas que implica la implementación de las US.

●​ Incremento del producto:

Es el más importante, todo lo que
hacemos es para generar un
incremento en el producto.

No cuenta el trabajo parcialmente

terminado, se usa gestión binaria,
está hecho o no está hecho. Si
está a 80% no sirve para mostrarla
en el sprint review, para scrum el
trabajo a medias es tiempo
desperdiciado. Por eso se apunta a
user story chiquitas (1,2,3,5) y si
son grandes dividirlas.