El Post pasado comentamos las principales etapas de un proyecto, comenzando desde su contexto histórico, pasando por el nacimiento de los procesos basados en iteraciones, y finalizando con el nacimiento de Agile, Scrum y sus similares. Finalmente vimos como las etapas según un proyecto PMI y un proyecto Scrum no son tan diferentes, simplemente cada uno lo ataca desde un lugar diferente. PMI desde un punto de vita más genérico, y Scrum desde un punto de vista enfocado 100% al desarrollo de Software. Recuerda que este esto forma parte de una serie de Posts, por lo que, si no has leído los anteriores, te recomiendo revisarlos desde el principio.

En esté post platicaremos primero del alcance del proyecto a desarrollar, luego veremos cuales son las principales actividades que se ejecutan durante cada una de las etapas del proyecto. Nos enfocaremos en las etapas siguiendo el proceso Scrum, pero cuando haga falta también mencionaremos etapas o documentación más relacionadas con PMI.

Alcance Definido (Proyecto) vs Alcance Indefinido (Operación)

Como lo mencione en el Post anterior, si trabajas en desarrollo de software, lo más seguro es que estés ejecutando en una de dos maneras:

• Proyectos con un Alcance Definido (Proyecto):
  • Estos respetan siempre la naturaleza finita del proyecto, es decir, buscan tener un principio y un final muy claro.
  • Para esto es indispensable especificar un alcance. Que se va a hacer, que no se va a hacer.
  • Si el alcance cambia, el tiempo y el presupuesto deben de cambiar.
  • Este proceso es más común en consultoría a clientes.
• Proyectos con un Alcance Indefinido (Operación):
  • Este tipo de software no tiene un final. Por lo menos no en papel. Estos se llevan con procesos más operativos como Kanban, aunque también es común usar Scrum.
  • El alcance va moviéndose en base a las ideas que vayan presentando los usuarios, filtrados por el Product Owner, se decide que va a hacerse y se agrega Backlog.
  • Ya que no hay tiempo ni presupuesto definido, se pueden hacer cambios a las actividades sin ningún problema.
  • Es un proceso más común con empresas con productos de software. Aunque se puede dar también en consultoría en proyectos por consumo de horas.

Lo importante es que todo el equipo, y principalmente el Scrum Master y el Product Owner, tengan muy claro qué tipo de ejecución se va a hacer, o se está haciendo. Una no es compatible con la otra. Y el tener claro esto es la primera y más importante tarea del Scrum Master. No hacerlo siempre provoca que el cliente comience a solicitar cosas adicionales, sin que entienda que estás están fuera de alcance. Esto se tiene que detener al momento.

“Todo el equipo debe de saber si se está trabajando si se está ejecutando con un Alcance Definido o Indefinido.”

Se que la naturaleza del Agile habla de aceptar libremente los cambios. Sin embargo, en un proyecto con alcance, tiempo y presupuesto fijos, debe de existir un proceso de control de cambios, y todo cambio deberá mover el alcance, tiempo y presupuesto, o en su defecto, ser intercambiado por otra funcionalidad. Todo bajo aprobación del cliente. No es la manera ideal de hacer software, pero es muy común en regiones como América Latina donde casi todo se hace con presupuestos cerrados.

En otros países de primer mundo, o con clientes que entienden mejor el mundo del desarrollo, la manera de hacerlo es hacer un estimado de horas. Con dicho estimado, se arranca un proyecto sin un alcance definido, y el cliente decide que funcionalidad ir agregando, en base a cálculos de dificultad hechos por el equipo de desarrollo. Esto es un verdadero proceso de Scrum, es mucho más sano, y mucho más eficiente.

Pero hay que aprender a vivir con los 2. En mi caso constantemente estamos trabajando clientes con los dos esquemas, además de los productos internos. Las siguientes secciones mencionare que cambios pueden aplicar para cada tipo de ejecución. También iré mencionando las diferencias si estás trabajando en un proyecto interno, o es un proyecto que se está ejecutando para un cliente.

Como último consejo. Si estás trabajando con un cliente que no sabe lo que quiere, todos conocemos alguno, nunca trabajes con Alcance Cerrado. Vas a tardar más tiempo en definir ese alcance, que en hacer el proyecto.

Inicio – Product Backlog

Product Backlog – Levantamiento Inicial

Antes de arrancar un proyecto, ya sea de manera interna, o para cotizar a un cliente, es necesario hacer un levantamiento inicial. En este se trata de recaudar toda la información requerida para generar una cotización o un alcance inicial. Esto lo hace usualmente un Analista, Programador Sr, o Scrum Master con habilidades técnicas.

