7.1 - Etapa 1: Inicio del proyecto

Esta etapa del ciclo de vida, está compuesta por 6 prácticas. El objetivo principal de esta etapa es establecer las condiciones básicas de conocimiento y planificación del producto, que permitirán su correcto desarrollo durante la ejecución de los distintos Sprints.

Nota: Las prácticas de esta etapa no suelen ser prácticas iterativas

dibujo

ID	Práctica	Rol vs Nivel de Involucramiento
	Etapa 1: Inicio del proyecto
1	7.1.1 - Definir la visión del proyecto (1)	Product Owner: Alto - Scrum Master: Nulo - Equipo de desarrollo: Nulo
2	7.1.2 - Formar el Equipo Scrum (2)	Product Owner: Alto - Scrum Master: Alto - Equipo de desarrollo: N/A
3	7.1.3 - Construir el Product Backlog (3)	Product Owner: Alto - Scrum Master: Medio - Equipo de desarrollo: Medio
4	7.1.4 - Priorizar el Backlog (4)	Product Owner: Alto - Scrum Master: Medio - Equipo de desarrollo: Medio
5	7.1.5 - Definir el cronograma de entregas (5)	Product Owner: Alto - Scrum Master: Alto - Equipo de desarrollo: Alto
6	7.1.6 - Definir la Arquitectura de Producto (6)	Product Owner: Medio - Scrum Master: Medio - Equipo de desarrollo: Alto

7.1.1 - Definir la visión del proyecto (1)

En la práctica de “Definir la visión del proyecto” se estructura la visión del proyecto, explicando las necesidades empresariales que el proyecto busca satisfacer, considerando el alcance, el tiempo, el presupuesto y la calidad esperada por el patrocinador del proyecto.

Algunas de las actividades clave dentro de esta práctica son:

7.1.1.1 - Restricciones de un proyecto

Los proyectos siempre tienen limitaciones, también llamadas “restricciones”. Por lo general se contemplan 4 restricciones principales (tiempo, presupuesto, alcance y calidad), sin embargo, según la naturaleza del proyecto y/o el estilo de la organización, podrían existir otras restricciones.

dibujo

7.1.1.2 - Identificar las partes interesadas

Al inicio del proyecto, el Product Owner, se encarga de garantizar que todas las Partes Interesadas son identificadas. Para ello, se recomienda que todas a su vez sean registradas, en lo que comúnmente se llama “Matriz de Partes Interesadas”

Esta matriz contiene la siguiente información:

• Empleados que trabajan para el proyecto, su respectivo rol y el tiempo en horas que dedican al proyecto.
• Proveedores del proyecto.
• Clientes / Usuarios que serán entrevistados, revisarán el proyecto o brindarán información útil para la construcción del producto.

7.1.1.3 - Definición de terminado (DoD)

Cuando un elemento del Product Backlog o del Incremento se describe como “Terminado”, todo el mundo debe entender lo que significa “Terminado” (Done); aunque esto puede variar significativamente para cada Equipo Scrum.

Los miembros del equipo deben tener un entendimiento compartido de lo que significa que el trabajo esté completado para asegurar la transparencia. Esta es la definición de “Terminado” (“Done”) para el Equipo Scrum, y se utiliza para evaluar cuándo se ha completado el trabajo sobre el Incremento de producto.

Esta misma definición guía al Equipo de Desarrollo en saber cuántos elementos del Product Backlog puede seleccionar durante la Planificación del Sprint. El propósito de cada Sprint es entregar Incrementos de funcionalidad que potencialmente se puedan poner en producción y que se ajusten a la Definición de “Terminado” (Done) actual del Equipo Scrum.

Los Equipos de Desarrollo (Development Team) entregan un Incremento de funcionalidad de producto en cada Sprint. Este Incremento es utilizable, de modo que el Product Owner podría elegir liberarlo inmediatamente. Si la definición de “Terminado” (Done) para un incremento es parte de las convenciones, estándares o guías de la organización de desarrollo, al menos todos los Equipos Scrum (Scrum Team) deben seguirla. Si “Terminado” (“Done”) para un incremento no es una convención de la organización, el Equipo de Desarrollo del Equipo Scrum debe especificar una definición de “Terminado” (Done) apropiada para el producto. Si hay múltiples Equipos Scrum (Scrum Teams) trabajando en la entrega del sistema o producto, los equipos de desarrolladores en todos los Equipos Scrum (Scrum Teams) deben definir en conjunto la definición de “Terminado” (Done).

