QUIERES SABER QUE ES AGILISMO!!!!!!

1. Un poco de historia del agilismo:

La definición moderna de desarrollo ágil de software de la IU.CESMAG evolucionó
a mediados de la década de 1990 como parte de una reacción contra los métodos
de "peso pesado", muy estructurados y estrictos, extraídos del modelo de
desarrollo en cascada. El cual era visto como burocrático, lento, degradante e
inconsistente con las formas de desarrollo de software que realmente realizaban
un trabajo eficiente.
Los métodos de desarrollo ágiles e iterativos pueden ser vistos como un retroceso
a las prácticas observadas en los primeros años del desarrollo de software
(aunque en ese tiempo no había metodologías para hacerlo). En el año 2001,
miembros prominentes de la comunidad se reunieron en Snowbird, Utah, y
adoptaron el nombre de "métodos ágiles". Poco después, algunas de estas
personas formaron la "alianza ágil", una organización sin fines de lucro que
promueve el desarrollo ágil de aplicaciones. Muchos métodos similares al ágil
fueron creados antes del 2000. Entre los más notables se
encuentran: Scrum (1986), Crystal Clear (cristal transparente), programación
extrema (en inglés eXtreme Programming o XP, 1996), desarrollo de software
adaptativo, feature driven development, Método de desarrollo de sistemas
dinámicos (en inglés Dynamic Systems Development Method o DSDM, 1995).
2. Que es un marco de trabajo: Es un conjunto estandarizado
de conceptos, prácticas y criterios para enfocar un tipo de
problemática particular que sirve como referencia, para
enfrentar y resolver nuevos problemas de índole similar.

3. Que es agilismo: La habilidad de las personas, equipos y organizaciones de

crear Valor a la vez que promover y responder al cambio para tener éxito en un
entorno incierto.

4. Los pilares del agilismo

 Entrega continua: Se entiende por retroalimentación

permanente, retorno temprano y continuo de la inversión,
gestionar el riesgo permanentemente, se establece
confianza, los usuarios se adueñan del desarrollo.
 Adaptabilidad: Producto evolutivo y planeación adaptativa
(Hipótesis y experimentos), Basado en el mejor valor de
negocio (Alineado al norte de producto - competitividad), Sin
desperdicios (Costo, tiempo).

 Mejora Continua: Los procesos siguen el ciclo (planear,

hacer, verificar y actuar -PHVA - Deming), Control
empírico de proceso (Inspección – hansei, Adaptación –
kaizen, Transparencia).

 Colaboración: Interactuar cara a cara, Evitar desperdicios

de comunicación, Estar constantemente alineados,
Comunicación se vuelve efectiva, Los acuerdos se
establecen en equipo.

5. Bibliografía de interés

 Cockburn, Alistair. Agile Software Development. Highsmith Series.

 Chin, Gary (2004). Agile Project Management: How to Succeed in the Face of
Changing Project Requirements. AMACOM.
 Martinez, Gustavo (2011). Coding, quality check and documentation (300%): Get
them from the same development team!. VPD.
 Páez, Nicolás et al. (2014). Construcción de software: una mirada ágil.
EDUNTREF.
 Elementos del Manifiesto Ágil

 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

ELEMENTOS DEL MANIFIESTO

Los individuos y sus interacciones por sobre los procesos y las herramientas. En
un mundo lleno de computadores y comunicaciones, las herramientas de software
priman. Pero ¿cuál es el verdadero impacto de las herramientas en el negocio? Retardos,
herramientas que se usan para lo que no se deben usar; herramientas de software que
pretenden optimizar la comunicación y que finalmente son más un obstáculo para una
comunicación efectiva. ¿Cuál es la comunicación más enriquecida y de impacto más
positivo? En la parte más baja de la escala tenemos los email, seguidos por el chat
escrito, y luego por software que permita ver a la otra persona tipo GoogleTalk, Skype,
FaceTime, etc. Luego viene el celular, que sigue siendo una excelente herramienta,
aunque aún no tengamos la imagen de la otra persona, y en la cúspide de la escala está
la comunicación presencial cara a cara, aquella que nos deja ver la cara del otro e
identificar sus expresiones, sus deseos, sus desaciertos; aquella que nos permite
identificar si la persona está o no está realmente involucrada en una comunicación; esa
misma que me deja a mi saber si la persona realmente se siente cómoda conmigo, o
está triste, o feliz; esa que me deja identificar el tipo de reacciones que pueden estar
teniendo mis palabras. Los individuos interactúan y eso supera cualquier tipo de
documento escrito, o de chat. Si pretende resolver un problema rápidamente, empiece
por usar el celular si no puede hacer una comunicación directa. El chat es una gran
alternativa si todas estas interacciones ricas no son posibles. En particular evite el email
para comunicarse y úselo sólo para llevar registro o para enviar documentos que no son
interactivos. Hoy no se puede ser ágil si nos fundamos en el uso de herramientas.

Software funcionando por sobre la documentación exhaustiva. ¿Qué prefieres: ver

avances del software funcionando, o saber que la documentación de requisitos está en
vías de ser perfecta? Los documentos con mucho detalle en las especificaciones
funcionales y no funcionales, y los documentos técnicos con todo tipo de diagramas, son
pan de cada día dentro de la industria del software. Sin embargo, ha sido esa búsqueda
de intentar lograr que la industria del software sea una ingeniería, la que nos ha llevado
a modelos de trabajo y ciclos de vida que son muchas veces inadecuados, dependiendo
de las necesidades del negocio. Lo que pretende el agilismo es recuperar el producto de
software y hacer la documentación que sea estrictamente necesaria. El manifiesto ágil
no da por inútil la documentación, sólo aquella que es innecesaria. Los documentos son
soporte de hechos, permiten la transferencia del conocimiento, registran información
histórica, y en muchas cuestiones legales o normativas son obligatorios, pero su
relevancia debe ser mucho menor que el producto final.

