Wie man einen Entwicklungsprozess mit Studenten implementiert

Bei meinem ersten Job als Softwareentwickler verwendete mein Team Agile / Scrum, um unseren Projektworkflow zu verwalten, und es funktionierte ziemlich gut. Ich hatte einige erfahrene Mentoren, die mich auf den richtigen Weg gebracht haben - ich bin ihnen zu großem Dank verpflichtet. Ich habe dort einige Jahre gearbeitet und bin dann vor ein paar Monaten zu einer neuen Gelegenheit übergegangen.

Schneller Vorlauf zu meinem aktuellen Job. Ich arbeite an einer Universität unter der Leitung eines Professors. Da ich an einer Universität bin, ist fast jeder Programmierer ein Student (sie sind billig und reichlich!). Mein Chef hat Managementerfahrung, aber nicht mit Softwareentwicklung, und das Softwareteam ist nicht immer im Kopf meines Chefs . Diese Bedingungen haben die perfekte Umgebung für die Erstellung von Software von sehr schlechter Qualität geschaffen. Softwareprojekte scheinen ein bisschen schelmisch zu sein, haben nicht daran gedacht zu entwerfen und haben einige wirklich beängstigende Praktiken angewandt. Ich weiß, dass es besser sein könnte.

Ich möchte einen Entwicklungsprozess implementieren, um alle auf den richtigen Weg zu bringen, die Codequalität zu verbessern und stabilere Software bereitzustellen. Ich bin mir einfach nicht sicher, wo ich anfangen soll.

Ich suche nicht nach Antworten wie "Scrum verwenden", "Kanban-Board einrichten" oder "Agile ansehen!" (obwohl Ideen geschätzt werden). Insbesondere hoffe ich, einen Einblick in die Implementierung eines Entwicklungsprozesses für diese Arbeitsumgebung zu erhalten. Die Mitarbeiter arbeiten in der Regel 1 bis 2 Jahre vor ihrem Wechsel, sind in der Regel unerfahren und es ist nahezu unmöglich, tägliche Standup-Meetings zu planen, an denen alle teilnehmen.

Wie fördert man Qualität, Effizienz und Kommunikation an einem solchen Arbeitsplatz?

Update: Nachdem ich einige der Antworten und Kommentare gelesen hatte, dachte ich, ich würde zusätzliche Hintergrundinformationen liefern.

Ich würde mich nicht als Meister der Kunst der Softwareentwicklung betrachten, aber ich bin erfahren genug, um schlechte Programmierung zu erkennen, wenn ich sie sehe. Ich kann feststellen, ob ein Entwickler talentiert ist oder nicht, nachdem ich nur ein oder zwei Minuten mit ihm gearbeitet habe. Ich bin mit meinen eigenen Fähigkeiten vertraut , um einen Weg zu finden, um ein Problem intelligent zu lösen. Der Bereich, in dem mir wirklich die Erfahrung fehlt, ist das Projektmanagement, an dem andere Entwickler beteiligt sind (weshalb ich Sie alle hier um wunderbare Leute bitte Rat).

Ich habe es so klingen lassen, als wäre jeder Student, der in dieses Büro kommt, ein Vollidiot. Es gab einige schlechte Eier hier, aber die Mehrheit der Studenten, die ich getroffen habe, sind intelligent, wollen lernen und leidenschaftlich über die Arbeit. Einige fangen gerade erst an und wissen nicht, was sie nicht wissen. Und das ist okay. Als ich anfing zu programmieren, ging es mir nicht besser!

Das Aufräumen eines Fehlers dauert länger als das Vorabprüfen. Wenn Sie mit Entwicklern zu tun haben, die (möglicherweise) nicht qualifiziert sind oder sich bewährter Verfahren nicht bewusst sind, bedeutet dies, dass sie die (Master-) Codebasis erst ändern können sollten, wenn ihr Code von einer erfahrenen Person überprüft wurde.

Sie wollten keine Erklärung der Methoden, also lassen Sie mich diesen Teil überfliegen: Verwenden Sie agile Aufgaben, um verschiedene Funktionen einzurichten, die unabhängig voneinander entwickelt werden können.

Verwenden Sie Feature-Zweige, damit jeder an einem separaten Zweig arbeitet. Wenn eine Aufgabe abgeschlossen ist, kann der Entwickler seinen Code nicht mit dem Hauptzweig zusammenführen. Wenn Sie Git verwenden, können sie dennoch eine Pull-Anfrage starten. Verwenden Sie andernfalls eine beliebige Methode zum Verfolgen abgeschlossener Aufgaben (/ Zweige), die Ihnen gefällt.

