communication - comunicativas - diferencias comunicacion entre hombres y mujeres

¿Cómo se comunica efectivamente en un pequeño equipo de desarrollo? (8)

Aquí hay algunos pensamientos fuera 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 qué están trabajando los demás. Las reuniones en las que he estado trabajando "funcionan para algunas personas, pero no soy un fanático de ellas; están demasiado reglamentadas, y una reunión sentada para este propósito a menudo puede convertirse en una pérdida de tiempo y / o o ser propensos a desaparecer por los rabinos. En mi trabajo actual tenemos un trabajo cron que nos recuerda enviar nuestros correos electrónicos de progreso semanales: en estos se espera que digamos lo que hemos logrado, los siguientes elementos de nuestra lista de tareas pendientes (con estimaciones donde corresponda), cualquier problema que he encontrado
Notificaciones de confirmación selectiva . Muy pocas personas pagan más que una simple mirada a los correos de confirmación de toda la empresa (incluso en mi pequeño equipo), pero si puede capacitar a cada desarrollador para que monitoree solo los campos en los que están trabajando, probablemente puedan realizar un seguimiento. (De todos modos, no debería tener demasiadas personas trabajando en el mismo código a la vez. Demasiados cocineros y todo eso).
Puede ser útil algún tipo de sistema de emisión de boletos para proporcionar una lista de tareas pendientes. Sin embargo, debe tener muy claro cómo se gestiona esto, en particular, cuáles son sus procesos para generar y cerrar tickets.
Documentación interna. Es este un problema difícil; algunos desarrolladores lo odian, otros escriben demasiado y otros escriben lo suficiente. Al menos la mitad del problema está en la indexación y la presentación; no sirve de nada si la información que necesita está escondida 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 cierto tamaño de equipo, puede 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 búsqueda, rastreando continuamente nuestros sitios de intranet, lo que fue maravilloso.

Trabajo en un pequeño equipo (4-5 desarrolladores) en un solo proyecto. Cada miembro de nuestro equipo está desarrollando una funcionalidad diferente de nuestro proyecto y son altamente independientes. De hecho, algunos miembros usan tecnologías que otros miembros no conocen. Sigue siendo un proyecto único y contiene mucha lógica de negocios común.

Además, la mayoría de los miembros desconocen completamente qué y cómo están haciendo los demás. De alguna manera, conseguimos evitar la réplica del código (créditos para nuestro líder de equipo, pero incluso él no está completamente consciente de lo que está sucediendo). Me pregunto qué es una buena práctica para mantener a todo el equipo en la pista sobre lo que está sucediendo. Por ejemplo, si alguien del equipo se retira o falta cuando se debe hacer un arreglo importante, es difícil para los demás.

Tenemos una política para realizar revisiones de código, pero solo los líderes de equipo y un miembro del equipo participan en ella. Los otros miembros "regulares" no participan, allí.

Además, tenemos una "lista de noticias" para el checkin-s comprometida en el control de la fuente por parte de nuestros miembros, pero esto parece demasiado aburrido y parece que nadie se toma el tiempo de leer lo que otros acaban de cometer (y no es efectivo, para ser justo).

Entonces, me pregunto qué es una buena práctica en este asunto. ¿Qué experiencia tiene usted? ¿Hay alguna solución?

EDIT: Déjame aclarar un poco. Nuestro equipo trabaja desde hace más de 2 años y el proyecto tiene casi 5 años. Por lo tanto, no podemos iniciar un desarrollo ágil, aunque podríamos hacer algunas prácticas ágiles (como una reunión de pie, lo encuentro muy útil).

Además, nuestro equipo es parte de una empresa más grande, por lo que hemos establecido prácticas de formación de equipos. Y no nos odiamos el uno al otro :) - somos amigos, hablamos de la vida social y las actividades. Las charlas profesionales es lo que nos falta.

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

A veces le sigue un mini evento social cuando compartimos un pastel casero. El nombre de la persona que trae la torta la próxima vez está escrito en los minutos de la reunión de progreso.

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 diarias de pie son una necesidad. En mi experiencia, un standup diario bien conducido es lo mejor para fomentar la comunicación entre el equipo. Todos saben lo que están haciendo todos los miembros del equipo y pueden ayudar con cualquier problema.
Una wiki también es esencial. Puede colocar prácticas y tecnologías estándar que se utilizan dentro del equipo. Para que todos participen activamente, el líder asigna a todos los miembros del equipo algo sobre lo que escribir y mantener en la wiki. Es particularmente efectivo cuando cada uno escribe sobre algo que le gusta o le interesa particularmente.
Trate de que todo el equipo esté presente, o todos los miembros disponibles, en reuniones donde se analicen los requisitos / características, se prioricen, etc. No importa si algunos de los miembros del equipo no trabajan específicamente en esa área proyecto. Esto dará contexto a todos y una visión más amplia del proyecto. Les permitirá (y alentará) a ellos participar en estas discusiones del proyecto en su conjunto, y no solo concentrarse en la parte en la que están trabajando. Esta práctica motivará mucha discusión, todos los que, cuando se nos brinda una oportunidad y un conocimiento (solo se necesita una cantidad muy pequeña), tenemos una opinión y nos gusta comentar sobre todo lo que hay dentro del proyecto.
La práctica final que motiva una gran cantidad de "compras" es que cada dos semanas algún miembro hace una pequeña presentación sobre alguna tecnología o técnica. En general, incluye ejercicios prácticos, y tiempo para discutir y hacer preguntas.

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 información o prácticas con otros miembros del equipo. Me parece que esto es muy poco profesional y, en general, perjudicial 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 se puede hacer es tener reuniones programadas y revisiones de códigos 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 descubre algo que cree que puede ser útil para el resto del equipo, cárguelo en el sitio y envíe un correo electrónico a todos. La comunicación es clave.