Si estás trabajando un proyecto con Alcance Definido, es indispensable establecer el alcance a detalle. La manera en la que hacemos esto suele ser por medio de la definición de roles del sistema e historias de usuario. Establecer que historias se van a hacer, y quien las va a ejecutar. Todo esto se pone en el documento Acta de Inicio. Estás historias funcionan como la base del Product Backlog.

En un proyecto más Agile, la intención es apoyar al que será asignado como Product Owner, a hacer un listado inicial de las funcionalidades que quiere que tenga el sistema, con la intención de enseñarle como comenzar a hacer un Product Backlog, como definir la prioridad de las funciones, y como acomodarlas para que tengan sentido en un proceso de desarrollo.

Documentos Adicionales PMI

Si estás trabajando, utilizando PMI, y si tu proyecto es con un Alcance Definido te recomiendo hacerlo, durante el levantamiento se suelen también hacer los siguientes documentos:

• Lista de Interesados – Es un documento sencillo que simplemente documenta todos los interesados en el proyecto, su participación, roles y datos de contacto. Es un documento que recomiendo, aunque no estés siguiente PMI.
• Documento de Riesgos – Es un listado de los principales riesgos detectados durante el levantamiento. Esto nos ayuda a detectar las actividades que pueden tomar más tiempo de lo estimado, actividades en las que no se tiene la experiencia o se necesita investigación. Ambas cosas muy comunes en desarrollo de Software.
• Plan de Trabajo – Un estimado de las fechas en las que se realizarán las actividades. En desarrollo no sirve mucho ya que usualmente las actividades se van adecuando al progreso del proyecto. Si alguna vez haces uno, que quede claro con el cliente que es solo un estimado y no un compromiso.
• Listado de Entregables – Los administradores de proyectos PMI les fascina crear documentos para entregar como resultados. Estos documentos normalmente no aportan valor. En desarrollo lo importante es entregar el Software funcionando, y si acaso un Acta de Aceptación del cliente de que se entregó y funciona según lo solicitado.

Durante el Sprint – Planeación

Sprint Planning – Definición del Sprint

Una vez que se arranca el proyecto, estaremos haciendo Sprints, o iteraciones de entre 2 y 4 semanas. Para empezar un Sprint, primero se hacer una reunión llamada Sprint Planning. En esta reunión se definen las historias o funcionalidades a hacer durante el sprint en base a su prioridad y numero de esfuerzos. Si las estimaciones de esfuerzos son muy iniciales, se le puede pedir aclaraciones al Product Owner para mejorarlas. Dependiendo de cómo trabaje el equipo, se puede o no hacer asignación de las tareas a cada persona.

Detalle de Historias y Prototipado de UX / UI

Una vez que se definió que se va a hacer, comenzamos el proceso de desarrollo de la funcionalidad. Es en este momento en el que el Analista se junta con el Product Owner, y algunos otros usuarios para documentar a detalle lo que se requiere en la funcionalidad o historia de usuario. Se busca establecer el rol que utilizará la historia, y los requisitos funcionales y de reglas de negocio que se tienen que programar. También se define el concepto “Definición de Finalizado” (Definition of Done), que es lo que validará el Product Owner para dar por terminada la funcionalidad.

Con esta información, el Analista y el Diseñador construyen un prototipo o maqueta de las pantallas a realizar. Esta debe de ser aprobada por el Product Owner antes de comenzar el desarrollo.

Estas tareas pueden ser intercaladas con el desarrollo, para que, en un Sprint se definan tareas y prototipos, y en el siguiente se ejecute su desarrollo.

Sprint o Iteración – Ejecución

Desarrollo

Durante la ejecución del Sprint, los desarrolladores se ponen a programar lo solicitado. Se utilizan como principales fuentes de información las Historias de Usuario y el Prototipo, pero habrá muchos casos donde existan dudas adicionales. Estás debe de ser preguntadas inmediatamente con el analista, o si hace falta escaladas hasta el Product Owner.

La idea es que durante el desarrollo se vayan validando los detalles con el Product Owner, para que en la etapa de Pruebas ya únicamente se hagan las validaciones de la “Definición de Finalizado”.

Daily Scrum – Monitoreo y Control

Cualquier persona que haya participado en un Proyecto con Scrum, sabe lo que es el Daily Scrum. Es una junta muy rápida (15 a 20 minutos) con el Scrum Master y el equipo de desarrollo para establecer:

