management - Functional Spec & Agile Processes
waterfall methodology pdf (8)
Agile no significa "sin especificaciones". Significa prueba y lanzamiento temprano y a menudo (pero no necesariamente a la producción).
El retraso en Scrum es la "especificación". Si en realidad no escribe ni administra la lista de características, PERDERá las características, y NUNCA podrá saber cuándo se lanzará el producto (no podrá estimar la cantidad de trabajo restante porque tiene ni idea de dónde estás ni cuánto queda por hacer). La lista de características DEBE ser administrada por alguien. La manera más fácil de hacerlo es anotar todo lo que debe hacer el producto (puede ser tan intrincado en la redacción y la definición como desee) y realizar un seguimiento de lo que se ha completado y lo que queda por hacer. ¿De qué otra forma asignarías trabajo a los desarrolladores y reportarías el estado a "administración"?
En Cascada tradicional, se recopilaron los requisitos, generalmente en un documento MS-Word, siguiendo una plantilla esotérica. En un modelo de cascada "estricto", este documento se congela después de la fase de requisitos y un proceso de Control de cambios / Gestión de cambios es responsable de introducir cambios controlados. (**) [Por lo general, el documento se convierte en un "documento vivo" y, finalmente, una "pesadilla viviente"]
Actualmente, tengo que liderar un proyecto que es una reescritura de una aplicación de escritorio existente en la web (desde VB 6.0 a ASP.Net). El cliente tiene una versión actualizada de la aplicación que quiere que se vuelva a redactar. [Así que los requisitos están congelados ... No se arrastra el alcance]. El modelo de datos que se reutilizará tal cual. Solo las reglas de front / Business para migrar. Al mirar la aplicación, creo que es como máximo de 3/4 pantallas principales y eso es todo.
Algunos de los miembros del equipo quieren documentar (en la vieja escuela de pensamiento, en mi opinión) todo antes de comenzar el nuevo desarrollo. Yo y algunos otros pensamos que sería relativamente fácil traducir la IU a la Web, buscar el código antiguo, escribir la lógica comercial, hacer pruebas unitarias automatizadas, realizar pruebas de integración y entregar pantalla a pantalla (o función comercial por función)
Mi pregunta es: en un desarrollo ágil cómo lo hago, me mantengo "ágil" si no fuera para optimizar esto. Mi opinión es que escribir documentación detallada es anti-ágil. ¿Qué piensas? ¿Cómo se acercaría un gurú ágil al problema anterior (de reescribir una aplicación VB 6.0 existente en ASP.Net)?
Descargo de responsabilidad: la creación de una especificación funcional de 1000 páginas podría ser para cumplir obligaciones contractuales, una necesidad política, el sistema podría ser realmente complejo (ahora, la definición de "complejidad" es un viaje a la tierra turbia).
Como tiene un documento que describe lo que debería hacer el producto, lo usaría como la acumulación inicial y comenzaría a dividir el trabajo en piezas de tamaño de mordida ordenadas de la prioridad más alta a la más baja. Cada conjunto de piezas se manejaría durante una iteración. En resumen, use Scrum con su documento inicial como la acumulación.
No iría directamente a la implementación sin hacer este trabajo de priorización. No requiere mucha escritura, sino que hace referencia a las piezas que desea abordar.
No documentaría todo por adelantado.
Además, tendrá algunas tareas directamente relacionadas con la plataforma que abordará y esas tareas deben ser capturadas y agregadas a la acumulación de sprints.
Además, puede darse cuenta de que no desea implementar todos los requisitos después de algunas iteraciones.
He pensado mucho sobre el tema: trabajamos en un entorno de Scrum y hemos tenido dificultades para organizar la documentación.
A lo que me dirijo ahora, aunque es bastante temprano, así que no sé si pasará la prueba a largo plazo, es utilizar una wiki para la documentación.
Básicamente, el flujo de trabajo es el siguiente:
- Las historias aparecen en la acumulación
- La historia es captada por un programador
- El programador hace el código, y en el DoD (Definición de Hecho), también tiene que escribir algunas pruebas en contra de la nueva funcionalidad, y tiene que editar la wiki para agregar una página para la nueva funcionalidad.
El wiki está organizado con plantillas de mediawiki, bastante inspiradas en las páginas de doc. De extensiones de mediawiki, con el nombre de la funcionalidad, la versión en la que se ha introducido, cualquier cosa que pueda ser útil. La plantilla agrega pictos para distinguir entre diferentes tipos de características (y de su estado).
Al final del día, la wiki tiene la gran ventaja de permitirte agregar la página de documentación sin preocuparte por dónde o cómo ponerla, pero obviamente necesitas a alguien que vaya detrás y organice el desorden.
Lo importante a tener en cuenta, independientemente de la herramienta que use, es que el desarrollador debe escribir algún documento justo después de que se haya producido el desarrollo (incluidos los aspectos técnicos), y no antes, y no meses después ...
Si la creación de una especificación de función es una necesidad contractual, debe pensar muy cuidadosamente qué es lo que contiene. Se le puede negar el pago si no entrega lo que promete en su especificación funcional.
Desafortunadamente no vas a ser muy ágil si adoptas este proceso. ¿El cliente realmente quiere las mismas funciones para la aplicación reescrita? Si es así, ¿por qué se vuelve a escribir? Estoy seguro de que hay características que nunca se usan.
No me molestaría en documentar la versión anterior. Ya tiene una referencia, la aplicación en sí misma. No hay ambigüedad en el software.
La escritura de documentos no es anti-ágil. Diseñar algo sin priorizar y obtener retroalimentación de su cliente es. Un aspecto importante de ágil es obtener la aceptación del cliente. Si no lo creen, entonces el proyecto tendrá más dificultades de la debida.
Como ya se señaló, Agile no significa poca o ninguna documentación: "software en funcionamiento sobre documentación integral".
La forma en que abordo la documentación es casi invertir las cosas y considerar casi todo parte de la documentación (incluido el código y las pruebas unitarias como especificaciones técnicas). Por lo tanto, una historia (o cualquier otro mecanismo que utilice para dividir el trabajo) que describa un requisito de negocio / usuario debe ser lo suficientemente detallada como para ser estimada por el equipo que realiza el trabajo; de lo contrario, es incompleto y vago. Además, algo que hago en mi propia práctica, si se estima que la historia (o lo que sea) demore más de un día laboral para ajustarse a la definición del equipo de "hecho", lo más probable es que se descomponga (esta atomización luego compilación finalmente conduce a documentación bastante extensa, pero no asume tantas incógnitas como no hacerlo, y puede conducir a reutilizaciones y revelaciones de patrones bastante interesantes).
Ejemplo utilizando los requisitos de estilo de BDD:
Given I am working on a document
When I select "Save As..."
Then a menu should appear allowing me to choose a name,
and a file type,
and a location in the file system,
and a file should be created in the file system
Es posible que necesitemos / deseemos agregar elementos de la interfaz de usuario para lograr esto, elementos de menú, guiones gráficos, métodos abreviados de teclado, etc. a esta descripción (podemos tener varias variaciones sobre el mismo tema de "guardar un archivo"). Y así.
Todos estos artefactos relacionados se pueden unir a la historia / requisito base; dando como resultado una documentación más completa. Pero solo agregue esas historias que realmente implemente a su documentación de la versión web del software.
Aquí es donde las cosas se ponen de cabeza y se vuelven más "ágiles". Durante el desarrollo y después del desarrollo, se revisan los requisitos documentados y se agregan los cambios / modificaciones / mejoras realizados por las ediciones del equipo (sin tener que pasar por un CCB solo de documentación). La capacidad de editar / actualizar la documentación y los activos relacionados sin pasar por todos los paneles de revisión y otras cosas, o tirar el documento "al revés" cuando descubrimos durante el desarrollo que el documento está incompleto de alguna manera nos permite adaptarnos a las incógnitas, por lo tanto, Ágil.
Esta documentación debe tener alguna forma de control de versiones o historial, que nos permita describir el sistema que deseamos, pero también describir el sistema que realmente se implementó, anotando otras respuestas / sugerencias con respecto a la documentación que forma parte de la Definición de Hecho (algo que también hacer). (Las wikis son buenas para esto, sin embargo, un concepto totalmente integrado es un poco más deseable, por ejemplo, sería agradable relacionar un ticket en un archivo en el tronco en el sistema de control de versiones).
Para concluir. Crear una documentación exhaustiva por adelantado, que no se pueda modificar durante y / o poco después del esfuerzo de desarrollo, le impedirá ser ágil, capaz de adaptarse rápidamente a las incógnitas. Sin embargo, para hacer referencia a Leading Lean Software Development, en el que mencionan que si las políticas no permiten que ciertas prácticas / procesos se usen correctamente, entonces no importa si usted dice que es delgado (o scrum, o ágil).
Una forma de asegurarse de que no está siendo demasiado exhaustivo, probablemente podría haber usado esta forma de pensar en esta respuesta, es escribir solo lo que necesite cuando lo necesite (existen conceptos similares en el desarrollo en general). Otra sería lograr que todos entiendan que no es necesario que intentes resolver todo por adelantado (la mayor transición de Waterfall a Agile): documentaremos cada idea y puede que termine en un lanzamiento o no. Y, finalmente, desaprobar (y eliminar) cualquier cosa que ya no se aplique ... Recuerdo haber visto la documentación de un sistema una vez y, cuando revisé el sistema, la mitad del documento ya no se aplicaba al sistema.
En primer lugar, puede generar documentación y mantenerse ágil , si el cliente o el propietario del producto solicita tener documentación (leer está listo para pagar).
Haga crecer su documentación de forma gradual e iterativa, como lo hará con el código. Pruebe un poco, codifique un poco y ... documente un poco.
Veo tres formas de hacer esto: incluir el tiempo para escribir la documentación en la estimación de tareas, crear tareas específicas de documentación o tener elementos / historias de acumulación de documentación.
El riesgo con las historias de documentación es que se pueden planificar muy tarde, mucho tiempo después de que se hayan implementado, por lo que no lo recomendaré.
Las tareas de documentación tienen la ventaja de ser visibles en la planificación de iteración, por lo que no deben olvidarse o pasarse por alto.
Agile tiene un documento de especificación funcional en forma de la lista de características ágiles, la acumulación de productos e incluso tan lejos en el sprint como las tareas en los eslora también. El hecho de que no se les llame documentos no los hace menos. ¿Y la diferencia con la especificación funcional en cascada? ... La especificación funcional ágil solo contiene lo que se necesita (lol), por lo tanto, es menos voluminosa. ¿Recuerda su "Software de trabajo sobre documentación completa"?
En mi opinión, la especificación funcional es necesaria dependiendo de qué tan involucrado esté el equipo de tecnología con el producto y qué tan alto sea el equipo. Si el equipo técnico está involucrado en la definición del producto, definitivamente necesitará menos documentación porque habrá menos espacio para suposiciones. Si tiene un equipo de ingenieros que son juniors, necesita una documentación más sólida o, de lo contrario, las cosas no se harán de la forma en que se definieron al final de los sprints.
También tenga en cuenta que los equipos remotos necesitan más documentación en forma de especificaciones funcionales debido a la barrera natural de no estar cerca de las partes interesadas y los visionarios del producto. Tener especificaciones funcionales por adelantado es una característica de ágil. Vi una gran cantidad de equipos de tecnología en los que las tareas se describen únicamente por la historia de un usuario y con bastante frecuencia vi que esos equipos no lograban los lanzamientos y cumplían con las expectativas de las partes interesadas.
Este tema es muy amplio y hay muchas opiniones, pero en mi opinión esto se puede reducir al hecho de que los desarrolladores no deberían tener que adivinar los requisitos.
De hecho, creo que el éxito y la calidad de los entregables es inversamente proporcional a la cantidad de suposiciones / suposiciones que los desarrolladores deben hacer. Creo que la agilidad aumenta con lo bien especificado que es algo porque tendrás menos errores y pasarás menos tiempo corrigiendo esos errores.