Cada Incremento se integra con todos los Incrementos anteriores y es probado de manera exhaustiva, asegurando que todos los Incrementos funcionan en conjunto.

A medida que los Equipos Scrum maduran, se espera que su definición de “Terminado” (Done) se amplíe para incluir criterios más rigurosos para una mayor calidad. El uso de las nuevos criterios puede descubrir trabajo por hacer en los incrementos previamente “Terminados” (Done). Cualquier producto o sistema debería tener una definición de “Terminado” (Done) que es un estándar para cualquier trabajo realizado sobre él.

La Definición de Terminado puede ser definida para:

• Un sólo Sprint.
• Un Conjunto de Sprints.
• Un Proyecto.
• Un Programa.
• Toda la Organización.

Un ejemplo genérico de criterios de terminado puede ser:

• Los elementos fueron revisados por otros miembros del equipo (se realizaron las pruebas de colegas).
• Todos los defectos están arreglados.
• Se completaron las pruebas unitarias de la Historia de Usuario.
• Se finalizó toda la documentación técnica y de usuario final.
• Todos los archivos y documentos del proyecto están en el repositorio de la organización.
• Se hizo la demostración exitosa a los Socios y/o representantes de la empresa.
• El cliente dio su visto bueno a los entregables.

7.1.2 - Formar el Equipo Scrum (2)

Durante esta práctica se eligen los miembros que harán parte de los distintos Equipos Scrum.

7.1.2.1 - Plan de colaboración

Este artefacto define cómo las distintas partes interesadas y miembros del equipo de proyecto participan, se comunican y colaboran durante todo el proyecto. También se pueden definir las herramientas o técnicas específicas que se utilizarán para este fin.

Por ejemplo, cuándo y cómo se llevarán a cabo las reuniones, qué tipo de herramientas de comunicación se utilizarán, y quién debe estar involucrado en las diversas reuniones.

En proyectos grandes y complejos, especialmente con equipos distribuidos, este artefacto tiene mucha más formalidad. En otros proyectos pequeños, a veces puede ser simplemente un entendimiento verbal.

Por lo general es un artefacto que se construye en una reunión breve (30 minutos máximo), y se tiene en cuenta la opinión del todo el equipo.

7.1.2.2 - Reunión de inicio de proyecto o Kickoff

En esta reunión participan los responsables de ejecutar el proyecto y el cliente para formalizar el nuevo proyecto y en qué momento inicia. Esta reunión también resulta una herramienta que facilita la comunicación en el proyecto. (Esta reunión la dirige el Product Owner).

Los principales objetivos de la reunión de Kickoff son:

• Presentar los objetivos, beneficios y alcance del proyecto.
• Presentar el equipo de proyecto.
• Obtener el compromiso del equipo y partes interesadas frente al proyecto.
• Presentar el plan de trabajo inicial.
• Presentar la identificación inicial de riesgos.
• Definir la comunicación durante el proyecto.

7.1.2.3 - Modelo de desarrollo de equipos – Dr. Bruce Tuckman

El Dr. Bruce Tuckman definió el modelo para describir el curso que la mayoría de los equipos siguen en su camino hacia un alto rendimiento.

dibujo

• 1. Formación (Dirección) Esta es la etapa en que se conforma el equipo y los miembros del equipo están empezando a conocerse, por lo que inicialmente su comportamiento tiende a ser individualista. Durante esta fase de Formación se establecen las primeras interacciones entre ellos, por lo que es común que no se presenten conflictos o discusiones.

En esta etapa también se definen las reglas del equipo, su propósito y su identidad (un nombre para el equipo), lo cual hace parte de un buen entorno de trabajo para el equipo.

En esta fase el Scrum Master toma una posición de “director” dado que los miembros del equipo dependen de él para la definición del rumbo del equipo y su orientación.

• 2. Enfrentamiento/Conflicto En esta fase ya se ha generado confianza entre los miembros del equipo, por lo que se presentan diferencias en el equipo y los miembros compiten entre sí, estableciendo o rompiendo relaciones entre ellos. Dado que cada miembro tiene su propia personalidad y estilo de trabajo, será necesario que se alcance un acuerdo de convivencia para evitar la disminución de la motivación.

