¿Cómo usar Wiki para la gestión de requisitos?

Question

He estado buscando una herramienta colaborativa para desarrollar especificaciones funcionales. Estoy buscando la capacidad de:

• Haz que varios usuarios contribuyan a la especificación.
• Proporcione algún tipo de trazabilidad, que se puede hacer manualmente si es necesario.
• Ofrezca a los usuarios la posibilidad de agregar comentarios y notas.
• Cargar y mostrar documentos de Visio
• Cargar y mostrar pantallas de maquetas utilizando Balsamiq Mockup.

Mi impresión inicial es que usar una wiki podría ser una buena herramienta para esta tarea. ¿Alguien tiene experiencia con el uso de una wiki para crear especificaciones funcionales? ¿Cuáles serían los pros y los contras del uso de una herramienta como esta en comparación con una herramienta de gestión de requisitos?

¡Su opinión es muy apreciada!

Answer 1

Es posible hacer lo que describes, para desarrollar requisitos de forma colaborativa, a pesar de usando una wiki. Nada sobre el paradigma wiki ayuda en este proceso.

Logré un wiki en el proyecto Zend Framework para rastrear propuestas de componentes. They're still using it. Las propuestas son diferentes de las especificaciones funcionales, pero el uso es lo suficientemente similar a su pregunta que creo que es relevante.

Un wiki no se ocupa de sí mismo. A menos que tenga a alguien responsable de administrarlo y asegurarse de que haya cierta estructura y consistencia, rápidamente se convierte en un desastre. La analogía del mundo real sería entregar a cada uno de su equipo una hoja de papel en blanco y decirles que escriban su parte de los requisitos. Los problemas con esto son:

• Todos los contribuyentes tienen que hacer su propia estructura de documentos y escribir sobre cosas diferentes en un orden diferente. Por lo tanto, es imposible comparar una página con otra.
• No hay una "página de índice" para organizar todas las contribuciones dispares.Nadie quiere que una página "caiga por las grietas", pero en una wiki que es el predeterminado destino de cualquier página tan pronto como está escrita.
• No hay ningún ciclo de retroalimentación para asegurarse de que la escritura realmente se realiza.

La manera de hacerlo funcionar es aplicar algún proceso al proyecto, y usar el wiki de acuerdo con ese proceso.

• dar a las personas la posibilidad de crear una nueva página en el wiki, pero sólo a través de una interfaz que enlaza automáticamente la nueva página en el índice derecho.
• Defina un ciclo de vida para documentos, por lo que es seguro que se redactarán, revisarán y aprobarán en las etapas apropiadas.
• Proporcione una plantilla para una página nueva. Proporcione los encabezados de las secciones que necesita en cada una de estas páginas, y haga que parte del proceso de revisión sea una confirmación de que la sección principal se ha completado de manera adecuada.

Answer 2

"¿Cuáles serían los pros y los contras del uso de una herramienta como esta en comparación con una herramienta de gestión de requisitos?"

Si bien parece una gran idea, lo que se encuentra son personas que no pueden y no escribirán.

Las personas que no pueden escribir, bueno, no pueden escribir. No se pueden comunicar con un correo electrónico o una wiki o cualquier medio de voz externo.

• Algunas personas son "desorganizadas". En realidad, escribir es demasiado lineal y no piensan de forma lineal.

• Algunas personas no reciben la "escritura a su audiencia" y escriben cosas que son incomprensibles.

• A veces ni siquiera se da cuenta de lo que están hablando, y mucho menos de lo que están escribiendo. Hablan en jerga o código. No saben mucho pero insisten en ser escuchados.

Algunas personas no escribirán.

• Algunas personas se niegan a asumir compromisos. Incluso en una wiki donde se puede retractar. Sienten que deben discutir todo antes.

• Algunas personas tienen la costumbre de hacer todo dando instrucciones a alguien más. No escriben por sí mismos, o hacen que la gente se quede parada en su oficina y los escuche hablar y escribir.

• Algunas personas son generalmente tóxicas en cualquier tipo de proyecto. Lanzan nuevos requisitos en el último minuto. Su primera respuesta es "eso nunca funcionará". No hacen una buena lluvia de ideas. Cuando dicen que funciona, y les suplicas una mejora, no tienen una. Simplemente saben que no funcionará.

Mi experiencia es que solo los programadores pueden usar un Wiki con éxito. Y solo programadores de alto nivel.

• N00bz no tiene la experiencia suficiente para resolver los requisitos del diseño de los rumores y la gestión de la pelusa.

• N00bz no siempre tienen los conocimientos de idiomas para escribir con claridad. Eventualmente, es posible, pero un vistazo a sus comentarios de Javadoc indica que están luchando con la parte de "claridad" de la escritura.

Es muy atractivo. Espero que las personas mejoren al usar wiki porque creo que podría tener muchas ventajas sobre los enfoques más tradicionales donde una persona entrevista a todos y escribe cosas. Pero requiere un nivel de confianza y habilidad en la comunicación que pocas personas parecen tener.

Answer 3