La colaboración con el cliente por sobre la negociación contractual. Debemos dejar

de ser “contrapartes” en un negocio para volvernos “equipo”. Son los equipos
compuestos de personas que quieran producto y personas que sepan hacerlo, los que
hacen software de calidad. Las leyes y los documentos no saben hacer software.
Entonces, no intente solucionar los problemas de mala interacción entre las partes a
través de minutas o cláusulas contractuales. Debe involucrar al cliente en el proceso de
desarrollo: debe ser parte del equipo.

Adaptarse al cambio por sobre seguir un plan. Los ciclos de vida rígidos, como el
cascada, dificultan la incorporación del cambio como una ventaja en los procesos de
desarrollo de software. De hecho, hablar de cambios continuos sobre las
especificaciones del producto, es visto por muchas empresas de desarrollo de software
como algo complejo de incorporar. Es la posibilidad de adaptarse al cambio de las
organizaciones lo que hace la calidad del software, incluso durante fases tardías de
desarrollo. El software debe evolucionar según las circunstancias, por lo que el cambio
es bienvenido. No se trata tampoco de generar desorden. Se trata de aprender a abordar
el cambio. El agilismo persigue siempre esta característica en todo aspecto.
12 principios del Manifiesto Ágil

1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y

continua de software con valor.

Nuestra mayor prioridad es satisfacer al cliente mediante la

entrega temprana y continua de software con valor. El cliente
hace una inversión y espera un retorno de ella. La entrega temprana
de incrementos de software a través de iteraciones le da mucho valor
al cliente, y le garantiza un retorno continuo de la inversión desde
etapas tempranas. También, el cliente de forma intuitiva reflexionará
sobre el uso del software en su negocio y decidirá mejoras o cambios
que requiere en el mismo, evitando que malas definiciones o software
inútil sean creados. En Scrum estas iteraciones se llaman Sprint, y
cada una de ellas entrega un incremento de producto.

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.

Aceptamos que los requisitos cambien,

incluso en etapas tardías del desarrollo. Los
procesos Ágiles aprovechan el cambio para
proporcionar ventaja competitiva al cliente.
Aceptar que el software puede cambiar
constantemente es permitir que las empresas
sean competitivas. La competitividad de las
empresas hoy se debe mucho en el ámbito de
los servicios que brindan sus sistemas de
información al interior de la compañía, o al
exterior a sus clientes. De la velocidad del
cambio dependerá la velocidad de reacción al
mercado, y la empresa será más competitiva.
3. Entregamos software funcional frecuentemente, entre dos semanas y dos
meses, con preferencia al periodo de tiempo más corto posible.

Entregamos software funcional frecuentemente, entre dos

semanas y dos meses, con preferencia al periodo de tiempo más
corto posible. Los ciclos o iteraciones cortas garantizan una más
frecuente revisión del producto y de los procesos. Eso permitirá
corregir desviaciones frecuentemente, de modo que los riesgos son
mitigados muy tempranamente.

4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma

cotidiana durante todo el proyecto.

Los responsables de negocio y los desarrolladores trabajamos juntos de forma

cotidiana durante todo el proyecto. Un gran problema es que el desarrollo de un
producto de software se hace partiendo de la
premisa que hay dos partes involucradas en el
proceso: el que recibe el software y el que lo
hace. Todos los problemas comienzan allí,
pues la comunicación que se usa a través de
documentos es casi siempre improductiva,
confusa y lleva a malos entendidos. Por muy
buenas que sean las especificaciones, siempre
habrá aspectos que resolver y aspectos que se
malinterpretan. En la medida en que las partes
formen un verdadero equipo los problemas
empezarán a desaparecer poco a poco. Se
trata de que el cliente se involucre realmente en todo el proceso, de tal modo que
mientras se desarrolla el software se resuelvan las dudas, y el producto se ajuste mejor
a los cambios que requieran las organizaciones. Esta colaboración dispara la
productividad, y la calidad del producto en cuanto a lo que se espera de parte de los
stakeholders o personas involucradas.
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.

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. La calidad
del trabajo individual y de equipo depende de la motivación del equipo y del gusto por
hacer lo que se tiene que hacer. Esa motivación se logra si hay claridad de las metas, y
si se cuenta con el espacio, tiempo, y recursos necesarios. El acompañamiento a los
equipos por parte de un líder servicial, alguien que los apoye en
momentos de situaciones bloqueantes, es definitivo. El equipo se
tiene que sentir respaldado. Adicionalmente el equipo tiene que
sentir que está empoderado del asunto para poder hacer la tarea
bien hecha. Se debe generar mucha confianza dentro de los
equipos y los miembros del mismo no deben sentir que necesitan
personas de afuera para hacer bien hecho su trabajo. Toda persona
ajena al equipo y que tenga control de una variable que pueda
afectarlo, como es el caso de impedimentos que se pueden
presentar, deben ser vigilados de cerca por un líder que esté atento
a gestionarlo y que evite que el equipo sea afectado.

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.

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. En la
cúspide de la escala de la riqueza de las comunicaciones
está la comunicación presencial cara a cara; aquella que
nos deja ver la cara del otro e identificar sus expresiones,
sus deseos, sus desaciertos; aquella que nos permite
identificar si la persona está o no está realmente
involucrada en una comunicación; esa misma que nos
deja saber si la persona realmente se siente cómoda con
nosotros, o está triste o feliz; esa que nos deja identificar
el tipo de reacciones que pueden estar teniendo nuestras palabras. Los individuos
interactúan y eso supera cualquier tipo de documento escrito o de chat.
Por otro lado, una comunicación usando emails es ineficiente: para discutir una idea
muchos emails pueden ser requeridos, y mucho tiempo también, incluso días podrían
requerirse. Usando una conversación cara a cara, el mismo propósito podría ser
alcanzado en solo algunos minutos.