Aunque la fase hace alusión al enfrentamiento, también es necesario que esos enfrentamientos se resuelvan para asegurar el buen rendimiento del equipo.

En esta fase el Scrum Master toma una posición de “coach”, brindando acompañamiento al equipo y guiando a los miembros para mantener los conflictos bajo control. También debe mantener la calma y dar ejemplo del comportamiento deseado para que los demás miembros del equipo lo imiten y adopten sanamente. El Scrum Master también es responsable de promover actividades que aumenten la motivación del equipo e identificar cuáles son las interacciones que mejoran o deterioran la convivencia en el equipo.

• 3. Normalización En esta fase los conflictos se reducen y se generan acuerdos que mejoran las interacciones entre los miembros del equipo. Durante esta fase los miembros comprenden mejor cuáles son sus responsabilidades, fortalezas y debilidades, lo cual propicia un entorno de mayor confianza y colaboración.

Cada miembro ya es consciente de su lugar en el equipo y es capaz de entender y aceptar el estilo de trabajo de los demás miembros, por lo que los intereses personales pasan a un segundo plano para dar prioridad a los intereses del equipo como un todo.

En esta fase el Scrum Master es un “facilitador”, ya que toma un enfoque hacia la mejora y acondicionamiento del entorno para facilitar el rendimiento del equipo. Dado que en esta fase el Scrum Master conoce más al equipo, puede identificar de qué manera encajan mejor sus miembros y cómo puede aumentar su rendimiento y motivación.

Es común que en esta fase se puedan incorporar nuevos miembros al equipo, por lo que el Scrum Master tiene que velar por mantener la estabilidad del equipo asegurando que los nuevos miembros se integren fácilmente al equipo sin disminuir su rendimiento ni su motivación.

• 4. Desempeño En esta fase se cuenta con un equipo maduro con suficiente confianza, motivación y autonomía por lo que los miembros están en la capacidad de tomar ciertas decisiones sin la presencia de un “jefe”, y se le pueden delegar tareas que antes eran exclusivas del Scrum Master (como llevar a cabo reuniones diarias, identificar impedimentos, etc.). Además, los miembros del equipo ya son capaces de resolver los desacuerdos o diferencias positivamente y en poco tiempo.

Se debe reconocer que no todos los equipos llegan a esta etapa pues se logra después de enfrentar conflictos y grandes dificultades, convivir y compartir experiencias, lo que implica que muchos equipos no logren completamente la etapa de Normalización y se queden estancados en la etapa de Enfrentamiento.

En esta etapa no se requiere de mucho esfuerzo por parte del Scrum Master, lo que le permite enfocarse mucho más en mantener y mejorar el entorno de trabajo del equipo favoreciendo el alto rendimiento de los miembros.

• 5. Finalización/Disolución Esta etapa comprende dos situaciones: la disolución del equipo o la finalización del equipo. La disolución se presenta cuando eventualmente durante el proyecto, uno o más integrantes se van del equipo, lo que provoca un atraso en el avance que ya se había logrado, conllevando a una disminución de la motivación y del rendimiento, pues el equipo queda resentido tras la pérdida de su estabilidad.

La finalización del equipo se presenta cuando acaba el proyecto y los miembros del equipo pasan a ser parte de otro proyecto o de otra empresa, lo cual implica que, aunque se haya alcanzado exitosamente el objetivo del proyecto, entre los miembros se genera una sensación de “pérdida” pues las interacciones que ya estaban establecidas y que ya funcionaban adecuadamente se terminarán junto con el proyecto. En algunos casos el mismo equipo puede hacer parte de un próximo proyecto, sin embargo, al tratarse de un nuevo proyecto no necesariamente significa que las interacciones permanecerán de la misma manera.

Es necesario que el Scrum Master brinde acompañamiento al equipo, pues ya sea si se trata de la disolución o la finalización, representa un cambio significativo para los miembros del equipo.

7.1.2.4 - Equipos de alto rendimiento

