documentation - que - ¿Ejemplos específicos de documentación ágil?
title html ejemplos (5)
En una respuesta a la pregunta ¿ Documentos para un proyecto? , Chris Ballance respondió que "User Stories" y un "burndown chart" son los dos tipos más útiles de documentación de proyecto para un desarrollador.
Mi pregunta es, ¿conoces algún buen ejemplo [s], que pueda ver (por ejemplo, en Internet o en un libro), de este tipo de documentación?
Si es posible, me gustaría ver muchos ejemplos, que incluyen:
- Ejemplos pequeños / cortos / simples
- Ejemplos grandes / largos / complicados
- Famosos ejemplos
- Ejemplos de alta calidad
No encuentro que este sea un tema fácil de tratar para Google: encuentro muchos escritos sobre él, pero hay menos demostraciones que lo muestran.
Considere leer "Modelado ágil" de Ambler. Explica muy bien por qué la simple creación de toneladas de UML completos es una idea bastante mala y ofrece algunos buenos ejemplos.
Hace unos meses, comenzamos a escribir la documentación del usuario al mismo tiempo que estamos desarrollando funciones. Se asigna un escritor técnico a cada equipo de Scrum.
Tener que escribir la documentación del usuario mientras se desarrolla ayuda a validar el diseño. El escritor técnico también participa en el diseño de la aplicación.
Esto es, además de la versión de lanzamiento y la reducción de sprint.
El equipo crea documentación adicional cuando sienten que es útil comunicarse con el propietario del producto. Esto se volvió menos importante a medida que aprendemos a escribir mejores historias de usuarios.
Un buen lugar para comenzar en lo que respecta a los libros es Estimación de usuarios aplicados y Estimación ágil y planificación, ambos de Mike Cohn. Esto tiene excelentes ejemplos y buenos puntos de partida para cualquiera que primero se acerque a las metodologías ágiles.
En cuanto a los recursos del sitio web, son pocos y distantes. Probablemente, un buen lugar para comenzar sería buscar esas palabras clave en Google Images, ya que muchas personas toman fotos de sus gráficos de quemadas y User Stories. Esto me ayudó mucho cuando comencé. Aquí hay algunas muestras: Burndown Chart e User Stories
Sin embargo, tenga en cuenta que aunque un gráfico de quemados es un informe simple que ejecuta en los puntos de historia actuales que quedan en una iteración, las historias de usuarios son más complejas que eso y requieren un poco de lectura para entender. Comience con User Stories. Libro aplicado para eso.
¡Espero que ayude!
Creo que para ambas preguntas, puede hacer mucho peor que escanear en el sitio web de Alistair Cockburn. En particular, tiene un excelente artículo sobre los gráficos burndown y algunas formas diferentes de generarlos:
http://alistair.cockburn.us/Earned-value+and+burn+charts
(Aunque me hago eco de la recomendación del cartel anterior sobre el trabajo de Mike Cohn).
Uno de los trucos es decidir qué tipo de documentación es buena para TU proyecto. ¿Tienes muchos desarrolladores, repartidos en el tiempo y el espacio? Necesitarás historias más grandes, pesadas y detalladas. ¿Tienes uno o dos desarrolladores trabajando en el mismo lugar? Puedes salirte con los más ligeros. ¿Ha trabajado el equipo en el sistema (si es legado) durante mucho tiempo? Las historias ligeras probablemente lo hagan. ¿El equipo es nuevo en el sistema o sus requerimientos de negocios son complejos? Esto lo empuja en la dirección más detallada.
Si estás en un proyecto "pequeño" según cualquiera de las doce definiciones de pequeño, puedes estar bien con historias muy ligeras. Aquí hay un ejemplo, nuevamente del sitio de Cockburn:
http://alistair.cockburn.us/Examples+of+ultra-light+use+cases
Este artículo muestra un par de tablas de tareas reales. http://www.mountaingoatsoftware.com/task-boards