¿Trabajas con Scrum? ¿Te suena "Inception Deck"?

¿Trabajas con Scrum? ¿Te suena "Inception Deck"?

La Inception Deck o solo Inception son un conjunto de dinámicas en las que deben participar todos los implicados del proyecto, indistintamente de su grado de implicación. Estas dinámicas están orientadas a que todo el mundo comparta la misma visión del producto, conocer los riesgos existentes y las necesidades para abordar el proyecto exitosamente.

El objetivo principal de la fase de inception es conseguir unificar la visión que del producto tienen todos los implicados en el proyecto. A menudo, al iniciar un proyecto todo el mundo tiene clara su propia visión del producto. El problema viene cuando nos damos cuenta que no todo el mundo tenía la misma visión de dicho producto, y cual es la misión a realizar.

La visión del producto es el principal objetivo, pero no el único. También queremos concretar:

• Alcance.
• Dependencias.
• Primeros pasos necesarios antes de poder empezar el primer sprint.
  • Conocer al equipo.
  • Product Backlog:
    • Taller de historias.
    • Taller estimación (Alto nivel).
    • Taller de priorización.
    • Refinamiento del product backlog.
  • Forma de trabajo:
    • Arquitectura a alto nivel.
    • Herramientas.
    • Entornos disponibles.
    • Cómo se obtendrán los datos de prueba.
• ¿Existe fecha de release fijada?
  • Velocidad objetivo.
  • Tamaño del equipo objetivo.
• Riesgos.
• Prioridades.
• Expectativas finales.

Visión

Como hemos comentado anteriormente, es crítico que todo el mundo esté alineado en las funcionalidades de las que constará el producto.

Para ello, se pueden utilizar diferentes dinámicas como el "elevator pitch" (discurso de ascensor), o el "product box" (caja de producto).

• Elevator pitch: Esta técnica no es nada nuevo, ni nada del mundo del agilismo. Viene de los 80s y del mundo de los negocios. Consiste en condensar la información sobre el producto en un pequeño discurso que llame la atención de alguien en pocos segundos o minutos. Para ello debemos contestar a 6 preguntas y dar el nombre del producto.
  • Para: ¿Quién?
  • De los cuales: ¿Qué lo motiva?
  • Nombre del producto.
  • Es: ¿Qué es?
  • Qué: Principal característica.
  • A diferencia: ¿De quién nos diferenciamos?
  • Nuestro producto: ¿Qué ofrecemos diferente?

Ejemplo de elevator pitch de Sngular:

"Si eres un techie, que siempre está atento tanto a las nuevas tecnologías como a las nuevas oportunidades, Sngular agrupa a más de 300 compañeros entre sus diferentes áreas de especialización como VR,RX,Desarrollo Ágil, Cloud, Data&Analytics… Lo que nos une es que todos amamos la tecnología y la innovación, lo que nos diferencia de las demás empresas es nuestro ambiente laboral, uno de los valores más resaltados y el ambiente colaborativo por el que se apuesta, haciendo de las personas su principal valor."

• Product-box: Esta dinámica está enfocada a diseñar la que podría ser la caja del producto si lo vendiéramos en los grandes almacenes. La caja del producto, o su envase, está orientada a convencer al cliente que su producto es mejor que el de la competencia. Para ello se recomienda proporcionar las 3 principales características del producto y un slogan.

Personas

No hay que olvidar que cualquier proyecto tiene un fin último, y es que el producto o servicio que se construya sea utilizado por personas. Cada vez con más frecuencia,  y con buen criterio, los productos se diseñan con el usuario final en mente, como centro y guía de las decisiones de diseño que se deben tomar.

Para ello, es importante tener una visión común de quién o quienes van a ser nuestros usuarios, hacer un proto-tipo de los mismos (proto-personas), ponerle nombre, profesión, imaginar cual es su medio de vida, intereses, miedos y motivaciones y reflejarlos en lo que se denomina un mapa de empatía. Entendiendo a nuestros usuarios, como personas, seremos capaces de tomar mejores decisiones al llevar a cabo nuestro proyecto  

