Está en la página 1de 32

17-6-2019 Administración de

proyectos de TI
Unidad 1

Ricardo Iván Macias Fusco – 65141150006

Macario De la Peña Valencia – 1113150057

Dulce Mireya Loera Ramos – 1116250008

Daniel Eduardo Sánchez Alvarado – 1115150089

Ricardo Naranjo De la Riva – 1116250052

MATERIA: ADMINISTRACIÓN DE PROYECTOS DE TI


CATEDRÁTICO: M.G.T.I. MARCO ANTONIO OROZCO SANCHEZ
INDICE

INDICE ............................................................................................................................ 1

TABLA DE ILUSTRACIONES ........................................................................................ 3

RESUMEN EJECUTIVO ................................................................................................. 4

Valor Único: ................................................................................................................. 6

Factibilidad Técnica: .................................................................................................... 6

Factibilidad Operativa: ................................................................................................. 7

Factibilidad Económica: ............................................................................................... 7

Alcance Primario: ......................................................................................................... 8

Alcance Adicional:........................................................................................................ 8

ROLES ............................................................................................................................ 9

Project Manager........................................................................................................... 9

Scrum Master............................................................................................................. 10

Product Owner ........................................................................................................... 10

Documentador ........................................................................................................... 12

Programador FrontEnd .............................................................................................. 12

Programador BackEnd ............................................................................................... 13

SysAdmin ................................................................................................................... 13

PLAYBOOK O PLAN DE GESTIÓN DEL PROYECTO ............................................... 14

1
Plan de Gestión de Costos y Adquisiciones............................................................... 14

Plan de Gestión de Riesgos....................................................................................... 15

Plan de Gestión de Calidad ....................................................................................... 15

Plan de Gestión de Interesados ................................................................................. 16

Plan de Gestión de Recursos .................................................................................... 16

Plan de Gestión de Alcance ....................................................................................... 17

Plan de Gestión de Comunicaciones ......................................................................... 18

Plan de Gestión de Scrum ......................................................................................... 19

HITOS Y TAREAS REPETITIVAS ................................................................................ 20

PRODUCT BACKLOG INICIAL ................................................................................... 23

SPRINT 1 BACKLOG ................................................................................................... 24

SPRINT 2 BACKLOG ................................................................................................... 25

PRODUCT BACKLOG PIVOTE ................................................................................... 26

MATRIZ RACI ............................................................................................................... 28

2
TABLA DE ILUSTRACIONES

Ilustración 1. BLE Bus Stop Icon ..................................................................................... 4

Ilustración 2. Actividades Repetitivas ............................................................................ 21

Ilustración 3. Calendario de Actividades ....................................................................... 22

Ilustración 4. Product Backlog Inicial ............................................................................. 23

Ilustración 5. Sprint 1 Backlog ....................................................................................... 24

Ilustración 6. Sprint 2 Backlog ....................................................................................... 25

Ilustración 7. Product Backlog Pivote ............................................................................ 26

Ilustración 8. Lista de Actividades o ToDo List .............................................................. 28

Ilustración 9. Creación de ToDo .................................................................................... 29

Ilustración 10. Tablero Kanban ..................................................................................... 29

Ilustración 11. Actividad de Kanban .............................................................................. 30

Ilustración 12. Tablero de Archivo de Sprint .................................................................. 31

3
RESUMEN EJECUTIVO

Ilustración 1. BLE Bus Stop Icon

A través del uso de la tecnología BLE (Bluetooth Low Energy) en un Beacon, enviar
información acerca de los horarios de autobuses a los Smartphones de los usuarios
quienes hacen uso del transporte público, una vez que hayan tomado la ruta se hace un
check-in, para que puedan accesar a una aplicación web desarrollada en JavaScript que
se conectará a una API que contendrá la información de las rutas que pasan por esa
parada y los horarios dentro de un margen de tiempo específico dependiendo de la hora,
para que el usuario pueda saber si el autobús esta retrasado o probablemente ya pasara,
permitiéndoles avisar en caso de que el autobús no haya llegado o que existe un retraso
en la ruta, para que otros usuarios puedan saberlo e incluso tener información analítica
acerca del transporte público. En la aplicación del conductor del camión también se
visualiza el horario y el estado actual en la que la ruta se encuentra, esto con la finalidad
de que el conductor tenga conocimiento si se encuentra en el margen correcto en tiempo