Las técnicas ágiles como la programación en parejas y las reuniones diarias de pie son buenas formas formales de lograr que la comunicación se desarrolle.

Pero parece que lo que realmente necesitas hacer es que las personas hablen entre sí. Los desarrolladores tienden a ser introvertidos, así que tienes que trabajar en esto. Almorzar juntos Mirarse por encima de los hombros del otro. Pida consejos entre sí (incluso cuando no lo necesite). Preguntarse mutuamente acerca de esas tecnologías extrañas que no todos entienden. Reunirse para las pruebas de integración.

Lo que podría ayudarlo son las paradas diarias (de un desarrollo ágil). Solo toma un par de minutos y, básicamente, todos los miembros presentan a los demás el estado de su trabajo, los problemas que enfrentan y los planes para el futuro.

Creo que las paradas son un buen comienzo para ti. Puede encontrar más información, por ejemplo, en Martin Fowler - No es solo levantarse: patrones de reuniones diarias

Trabajo en equipo

Haz una barbacoa juntos, juega al futbolín, encuentra alguna actividad de equipo además del trabajo que a todos les gusta. Eso les 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 de equipo útil, como la reunión de scrum o la programación en pareja.

Reuniones de pie cada día (manténgalos cortos) con todos los presentes, ayude a todos a comprender lo que hacen los demás. Esto también ayuda al gerente a hacer algo de manejo, ayuda a evitar las thrashing y pone un poco de presión sobre cada individuo sin que el gerente tenga que hacerlo. (Quieres que te hagan algo para verte bien delante de tus compañeros mañana por la mañana). Algunas metodologías como Scrum formalizan esto.
Haga revisar el código con diferentes miembros del equipo. ¿Uno de los miembros del equipo que no es gerente tiene más experiencia? Sería bueno que esta persona hiciera una revisión de código con otros; él / ella compartiría su experiencia y sería otra persona (además del gerente) que sabe la mayor parte de lo que está sucediendo. No hay ninguna ley que diga que, en una revisión por pares, una persona debe ser mayor que la otra y ser quien declare que el código es correcto o incorrecto. Sin embargo, creo que si dos "compañeros" están haciendo una revisión del código, para empezar, deberían simplemente emparejar el programa.
Si está intentando escribir algún código de calidad, ciertos bits de código podrían prestarse a pair-programming . La gente de XP dice que deberías hacer esto todo el tiempo, pero creo que es más útil a veces y otras veces. Por ejemplo, cuando un desarrollador tiene más experiencia que el otro, esto ayuda con la tutoría. Además, cuando hay un área específica en la que desea difundir el conocimiento. (Solo un individuo entiende una parte del sistema; la próxima vez que necesite una revisión, pídale que lo haga con la otra persona escribiendo ) . Además, a veces una parte del sistema es realmente importante , y hacerlo correctamente es mucho más importante que las líneas de código por minuto. Este es un gran lugar para tener dos cabezas en el problema, y al final dos personas tienen un conocimiento íntimo de este código clave en lugar de uno.
Algo así como una vez por semana, hacer que alguien presente una breve charla durante el almuerzo sobre algo interesante que están haciendo. Esto puede generar una gran discusión, promover la confianza y el respeto mutuo, pero lo que nos interesa aquí es que promueve la conciencia.
Valora, apoya y cree en un buen código . Algunas tiendas (principalmente los gerentes) realmente no creen en un buen código, y esto lleva a que la gente simplemente saque el código (de mierda), incluso si los desarrolladores podrían hacer un gran código. La comunicación sobre el código es mucho más fácil si los desarrolladores están contentos con el código que están creando, si está implementando alguna tecnología nueva de vez en cuando, y si el trabajo de calidad ayuda a su carrera .

Y más sobre la programación de pares. La parte clave de la programación de pares para esta discusión es que pair-progrmaming promueve el código compartido y el conocimiento cruzado. La razón por la que menciono los lugares específicos donde la programación de pares es particularmente útil es porque la política " vamos a hacer la programación de pares " tiene éxito aproximadamente el 10% del tiempo. El otro 90%, los defensores de la práctica no pueden dar una respuesta lo suficientemente buena cuando un gran gerente pregunta: "¿por qué todas estas personas están sentadas en los mismos escritorios?" Las ventajas de la programación de pares tienen que ser un 200% más que un simple programador que lo haga, porque estás usando a dos personas . Hecho en el momento adecuado , la programación de pares puede aumentar su relación solución / buck; En el momento equivocado puede disminuirlo.