Atribuciones para la toma de decisiones

Una de las cosas más importantes es decidir quién va a decidir determinados aspectos esenciales. Entre ellos, pueden estar cosas tan importantes como

• Quién prioriza las historias de usuario en el backlog.
• Quién decide el alcance de un sprint.
• Quién decide que una historia está lista para ejecutarse (Definition of Ready, DoR).
• Quién decide que una funcionalidad está terminada correctamente (Definition of Done, DoD).

Pero también puede que haya que dar atribuciones para decidir:

• Si hay que contratar más personal.
• Si hay que dar formación a un miembro del equipo.
• o si hay que revisar un salario.

Estos aspectos es necesario hacerlos patente en la incepción del proyecto.

En estos puntos, hay que hacer convivir los puntos de vista del Product Owner (PO) y del equipo (Team), para ver quién tiene las atribuciones para la toma de decisiones.

Se establece en una “matriz de delegación” quién va a tomar dichas decisiones. Como la mayoría de las cosas en la vida, no todo es blanco ni negro, y en dicha matriz se considera un abanico de siete posibilidades, que van desde el extremo en el que el Product Owner decide unilateralmente y sin consultar al equipo, sólo informándole (nivel 1, o “Tell”); hastas el extremo en el que es el equipo el
que decide unilateralmente y sin consultar al Product Owner, sólo
informándole (nivel 7, o “Delegate”).

Entre medias, una serie de opciones intermedias:

1. Tell: El PO decide, sin consultar. Luego comunica al equipo.
2. Sell: El PO decide primero, y luego trata de convencer al equipo con sus argumentos.
3. Consult: El PO consulta al equipo primero, pero luego es él quien decide.
4. Agree: La decisión se toma conjuntamente entre el PO y el equipo.
5. Advise: El equipo consulta primero al PO, que da su opinión, pero luego es el equipo quien decide.
6. Inquire: El equipo decide, y después trata de convencer al PO con argumentos.
7. Delegate: El equipo decide, sin consultar al PO, al que luego comunica su decisión.

Alcance

Una vez tenemos clara la dirección en la que queremos ir hay que concretar hasta dónde queremos llegar o hasta dónde nos es rentable. Esto, al igual que la visión, no es más que una gestión de expectativas. Queremos que todo el mundo tenga claro qué es lo que se va a realizar: puede que haya personas relacionadas con el proyecto que quieran llegar más lejos de lo que el presupuesto permite, o que desarrollar una funcionalidad sea necesario pero sin demasiado esfuerzo, pues no aporta un valor de negocio, por lo que no debemos dedicarle muchos recursos.

People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. Innovation is saying no to
1,000 things.” – Steve Jobs

La lista del “NO”

Hay pocas cosas que aclaren tan bien la visión, misión y alcance del proyecto como hacer explícito lo que NO vamos a hacer, lo que NO está en el alcance, y que todos los implicados tengan una visión común de estos aspectos. Tan valioso como hacer patente estos aspectos, es hacerlo con aquellos que no están claros o sobre los que no se llega a un acuerdo. Es antes de iniciar el proyecto cuando deben decidirse, y no cuando ya se está en ejecución, momento en el cual cualquier ampliación de alcance o malentendido de cara a los stakeholder (el famoso “yo pensaba… yo creía…”) tiene mala solución, y un impacto en coste, plazo y sobre todo, en expectativas.

Dependencias y Vecinos

Es habitual que nuestro proyecto no sea un proyecto aislado y forme parte de un portfolio. En estos casos, es más que probable que existan proyectos o departamentos que dependan o simplemente necesiten estar informados en mayor o menor medida de nuestro proyecto y por supuesto de cuales dependemos nosotros. Del mismo modo, nosotros podemos depender de terceros, ya sea porque nos tengan que definir políticas de seguridad o porque tengan que desarrollar algún servicio que debamos consumir. Por ejemplo, en caso de haber un departamento de seguridad informática que nos va a dictar unas reglas, es importante conocerlo cuanto antes, ya que si nos enteramos a mitad del desarrollo puede ocasionar una gran variación del plan.