4
para cumplir con sus horarios establecidos, teniendo una aplicación secundaria para el
conductor permite que la Dirección de transporte reciba informes reales sobre el
desempeño y el cumplimiento de los horarios establecidos.

Problemática:
En la ciudad de Chihuahua, así como muchas otras ciudades del México, y
probablemente del mundo existe, el servicio de transporte es ineficiente e inconstante,
especialmente en lo que se refiere a la puntualidad. Las rutas cambian de horario y los
usuarios desconocen a qué hora pasa o si ya han pasado, y la implementación de
sistemas de geolocalización satelital como el GPS, resultan de carácter privado o
ineficientes, por lo que los usuarios nunca conocen los horarios y no tienen forma de
tener certeza de si llegaran a tiempo o no a algún lugar. Incluso las autoridades
desconocen si un autobús pasa en tiempo o no, reservándose esa información.

Solución:
Usando al tecnología BLE, instalar un beacon en la paradas de autobuses así como en
el autobús, de forma que permita que los usuarios al tomar su ruta, reciban una
notificación que les señale que pueden accesar a un sitio web para revisar las rutas y
horarios de los autobuses que pasan por ese lugar, para que puedan determinar si toman
otro medio de transporte o esperan el autobús correspondiente, igualmente puedan
saber con la información alimentada por otros usuarios como crowd-sourcing (como se
informa del tráfico en Waze y otras aplicaciones) si un autobús va cumpliendo con su
ruta o presenta retrasos.(Opcional dependiendo del tiempo y la dificultad en la creación
de la API). Igualmente, de forma opcional, generar el Dashboard de acceso remoto de
los beacons, si es que se cuenta con acceso a internet en el área donde se encuentran
los beacons. Esta parte es super opcional, ya que la infraestructura de las paradas de
camión, no permite eso de momento. Así mismo la aplicación de conductor que ofrece la
posibilidad de que el conductor tenga conocimiento de que cumple su horario

5
establecido, esto también automatiza el proceso de verificación de cumplimiento de
horario de la ruta por parte de Dirección de transporte, el cual actualmente se realiza de
manera manual y puede tener información no totalmente verídica.

Valor Único:

1. Las aplicaciones que existen, el usuario tiene que tenerlas descargadas.


2. Las páginas web existentes contiene información de horarios, con tiempos reales
de rutas.
3. Proporcionaría información analítica con el uso de la aplicación que los usuarios
hicieran por crowd-sourcing
4. Se tiene una aplicación para los autobuses la cual tiene el horario establecidos
para cada ruta, haciendo más certero que el camión deba pasar en un horario
definido.
5. Únicamente es necesario desplegar un beacon, y pueden hacerse conexiones
remotas a el de existir una red a donde se puedan conectar.

Factibilidad Técnica:

 Es posible usar el beacon para emitir una URL con la pagina del sitio web,
redirigiendo al pasar un parámetro que identifique el ID de la parada.
 Es posible hacer en JavaScript con el uso de React y Redux una web app y una
API que envíen los datos en JSON para poder enviar una lista de las rutas con
detalle de los horarios.
 Es posible alimentar información a través de Crowd-sourcing de la información de
los autobuses.
 Es posible conectar Google Beacon Dashboard a los beacon para el prototipo del
proyecto.

6
 Es posible el llevar un control sobre el horario que tiene el camión dado a que se
recibe la información directa de la Dirección de transporte lo cual permite poder
dar un margen de estimación de llegada del camión a las paradas.

Factibilidad Operativa:

 El equipo cuenta con desarrolladores que pueden hacer el endpoint de la API, así
como la web app que reciba la información, por lo que es sostenible el uso de la
aplicación.
 Pueden usarse los beacons de forma efectiva por el equipo por ser de lenguaje
alto y funcionalidad básica.
 El equipo soluciona un problema que es real y puede aplicarse la solución de
forma rápida y resolviendo el problema, incluso es escalable para poder generar
una red de información para usuarios y generar analíticos con la información de
los mismos.

Factibilidad Económica:

 Es necesario realizar la compra de 3 o 4 beacons para pruebas de ubicación, los


cuales tienen costos variables desde 300 hasta 1500 pesos cada uno. Es
importante revisar tiempos de entrega de los beacons lo cual podría generar un
importe adicional aduanal, elevando su costo final.
 Se requiere un servidor, el cual puede usarse de forma gratuita para conexión web
