Comment mettre en œuvre un processus de développement avec des étudiants

Lors de mon premier emploi en tant que développeur de logiciels, mon équipe a utilisé Agile / Scrum pour gérer notre flux de travail de projet et cela a plutôt bien fonctionné. J'avais des mentors expérimentés qui m'ont mis sur la bonne voie - je leur dois beaucoup de gratitude. J'y ai travaillé pendant quelques années, puis je suis passé à une nouvelle opportunité il y a quelques mois.

Avance rapide vers mon emploi actuel. Je travaille dans une université sous la direction d'un professeur. Depuis que je suis dans une université, presque tous les programmeurs sont des étudiants (ils sont bon marché et abondants!) Mon patron a une expérience de gestion, mais pas avec le développement de logiciels, et l'équipe logicielle n'est pas toujours au premier plan de l'esprit de mon patron . Ces conditions ont créé l'environnement parfait pour créer des logiciels de très mauvaise qualité. Les projets logiciels semblent fonctionner un peu malhonnêtement, n'ont pas pensé à concevoir et ont utilisé des pratiques vraiment effrayantes. Je sais que les choses pourraient être meilleures.

Je veux mettre en œuvre un processus de développement pour aider tout le monde à suivre le chemin, augmenter la qualité du code et déployer des logiciels plus stables. Je ne sais pas par où commencer.

Je ne cherche pas , par exemple, des réponses comme "Utiliser Scrum", "Configurer un tableau kanban" ou "Jetez un œil à l'agile!" (bien que les idées soient appréciées). Plus précisément, j'espère avoir un aperçu de la façon de mettre en œuvre un processus de développement pour cet environnement de travail. Les employés travaillent généralement entre 1 et 2 ans avant de passer à autre chose, sont généralement inexpérimentés et les réunions de stand-up quotidiennes qui incluent tout le monde sont presque impossibles à planifier.

Comment favoriser la qualité, l'efficacité et la communication dans un tel lieu de travail?

Mise à jour: Après avoir lu certaines des réponses et des commentaires, j'ai pensé que je fournirais des informations supplémentaires.

Je ne me considère comme un maître dans l'art du développement logiciel, mais je suis assez expérimenté pour reconnaître une mauvaise programmation quand je le vois. Je peux déterminer si un développeur est talentueux ou non après avoir passé une minute ou deux à travailler avec lui. Je suis à l'aise avec mes propres capacités pour trouver un moyen de résoudre un problème intelligemment , cependant, le domaine où je manque vraiment d'expérience est la gestion de projet où d'autres développeurs sont impliqués (c'est pourquoi je suis ici pour vous demander à tous des gens merveilleux de Conseil).

J'ai donné l'impression que chaque étudiant qui entre dans ce bureau est un idiot complet. Il y a eu de mauvais œufs ici, mais la majorité des étudiants que j'ai rencontrés sont intelligents, veulent apprendre et passionnés par le travail. Certains débutent cependant et ils ne savent pas ce qu'ils ne savent pas. Et ça va. Quand j'ai commencé la programmation, je n'étais pas mieux loti!

Il faut plus de temps pour nettoyer une erreur que pour la pré-vérifier. Si vous avez affaire à des développeurs qui sont (éventuellement) non qualifiés ou qui ne connaissent pas les bonnes pratiques, cela signifie qu'ils ne devraient pas être en mesure de modifier la base de code (maître) tant que leur code n'a pas été examiné par une personne expérimentée.

Vous ne vouliez pas d'explication des méthodologies, alors laissez-moi parcourir cette partie: utilisez des tâches agiles pour configurer différentes fonctionnalités qui peuvent être développées indépendamment.

Commencez à utiliser les branches de fonctionnalité, afin que tout le monde travaille sur une branche distincte. Lorsqu'une tâche est terminée, le développeur n'est pas en mesure de fusionner son code dans la branche principale. Si vous utilisez Git, ils peuvent toujours lancer une demande de tirage. Sinon, utilisez la méthode de suivi des tâches terminées (/ branches) qui vous convient.

Ensuite, nous arrivons au processus d'examen . Ce dont vous vous interrogez est un peu vague sur la question de savoir s'il existe également des développeurs expérimentés dont le jugement peut être plus fiable que celui des étudiants. Permettez-moi donc de développer dans les deux sens:

S'il y a des développeurs expérimentés, chargez-les de revoir le code des tâches terminées. Si c'est bon, ils peuvent le fusionner dans la branche principale. Si ce n'est pas le cas, ils peuvent soit le refactoriser eux-mêmes, soit donner des commentaires au développeur sur ce qui doit être amélioré.

S'il n'y a pas de développeurs expérimentés, vous rencontrerez toujours des problèmes. S'il n'y a personne pour repérer le bon code du mauvais code, il est impossible de maintenir la qualité du code.
Le mieux que vous puissiez faire est d'organiser des réunions d'examen, où les développeurs présentent et expliquent leur mise en œuvre devant les autres développeurs. Bien que cela ne puisse garantir d'empêcher chaque problème (par exemple, si tous les développeurs ont la même idée fausse sur les bonnes pratiques, cela empêchera toujours la majorité des problèmes (par exemple, si au moins un développeur a la bonne idée et peut l'articuler; ou lorsque le problème découle de développeurs comprenant le problème différemment les uns des autres)

