Wie Sie Ihre Softwareprojekte effektiv erweitern können

Seit ich meine Karriere als Softwareingenieur begonnen habe, habe ich gelernt, dass das Scoping eines der schwierigsten Dinge ist, um es richtig zu machen. Leider lernen Sie in CS-Programmen an Universitäten nicht wirklich, wie man Projekte umfasst. Hier ist also mein Versuch, das, was ich zu diesem Thema gelernt habe, zu festigen.

Das Scoping ist nichts, worüber Sie während des Projekts einen Tag lang nachdenken und nie wieder nachdenken können. Um ein Projekt genau zu erfassen, müssen Sie während des gesamten Projekts auf Folgendes achten:

  1. Die Planungsphase: Die frühen Phasen der Definition des Projekts und seiner Ziele
  2. Die Scoping-Phase: Die Zeit, in der die meisten Menschen über Scoping nachdenken. Hier versuchen Sie, die Arbeit aufzulisten, die in Anbetracht der Projektziele erledigt werden muss, und abzuschätzen, wie viel Zeit dafür benötigt wird.
  3. Die Ausführungsphase: wenn Sie das Projekt tatsächlich umsetzen.

Die Planungsphase

Eines der wichtigsten Dinge, die in dieser Zeit zu tun sind, ist die Festlegung sehr spezifischer Ziele für das Projekt. Anstatt beispielsweise "X zu verbessern, um skalierbarer und performanter zu sein", könnte ein besseres und spezifischeres Ziel darin bestehen, "X durch Hinzufügen von Komponententests zu verbessern, 20.000 Abfragen pro Sekunde zu unterstützen und den begrenzten Mittelwert der Benutzerlatenz auf <= 200 ms zu reduzieren . "

Mit sehr spezifischen Zielen können Sie unbarmherzig alles abschneiden, was nicht zu diesen Zielen beiträgt, sodass Sie nicht unter dem Kriechen von Funktionen leiden. In diesem Sinne könnten Sie auch erwägen, Anti-Ziele explizit zu definieren und Must-Haves und Nice-to-Haves zu trennen.

Minimieren Sie die Stapelgröße des Projekts, indem Sie (1) eindeutige Meilensteine ​​und Prüfpunkte für das Projekt festlegen und (2) das Starten nur eines Teils des Projekts vereinfachen. Dies hilft nicht nur dabei, das Projekt aufzulösen, sondern ermöglicht es dem Team auch, das Projekt vorzeitig anzuhalten oder abzubrechen, wenn eine andere Aufgabe mit höherer Priorität ansteht.

Riskiere das Projekt so schnell wie möglich. Zwei gängige Methoden zur Risikominimierung eines Projekts sind: (1) Arbeiten an den riskantesten Teilen im Voraus und (2) Prototyping der riskantesten Teile mithilfe von Dummy-Daten und / oder Gerüsten. Wenn ein neues Open-Source-System oder ein externer Dienst verwendet wird, ist dies in der Regel ein großes Risiko.

Optimiere nicht für die Gesamtmenge der geleisteten Arbeit. Optimieren Sie stattdessen den Gesamtwirkungsgrad im Laufe der Zeit. Sobald Sie den riskantesten Teil aus dem Weg geräumt haben, sollten Sie die Arbeit an dem Teil des Projekts priorisieren, der sofort zu den größten Auswirkungen führen würde.

Hier ist eine Möglichkeit, darüber nachzudenken: Zeichnen Sie die Auswirkung eines Projekts über die Zeit, wobei die Y-Achse die Auswirkung und die X-Achse die Zeit ist. Zu Beginn des Projekts beträgt die Auswirkung 0%, und am Ende des Projekts beträgt die Auswirkung 100%. Sie möchten den Bereich unter der Kurve maximieren, indem Sie zuerst Aufgaben mit hohem ROI ausführen.

Versuchen Sie, große Systeme möglichst nicht von Grund auf neu zu schreiben. Beim Umschreiben neigen wir dazu, (1) den Arbeitsaufwand zu unterschätzen, (2) neue Funktionen und Verbesserungen hinzuzufügen und (3) ein übermäßig kompliziertes System zu erstellen, da wir uns zu sehr auf alle Mängel von konzentrieren das erste System.

Anstatt ein umfangreiches Umschreiben durchzuführen, sollten Sie Subsysteme schrittweise ersetzen. Verfügen Sie über gute Abstraktionsebenen, die das Auslagern eines Teils des alten Systems nach dem anderen unterstützen, sodass Sie nicht darauf warten müssen, dass alles getan wird, um das neue System zu testen.

