Taller Marco de Trabajo Scrum.

ACTIVIDADES:

Los equipos presentarán y sustentarán cada jueves el taller de las actividades de cada Sprint
(Incrementos Semanales de su Proyecto). Se sugiere utilizar una herramienta como Trello para
el seguimiento y utilización del Kanban. La presentación debe incluir el nombre del proyecto,
los integrantes (Equipo y Scrum Master). Al finalizar la segunda fase se deberá presentar todos
los incrementos de los sprints y la Retrospective aplicado al proyecto planteado, con sus
comentarios de qué funcionó bien en cada sprint y qué consideran se puede mejorar.

De acuerdo a lo conversado en clases yo haré el rol de Product Owner y utilizaré las historias
de usuario como herramienta para aplicar SCRUM.

Para las Historias de Usuario, utilizaré la regla de INVEST de la siguiente forma:

Independientes entre sí, para poder llevarlas a cabo en el orden establecido.

Negociables con el Product Owner para establecer los limites adecuados, la parte de
conversación de una historia es esencial. Los Scrum Master podrán comunicarse vía chat.

Valor para el usuario, el PARA es fundamental. Se ha de entender la funcionalidad siempre y la

tiene que entender todo el Equipo de Desarrollo, nuestro Usuario será un posible inversor.

Estimable. El Equipo de Desarrollo que la vaya a recoger, debe ser capaz de estimar el esfuerzo
que supone realizarla en puntos de Sprint.

Small de un tamaño que el equipo de desarrollo pueda asumir en un sprint semanal. Y a ser
posible que el equipo pueda asumir varias de las tareas que se requieran dentro del sprint.

Testeable para poder confirmar que está correctamente implementada. O dicho de otra forma
con los Criterios de aceptación establecidos.

Adjunto encontrarán una plantilla en Excel con las primeras historias de usuario y el Burndown
para que el equipo le asigne puntos y verifiquen el desarrollo de los Sprints hasta el fin de la
fase.