o usar una Raspberry para colocar un servidor en la misma, otra optativa es el
montar un servidor nativo en una computadora o laptop que tenga la capacidad .
Es importante revisar costos del servidos, aunque hay alternativas gratuitas. Tal
vez solo se necesite invertir en algún dominio o hosting básico. Igual puede usarse
una Raspberry, la cual de momento tenemos gratuita para pruebas.

7
 Los servicios de Google son gratuitos para desarrolladores, por lo que solo habría
que pagar si se sacara una versión a producción, lo que no se tiene contemplado
en el proyecto.
 Se usarían los equipos (computadoras y celulares) de los integrantes para
programación y configuración, no es necesario comprar equipos adicionales.

Alcance Primario:

1. Configurar beacons para que emitan URL.


2. Hacer web app para revisar rutas y horarios.
3. Configurar servidor para hacer una API que permita alimentar la web app con
información
4. Hacer API con información como endpoint.

Alcance Adicional:

1. Configurar Google Dashboard para poder manipular beacons a través de WiFi.


2. Generar estadísticas de cuando un camión llego a tiempo y cuando no llego a
tiempo con información de los usuarios.
3. Hacer un login y cuentas de usuarios para información más precisa y evitar
duplicados o basura en las estadísticas.

8
ROLES
Project Manager

El Project Manager es el encargado de revisar que los planes de gestión se estén


llevando a cabo durante la elaboración del proyecto y ayudar a la correcta administración
del equipo de la mano del Product Owner.

Su función principal es proveer herramientas, información y recursos necesarios al


equipo cuando se determine que las actividades están fuera del alcance del producto,
pero involucran al proyecto por completo.

Elaborará la documentación básica necesario para la administración del proyecto que


este fuera de la gestión de Scrum o que no produzca de forma directa un valor al
producto, pero ayude a la mejora o terminación del proyecto.

Cualquier duda respecto a las funciones del Project Manager deberá aclararse con el
Product Owner. Si es necesario agregar funciones se realizará una junta al respecto con

9
el equipo si es emergente el problema o se esperará al siguiente Sprint Planning para
añadirla. El Project Manager no interviene en las Ceremonias de Scrum salvo para
garantizar que el proyecto vaya avanzando y proveer de herramientas en caso de ser
necesarias.

Scrum Master

El Scrum Master es el encargado de dar seguimiento a las actividades del equipo en


cuanto a los documentos y actividades propias de Scrum que deben realizar como es
Subir diariamente su Daily Meeting, verificar que el Product Owner este asignando las
actividades y alimentando constantemente el Burndown Chart y que durante los Sprint
Planning se estén efectuando las actividades propias del mismo.

El Scrum Master tendrá la responsabilidad de dar seguimiento a los documentos que se


usen para la elaboración del producto y las herramientas apropiadas para la
comunicación durante el proyecto en cada una de las ceremonias y los Sprint.

De igual forma es responsable de apoyar al Product Owner cuando por causas externas
no pueda terminar o desarrollar los Backlogs correspondientes tanto al Sprint como al
producto.

Cualquier duda respecto a las funciones del Scrum Master deberá aclararse con el
Administrador de Proyecto. Si es necesario agregar funciones se realizará una junta al
respecto con el equipo si es emergente el problema o se esperará al siguiente Sprint
Planning para añadirla.

Product Owner

El Product Owner es el encargado de elaborar y dar seguimiento a la pila de producto.


Su principal actividad es revisar las actividades que se están realizando y verificar que
se llevan a cabo conforme lo basado en los requerimientos de las mismas que se

10
determinaron en el Sprint Planning.

Determinará de igual forma los riesgos y prioridades en la lista de productos, para poder
valorarlos y diseñar el Burndown Chart. En caso de que algún miembro del equipo tenga
dificultades para el desarrollo del producto se encargará de ayudarlo y revisar la
información detalladamente para poder asistirle y determinar si es necesario algún
cambio.

Durante el Sprint Planning será el encargado de elaborar el Sprint Backlog con la


información que el equipo y él en conjunto determinen que es la más importante o posible
de hacer, esto basado en las prioridades y valor determinados con anterioridad.

Durante el Sprint Review verificará que las actividades realizadas cumplan con los
parámetros de calidad establecidos y que se hayan llevado a cabo todas las actividades
para concretar la actividad, de igual forma alimentará el Product Backlog si a
consideración propia o del equipo es necesario agregar actividades.