Un equipo de alto rendimiento es aquel que tiene un desempeño notablemente superior al promedio. En Scrum normalmente el rendimiento se asocia a la velocidad con la que el equipo consigue entregar valor. Para lograr equipos de alto rendimiento, se necesitan considerar como mínimo los siguientes factores:

Se debe medir el rendimiento continuamente.

• Se deberían utilizar herramientas para automatizar la mayor cantidad de tareas posibles.
• La visión y reglas deben estar claras desde el inicio del proyecto.
• Se debe garantizar la presencia de elementos que fomenten la creatividad.
• Los objetivos definidos deben suponer un reto para el equipo.
• El equipo debe mantenerse motivado.

7.1.2.5 - Modelo de desarrollo de habilidades de Dreyfus

Cuando se consideran temas como la contratación de personal para un proyecto Scrum, y se cuenta con el tiempo apropiado, con los recursos suficientes y una complejidad aceptable para desarrollar una curva de aprendizaje, o cuando se quiere formar un equipo multidisciplinar con una visión de largo plazo, entonces un modelo de desarrollo de habilidades y competencias es aplicable y rendirá sus frutos en términos de calidad del trabajo, gestión del conocimiento, cumplimiento de tiempos y reducción de costos.

Este modelo permite a las organizaciones identificar jóvenes talento con potencialidad para desarrollar sus habilidades desde un nivel novato a un nivel experto a través de una combinación de aprendizaje y práctica, así como determinar los perfiles necesarios para el desarrollo de un proyecto. El modelo Dreyfus se divide en cinco (5) etapas:

1. Novato: Carece de experiencia, utiliza razonamiento analítico y reglas para determinar una acción (causa-efecto), le es difícil sintetizar o alcanzar un nivel de generalización o priorización de información. Necesita monitoreo y retroalimentación.
2. Principiante: Identifica puntos recurrentes o patrones significativos que componen la situación, o unidades de comprensión, independientes del contexto. Utiliza el razonamiento analítico y el reconocimiento de patrones para resolver problemas, además puede abstraer la información más general de un problema.
3. Competente: Tiene un equilibro entre el razonamiento clínico metódico y analítico que le permite reconocer e identificar con mayor facilidad patrones y aspectos comunes de un problema. Depende del razonamiento analítico para el abordaje de problemas complejos o poco frecuentes.
4. Profesional: Evalúa situaciones conocidas y las extrapola a otras desconocidas, haciendo frente a la ambigüedad, con visión de conjunto y un reconocimiento aparentemente intuitivo obtenido a través de la experiencia, es capaz de construir perspectivas particulares con base en el conocimiento y la experiencia.
5. Experto: Dicta intuitivamente una acción adecuada, descubre conscientemente las normas o reglas presentes en una situación, está abierto a situaciones inesperadas, va más allá de la imagen global, considerando aspectos culturales y de contextos más amplios a cada situación.

dibujo

7.1.3 - Construir el Product Backlog (3)

Durante esta práctica se construye el Product Backlog (Ver Sección 4.1 - Product Backlog).

Los elementos que hacen parte del Product Backlog son:

• Épicas.
• Historias de Usuario.
• Errores.
• Tareas.
• Pruebas de Concepto.

Algunas de sus características más relevantes son:

• Sus elementos están ordenados según la prioridad.
• Su contenido está directamente relacionado con lo acordado con el patrocinador del proyecto.
• Cada elemento que hace parte del Product Backlog se llama PBI (Product Backlog Ítem).

7.1.3.1 - Clasificando el Product Backlog

Durante la construcción del Product Backlog es importante clasificar los elementos del Product Backlog, para lo cual se podría utilizar el concepto de “épicas”.

Las épicas permiten agrupar los elementos del Product Backlog, permitiendo una mejor navegación por el mismo. Algunas ideas de las que se podrían definir las épicas son:

• Módulos.
• Componentes.
• Hitos.
• Entregables.
• Funcionalidades.

7.1.4 - Priorizar el Backlog (4)

Priorizar los elementos del Product Backlog es una práctica clave para garantizar la entrega de valor al cliente. Algunos de los factores que se deben considerar para la priorización de las Historias de usuario dentro del Product Backlog son:

• Tiempo.
• Esfuerzo.
• Valor Funcional.
• Dependencias.
• Riesgos.
• Opinión de los Stakeholders.
• Opinión del equipo de desarrollo.
• Valor de Mercado ($).

