Concepto
La fase de concepto puede plantearse desde muy distintos niveles de conocimiento:
- Puede necesitarse hacerla desde el principio desde una definición vaga.
- Partir de algo ya madurado por negocio o basado en algo existente pero con otras necesidades añadidas
- Puede ser una migración desde otro sistema y estar muy claro lo que se necesita o incluso contar con un prototipo.
Hay que tener en cuenta que independientemente del punto de partida hay que llegar a un entendimiento compartido (Shared Understanding) entre el equipo de desarrollo y el personal de negocio. Durante la asignatura se van a utilizar herramientas visuales que nos van a ayudar a esa puesta en común de conceptos, necesidades y objetivos. Se utilizarán las siguientes herramientas:
- Mapa Mental (Mind Map): Especialmente indicado para crear un “diccionario común” y relacionar conceptos. Si no se realiza este paso con el cliente se corre el riesgo de que distintas personas entiendan conceptos de forma distinta total o que se queden conceptos relevantes fuera del alcance.
- Mapa de Impacto (Impact Map): Donde se relacionan objetivos de negocio con las tareas de desarrollo previstas (La Pila - backlog) por medio del personal implicado y el impacto que tendrán en este personal. Es una herramienta fundamental para servir de guía de lo que estamos haciendo y vamos a hacer.
- Mapa de Historias de Usuario (User Story Map): Se crea una agrupación de historias de usuario (tareas) organizadas temporalmente y priorizadas. Ayuda a determinar qué es realmente una necesidad. Normalmente sirve para establecer en un diagrama procesos que ya se están llevando a cabo. En este caso podría sustituir al Impact Map.
- Mapa de versiones (Release Plan): Para programar los incrementos previstos (previsión de Sprints). Sirve para ver una secuencia lógica, no para estimar. No se debe tomar como un plan que restrinja el contenido de los futuros sprints.
Nota: Si hay algún concepto desconocido como “La Pila”, backlog o sprint, no hay que preocuparse, se enseñan cuando se explican los conceptos de Scrum.
La ventaja de las herramientas visuales es que son más fáciles de entender que un diagrama UML por parte de los stakeholders. Si se les muestra un diagrama de Casos de Uso ya elaborado en una diapositiva habitualmente dirán que les parece bien a menos que haya errores evidentes o falten casos importantes, pero si se tiene una pared con posits bien estructurada va a ser más fácil poder interactuar con ella y facilitar el entendimiento.
Conocer el negocio es fundamental para realizar un buen desarrollo. Un producto muy bueno técnicamente no es sinónimo de éxito en el negocio. Un producto aceptado por los stakeholders disminuye la resistencia al cambio y aumenta la probabilidad de éxito.
Entender el negocio se trata de un proceso iterativo. Poder contar con un responsable de negocio a diario es lo ideal. En caso contrario hay que extraer lo que el cliente/usuario necesita en las reuniones, encuestas o cualquier forma de captar información que sea adecuada. Es decir, no puede limitarse a “tomar nota” de forma pasiva, debe extraerse información útil para el desarrollo ya que, en general, el cliente no es muy detallista y esperará que el desarrollador “ya sepa lo que hace falta”.
Conforme se va consiguiendo ese entendimiento se debe ir registrando en documentación que sirva de explicación de por qué se ha hecho lo que se ha hecho y por qué no se ha hecho otra cosa.
Nota: a veces este último punto es clave pues el desarrollo se hace dentro de un contexto que en un futuro puede cambiar: legislación, tecnología, recursos, alcance objetivo, etc… por lo que disponer del trasfondo de por qué se tomo una decisión en concreto es útil a la hora de alcanzar un contexto que explique otra decisión.
La documentación que registra el trabajo conceptual del producto consiste en tres documentos principales:
- Estudio de Viabilidad del Sistema (EVS)
- Especificación de Requisitos de Software (ERS)
- Definición del Producto Mínimo Viable (MVP)