Cómo convencer a mis compañeros de equipo para que sigan algunas reglas básicas

Tengo un problema con mis compañeros de equipo. Larga historia corta: somos tres estudiantes trabajando en un proyecto para una competencia. El proyecto consta de 2 aplicaciones separadas: una para Windows (que desarrollo) y otra para Android (mis colegas son responsables de desarrollarla). Nuestras bases de código nunca se cruzarán, las aplicaciones se comunicarán a través de herramientas de terceros.

El problema es el siguiente: tengo algo de experiencia trabajando en equipos ya que hice una pasantía en una gran empresa el año pasado, y trato de hacer cumplir algunos estándares de codificación para nuestro código. También configuré un software de repositorio / wiki / colaboración de git que podemos usar para insertar ideas de código / escritura, protocolos de documentos, etc., pero parece que soy el único que usa estas herramientas.

Traté de decirles que escribir código de calidad y documentar cada paso nos beneficiará a largo plazo, pero no parecen ver la ventaja. También estaba pensando en agregar algunas pruebas de integración, pero por lo que puedo ver, siempre que no utilicen las herramientas actuales para facilitarles la vida, no creo que pueda convencerlos de la utilidad de las pruebas de integración.

La mayor parte del código de los compañeros reside en sus computadoras, no comparten una base de código común y, como descubrí, integraron sus piezas al conocer y compartir el código a través de una memoria USB.

Mi pregunta es: ¿soy demasiado duro con este asunto? ¿Cumplo algunas reglas absurdas? Tenga en cuenta que este es un proyecto pequeño, los requisitos son muy claros (creé documentos que especifican qué deberían hacer las aplicaciones), tres desarrolladores expertos podrían hacer esto en 3-4 días, por lo que es posible que no vean la complejidad adicional de la calidad de escritura código siempre que su método actual simplemente funcione.

¿Hay alguna forma de mostrarles el beneficio de documentar el código, usar git, etc.?

Mi pregunta es: ¿soy demasiado duro con este asunto?

Puedes llevar un caballo al agua, pero no puedes obligarlo a beber.

Es difícil decir si eres "demasiado duro", pero puede ser poco realista esperar que tus compañeros de equipo adopten toda la infraestructura que esperas. Y realmente, si el equipo está trabajando bien juntos, usar una wiki para comunicarse entre tres personas probablemente sea excesivo.

Reduzca sus expectativas y busque formas de lograr algunos de sus objetivos sin requerir que comiencen a utilizar herramientas que no conocen. Si no saben cómo usar git, probablemente no obtendrán muchos beneficios en ningún caso. Sin embargo, aún desea asegurarse de que todo el código esté respaldado en caso de falla del disco duro u otra catástrofe, por lo tanto, pídales que copien periódicamente su carpeta de proyecto en un Google Drive, Dropbox o un servicio similar de intercambio de archivos en línea. Asegúrate de hacer lo mismo.

Mi actitud es que si puedes aprender a hacer estas cosas en proyectos pequeños, estarás preparado cuando aparezcan proyectos grandes.

Si siguen buenas prácticas de desarrollo con este proyecto, tendrán un código para mostrar a los futuros empleadores, y tendrán una experiencia que los hará valiosos como empleados.

Si desea más material para convencerlos, me referiría al Programador Pragmático , o Código Completo .

Por otro lado, considera cortarlos un poco. Si el proyecto es una prueba de concepto que se está eliminando inmediatamente después de la competencia, entonces debe considerar dejarlos hacer lo que quieran. En primer lugar, podrían tener dificultades para escribir el código, sin la sobrecarga mental de las buenas prácticas.

Me temo que las reglas que describiste no son básicas en absoluto.

La tarea más fácil de la OMI es convencer a tus compañeros de equipo para que usen algunos estándares de codificación. Y una forma simple de lograr esto es mostrarles el mismo fragmento de código una vez bien formateado y luego mal diseñado, pedirles que lean el código, entender lo que hace y dejar que se juzguen a sí mismos.

Lo que viene a usar un repositorio git, esto puede ser un dolor para los novatos. Cuando estaba trabajando en un equipo de 3 personas en un proyecto de Android, al principio tuvimos muchos problemas con nuestro sistema de control de versiones. Así que espero que tus compañeros de equipo también tengan problemas.

Usted mencionó que los desarrolladores experimentados tardarían entre 3 y 4 días en finalizar el proyecto (supongo que su equipo tardará 2-3 veces más). Este es un período de tiempo muy corto, por lo que el argumento de que el uso de nuevas herramientas ayudará a largo plazo simplemente no funcionará.

Lo que puede hacer es hacer demostraciones cortas y simples para mostrar cómo se usan esas herramientas. Primero cubra las funciones más básicas, siéntese a su lado y ayúdelos a usar las herramientas. Esté preparado para hacer todas las tareas como configurar el git, crear la estructura de la página wiki, etc.