Dann kommen wir zum Überprüfungsprozess . Was Sie fragen, ist etwas vage, ob es auch erfahrene Entwickler gibt, denen man mehr vertrauen kann als den Studenten. Lassen Sie mich so oder so näher darauf eingehen:

Wenn es erfahrene Entwickler gibt, beauftragen Sie sie mit der Überprüfung des Codes der abgeschlossenen Aufgaben. Wenn es gut ist, können sie es in den Hauptzweig zusammenführen. Wenn dies nicht der Fall ist, können sie es entweder selbst umgestalten oder dem Entwickler Feedback geben, was verbessert werden muss.

Wenn es keine erfahrenen Entwickler gibt, werden Sie immer auf Probleme stoßen. Wenn es niemanden gibt, der guten Code von schlechtem Code unterscheidet, ist es unmöglich, die Codequalität aufrechtzuerhalten.
Das Beste, was Sie tun können, sind Überprüfungsmeetings, in denen Entwickler ihre Implementierung vor den anderen Entwicklern präsentieren und erläutern . Dies kann zwar nicht garantieren, dass jedes Problem verhindert wird (z. B. wenn alle Entwickler das gleiche Missverständnis bezüglich bewährter Verfahren haben, verhindert jedoch die Mehrzahl der Probleme (z. B. wenn mindestens ein Entwickler die richtige Idee hat und sie artikulieren kann oder wenn das Problem auftritt) von Entwicklern, die das Problem unterschiedlich verstehen)

Wie fördert man Qualität, Effizienz und Kommunikation an einem solchen Arbeitsplatz?

• Qualität - Überprüfen Sie den Code von erfahrenen Entwicklern. Wenn keine erfahrenen Entwickler vorhanden sind, sollten Sie eine Gruppenüberprüfung durchführen, um zumindest Ihre Grundlagen so gut wie möglich abzudecken.
• Effizienz - Wenn Sie die unabhängigen Aufgaben richtig einstellen, minimieren Sie die Wartezeiten der Mitarbeiter. In einer Umgebung, in der nicht alle gleichzeitig verfügbar sind, haben Sie vermutlich viele Verzögerungen beim Warten auf Person A. Verfolgen Sie Entwickler, die keine Fortschritte machen, nur um zu überprüfen, ob sie Hilfe benötigen oder ihnen nur erlauben, ihre Frustrationen abzulassen (diese Frustrationen können Missverständnisse über vermeidbare Probleme aufdecken).
• Kommunikation - Legen Sie eine Richtlinie für offene Türen fest, damit Entwickler jemanden um Hilfe, Feedback oder Inspiration bitten können. Versuchen Sie in Abwesenheit eines qualifizierten Mentors, die Teaminteraktion zu erleichtern (Sie können dies natürlich auch dann tun, wenn Sie einen Mentor zur Verfügung haben, aber die Wichtigkeit, dies zu tun, steigt in Abwesenheit eines Mentors). Insbesondere in Situationen, in denen Mitarbeiter remote und nach unterschiedlichen Zeitplänen arbeiten, stehen Entwickler ihren Mitarbeitern häufig nicht nahe und kommunizieren in der Regel nicht untereinander. Selbst eine Handvoll gesellschaftlicher Zusammenkünfte kann zu anderen Zeiten Wunder bewirken, um die arbeitsbezogene Kommunikation zu verbessern.

Das Größte für diese Art von Umgebung, in der Menschen neu sind und wahrscheinlich gehen, sind obligatorische Codeüberprüfungen.

Sie helfen dabei, Wissen darüber zu verbreiten, was getan werden sollte. Sie verhindern, dass der schlechteste Code in die Codebasis gelangt. Sie fördern die Kohärenz bei der Umsetzung.

Denn bei so viel Umsatz und Unerfahrenheit ist Kommunikation wichtiger als gewöhnlich.

Eher eine Idee als eine Lösung, aber finden Sie einen kritischen Abschnitt der Codebasis, der ähnliche Funktionen und Elemente wie Projekte enthält, die Ihre Schülerentwickler möglicherweise durchführen, und bereinigen Sie ihn SEHR gut. Ein großes Problem bei neuen Entwicklern besteht darin, dass sie die Normen und Konventionen der Codebasis nicht kennen und sich anderen Code ansehen, um eine Vorstellung davon zu bekommen, wie sie ihre eigenen einrichten können. Wenn viele neue Entwickler in einer chaotischen Codebasis arbeiten, werden sie das Chaos sehen und denken, dass dies akzeptabel oder der beste Weg ist, Dinge zu tun. Schlechte Praktiken setzen sich dann auch in einer Umgebung mit hohem Umsatz fort.

