wiki - zimbabue - ¿Qué herramientas usas para compartir información entre los desarrolladores de tu grupo?
zimbabwe poblacion (15)
Bueno, cualquiera que sea la tecnología o producto que decida usar, no será el problema. Todo el conocimiento que no está suficientemente bien compartido en la máquina de café necesita atención.
- Atención al momento de escribirlo (ya sea un documento en una unidad de red, una página wiki, un servidor de SharePoint, lo que sea).
- Atención para categorizarlo (mediante enlaces, etiquetas, páginas web, lo que sea ...).
- Atención para mantenerlo actualizado (por esfuerzo individual a pedido o programado).
Lo que sea que uses, ninguna tecnología te ayudará con esto. Para esto, necesitas motivar al equipo para que escriba las cosas, leer las cosas en el repositorio antes de llamar (e interrumpir) a un grupo de otros miembros del equipo, y corregir las cosas si están equivocadas.
Desde mi experiencia, SharePoint y Wikis realizan más o menos lo mismo. Necesita vencer a las personas para que lo usen, hasta que experimenten que desean usarlo, porque en algún momento experimentarán que ese tipo de intercambio de información puede ahorrar tiempo: su tiempo.
Como ya tiene el hábito de compartir información, esto puede no ser un problema tan difícil para usted. Yo recomendaría que uno (o unos pocos, mejor menos que muchos) proporcionen alguna estructura inicial (de repuesto) y luego comiencen el relleno. Como no existe una categorización perfecta, no debe preocuparse demasiado por eso.
Ya contamos con mentores, compartimos información entre nosotros y realizamos sesiones técnicas periódicas. Sin embargo, queremos que se anoten estas cosas, para el registro y para los nuevos miembros del equipo en el futuro. En este momento estamos en alrededor de 30 desarrolladores.
Estamos pensando en un blog y wiki interno.
Si bien sería genial compartir cosas en blogs públicos (y tal vez incluso tener blogs públicos oficiales de desarrolladores), por ahora queremos mantenerlo interno. Nuestra tienda tiene una programación principalmente a medida, y no productos, por lo que habrá mucha información de clientes propietarios allí. La autocensura de un blog público simplemente nos ralentizará.
Los wikis tienen un concepto agradable, pero necesitan más organización y editorial, por lo que no estoy convencido de que sea tan sostenible.
¿Cómo lo hace su organización?
Como programador que trabaja desde casa (sin ninguna opción de ir "a la oficina"): nuestro principal medio de comunicación es un canal privado de IRC. Somos un pequeño equipo de 3 desarrolladores por lo que funciona bien.
Las wikis me han funcionado bien en el pasado. Usamos la wiki gratuita ScrewTurn ejecutándose en una pequeña máquina virtual. Fue rápido, muy fácil de usar y a la gente pareció gustarle, así que realmente lo usaron.
Nuestro equipo no es muy grande (11 desarrolladores), así que tenemos cada mes una reunión en la que compartimos conocimiento. Además de eso, estoy ocupado agregando documentos interesantes a la intranet.
Y a menudo caminamos el uno al otro para hacer preguntas.
Para la administración de contenido solíamos usar un servidor Zope con Plone y ZWiki . Ahora usamos SharePoint 2007 .
También usamos Jabber para IM (somos un equipo distribuido). La mensajería instantánea es agradable para compartir cosas rápidamente con el equipo, pero debe tener cuidado de no abusar de ella o se ahogará en ruido.
Skype es bueno para compartir información / hacer preguntas rápidas. Para algunos conocimientos a largo plazo, utilizamos Wiki.
Un lugar donde trabajé también usamos un Wiki, pero descubrimos que no se actualizó con la suficiente frecuencia. Tenía que seguir presionando a la gente para que lo usara.
Obviamente, tenemos un sistema de archivos loco compartido con carpetas de correo electrónico compartido para las comunicaciones del proyecto.
También usamos un sistema interno de mensajería instantánea para evitar correos electrónicos generales en la oficina, pero al igual que Fog Creek, probablemente implementaría un clon privado de Twitter.
Una cosa que hicimos fue tener un día cada año en el que todos los desarrolladores se reunieran en algún lugar fuera de la oficina y se presentaran entre sí sobre cosas interesantes que habían encontrado / hecho. A veces cosas de proyectos, a veces de trabajo personal y, a veces, del día al mes, a las personas se les permitía trabajar en lo que quisieran (como el 20% de Google).
Usamos Fogbugz para los wikis, los grupos de discusión y la discusión enfocada de casos particulares. Para la mensajería instantánea, usamos Sametime . Esta combinación ha resultado ser muy poderosa para nosotros porque proporciona montones de funcionalidades sin forzarnos a tener mucha interfaz. La ceremonia baja es buena.
NOTA: la mensajería instantánea es el único aspecto de Sametime que usamos. Supongo que hay muchas otras locuras que puede hacer y que no nos interesan en absoluto.
Usamos Yammer para infos cortos, que es un servicio similar a Twitter, pero es privado dentro de su dominio de correo electrónico. Hay una aplicación web, un cliente de Windows y Mac e incluso una versión de iPhone.
Para la documentación utilizamos una Wiki de código abierto ( ScrewturnWiki en la plataforma ASP.NET). Fue aceptado muy bien.
Wikis son geniales Necesitan ser estructurados, pero creo que el mayor obstáculo para hacer funcionar una wiki es hacer que la gente la use para escribir la información relevante.
En mi trabajo anterior, teníamos un canal de IRC interno que era muy útil para la microcomunicación. En mi trabajo actual, esto no funciona en absoluto; muy pocos desarrolladores tienen la costumbre de usar un programa de chat para fines laborales.
mensajeros y correo electrónico
En mi trabajo anterior, utilizamos SharePoint para mantener nuestra documentación organizada. Esto fue razonablemente exitoso, pero obviamente hay una necesidad de mantener el sitio actualizado, relevante y configurado adecuadamente. Sin embargo, la arquitectura de SharePoint era lo suficientemente flexible como para que pudiéramos personalizarla según nuestras necesidades sin recurrir a la codificación. Lo que sugeriría es que dedique un poco de tiempo para administrar cualquier solución que busque. Sin mantenimiento, es muy fácil que un repositorio de documentación se vuelva obsoleto o desorganizado. Nos aseguramos de actualizar las carpetas de nuestro equipo al final de cada Sprint of work (utilizamos la metodología ágil de Scrum).
Los wikis son una gran idea para compartir conocimiento, posiblemente de una manera menos formal. Experimenté con el uso de una wiki privada de WetPaint, pero no recibí la aprobación de la gerencia. Sin embargo, definitivamente vale la pena intentarlo. No se va a escapar sin necesidad de control editorial, pero no hay nada de malo en hacer de este aspecto una responsabilidad compartida entre los equipos o hacerlo de forma rotativa.
Lo que recomendaría es reservar tiempo en sus calendarios para sesiones de intercambio de conocimiento. Es muy fácil para las grandes casas de desarrollo dividirse en silos (no deliberadamente, sino casi como un subproducto de la especialización necesaria) y para que esto resulte en dos o más equipos trabajando en muchos de los mismos problemas. Las sesiones mensuales o quincenales con todo el grupo pueden ser muy útiles. Las presentaciones en video son otra idea, pero tiene que haber un equilibrio entre mantener un registro de los detalles técnicos y la preparación requerida para hacerlo de manera efectiva. (Nunca lo hicimos en el suelo en mi trabajo anterior).
Si está dividido en equipos pequeños, realmente recomendaría reuniones de pie diarias en las que todos pasen por lo que lograron el día anterior y lo que planean hacer hoy. Esta es una de las claves de Scrum, mantiene a todos actualizados rápidamente y ahorra muchas reuniones y revisiones innecesarias.
Espero que esto ayude.