tutorial que office caracteristicas sharepoint documentation moss wiki

que - Documentación para desarrolladores: Sharepoint Document Management vs. ScrewTurn Wiki



sharepoint tutorial (11)

Actualmente estamos utilizando una combinación de ambos, sharepoint para especificaciones y documentos formalizados y un Wiki para "conocimiento tácito". Cada una de nuestras soluciones tiene una página en la wiki y esto funciona muy bien debido a la facilidad de agregar contenido.

Información de fondo

Estoy trabajando en la configuración de un método para que los desarrolladores de mi empresa compartan documentación e información sobre nuestros diversos sistemas internos. Esto podría abarcar desde información que sería útil para poner al día a un nuevo empleado hasta descripciones de problemas comunes que los usuarios tienen con los sistemas y sus resoluciones.

Esto me pareció un trabajo ideal para un wiki, y como nuestra empresa solo tiene la capacidad de alojar aplicaciones ASP.NET, me puse a investigar los wikis de ASP.NET disponibles. ScrewTurn Wiki parecía ser el más apropiado, tiene muchas funciones y hay varios complementos disponibles que serían útiles para mi situación, incluidos el resaltado de sintaxis y la integración de AD.

Sin embargo, al iniciar el proceso para instalar ScrewTurn en nuestra intranet, se recordó repentinamente que, bueno, Sharepoint 2007 tiene una wiki, y como ya tenemos configurado Sharepoint, ¿no podríamos usarlo? Hice una pequeña evaluación de la "wiki" de Sharepoint (entre comillas porque apenas califica), y pude demostrar que no sería adecuado debido a sus muchas deficiencias, que no voy a enumerar aquí.

Ahora, en este punto, se ha sugerido que tal vez no necesito una wiki en absoluto, ¿no podríamos simplemente hacer todo en documentos de Word y usar la funcionalidad de administración de documentos de Sharepoint en su lugar?

La pregunta actual

Entonces, lo que estoy buscando es un poco de munición adicional, preferiblemente de personas con experiencia. ¿Cuáles son ejemplos de cosas que serán difíciles o imposibles con Sharepoint en el contexto de la documentación interna del desarrollador? ¿En qué es mejor un wiki? Oye, soy de mente abierta, ¿en qué es mejor Sharepoint?

¿Qué hará que valga la pena implementar un wiki en lugar de simplemente usar lo que ya tenemos?

Como una generalización, la palabra es bastante horrible para los documentos técnicos. Debido a que funciona muy mal para documentos grandes y estructurados, fomenta la proliferación de documentos pequeños sin referencias cruzadas entre documentos. Escala esto a cualquier tamaño significativo y tendrás problemas para encontrar qué documentos pertenecen a un problema que estás tratando de investigar. A medida que pase el tiempo, encontrará personas que pierden cada vez más tiempo buscando en una maraña de documentos de Word, hojas de cálculo, diagramas de visio e incluso presentaciones en PowerPoint para encontrar información que pueda o no estar registrada.

Ponerlos en sharepoint simplemente lo obliga a encaminar su búsqueda a través de un navegador.

Cualquier herramienta de documentación técnica debe admitir referencias cruzadas entre documentos para evitar perder esas referencias. Un wiki logra esto mucho mejor que la palabra nunca lo hará. Además, es mucho más fácil incorporar contenido generado, como diccionarios de datos o documentos API en una wiki, y puede hacer que los objetivos de XRef sean estables.

En primer lugar, echa un vistazo a este hilo . Se hizo una pregunta similar acerca de las wikis de Sharepoint, y las respuestas tanto pro como con son realmente útiles y resumen la parte de su pregunta como "imposible en Sharepoint".

Estoy en el medio de intentar implementar una wiki de equipo en Sharepoint ahora mismo casi por lo mismo que tú, después de haber usado Sharepoint para documentos de equipo durante un par de años. Mis observaciones:

Sharepoint Document Libraries

