Cómo implementar un proceso de desarrollo con estudiantes universitarios

En mi primer trabajo como desarrollador de software, mi equipo utilizó agile / scrum para administrar nuestro flujo de trabajo del proyecto y funcionó bastante bien. Tenía algunos mentores experimentados que me pusieron en el camino correcto: les debo una gran deuda de gratitud. Trabajé allí durante algunos años, luego pasé a una nueva oportunidad hace un par de meses.

Avance rápido a mi trabajo actual. Trabajo en una universidad bajo la dirección de un profesor. Como estoy en una universidad, casi todos los programadores son estudiantes (¡son baratos y abundantes!) Mi jefe tiene experiencia en administración, pero no en desarrollo de software, y el equipo de software no siempre está en la mente de mi jefe . Estas condiciones han creado el entorno perfecto para crear software de muy baja calidad. Los proyectos de software parecen funcionar un poco deshonesto, no han pensado en diseñar y han empleado algunas prácticas realmente aterradoras. Sé que las cosas podrían ser mejores.

Quiero implementar un proceso de desarrollo para ayudar a todos a encaminar, aumentar la calidad del código e implementar un software más estable. No estoy seguro de por dónde empezar.

Estoy no buscando, por ejemplo, para las respuestas como "Uso Scrum", "constituirá una comisión de Kanban", o "Tome un vistazo a ágiles!" (aunque las ideas son apreciadas). Más específicamente, espero obtener información sobre cómo implementar un proceso de desarrollo para este entorno de trabajo. Los empleados generalmente trabajan entre 1 y 2 años antes de continuar, generalmente no tienen experiencia y las reuniones diarias que incluyen a todos son casi imposibles de programar.

¿Cómo se fomenta la calidad, la eficiencia y la comunicación en tal lugar de trabajo?

Actualización: después de leer algunas de las respuestas y comentarios, pensé en proporcionar algunos antecedentes adicionales.

Yo no me considero un maestro en el arte de desarrollo de software, pero yo soy lo suficientemente experimentado para reconocer una mala programación cuando lo vea. Puedo determinar si un desarrollador tiene talento o no después de pasar solo un minuto o dos trabajando con él. Me siento cómodo con mis propias habilidades para encontrar una manera de resolver un problema de manera inteligente , sin embargo, el área en la que realmente me falta experiencia es la gestión de proyectos en la que participan otros desarrolladores (es por eso que les pido a todas ustedes maravillosas personas Consejo).

Lo hice sonar como si cada estudiante que entra en esta oficina es un completo imbécil. Aquí ha habido algunos malos huevos, pero la mayoría de los estudiantes que he conocido son inteligentes, quieren aprender y les apasiona el trabajo. Sin embargo, algunos recién están comenzando y no saben lo que no saben. Y eso esta bien. Cuando comencé a programar, ¡no estaba mejor!

Se tarda más en limpiar un error que en comprobarlo previamente. Si se trata de desarrolladores que (posiblemente) no están calificados o que desconocen las buenas prácticas, eso significa que no deberían ser capaces de alterar la base de código (maestra) hasta que alguien con experiencia haya examinado su código.

No querías una explicación de las metodologías, así que déjame echar un vistazo a esa parte: usa tareas ágiles para configurar diferentes características que se pueden desarrollar de forma independiente.

Comience a usar ramas de características, para que todos trabajen en una rama separada. Cuando finaliza una tarea, el desarrollador no puede fusionar su código con la rama maestra. Si está utilizando Git, aún pueden iniciar una solicitud de extracción. De lo contrario, utilice cualquier método de seguimiento de tareas finalizadas (/ ramas) que más le convenga.

Luego llegamos al proceso de revisión . Su pregunta es un poco vaga sobre si también hay desarrolladores experimentados en cuyo juicio se puede confiar más que en el de los estudiantes. Entonces déjenme explicarlo de cualquier manera:

Si hay desarrolladores experimentados, realice la tarea de revisar el código de las tareas terminadas. Si es bueno, pueden fusionarlo en la rama maestra. Si no es así, pueden refactorizarlo ellos mismos o dar retroalimentación al desarrollador sobre lo que debe mejorarse.