Wenn Sie mindestens einen makellosen, gut geschriebenen Codeabschnitt (oder sogar nur eine Datei) haben, können Sie Ihren Schülerentwicklern anweisen, diesen als Beispiel für Best Practices zu verwenden. Sagen Sie ihnen, dass Sie begeistert sein werden, wenn sie ähnlichen Code schreiben können und dass ein Großteil des anderen Codes möglicherweise kein gutes Beispiel für die richtige Vorgehensweise ist.

Das Hinzufügen von Kommentaren oder anderer Dokumentation mit einer Erklärung, warum Dinge auf eine bestimmte Weise ausgeführt werden, hilft auch neuen Entwicklern, sich schneller mit besseren Code-Praktiken vertraut zu machen.

Kontinuierliche Integration -

Dies ist ein praktischer und konzeptioneller Rahmen für die schrittweise und flexible Implementierung von Teamwerkzeugen, -fähigkeiten und -prozessen.

CI ist die Idee eines Workflows vom Schreiben von Code bis zur Bereitstellung. Diese Aufgaben sind konzeptionell und tatsächlich unabhängig.

CI ist insbesondere die Automatisierung. Dies hat tiefgreifende Auswirkungen auf Qualität und Produktivität, beginnend an dem Punkt, an dem Code auf dem Bildschirm eingegeben wird.

• Die Implementierung von CI-Aufgaben kann unabhängig, detailliert und gleichzeitig erfolgen. Der Fokus kann sich nach Bedarf verschieben.
• Führen Sie kein CI-Tool für Suppen-Nüsse ein
  • Sie werden durch den Prozess abgelenkt und neigen dazu, die gekapselten Aufgabenfähigkeiten zu tünchen.
• Stellen Sie Dinge auf der Basis des Geldes vor

• Erwarten Sie, der Vollzeit-Change Agent zu sein. Werde der Anführer. nicht nur ein Manager, nicht nur der Senior Coder.

• Seien Sie strategisch

  • Der Heilige Gral von CI ist eine praktische Zusammenstellung zur Automatisierung der Bereitstellung. Sie können es nicht FUBAREN, wenn sie es nicht berühren können.
  • Schulungen und Schulungsunterlagen.
    • Prozesse dokumentieren.
    • Erstellen Sie ein Programmierhandbuch und lassen Sie es sich organisch weiterentwickeln.
    • Verpflichtend.
    • Die Erkundung beschreibt bestimmte Fähigkeiten und die Codebasis selbst.
  • Vermitteln Sie professionelle Programmiererwerte wie:
    • TDD schafft absolut Qualität
    • Codeüberprüfungen umfassen alle Artefakte: Kommentare, auskommentierter Code, Komponententests usw.
    • "Es ist mir peinlich, wie viele Fehler gefunden wurden"
    • Die Objektivität wird nicht durch das Gefühl des Besitzes von persönlichem Code und die Angst, den Eigentümer zu "beleidigen", behindert.

• Sei taktisch

  • Diskrete CI-Aufgaben können selbst automatisiert werden, z. B. ein Versionskontroll-Commit, das Kompilierungs- und Komponententests auslöst.
  • Durch Automatisierung erzwungene Regeln, z. B. Code-Formatierung.
    • Hüten Sie sich vor zu viel pedantischen Kleinigkeiten. Das Tool wird ignoriert. Modulieren Sie die Durchsetzung von Regeln, damit sie nicht überwältigend sind.
  • Implementieren Sie Test Driven Development sofort
  • Priorisieren und betonen Sie jede Änderung
    • Gehen Sie nicht davon aus, dass wichtige Wissens- und Fähigkeitssprünge einfach passieren.
  • Lassen Sie nicht zu, dass die Dringlichkeit die ordnungsgemäße Implementierung untergräbt
  • Führe die Veränderung und folge durch
    • Neue Orientierung und ein wenig Training sind notwendig.
    • Explizites Training und eindeutige Anleitung für neue Dinge
    • Trainieren Sie mindestens einige fiktive Mindeststandards. Muss nicht wirklich formal sein, aber ein zufälliger Spaziergang durch YouTube ist kein Training. Persönlich überprüfen - wieder Formalität vermeiden.
  • Seien Sie der Code-Prüfer und überprüfen Sie den gesamten Code.
    • Führen Sie herausfordernde Fehlerbehebungen explizit durch und teilen Sie bemerkenswerte Lernerfahrungen.
  • Starre Flexibilität. Entschuldigung, musste es sagen. Aber es ist wahr.
