Como organizar las historias para que:
- Proporcionen una visión general del sistema
- Permitan anotar detalles donde haga falta
- Sirvan para planificar qué vamos a hacer cuando
- Resulten fáciles de convertir en código
Las cosas tienen que esta a su tiempo. Si tenemos una hora, no hay más. Es muy difícil muchas veces. Muchas veces es mucho más práctico decidir antes que bien. La diferencia entre tarde y mal no es tanta. Las cosas van a ir cambiando. Es menos importante pasarse el rato discutiendo que ir probando. Al final del proyecto, tiene que haber el trabajo equivalente al curro de todos. No hay tiempo para tocarse las narices mientras uno sólo integra. El ritmo frenético va a ser costumbre. Básicamente repartirnos las cosas es la clave. El mismo problema a distintos niveles es lo que vamos a hacer todo el puto curso.
Si hacemos bien los repartos, todo el mundo curra, luego se junta y sale todo bien. Lo mismo hay que hacerlo con el tiempo total del proyecto. Que no haya dependencias sería lo mejor. Tendremos que hacer un diseño que nos permita identificar partes diferentes del código que nos permita dividirlo y luego integrarlo casi sin hablar entre nosotros. Qué herramienta usamos para esto? Bazaar.
Cómo probamos toda nuestra aplicacion entre todos, no uno sólo?
Confieso que todos los que hemos dicho que esto era muy apresurado tenían razón. Estamos intentando reproducir un fenómeno que pasa en una empresa a escala. No tenemos tiempo para hacerlo más real.
Lo que hicimos ayer se hizo muy deprisa, pero como había que hacerlo. Objetivos: repartir trabajo, a una escala diferente. Si hubiéramos tenido la sensacion de hacerlo mejor una persona sola, en un proyecto real, probablemente sí que lo hubiera hecho una sola persona.
Paso siguiente:
Tenemos:
1- Historias (sin tecnología, sólo decisiones). Si cambiamos de tecnología, esto tiene que seguir valiendo
2- Interfaces. El dibujo de la tecnología
3- Tecnología. Hay que ir asignando tecnología a cada una de esas historias.
Traspa 2: Casos de uso
- Cada forma en que alguien usa el sistema
- Fragmentos de funcionalidad que el sistema ofrece para aportar un resultado de valor para quien interactúa con el
- Especifica una secuencia de acciones que el sistema puede llevar a cabo interactuando con otros elementos, incluyendo alternativas dentro de la secuencia.
Tiene que corresponderse con una funcionalidad que se puede probar y desarrollar por separado. La idea es que cada historia pueda probarse por separado. Los casos de uso se pueden descomponer en casos de uso más pequeños dependientes de la tecnología. Lo básico es para la funcionalidad, no para un objetivo. Desglosarlo vendrá después, a la hora de hacer el diseño. Tenemos que garantizar que cada una de esas cosas pueda funcionar por separado.
Cuenta la historia de cómo se alcanza un objetivo. o un conjunto de historias de cómo se consigue un objetivo, o cómo se intenta, pero no se consigue el objetivo.
EJ:
Hacemos un pedido:
- se identifica al cliente, se pide qué pedido quiere y cuantos quiere. Se pone el pedido en cola.
- Si el cliente no se identifica, no tiene dinero, no queda stock, se jode el objetivo.
Opciones: si no tiene crédito, se le pide por adelantado, se le ofrece menos cantidad de producto.
Actor
- Cada tipo de usuario o cada sistema externo que interactúa con el sistema (terceros fuera del sistema que colaboran con el sistema)
Si nos tenemos que conectar a una base de datos que no implementamos nosotros, esto es un actor más. Si nuestra app se tiene que comunicar con el SO, probablemente el SO sea un actor. Esto sale en la tecnología, pero no sale en las historias.
El nombre del caso de uso es el objetivo a cumplir. siempre tiene que ser un verbo en infinitivo.
Howtodoit:
- Identificar casos de uso, actores y objetivos
- Cuantos actores, con comportamiento, van a participar en nuestro sistema?
- Qué necesita cada actor que haga el sistema?
Historias: secuencias de objetivos cumplidos por alguno/s de los actores
Para cada caso de uso:
Escribimos el recorrido más simple de caso: cuando se cumple el objetivo. Todo lo demás es una complicación de éste. Tiene que ser el más facil de leer. Hay que capturar la responsabilidad de cada actor, su papel para obtener el objetivo. Decir que información se pasan unos actores a otros, eso hay que modelarlo más tarde. En cada punto se pone un numerito.
Teniendo el recorrido principal, para cada fallo que pueda ocurrir en cada paso, hay que identificarlo y hacer una rama. Refiriendo a los numeritos, cuando falla el 1, abajo de todo ponemos 1A y contamos que ocurre en este primer error del paso 1… Extensiones recuperables, sí al dar un fallo podemos pasar a otro número. Se pueden escribir como "if". Tiene que ser fácil de leer. Estamos intentando compactar. No debería haber nada escrito dos veces ni en el codigo ni en la documentación, por eso, esta forma sirve. Con esto empezamos a tener un caso de uso completo.
Ojo porque muchas veces tenemos esta vision de que el tratamiento de errores lo hacemos si nos da tiempo, pero aqui no podemos, esto es crítico.
Si identificamos al usuario muchas veces, tiene sentido hacer un caso de uso de identificación al usuario, y desde otros sitios hacemos referencias.
Caso de uso #1: Arrancar Sistema
Objetivo en contexto
Entradas
Precondiciones
Salidas
Poscondicion en exito
" si fallo
Actores
Secuencia normal
" alternativas
Tambien la frecuencia de uso de estos casos de uso, y qué tiempo de respuesta tienen que tener. Esto son requisitos especiales.
Glosario: Que elementos de nuestro dominio tiene que quedar muy claritos para que no se confunda nadie.