Si no hay desarrolladores experimentados, entonces siempre tendrás problemas. Si no hay nadie para detectar el código bueno del código malo, es imposible mantener la calidad del código.
Lo mejor que puede hacer es tener reuniones de revisión, donde los desarrolladores presenten y expliquen su implementación frente a los otros desarrolladores. Si bien esto no puede garantizar la prevención de todos los problemas (por ejemplo, si todos los desarrolladores tienen la misma idea errónea sobre las buenas prácticas, seguirá previniendo la mayoría de los problemas (por ejemplo, si al menos un desarrollador tiene la idea correcta y puede articularla; o cuando el problema surge) de desarrolladores que entienden el problema de manera diferente entre sí)

¿Cómo se fomenta la calidad, la eficiencia y la comunicación en tal lugar de trabajo?

• Calidad : revise el código por desarrolladores experimentados. En ausencia de desarrolladores experimentados, haga una revisión grupal para cubrir al menos sus bases lo mejor que pueda.
• Eficiencia : si configura las tareas independientes correctamente, minimiza las personas que tienen que esperar entre sí. En un entorno donde no todos están disponibles al mismo tiempo, supongo que está lidiando con muchos retrasos de "esperar a la persona A". Haga un seguimiento de los desarrolladores que no están progresando, solo para verificar si necesitan ayuda o incluso simplemente permitirles desahogar sus frustraciones (esas frustraciones pueden revelar conceptos erróneos sobre problemas evitables).
• Comunicación : establezca una política de puertas abiertas para que los desarrolladores puedan pedir ayuda, comentarios o inspiración a alguien. En ausencia de un mentor calificado, intente facilitar la interacción del equipo (por supuesto, puede hacerlo incluso si tiene un mentor disponible, pero la importancia de hacerlo aumenta en ausencia de un mentor). Especialmente en una situación en la que las personas trabajan de forma remota y en diferentes horarios, los desarrolladores a menudo no están cerca de sus compañeros de trabajo y tienden a no comunicarse entre sí. Incluso un puñado de reuniones sociales pueden hacer maravillas para mejorar la comunicación relacionada con el trabajo en otros momentos.

Lo más importante para ese tipo de entorno donde las personas son nuevas y es probable que se vayan es la revisión obligatoria del código.

Ayudan a difundir el conocimiento de lo que debe hacerse. Ayudan a evitar que el peor código ingrese a la base de código. Promueven la coherencia en la implementación.

Porque con tanta rotación e inexperiencia, la comunicación es más importante de lo que suele ser.

Es más una idea que una solución, pero encuentre una sección crítica de la base de código que contenga características y elementos similares a los proyectos que los desarrolladores de sus estudiantes podrían hacer y límpiela MUY bien. Un gran problema con los nuevos desarrolladores es que no conocen las normas y convenciones de la base de código, y buscarán otro código para tener una idea de cómo configurar el suyo. Tener muchos desarrolladores nuevos trabajando en una base de código desordenada significa que verán el desorden y pensarán que es aceptable o la mejor manera de hacer las cosas. Las malas prácticas se perpetúan incluso en un entorno de alta rotación.

Al tener al menos una sección de código prístina y bien escrita (o incluso solo un archivo), puede decirle a los desarrolladores de sus estudiantes que la usen como un ejemplo de mejores prácticas. Dígales que estará encantado si pueden escribir código similar a ese, y que gran parte del otro código podría no ser un buen ejemplo de la forma correcta de hacer las cosas.

Agregar comentarios u otra documentación con una explicación de por qué las cosas se hacen de cierta manera también ayudará a los nuevos desarrolladores a ponerse al día más rápidamente con mejores prácticas de código.

Integración continua -

Este es un marco práctico y conceptual para la implementación incremental y flexible de herramientas de equipo, habilidades y procesos.

CI es la idea de un flujo de trabajo desde la escritura del código hasta la implementación. Estas tareas son conceptuales y en realidad independientes.

CI es automatización, en particular. Esto tiene profundas implicaciones para la calidad y la productividad, comenzando en el punto donde se escribe el código en la pantalla.

• La implementación de tareas de CI se puede abordar de forma independiente, detallada y simultánea. El enfoque puede cambiar según sea necesario.
• No introduzca una herramienta CI de sopa a nueces
  • Todos se distraerán con el proceso y tenderán a blanquear las habilidades de tareas encapsuladas.
• Presente las cosas a cambio de dinero

• Espere ser el agente de cambio a tiempo completo. Conviértete en el líder; no solo un gerente, no simplemente el codificador senior.

