In jedem komplexen Projekt verwenden wir viele externe Abhängigkeiten und Tools. Natürlich haben sie Fehler.
Dank Github und dergleichen ist es sehr einfach, ein Projekt zu verzweigen und Probleme in Bibliotheksabhängigkeiten zu verfolgen, sodass dies nicht der Umfang dieser Frage ist.
Die Tools können jedoch viel komplexer zu prüfen, zu debuggen und einzureichen. Beschränken wir uns hier auf die Open-Source-Werkzeuge.
Wird das Tool nur zu Entwicklungs- und Testzwecken genutzt, ist die Priorität für die Behebung dieser lästigen Fehler eher gering. Aus diesem Grund melden wir das Problem oft nicht einmal, sobald jemand eine Problemumgehung gefunden hat.
Das ist schlecht. Wir sollten die Werkzeugprobleme im Auge behalten, da sie viel über das Leben des Projekts erklären und sie irgendwo zu haben, um allen zu zeigen, dass wir es beheben können, und es wird ein gewisser Wert in diesen Korrekturen sein. Aber auf der anderen Seite können wir diese Probleme nicht in denselben Eimer wie das Projekt stecken, weil sie nichts miteinander zu tun haben und unseren Issue-Tracker verschmutzen würden.
Die Zufriedenheit meines Teams ist eine meiner obersten Prioritäten, und ich weine innerlich, wenn ich sehe, dass sie komplexe Rituale für zufällige Situationen mit bestimmten Bedingungen dokumentieren müssen, die einmal pro Woche oder seltener erfüllt werden.
Wie gehen Sie mit den Problemen im Zusammenhang mit Ihren Werkzeugen um? Wie priorisieren Sie diese Fehler?
Mir ist klar, dass meine Frage ziemlich vage ist, aber ich hoffe, sie ist trotzdem klar. Ich werde es gerne verbessern, wenn Sie einige Flüsse sehen.
Wir sollten die Werkzeugprobleme im Auge behalten, da sie viel über das Leben des Projekts erklären und sie irgendwo zu haben, um allen zu zeigen, dass wir es beheben können, und es wird ein gewisser Wert in diesen Korrekturen sein.
Alle Projekte sammeln während des typischen Projektlebenszyklus ein gewisses Maß an Stammeswissen an. Womit Sie anscheinend zu kämpfen haben, ist, wie Sie dieses Wissen richtig erfassen können.
Einige Ihrer Prozessschwierigkeiten können auf den Glauben zurückzuführen sein, dass alle Prozesse in ein einziges Tool passen – in Ihrem Fall wäre das Trello. Obwohl es verlockend sein kann, eine einzige Tracking-Technik zu verwenden, um alles zu verfolgen , kann dies manchmal kontraproduktiv sein. Scheuen Sie sich nicht, bei Bedarf zusätzliche Tracker, Wissensspeicher oder Tools hinzuzufügen. Wichtig ist, sicherzustellen, dass alle Projektbeteiligten wissen, wo wichtige Informationen wahrscheinlich zu finden sind.
Es gibt zwei offensichtliche Wege. Bei externen Tools, wie z. B. Open-Source-Projekten auf GitHub, müssen Sie das Tool nicht patchen, um einen effektiven Beitrag zu leisten. Insbesondere GitHub unterstützt im Allgemeinen Repository-spezifische Probleme und Wikis, und diese sind ein guter Ort, um Probleme und Problemumgehungen zu dokumentieren, auch wenn Sie keine dauerhafte Lösung anbieten können. Nicht-GitHub-Projekte haben natürlich andere Mechanismen, aber der Beitrag zum Upstream ist wirklich die beste langfristige Lösung.
Für interne Tools oder für externe Projekte, die keine Möglichkeit bieten, Wissen zurück in die Community zu bringen, finde ich oft, dass eine projektspezifische Wissensdatenbank oder ein Wiki immens nützlich ist. Das Werkzeug zur Wissenserfassung ist hier nicht wichtig; Entscheidend ist, dass Sie Ihre Workflows und Workarounds in einer zentralen Clearingstelle erfassen, die dem gesamten Projektteam zur Verfügung steht.
Um Prozesseffizienz und Wiederholbarkeit zu gewährleisten, sollten Werkzeuge und Infrastruktur immer über einen dokumentierten Prozess zur Implementierung von Komponenten verfügen. Dies sollte ein lebendiges Dokument sein, und wenn es auf dem neuesten Stand gehalten wird, wird es jene Teile des Stammeswissens enthalten, die derzeit verloren gehen.
Bei Softwareprojekten kann diese „lebende Dokumentation“ oft in Form von Bereitstellungs- oder Setup-Skripten vorliegen. Niemand muss Zeit damit verbringen , die Dokumentation zu lesen , solange sich das Projektteam die Zeit nimmt, die Skripte auf dem neuesten Stand zu halten. Dies ist im Wesentlichen eine Möglichkeit, technische Schulden kontinuierlich zu begleichen, und sollte wahrscheinlich eine wiederkehrende Aufgabe sein, die für jede Iteration in Ihre Definition of Done integriert wird (wenn Sie agil sind), oder an kritischen Meilensteinen oder Kontrollpunkten erneut überprüft werden, wenn Sie einer folgen traditionellere Methoden.
Ich könnte mich irren, aber es hört sich so an, als ob Sie eine große Hoffnung haben, diese Fehler zu beheben, aber vielleicht nie dazu kommen, Entwickler mit der Behebung zu beauftragen!
Bitten Sie stattdessen das Team, die geringe Zeit, die zum Erstellen der Tickets benötigt wird, im Bugtracker des jeweiligen Open-Source-Tools aufzuwenden. Bitte fügen Sie Schritte zum Reproduzieren, Fehlermeldungen, Screenshots ... und so weiter hinzu. Wenn Sie Problemumgehungen gefunden haben, fügen Sie diese bitte ebenfalls hinzu.
Dies hilft auf folgende Weise:
Wenn Sie jemals die Zeit finden, können Sie jederzeit zurückgehen, um diese Tickets zu finden und zu beheben.
In der Zwischenzeit kann jeder andere sie auch reparieren.
Und Sie werden Ihren Issue-Tracker nicht verschmutzen.
MCW
Thomas Wickham