Programar con un grupo de personas que nunca he conocido

El líder de este proyecto será la persona que se hace cargo y se hace cargo al principio.

Esto se aplica a la mayoría de las cosas en la vida, no solo al desarrollo de software. Cuando todos los demás corren como pollos sin cabeza, la persona que piensa las cosas, se adelanta y dice: " Esto es lo que vamos a hacer y cómo lo haremos . " Es usualmente la persona considerada como líder para el resto del proyecto. Tenga en cuenta que al hacer esto, usted es responsable del éxito o fracaso final del proyecto.

¿Quieres liderar este proyecto? Aquí hay un par de cosas que puede comenzar a hacer de inmediato para lograr un gran impacto.

1. Use una herramienta de gestión de proyectos como Trello y envíe invitaciones a todos y comience a asignar partes del proyecto a las personas. .
2. Genere una base de datos de errores y comience a agregar tareas y errores, nuevamente, simplemente comience a asignar.
3. Configura un repositorio de control de versiones y verifica una buena porción inicial de código en la que todos puedan trabajar. Se niegan a tratar con cualquier otra forma de control de código.
4. Ofrézcase para ayudar a las personas a iniciar el desarrollo mostrándoles cómo utilizar el sistema de control de versiones y la base de datos de errores.
5. Envíe correos electrónicos semanales que detallan el estado del proyecto y el progreso de la semana anterior.

Ninguno de estos pasos es particularmente difícil, o requiere mucho tiempo, pero serán enormes ahorradores de tiempo en el futuro. Además, hará que su equipo hable entre ellos y se acostumbrarán a que usted esté a cargo.

Jarrod Nettles resume bastante mucho lo que iba a sugerir, así que incluiré algo de lo que funcionó en mis experiencias recientes en una situación similar.

Sugeriría encontrar una manera de hablar con ellos vocalmente, en lugar de hacerlo por correo electrónico. Si no está en la misma área, consígalos todos en Skype. Si estás en la zona, reúnete con ellos en una cafetería o algo así. Hablar en persona en las reuniones iniciales lo llevará a tomar decisiones y realizar el trabajo allí mismo; Los mensajes de correo electrónico permiten a los que son tímidos o que a menudo no están en su computadora detener el proceso. ¡Todos sabemos lo perezosos que pueden ser los estudiantes!

En su primera reunión, trataría de conocer a su grupo en lugar de seguir adelante con el proyecto, ¡pero no ignore el proyecto! Pasar 10 o 20 minutos para romper el hielo es probablemente suficiente entre 4 personas.

Cuando se trata de hablar sobre el proyecto, sugeriría analizar lo que usted cree que implica el proyecto. Creo que es importante que deje en claro que es su comprensión, y no es un caso de que les diga exactamente qué hacer. Todo el mundo debería poder lanzar sus pensamientos e ideas al ring si tienen alguno, y usted debería salir de esa reunión inicial con una comprensión lo suficientemente decente de lo que usted, como grupo, siente que implica el proyecto.

En reuniones futuras (regulares), puede comenzar a ver diferentes partes del proyecto con más detalle; mire qué necesita hacer exactamente, qué recursos y cuánto tiempo se necesitará y quién puede hacer qué. Dividir la pieza más si es necesario. Tal vez intente establecer algunos plazos suaves?

  

¿Alguno de ustedes tiene experiencia trabajando con un grupo de personas que nunca conoció en línea y no puede reunirse con ellos en persona, pero debe completar un proyecto en conjunto?

Agregue en la subestimación de presupuestos, plazos ridículos y que el marketing los venda en el río, y esto suena como aproximadamente el 65% de los proyectos de desarrollo de software en el mundo real.

Probablemente le serviría mejor si la gente se ofreciera como voluntaria para las partes que les gustaría hacer en lugar de encargarse unilateralmente y asignar tareas. Probablemente todos están sentados allí pensando en cómo deberían hacerse cargo. O cómo pueden obtener algunos pobres tíos que se preocupan demasiado por hacer todo el trabajo en grupo para que puedan viajar en su grado.

Lo primero que debe hacer en casos como este es establecer un seguimiento de problemas y aprender a usarlo. .