7. El software funcionando es la medida principal de progreso.

El software funcionando es la medida principal de

progreso. No son los porcentajes de los cronogramas
los buenos para hablar sobre el avance de su proyecto.
Las líneas base de cronogramas comparadas contra lo
ejecutado, tampoco son la medida. Si quiere saber si su
producto va bien, pregúntele a los usuarios. Para poder
preguntarle a los usuarios, ellos deben poder haber
usado el sistema, y si usted usa un ciclo de vida donde
el producto se entrega al final, es imposible conocer la
medida real del progreso, y sólo al final sabrá si el software está bien o no.

8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores,

desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante
de forma indefinida.

Los procesos ágiles promueven el desarrollo sostenible. Los promotores,

desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante
de forma indefinida. Los atletas de 100 metros, saben correr los 100 metros. Los atletas
de 400 metros, saben correr 400 metros. Lo mismo pasa con un maratonista de 42
kilómetros, que sabe cómo correr 42000 metros y que muy probablemente no tenga las
habilidades para ganar una competencia de 100 metros que requiere de otro tipo de
conocimientos, prácticas, y patrones de trabajo físico. Cada corredor en su especialidad
sabe cómo comienza, cómo llega a su interludio y cómo finalizan la carrera. Montan su
estrategia, y dicha estrategia se aplica sin que les modifiquen la longitud de la carrera.
Saben dónde comienza el estrés, si lo hay, pero también lo saben moderar e incluso
eliminar. Comprenden que no tendrán obstáculos si todo anda bien y manejan la carrera
bajo condiciones normales.

En el caso de los equipos de desarrollo de software pasa algo similar. También pueden
montarse en un tren o ritmo sostenido basado en iteraciones del mismo tamaño, de tal
forma que entre las reuniones de planeación y revisión siempre haya el mismo lapso, lo
que permitirá alta predictibilidad del proceso.

La sostenibilidad alude además a equipos que tienen

un ritmo libre de impedimentos, o al menos con
impedimentos muy controlables y potencialmente
predecibles. Y como es de esperarse, el equipo debe
tener un ritmo sostenible con un estrés moderado. Un
ejemplo interesante es el estrés que se genera
finalizando los ciclos de desarrollo. Este pico de estrés
es muy común, pero es mucho menor entre más
pequeñas son las iteraciones de trabajo, por lo que se
hace más controlable, lo que permitirá tener una mejor salud mental y física en el equipo.
Otro ejemplo son los ciclos de entrega internos de las historias de usuario, y los ciclos
de prueba que a veces se ve dentro de los equipos: en la medida en que el equipo tenga
claro cómo operan dentro de una ventana de tiempo, más fácil será establecer un ritmo
constante de forma indefinida.

9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

La atención continua a la excelencia técnica y al buen

diseño mejora la Agilidad. Realmente no se gana mucho
con tener un norte de producto bien definido, si no se vigila
frecuentemente la calidad técnica y las prácticas técnicas que
se usan dentro del equipo de desarrollo.

Debemos procurar siempre alcanzar la excelencia técnica, y

eso se logra a través de la constante inspección de la forma
en que hacemos el trabajo. Por ejemplo, las pruebas
manuales podrían estar automatizadas o podríamos pensar
en revisiones pares. Por otro lado, el buen diseño es muy
importante, ya que de él también depende la calidad técnica del producto final.
10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es
esencial.

La simplicidad, o el arte de maximizar la cantidad de trabajo

no realizado, es esencial. Enormes documentos llenos de
información que nadie lee es un desperdicio común en muchas
empresas. También lo es todo software no usado por los usuarios,
porque realmente se hizo pensando en que sería útil algún día y
hoy se sabe que no lo es y que se perdió la inversión. Largas
reuniones que nos llevaron a una especificación concreta.
Diseños enormes que no hacían falta. Todos estos problemas son
síntoma de que no hay un análisis del verdadero valor o retorno
de la inversión para la empresa, lo que finalmente nos deja
software de baja calidad en nuestras manos.

Debemos hacer software de forma evolutiva para garantizar que sabremos darnos
cuenta cuándo estamos haciendo software de valor para la empresa, y no incurrir en
malgastos de software sin valor. Debemos ser cuidadosos de dónde aplicamos
demandas de procesos establecidos, y determinar cuándo dichos procesos son una
carga innecesaria para la empresa. Debemos ser muy críticos para poder identificar
aquellos puntos donde el desperdicio se puede dar o se dará. Todo esto hará que
hagamos el trabajo mucho más simple.

11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-

organizados.

Las mejores arquitecturas,

requisitos y diseños emergen de
equipos auto-organizados. Los
equipos autoorganizados son más
poderosos que los individuos. Si bien
es cierto que todo conocimiento de
experto puede ser útil, hay que
considerar que muchas personas
técnicamente efectivas pueden
propiciar mejores diseños y
arquitecturas si trabajan en equipo.
Igualmente si se trabaja en equipo los
requisitos son más exitosos a si los
requisitos aparecen de forma aislada,
ya que si los requisitos son refinados en equipo garantizaremos que se conocen y
entienden mejor.
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.

A intervalos regulares el equipo reflexiona sobre cómo ser

más efectivo para a continuación ajustar y perfeccionar su
comportamiento en consecuencia. Los japoneses hablan del
“cambio bueno” o kaizen. En occidente lo llamamos mejora
continua. No importa cómo lo llamemos, la idea es inspeccionar
frecuentemente para ver cómo estamos haciendo el trabajo, y
sobre la base de los resultados de dicha inspección, actuar en
consecuencia.
 QUE ES SCRUM, DE DONDE VIENE, CÓMO SE DESARROLLA Y QUE