• Ser estratégico

  • El Santo Grial de CI es una compilación automática para la implementación. No pueden FUBAR si no pueden tocarlo.
  • Capacitación y materiales de capacitación.
    • Procesos documentales.
    • Cree un Manual del programador , déjelo evolucionar orgánicamente.
    • Obligatorio.
    • Contornos de exploración dirigidos a habilidades específicas y la base del código en sí.
  • Inculcar valores de programador profesional, tales como:
    • TDD crea absolutamente calidad
    • Las revisiones de código incluyen todos los artefactos: comentarios, código comentado, pruebas unitarias, etc.
    • "Me da vergüenza la cantidad de errores encontrados"
    • La objetividad no se ve sofocada por el sentido de propiedad del código personal y el miedo a "ofender" al propietario.

• Ser táctico

  • Las tareas de CI discretas pueden automatizarse, por ejemplo, una confirmación de control de versión que desencadena la compilación y las pruebas unitarias.
  • Reglas impuestas por la automatización, como el formato de código.
    • Cuidado con demasiadas minucias pedantes. La herramienta comenzará a ser ignorada. Module la aplicación de reglas para que no sea abrumador.
  • Implemente Test Driven Development de inmediato
  • Priorizar y enfatizar cada cambio
    • No asuma que el conocimiento clave y los saltos de habilidad simplemente suceden.
  • No permita que la urgencia subvierta la implementación adecuada
  • Liderar el cambio y seguir adelante
    • Se necesita una nueva orientación de chico y un entrenamiento mínimo.
    • Formación explícita y orientación inequívoca para cosas nuevas.
    • Entrenar al menos a un mínimo, nocional, estándares. No tiene que ser realmente formal, pero un recorrido aleatorio por YouTube no es entrenamiento. Verifique personalmente, evite nuevamente la formalidad.
  • Sé el revisor del código, revisa todo el código.
    • Guíe explícitamente las correcciones de errores desafiantes y comparta experiencias de aprendizaje notables.
  • Flexibilidad rígida. Lo siento, tuve que decirlo. Pero es verdad.
• Crear cultura
  • Tener expectativas profesionales.
  • Herramientas estandarizadas
  • Enfatice el aprendizaje sobre las métricas de producción
  • Ser un mentor
  • Al introducir el cambio, simplemente dependiendo de la iniciativa de los individuos "para hacerlo" subvierte sutilmente el desarrollo del equipo. La identidad de un equipo cohesionado incluye su común: herramientas, conocimiento y nivel de habilidad. El respeto mutuo crece en la medida en que cada miembro abraza las tesis como valores dignos. El líder del equipo es el modelo, es ineludible; no modele una actitud y expectativa de "lo que sea".

El camino a la calidad

• Examen de la unidad

  • clave para el desarrollo impulsado por pruebas
    • No es necesario leer libros completos al respecto
    • Esto debería convertirse en el paradigma de codificación
    • Como líder, debes seguir haciéndolo hasta que todos hagan el "salto de fe en las pruebas unitarias". Ese cambio de paradigma de "¡Estoy escribiendo dos veces el código!" para abrazar su increíble productividad.
  • Las pruebas unitarias eran obligatorias en nuestra tienda. Pero muchos no lo hicieron porque no quisieron. La falta de convicción de la gerencia envió el mensaje de que las pruebas unitarias realmente no funcionan de todos modos.
    • Por lo tanto, las pruebas unitarias se ignoraron con demasiada frecuencia durante las revisiones de código, lo que permitió pruebas incorrectas, ineficaces y con errores en la base del código. Las pruebas unitarias carenciales destruirán todo el esfuerzo.

• Control de versiones

  • Lo pondría primero, pero es más fácil comenzar con las pruebas unitarias
  • no demore otras iniciativas porque el control de versiones no es tan fácil
  • Haz un plan de control de versiones.
    • Debes escribirlo.
    • Haga esto incluso si es tan simple como "arrojar todo en el maletero y no ramificar".

• Revisiones de código

  • Esto tiene el mayor potencial para mejorar la calidad del código en detalle.
  • Use un proceso de revisión 2.
    • Me sorprendió la cantidad de errores que detecta una segunda revisión.
    • Confiar pero verificar. Ejecuta el código. ¿Por qué deberías decir esto? Ver inmediatamente arriba.
    • Inicialmente serás el único revisor. Haga que el equipo lo vea revisar "en vivo". Nunca aprenderán a pensar lo contrario.
    • Pronto serás solo el segundo crítico. Como las habilidades individuales lo justifican, haga que las revisen; finalmente ambos revisores. Por supuesto, siempre estará mirando el código, sin excepción.

