En mi caso, siempre he encontrado que el nivel de detalles necesarios para los casos de uso completo se obtiene al pensar primero en mis historias de usuario. La primera pregunta que hago es "¿qué necesitan las personas para poder hacer?". Una vez que tengo los escenarios, es más fácil comenzar a analizar todos los casos de uso y variantes de flujo para el sistema.
Dicho esto, para un solo desarrollador que trabaja solo, realmente no necesita preocuparse si se trata de un caso de uso o una historia de usuario o una pegajosa en la pared que dice "no se olvide de 'x'". Lo que necesita es cualquier proceso que lo haga pensar en lo que sus usuarios están tratando de lograr y lo ayude a rastrear las diferentes cosas que deben poder hacer. Todo lo demás depende de usted en cuanto al nivel de detalle que necesita escribir para planificar su desarrollo.
Por ejemplo, cuando trabajo en un proyecto paralelo en solitario, mis tareas de trabajo se ven así:
- Iniciar sesión
- Ver lista de 'foo'
- Guardar selecciones de la lista
- Buscar
Honestamente, cada uno de ellos no tendría nada más que una estimación. ¿Por qué? Porque solo los estoy usando como un recordatorio de lo que necesito para que el usuario pueda hacer y descubriré los detalles cuando llegue a esa parte. Con un equipo de una sola persona, todo puede estar en tu cabeza y eso está bien, porque no tienes que comunicarlo a nadie más.
Ahora, hay advertencias ...
Desarrollador único que trabaja con otros especialistas.
¿Necesita informar sobre el progreso a otro equipo? ¿Tienes probadores que necesitan validar tu trabajo? ¿Tiene una administración que quiere saber lo que ha hecho? ¿Tiene un gerente de proyecto que necesita predecir una línea de tiempo? ¿Tiene un propietario de producto que determina las características que se requieren?
Si estas personas son parte de su proyecto, entonces debe asegurarse de que sus tareas de trabajo tengan suficiente información sobre ellas para permitirles hacer su trabajo. El primer ministro probablemente necesita una forma de ver los tamaños relativos de las cosas y progresar en ese trabajo. Sus evaluadores necesitarán detalles sobre cómo se espera que fluyan las cosas (casos de uso) e incluso puede pedirles que lo ayuden a escribirlos. Es posible que la administración quiera saber en qué está trabajando, por lo que necesitará una descripción comercial suficiente para que puedan comprender las características que ofrecerá.
Si respondió 'sí' a todas esas preguntas, probablemente necesite tener una acumulación de documentos más rígidamente documentada, ya que la usará para comunicarse con los otros miembros de su equipo.
- Es probable que necesite tener el concepto de 'Epics' o 'Características', que será la funcionalidad de alto nivel que puede usar para informar a la gerencia o a los propietarios de sus productos.
- Habrás historias de usuario anidadas dentro de esas epopeyas / características que definirán los bloques más pequeños de funcionalidad que se usarán para comunicar el progreso con tu gerente de proyecto, definirán tus tareas de trabajo dentro de un sprint y se usarán para comunicar el objetivo comercial al equipo de prueba
- Tendrá casos de uso o casos de prueba definidos para las historias para capturar las diversas decisiones de flujo de bajo nivel que se requieren para asegurarse de que usted, la empresa y el equipo de prueba estén alineados y sepan qué se aceptará como "correcto".
Todo lo anterior puede ignorarse si usted es quien define el trabajo, administra el progreso, prueba el software y decide si algo es "correcto". Reduzca el esfuerzo adicional y asegúrese de hacer lo que es importante: ¡crear software que funcione!