INDICADORES USAR

1. Que es Scrum: Es un marco de gestión ágil que gira alrededor de un modelo de

control empírico. Sus iteraciones enmarcadas en tiempos fijos (timeboxed), son
protegidas contra intervenciones externas y presentan características de ciclo de
vida iterativo e incremental.

2. Un poco de Historia de Scrum

 En 1986, El primer registro del término SCRUM en el desarrollo de producto en
el artículo “The New New Product Development Game.” publicado en el Harvard
Business Review. Los autores, Takeuchi, Hirotaka and Nonaka, Ikujiro aplicaron
estas metodologías en empresas como Fuji-Xerox, Canon, Honda, NEC, Epson,
Brother, 3M, Xerox, and Hewlett-Packard. De aquí toman el nombre Jeff
Sutherland y Ken Schwaber en 1995. El término ‘Scrum’ refiere al Rugby para
destacar la importancia del trabajo en Equipos para el éxito en el desarrollo.

 En 1993: Jeff Sutherland crea el framework de Scrum, tomando el término

"Scrum" del paper de Takeuchi and Nonaka (1986), adaptándolo para el desarrollo
de Software.
 En 1995: Jeff Sutherland y Ken Schwaber popularizan Scrum tras hacer público
el paper "The SCRUM Development Process" en la conferencia OOPSLA de
Texas. Mike Beedle fue uno de los primeros en adoptarlo y llevarlo a
organizaciones. [ref]. Las primeras empresas donde se implementó y refinó
Scrum fueron Individual, Inc., Fidelity Investments, and IDX (ahora GE Health).

 En 1995: Jim Coplien y Larry Constantine separadamente introducen la idea

de Programación en Pareja (Pair Programming)

 En 1999: Kent Beck introduce la metodología de desarrollo Extreme

Programming (XP), el empleo de User Stories, la Integración Continua, Pair
Programming y otras prácticas usadas ampliamente en el desarrollo ágil.

 2001: 17 agilistas se juntaron a discutir y firmar el Manifesto Ágil con los cuatro
valores y doce principios.

2001: Se publica el primer Libro sobre Scrum: "Agile Software Development with
Scrum". (Ken Schwaber, Mike Beedle)

 2002: Ken Schwaber, Mike Cohn y Esther Derby fundan la ScrumAlliance y crean
la Certificación de Scrum Master. Además se crean las técnicas de Test Driven
Development (Kent Beck) y Planning Poker (James Grenning)

 2003: Mary and Tom Poppendieck publican el libro Lean Software

Development llevando los Principios de Lean al desarrollo de Software.

 2006: Jeff Sutherland funda la empresa Scrum.inc.

 2008: Surge la certificación de Scrum Product Owner (CSPO)

3. Que es un modelo de control empírico de procesos: El marco de trabajo Scrum

se basa en la inspección y en la adaptación continua con base en los resultados
que se vayan obteniendo en el contexto del proyecto. A esto se le llama Control
empírico de procesos, y este nos habla de tres pilares: Inspección, Adaptación y
Transparencia.
4. Manifiesto de desarrollo ágil: En febrero de 2001 diecisiete expertos en
metodologías “livianas” se reunieron. El propósito era tratar de llegar a un
consenso sobre las maneras de trabajo que estaban utilizando. El grupo se
autodenominó “The Agile Alliance” (la Alianza Ágil). En esta reunión se definió lo
que se conoce como el Manifiesto para el Desarrollo Ágil de Software y los doce
principios que respaldan el manifiesto.
5. Valores SCRUM:

 Foco: El equipo está lo más concentrado posible en una tarea a la

vez. El cerebro no tiene procesamiento en paralelo. Para hacer bien
una tarea, deberemos estar concentrados en ella y no en varias a la
vez.

 Respeto: Tratarnos a nosotros mismos y a otros con

dignidad, y mantener un deseo mutuo de éxito y de ganar
experiencia. Mientras trabajamos juntos, compartimos éxitos
y fracasos, nos respetamos mutuamente, y nos ayudamos a
ser merecedores del respeto.

 Compromiso: Un equipo que tiene claro lo que tiene que hacer

puede comprometerse. Necesitamos establecer metas claras
para las iteraciones (sprints), de tal modo que podamos saber
qué es posible hacer y qué no, y de ese modo establecer un
compromiso claro.

 Coraje: Hay varios tipos de coraje que se pueden evidenciar en

el trabajo en equipo. El coraje de hablar con transparencia con
el resto del equipo, y en particular de ser muy claro siempre con
el Product Owner.
 Apertura: Los equipos deben ser muy abiertos al cambio,
y en particular a la adopción de nuevas tecnologías.

6. ROLES SCRUM:

 Rol - Scrum Master (Líder del proyecto): Es la persona que vela por la mejora
continua en los equipos de trabajo. Busca además que el equipo entienda el
proceso y lo aplique correctamente. Busca estrategias que incrementen la calidad
del equipo. Y es el responsable de asegurar que Scrum es entendido y adoptado
por la organización, el equipo (team) y el dueño del producto (product owner).
Algunas características que debe tener son:
 Ser un líder que está al servicio del Equipo Scrum.
 Ayudar a las personas externas al Equipo Scrum a
entender qué interacciones con el Equipo Scrum
pueden ser de ayuda y cuáles no.
 Ayudar a todos a modificar las interacciones para
maximizar el valor creado por el Equipo Scrum.

 Product Owner (Dueño de Producto): Es el responsable de maximizar el valor

