Wir bauen ein Softwareprojekt (unter Verwendung von Python Django und einer Reihe anderer Open Source-Technologien). Das Projekt ist ziemlich groß. Um eine Idee zu geben, hat es über 50 Vorlagen.
Unser Team besteht aus Leuten, die in Django unerfahren sind. Es ist das erste Django-Projekt für uns alle. Wenn also ein Feature gewünscht wird, folgt jeder einfach dem ersten Ansatz, der ihm in den Sinn kommt, ohne eine Vorstellung von den Auswirkungen auf das, was früher getan wurde. Niemand schaut auf das große Ganze. Infolgedessen brechen oft Dinge zusammen, die in der Vergangenheit funktioniert haben.
Wir haben zwei große Probleme .
Derzeit haben wir es irgendwie geschafft, die Hälfte unseres Projekts fertigzustellen (außerdem hat sich das Projekt um 1 Jahr verzögert). Die Hälfte bleibt noch übrig. Außerdem ist ein neues Projekt entstanden. Mir wurde die Aufgabe übertragen, die Grundursachen der beiden oben genannten Probleme zu identifizieren und vorzuschlagen, wie sie minimiert werden können . Wenn wir das tun, würde sich das neue Projekt besser entwickeln.
Integrationstests mit automatisierten Tests sind eine Möglichkeit, die ich mir vorstellen kann, um die Fehler zu finden. Aber mein Ziel hier ist, irgendwie zu verhindern, dass sie überhaupt entstehen, zumindest zu minimieren.
Wie kann ich die Robustheit unseres Codes erhöhen? Mit anderen Worten, was sind Best Practices für Django-Projekte auf Unternehmensebene ?
Kann mir bitte jemand, insbesondere Personen mit Erfahrung im Management von Projekten, die richtigen Ansätze vorschlagen oder in die richtige Richtung weisen?
Über die Reihenfolge lässt sich streiten, idealerweise sollten Sie so schnell wie möglich damit beginnen :-) Es gibt wahrscheinlich noch viel mehr potenzielle Verbesserungen, aber ich denke, dies sind die wichtigsten Maßnahmen, die Sie weit nach vorne bringen können.
Wenn Sie die oben verwendeten Prinzipien / Ausdrücke besser verstehen möchten, sollten Sie sich über agile und schlanke Softwareentwicklung informieren .
Möglicherweise vermissen Sie Vorschläge speziell für Python oder Django; andere Antwortende können (und werden es hoffentlich) Ihnen solche Ratschläge geben. Meine Wahrnehmung ist, dass Ihre Probleme nicht spezifisch für Python oder Django sind, sondern eher systemische Probleme, also müssen Lösungen auch systemisch sein.
Ich sehe zwei Probleme, und Sie haben eines davon selbst identifiziert: Niemand hat die technische Aufsicht über das System als Ganzes. Bei der Integration brechen die Dinge zusammen, weil bis dahin niemand über das ganze System nachdenkt. Das andere ist, dass Ihre Leute eher als eine Ansammlung von Einzelentwicklern als als ein Team zu fungieren scheinen.
Unvertrautheit mit Django ist ein kleiner Ablenkungsmanöver. Ein größeres Problem ist, dass Ihr Team nicht genug mit dem Code vertraut ist, den Sie selbst schreiben.
Ihre Entwickler kennen weder die APIs, die Dinge kaputt machen, wenn sie nicht respektiert werden, noch die Annahmen im Design, die Dinge kaputt machen, wenn sie verletzt werden, oder die Ansätze, die andere Leute bereits ergriffen haben, um ähnliche oder verwandte Probleme zu lösen.
Dokumentation des Programmierers
Die ersten beiden können im Code selbst und/oder in einem Entwicklerhandbuch dokumentiert werden. Verwenden Sie ein Tool wie Sphinx , das automatisch Dokumentation aus richtig formatierten Docstrings generieren kann.
Das Schreiben von Tests, die sich auf die APIs konzentrieren, ist eine einfache praktische Übung, die sowohl mit der Entwicklung dieses Wissens beginnt (wenn Sie alle etwas davon tun lassen) als auch dazu beiträgt, einige der Integrationsprobleme zu vermeiden, die Sie haben (wenn Sie die Durchführung dieser Tests vorschreiben). vor dem Festschreiben).
Code-Überprüfungen
Als drittes müssen Sie die Augen aller auf mehr Code lenken als nur auf ihren eigenen. Fordern Sie Code-Reviews für alle nicht trivialen Änderungen an. Verwenden Sie ein Online-Tool wie ReviewBoard oder die Pull-Requests von GitHub, mit denen Prüfer Kommentare inline sowie allgemeine Kommentare abgeben können. Stellen Sie sicher, dass die Leute den Code zur Überprüfung posten, wenn er sich in der „ersten Entwurfsphase“ befindet, und nicht „poliert und fertig“, und konzentrieren Sie die Diskussion darauf, wie und warum die Dinge auf eine bestimmte Weise gemacht wurden, Vor- und Nachteile verschiedener Ansätze, anstatt auf Stil und Einhaltung von Kodierungsstandards. Erwarten Sie, dass das Ergebnis der Überprüfung erhebliche Umschreibungen beinhalten kann, wenn während der Überprüfung ein besserer Ansatz identifiziert wird, und dass Codeblöcke, die die Prüfer verwirren, mit Erklärungen kommentiert werden sollten.
Hoffentlich erkennt Ihr Team, dass es mit der von ihm verwendeten Technologie unerfahren ist und seine Fähigkeiten verbessern möchte. Präsentieren Sie die Code-Reviews als eine effiziente Möglichkeit, Wissen aufzubauen und zu teilen (und vermeiden Sie wie die Pest alles, was nach Konkurrenz oder Scham riecht). Stellen Sie sicher, dass sie verstehen, dass regelmäßige Überprüfungen Teil ihrer Arbeit als Entwickler sind und kein optionales Add-on. Wenn Ihre Mitarbeiter die Arbeit für jede Funktion in Rechnung stellen oder nachverfolgen, sollten sie die Überprüfungsarbeit für die zu überprüfende Funktion in Rechnung stellen: Das wird auch zu einem Gefühl der Teamverantwortung für das gesamte Produkt beitragen. Irgendwann sollten Sie feststellen, dass sich einige allgemeine Problemansätze abzeichnen, da Ihre Entwickler beginnen zu erkennen, dass dieses Problem diesem ähnlich isteine, die im letzten Build implementiert wurde und auf ähnliche Weise bearbeitet werden kann.
Planungspoker
Ich würde Ihnen empfehlen, etwas Ähnliches auch im Voraus zu tun. Sie haben nichts über den Prozess gesagt, durch den Entwicklern Funktionen zugewiesen werden, aber bringen Sie das auch in einen Teamprozess ein.
Mein Team hat festgestellt, dass Planning Poker als Struktur für technische Diskussionen sogar noch wertvoller ist als für seinen nominellen Zweck, den Aufwand zu schätzen. Es bringt uns alle dazu, über den Umfang und die Komplexität jeder Aufgabe zu sprechen, bevor wir versuchen, sie abzuschätzen; Wenn die Schätzungen dann abweichen, werden häufig Unterschiede in der Herangehensweise diskutiert. Dies hilft bei Ihrem Problem, dass einzelne Entwickler den ersten Ansatz implementieren, der ihnen in den Sinn kommt. Es wird auch bei den Code-Reviews helfen, da alle Ihre Entwickler an der vorherigen technischen Diskussion beteiligt waren.
Da Ihre Leute mit der von Ihnen verwendeten Technologie noch unerfahren sind, stellen Sie sicher, dass Sie die Liste der zu schätzenden Aufgaben ein oder zwei Wochen im Voraus verteilen, um den Leuten die Möglichkeit zu geben, sich mit der Feature-Anfrage vertraut zu machen und sich darüber zu informieren Ansätze vor dem Spiel.
Nachdem alle Aufgaben geschätzt wurden, lasse ich normalerweise mein Team die Arbeit untereinander aufteilen, solange der Aufwand und die Aufgaben mit hoher Priorität gleichmäßig verteilt sind. (Natürlich können wir im Laufe des Entwicklungszyklus neu zuweisen, wenn sich herausstellt, dass einige Arbeiten mehr oder weniger Aufwand erforderten als geschätzt.) Vermeiden Sie auch hier alles, was nach Konkurrenz oder Scham riecht.
Systemaufsicht
Diese beiden Praktiken werden Ihren Entwicklern nach und nach dabei helfen, sich des Gesamtbildes bewusst zu werden und gemeinsam die notwendige Systemaufsicht durchzuführen, aber es wird einige Zeit dauern.
In der Zwischenzeit würde ich, wenn möglich, erwägen, ein oder zwei Personen im Team zu identifizieren, die gut im systemischen Denken sind und deren Fachwissen allgemein anerkannt ist, und sie mit der Systemaufsicht beauftragen: Verständnis der Architektur und APIs sowie Identifizierung und Kuratierung von Gemeinsamkeiten Herangehensweisen an allgemeine Probleme. Diese Person sollte nach Möglichkeit an allen Code-Reviews teilnehmen; nicht als leitender Gutachter (das würde das Ziel der Verbreitung von Wissen und Verantwortung untergraben), sondern zumindest als abschließender Gutachter, um systembezogene Probleme anzusprechen, die noch nicht identifiziert wurden.
Der Teamleiter kann dies tun, wenn er/sie Zeit hat; Die Personen, die am ursprünglichen Design beteiligt waren, wären ebenfalls logische Kandidaten.
Wenn Sie sich von Anfang an an Code-Reviews und Planungsspielen für das neue Projekt beteiligen, wird es wahrscheinlich weniger notwendig sein, jemanden explizit als Systemarchitekten/Kurator zu beauftragen. Andererseits könnte es sich angesichts der Probleme, die Sie in der Vergangenheit hatten, trotzdem lohnen.
Tests und Retrospektiven
Bauen Sie Ihrem Team auf jeden Fall einen Standardsatz von Tests auf, einschließlich Integrationstests, die jede Nacht ausgeführt werden und die jeder Entwickler während der Entwicklung routinemäßig ausführen kann. Erwarten Sie, dass jede neue Funktion zusammen mit neuen Tests bereitgestellt werden sollte und dass Entwickler sie testen sollten, bevor sie sich festlegen.
Retrospektiven nach jedem Build/Delivery/Sprint sind ein wesentliches Element der kontinuierlichen Prozessverbesserung. Dazu bringe ich gerne Leckereien mit, um Wertschätzung zu zeigen und eine lockere Atmosphäre zu schaffen. Als Teamleiter beginne ich mit den allgemeinen Fragen: Was hat gut funktioniert? Was nicht? Was wollen wir beim nächsten Mal an unserem Prozess ändern? Dann mache ich meistens nur Notizen (auf dem Projektor, damit jeder es sehen kann) und moderiere die Diskussion und Entscheidungen. Es ist wichtig, sowohl die guten als auch die schlechten Dinge zu identifizieren, und es ist in Ordnung, sich über Dinge zu beschweren, die nicht gut gelaufen sind, solange Sie dann auch einige Lösungsvorschläge erhalten.
Es gibt strukturiertere Ansätze für Retrospektiven, die ich nicht ausprobiert habe, obwohl sie interessant aussehen. Aber dieser sehr grundlegende Ansatz hat für mein Team gut funktioniert.
(Übrigens leite ich ein kleines Team, das eine mittelgroße/kleine Python-Django-Webanwendung entwickelt und verwaltet. Als wir anfingen, waren wir mit Django unerfahren. Wir haben alles verwendet, was ich hier empfohlen habe.)
Tiago Cardoso
Akash Gaurav