Formas de mejorar la comunicación entre los miembros de un equipo de software

Question

medida que el equipo que estoy en las obras de formalizar y establecer más prácticas de desarrollo, me parece que la comunicación parece fallar en los siguientes puntos:

1. Durante una informal conversación sobre un proyecto, un momento de chispa cerebral se convierte en una nueva característica/requisito. Estos "complementos" parecen fallar a través de las grietas o los detalles se vuelven borrosos después de que ha pasado un tiempo.

2. En las reuniones donde los objetivos o tareas no están claramente delegados, los miembros involucrados en la reunión tienen cuentas diferentes de lo que realmente se discutió.

3. Como equipo, somos constantemente desafiados (más aún ahora que realmente aspiramos a escribirlos) para generar especificaciones de calidad y documentos técnicos que detallen exactamente qué características necesitan estar en los proyectos.

Mi pregunta es: ¿Cuáles son algunas sugerencias y enfoques para abordar estos cuellos de botella e ineficiencias de comunicación? A ningún programador le gusta escribir documentación pero esperamos poder centralizar la comprensión y mantener esa información más visible y disponible durante el ciclo de vida de un proyecto ...

¡Gracias por su ayuda!

Answer 1

Se adhieren a la agenda. Manténgase en el objetivo. Cuando las cosas comiencen a desviarse del rumbo, programe otra reunión o llévela al correo electrónico después de la reunión.

Finalice cada reunión con elementos de acción: una lista escrita de quién hará qué y cuándo se espera. Sí, esto significa que alguien necesita escribir/escribir algo durante la reunión.

Si la documentación se está volviendo importante y necesaria, entonces le sugiero que proponga estándares simples y luego cumpla con ellos.

Wiki. Wiki. Wiki. Toda la información de "conocimiento tribal" útil para el equipo debe ir a una wiki. Cómo configurar entornos de desarrollo, sugerencias comunes para la depuración, etc.

Answer 2

¿Por qué no mantener notas en estas reuniones, en una wiki, para que otros puedan verla, y las personas puedan modificarla para aclarar las ambigüedades, y luego tenga un recordatorio de lo acordado?

Luego puede tomar las funciones y ponerlas en su software de seguimiento de fallas, para que no pierda de vista el hecho de que hay características a la espera de implementarse.

Answer 3

Antes de cerrar una reunión, la persona que la dirige debe indicar los elementos de acción y, por supuesto, quién los va a realizar y obtener el acuerdo de la persona asignada. persona o personas Alguien debe ser asignado para crear notas de reuniones y publicarlas. Podría intentar turnarse con las notas para que todos tengan que hacerlo a veces. Podrías probar con un scrum master (si estás haciendo scrum).

Pruebe una wiki para las notas. Las notas de la reunión deben incluir los elementos de acción. Todos los elementos de acción deben tener una fecha asociada a ellos.

Si no puede lograr que nadie reconozca que un registro de lo que está haciendo es importante, tiene un problema grave con sus desarrolladores. Por supuesto, puede tomar una fotografía de la pizarra y sus notas, pero eso no ayudará a los problemas de lectura y mantenimiento.

A muchos programadores (yo incluido) les gusta escribir documentación bastante.

Answer 4

En cuanto al n. ° 1: ¿qué tal un nuevo tablero post-it de ideas? Cree un área que sea altamente visible en el entorno de trabajo. A medida que se discutan las ideas, coloque una nota recordatoria en un papel adhesivo y colóquela en el tablero. Mantenga la placa dividida en categorías (es decir, interfaz de usuario, mejora del rendimiento, etc.). Un miembro responsable puede encargarse de transcribirlos en una wiki completa, cuando los detalles se agreguen o la idea sea lo suficientemente buena como para merecer un verdadero esfuerzo en el diseño.

En cuanto al n. ° 2: si su equipo tiene problemas para cumplir el objetivo, definitivamente el organizador de mtg debe tomarse el tiempo de preparar una agenda y adjudicar conversaciones para mantener el tema e insistir en que la reunión finalice a tiempo. Salga de la reunión sabiendo quién debe hacer qué.

En cuanto al n. ° 3: alguien debe liderar el proceso, encontrar ejemplos de los tipos de documentación y especificaciones que le gustaría ver y programar un tiempo con el equipo para revisar y debatir.

Answer 5

Encuentro que es importante registrar el motivo de una decisión en una junta Wiki o post-it. Sin ella, en elementos críticos donde se pueden implementar dos opciones, verá a un desarrollador revertir el código de otro desarrollador. Ambos pueden tener razones válidas, pero es una clara indicación de falta de comunicación.

Para evitar problemas como este, las decisiones clave de las reuniones deben repetirse, incluso hasta un mes después.

Answer 6

¡Documente todo, y no en el correo electrónico!

Usa algo con un historial. He tenido la tentación de usar Google Wave para rastrear el "Desarrollo" de un proyecto (cambios en los requisitos, interpretaciones, etc.). Una wiki también funcionará pero tiene una barrera más alta para la edición y puede ser actualizada por menos personas. Campfire es también una buena metodología.

Las nuevas metodologías (Campfire/Wave) son esencialmente registros de chat grabados que se dejan abiertos todo el tiempo. Campfire no tiene forma de "Promover" decisiones importantes, creo que se perderían en la conversación general, pero con Google Wave y Wikis, puedes recortar continuamente la información irrelevante o antigua. Wikis le dará más capacidad para reformatear el nuevo.

En realidad, una combinación de Wave/Wiki podría ser la mejor. Solo usa la ola para hablar diariamente sobre tipo de mensajería instantánea, y tira hilos/decisiones importantes al Wiki.

Algunas de las prácticas en XP (Agile) también ayudan aquí. Si utiliza FULL ON xp (no solo llama a sus reuniones diarias "Scrums"), encontrará ayuda importante, como el seguimiento de los requisitos de las tarjetas que se actualizan constantemente o la presencia de un cliente en el sitio para responder preguntas importantes. La idea general de XP/Agile se basa en el hecho de que los requisitos cambian y que esos cambios deben rastrearse y que afectan el cronograma de liberación.

Answer 7

Creo que un wiki o un blog interno podría ser excelente para documentar procedimientos útiles para todos los miembros del equipo.

Pero otro punto interesante es la comunicación entre programadores cuando algún programador tiene una duda de implementación. Por ejemplo: un programador no sabe cómo implementar alguna funcionalidad. Por lo tanto, podría publicar su duda en una "aplicación de mensajes cortos", como un twitter (pero con más de 140 caracteres). Entonces, algún desarrollador que sepa cómo resolver su duda podría publicar la solución. Todos los mensajes se almacenarán hasta que se encuentre la solución. Entonces, todos los demás miembros del equipo buscarán esta solución en el futuro.

Creo que este esquema es agradable, porque a veces al desarrollador no le gusta "perder mucho tiempo" escribiendo una publicación en un blog o algo en wiki.

Answer 8

Uso BaseCamp para administrar mis proyectos. Las reuniones se convierten en sesiones de lluvia de ideas divertidas, el trabajo se delega en el sitio.

Answer 9

Si estamos hablando de estar en contacto de una manera que reemplaza la voz y el texto, consulte http://CircleHubb.com. No solo puede conversar con miembros del mismo grupo, sino también compartir documentos en formato pdf y de texto, fotos y videos. También puedes hacer que tu grupo sea privado o público. Su aplicación se supone que saldrá pronto también.