¿Cómo facilitar la comunicación y las revisiones por pares en un equipo Scrum distribuido?

Dado que nadie ha dado muchos consejos en términos de productos de software, solo me gustaría presentar que Team Foundation Server 2012 Preview es gratuito para menos de 5 usuarios y es un gran recurso para administrar equipos distribuidos y facilitar la comunicación.

Para resaltar algunas de las formas en que puede ayudarlo:

• Solicitar revisiones de código: cualquier conjunto de cambios se puede archivar y enviar a otro desarrollador para la revisión del código. La interfaz es muy fluida y se realiza un seguimiento del flujo de trabajo mediante la creación automática de un elemento de trabajo para usted. Una vez que se completa la revisión del código, puede abrir el conjunto de cambios y fusionarlo con su versión actual de la solución (piense en ello como algo muy similar a un escenario típico de bifurcación y fusión). Si desea hacer cumplir una política de revisión de código, esta es una muy buena manera de hacerlo. Puede establecer una política de verificación cerrada que requiera una revisión completa del código antes de la verificación para que se asocie con el conjunto de cambios.

• Acceso web: se ha mejorado mucho con respecto a la versión 2010, lo que lo hace mucho más útil. Prácticamente todo lo que necesitas para hacer una planificación ágil de sprints está ahí. Vuelva a priorizar y administre su acumulación, asigne elementos de trabajo, gráficos de trabajo pendiente y mucho más.

Para responder a sus preguntas en la especificidad:

1) Planificación colaborativa de sprints y revisión de sprints. Por lo general, esto es mejor hacerlo a mitad de la semana, porque desea que todos estén allí constantemente. Dedique la primera mitad del día a la revisión de primavera y la retrospectiva, y la segunda mitad a la planificación del sprint (ajuste según sea necesario, tal vez solo necesite medio día para ambos). De esta forma, obtiene gran parte de los gastos generales administrativos en un solo día. Trate de ser lo más discreto posible durante estas reuniones. No dicte a su equipo cuánto tiempo debe tomar algo, reúna sus aportes sobre cuánto tiempo cree que tomará cada historia de usuario, retírelo de su prioridad de trabajo pendiente y agregue una cantidad aceptable de trabajo al sprint actual. Pienso en los gerentes de proyectos más como facilitadores de proyectos que cualquier otra cosa. Su trabajo es permitir que sus desarrolladores hagan el suyo,

2) TFS 2012, como se describe anteriormente

3) Las solicitudes de revisión de código son excelentes. Es posible que deba aplicarlos mediante la creación de una política de verificación cerrada para comenzar, pero eventualmente podría alejarse de eso a medida que su equipo vea su beneficio en la calidad mejorada del código. Se cuida la documentación ya que la revisión es parte del control de fuente como un elemento de trabajo, por lo que siempre está ahí. Esto también soluciona el problema de sacrificar el tiempo de revisión del código por el tiempo de desarrollo. El tiempo de revisión del código se convierte literalmente en parte del tiempo de desarrollo, y su equipo no sentirá que los está sacando de sus trabajos para hacer otra cosa.

Y en una nota final: prefiero poner los documentos del equipo en el control de código fuente en lugar de compartir el punto. En 2012, TFS detectará los cambios realizados desde fuera de VS, de modo que sean fáciles de verificar y mantener. Me parece que tener un único repositorio hace que sea más fácil para el equipo realizar un seguimiento de toda la documentación.

No comunicas por comunicar. No despliega un vehículo de comunicación si no tiene un mensaje que entregar, un mensaje que recibir, un mensajero o una audiencia.

Parte de su comunicación es el análisis de quién, qué, dónde, cuándo, por qué y cómo deben llevarse a cabo las comunicaciones, es decir, NECESIDAD. Si descubre que no lo quieren, entonces tal vez no lo necesiten... o no necesiten el mensaje que está entregando en ese momento de esa manera.

La comunicación es uno de los mayores factores críticos de éxito para el éxito del proyecto y es muy, muy difícil hacerlo bien. El desafío es adaptar los métodos para que se ajusten al entorno del proyecto, la cultura, la dinámica y las personalidades que tiene a bordo. Y todo tu borrador se lee como si no hubieras superado ese desafío.

Lo primero que debe hacer es obtener la experiencia a bordo sobre cómo hacer esto. Hay consultores que no hacen más que especializarse en esta área. El segundo paso es realizar un análisis de las partes interesadas, que es donde respondería la mayoría de las preguntas anteriores de 5W y H. Si su análisis se realizó correctamente y despliega las consecuencias de ese análisis, la comunicación debería fluir. Paso tres: ajustes.

Aquí hay otra pista: investiga los tipos de personalidad y los comportamientos inherentes. Hay un tipo de personalidad o dos que se sienten atraídos por el trabajo altamente técnico. Hay comportamientos consistentes adjuntos a este tipo o tipos y debe atenderlos si desea que sus comunicaciones mejoren. Recompensar y castigar hará muy poco.

Si bien en general estoy de acuerdo con el comentario de la primera respuesta (no desea ser puramente punitivo, necesita incentivos positivos, etc.), es posible motivar a las personas para que se muevan en esta dirección sin recompensas explícitas.