Primer Sprint tiene por objetivo: “Aprender y aplicar el Impact Mapping para seleccionar y
formular su proyecto”. El Primer Sprint que se presenta el jueves 21 de mayo, debe contener
los siguientes requerimientos: (Idea de proyecto de preferencia una STARTUP. Justificar.

1. El problema debe estar debidamente evidenciado.

2. El objetivo del proyecto debe estar formulado siguiendo SMART (Específico, Medible,
Alcanzable, Relevante y Temporal.)
3. Explicar las Personas (Involucrados, comprometidos...todos los stakeholders que
pueden afectar o ser afectados por el proyecto.
4. Explicar los Impactos positivos y/o negativos para cada involucrado.
5. Explicar la mayor cantidad de “entregables” para lograr los impactos deseados.
Busque la mayor cantidad de opciones.
Sugerencia: Utilizar la herramienta Inception Deck 10. Para mayor detalle se usará la
plantilla en ppt.

El Segundo Sprint: Determinación del Tamaño y Localización para su proyecto.

Fecha de presentación: 28 de mayo del 2020

FUNDAMENTO TEORICO.

Realizar el desarrollo del Proyecto usando Scrum tiene por objetivo que los participantes
interioricen Scrum y la agilidad como método de trabajo para conocerlo, aprenderlo y aplicarlo
en el desarrollo de sus interacciones en equipo.

Los Sprint
Antes de empezar se deben conformar los equipos de trabajo, equipos, que serán fijos durante
toda la asignatura, como marcan las buenas prácticas del Peopleware… son equipos
multifuncionales de menos de 5 personas.
Los Sprints serán de una semana. Según la duración de la fase, esto me da para, normalmente,
4 Sprints por fase. Los Sprints requieren una explicación de los requerimientos que como
Product Owner se irán conversando en cada semana y que luego serán el objetivo del Sprint.
Cada Sprint tiene su objetivo, por ejemplo, “Aprender y aplicar el Impact Mapping para
seleccionar y formular su proyecto”.

El Product Backlog
Al comienzo de cada Sprint, la primera clase de práctica docente es una “Sprint Planning”.
Durante ese Sprint Planning, explicaremos las historias de usuario a completar durante el
Sprint que empieza.
Para interiorizar la diferencia entre proyectos tradicionales en cascada y un ciclo de vida ágil,
entre requisitos cerrados, tipo especificación de requisitos contractuales, e historias de
usuario, que el cambio es bienvenido frente al inmovilismo de una gestión de proyectos
tradicional, y otros tantos, no daremos el primer día de clase una lista completa de historias
de usuario a completar en los 4 Sprints, sino que yo, haciendo el rol de “Product Owner”,
mostraré una lista solo con las historias para cada Sprint.

El Product Backlog es una lista de historias de usuario (o items de manera general). Son el qué
se espera que se complete durante cada Sprint. Esas historias tienen objetivos de la asignatura,
son del tipo aprendizaje resumidas (las historias tiene un formato elaborado por ejemplo:
“Determinar el precio del producto o servicio del proyecto”, “Identificar los competidores”,
etc. Pondré esas historias porque son los objetivos de la signatura, pero igualmente, para ti
podría ser “buscar los stakeholders más importantes del proyecto”.
Cada historia de usuario tiene un valor que las prioriza, como Product Backlog. Los puntos de
usuario y la suma del valor de las historias propuestas serán dadas por el equipo. Así, por si no
les diera tiempo a terminarlas todas, deben priorizar para obtener el máximo valor, que viene
a estar relacionado con obtener mayor nota.

El Sprint Backlog
Como es lógico, es tarea del equipo, es el cómo se organiza para resolver las historias de
usuario. Es el cómo. Aquí hay libertad para usar pared y posit o, por ejemplo, Trello u otra
herramienta de software que puedan aplicar.

Daily, Sprint Review y Retrospectiva

Los Dailys son una recomendación, si bien es razonable que no puedan hacerlos diariamente.
La clase del último día del Sprint es el Sprint Review. Antes, además de las historias del Sprint,
los alumnos deben haber hecho ellos una retrospectiva, para mejorar como grupo Sprint a
Sprint. Y, para ello, normalmente, usan la técnica de la estrella de mar o la del barco.
Durante la clase Sprint Review los alumnos hacen una presentación o “demo” al Product
Owner. En la presentación y/o demo, por equipos, muestran cómo han completado las
historias del Sprint, el incremento y al final de la fase presentarán toda la Retrospectiva.
En el mundo real la retrospectiva se hace después del Sprint Review, pero en el caso que nos
ocupa, por razones obvias, es más efectivo que los equipos la hagan antes y la cuenten durante
la presentación final de fase.

Uso de otras herramientas.

Se sugiere usar intensivamente la pizarra, post-its para la planificación del Sprint, Para el
Sprint Backlog, usar el Tablero Sprint. Y BurnDown manual.
Aunque lo más recomendable es llevar la gestión del proyecto Scrum utilizando un soporte
“gráfico - artesanal”, también hay quienes pueden gestionarlo todo con algún tipo de
herramienta, como Trello. Bien porque necesite dejar evidencias de la gestión del proyecto,
para afrontar una auditoría de procesos (leer post Scrum y CMMI y ISO 15504 y prácticas
ágiles), porque el equipo tenga que estar distribuido, o por cualquier otra razón. Por ello, al
igual que en aquel post de herramientas Kanban, se pueden probar el uso de herramientas
Scrum de uso gratuito. (Presentarlas en caso de haber sido usadas lo cual aumentará su nota).

Herramientas Scrum
– Kunagi. Herramienta Web que proporciona un sistema de gestión de proyectos basado en
Scrum. Ofrece herramientas colaborativas y otras facilidades, como un cuadro de mando del
proyecto, un panel interactivo para el Sprint o soporte a la estimación con Planning Poker.
– ScrumDo. Herramienta Scrum muy centrada en la simplicidad y en la facilidad de uso.
Permite gestionar las listas de tareas e historias de usuario, crear y gestionar iteraciones,
obtener gráficos de avance “burndown” y también dar soporte a la estimación con Planning
Poker.
– SprintoMeter. Herramienta para la gestión, medición y seguimiento de proyectos Scrum y
eXtreme Programming. Para simplificar el intercambio de datos permite exportar gráficos e
informes a Excel. Posee gráficos de avance burndown en 3D.
– IceScrum. Herramienta Scrum y Kanban. Ofrece las opciones de operación, consulta y
estimación de historias de usuario. Permite añadir historias de usuario a la pila de producto,
dividir el tiempo en Sprints y mover estas historias de la pila de producto a cada uno de los
Sprint. Posee la técnica de Planning Poker para la estimación y paneles virtuales.
– Pango Scrum. Otra de las herramientas Scrum online, con una interfaz sencilla y amigable
que permite escribir, estimar y priorizar la pila de producto. Facilita en gran medida la
planificación de Sprints y las reuniones.
Se valoraré el uso y compartir la experiencia del uso de alguna de estas herramientas u otras
que cada equipo pueda encontrar.