• Kultur schaffen
  • Professionelle Erwartungen haben
  • Werkzeuge standardisieren
  • Betonen Sie das Lernen über Produktionsmetriken
  • Sei ein Mentor
  • Wenn man Veränderungen einführt, untergräbt dies einfach die Teamentwicklung auf subtile Weise, abhängig von der Initiative des Einzelnen, "um es so zu machen". Die Identität eines zusammenhängenden Teams umfasst Folgendes: Werkzeuge, Wissen und Können. Der gegenseitige Respekt wächst in dem Maße, in dem jedes Mitglied diese als würdige Werte anerkennt. Der Teamleiter ist das Modell, es ist unausweichlich; Modellieren Sie keine "was auch immer" Haltung und Erwartung.

Der Weg zur Qualität

• Unit Testing

  • Schlüssel zur testgetriebenen Entwicklung
    • Es ist nicht notwendig, ganze Bücher darüber zu lesen
    • Dies sollte sich die Codierung Paradigma
    • Als Anführer müssen Sie so lange dranbleiben, bis alle den "Unit-Testing-Sprung des Glaubens" geschafft haben. Dieser Paradigmenwechsel von "Ich schreibe zweimal den Code!" zu seiner unglaublichen Produktivität zu umarmen.
  • Unit-Tests waren in unserem Shop obligatorisch. Aber viele haben es nicht getan, weil sie es nicht wollten. Die mangelnde Überzeugung des Managements hat die Nachricht gesendet, dass Unit-Tests sowieso nicht wirklich funktionieren.
    • Daher wurden Komponententests bei Codeüberprüfungen zu oft ignoriert, sodass falsche, ineffektive und fehlerhafte Tests in die Codebasis aufgenommen wurden. Lackadasische Unit-Tests zerstören den gesamten Aufwand.

• Versionskontrolle

  • Ich würde dies an die erste Stelle setzen, aber Unit-Tests sind einfacher zu beginnen
  • Verzögern Sie andere Initiativen nicht, da die Versionskontrolle nicht so einfach ist
  • Erstellen Sie einen Versionskontrollplan.
    • Sie müssen es aufschreiben.
    • Tun Sie dies auch dann, wenn es so einfach ist wie "alles in den Kofferraum werfen und keine Verzweigung".

• Codeüberprüfungen

  • Dies hat das größte Potenzial zur detaillierten Verbesserung der Codequalität.
  • Verwenden Sie einen 2-Überprüfungsprozess.
    • Ich war sehr überrascht, wie viele Fehler eine zweite Bewertung abfängt.
    • Vertrauen, aber überprüfen. Führen Sie den Code aus. Warum solltest du das überhaupt sagen müssen? Siehe unmittelbar oben.
    • Zunächst sind Sie der einzige Gutachter. Lassen Sie das Team beobachten, wie Sie "live" bewerten. Sie werden nie lernen, anders zu denken.
    • Bald sind Sie nur noch der zweite Rezensent. Wenn individuelle Fähigkeiten erforderlich sind, lassen Sie sie überprüfen. schließlich beide Rezensenten. Sie werden sich natürlich immer ausnahmslos den Code ansehen.

• Refactoring

  • Dies ist eine eigenständige, formale Disziplin.
  • Refactoring: Verbesserung des Designs von vorhandenem Code von Martin Fowler
    • Codierte Refactoring-Rezepte, die eine fehlerfreie Codeänderung gewährleisten.
    • Beginnen Sie mit diesem Buch eine professionelle Bibliothek.
  • Abgesehen von der Formalität, führen Sie sie ad hoc durch Codeüberprüfungen ein

• Erfassen Sie Ihre Umgebung

  • Grundkonfigurationen des Tools: Versionskontrolle, IDE, CI-Tool, Betriebssystem usw.
  • Quellcode, Dokumentation und Konfigurationen sollten in der Versionskontrolle synchronisiert werden.

Ein Wort zum Prozess

Agile (und seine Subgenres wie Scrum): Vergiss es. "Sie sind agil, Sie machen nicht agil." Sehen Sie diese von Dave Thomas, einem der ursprünglichen Unterzeichner des Agilen Manifests .