del producto y del trabajo del Equipo de Desarrollo. El Dueño de Producto es la
única persona responsable de gestionar la Lista del Producto (Product Backlog).
La gestión de la Lista del Producto incluye:
 Expresar claramente los elementos de la Lista del Producto;
 Ordenar los elementos en la Lista del Producto para alcanzar los objetivos y
misiones de la mejor manera posible;
 Optimizar el valor del trabajo desempeñado por
el Equipo de Desarrollo;
 Asegurar que la Lista del Producto es visible,
transparente y clara para todos, y que muestra
aquello en lo que el equipo trabajará a
continuación; y,
 Asegurar que el Equipo de Desarrollo entiende
los elementos de la Lista del Producto al nivel necesario.
 Team (Equipo): Son las personas que se encargan de entregar un incremento de
producto “Terminado”, que potencialmente se pueda poner en producción, al final
de cada Sprint y con calidad.
Los Equipos de Desarrollo tienen las siguientes características:
 Son autoorganizados. Nadie (ni siquiera el Scrum Master) indica al Equipo de
Desarrollo cómo convertir elementos de la Lista del Producto en Incrementos
de funcionalidad potencialmente desplegables;
 Los Equipos de Desarrollo son multifuncionales, contando como equipo con
todas las habilidades necesarias para crear un Incremento de producto;
 Scrum no reconoce títulos para los miembros de un Equipo de Desarrollo,
todos son Desarrolladores, independientemente del trabajo que realice cada
persona; no hay excepciones a esta regla;
 Scrum no reconoce sub-equipos en los
equipos de desarrollo, no importan los
dominios particulares que requieran ser
tenidos en cuenta, como pruebas o análisis de
negocio; no hay excepciones a esta regla; y,
 Los Miembros individuales del Equipo de
Desarrollo pueden tener habilidades
especializadas y áreas en las que estén más
enfocados, pero la responsabilidad recae en
el Equipo de Desarrollo como un todo.

7. EVENTOS SCRUM:

 Sprint (Iteración): Es cada una de las

permanentes iteraciones del desarrollo de
incremento de producto que son
delimitadas por una franja de tiempo fija
entre 1 y 4 semanas.

 Sprint Planning (Planeación): Es una reunión donde se

llevan a cabo dos actividades clave: la primera actividad es
determinar qué se construirá, y la segunda cómo se
construirá.
 Daily (Reunión diaria): Es una reunión donde todo
el equipo de desarrollo se actualiza sobre las
actividades que se desarrollaron el día anterior, las
que están en curso y las que se van a desarrollar en
pro de alcanzar los objetivos del sprint, y así conocer
la tendencia del progreso que podría estar por
encima de lo esperado, o por debajo de lo esperado.

 Sprint Review (Revisión): Al final del Sprint se lleva a cabo una Revisión de
Sprint para inspeccionar el Incremento y adaptar la Lista de Producto si fuese
necesario.

 Sprint Retrospective (Restrospectiva): La retrospectiva de Sprint tiene lugar

después de la Revisión de Sprint y antes de la siguiente Reunión de
Planificación de Sprint. El propósito de la Retrospectiva de Sprint es:
 Inspeccionar cómo fue el último Sprint en
cuanto a personas, relaciones, procesos y
herramientas;
 Identificar y ordenar los elementos más
importantes que salieron bien y las posibles
mejoras; y,
 Crear un plan para implementar las mejoras a
la forma en la que el Equipo Scrum
desempeña su trabajo
 Refinement (Refinamiento): Es una actividad que ocurre durante todo el
proyecto de Scrum. Esta actividad incluye (pero no está limitada a):
 Mantener ordenado el Backlog del Producto
 Eliminar ideas que ya no son importantes
 Agregar o promover elementos que surgen o se
vuelven importantes
 Dividir elementos en elementos más pequeños
 Unir elementos en elementos más grandes
 Estimar elementos

8. ARTEFACTOS SCRUM:

 Product Backlog (Lista de Producto): Es una lista dinámica de

necesidades que se va detallando, modificando y ampliando a
medida que se sabe qué es lo que realmente necesita el negocio
en su quehacer frente a su operación para ser más competitiva de
cara al mercado.

 Sprint Backlog (Lista de producto del Sprint): Es toda la

funcionalidad que el equipo de desarrollo predijo que alcanzaría
a adicionar al incremento de producto del sprint, junto con todas
las tareas que el equipo de desarrollo estima necesita para
cumplir el objetivo de tener la funcionalidad cumpliendo con la
definición de terminado o hecho.

 Increment (Incremento de Producto): El propósito en un sprint

es agregar valor al negocio a través de la adición de nueva
funcionalidad al producto construido en sprint anteriores, o
simplemente se agrega valor a través de la mejora del producto,
o ambas. Siempre estamos teniendo un producto en permanente
evolución.
.
9. Algunas métricas que pueden ser usadas

 Métricas de productividad y efectividad de la entrega

 Velocidad con que se completan objetivos/requisitos en cada iteración.
Idealmente debería aumentar con respecto al tiempo (productividad). También
permite ir extrapolando la fecha de finalización del proyecto en función de
cuando se vaya a completar todo su alcance.
 Tiempo de entrega de un requisito tras su petición o Lead Time (Time to
Market, tiempo de servicio), en función de la criticidad de la petición (urgente,
etc.) y cumplimiento de los Acuerdos de Nivel de Servicio (ANS / SLA).
 Urgencias y prioridad/valor de los requisitos completados, para comprobar si
existe desalineamiento con los objetivos del proyecto y/o la estrategia de la
organización.

 Métricas de resultados del proyecto

 Velocidad con que se aporta valor al negocio (desde el punto de vista del
cliente).
 Requisitos completados en la iteración.
 Cambios incorporados y requisitos añadidos sobre el alcance inicial del