Comment favoriser la qualité, l'efficacité et la communication dans un tel lieu de travail?

• Qualité - Révisez le code par des développeurs expérimentés. En l'absence de développeurs expérimentés, faites-en une revue de groupe pour couvrir au moins vos bases du mieux que vous le pouvez.
• Efficacité - Si vous définissez correctement les tâches indépendantes, vous minimisez le fait que les gens doivent s’attendre les uns les autres. Dans un environnement où tout le monde n'est pas disponible en même temps, je suppose que vous faites face à de nombreux retards «en attente de la personne A». Faites le suivi des développeurs qui ne progressent pas, uniquement pour vérifier s'ils ont besoin d'aide ou même simplement leur permettre d'exprimer leurs frustrations (ces frustrations peuvent révéler des idées fausses sur les problèmes évitables).
• Communication - Définissez une politique de porte ouverte pour que les développeurs puissent demander de l'aide, des commentaires ou de l'inspiration à quelqu'un. En l'absence d'un mentor qualifié, essayez de faciliter l'interaction en équipe (vous pouvez bien sûr continuer à le faire même si vous avez un mentor disponible, mais l'importance de le faire augmente en l'absence d'un mentor). Surtout dans une situation où les gens travaillent à distance et selon des horaires différents, les développeurs ne sont souvent pas proches de leurs collègues et ont tendance à ne pas communiquer entre eux. Même une poignée de rencontres sociales peuvent faire des merveilles pour améliorer la communication liée au travail à d'autres moments.

La plus grande chose pour ce type d'environnement où les gens sont nouveaux et susceptibles de partir est la révision obligatoire du code.

Ils aident à diffuser les connaissances sur ce qui doit être fait. Ils aident à empêcher le pire code de pénétrer dans la base de code. Ils favorisent la cohérence de la mise en œuvre.

Parce qu'avec autant de chiffre d'affaires et d'inexpérience, la communication est plus importante qu'elle ne l'est habituellement.

Plus une idée qu'une solution, mais trouvez une section critique de la base de code qui contient des fonctionnalités et des éléments similaires aux projets que vos étudiants développeurs pourraient réaliser et nettoyez-la TRÈS bien. Un gros problème avec les nouveaux développeurs est qu'ils ne connaissent pas les normes et les conventions de la base de code, et ils examineront d'autres codes pour avoir une idée de la façon de configurer le leur. Avoir beaucoup de nouveaux développeurs travaillant dans une base de code désordonnée signifie qu'ils verront le désordre et penseront que c'est acceptable ou la meilleure façon de faire les choses. Les mauvaises pratiques se perpétuent alors même dans un environnement de retournement élevé.

En ayant au moins une section de code vierge et bien écrite (ou même un seul fichier), vous pouvez dire à vos étudiants développeurs de l'utiliser comme exemple de meilleures pratiques. Dites-leur que vous serez ravis s'ils peuvent écrire du code similaire à cela, et qu'une grande partie de l'autre code n'est peut-être pas un bon exemple de la bonne façon de faire les choses.

L'ajout de commentaires ou d'une autre documentation avec une explication des raisons pour lesquelles les choses sont faites d'une certaine manière aidera également les nouveaux développeurs à se mettre plus rapidement à jour avec de meilleures pratiques de code.

Intégration continue -

Il s'agit d'un cadre pratique et conceptuel pour une mise en œuvre progressive et flexible des outils, des compétences et des processus de l'équipe.

CI est l'idée d'un flux de travail de l'écriture de code au déploiement. Ces tâches sont conceptuellement et réellement indépendantes.

CI est l'automatisation, en particulier. Cela a de profondes implications pour la qualité et la productivité, à partir du moment où le code est tapé à l'écran.

• La mise en œuvre des tâches CI peut être traitée indépendamment, en détail et simultanément. La mise au point peut changer selon les besoins.
• N'introduisez pas d'outil CI soupe-aux-noix
  • Vous serez tous distraits par le processus et aurez tendance à blanchir les compétences de tâche encapsulées.
• Présentez les choses en toute sécurité

• Attendez-vous à être l'agent de changement à temps plein. Devenez le leader; pas seulement un gestionnaire, pas seulement le codeur principal.

• Soyez stratégique

  • Le Saint Graal de CI est une solution d'automatisation de compilation et de déploiement. Ils ne peuvent pas le FUBAR s'ils ne peuvent pas le toucher.
  • Formation et matériel de formation.
    • Documenter les processus.
    • Créez un manuel du programmeur , laissez-le évoluer de manière organique.
    • Obligatoire.
    • L'exploration décrit le ciblage de compétences spécifiques et la base de code elle-même.
  • Instillez des valeurs de programmeur professionnel, telles que:
    • TDD crée absolument la qualité
    • Les révisions de code incluent tous les artefacts: commentaires, code commenté, tests unitaires, etc.
    • "Je suis gêné par le nombre de bogues trouvés"
    • L'objectivité n'est pas étouffée par le sentiment d'appartenance au code personnel et la peur de «choquer» le propriétaire.

• Soyez tactique

  • Les tâches CI discrètes peuvent elles-mêmes être automatisées, par exemple une validation de contrôle de version déclenchant une compilation et des tests unitaires.
  • Règles appliquées par l'automatisation, telles que le formatage du code.
    • Méfiez-vous de trop de minutie pédante. L'outil commencera à être ignoré. Modulez l'application des règles afin que ce ne soit pas écrasant.
  • Implémentez immédiatement le développement piloté par les tests
  • Prioriser et souligner chaque changement
    • Ne présumez pas que les connaissances clés et les sauts de compétences se produisent simplement.
  • Ne laissez pas l'urgence renverser la bonne mise en œuvre
  • Menez le changement et suivez-le
    • Une nouvelle orientation des gars et une formation minimale sont nécessaires.
    • Formation explicite et conseils sans ambiguïté pour de nouvelles choses
    • Entraînez-vous au moins selon certaines normes minimales théoriques. Cela ne doit pas être vraiment formel, mais une promenade aléatoire sur YouTube n'est pas une formation. Vérifier personnellement - encore une fois éviter la formalité.
  • Soyez le réviseur de code, examinez tout le code.
    • Guidez explicitement les corrections de bogues difficiles et partagez des expériences d'apprentissage notables.
  • Flexibilité rigide. Désolé, je devais le dire. Mais c'est vrai.
• Créer la culture
  • Avoir des attentes professionnelles
  • Standardiser les outils
  • Mettre l'accent sur l'apprentissage par rapport aux métriques de production
  • Soyez un mentor
  • Lors de l'introduction du changement, simplement en fonction de l'initiative des individus "pour le rendre", subvertit subtilement le développement de l'équipe. L'identité d'une équipe cohérente comprend ses caractéristiques communes: outils, connaissances et niveau de compétence. Le respect mutuel se développe dans la mesure où chaque membre embrasse ces thèses comme des valeurs louables. Le chef d'équipe est le modèle, il est incontournable; ne modélisez pas une attitude et une attente «quoi que ce soit».

La route vers la qualité

• Tests unitaires

  • clé du développement piloté par les tests
    • Il n'est pas nécessaire de lire des livres entiers à ce sujet
    • Cela devrait devenir le paradigme de codage
    • En tant que leader, vous devez vous y tenir jusqu'à ce que tout le monde fasse le "test de foi". Ce changement de paradigme de "j'écris deux fois le code!" à embrasser sa productivité impressionnante.
  • Les tests unitaires étaient obligatoires dans notre boutique. Mais beaucoup ne l'ont pas fait parce qu'ils ne le voulaient pas. Le manque de conviction de la direction a envoyé le message que les tests unitaires ne fonctionnent pas vraiment de toute façon.
    • Les tests unitaires ont donc été trop souvent ignorés lors des révisions de code, permettant des tests erronés, inefficaces et bogués dans la base de code. Les tests unitaires inadaptés détruiront tout l'effort.

• Contrôle de version

  • Je mettrais cela en premier, mais les tests unitaires sont plus faciles à démarrer
  • ne retardez pas les autres initiatives car le contrôle de version n'est pas si simple
  • Faites un plan de contrôle de version.
    • Vous devez l'écrire.
    • Faites-le même si c'est aussi simple que «jetez tout dans le coffre et sans branchement».

• Revues de code

  • Cela a le plus grand potentiel pour améliorer la qualité du code en détail.
  • Utilisez un processus d'examen 2.
    • J'ai été très surpris du nombre de bogues détectés par un deuxième avis.
    • Faites confiance mais vérifiez. Exécutez le code. Pourquoi devriez-vous même avoir à dire cela? Voir immédiatement ci-dessus.
    • Au départ, vous serez le seul critique. Demandez à l'équipe de regarder votre critique "en direct". Ils n'apprendront jamais à penser autrement.
    • Bientôt, vous ne serez que le deuxième critique. Comme les compétences individuelles le justifient, faites-les réviser; éventuellement les deux examinateurs. Bien sûr, vous regarderez toujours le code, sans exception.

• Refactoring

  • Il s'agit d'une discipline distincte et formelle.
  • Refactoring: Améliorer la conception du code existant par Martin Fowler
    • Recettes de refactorisation codifiées qui garantissent un changement de code sans bogue induit.
    • Commencez une bibliothèque professionnelle avec ce livre.
  • Mis à part la formalité, introduisez-la ad hoc par le biais de révisions de code

• Capturez votre environnement

  • Configurations d'outils de base: contrôle de version, IDE, outil CI, OS, etc.
  • Le code source, la documentation et les configurations doivent être synchronisés dans le contrôle de version.

Un mot sur le processus

Agile (et ses sous-genres comme Scrum): Oubliez ça. "Vous êtes agile, vous ne faites pas d'agile." Découvrez-les par Dave Thomas, l'un des signataires originaux du Manifeste Agile .

• The Corruption of Agile - Une interview du Dr. Dobbs Journal
• Agile is dead (longue vie agilité)
• Agile is dead - Un discours de conférence.

Étant donné les petites équipes inexpérimentées, mon sens de l'esprit disparaît lorsque je vois des outils d'intégration d'équipe comme Visual Studio Team Services. Mon expérience est limitée ici, mais je sens une imposition de processus abrutissante, superflue et rigide. Je sais que beaucoup utilisent ces choses à bon escient, mais méfiez-vous potentiellement d'acheter une solution à la recherche d'un problème.

Un mot sur les outils

Juste moi. Pas de ces "meilleurs outils logiciels maintenant ..." des pots de miel à appâts cliquables.

Jenkins

Un outil d'intégration CI. Basé sur le Web, largement utilisé. Essentiellement, via une interface graphique Web, vous configurez et automatisez les différentes tâches et l'ordre d'exécution comme la compilation, l'exécution de tests unitaires, la mise à jour du contrôle de version. Il est très à la carte, donc il convient à votre environnement CI naissant.

Contrôle de version

Je préfère Mercurial à Git. Ce billet de blog est la raison pour laquelle j'ai choisi Mercurial à l'origine: Git est MacGyver, Mercurial est James Bond

La subversion est bonne. Mercurial & Git ont une architecture différente qui est supérieure à celle de Subversion.

Environnement de développement intégré

Voici une grosse considération si tout le monde utilise différents outils de codage: Il n'y a rien de tel que le texte brut

Un mot sur une bibliothèque professionnelle

Internet est large, peu profond et désorganisé.

• Code complet par Steve McConnell
  • Faites lire à tout le monde le tiers du milieu.
  • A une annexe de livres professionnels suggérés.
• Refactoring: Amélioration de la conception du code existant
  • Recettes de refactorisation codifiées qui garantissent un changement de code sans bogue induit.
• Défaillances logicielles. Pas de recommandation spécifique mais ce devrait être des histoires face à un traité.

Je propose d'utiliser une autre méthodologie pour gérer votre processus, car comme vous le dites, il est impossible de planifier des réunions (ce qui est absolument important pour Scrum!). Il n'y a toujours rien de mal à faire un bon concept afin que tout le monde sache ce qui se passe (probablement en utilisant un prototype vert aussi) et en utilisant un modèle en cascade. De toute façon, la communication est la plus grande partie du travail.

Je vous encourage à utiliser le contrôle de code source si vous ne l'êtes pas déjà. Cela vous permet de voir ce qui a été archivé par chaque développeur et permet de régresser où un bogue a été introduit.

Je mettrais en place une sorte de suite de tests. Il peut s'agir d'un développement piloté par les tests dans lequel vous écrivez des tests pour chaque fonction que vous validez, ou il peut s'agir d'un moyen automatisé d'exécuter vos applications et de les envoyer les résultats dans un fichier qui peut être comparé à celui souhaité. production. Si celui-ci est exécuté après chaque validation ou exécuté au moins une fois par nuit, vous trouverez rapidement des régressions.

La dernière chose que je ferais est d'implémenter 2 politiques: 1) toutes les versions doivent avoir des avertissements définis sur des erreurs et toutes les erreurs activées 2) Tout le code doit passer par l'analyseur statique sans produire d'erreurs ou d'avertissements avant d'être validé. Je ferais même une action de pré-validation. Ces 2 choses empêcheront le code de devenir rapidement horrible de plusieurs manières courantes. (Ils n'attrapent pas tout, mais ils attrapent beaucoup.)

Cela préparera également vos élèves à ce que sera le travail dans le «monde réel» et leur inculquera de bonnes habitudes.