Mantenimiento de un Wiki de programador [cerrado]

Question

Recientemente me pusieron a cargo del wiki para el equipo de desarrollo. El wiki aún está en su infancia, por lo que tengo mucho espacio para trabajar. Su objetivo es albergar internamente al equipo de desarrollo. Actualmente, la información principal que contiene el wiki es la codificación de estándares.

• ¿Cuáles son algunas de las mejores prácticas que su equipo de desarrollo utiliza para su wiki interno?
• ¿Qué información es importante tener en un wiki de desarrollo?
• Si fuera a ir a la wiki para su equipo de desarrollo, ¿qué información esperaría ver?
• ¿Hay alguna información que no debería aparecer en la wiki aunque parezca una buena idea?

- editar -

• Además, ¿hay una buena manera de organizar la información? (como por capa (datos, ui), por proyectos u otros)

Answer 1

• Introducción a la base de origen para nuevos programadores
• Documentación general (no la documentación de API en sí, sino más tutoriales similares)
• Listas de personal / quién está haciendo qué y cómo comunicarse con ellos
• Notas / recursos / artículos que explican los conceptos utilizados en el software
• Documentación del proceso de compilación y el diseño del sistema de archivos de la base de código

Otras cosas que suelo poner allí son

• Planificación / listas de tareas
• Información que es interesante para que otros la lean
• Todo lo demás que siento debería ser compartido

Answer 2

Teníamos una wiki de desarrollo y fue una gran herramienta. Lo usamos para todo !

• Al intercambiar ideas nuevas, las capturamos en la wiki. La naturaleza de baja fricción de la wiki hizo que sea fácil para cualquiera en la organización (éramos una pequeña empresa) agregar ideas a medida que pensaban en ellas. Tuvimos un alto nivel " lluvia de ideas " página que enlaza con páginas detalladas que contienen una descripción detallada de cada idea.
• Para cada iteración, "moveríamos" elementos de la idea principal de la " lluvia de ideas " lista a la lista de características para esa iteración. Los detalles de la función se eliminaron para incluir los detalles de diseño e implementación.
• A medida que se completaron las funciones, la página de la iteración se convirtió en nuestra página de notas de la versión, que también incluía la etiqueta de la versión de nuestro sistema de control de versiones.
• Tuvimos una página de error que funcionó muy similar a las páginas de características. Las correcciones de errores se agregaron a las páginas de iteración / lanzamiento a medida que se trabajaron en / complete.
• También creamos nuestra documentación de usuario en el wiki y exportamos esas páginas con el lanzamiento.

Con el paso del tiempo. Esta herramienta fue vista cada vez más valiosa. Terminamos creando nuevos wikis para diferentes productos en los que la compañía estaba trabajando.

¡Espero que encuentres tu wiki de desarrollo tan útil como lo hicimos nosotros!

Answer 3

Wikipatterns es un sitio web dedicado a documentar las mejores prácticas de wiki. También describen antipatrones y hablan sobre formas de tratarlos. Leí su libro y fue una gran ventaja para mí poner en marcha una wiki en una organización de más de 150 personas.

Answer 4

Una cosa que destacamos en nuestra wiki de desarrollo es que se actualiza cuando las cosas cambian. No queremos que nuestro wiki tenga la intención de proporcionar información y ser una fuente central de conocimiento recopilado para que esté tan desactualizado que sea inútil. A medida que se actualiza el código, se solicita a los desarrolladores que actualicen cualquier información relacionada en la wiki.

Aparte de los estándares de codificación, guardamos consejos y trucos para trabajar con nuestra base de códigos, información de configuración para nuevas contrataciones e información general del entorno.

Answer 5

• Gráficos de Burndown
• información de configuración común para entornos de desarrollo (agradable para cuando comienzan nuevas personas)
• Especificaciones
• Problemas conocidos y soluciones alternativas con herramientas de desarrollo

Answer 6

Proponga algún tipo de guía de estilo y enséñeles a otros cómo diseñar cosas. Cuando estaba a cargo de una wiki corporativa, todos los demás desarrolladores simplemente escribían una prosa horrible que apenas estaba formateada y se veía terrible.

Manténgase alejado de las cosas que requieren discusión. Traté de calzador en una sección de revisión de libros, pero era demasiado difícil que otros comentaran sobre las cosas.

Los ejemplos de bibliotecas internas son buenos. Y / o " guiones gráficos " guiar a un usuario a través de un proceso cuando se llama a MethodX.

Answer 7

¿Cuáles son algunas de las mejores prácticas que utiliza su equipo de desarrollo para su wiki interno?

