Ejemplos específicos de documentación ágil?

En una respuesta a la pregunta Documents for a project?, Chris Ballance respondió que "User Stories" and a "burndown chart" are the two most useful types of project documentation for a developer.Ejemplos específicos de documentación ágil?

Mi pregunta es, ¿sabe de cualquier buen ejemplo [s], que puedo ver (por ejemplo, en Internet o en una libro), de este tipo de documentación?

Si es posible me gustaría ser feliz de ver muchos ejemplos, incluyendo:

pequeños ejemplos/cortas/simples
grande/larga/ejemplos complicados
Ejemplos famosos
de alta calidad ejemplos

No encuentro este tema fácil para Google: encuentro muchos escritos sobre él, pero hay menos demostraciones que muestran t.

Fuente

2009-02-10 ChrisW

Un muy buen lugar para comenzar en cuanto a libros se refiere es User Stories Applied y Agile Estimation and Planning ambos por 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 recursos de Internet que son pocos y distantes entre sí. 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é. He aquí algunos ejemplos: Burndown Chart y User Stories

Tenga en cuenta sin embargo, mientras que un gráfico de quemado es un informe simple que se ejecuta en sus puntos de historia actuales quedan en una iteración, historias de usuario son más complejo que eso y no se requiere un poco de leyendo para envolver tu cabeza. Comience con User Stories. Libro aplicado para eso.

Espero que ayude!

Fuente

2009-02-10 20:27:39

Me sorprende escuchar que "recursos de Internet son pocos y distantes entre sí": son estos tipos de documentación que no se utilizan en la práctica, entonces, por "equipos virtuales" (es decir, por los desarrolladores distribuidos geográficamente) en desarrollo de código abierto (es decir, proyectos disponibles al público)? Si no, ¿puedes especular sobre por qué no? – ChrisW

Actualmente trabajo en un equipo ágil remoto y, por supuesto, utilizamos herramientas remotas, pensé que se refería a un aspecto del aprendizaje ágil. Para las herramientas virtuales, tiene opciones como Acunote, TargetProcess, Unfuddle. Estas herramientas son útiles para equipos remotos, pero no deberían reemplazar un tablero de corcho cuando sea posible. –

Así que creo que estás diciendo que las historias de usuario, etc. * son * usadas por equipos virtuales; pero, tienden a no estar en los sitios web, porque en su lugar se crean utilizando herramientas [como las que usted citó] que no sean la web. – ChrisW

Considere leer el "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

Fuente

2009-02-10 20:28:46 Uri

Simplemente explicar por qué no crear toneladas de UML no sería una respuesta a mi pregunta. – ChrisW

Disculpe, no tuve tiempo para escribir algo más completo, la mayoría quería referirlo al libro. Discute sus alternativas para usar casos y lo que sería importante capturar. – Uri

unos meses, empezamos a escribir la documentación del usuario, al mismo tiempo que estamos desarrollando características. Se asigna un escritor técnico a cada equipo de Scrum.

tener que escribir la documentación del usuario mientras que el desarrollo 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 burndown liberación y burndown sprint.

documentación adicional es creado por el equipo cuando se sienten que es útil para comunicarse con el dueño del producto. Esto se volvió menos importante a medida que aprendemos a escribir mejores historias de usuarios.

Fuente

2009-02-10 22:38:25

Siempre he pensado que una especificación funcional es la documentación más útil. La documentación del usuario es una subclase de especificación funcional, IMO. Entonces, si está diciendo que la documentación del usuario es suficiente y que es bueno desarrollarla antes y/o con el software, me parece plausible. – ChrisW

En realidad, la documentación del usuario puede ser suficiente para los desarrolladores ("¿qué funcionalidad de usuario final estamos construyendo?") Pero no para los administradores de proyecto ("qué están haciendo * en este sprint * y, a la inversa, qué funcionalidad de menor prioridad se triaged y se ignora al menos hasta la próxima vez? "). – ChrisW

Creo que para ambas preguntas, usted puede hacer mucho peor que escanear a través de la página web de Alistair Cockburn. En particular, tiene un gran artículo tablas de quema y algunas maneras distintas de generar ellos sobre:

http://alistair.cockburn.us/Earned-value+and+burn+charts

(thoug Me hago eco de la recomendación del cartel anterior de 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á en un proyecto "pequeño" por cualquiera de las definiciones de docena de pequeñas, puede estar bien con historias muy ligeras. He aquí un ejemplo, una vez más desde el sitio de Cockburn:

http://alistair.cockburn.us/Examples+of+ultra-light+use+cases

Fuente

2009-02-11 04:48:40