Editar : en respuesta al comentario, creo que establecer tareas claras, estimaciones y plazos y hacer un seguimiento del tiempo dedicado es más importante que usar git o herramientas similares. Si planea trabajar en la aplicación más adelante, es muy importante realizar un seguimiento de lo que ya se hizo y cuánto tiempo tomó cada función. Por lo tanto, le sugiero que comience desde la administración de tareas y luego continúe con las herramientas que desea utilizar.

De hecho, me gustan los pensamientos de Joel Spolsky al respecto, tal como lo expuso en Cómo hacer las cosas cuando solo eres un gruñido . Para resumir:

1. Solo hazlo : escribe makefiles, crea un servidor de compilación diario, etc.
2. ¿Nadie usa control de fuente o bases de datos de errores? Comience a usarlos usted mismo. Si alguien informa de un error en su trabajo, pídale cortésmente que use la base de datos de errores para informarle de los errores, de modo que pueda seguirlos; de lo contrario no podrá mantenerlos en su cabeza y arreglarlos. En cualquier proyecto no trivial, habrá una situación que solo se puede resolver con el control de la fuente: use el control de la fuente para el código usted mismo y descienda heroicamente para salvar el día en que ocurra tal situación. Una vez que esto suceda varias veces, se convencerán
3. Cree un bolsillo de excelencia : haga lo correcto para usted: especificación, programación, etc. Dado que esto no parece un proyecto de trabajo, no parece que pueda tomar este consejo hasta el final, ya que no puede contratar nuevos miembros del equipo que creen en tu mensaje
4. Sea invaluable : demuestre que es un gran contribuyente para consolidar su influencia en el equipo. De lo contrario, corre el riesgo de ser conocido como una persona que valora los procesos y las herramientas sobre los resultados.

La documentación, Wiki, software de versiones, metodologías, etc. son experiencias y lecciones aprendidas a lo largo del tiempo; trabajando en varios proyectos y probablemente en varios equipos. Y generalmente se queda con aquellos que ya están empleados o que toman en serio su industria. Son estudiantes, por lo que sus intereses probablemente estén limitados por debajo de lo que suceda en el futuro. :)

Pero para tratar de responder a tu pregunta:

Si está en un equipo con ellos, deberá aplicar lo que considere importante de una manera que beneficie sus intereses. Como ejemplo: ¿Deberían quejarse de que su código se rompa mucho cuando el usb lo comparte? Entonces, quizás les dé una forma simple (no complicada) de usar SVN (en lugar de git) como herramienta de control de versiones.

También estoy de acuerdo con el comentario de arnaud.

Usted vio el beneficio de todas estas herramientas cuando trabajaba con ellas y así es como vio valor en ellas y por qué comprende su uso. Si sus compañeros de equipo no ven un valor agregado en cómo hacen las cosas actualmente, entonces no lo aplicarán. Y lo triste es que esto incluso cuenta para equipos formados por personas con cualquier nivel de experiencia.

El enfoque tiene problemas:

1. Tu enfoque no es simétrico. Los otros miembros de tu equipo deben cambiar, pero no estás aprendiendo sus buenas prácticas. Hacer cumplir las reglas en una situación como esta es difícil. Un mejor enfoque sería recopilar buenas reglas y prácticas de todos los miembros del equipo y luego todos simplemente leerán el documento resultante.

2. El aprendizaje es dificil. Las reglas de otras personas simplemente no tienen sentido porque esas reglas no tienen la estructura lógica que sus programadores esperan. Hacer cumplir las reglas que no tienen sentido no es una actividad útil.

3. Todos aprendieron cosas diferentes. Es natural que los programadores provenientes de diferentes entornos hayan aprendido cosas diferentes. Sus puntos fuertes son diferentes y los estilos de escritura de código diferentes. Las herramientas que usan son diferentes. Hacer cumplir un conjunto de reglas / herramientas / estilos será una pesadilla porque las limitaciones están perdiendo la fuerza que esos desarrolladores han pasado años aprendiendo.
4. El cambio lleva tiempo. Mientras que la persona que inventó las reglas que está aplicando tiene bastante facilidad para seguirlas, todos los demás sufren y pasan tiempo aprendiendo las nuevas reglas. Esta es una razón por la cual todos en el equipo deberían poder cambiar las reglas.
5. Elegir herramientas / convenciones de codificación o estilos para todo un equipo es una actividad difícil . Solo se puede hacer lentamente con el tiempo, probando qué cosas funcionan y qué no. Darle a un equipo 2 semanas para comenzar a seguir 50 reglas no va a funcionar.

Encontré este mismo problema en la universidad. Muchas personas simplemente no están dispuestas a aprender una forma de trabajo diferente (y quizás más profesional).

Sin embargo, si tiene sistemas establecidos y explica cómo usar el sistema, muchas personas están dispuestas a probarlo. También creo que los repositorios están muy por debajo de las herramientas usadas y la gente comúnmente usará algo como Dropbox.