Como parte de la incepción del proyecto, se deben hacer patentes quienes son los vecinos del mismo. Es decir, aquellas personas (con nombres y apellidos, no valen nombres de departamentos), que sin estar en el día a día del proyecto, van a ser necesarias en algún momento para abordar ciertas tareas clave.

Taller de historias + Taller de priorización

Más que una dinámica, es una reunión para poblar el Backlog de historias y priorizarlas. Por el momento no hace falta una gran definición de la historia pero sí ha de contener unos datos mínimos.

• Titulo: Descripción breve.
• Descripción: Ha de contestar a 3 preguntas ¿Quién?¿Qué?¿Por qué?
• Criterios de aceptación.

Definición: DoR y DoD

El Definition of Ready (DoR) es una lista de todas aquellas cosas que serán necesarias para poder empezar a desarrollar una historia. Ha de ser informado por el equipo de desarrollo. Un ejemplo muy genérico de DoR podría ser:

• La historia está suficientemente clara y comprendida por el equipo de desarrollo como para ser completamente desarrollada.
• Todas las dependencias están identificadas y ninguna de ellas impedirá que la historia sea completamente desarrollada.
• La historia está estimada y es lo suficientemente pequeña como para poder ser abordada completamente dentro de un solo sprint.
• Los criterios de aceptación son claros y testeables.
• En caso de ser necesario, los criterios de rendimiento están definidos y son testeables.
• El equipo scrum sabe cómo podrá mostrar la funcionalidad en la Sprint Review.

El Definition of Done (DoD) ha de ser definido por el equipo scrum al completo, y una tarea no se podrá dar por acabada hasta que se haya cumplido. Esto quiere decir que si llega el día del sprint review y nos falta aunque sea solo un punto de la lista no deberemos mostrar la funcionalidad. El DoD puede ser muy variado dependiendo del proyecto ya que puede incluir todo aquello que consideremos oportuno
para no volver a tener que tocar la funcionalidad a no ser que se solicite un cambio. Un ejemplo genérico podría ser:

• Todas las tareas están completadas.
• Se ha realizado el "Code Review".
• El código compila y pasa todos los test (ya sean unitarios, funcionales, de aceptación de usuario, de rendimiento, de integración, los que se hayan definido como necesarios).
• El código está comentado y la funcionalidad documentada.
• El tiempo restante de la historia se ha puesto a cero y se ha cerrado.

Taller de estimación y refinamiento

El objetivo es tener el product backlog completamente estimado a alto nivel; no se trata tanto de ser preciso como de, al menos, tener una expectativa. Posteriormente procederemos a refinar las historias más prioritarias. Desglosaremos las funcionalidades en historias más pequeñas y éstas en tareas, hasta tener al menos capacidad para abordar en 1.5 o 2 sprints. Al mismo tiempo que refinamos estas historias, procederemos a revisar el DoR y el DoD. Esta labor es imprescindible ya que, cuando empecemos el primer sprint, lo haremos con un sprint planning en el que seleccionaremos las historias más prioritarias que tengan su DoR completo hasta completar nuestra capacidad disponible en el sprint.

Pasos previos al primer sprint