proyecto.
 Número de requisitos completados respecto al total de requisitos (métrica
que también permite observar cambios de alcance).
 Desviación de resultados de proyecto respecto a planificación inicial.

 Métricas de situación financiera

 Retorno de Inversión (ROI) pendiente, el valor pendiente respecto al costo
pendiente, para saber cuándo finalizar el proyecto.
 Presupuesto disponible y/o presupuesto gastado.
 Desviación financiera respecto a la planificación inicial.
 Métricas de calidad
 Expectativas: Satisfacción del cliente / usuario, respecto a los resultados
del proyecto y a la colaboración con el equipo y Ambiente en el equipo.
 Calidad funcional: Incidencias (defectos encontrados por el cliente o
usuarios del producto). Errores (defectos detectados internamente, bugs),
por estado y por criticidad y Cobertura de las pruebas.

 Métricas de impedimentos y mejora continua

 impedimentos: considerando las dependencias o sinergias con otros
equipos o proyectos, la implicación del cliente, los problemas tecnológicos,
el resultado de las retrospectivas, etc.
 Lecciones aprendidas.
 Actividades de mejora a planificar (comunicaciones, formaciones, soporte,
herramientas, etc.).
 Situaciones anómalas: sobreesfuerzo, requisitos no completados,
interrupciones.

10. Herramientas Virtuales

 Kunagi - http://kunagi.org/
 ScrumDo - https://www.scrumdo.com/
 SprintoMeter - http://sprintometer.com/
 IceScrum - https://www.icescrum.com/?lang=es
 Pango Scrum - http://pangoscrum.com/
 QUE ES, PARA QUE SIRVE Y COMO SE DESARROLLO KANBAN

1. Que es Kanban: Es una palabra japonesa que significa “tarjetas

visuales” (kan significa visual, y ban tarjeta).
El sistema Kanban como tal surgió en Toyota, el fabricante japonés de automóviles,
para organizar mejor su producción de vehículos dividiendo el proceso en
fases bien delimitadas que se tenían que cubrir correctamente para pasar a la
siguiente fase, garantizando así un producto de calidad. De este sistema, aplicado a
la industria de la automación, surgió el método Kanban, ideado por David J.
Anderson y que adapta la filosofía original al desarrollo de software, un proceso con
muchos puntos en común con el industrial, con diferentes fases, equipos de trabajo y
el requisito de que cada pieza del programa a crear funcione correctamente y sea de
la mejor calidad posible. El método Kanban en su versión moderna aplicada al
software se usó por primera vez en Microsoft, y desde entonces ha sido aplicado
en cientos de proyectos de todo el mundo.

2. Para que Sirve: Esta técnica se utiliza para controlar el avance del trabajo,
en el contexto de una línea de producción. Su objetivo es gestionar de manera
general como se van completando tareas.

3. Principios de la Metodología Kanaban

 Calidad garantizada. Todo lo que se hace debe salir bien a la primera, no hay
margen de error. De aquí a que en Kanban no se premie la rapidez, sino la calidad
 final de las tareas realizadas. Esto se basa en el hecho que muchas veces cuesta
más arreglarlo después que hacerlo bien a la primera.
 Reducción del desperdicio. Kanban se basa en hacer solamente lo justo y
necesario, pero hacerlo bien. Esto supone la reducción de todo aquello que es
superficial o secundario (principio YAGNI).
 Mejora continua. Kanban no es simplemente un método de gestión, sino también
un sistema de mejora en el desarrollo de proyectos, según los objetivos a
alcanzar.
 Flexibilidad. Lo siguiente a realizar se decide del backlog (o tareas pendientes
acumuladas), pudiéndose priorizar aquellas tareas entrantes según las
necesidades del momento (capacidad de dar respuesta a tareas imprevistas).

4. Cómo aplicar kanban: La aplicación del método Kanban implica la

generación de un tablero de tareas que permitirá mejorar el flujo de trabajo y
alcanzar un ritmo sostenible. Para implantar esta metodología, deberemos tener
claro los siguientes aspectos:

 Definir el flujo de trabajo de los proyectos: para ello, simplemente deberemos

crear nuestro propio tablero, que deberá ser visible y accesible por parte de todos
 los miembros del equipo. Cada una de las columnas corresponderá a un estado
concreto del flujo de tareas, que nos servirá para saber en qué situación se
encuentra cada proyecto. El tablero debe tener tantas columnas como estados
por los que pasa una tarea, desde que se inicia hasta que finaliza (p.e: diagnóstico,
definición, programación, ejecución, testing, etc.).

 Determinar el límite de “trabajo en curso”.: Quizás una de las principales ideas

del Kanban es que el trabajo en curso (Work In Progress o WIP) debería estar
limitado, debe existir un número máximo de tareas a realizar en cada fase. A esto,
se le añade otra idea que, por muy obvia que pueda parecer, la práctica nos
demuestra que no es así: no se puede abrir una nueva tarea sin finalizar otra.

 Control del Flujo: Además de visualizar el flujo de trabajo hay que controlar su
funcionamiento, ver en todo momento si las piezas están funcionando o si alguien
tiene problemas y solucionarlos.

 Inspección y Adaptación: Uno de los pilares del método Kanban es la mejora

constante. En este sentido, la mejora debe ser acordada en equipo, aportando la
experiencia de todos los miembros del equipo.

5. Metricas Recomendadas:

 Lead Time: Es el tiempo que se tarda en terminar cada tarea. El “lead time” cuenta
desde que se hace una petición hasta que se hace la entrega. Con el “lead time”
se mide lo que ven los clientes y lo que esperan.

 Cicle Time: Mide desde que el trabajo sobre una tarea comienza hasta que
termina. Con el “cycle time” se mide más el rendimiento del proceso.

 Medir el tiempo en cada fase del flujo, para ver oportunidades de mejora.