• Refactorización

  • Esta es una disciplina distinta y formal.
  • Refactorización: mejora del diseño del código existente por Martin Fowler
    • Recetas de refactorización codificadas que aseguran un cambio de código libre de errores inducidos.
    • Comience una biblioteca profesional con este libro.
  • Dejando de lado la formalidad, preséntela ad hoc a través de revisiones de código

• Captura tu entorno

  • Configuraciones de herramientas básicas: control de versiones, IDE, herramienta CI, sistema operativo, etc.
  • El código fuente, la documentación y las configuraciones deben sincronizarse en el control de versiones.

Una palabra sobre el proceso

Ágil (y sus subgéneros como Scrum): Olvídalo. "Eres ágil, no lo haces ágil". Vea esto por Dave Thomas, uno de los firmantes originales del Manifiesto Ágil .

• La corrupción de Agile - Una entrevista del Dr. Dobbs Journal
• Ágil está muerto (viva la agilidad)
• Agile está muerto : una conferencia magistral.

Dados los equipos pequeños e inexpertos, mi sentido arácnido se dispara cuando veo herramientas de integración de equipos como Visual Studio Team Services. Mi experiencia es limitada aquí, pero siento la imposición de procesos rígidos, superfluos y estúpidos. Sé que muchos usan estas cosas con gran efecto, pero ten cuidado de comprar potencialmente una solución en busca de un problema.

Una palabra sobre herramientas

Solo yo. No de esas "Mejores herramientas de software ahora ...".

Jenkins

Una herramienta de integración de CI. Basado en la web, ampliamente utilizado. Esencialmente, a través de una GUI web, configura y personaliza las diversas tareas y el orden de ejecución, como compilar, ejecutar pruebas unitarias y actualizar el control de versiones. Es muy a la carta, por lo que es adecuado para su entorno naciente de CI.

Control de versiones

Prefiero Mercurial sobre Git. Esta publicación de blog es la razón por la que elegí originalmente Mercurial: Git es MacGyver, Mercurial es James Bond

La subversión es buena. Mercurial y Git tienen una arquitectura diferente que es superior a la de Subversion.

Entorno de desarrollo integrado

Aquí hay una gran consideración si todos usan diferentes herramientas de codificación: No existe tal cosa como texto sin formato

Una palabra sobre una biblioteca profesional

Internet es amplio, poco profundo y desorganizado.

• Código completo por Steve McConnell
  • Haz que todos lean el tercio medio.
  • Tiene un apéndice de libros profesionales sugeridos.
• Refactorización: mejora del diseño del código existente
  • Recetas de refactorización codificadas que aseguran un cambio de código libre de errores inducidos.
• Fallos de software. No hay una recomendación específica, pero deberían ser historias frente a un tratado.

Propongo usar otra metodología para administrar su proceso, ya que, como usted dice, es imposible programar reuniones (¡lo cual es absolutamente importante para scrum!). Todavía no hay nada malo para hacer un buen concepto, por lo que todos saben lo que está sucediendo (probablemente también usando un prototipo de vert) y el modelo de cascada. De cualquier manera, la comunicación es la mayor parte del trabajo.

Te animo a que uses el control de fuente si aún no lo has hecho. Esto le permite ver lo que fue registrado por cada desarrollador y permite retroceder donde se introdujo un error.

Instalaría algún tipo de conjunto de pruebas. Podría ser un desarrollo impulsado por pruebas en el que escribe pruebas para cada función que está cometiendo, o podría ser una forma automatizada de ejecutar sus aplicaciones y hacer que envíen los resultados a un archivo que se pueda comparar con el deseado salida. Si esto se ejecuta después de cada confirmación, o se ejecuta al menos una vez por noche, encontrará regresiones rápidamente.

Lo último que haría es implementar 2 políticas: 1) todas las compilaciones deben tener advertencias configuradas con errores y todos los errores activados 2) Todo el código debe pasar por el analizador estático sin producir ningún error o advertencia antes de que se confirme. Incluso haría de esto una acción previa al compromiso. Estas 2 cosas evitarán que el código se vuelva horrible rápidamente de varias maneras comunes. (No atrapan todo, pero atrapan mucho).

Esto también preparará a sus estudiantes para cómo será el trabajo en el "mundo real" y les inculcará algunos hábitos razonablemente buenos.