Para obtener una introducción más fundamental sobre cómo manejar el desarrollo como lo describe, mi referencia favorita se refiere al artículo de Martin Fowler Uso de un proceso de software ágil con Desarrollo Offshore . Este artículo describe los conceptos básicos y avanzados de la configuración de la comunicación distribuida del equipo:

Use Continuous Integration to Avoid Integration Headaches
Have Each Site Send Ambassadors to the Other Sites
Use Contact Visits to build trust
Don't Underestimate the Culture Change
Use wikis to contain common information
Use Test Scripts to Help Understand the Requirements
Use Regular Builds to Get Feedback on Functionality
Use Regular Short Status Meetings
Use Short Iterations
Use an Iteration Planning Meeting that's Tailored for Remote Sites
When Moving a Code Base, Bug Fixing Makes a Good Start
Separate teams by functionality not activity
Expect to need more documents.
Get multiple communication modes working early

Para tu proyecto, seguro que no podrás seguir todos los consejos y trucos mencionados allí (por ejemplo, es probable que no haya Embajadores ni Visitas de contacto para ti :) pero vale la pena estudiarlo.

• Para muchos equipos, tener todo lo anterior sería una exageración seguro. Aún así, me parece realmente útil tener una lista de verificación completa de esa manera. que incluso los elementos omitidos se verifican y tienen razones claramente documentadas de rechazo, solo para asegurarse de que no se haya omitido nada importante.

No nos ha dicho cuánto tiempo tiene para esto o el idioma en el que está trabajando (yo diría que una sola clase es muy pequeña, pero quizás en su idioma sea mucho más).

En primer lugar, tenga un producto que funcione a cualquier costo.

Si el proyecto dura dos semanas o menos, asuma que usted será el único que hará algo y se sentirá muy contento con la ayuda que reciba. Intenta programar cosas para todos, pero asegúrate de que si nadie hace algo, tendrás un producto que funcione. Incluso si alguien hace algo, no confíe en que continúe: esté preparado para que cualquier persona lo abandone en cualquier momento.

Si tiene más de una semana, considere programar un día de la semana cuando el producto debe marcarse como un hito y atenerse a eso lo más posible. Asegúrese de tener algo de lo que pueda patear y verifique las deficiencias de: si lo peor es peor, esto será lo que entregue. Cada uno que cree, verá cuánto podría mejorar las cosas, lo que lo motivará a ir. en. No planifique demasiado hacia adelante: seguro, necesita tener una idea de lo que terminará, pero mantenga sus planes más específicos a corto plazo.

Tenga en cuenta que estos dos se superponen un poco: esto es intencional, ya que dos semanas es, en mi opinión, un área gris donde es difícil realizar dos iteraciones, pero trabajar en una iteración es arriesgado.

Supongo que en el peor de los casos, trabajarás con personas muy nuevas en programación. Mi consejo general sería:

• Mantenga una lista de las características que desea implementar pronto y quién trabajará en ellas. Jarrod sugirió a Trello, y lo apoyo totalmente: si tus compañeros de equipo no tienen mucha experiencia, te ayudará mucho. También puedes intentar mantener los errores allí.
• En un equipo de cuatro, necesitas control de versiones. Puede hacer que otros se muestren más reacios a contribuir si no saben cómo trabajar, pero vale la pena.
• Cualquier dependencia externa puede asustar a los novatos. Si escribe pruebas de unidad, dígales a las personas que no deben preocuparse por romperlas. Dígales a las personas que no deben preocuparse por romper la construcción, especialmente al principio. Es mucho más difícil corregir a las personas que no cometen ningún código que las que cometen códigos de buggy.
• Comprueba si las cosas aquí sugeridas realmente se aplican a ti. "Integración continua" es un término elegante, para un programa pequeño, que podría significar que "este programa se ejecuta y se pueden usar todas las funciones". ¿Incluso tienes sitios? ¿La división en equipos te ayuda?
• YAGNI, cien veces más. Si realmente tienes que hacerlo, escribe las cosas con anticipación para las características que harás tú mismo. Haz que funcione, luego refactoriza, o no podrás hacer que funcione.
• Refactor. Una vez que esté funcionando, dedica un tiempo a arreglarlo. No olvide que sus compañeros de equipo también tendrán que leer su código: un día dedicado a reparar piezas feas y reemplazar soluciones simples con soluciones de mejor rendimiento no es un día perdido.
• Mantenga un ojo en todas las partes. Revisar los registros de cambios y, en ocasiones, leer el código de otros usuarios, ayuda a garantizar que todo se ajuste a los estándares de calidad que usted considera que debe cumplir y asegura que no sea tan difícil sumergirse si la persona lo abandona.
• No dude en trabajar en lo más importante, a diferencia de lo designado. Si alguien se está atrasando, haz una nota escrita de eso en algún lugar y hazlo tú mismo. Pregúntales primero, pero sigue adelante si no responden, o si preguntas una o dos veces y luego sientes que todavía no lo harán.
• Enfócate en hacer algo de lo que estés orgulloso. Incluso si se desvía de la tarea. Incluso si tienes que cortar grandes características para hacer que lo que tienes sea más suave. Cada iteración piensa "¿Estoy orgulloso de esto?", Y en la próxima iteración, intente arreglar esas cosas.