Durante los Daily Meeting revisará que los miembros del equipo estén elaborando
actividades acordes al Sprint Backlog con la finalidad de cumplir las actividades que les
sean asignadas durante el Sprint Planning.

Se encargará de dividir las actividades de forma equilibrada entre los miembros del
equipo para que cada uno de ellos pueda aportar valores similares a las actividades
durante el desarrollo y evaluación del proyecto.

Cualquier duda respecto a las funciones del Product Owner deberá aclararse con el
Administrador de Proyecto. Si es necesario agregar funciones se realizará una junta al
respecto con el equipo si es emergente el problema o se esperará al siguiente Sprint
Planning para añadirla.

11
Documentador

La función del Documentador es verificar que todas las actividades del proyecto tengan
sus documentos, así como verificar los entregables que cumplan con los requerimientos
solicitados para cada materia. Se encargará de elaborar un reporte de todo lo entregable
y llevar un seguimiento de si se encuentra un documento para cada una de esas
actividades o procesos. La gramática y ortografía de los documentos, así como el
glosario, son responsabilidad del Documentador exclusivamente.

El Documentador de igual forma elaborará los formatos de ser necesarios para el control
de calidad del proceso y ayudará al Scrum Master en las funciones que correspondan a
llevar un control de calidad adecuado a través de documentos.

Cualquier duda respecto a las funciones del Documentador deberá aclararse con el
Administrador de Proyecto. Si es necesario agregar funciones se realizará una junta al
respecto con el equipo si es emergente el problema o se esperará al siguiente Sprint
Planning para añadirla.

Programador FrontEnd

El Programador FrontEnd fungirá como programador Full Stack en los casos que no haya
un programador determinado o previsto.

El desarrollo del FrontEnd lo realizara con el uso de React y JavaScript. Queda a su libre
elección realizar cambios a la aplicación para su correcto funcionamiento en tanto
notifique directamente al Programador BackEnd si necesita que la Web App realice
llamadas especificas al endpoint o la API.

El Programador FrontEnd deberá realizar la Web App siguiendo las mejores prácticas
como es el uso de Material-UI y que pueda ser responsiva para verse en un Sitio Web
como en Smartphone.

12
Cualquier duda respecto a las funciones del Programador FrontEnd deberá aclararse con
el Administrador de Proyecto. Si es necesario agregar funciones se realizará una junta
al respecto con el equipo si es emergente el problema o se esperará al siguiente Sprint
Planning para añadirla.

Programador BackEnd

El programador de BackEnd desarrollará la API y el endpoint desde donde se le llamará


la información para abrirla en la Web App.

El trabajo del programador de BackEnd consiste en hacer todo el desarrollo de la API


para que la transmisión de datos al FrontEnd sea en un documento JSON, y para habilitar
el paso de parámetros en el BackEnd para llamar determinada información, así como
habilitar la base de datos para poder subir información a través de parámetros desde el
FrontEnd.

Deberé documentar todos sus avances para poder determinar qué y cómo se ha
realizado la API, así como la forma de llamar los datos a través de una URL.

Cualquier duda respecto a las funciones del Programador de BackEnd deberá aclararse
con el Administrador de Proyecto. Si es necesario agregar funciones se realizará una
junta al respecto con el equipo si es emergente el problema o se esperará al
siguiente Sprint Planning para añadirla.

SysAdmin

El Administrador de Sistemas o SysAdmin es el encargado de los servidores que


puedan utilizar las aplicaciones, desde levantarlos, administrarlos y darles
mantenimiento.

13
Para el proyecto el SysAdmin se encargara de levantar un servidor en para la aplicación
web, así como de administrarlo para que se puedan conectar a él, ya sea a través de un
dominio o un servidor local al cual se pueda tener acceso a través de un Access Point.

El servidor en caso de ser local se hará en una Raspberry Pi, para hacer uso de un
dispositivo que nos permita mover el servidor de lugar de forma práctica y rápida.

El SysAdmin debe documentar como realizo los procesos para habilitar el servidor y las
contraseñas del mismo. De igual forma se encargará en dar de alta los Beacons en
Google Beacon Dashboard en caso de usarse una red móvil para el uso de los mismos.

