Mein Team bestand in der Vergangenheit über mehrere Jahre im Durchschnitt aus etwa 40 Personen, oft mehr als das. Wir haben ein ziemlich komplexes Produkt, das sich über mehrere Problembereiche erstreckt. Wir haben von Wasserfall zu Scrum gewechselt und rückblickend muss ich sagen, dass beides nicht (gut) funktioniert hat. Wie mir ein PM sagte, war unser Projekt „immer gelb oder rot“ (d. h. in einem Zustand mit hohem Risiko oder ernsthaft verzögert).
Watefall "funktionierte", nachdem wir offiziell mit der Entwicklung fertig waren und zum Testen übergingen, nicht viele der offiziell fertiggestellten Funktionen funktionierten tatsächlich und eine effektive Entwicklung wurde während (langer) Tests durchgeführt und mühsam korrigiert. Man könnte sagen, dass es eine Art offizieller Wasserfall war, kombiniert mit einem darunter liegenden iterativen Prozess.
Wir sind auf Agile/Scrum (in einer sehr einfachen Form) umgestiegen. Von der Bratpfanne ins Feuer: Wir haben schreckliche Probleme, jetzt ein logisch konsistentes Produkt zu bekommen. Das ist nicht verwunderlich, wenn man bedenkt, dass wir 5 große Unterteams haben (nicht alle an einem geografischen Standort) und Conways Gesetz gilt. Außerdem neigt wiederholter Stress am Ende der Iteration über mehrere Jahre dazu, die Menschen zu erschöpfen / zu erschöpfen (das ist jedoch mein subjektives Gefühl, ich habe keine harten Daten, um das zu beweisen). Es war auch schrecklich, die Leute lange genug an einem Ort/Teilsystem des Produkts zu halten, damit sie an ihrem Platz Experten und hochproduktiv werden konnten: Ich habe den Eindruck, dass wir uns in diesem ständigen Wandel zu Alleskönnern und Meistern entwickeln nichts. Im Nachhinein kann ich nicht sagen, dass uns Scrum definitiv Vorteile gebracht hat (wir haben "Scrum of Scrums" natürlich und ich kann nicht feststellen, dass es einen Unterschied gemacht hat). Sicherlich ist das Fehlen eines großen Up-Front-Designs aus meiner POV ein schwerwiegender Fehler: Die Arbeit wird unsynchronisiert, schlecht partitioniert und muss später wiederholt oder geändert werden.
Es ist wie ein klassischer CS-Prozess-Deadlock, der gerade auf die Konzept-/Designebene verschoben wurde: Entwickler/Subteam A wartet darauf, dass Entwickler/Subteam B Design X fertigstellt, auf das er/es sich verlässt, damit er sein/sein Design Y fertigstellen kann, während Entwickler/Subteam B darauf wartet A, um sein/ihr Design Y zu machen, damit er/sie X machen kann.
Scrum sagt nichts über Infrastrukturaufgaben aus, außer „es in eine User Story zu stopfen“ (und so leidet die Infrastruktur). Zusätzliche 3 kleinere Unterthementeams (intern, extern, Content-Provider-Team, das Produkte der beiden vorherigen verwendet) für einen bestimmten Bereich können sich immer noch nicht einmal auf eine gemeinsame Datendarstellung und ein gemeinsames Format einigen. Das Nachverfolgen des Ist-Zustands einer Million Aufgaben ist ein Albtraum. Der Konsens im Team ist, dass Scrum uns keine Vorteile gebracht hat, aber zusätzliche Kosten verursacht hat. Sicherlich hat es uns nicht dazu gebracht, besser darauf zu achten, was Kunden/Endverbraucher tatsächlich brauchen.
Ich kann nicht glauben, dass ich das sage, aber für uns hat Wasserfall (etwas) besser funktioniert als Scrum (oder genauer gesagt: es war "nicht so schlimm, wenn auch nur etwas weniger schlimm").
Glücklicherweise sind einige Subsysteme ziemlich orthogonal, sonst würden wir nichts erreichen. Dies ist jedoch ein rein zufälliger Zufall: ein bisschen mehr interne Abhängigkeiten zwischen Subsystemen (in Bezug auf konzeptionelle Integrität, Leistung usw.) und wir wären Toast. Durch dummes Glück gerettet zu werden, ist kein Beweis für effektive Organisation oder Weisheit.
Aus meiner Sicht ist es so: Wenn ein Projekt klein ist (von einer Person vollständig oder in der Nähe davon erfassbar ist) oder aus einer Reihe von nahezu unabhängigen Konzepten und Funktionen besteht, funktioniert jede Methodik. Wenn ein Projekt groß ist (eine Person kann nicht einmal ein ganzes Subsystem groken + es gibt viele interne Abhängigkeiten zwischen Subsystemen in Konzepten, Design, Geschäftslogik und Algorithmen), funktioniert keine Methodik.
Die einzige Lösung, die ich persönlich sehe, wäre diese:
Wenn das nicht funktionieren sollte, muss ich sagen, dass mein Projekt für mich wie ein "gordischer Knoten aus der Hölle" ist, der aus meiner Sichtweise im Grunde (naja) unlösbar ist.
Diese superlangen Hintergrundinformationen bringen mich zu meiner Frage: Gibt es PM-Methoden, die bei großen Projekten gut funktionieren?
Ich verstehe, dass die Karte nicht die Straße ist. Sicher. Aber ich kann mir nicht vorstellen, ohne die Karte von SA nach Alaska zu kommen. :-) Wie man in der Mathematik sagt, ist Methodik für mich eine notwendige, keine hinreichende Bedingung.
Probleme:
Ich weiß, dass die Leute meine Vision als „nach Autopilot / Allheilmittel fragen“ abschießen werden, aber ich neige dazu zu glauben, dass A. Whitehall auf etwas steht, wenn er sagt, dass Fortschritt an einer Reihe von Dingen gemessen wird, die wir tun können, ohne darüber nachzudenken. Eine perfekte Methodik würde zu jedem Team passen: Haben Sie einfach den Mut, dem Verfahren zu folgen. Wenn „andere Faktoren“ – die unbekannten Faktoren – notwendig sind, um das Projekt zum Erfolg zu führen, welche sind das?
Ich fange an zu denken, dass das alles sinnlos ist. Ich habe einige grobe Beispielrechnungen durchgeführt: Stellen Sie sich vor: n Funktionen, m Klassen (unter der Annahme einer OO-Programmierung), k Softwareeigenschaften (Zuverlässigkeit, Leistung in verschiedenen Kontexten, Sicherheit, Implementierungskosten, Fehlerquoten, Zeitaufwand für die Entwicklung, Tests Kosten, Testzeit usw.), o Personen. Potenzielle Komplexität: Jedes Merkmal kann in p Klassen unterteilt werden (p kleiner als m, mit Summe aller p für alle Merkmale == m), wirkt sich auf höchstens k Merkmale aus und kann die Arbeit oder Intervention einer beliebigen Untergruppe von o Personen erfordern.
Die Worst-Case-Komplexität (Anzahl der Kombinationen) ist also n*m*k*o. mit 20 Features, 500 Klassen, 10 Aspekten und 40 Personen sind das 4000000 (4 Millionen). Geht man von einer großzügigen Freigabezeit von 18 Monaten aus, sind das 222.222 (222.000) Kombinationen pro Monat. Angenommen, wir teilen 500 (oder „m“) Klassen in 50 verwaltbare Sammlungen auf, wobei jede Sammlung intern modifizierbar/refaktorierbar ist, ohne dass sich dies auf eine andere Sammlung auswirkt. Das sind immer noch über 22.000 Kombinationen pro Monat.
Es ist menschlich nicht möglich, so viele potenzielle Auswirkungen von Merkmalen/Klassen/Personen auf k (Softwaremerkmale) zu verfolgen und die besten Kombinationen auszuwählen (im Voraus zu planen). Ein Hard-AI-Tool im Sci-Fi-Stil müsste es tun. Ansonsten werfen wir nur "Ave Mary": Vielleicht funktioniert es in genügend Fällen gut genug, dass das Projekt nicht verzögert wird. Oder vielleicht wird es nicht.
Hintergrundinformationen, um Ihnen eine bessere Vorstellung von dem betreffenden System zu geben. Dies muss aus Gründen der Vertraulichkeit sozusagen "anonymisiert" werden.
Dieser ist glücklicherweise ziemlich einfach: Agenten <-> Server, wobei der Server aus den folgenden Hauptsubsystemen besteht:
(Es gibt natürlich viele unterstützende Subsysteme, von der Server-Konfigurationskonsole über die Web-Benutzeroberfläche bis hin zur REST-API, aber ich schließe diese hier nicht ein.)
Implementierung
Technologien: C, Java, SQL. Umgebungen reichen von Hunderten bis zu Zehntausenden von Agenten (die größte Umgebung: etwa 100.000 Agenten).
Codegröße: Mehrere tausend Java-Dateien, organisiert in ca. 500 Paketen. Bisher insgesamt etwa 900 KLOC (ohne den Agenten). Es ist also nicht so groß, aber es ist komplex in dem Sinne, dass es viele Problembereiche umfasst.
Die Aggregation ist der komplexeste und ressourcenintensivste Teil der App. Wir verwenden einfaches SQL für die Leistung, aber selbst dann kann die Aggregation für große Umgebungen nicht innerhalb von 24 Stunden abgeschlossen sein (genau dann, wenn die nächste Aggregationsrunde beginnen sollte, dh am nächsten Tag). Fehlkalkulationen können schwerwiegend sein, da sie einen Kunden leicht Dutzende von Millionen US-Dollar kosten können.
Nach der Antwort von Tiago geht es nicht um die Methodik, sondern darum, wie die Methodik auf Ihre Projekte zugeschnitten wird.
Basierend auf meiner Erfahrung bei der Arbeit an Bioverteidigungsprojekten für die US-Regierung steigt mit zunehmender Komplexität eines Projekts auch Ihr Bedarf an Vorausplanung und gründlicher Projektüberwachung. Unabhängig davon, ob Sie Wasserfall oder Agile oder was auch immer verwenden:
Die Frage, ob es eine Methode gibt , die für ein großes Projekt gut funktioniert, klingt wie die Frage, ob eine Landkarte jemanden von Südamerika nach Alaska führen kann.
Gibt es eine (Methodik oder Karte)? Ja. Wird es das (Arbeiten oder Reisen) von selbst erledigen? Definitiv nein.
Eine Methodik ist eine Richtlinie. Aber wie die Karte sind es nur Vorschläge, wie man etwas oder irgendwo erreichen kann, nicht das Schicksal selbst.
Sie haben Waterfall x Agile erwähnt. Es gibt HIER eine sehr gute Diskussion zu diesem Thema , und ich glaube, Pawels Antwort ist erstaunlich (wie immer!). In Ihrem Fall als großes Projekt scheint eine formellere Methodik besser zu passen (z. B. Wasserfall), aber es gibt keine strenge Regel, die dies besagt.
Fazit: Das Problem ist nicht die Karte . Das Problem ist nicht die Methodik . Abgesehen davon ist die zugrunde liegende Frage hier:
Was ist Ihr Projekt Nummer eins? Oder warum Ihre Projekte immer zwischen gelb / rot sind?
Sie müssen die Grundursache Ihrer Projektprobleme ermitteln und können dann beurteilen, welche Methodik am besten zu Ihrem Projekt passt. Nicht umgekehrt.
In den Kommentaren ging das OP auf seine Projektumgebung ein. Er sagte:
[D]as Hauptproblem bei unserem Projekt ist nicht, dass es entweder groß in KLOC/FP oder "komplex" ist ... Das Problem ist, dass das Projekt eher wie eine "Schüssel Büroklammern" ist als ein Haufen unabhängiger Features - Sie können kein Feature oder Problem anfassen, ohne die meisten anderen Aspekte, Subsysteme und Probleme zu beeinflussen.
So wie ich es verstehe, besteht das Problem darin, dass die Projektaufgaben, Meilensteine, Funktionen und Ziele so voneinander abhängig sind, dass jede Änderung oder Abweichung eine Überarbeitung des gesamten Projektplans und/oder Zeitplans erfordert.
Dies ist also ein X/Y-Problem, weil:
Basierend auf meinem Verständnis der Grundursache würde ich empfehlen, den Projektplan zu überarbeiten, anstatt den Projektmanagementprozess neu zu gestalten. Speziell:
Sie könnten auch in Betracht ziehen, die starken Abhängigkeiten zwischen Aufgaben als Projektrisiko zu behandeln. Dokumentieren Sie das Risiko angemessen, melden Sie die Risiken der vorgelagerten Geschäftsleitung und lassen Sie sie entweder das Risiko akzeptieren oder die erforderlichen Maßnahmen zur Risikominderung genehmigen.
Wenn alles andere fehlschlägt, setzen Sie schließlich einen Maßstab dafür, wann das Projekt so weit außerhalb der Toleranz liegt, dass es zum Abbruch empfohlen werden sollte. Während es normalerweise nicht die Rolle des Projektmanagers ist, das Ziehen des Steckers zu genehmigen, liegt es sicherlich in Ihrem Bereich, die Grenzen des Risikos und der Kapitalausgaben zu identifizieren, die das Unternehmen zu tolerieren bereit ist. Sobald diese Informationen bekannt sind, können Sie mit dieser Kennzahl umgehen und eine rechtzeitige vorzeitige Beendigung empfehlen (wenn ein Scheitern unvermeidlich ist), um dem Unternehmen Geld zu sparen.
Waterfall wird erfolgreich bei den größten Projekten der Welt eingesetzt, z. B. 500 Personen über 6 Jahre mit Kosten von 21 Milliarden US-Dollar. Dies sind hauptsächlich Infrastrukturprojekte (Brücken, Tunnel und Eisenbahnen), Luft- und Raumfahrt- und Verteidigungsprojekte (Flugzeuge und Waffensysteme) und Energieprojekte (Pipelines, Bohrinseln).
Nicht die Methodik scheitert, sondern die Umsetzung und die „Vibes“ des Projektumfelds. Als Beispiel für „Vibes“ in der Projektumgebung komme ich gerade von einem Workshop zurück, der die 3,3-Milliarden-Dollar-Entwicklung des Kampfflugzeugs FA-18 Hornet untersuchte. Einer der kritischen Erfolgsfaktoren, die für das Projekt genannt wurden, war die Schaffung einer Atmosphäre des Vertrauens und des genauen Datenflusses im Projekt.
Sie müssen sich die Organisation, die Führung und das Projektumfeld ansehen. Das ist kein methodisches Problem.
David Espina
Tiago Cardoso
Todd A. Jacobs
mrkafk
mrkafk
Tiago Cardoso
mrkafk
mrkafk
Tiago Cardoso