6. Herramientas virtuales

 Kanban Tool - http://kanbantool.com/

 KanbanFlow - https://kanbanflow.com/

 Kanbanize - https://kanbanize.com/?a=6&utm_expid=117602265-

20.57PkQaRZRAmjuljlUB4Fpw.1

 Trello - https://trello.com/

 KanbanPad

 LeanKit - https://leankit.com/
QUE ES, PARA QUE SIRVE Y COMO SE DESARROLLA EL IMPACT MAPPING

1. Que es Impact Mapping: Es una novedosa técnica de planificación y estrategia

creada por Gojko Adzic, un reconocido consultor en Ingeniería de Software. Esta
técnica tuvo una gran repercusión en la comunidad Agile, con especial aplicación
en la iteración 0 de los proyectos o bien antes de su inicio.

2. Para qué sirve el Impact Mapping: Es una herramienta fundamental que

propone concentrar esfuerzos en lo realmente importante, en hacer las preguntas
correctas para lograr determinar con precisión qué es aquello que debe
conseguirse para lograr las metas deseadas. Y además permite generar la versión
inicial de un Product Backlog.

3. Como se hace: Es una reunión donde deben estar todos los interesados y se deben
hacer las preguntas correctas para lograr determinar con precisión qué es aquello que
debe conseguirse para lograr las metas deseadas. Todo se combina, luego, a través de
una visualización muy simple y efectiva de la información que permite realizar un análisis
adecuado. Cuatro preguntas conducen la técnica:
 ¿Por qué?
 ¿Quién?
 ¿Cómo?
 ¿Qué?

 Lo primero es responder por qué se está haciendo esto. Es la meta u objetivo

principal a conseguir. Es importante dedicar el tiempo necesario para asegurar
que sean SMART.

 Luego, se debe responder quién puede lograr el efecto deseado, quién lo

puede obstruir, quién se verá beneficiado (es decir, el conjunto completo de
los stakeholders).

 A continuación, se responde cómo ayudarán los actores identificados en el

punto anterior a lograr las metas, ¿Cómo debería cambiar el comportamiento
de los actores? ¿Cómo nos podrían ayudar a alcanzarlos? o de lo contrario,
¿Cómo podrían causar obstrucción en el cumplimiento de los objetivos?

 Finalmente, se responde qué puede hacer la organización o empresa para

apoyar y consolidar los cambios necesarios para lograr la meta deseada. Se
puede incluir funcionalidad de software, actividades que no tengan nada que
ver con el producto que estamos construyendo en la medida que puedan
ayudar a alcanzar los objetivos, cambios a procesos, etc.

Toda esta información se estructura visualmente con un estilo de árbol y

ramificaciones, como lo muestran las siguientes imágenes.
4. Ejemplo: Alcanzar 1 millón de jugadores en un video juego.

5. Herramientas virtuales

 Mindmup - https://app.mindmup.com/
 QUE ES, PARA QUE SIRVE Y COMO SE DESARROLLA UN
INCEPTION

1. Que es Agile Inception: También conocida como Inception Deck o

simplemente Inception, es un conjunto de dinámicas orientadas a enfocar a todas
las personas involucradas en un proyecto hacia un mismo objetivo, reduciendo
muchas de las incertidumbres, ayudando a explicitar los riesgos más evidentes y
poniendo en común las expectativas de todos. Se puede emplear al iniciar
cualquier tipo de proyecto, no sólo de software.

2. Para que Sirve: Agile Inception no es una garantía para conseguir el consenso,
pero ayuda mucho a conseguirlo. De hecho, uno de los resultados esperables de
la misma es que el proyecto no es viable o demasiado arriesgado para iniciarlo.

3. Como se hace: Es una reunión que requiere la participación continuada de

muchas personas durante el tiempo que dure. La logística (comida, bebida,
descanso, etc) es muy importante para conseguir que todos los participantes
puedan aportar en todas las actividades. Para ayudar a que las actividades fluyan
es conveniente contar con un facilitador.

Las actividades que se desarrollan en la reunión son:

 ¿Por qué estamos aquí?: Tenemos que saber por qué se

hace, quiénes son los clientes o usuarios, ponernos en su
situación y validar con ellos la respuesta.

 The Elevator Pitch: Esta técnica consiste en ponernos en la

situación que estamos en un ascensor con un posible
cliente y tenemos treinta segundos para contar la idea de
nuestro producto, de esta manera aprovecharemos el
tiempo y destacaremos qué es nuestro producto, para
quién es y por qué alguien lo quiere comprar, comunicando
así la esencia de nuestra idea.
 Diseñar la caja de tu producto: Esta técnica se basa en
empezar con las siguientes preguntas: Si pudiéramos
comprar nuestro producto de la estantería de un centro
comercial, ¿cómo sería la caja? Y lo más importante
¿podríamos comprarlo?. Seguidamente tenemos que tener
en mente a nuestro cliente una vez más y pensar cuales son
las razones por las que va a comprar nuestro producto, las
características más destacas del mismo y con base a eso destacar los beneficios
de nuestro producto.

 La lista de los NO: Con esta actividad vamos a establecer las

expectativas y a centrarnos en el alcance de nuestro proyecto,
partiendo de las ideas tanto del equipo como del cliente. Se
trata de crear tres listas de forma visual: La primera contendrá
lo que está a nuestro alcance, la segunda lo que dejamos
fuera, la tercera se compone de las expectativas que todavía
no están en ninguna de las listas anteriores.

 Conocer a la comunidad: Se trata en hacer un símil con una

comunidad de vecinos, tenemos que conocer a todos y cada
uno de ellos, porque nunca sabemos que vamos a necesitar
de ellos. La mayoría de las veces en nuestros proyectos hay
más personas implicadas de las que pensamos, y es mejor
establecer pronto las relaciones entre todos y generar
confianza en las mismas que solicitar ayuda sin haber tenido
contacto previo.

 Muestra la solución: Es importante mostrar la solución y

