Software/plataforma para compartir especificaciones

Question

¿Cuál es el software/Wiki que utiliza para escribir y compartir sus especificaciones sobre los desarrolladores, los evaluadores y la administración?

¿Utiliza el sistema Wiki y, en caso afirmativo, qué software Wiki utiliza?

¿O utiliza Sharepoint para administrar y versionar las especificaciones? Un problema con SharePoint 2003 como plataforma de especificaciones es que es muy difícil colaborar con diferentes personas.

Por razones de compatibilidad con versiones anteriores, también me gustaría que la plataforma pueda importar Microsoft Word a la perfección. Y sin duda ayudaría si la interfaz es similar a Microsoft Word.

¿Alguna idea?

Answer 1

He usado Confluence en varios lugares, es una wiki bastante poderosa y muy buena para crear especificaciones que se pueden compartir entre varias partes. Ver:

http://www.atlassian.com/software/confluence/

Hay un poco de más información aquí sobre las ventajas de la utilización de Confluencia:

https://stackoverflow.com/questions/170352/confluence-experiences

EDIT: He actualizado este para hacer frente a la función de importación de Microsoft Word que mencionado. Confluencia apoya esto a través del conector Oficina aquí:

http://www.atlassian.com/software/confluence/plugins/office-connector.jsp

También hay un Sharepoint conector:

http://www.atlassian.com/software/confluence/plugins/sharepoint-connector.jsp

además de un montón de plugins:

http://www.atlassian.com/software/confluence/plugins/sharepoint-connector.jsp

Algunos de estos son contribuciones del usuario también. No puedo recomendar Confluence lo suficiente como una wiki comercial.

También he usado JSPWiki, que es de código abierto. No está mal pero no tan buena como la confluencia, ver:

http://www.jspwiki.org/

Answer 2

Utilizamos SharePoint - no es ideal, pero hace un trabajo decente. Si yo fuera usted, consideraría seriamente salir de SharePoint 2003 y seguir a MOSS (SharePoint 2007). No es perfecto, pero es sustancialmente mejor. Aquí hay un poco sobre cómo usar MOSS as a wiki. Creo que, en general, las wiki son una buena herramienta para que las personas se familiaricen con su sistema. Solíamos pasar por "documentos para comenzar" y ahora tenemos todo ese tipo de cosas en nuestro portal para desarrolladores.

Según el comentario de John, busqué this feature comparison. Tengo que volver atrás y ver qué funciones estoy usando que no están en WSS: ¡podría estar pagando licencias que no necesito! :)

Answer 3

Usamos el correo electrónico. Sé que no es elaborado, pero es fácil de usar. Todos lo tienen instalado y no hay problemas de licencia.Todos los cambios de especificaciones se envían a una distribución de correo electrónico súper establecida que indica las actualizaciones y la ubicación en la red donde se puede encontrar la especificación.

Answer 4

Utilizamos Alfresco, en su versión comunitaria, tanto desde su Participación e interfaces Web Explorer. Bastante útil, con una biblioteca de documentos, wiki, foro y calendario. Hospedamos aproximadamente 1.8 Go, principalmente en documentos, versiones y, a veces, convertido automáticamente a PDF (creando una regla de contenido automático). FTP, WebDav y el recurso compartido de red también se utilizan para acceder al mismo repositorio.

Answer 5

Se puede echar un vistazo a Microsoft Groove - el software de colaboración que Microsoft compró hace unos años.

Se incluye de forma gratuita con las versiones premium de Microsoft Office.

se puede personalizar el espacio de trabajo con foros de discusión y bastante perfección puede almacenar documentos de Office editado en colaboración.

Answer 6

Utilizamos MediaWiki para DOS & especificaciones. Wiki definitivamente gana algo como Microsoft Word o SharePoint: le permite desarrollar una documentación en la forma de "primero consulte, luego describa" = "divide y rige". Perfecto para los desarrolladores: solían pensar de la misma manera. El proceso de desarrollo de una documentación es casi ideal: comienza desde el TOC y profundiza hasta que escribe el documento para cada enlace que coloca antes.

MediaWiki es bastante personalizable, hay muchas extensiones allí. Los más necesarios son:

• Fuente código rotulador - CSO_Source
• Nuestras propias plantillas que integran wiki con referencia clase.
• Otros son InterWiki, FileProtocolLinks, YouTube (utilizamos una versión personalizada de este para mostrar video de alta definición), ReCaptcha, SpecialDeleteOldRevisions, Maintenance.

Algunos ejemplos de integración son here.

Y utilizamos Google issue tracker para realizar un seguimiento de los temas. Sus principales ventajas son:

• Imputibilidad de uso: el proceso de agregar \ cambiando el problema es realmente conveniente. Anteriormente probamos Track Studio - las mismas acciones requieren 2-3 veces más tiempo allí, por lo que murió rápido simplemente porque la mayoría de nosotros odiaba usarlo.
• Rejillas personalizables. Vea el examples. De mucha ayuda.
• Soporte de Atom \ RSS. Entonces, todos saben lo que está pasando.
• Hay una herramienta Gurtle que lo integra con TortoiseSVN. De mucha ayuda.

Su principal desventaja es que no se puede cerrar desde el acceso público. Esto lo hace simplemente inutilizable en muchos casos.

Answer 7

Usted podría intentar Google docs - He utilizado con éxito en el pasado. Es compatible con la importación/exportación a MS Word, y tiene un gran soporte para múltiples usuarios - ver http://www.brighthub.com/internet/google/articles/8236.aspx.
Admite el control de versiones, le permite chatear con otras personas que están trabajando actualmente en el documento y le muestra una lista de todos los cambios que otros han realizado en el documento (sin necesidad de cerrar/volver a abrir el documento).

Si desea soporte corporativo, Google también proporciona eso - vea Google Apps for business.

Answer 8

Si desea una interfaz de usuario similar a Word, ¿por qué no utilizar Word con SharePoint 2007? Estás en 2003, así que la experiencia está ahí. Actualice a SharePoint 2007 y puede tener la colaboración, las funciones de Word, compartir documentos, etc.

Este es el tipo de cosas que Microsoft quiere que la gente a usar para la Oficina, así que hay un montón de mana por ahí acerca de cómo configurar el entorno de SharePoint y Office para apoyar la colaboración.

Answer 9

hay algo que Google puede hacer en este sentido y se ve muy cool: wave.google.com. Sería un gran paso en la colaboración y vale la pena esperarlo.

Answer 10

Aquí usamos Google Docs, hace que los documentos estén disponibles para todos los que escriben o leen solo, públicos o privados entre personas que tienen o no cuentas de Google, también puede importar documentos de Word, sin mencionar que se ejecuta directamente en el navegador por lo que tiene alta disponibilidad con costo cero y configuración cero, también es independiente de su computadora/sistema operativo, tenemos una experiencia agradable con él.

También tal vez debería echar un vistazo a Basecamp o Mochila al 37Signals, cualquiera de estos también podría ajustarse a su factura.

Answer 11

Utilizamos DocBook para todas nuestras especificaciones (y otra documentación para el cliente). DocBook es un formato XML que le permite generar fácilmente documentos en casi cualquier formato, incluido PDF, que es la forma en que distribuimos las cosas a los clientes para que se cierren. Podemos dividir un documento en archivos (por sección) y comprometer todo a nuestro sistema de control de fuente (Subversion). Debido a que es todo XML (es decir, basado en texto), la fusión automática y la resolución de conflictos de Subversion funcionan muy bien si dos personas trabajan en el mismo archivo. Tenemos un conjunto de hojas de estilo que utilizan todos nuestros documentos, por lo que todos los documentos comparten exactamente el mismo estilo/formato, sin ningún trabajo adicional de nuestra parte.

Y si no te gusta editar archivos XML directamente, hay interfaces de interfaz gráfica de usuario que proporcionan una experiencia razonablemente similar a WYSIWYG. Creo que la mayoría de las personas en mi oficina usan XMLMind. Aún así, todos somos personas técnicas, por lo que si tuviéramos que escribir XML directamente, no sería un problema.

Como anotación al margen, sino que también ponen a cabo notas de la versión. Tenemos algo de XSLT que nos permite escribir documentos como éste:

<bugs> 
    <bug id="1234" component="web">JavaScript error when clicking the Kick Me button</bug> 
</bugs> 

entonces tenemos un script que se ejecuta a través de nuestro repositorio de Subversion haciendo un svn log de la etiqueta de versión anterior a la etiqueta de versión actual y una cierta integración Bugzilla de forma automática generar notas de la versión sobre la marcha.

(también, para la mayor parte interna de sólo la documentación, se utiliza MediaWiki, que es también una gran manera de colaborar.)

Answer 12

Utilizamos OnTime. Originalmente solo se usaba para el seguimiento de defectos, pero también hemos comenzado a usarlo para rastrear características. Se pueden usar para documentar la característica a medida que evoluciona durante el desarrollo. Las características se pueden agrupar en sprints o lanzamientos, y se puede rastrear el tiempo con cada característica. Si está utilizando SCRUM, también puede graficar gráficos quemados para cada sprint. También tiene funcionalidad wiki.