Cualquier duda respecto a las funciones del SysAdmin deberá aclararse con el
Administrador de Proyecto. Si es necesario agregar funciones se realizará una junta al
respecto con el equipo si es emergente el problema o se esperará al siguiente Sprint
Planning para añadirla.

PLAYBOOK O PLAN DE GESTIÓN DEL PROYECTO


Plan de Gestión de Costos y Adquisiciones

Todo costo dentro del proyecto buscará reducirse al mínimo cuando se trate de
cuestiones económicas conforme al plan de gestión de recursos.

En cuanto a tiempos o adquisiciones, se buscarán siempre los más eficientes en cuanto


a tiempo principalmente y posteriormente a costo.

Cualquier cosa no prevista en el documento se realizará una junta para tomar una
decisión y llegar a consenso entre los miembros del equipo.

14
Plan de Gestión de Riesgos

Es responsabilidad del Project Manager y del Producto Owner dar seguimiento a las
necesidades y riesgos del proyecto. En caso de presentarse una dificultad, son los
responsables de hacer las estrategias y presentar alternativas al equipo para poder
determinar el camino a seguir.

 Cuando los riesgos que se presenten sean económicos, se centrará en el plan de


gestión de costos y de recursos.
 Cuando los riesgos sean del personal, se centrará en el plan de gestión de
recursos y comunicación.
 Cuando los riesgos sean del producto o su desarrollo, se guiarán con el plan de
gestión de Scrum.

Cualquier otro riesgo que se presente y que no esté previsto, se realizará una reunión de
equipo para determinar cuál será el proceso o camino a seguir relacionado al mismo, ya
sea por consenso o mayoría.

Plan de Gestión de Calidad

Toda actividad debe estar debidamente documentada y revisada por los responsables
de la misma.

El encargado de una actividad producirá su propia documentación, la cual debe tener en


la carpeta correspondiente a la materia en Google Drive. Es importante que
posteriormente informe al documentador de la misma para que pueda revisarla y corregir
la ortografía, agregar términos al glosario o realizar algún formato o estilo al texto para
su entrega de ser el caso.

15
Plan de Gestión de Interesados

Los interesados internos del proyecto son los miembros del equipo (Naranjo, Mireya,
Mack, Dany y Dicky). Los miembros del equipo tienen igual determinación en lo que al
proyecto corresponde. cada uno de ellos fungirá con un rol primario y un rol secundario
durante el proyecto. Todos tendrán su propia cuenta de Basecamp y Kanban, así como
acceso a toda la documentación que se reúna en Google Drive.

Los interesados externos serán los profesores de asignatura. A ellos se les entregarán
los documentos o entregables que soliciten. Es importante considerar que algunos de
ellos tendrán acceso a herramientas como GitHub, Basecamp o Kanban para permitirles
llevar seguimiento de lo que se hace en sus materias. Los interesados externos
únicamente tienen control sobre los entregables solicitados a través de minutas o
previamente a los miembros del equipo, mas no en la gestión y desarrollo del equipo o
producto.

Plan de Gestión de Recursos

Los recursos humanos para el proyecto se determinarán en cuanto a tiempos y


posibilidades de los miembros del equipo. Cada uno de los miembros deberá considerar
tiempo suficiente para realizar las actividades que le correspondan dentro de un Sprint y
en el transcurso del proyecto.

Para asignar una actividad, se creará un ToDo al responsable y este deberá informar de
inmediato si es capaz o no de realizar las acciones correspondientes en el tiempo
señalado o antes de terminar el Sprint.

En relación a Recurso Económicos, se determina que cualquier gasto que se realice del
proyecto se dividirá por partes equitativas en el equipo. Previo a realizar cualquier gasto,
los miembros del equipo deberán autorizarlo por escrito. Para ello se creará un aviso en
Basecamp donde se expondrá la información del gasto. Si algún miembro del equipo

16
tiene inconformidad del mismo, deberá exponerla y proponer una alternativa. Como
ultima determinación, en caso de no haber consenso unánime, se determinará por
mayoría y todos serán responsables de participar del gasto. Se estable como tope
máximo para el proyecto la cantidad de $1250 pesos por miembro de equipo para gastos
del mismo.