1. Lo que la gerencia habla con los desarrolladores es lo que ellos piensan. Si toda la administración habla de plazos, eso es para lo que trabajarán los desarrolladores. Si comienza a tener una reunión semanal con sus desarrolladores para analizar el proceso/las herramientas de las revisiones de código, descubrirá que comienzan a pensar más en esto y se involucran en el proceso. Si sus desarrolladores son como mis desarrolladores, las reuniones por sí solas son un castigo (sin llamar explícitamente a nadie o al equipo en su conjunto para el castigo). :) El simple hecho de tener una reunión rápida de 20-30 minutos una vez a la semana les ayudará a pensar más sobre el proceso y comprender que el objetivo de CMM es importante. Y con el tiempo, hablar sobre el proceso conducirá a mejoras en el proceso, y AHÍ es donde quiere ir. Dar a los desarrolladores el control para mejorar el proceso es un gran incentivo positivo. Solo asegúrese de establecer objetivos claros para los resultados y deje que ellos descubran cómo llegar allí.

2. Haz las cosas lo más fáciles posible. Esta es la razón por la que debe comprometerse con los desarrolladores en lugar de simplemente imponerles un proceso. Conocen las herramientas mejor que tú (especialmente cuando se trata de revisiones de código). Cree un entorno similar a un laboratorio donde todos puedan experimentar para mejorar y simplificar el proceso. Simplificar, simplificar, simplificar. Si la sobrecarga de la herramienta para realizar una revisión de código es de 2 minutos, obtendrá mucha más acción que si la sobrecarga de la herramienta es de 15 minutos. Los desarrolladores llegarán a extremos ridículos para ahorrarse 15 segundos si es algo que tienen que hacer más de una vez al día. Ejemplo: Usamos Subversion en mi tienda anterior. Para hacer revisiones de código, el revisor tenía que enviar por correo electrónico los archivos modificados al revisor, quien tenía que guardarlos en el sistema de archivos, tener cuidado de no sobrescribir los archivos actuales, hacer una diferencia, luego elimine cuidadosamente los archivos revisados ​​sin estropear su trabajo existente. Entonces alguien descubrió que podíamos usar archivos de parches de Subversion para revisiones de código. De repente, el proceso fue enviar por correo el archivo del parche, el revisor guarda el archivo del parche y lo carga en su cliente, lo que muestra los archivos modificados y los cambios. No había peligro de sobrescribir sus archivos fuente actuales y podían limpiarlos o no después de la revisión. No importaba. Los desarrolladores no estaban más contentos de participar en las revisiones de código, pero estaban menos descontentos al respecto. Y para no ser subestimado, a alguien se le ocurrió una mejora; la mejora se actuó de inmediato; los desarrolladores se sintieron mejor con las cosas porque se les permitió mejorar el proceso. Entonces alguien descubrió que podíamos usar archivos de parches de Subversion para revisiones de código. De repente, el proceso fue enviar por correo el archivo del parche, el revisor guarda el archivo del parche y lo carga en su cliente, lo que muestra los archivos modificados y los cambios. No había peligro de sobrescribir sus archivos fuente actuales y podían limpiarlos o no después de la revisión. No importaba. Los desarrolladores no estaban más contentos de participar en las revisiones de código, pero estaban menos descontentos al respecto. Y para no ser subestimado, a alguien se le ocurrió una mejora; la mejora se actuó de inmediato; los desarrolladores se sintieron mejor con las cosas porque se les permitió mejorar el proceso. Entonces alguien descubrió que podíamos usar archivos de parches de Subversion para revisiones de código. De repente, el proceso fue enviar por correo el archivo del parche, el revisor guarda el archivo del parche y lo carga en su cliente, lo que muestra los archivos modificados y los cambios. No había peligro de sobrescribir sus archivos fuente actuales y podían limpiarlos o no después de la revisión. No importaba. Los desarrolladores no estaban más contentos de participar en las revisiones de código, pero estaban menos descontentos al respecto. Y para no ser subestimado, a alguien se le ocurrió una mejora; la mejora se actuó de inmediato; los desarrolladores se sintieron mejor con las cosas porque se les permitió mejorar el proceso. No había peligro de sobrescribir sus archivos fuente actuales y podían limpiarlos o no después de la revisión. No importaba. Los desarrolladores no estaban más contentos de participar en las revisiones de código, pero estaban menos descontentos al respecto. Y para no ser subestimado, a alguien se le ocurrió una mejora; la mejora se actuó de inmediato; los desarrolladores se sintieron mejor con las cosas porque se les permitió mejorar el proceso. No había peligro de sobrescribir sus archivos fuente actuales y podían limpiarlos o no después de la revisión. No importaba. Los desarrolladores no estaban más contentos de participar en las revisiones de código, pero estaban menos descontentos al respecto. Y para no ser subestimado, a alguien se le ocurrió una mejora; la mejora se actuó de inmediato; los desarrolladores se sintieron mejor con las cosas porque se les permitió mejorar el proceso.

Comprometer. Simplificar. Repetir.

Generalmente la gente no va a hacer algo si no hay nada para ellos. Entonces, si no hay consecuencias negativas por su comportamiento actual y no hay recompensa/pago por pasar por el proceso de revisión por pares, continuarán haciendo lo que están haciendo. No basta con encontrar una herramienta para hacer algo, se necesita motivación.

Es fácil tener consecuencias negativas por no hacer, por ejemplo, revisiones por pares, simplemente no acepte el producto si no se ha sometido a una revisión por pares y responsabilice al productor por la demora en su entrega. O forzar la repetición del trabajo que se habría detectado sin la revisión por pares.

Pero castigar no es suficiente y, a la larga, será contraproducente para motivar al equipo. Es necesario premiar el buen comportamiento. El aspecto, la sensación y la forma de esa recompensa dependerán de los motivadores del productor.