Mi experiencia es que Sharepoint para documentos es decente. Puede ser inestable y, a veces, perderá ediciones o tendrá problemas de rendimiento, aunque un buen equipo de soporte de Sharepoint puede ayudar con algo de eso. Encontré las bibliotecas de documentos de Sharepoint mejor que almacenar cosas en la red. Hace que los documentos y las bibliotecas sean fáciles de enlazar. El uso juicioso de las propiedades de metadatos puede hacer que una vista de lista de Sharepoint sea muy útil para ver qué es el documento, para qué sirve y en qué estado se encuentra, por lo que nuestros analistas, PM, desarrolladores, etc., saben de un vistazo quién tiene La pelota y cuando algo los espera. Eso comenzó para un proyecto hace un par de años; hoy los flujos de trabajo de Sharepoint 2007 probablemente pueden proporcionar notificaciones.

También hay control de versiones para los documentos. Pero como otros han señalado, hacer cosas en documentos tiene gastos generales y fallas en la composición, descarga y uso compartido. Las verificaciones de documentos ayudan, pero los desarrolladores de cañones sueltos pueden descargar documentos, editarlos y almacenarlos en otro lugar, lo que anula el control de versiones. Esto nos ha sucedido, aunque es un problema de disciplina y no es culpa de Sharepoint.

Sharepoint Wiki

Según la respuesta de Chris Hynes, la fricción es una buena palabra para describir el problema. Para una referencia rápida de los detalles de la infraestructura interna de un equipo, la wiki parece funcionar mejor para nosotros. La wiki hace que los datos se vean casi instantáneamente, sin tener que hacer clic en un enlace primero y esperar a que Word se cargue. Las ediciones también son más rápidas y fáciles ... y aunque todavía estoy experimentando con ellas, las wikis de Sharepoint tienen control de versiones y permiten "verificaciones" de artículos de wiki.

Como usted y el otro subproceso SO señalaron, en comparación con otros motores de wiki, Sharepoint es ligero. ¿En qué es mejor? Bueno, lo estoy usando porque está ahí, no requirió ninguna configuración especial, mejor que nada, y francamente, funciona bien para cosas internas que no tienen que ser robustas o orientadas al cliente. Es fácil venderle al jefe porque no cuesta nada más de lo que ya hemos gastado. La wiki tampoco se puede comprometer tan fácilmente por los tipos de cañones sueltos que mencioné anteriormente, y podríamos ver la pista de auditoría o la reversión si es necesario.

Es fácil agregar y entrecruzar entradas, aunque si desea incrustar gráficos, primero debe cargarlos en una biblioteca de Sharepoint. También puede editar el HTML en la wiki, aunque no estoy seguro de qué limitaciones hay con eso, y el control del CSS creo que no está disponible sin acceso de seguridad y Sharepoint Designer. Así que cualquier cosa que no sea texto (como tablas) no es muy robusta.

Hasta ahora me gusta más que almacenar todo como documentos. La inmediatez de ver y editar los datos le da a la wiki una ventaja real. Sin duda, es más fácil que bajar un documento y volver a registrarlo. Con el desarrollador promedio que muestra aversión, ayuda a eliminar las barreras que impiden mantener la información actualizada.

Algo más a tener en cuenta. ¿Esperas que tus desarrolladores sean entusiastas y participen activamente en la edición del wiki? Si es así, es posible que desee las características de discusión de un motor de wiki diferente. Mis desarrolladores son como la mayoría; Las dos cosas que más odian son las pruebas y la documentación. Así que soy el tipo que está creando artículos que explican el procedimiento de compilación, el uso del entorno de la base de datos, las instancias de la aplicación, el mapa del servidor, la lista de verificación de la documentación de SOX, etc. La mayoría de los desarrolladores se referirán y publicarán actualizaciones menores. Nuestro soporte de versiones y concurrencia no está siendo muy estresado.

Es mucho más probable que se use un wiki que un grupo de documentos de Word simplemente porque es más rápido y más fácil encontrar una entrada para editar o crear una página nueva de lo que será un grupo de documentos de Word.

La pregunta entonces es qué wiki.

Casi cualquier wiki es mejor que el wiki de SharePoint, que uno está más allá de una broma

Screwturn es excelente, tiene ACL y WYSIWYG en v3, y es muy fácil de extender

Por ejemplo, el uso del complemento XSLT es ideal para incrustar la salida de procesos del servidor, compilaciones de CI, pruebas, estadísticas de control de fuente, etc.

por ejemplo, tenemos un complemento OLEDB que lee valores críticos de varias bases de datos de la empresa y los integra en páginas que describen qué son los datos y qué valores deberían tener. Tenemos una página maestra que enumera todas las páginas que tienen datos fuera de los rangos prescritos. Una especie de mezcla de FIT y una herramienta de monitoreo de sistemas