Las herramientas especializadas ayudan a mantener las cosas en curso e introducen un flujo de trabajo fijo. Este es el tipo de punto, mantener las cosas enfocadas y funcionales. El uso de herramientas genéricas como un Wiki puede ser grande para un grupo de programadores pero introduciendo una para el trabajo 'de modo mixto' puede ser malo:

1. cosas pueden arrastrarse y conseguir fuera de la pista rápidamente
2. comunicación se puede perder en el medio

Mira cosas como Basecamp. Se los puede considerar como una wiki aplicada o una herramienta de colaboración. Una herramienta genérica para fines específicos necesita refinación. No sé si MediaWiki u otros tienen suficiente personalización para mantener las cosas limpias y enfocadas.

Quizás reúna los requisitos para su herramienta de gestión de requisitos (recursivo lo sé) y qué aspectos (aspectos de comunicación) puede tomar de la cultura wiki y una mentalidad de comunicación abierta. Si ni las herramientas de gestión de requisitos ni los wikis se ajustan a la factura, consulte la creación de uno. Puede ser la próxima gran cosa. Se siente como decir ¿Podría usar una wiki en lugar de Bugzilla?

¡Una aplicación de flujo de trabajo fija para la gestión de requisitos con un énfasis de comunicación abierta que permite que las personas de muchos roles puedan ver y comprender podría ser buena!

Answer 4

Considere investigar Fog Bugz. Se anuncian a sí mismos como lo mejor de la mejor para la gestión de proyectos. Considerando la historia de Joel, les daría el beneficio de la duda . Usan una wiki de la manera que acabas de describir.

Sugeriría inscribirse en la versión de prueba gratuita, si habla en serio. Dependiendo del tamaño de su proyecto, comprarlo podría ser una muy buena opción .

Al menos se podía ver cómo se ha estructurado, o leer los foros para obtener ideas sobre cómo construir su propia versión simplificada

Answer 5

Como un término medio entre una forma libre y una wiki herramienta de gestión de requisitos, considere utilizar un structured wiki como Foswiki. No he realizado ninguna gestión formal de requisitos (con un wiki u otro), pero he utilizado TWiki (el predecesor de Foswiki) para otras tareas, y le permite definir un flujo de trabajo, campos de formulario, etc., según lo necesite. ellos, manteniendo la flexibilidad de una wiki cuando no se necesita una estructura formal.

Answer 6

Estoy de acuerdo con todas (la mayoría) de las personas anteriores: el uso de una wiki puede sonar bien, pero las wiki están destinadas a ser información actual y actualizarse según sea necesario, no para ser utilizadas como una herramienta interactiva de gestión de proyectos. Sugiero encarecidamente SmartSheet (soy un firme defensor del producto): proporciona una interfaz de hoja de cálculo en la que puede almacenar múltiples archivos por fila/tarea, enviar actualizaciones automáticas a los usuarios y mantener las revisiones de las especificaciones ... La otra El enfoque podría ser el uso del correo electrónico, los documentos y el calendario de Google, una forma amigable y gratuita de interacción en equipo ... Me abstengo de las herramientas de seguimiento de problemas y errores para la gestión de proyectos. Tienden a tener enfoques diferentes: las herramientas de PM en el todo el proyecto/recurso/línea de tiempo y herramientas de seguimiento de problemas para problemas específicos ingresados ​​....

Answer 7

Hemos usado TWiki y ahora FosWiki en ese contexto. Hay muchas cosas que se obtienen de forma gratuita (control de versiones, control de acceso, acceso a la base web, búsquedas, administración remota, parches de seguridad, ...). En unos minutos, se puede definir: los atributos de los requisitos que definen

• una mesa,
• que crea formas interactivas con selección de campo y validación (donde también se puede documentar discusiones y razonamientos, incrustar imágenes, adjuntar documentos, enlace a otros requisitos ...),
• y luego consulta sobre estos "requisitos" y los muestra como tablas que se pueden clasificar, filtrar, imprimir, informar contra, etc. (por ejemplo, http://jucmnav.softwareengineering.ca/ucm/bin/view/ProjetSEG/JUCMNavRequirementsVer2).

Obviamente, uno puede usar fácilmente hipervínculos y enlaces de Wiki en el camino. FosWiki también tiene características que se pueden usar para imponer flujos de trabajo específicos, si es necesario. También es fácil admitir formularios para casos de uso y otros paradigmas (lo hemos hecho en el pasado, y eso funciona generalmente bien).

Wikis como Foswiki son extensibles y se podría desarrollar más módulos para abordar las deficiencias relacionadas con la gestión de la trazabilidad y análisis de impacto, las modificaciones basadas en tablas de requisitos, el embalaje en general, etc.

Answer 8

Esto puede ser un poco viejo ahora , pero actualmente estoy usando "Confluence" de Atlassian y ha sido genial. Actualmente trabajo como ingeniero de experiencia de usuario interpretando el rol de "Product Owner" dentro de un proceso ágil. Puedo documentar los requisitos para interfaces discretas, permitir comentarios y comentarios de múltiples usuarios, y entrelazar cada interfaz con otras interfaces dentro de un contexto más amplio (por ejemplo, la historia del usuario). Todo es muy dinámico e impulsado por la plantilla. Está satisfaciendo mis necesidades actuales muy bien.