asegurarnos que todo el mundo está de acuerdo con la
solución, así como la forma de trabajar y la tecnología a utilizar.
 De esta forma tratamos el riesgo y los límites de nuestro
proyecto con todo el equipo.
 ¿Qué nos quita el sueño por las noches? – Los miedos: Una
vez que hemos llegado a este punto tenemos que conocer y
tratar las preocupaciones porque con ellas llegaremos a
afrontar los riesgos del proyecto, así como dejar claro qué
necesitamos para el éxito del mismo definiendo nuestros
retos.

 El tamaño de nuestro proyecto Si medimos el tamaño de

nuestro proyecto en tiempo, nosotros no vamos a poder decir
exactamente cuántos días va a durar pero sí que podemos
hacer una aproximación. Para ello necesitamos hacer uso de
la estimación y del Roadmap para ver si es factible hacerlo
en un periodo de tiempo razonable.

 Muestra con claridad lo que se va a dar: Se trata de poner

sobre la mesa todos los temas importantes y decisivos en
algún momento del proyecto, me refiero a calidad, tiempo,
dinero, alcance…
Imaginarnos diferentes situaciones y hacernos preguntas del
estilo: ¿Qué es lo mejor cuando nos enfrentamos a
demasiadas cosas y no hay tiempo?

 Cuánto Cuesta: Las necesidades del proyecto respecto al

equipo necesario y al tiempo tienen que ser factores
conocidos. En este punto vamos a estudiar si es factible todo
lo que hemos tratado en las actividades anteriores.
 QUE ES, PARA QUE SIRVE Y COMO SE DESARROLLO EL USER STORY
MAPPING

1. Que es el User Story Mapping: Jeff Patton ideó una herramienta muy usada en
metodologías ágiles llamada User Story Mapping, que permite generar una
representación visual del sistema completo. Ofrece una vista general de todas las
funcionalidades que lo componen de punta a punta. Permite identificar las
Historias de Usuario faltantes en el Backlog, planificar Releases partiendo en
rebanadas (Slicing), visualizar cómo se distribuyen las funcionalidades de acuerdo
a las diferentes áreas del sistema.

2. Para qué sirve: Al construir el User Story Map al principio del proyecto, sirve para
tomar decisiones y provocar muchas conversaciones que posteriormente serán
útiles durante la construcción. Durante el resto del proyecto es muy útil para no
perder el horizonte sobre lo que se pretende construir.
También se puede implementar para:
 Descubrir el proceso.
 Identificar las funcionalidades del sistema.
 Segmentar el product backlog en releases.

Un buen momento para hacer el User Story Map es al final de la Agile Inception

3. Como se construye: Para la construcción resulta fundamental pensar todo el

proceso desde el punto de vista del usuario y sus objetivos con nuestro producto;
nunca desde el lugar de Product Owner o de quienes construimos el producto u
ofrecemos el servicio.
  Backbone - Procesos: Identificar las grandes etapas en las que se divide
nuestro sistema. Por ejemplo, en un sistema de venta online, podría ser:
llegar al website, búsqueda de producto, compra/pago y entrega.

 Actividades: Identificar todas las actividades que debe o puede realizar el

usuario en nuestro sistema, desde que llega al mismo hasta que finaliza su
proceso. Ordenarlas de manera secuencial de manera horizontal. Esta
secuencia conforma la cadena de valor de nuestro sistema (Value Stream).

 Historias de Usuario o Requisitos o Tareas: Identificar las distintas

maneras que nuestro sistema puede ofrecer para que el usuario realice
cada una de las actividades identificadas. Por ejemplo, para la actividad
"encontrar producto" podría ser: navegar el catálogo, usar el cuadro de
búsqueda, sugerencias de productos, etc.

 Priorización: Cada columna debajo de cada Activity funciona como un

backlog que debe estar priorizado por relevancia.

El Story Map se puede implementar directamente sobre la pared con Post-its y

cinta de enmascarar. La única limitante es que queda fijo en una pared y
requiere reservarse este espacio para trabajar con la herramienta. Esta es la
forma más recomendada de implementarlo.

4. Algunos Conceptos:

 The Walking Skeleton: Con las activities y la primera fila de User Stories
obtenemos lo que Jeff Patton denomina "The Walking Skeleton" (el esqueleto que
camina) porque está completo y funciona, aunque sea en su forma más elemental.
Nuestro producto en este estado puede ser identificado como la versión MVP
(Minimum Viable Product).
 Releases (Entregas): El User Story Mapping permite planificar las próximas
versiones o releases del producto representando de manera visual en qué partes
de nuestros sistemas estamos dedicando mayor esfuerzo para generar
Incremento de Producto.

 El Poder Visual: El User Story Map permite a cualquier stakeholder comprender

qué funcionalidades ya fueron realizadas, cuáles se están trabajando en este
momento y cuáles son las próximas funcionalidades para todo el producto y la
organización.

5. Herramientas Virtuales: Al igual que los tableros de tarea de Kanban y Scrum

(Taskboards), se puede implementar también con software. Sin embargo, debería
ser la última alternativa a elegir, ya que tienen una exposición más reducida y el
potencial que tienen las herramientas visuales y colaborativas se ve muy
disminuido con herramientas abstractas.

 CoardBoard (https://cardboardit.com/) es una herramienta online para

construir User Story Maps de manera colaborativa.
 Real Time Board (https://realtimeboard.com/) no es una herramienta
específicamente diseñada para User Story Map pero sirve perfectamente.
 Agile User Story Map es un plugin que se integra automáticamente con Jira
 Stories on board http://storiesonboard.com/