Tuve un proyecto que fracasó horriblemente recientemente; puedes leer mis pensamientos sobre por qué falló si quieres, pero esto resume cómo Haría algo como esto si tuviera otra oportunidad.

La respuesta de Jarrod Nettles es buena. Yo añadiría esto:

1. Espere que al menos una de las otras tres personas sea completamente inútil.
2. Solo acepta que sentirás que estás haciendo la mayor parte (o todo) del trabajo, pero todos obtendrán el mismo crédito. Cualquier intento de tratar de hacer que las cosas sean "justas" solo causará conflictos innecesarios y ralentizará su actividad.
3. Manténgase en contacto con cualquier miembro del equipo que sea bueno. Estas personas son difíciles de encontrar y querrá trabajar con ellas nuevamente.

He estado en una posición similar varias veces porque estoy seguro de que hay mucha gente. Sin embargo, lo principal es hacer todo lo posible para mantener a todos contentos y felices, por lo que creo que es bueno que desee asumir la tarea de líder de equipo, sin embargo, como alguien mencionado anteriormente, esto debe abordarse con cuidado como alguien más. puede sentir que deberían hacer el trabajo en su lugar.

Sé que usted dijo que nadie se ha puesto en contacto entre sí, pero a veces estas situaciones pueden ser difíciles para las personas, como usted dijo que está trabajando con personas que nunca ha conocido y que puede ser difícil comunicarse, etc.

Comenzaría con un correo electrónico, dirigiéndome a todos y haciéndoles saber quién eres, cómo consideras que debería abordarse el proyecto, y te diré que quieres liderar el proyecto y asumir la responsabilidad de establecer roles, objetivos, plazos y tiempo de comunicación. , reuniones (si se desea / desea) y actualizaciones del proyecto.

Aunque no puedes influenciar completamente a otras personas, puedes hacer un seguimiento de quién está haciendo qué y quién no. La delegación de trabajos permite que el trabajo se divida de manera equitativa o adecuada a personas con diferentes habilidades o niveles.

De esta manera, si no se está haciendo cierto trabajo, puede encargarse de dividir el trabajo entre las personas que realmente están dispuestas a trabajar en ello. De esta manera, no terminará con un proyecto fallido al final y tendrá registros de intentos de comunicar fechas, horas y toda la información relevante que puede mostrar al final si las cosas salen mal. Todas las cosas que te mantienen en la derecha si algunas personas no hacen todo lo posible.

En términos de consejos:

Personalmente, me encanta un entorno de trabajo colaborativo que se encuentra aquí: enlace

Esto le permite compartir documentos de Word, hojas de cálculo, etc. Es una excelente manera de trabajar en colaboración. No puedo subrayar lo útil que es esto a veces. Lo uso con algunas personas con las que trabajo que no están en el país en este momento.

Espero que esto haya ayudado a alguien, hay tantos aspectos de liderar un proyecto que podríamos seguir para siempre pero solo depende de muchas cosas. Al menos esto es un poquito para ayudar.