Si tiene una posición de administración en "todo" tiene que estar en SharePoint, entonces hay complementos de Screwturn que representan las páginas de Screwturn como PDF, HTML, xml, etc. (puede convertir a docx en ese momento) y tienen un script para volcar el screwturn cambiado. Páginas cada noche a SharePoint para fines de búsqueda y "administración".

Es posible que desee consultar Confluence , ya que es probable que sea la wiki empresarial líder en el mercado. También hay un conector de SharePoint para esa wiki. Como uno de los colaboradores del Conector de SharePoint, estoy un poco sesgado, pero probablemente te estés haciendo un mal servicio si no verificas algunas de las opciones disponibles. Los wikis pueden ser poderosos y contagiosos, pero esto no sucederá si el wiki está por debajo de la media.

Espero que esto sea de alguna utilidad - puntos extra o no :)

SharePoint Server (SPS) o Windows SharePoint Services (WSS) es MUY bueno si está trabajando con documentos de Office: puede realizar versiones, registrar / eliminar, compartir, buscar, etc. No creo que haya nada en el mercado que se acerque a esa función (también hace listas personalizadas y esas cosas realmente bien).

Pero como señala, la función WIKI es, bueno, sub-estándar.

Para la documentación del desarrollador, un wiki es mucho mejor, ya que puede interconectar fácilmente documentos, ¡e incluso si por la única razón que los desarrolladores tienden a LE GUSTAR el marcado de wiki! Hace sentir que están escribiendo código, no un documento. Bueno, ok, me gusta. Documentos de Word? Frustración sin fin, especialmente para fragmentos de código y cosas como API''s. Los wikis usualmente manejan el código y el formato estructurado realmente, muy bien

Pero aquí está el punto principal de mi publicación:

Si puede alojar ASP.NET, y si tiene SPS, ¡ya puede hacerlo! - entonces simplemente instale AMBOS DE ELLOS. Cree un nuevo host virtual de IIS, coloque STW en ese (porque SPS estará en su propio host virtual) *. Masajea un poco el DNS (para que puedas golpear http://wiki o algo así), y simplemente hazlo.

Como todo es interno a su compañía, y STW tiene versiones y seguridad de Windows, la seguridad no es un gran problema. Cada página se puede vincular desde cualquier lugar, es una página HTML después de todo, por lo que puede vincularla desde la wiki de SPS si realmente lo desea. Hay algún bloqueo, supongo, pero no mucho.

Aquí en BBC Worldwide, utilizamos una serie de tecnologías:

  • Confluencia de Atlassian (WIKI) para algunos proyectos. Me encanta este wiki, pero es un gran sistema empresarial.
  • Tornillo Gire para algunas cosas dentro del departamento.
  • Trac para algunas otras cosas (alguien más lo configuró con SVN en nuestro repositorio de origen, por lo que se usa un poco; es bueno, me gusta, pero es un a * se para la configuración)
  • SPS / WSS para la gestión de documentación.

hay enlaces entre STW, Trac y SPS; por ejemplo, tratamos de no almacenar documentos como archivos adjuntos en trac, en lugar de vincularlos en SPS, etc.

Funciona bien.

En cuanto a la munición: SPS funciona bien si se ajusta a lo que usted quiere hacer (o USTED puede ajustarse a lo que hace TI). Si no, estás jodido, o necesitas hacer muchos dev, lo que realmente es lo mismo :)

Pero aparte de que la administración se está volviendo divertida, no puedo ver un problema con la instalación de ambos. STW es libre después de todo. Tienes servidor (s).

Y recibe los documentos de escritura del desarrollador, lo que rara vez es algo malo. Ok, es algo malo si los humanos reales tienen que leerlo, ¿pero para otros desarrolladores? Todo bien.

* nota: host virtual. DIRECTORIO no virtual.

He hecho ambas cosas. Después de esas experiencias, aquí está mi sugerencia:

  • Si necesita WYSIWYG y no le importa la cantidad y la falta de características de Sharepoint (la wiki es simplista, pero tiene las funciones principales que necesita en una wiki), vaya con eso. Funciona como un wiki y ayuda cuando las personas de negocios tienen que ir al wiki - mucho menos tiempo enseñándoles a usarlo, etc.
  • Si puedes trabajar con barebones y solo quieres un wiki simple que sea rápido y flexible, no puedes vencer el tornillo.