• Que se hizo el día anterior.
• Que se pretende hacer el día de hoy.
• Si hay alguna limitante o bloqueo para la ejecución de las tareas de hoy.

Esta es la principal actividad de Monitoreo y Control en Scrum. En ella se pretende poder detectar retrasos antes de que sucedan y apoyar al equipo a que tenga todo lo necesario para seguir trabajando.

Sprint o Iteración – Pruebas

Sprint Review – Presentación de Resultados

En esta tarea se presenta al Product Owner los resultados del Sprint, es decir, las funcionalidades o historias finalizadas. La intención es que las pueda ver y aprobar, validando que cumplen con la Definición de Finalizado acordada previamente.

Es importante aclarar, que cualquier ajuste o cambio que se solicite durante esta revisión debe de ser evaluado. Por ejemplo: Si el Product Owner solicita algo que no estaba definido en la historia, como una funcionalidad adicional, un campo, o una nueva función, o incluso cambios a la interfaz, esta se considerará como una nueva historia. Se trabajará dependiendo la forma de ejecución del proyecto como un Control de Cambios, o como una nueva Historia al Backlog.

Control de Cambios

Si se está haciendo un proyecto con Alcance Definido, cualquier cambio detectado en esta o cualquiera de las etapas debe de ser correctamente documentado, evaluado, y analizado los posibles impactos que tendrá en tiempo y recursos, y las posibilidades para ejecutarlo. Este documento será presentado al Product Owner, y de ser aprobado con sus respectivos impactos, se agregará al Backlog como una tarea adicional y se priorizará siguiendo el proceso normal.

Sprint o Iteración – Entregas y Retrospectiva

Puesta en Marcha

Finalmente, para cerrar el Sprint, se debería de publicar una nueva versión del Software. Esto depende mucho del proceso de publicación, ya que puede ser una versión al final del Sprint, o si hay procesos de DevOps la publicación de cada funcionalidad apenas se apruebe. Esto usualmente le corresponde a un responsable de sistema o a un equipo de Operaciones.

Sprint Retrospective – Cierre

Finalmente, la junta para dar por cerrado el Sprint. Esté es el principal proceso de mejora en Scrum. En esta junta, se pretende analizar la ejecución del Sprint. Que salió bien. Que salió mal. Que vamos a hacer o seguir haciendo. Que vamos a dejar de hacer. La intención es poder crear un proceso de evaluación y mejora continua. Esto lo podemos hacer analizando el número de esfuerzos, los retrasos y los problemas que surgieron durante el Sprint, y definir qué hacer para mejorar el siguiente Sprint.

Resumen

En este Post platicamos la importancia de que todo el equipo debe saber, que tipo de proyecto estas trabajando. Con un Alcance Definido, o con un Alcance Indefinido. Si tienes un Alcance Definido, cualquier funcionalidad adicional deberá ser evaluada, y tendrá impacto en el tiempo, funcionalidad y recursos, por lo que cualquier cambio es costoso, es más común en trabajo con clientes. Si trabajas con un Alcance Indefinido, se pueden adoptar cambios de manera ágil simplemente ingresándolos al Backlog, pero este tipo de proyectos no pueden tener ni un tiempo, ni un numero de recursos definidos. Es más común en proyectos internos o desarrollo de productos. Recuerda:

• Alcance Definido: Es necesario definir el alcance. No es flexible, cualquier cambio en alcance provocará un cambio en tiempo y en recursos. Aunque no es la manera correcta, muchas veces la necesidad (clientes) nos obligan a hacerlo así.
• Alcance no Definido: Se define un Backlog inicial, y se va trabajando en base a prioridad. Es flexible. Los cambios se pueden agregar al Backlog y priorizar en el proceso normal. No debe haber calendario ni recursos definidos. Es la manera correcta, eficiente y efectiva de hacer Software.

Posteriormente vimos las actividades que se realizan en cada etapa según el proceso Scrum.

• Inicio
  • Product Backlog o Levantamiento Inicial
  • Documentos Adicionales PMI (Interesados, Riesgos, Plan de Trabajo, Entregables)
• Sprint
  • Planeación
    • Sprint Planning o Definición del Sprint
    • Detalle de Historias y Prototipado UX/UI
  • Ejecución
    • Desarrollo
    • Daily Scrum – Monitoreo y Control
  • Pruebas
    • Sprint Review o Presentación de Resultados
    • Control de Cambio
  • Entregas y Retrospectiva
    • Puesta en Marcha
    • Sprint Retrospective