• Conocer al equipo scrum: Conocer las fortalezas de cada parte integrante del equipo: siempre es importante saber a quién se puede recurrir ante según qué dudas.
• Forma de trabajo: Tras esta fase, los integrantes del equipo conocerán o habrán llegado a un acuerdo acerca de:
  • Arquitectura a alto nivel. Quizás incluso se haya empezado a desarrollar lo mínimo e imprescindible junto con el esqueleto del proyecto; todo lo necesario para poder empezar a trabajar sin tener que dedicar tiempo a la configuración de los equipos o a tomar decisiones de cómo abordar las partes más generales.
  • Herramientas: Decidir cuáles se van a utilizar para el control de código fuente, el análisis de la calidad del código, gestor y contenedor de dependencias, framework de test unitarios, framework de test funcionales... Y por supuesto la configuración necesaria para tenerlas operativas.
  • Entornos disponibles. Es necesario conocer de qué entornos se va a disponer y la capacidad de integración continua existente. En algunos casos no se dispondrá de estos datos porque formen parte del proyecto, en cuyo caso, deberíamos disponer de personas con el conocimiento adecuado (DevOps). En caso de que los entornos ya existan deberemos  investigar cuál va a ser el modo de interactuar con ellos y definir entre otras cosas "cómo", "quién" y "por qué" puede hacer un cambio de entorno.
  • Cómo se obtendrán los datos de prueba. ¿Los podremos generar nosotros o dependeremos de terceros? En caso de ser lo segundo, ¿Qué información nos solicitarán?

Riesgos

• ¿Qué nos impide dormir? Es el momento de poner sobre la mesa todas aquellas cosas que prevemos que nos puedan causar dificultades, y solicitar aquellas que consideramos necesarias para el adecuado desarrollo del proyecto.
  • Nos interesan aquellas sobre las que podemos actuar.
  • ¿Qué necesitaríamos?

• SWOT: Strenght, Weakness, Opportunities, Threats.

Size  it up

Teniendo el backlog estimado aunque no sea preciso, nos podemos hacer una idea del tiempo que nos puede llevar realizar el proyecto con los recursos de los que disponemos. La idea no es comprometerse a una fecha pero sí tener una orientación razonada de si serán 3, 6 o 9 meses o quizás 1 o 2 años. Esto nos podrá decir si el proyecto es viable para nuestro cliente o si necesitaríamos más recursos para cumplir
con sus expectativas.

What’s going to give?

No es lo que queremos, pero en algún momento es posible que debamos elegir entre algunas de las características del proyecto. En tal caso, deberemos saber cuál es más importante para el cliente. Hay
veces que claramente es el coste, otras la fecha pero, ¿y si debemos elegir entre otras de sus características? Según el proyecto las características pueden variar pero considero que estas 5 siempre
serán pertinentes:

• Alcance.
• Presupuesto.
• Tiempo.
• Calidad.
• Sencillez de uso.

El objetivo es priorizar cuál de ellas es más importante y ordenar la lista entera según su importancia. De este modo tendremos una idea, en caso de necesitarlo, de qué deberíamos sacrificar en caso que
sea totalmente imprescindible para lograr el objetivo del proyecto.

What’s it going to take?

Ya hemos dado una estimación de tiempos, la cual quizás hasta nos haya hecho variar el equipo, pero ya tenemos una estimación aproximada del tiempo que durará y del equipo necesario. Ahora es momento de juntar todas las variables y realizar una estimación del coste del proyecto. Por supuesto es posible que el coste ya haya sido cerrado; en tal caso, podemos realizar una simulación de hasta dónde se podrá llegar o si el proyecto es o no viable con las premisas con las que se han trabajado.

Del mismo modo puede ser que aún no tengas equipo (en tal caso te habrás saltado algunas de las fases anteriores); éste es el momento de exponer los conocimientos y características necesarias del equipo, las infraestructuras esperadas o cualquier otra cosa que nos pueda ser relevante.

Conclusiones

Seguramente no te hayamos sorprendido demasiado con ninguna de las distintas partes del artículo, son todas cosas lógicas pero, sorprendentemente, muchas veces por unos motivos u otros no pasamos
por todas ellas. De hecho, tampoco planteamos que todas sean obligatorias (cada proyecto puede ser muy diferente), pero lo que sí es recomendable es que al menos hayan sido contempladas.