En cuanto a la razón por la que se usa un wiki, ya sea destornillador o sharepoint, es mejor que los documentos de Word en Sharepoint con las manos hacia abajo. Para usar Sharepoint, primero tiene que descargar el documento, editarlo, cargarlo o usar la integración de Office, lo cual es, en el mejor de los casos, una opción. Los wikis eliminan toda la fricción y hacen que sea muy fácil de actualizar. Eliminar la fricción es clave, porque cuando tienes que trabajar con documentos de Word, terminas no actualizándolos tan a menudo como deberías. Con una wiki, es una transacción de 2 segundos de entrada / edición / guardar. Con Word Doc, se tarda minutos en cargar Word, abrir el documento, editar, preocuparse por el formato, guardar, etc.

Hey tengo experiencia aquí. Comenzamos a usar ScrewTurn en el trabajo, pero nos pidieron que cambiáramos porque la empresa ya había comprado SharePoint. La calidad de la documentación disminuyó porque los documentos de Word no son compatibles con una wiki, y como otros han señalado, SharePoint no está a la par.

En mi opinión, nada mejor que un wiki para la documentación. Creo que es principalmente la capacidad de crear enlaces a páginas que aún no existen. De esa manera puedo borrar la documentación y el resto se completa según sea necesario. Hace la documentación más concisa y legible.

Con los documentos de Word, no es muy probable que se utilice el hipervínculo, pero es muy útil para la legibilidad de la documentación. Podría seguir...

Nadie podría estar contento con el wiki de SharePoint comparándolo con cualquier otro sistema de wiki.

Entonces, no lo compares. Tiene las características básicas necesarias para que una wiki sea útil: puede ingresar (de alguna manera) texto con un formato rico, junto con enlaces a otras páginas, ya sea que existan o no. Al hacer clic en un enlace a una página inexistente lo llevará a una página de edición para la nueva página vacía, permitiéndole guardar la página.

Sí, el soporte de imagen apesta. Primero debes crear la imagen, luego pegar la URL de la imagen. Entonces, tómate dos minutos y crea una biblioteca de imágenes para publicar imágenes de wiki en.

Recuerde los objetivos principales de una wiki: no competir con otras herramientas de la wiki, sino escribir ideas rápidamente, sin detenerse para estructurarlas. La estructura se puede agregar más tarde, si es que lo hace.

Como han dicho otros, telerik ofrece un reemplazo para el editor de texto enriquecido, hay un proyecto de CodePlex que funciona (lentamente) en las mejoras y, personas, es SharePoint. Si no te gusta, puedes personalizarlo. Es ASP.NET, servicios web y Windows Workflow Foundation.

No recomiendo a nadie que salga y compre una licencia MOSS solo para implementar un wiki (o blog, para el caso). Pero si ya tiene la infraestructura de SharePoint (quizás como parte de Visual Studio Team System Team Team Foundation Server), entonces hágalo. He visto varias bibliotecas de la wiki de SharePoint que se utilizan para mejorar enormemente la cantidad y la calidad de la documentación del desarrollador disponible para varios grupos dentro de una gran organización de desarrollo de software. Una vez que cerramos la discusión sobre qué tan buenos eran los otros wikis, simplemente sucedió una gran cantidad de documentación, como se supone que debe hacer.

Uso Sharepoint con bastante frecuencia, y me parece un poco lento y molesto. Si todo ya es un documento de Office Y si su compañía está dispuesta a mantener las computadoras de todos al día con las versiones de Office, Sharepoint puede funcionar bien. Si tienes una variedad de versiones de Office (como nosotros), entonces es mucho menos bueno. Mi máquina tiene algunas versiones anteriores de componentes de oficina y la integración no siempre funciona correctamente. He aprendido a no tratar de usar la integración en absoluto.

Lo más importante con cualquiera de las soluciones es asegurarse de que su gente sepa cómo usarla. Tuvimos algunos problemas al principio (versiones de archivos con nombres diferentes en lugar de usar el control de versiones incorporado en sharepoint) que en realidad eran solo lagunas en la capacitación de las personas.