Die Scoping-Phase

  • Nur die Ingenieure, die den Code schreiben, sollten die Aufgaben übernehmen. Nicht ihre Manager, nicht die PM oder die wichtigsten Stakeholder im Unternehmen.
  • Widerstehen Sie der Versuchung, den Rahmen zu unterschreiten. Seien Sie ehrlich, wie lange Aufgaben dauern werden, und nicht, wie lange Sie oder jemand anderes (wie Ihr Manager oder das Go To Market-Team) möchten, dass sie dauern.
  • Teilen Sie das Projekt in kleine Aufgaben auf, die jeweils zwei Tage oder weniger dauern. Bei Aufgaben mit einem Umfang von "ungefähr 1 Woche" dauert dies häufig länger, da Sie nicht alle erforderlichen Unteraufgaben aufgelistet haben.
  • Definieren Sie messbare Meilensteine, um zum Projektziel zu gelangen. Planen Sie jedes mit einem bestimmten Kalenderdatum, das angibt, wann dieser Meilenstein voraussichtlich erreicht wird. Stellen Sie dann eine Art externe Verantwortlichkeit für diese Meilensteine ​​her, indem Sie sie beispielsweise Ihrem Manager zuweisen und Meilenstein-Checkins einrichten.
  • Stellen Sie sich Projektzeitschätzungen als Wahrscheinlichkeitsverteilungen vor, nicht als Best-Case-Szenarien. Anstatt jemandem mitzuteilen, dass ein Feature in 6 Wochen fertiggestellt sein wird, sagen Sie ihm etwas wie "Es besteht eine 50% ige Wahrscheinlichkeit, dass das Feature in 4 Wochen fertiggestellt wird, und eine 90% ige Wahrscheinlichkeit, dass wir es in 8 Wochen fertigstellen." zwingen die Menschen, realistischer zu sein.
  • Fügen Sie Puffer hinzu, um Folgendes zu berücksichtigen: (1) Entwicklungszeit! = Kalenderzeit aufgrund von Besprechungen, Interviews und Feiertagen. Normalerweise multipliziere ich die Entwicklungszeit mit 1,5, um zur Kalenderzeit zu gelangen. (2) Unerwartete Zeit für Projektaufgaben, da es immer Aufgaben gibt, die Sie erst viel später erledigen mussten, z. B. das Umgestalten von altem Code, das Debuggen scheinbar unerklärlicher Verhaltensweisen und das Hinzufügen von Tests. Je erfahrener Sie im Scoping sind, desto kleiner würde dieser Multiplikator werden.
  • Verwenden Sie historische Daten. Behalten Sie den Überblick darüber, ob Sie in der Vergangenheit Projekte häufig über- oder unterschätzt haben (die meisten Menschen tendieren dazu, zu unterschätzen). Passen Sie Ihr Scoping entsprechend an.
  • Denken Sie daran, dass 2X die Anzahl der Personen nicht 1 / 2X die Entwicklungszeit bedeutet, was auf Kommunikationsaufwand, Hochlaufzeit usw. zurückzuführen ist.
  • Betrachten Sie das Timeboxing offener Teile des Projekts. Anstatt „das beste Stream-Verarbeitungs-Framework für dieses System zu finden“, das Monate der Forschung und des Prototyping in Anspruch nehmen kann, sollten Sie es zeitlich planen, um „ein geeignetes Streaming-Verarbeitungs-Framework in einer Woche zu finden“ Overhead.

Die Ausführungsphase

Re-scope regelmäßig während der Projektdurchführung. Verfolgen Sie für jede Aufgabe, wie viel Zeit Sie für die Aufgabe veranschlagt haben, und wie lange Sie tatsächlich gebraucht haben, um sie zu erledigen. Tun Sie dies für jeden messbaren Meilenstein. Wenn Ihr Scoping für die ersten Teile des Projekts um 50% reduziert ist, ist die Wahrscheinlichkeit, dass Ihr Scoping für den Rest des Projekts reduziert ist, ebenfalls um 50%.

Verwenden Sie Meilensteine, um zu beantworten, wie das Projekt abläuft. Als Ingenieure ist es verlockend, zu antworten, dass es bis nächste Woche oder bis Ende dieses Monats fertig sein wird. Bei diesen vagen Antworten entstehen jedoch Projekte, die immer aktuell sind Noch 2 Wochen bis zur Fertigstellung. Verwenden Sie stattdessen die (neu definierten) Meilensteine, um eine konkrete Antwort auf die verbleibende Arbeit zu geben.

Wenn das Projekt abrutscht, stellen Sie sicher, dass jeder versteht, warum das Projekt abrutscht. Entwickeln Sie anschließend eine realistische und überarbeitete Version des Projektplans. Das Projekt zu löschen oder zu kürzen ist eine mögliche Option, die in Betracht gezogen werden sollte. Lesen Sie mehr über The Sunk Cost Fallacy, wenn Sie neugierig sind, warum die Leute eher dagegen sind, ein Projekt auf die Hälfte zu kürzen.

Wenn Kredit geboten wird, wo Kredit geboten wird, stammen viele Informationen aus Gesprächen mit Ingenieuren und Managern wie Spencer Chan und Nikhil Garg, dem Lesen von Büchern wie The Effective Engineer von Edmond Lau und dem persönlichen Scoping vieler Projekte mit unterschiedlicher Genauigkeit.

Wenn ich ehrlich bin, bin ich kein Experte für das Scoping und mache immer noch regelmäßig Fehler, wenn ich nicht den oben genannten Best Practices folge. Ich dachte nur, ich würde meine bisherigen Erfahrungen dokumentieren, damit ich in Zukunft darauf zurückgreifen kann.

Wenn Ihnen dieser Beitrag gefällt, folgen Sie mir auf Twitter, um weitere Informationen zu Engineering, Prozessen und Backend-Systemen zu erhalten.