En cuanto a bienes materiales, el equipo propone hacer lo posible por conseguir los
bienes de forma gratuita o a modo de préstamo, para usarlos durante el proceso del
proyecto. En caso de desperfecto de algún bien, se comprometen entre todos a cubrir
los gastos del mismo, siempre y cuando no haya sido por negligencia o responsabilidad
directa de uno de los miembros. En ese caso, el miembro es responsable de los gastos
erogados del mismo.

Plan de Gestión de Alcance

Para determinar el alcance del proyecto se organizará el equipo y decidirá a través de


un Pitch las actividades que consideren pertinentes en los comentarios.

El alcance puede ser cambiable considerando que es una metodología ágil, pero deberá
determinarse como alcance primario las cosas que el equipo está obligado a hacer, y
alcance secundario aquellas que pueden ser buenas adiciones, pero que no se
consideran por cuestiones técnicas, de tiempo o económicas pertinentes o posibles en
una primera fase.

Si una actividad no está prevista, deberá ponerse a consideración en un Sprint Planning.


No puede ser agregada salvo que sea una actividad que sea esencial para el logro de
un objetivo primario.

17
Plan de Gestión de Comunicaciones

La comunicación se podrá llevar a cabo de 3 formas dependiendo de la urgencia o


pertinencia del asunto.

La comunicación se llevará a cabo principalmente en la plataforma de Basecamp. Toda


la información actividades y detalles deberá ser alimentada en esta plataforma, así como
los chats o espacios de conversación ser el principal medio de información. Cualquier
acuerdo será publicado en el tablero de avisos con notificación a todos los interesados
en el proyecto, para que puedan revisar y determinar las actividades que se están
haciendo y elaborando. En caso de existir alguna actividad se agregará en un ToDo a la
persona que se le asignará con fecha del día en curso, para que pueda revisarla y
reagendar. La persona que le asigne la actividad quedará como responsable del
seguimiento y a quien se le informará. Las actividades generales del proyecto o propias
del Sprint, corresponde asignarlas al Product Owner.

El segundo medio de comunicación será a través de Kanban, la cual es una herramienta


de tablero de actividades. Cada miembro es responsable de hacer una actividad en
Kanban de las que esté realizando durante el proyecto para darle seguimiento y reportar
en que se está trabajando de momento. La finalidad de ello es poder llevar reportes
detallados y un mejor control del flujo de trabajo. Los archivos o documentos que se
deriven de la misma deberán ser guardados en Google Drive y referenciados con un link.

El tercer medio de comunicación y que únicamente se usará para informar cuestiones


generales o remitir la información a Basecamp es WhatsApp. La información de
WhatsApp no tiene validez para actividades, a excepción que alguien no tenga acceso a
la plataforma por alguna razón, sin embargo, se considerará pasar la información a esta
plataforma en un aviso o un ToDo.

Se usarán los nombres en inglés de toda la terminología, la cuál se puede revisar en la


bibliografía de Scrum o en los documentos anexos que se realicen como el glosario.

18
Cualquier cosa no prevista en algún documento o rol, se realizará una reunión para
determinar un responsable el mismo día, la cual puede ser en Campfire, WhatsApp o
presencial en la universidad, y corresponde al documentador actualizar los documentos
con la información recabada.

Plan de Gestión de Scrum

Se determinan los roles y funciones de cada uno de los participantes del proyecto y sus
funciones en la carpeta de roles. Se hará uso de las herramientas de Scrum para el
proyecto.

El Product Backlog, Sprint Backlog y Burndown Chart son responsabilidad del Product
Owner.

La revisión de las ceremonias (Daily Meeting, Sprint, Review, Retro, Sprint Planning)
deberán ser llevadas y guiadas por el Scrum Master. La documentación recabada de las
mismas deberá ser documentada debidamente por el Documentador.

El desarrollo de Software queda a cargo de los Programadores.

El uso de los Beacons, su administración y resguardo, así como de cualquier herramienta


o Hardware quedará a cargo del SysAdmin, así como los accesos a Herramientas
propias del Producto.

El desarrollo de formularios en caso de ser necesarios, serán principalmente hechos por


el responsable de la actividad, sin embargo, el documentador deberá modificarlos y
adecuarlos para la entrega de documentos, así como revisar los glosarios, ortografía y
gramática.

Los Sprint tendrán una duración de 15 días, salvo que en el desarrollo de un Sprint

19
Planning se determine otra cosa. La fecha de entrega del proyecto es el día 5 y 6 de
agosto, por lo que el día 3 de agosto deberá quedar completamente terminado el
proyecto y la documentación.