Nota: La prioridad de los elementos puede cambiar durante la ejecución del proyecto.

7.1.4.1 – Priorización por urgencia

Una de las técnicas de priorización del Product Backlog está determinada por la urgencia y el valor que representan los elementos del Product Backlog para las Partes Interesadas.

Los elementos que aporten más valor al negocio y tengan una mayor urgencia tendrán una mayor prioridad dentro del Product Backlog:

dibujo

7.1.4.2 - Visual Story Mapping

Esta es una técnica para proporcionar un esquema visual del producto y sus componentes claves. El Visual Story Mapping, fue formulado por Jeff Patton en 2005, y es comúnmente utilizado para ilustrar la trayectoria del producto.

Este representa la secuencia de iteraciones de desarrollo de los productos (de izquierda a derecha se organizan los componentes según su prioridad de desarrollo, tal como se ve en la imagen):

dibujo

7.1.5 - Definir el cronograma de entregas (5)

En esta práctica, el Product Owner en compañía de los demás miembros del Equipo Scrum, definen el cronograma de alto nivel del proyecto.

En esta práctica, podrían determinarse la duración estimada de los diferentes Sprints (dado que se ya tienen los elementos del Product Backlog priorizados).

Este cronograma incluye la descripción de alto nivel de las actividades, compromisos, tareas asignados específicamente a los miembros del equipo de desarrollo, los cuales se irán refinando a lo largo del proyecto, en las reuniones de Planificación de cada sprint.

dibujo

Nota: Este cronograma se irá actualizando de manera iterativa durante los Sprints.

7.1.5.1 - Calendario del equipo

El calendario del equipo contiene información sobre la disponibilidad de los miembros del equipo, considerando la información correspondiente a:

• Las vacaciones de los miembros del Equipo Scrum.
• Fechas de licencia.
• Acontecimientos importantes en la organización.
• Días festivos.
• Eventos de la oficina.
• Proyectos en curso.
• Etc.

7.1.6 - Definir la Arquitectura de Producto (6)

El objetivo de esta práctica es establecer o refinar el diseño técnico del producto o del componente de producto a desarrollar. Aunque esta actividad es obligatoria siempre al inicio del proyecto, podría hacerse también de forma iterativa antes de desarrollar componentes en los distintos Sprint.

Para garantizar que la arquitectura de producto que se defina cumple exactamente con los requerimientos del cliente se debe hacer en conjunto entre el equipo de desarrollo y el Product Owner.

Antes de iniciar la construcción del producto es importante identificar la relación entre todos los componentes que harán parte del mismo.

Ejemplo: Una empresa de desarrollo de software planea construir una aplicación para realizar cursos virtuales. Al ser un proyecto de software, en la definición de arquitectura se deberán tener en cuenta los siguientes elementos:

• Bases de datos.
• Servidores de almacenamiento.
• Servidores de procesamiento.
• Nombres de dominio.
• Servidores de procesamiento de correo electrónico.
• Firewall.
• Web services.
• Entre otros.

7.1.6.1 - Sprint Cero

Esta iteración es la primera en realizarse. El objetivo del Sprint Cero es preparar el equipo de proyecto desde una perspectiva tecnológica, metodológica y organizativa, buscando conformar un equipo y no simplemente un grupo de personas.

En esta actividad se analizan y evalúan las posibles soluciones que se pueden establecer para el desarrollo del proyecto.

Estas posibles soluciones pueden ser:

• Herramientas.
• Soluciones Tecnológicas.
• Soluciones técnicas.

Por cada solución escogida se deberá realizar una prueba de concepto, en donde se deben tener en cuenta los siguientes criterios:

• Curva de aprendizaje.
• Escalabilidad (Solo si es solución técnica o tecnológica).
• Soporte.
• Costo. Nota: Este sprint solo se utiliza para los casos en que el equipo de proyecto tiene poca o nula experiencia en la tecnología en la cual se va a construir el producto o incluso si cuenta con poca o nula experiencia en el tipo de producto que se va a desarrollar.

7.1.6.2 - Evaluación y Selección de Proveedores

El propósito de esta actividad es garantizar la selección objetiva de los proveedores, utilizando los criterios definidos por la organización. (Ver más información en la sección - Contratación de Proveedores).