¿Cómo se comunica eficazmente en un pequeño equipo de desarrollo? [cerrado]

Las técnicas ágiles como la programación en parejas y las reuniones diarias de stand-up son buenas formas formales de lograr que la comunicación suceda.

Pero parece que lo que realmente necesitas hacer es hacer que la gente hable entre sí. Los desarrolladores tienden a ser introvertidos, así que tienes que trabajar en esto. Almorcemos juntos. Miren por encima de los hombros del otro. Pida consejo el uno al otro (incluso cuando no lo necesite). Pregúntate unos a otros sobre esas tecnologías extrañas que no todo el mundo entiende. Reunir para pruebas de integración.

Estoy en una situación similar en mi lugar de trabajo. Algunos miembros del equipo son, como usted dijo, altamente independientes y no comparten ninguna visión o prácticas con otros miembros del equipo. Me parece que esto es muy poco profesional y en general hiriente para el equipo.

Por supuesto, es inevitable tener algunos miembros más competentes que otros, y, en el mundo de la programación, algunos miembros tendrán problemas para dejar de lado sus egos. Lo mejor que puedes hacer es tener reuniones programadas y revisiones de código en las que todos están involucrados. Tener un sitio central de documentación donde las personas puedan publicar ciertas técnicas que utilizan. Si averiguas algo que crees que puede ser útil para el resto del equipo, súbelo al sitio y envía un e-mail a todos. La comunicación es clave.

Lo que podría ayudarte son los stand-ups diarios (de agile development). Solo toma un par de minutos y básicamente todos los miembros presentan a los demás el estado de su trabajo, los problemas con los que tratan y los planes para el mañana.

En nuestro equipo, tenemos reuniones de progreso cada semana. Esto permite descubrir lo que hacen los demás y dónde se coloca cada uno en el panorama general.

A veces es seguido por un mini evento social cuando compartimos un pastel casero. El nombre de la persona que trae el pastel la próxima vez está escrito en las actas de la reunión de progreso.

Trabajo en equipo

Vayan a hacer barbacoa juntos, jueguen futbolín, encuentren algo de actividad en equipo además del trabajo que les guste a todos. Eso enseñará a las personas a confiar entre sí en lugar de ser "independientes" y multiplicará por 10 el efecto de cualquier otra práctica útil en equipo, como scrum-meeting o programación en pareja.

Aquí están algunos pensamientos de la parte superior de mi cabeza (pequeña empresa, tres programadores; solía trabajar en un equipo de unos 20).

• Algún tipo de informe de progreso para que todos puedan ver en lo que todos los demás están trabajando. Las reuniones" En las que he estado trabajando " funcionan para algunas personas, pero no soy un fan de ellas - están demasiado regimentadas, y una reunión para sentarse con este propósito a menudo puede convertirse en una pérdida de tiempo y/o ser propenso a desaparecer por las ratholes. En mi trabajo actual tenemos un trabajo de cron que nos recuerda enviar nuestros correos electrónicos de progreso semanales: en estos se espera que digamos lo que hemos logrado, los próximos elementos en nuestra lista de tareas pendientes (con estimaciones cuando corresponda), cualquier problema que hayamos encontrado.
• Notificaciones de confirmación selectivas . Muy pocas personas pagan más que un vistazo superficial a los correos de confirmación de toda la empresa (incluso en mi pequeño equipo), pero si puedes capacitar a cada desarrollador para monitorear solo los campos en los que están trabajando, probablemente puedan hacer un seguimiento de ello. (Usted no debería haber demasiada gente trabajando en la misma pieza de código a la vez, de todos modos. Demasiados cocineros y todo eso.)
• Algún tipo de sistema de venta de entradas para proporcionar una lista de tareas pendientes puede ser útil. Sin embargo, debe tener muy claro cómo se administra esto, en particular cuáles son sus procesos para generar y cerrar tickets.
• documentación Interna. Este es un problema difícil; algunos desarrolladores lo odian, algunos escriben demasiado y otros escriben lo suficiente. Al menos la mitad del problema está en indexación y presentación; no sirve de nada si la información que necesitas está enterrada a cinco capas de profundidad en un documento impenetrable titulado "Cuidado con el Leopardo". Soy un gran fan de los wikis para este propósito, ya que son muy fáciles de usar.
• Por encima de un cierto tamaño de equipo, es posible que se convierta en un trabajo de tiempo completo para que alguien administre su documentación. En un lugar de trabajo anterior gastamos el dinero en un dispositivo de motor de búsqueda, rastreando continuamente nuestros sitios de intranet, lo cual fue maravilloso.

Estamos en una situación similar (un proyecto largo y todos somos amigos), y tuvimos problemas similares. Las siguientes prácticas nos permitieron mejorar mucho:

• Las reuniones de pie diarias son una necesidad. En mi experiencia un bien dirigido el standup diario es lo mejor para fomentar la comunicación entre los equipo. Todo el mundo sabe lo que todos los miembros del equipo están haciendo, y puede ayudar con cualquier problema.
• Un wiki también es esencial. Usted puede poner prácticas estándar y tecnologías que se utilizan dentro del equipo. Tener a todos activamente participar, el líder asigna a todos los miembros del equipo algo para escribir y mantener en el wiki. Es particularmente eficaz cuando cada uno escribe sobre algo que le gusta o es interesar.
• Trate de tener todo el equipo presente, o todos los miembros que son disponible, en reuniones donde se analizan requisitos/características, priorizados, etc. No importa si algunos de los miembros del equipo son no específicamente trabajando en esa área del proyecto. Esto dará contexto para todos y una visión más amplia del proyecto. Lo hará permitir (y alentar) que participen en estas discusiones de la proyecto como un todo, y no solo concentrarse en la parte que estamos trabajando. Esta práctica motivará mucha discusión, todos de nosotros cuando se nos da la oportunidad y el conocimiento (solo se necesita una muy pequeña cantidad) tener una opinión y me gusta comentar sobre todo todo dentro proyecto.
• La práctica final que motiva un montón de "tienda" hablar, es que cada dos semanas algún miembro da una pequeña presentación sobre alguna tecnología o técnica. Generalmente incluye ejercicios prácticos, y tiempo discutir y hacer preguntas.