Los Sprint Review y Sprint Planning se llevarán a cabo los días sábados o domingos
cada 2 semanas al término del Sprint. En ello se llevará a cabo la presentación de los
entregables, los avances y documentos, y se organizarán las actividades para llevar a
cabo el siguiente Sprint. En caso de suspensión del proyecto o que sea necesario un
pivote, se realizará una reunión de Pitches para revisar las opciones y determinar si es
necesario un Sprint Planning Week para reformular el proyecto, su alcance y cómo será
la nueva distribución.

Cualquier cosa no prevista en el documento, se realizará una junta de equipo para


plantear la actividad o modificación. En caso de no estar presente alguno de los
miembros, no se le considerará para la actividad, sin embargo, será responsable de las
actividades que se le asignen.

HITOS Y TAREAS REPETITIVAS

En Basecamp y con Scrum gestionamos de dos formas los hitos o tareas repetitivas.

Se puede determinar un checklist automático que informe a la persona responsable las


actividades a hacer.

20
Ilustración 2. Actividades Repetitivas

Igualmente se puede agendar la actividad en el calendario, desde el cual le llegará una


notificación previa a la fecha para que pueda considerarlo.

21
Ilustración 3. Calendario de Actividades

Las actividades generales, así como los checklist deben ser asignados a todos los
participantes del proyecto para estar enterados.

22
PRODUCT BACKLOG INICIAL

Ilustración 4. Product Backlog Inicial

23
SPRINT 1 BACKLOG

Durante el primer Sprint se desarrollan tareas que se seleccionan i valoran según su


prioridad, con la finalidad de hacer la mayor cantidad de actividades prioritarias o de
mayor valor, siguiendo el principio de Pareto que determina que debe hacerse el 80% de
las actividades en el 20% del tiempo.

Ilustración 5. Sprint 1 Backlog

24
SPRINT 2 BACKLOG

Ilustración 6. Sprint 2 Backlog

Se determina a mitad del Sprint que al no ser técnicamente posible por uso de librerías
Open Source, es necesario hacer un pivote de proyecto y hacer un proyecto nuevo.

Se solicita autorización para nuevo proyecto. Se termina Sprint 2 y la semana adicional


se usará para un Sprint Planning. Se realizarán ajustes al proyecto y los roles del mismo,
se elabora nueva pila de producto y se tendrán que desarrollar nuevamente las
actividades para proyecto nuevo.

25
PRODUCT BACKLOG PIVOTE

Ilustración 7. Product Backlog Pivote

26
Se realiza nueva pila de actividades primaria para poder hacer una Sprint Planning Week
para determinar nuevamente alcances de proyecto y toda la información correspondiente
al pivote del proyecto.

Se determinaron actividades correspondientes al Sprint Planning Week, las cuales


pueden ser modificables para corresponder a las necesidades del proyecto.

27
MATRIZ RACI

En Basecamp y con Scrum las actividades funcionan de forma más dinámica. Cualquier
usuario puede asignar actividades a otro usuario, conforme se determina en el plan de
gestión de Scrum.

Ilustración 8. Lista de Actividades o ToDo List

Un usuario puede crear una actividad y asignarla a otro, pero deberá etiquetarse a sí
mismo como responsable del seguimiento y a la otra persona como responsable de
hacerla. Se deberá asignar el mismo día para que la persona sea notificada de la

28
actividad y deberá terminarla antes del siguiente Sprint Review o Demo Day. En caso de
cualquier inconformidad o duda, podrá resolverla en el mismo ToDo.

Ilustración 9. Creación de ToDo

Una vez asignada una actividad, el usuario deberá crear la tarea o actividad en el tablero
de Kanban para poder valorarla y generar el Burndown Chart correspondiente.

Ilustración 10. Tablero Kanban

29
Cuando una actividad es creada deberá hacerse la descripción de la misma, subtareas,
asignar un valor y fecha de vencimiento o la historia de la misma si es que cumple alguna
función específica. Estas actividades serán revisadas por el Product Owner.

Ilustración 11. Actividad de Kanban

30
Al terminar una actividad, pasara a la lista de Terminado y posteriormente a revisión. Con
la terminación del Sprint se procederá a archivar todas las actividades revisadas en el
tablero de archivo dentro del Sprint correspondiente.

Ilustración 12. Tablero de Archivo de Sprint

31