• Die Korruption des Agilen - Ein Interview aus dem Dr. Dobbs Journal
• Agile ist tot (es lebe die Agilität)
• Agile ist tot - Eine Keynote zur Konferenz.

Bei kleinen, unerfahrenen Teams geht mir der Sinn aus, wenn ich Teamintegrationstools wie Visual Studio Team Services sehe. Meine Erfahrung ist hier begrenzt, aber ich spüre eine stultifizierende, überflüssige, starre Prozessauferlegung. Ich weiß, dass viele diese Dinge mit großer Wirkung nutzen, aber hüten Sie sich davor, eine Lösung zu kaufen, die nach einem Problem sucht.

Ein Wort zu Tools

Nur ich. Nicht von diesen "Best Software Tools now ..." Klick-Köder-Honigtöpfen.

Jenkins

Ein CI-Integrationstool. Webbasiert, weit verbreitet. Im Wesentlichen konfigurieren und automatisieren Sie über eine Web-GUI die verschiedenen Aufgaben und Ausführungsreihenfolgen wie Kompilieren, Ausführen von Komponententests und Aktualisieren der Versionskontrolle. Es ist sehr A-la-Carte und daher für Ihre entstehende CI-Umgebung geeignet.

Versionskontrolle

Ich bevorzuge Mercurial gegenüber Git. In diesem Blog-Beitrag habe ich ursprünglich Mercurial ausgewählt: Git ist MacGyver, Mercurial ist James Bond

Subversion ist gut. Mercurial & Git haben eine andere Architektur, die der von Subversion überlegen ist.

Integrierte Entwicklungsumgebung

Hier ist eine große Überlegung, wenn jeder unterschiedliche Codierungswerkzeuge verwendet: Es gibt keinen einfachen Text

Ein Wort zu einer professionellen Bibliothek

Das Internet ist breit, flach und unorganisiert.

• Code komplett von Steve McConnell
  • Lassen Sie alle das mittlere Drittel lesen.
  • Hat einen Anhang mit vorgeschlagenen Fachbüchern.
• Refactoring: Verbesserung des Designs von vorhandenem Code
  • Codierte Refactoring-Rezepte, die eine fehlerfreie Codeänderung gewährleisten.
• Softwarefehler. Keine spezifische Empfehlung, aber es sollten Geschichten gegenüber einer Abhandlung sein.

Ich schlage vor, eine andere Methode zur Verwaltung Ihres Prozesses zu verwenden, da es, wie Sie sagen, unmöglich ist, Besprechungen zu planen (was für Scrum absolut wichtig ist!). Es gibt immer noch nichts Schlechtes, um ein gutes Konzept zu erstellen, sodass jeder weiß, was los ist (wahrscheinlich auch mit einem Vert-Prototyp) und das Wasserfallmodell verwendet. In jedem Fall ist Kommunikation der größte Teil der Arbeit.

Ich würde Sie ermutigen, die Quellcodeverwaltung zu verwenden, wenn Sie dies noch nicht getan haben. Auf diese Weise können Sie sehen, was von jedem Entwickler eingecheckt wurde, und es kann zurückgeführt werden, wo ein Fehler aufgetreten ist.

Ich würde eine Art Testsuite einrichten. Dies kann eine testgetriebene Entwicklung sein, bei der Sie Tests für jede von Ihnen festgelegte Funktion schreiben, oder es kann eine automatisierte Methode sein, Ihre Anwendung (en) auszuführen und sie die Ergebnisse in eine Datei ausgeben zu lassen, die mit der gewünschten verglichen werden kann Ausgabe. Wenn dies nach jedem Commit oder mindestens einmal pro Nacht ausgeführt wird, werden Sie schnell Regressionen finden.

Als letztes würde ich zwei Richtlinien implementieren: 1) Für alle Builds müssen Warnungen auf Fehler gesetzt und alle Fehler aktiviert sein. 2) Der gesamte Code muss den statischen Analysator durchlaufen, ohne Fehler oder Warnungen zu erzeugen, bevor er festgeschrieben wird. Ich würde dies sogar zu einer Pre-Commit-Aktion machen. Diese beiden Dinge verhindern, dass der Code auf verschiedene Arten schnell schrecklich wird. (Sie fangen nicht alles, aber sie fangen viel.)

Dies bereitet Ihre Schüler auch darauf vor, wie die Arbeit in der "realen Welt" aussehen wird, und vermittelt ihnen einigermaßen gute Gewohnheiten.