Haz que se vea bien. Sé que no suena importante, pero si pasa un poco de tiempo marcando la marca, vale la pena en términos de las personas que realmente lo usan. Y la aceptación es clave, o simplemente se marchitará y morirá.

¿Qué información es importante tener en un wiki de desarrollo?

• Información general sobre un proyecto, hitos, fechas de entrega, etc.
• Resúmenes de decisiones de diseño / reuniones. Importante para que no vuelva a visitar las mismas áreas una y otra vez.
• Guías prácticas para el desarrollo general de proyectos actuales (por ejemplo, cómo desarrollar un nuevo complemento)

Si fuera a ir a la wiki para su equipo de desarrollo, ¿qué información esperaría ver?

Información del proyecto, quién está trabajando en qué, etc. Decisiones de diseño. También las mejores prácticas y enlaces a sitios útiles.

¿Hay alguna información que no debería aparecer en la wiki aunque parezca una buena idea?

Las listas de tareas de bajo nivel tienden a fluctuar y no mantenerse actualizadas, y pueden ser engañosas. Además, las comunicaciones críticas entre los departamentos se adaptan mejor al correo electrónico, ENTONCES la conversación se puede copiar al wiki. ¡De lo contrario, es muy fácil ignorarlo!

Answer 8

Recuerda que un wiki es interactivo. Si está pensando en publicar, como en la publicación de gráficos de burndown, entonces no está pensando lo suficiente. Distribuir esa información es solo una parte de ella.

Por ejemplo, en lugar de tener un " Current Burndown Chart " página, cree una página para " Tabla de reducción para la semana del 10-27-2008 " y luego aliente a las personas a comentar sobre el cuadro, y lo que significa, y por qué lo hizo tan mal esa semana.

Answer 9

La parte más difícil es lograr que los desarrolladores usen tu wiki. Tengo algunas sugerencias de larga data aquí: http://posibility.com/wiki/index. php? title = GettingYourWikiAdopted

Adoptar un Wiki es difícil

Tener un campeón

Eliminar objeciones

Crear contenido

Enlazar la Wiki en los procesos de la empresa

Evangelizar

No te rindas

Considera no usar Wiki para las conversaciones

¡Sólo hazlo! No esperes un presupuesto

Tenga un plan de transición

Promocionando tu Wiki

Una buena práctica es tener disponible toda la documentación y el código fuente de cada compilación a través de su wiki. Luego, los desarrolladores irán a la wiki para acceder a la información de compilación, lo que la hace inestimable.

Answer 10

Los wikis pueden ser un recurso valioso para los equipos de desarrollo de software, pero no son una bala de plata. Es demasiado fácil crear un Wiki que caiga rápidamente en desuso o quede muy desactualizado.

En mi opinión, la clave para un Wiki exitoso es llevar a todo el equipo a bordo. Eso significa alejar a las personas de otros recursos (y en particular archivos de correo electrónico) como repositorios de conocimiento y ofrecer algún incentivo para que las personas contribuyan.

Sin embargo, también es importante no ser un zar de formato: si tiene muchos documentos que genera, digamos, MS WORD, puede ser ideal hacerlos todos en formato Wiki, pero eso lleva tiempo y puede ser molesto si tiene diagramas, documentos, etc. En esos casos, es mejor comprometerse y dejar que las personas lo mantengan en formato de palabra, siempre que la única forma de acceder a la versión más reciente sea a través del Wiki.

Si no es un gerente, debe tener un gerente a bordo porque requeriría cierta "aplicación".

Se ha acumulado investigación y experiencia en Wikis y su uso en ingeniería de software. Puede buscar en la biblioteca digital de ACM, por ejemplo. Soy un coorganizador de un taller anual sobre wikis para SE, tuvimos varios informes de experiencias interesantes y hay materiales adicionales en el simposio internacional sobre Wikis.

Answer 11

Somos el wiki del equipo interno y interno. Y allí ponemos toda la información necesaria para cada proyecto que estamos desarrollando:

• repositorios
• direcciones para máquinas virtuales
• contraseñas
• documentaciones del proyecto
• visión general del proyecto
• estado del proyecto

y cualquier otra cosa que completemos debe escribirse en un proyecto. Y es la aplicación web más útil que estamos ejecutando (además de Mantis ). En páginas más generales ponemos una definición de cada taxonomía que estamos usando, pautas generales del proyecto, políticas, codificación y prácticas de desarrollo que usamos. Está ahí, es simple y efectivo y creo que cada equipo debería tener uno de esos.