Projektmanagement-Vorhersagen vs. Agile/Scrum-Flexibilität

[...] wie bringen Sie den Wunsch des Unternehmens nach einer Art Schätzung des Gesamtaufwands und den Wunsch, iterativ agil zu bleiben, in Einklang.

Erklären Sie ihnen, warum eine große Schätzung im Voraus völlig nutzlos sein kann.

Das Problem mit Geschäftsleuten ist, dass ihnen oft Projektmanagementfähigkeiten fehlen und sie nicht verstehen, wie Softwareentwicklung abläuft. Folglich sind sie sich der Existenz des Cone of Uncertainty und seiner Auswirkungen nicht bewusst :

• Abschätzungen (z. B. zu Dauer, Kosten oder Qualität) sind zu Beginn eines Projekts naturgemäß sehr vage
• Schätzungen und Projektpläne, die auf Schätzungen basieren, müssen regelmäßig überarbeitet werden
• Unsicherheiten können in Schätzungen eingebaut werden und sollten in Projektplänen sichtbar sein
• Annahmen, die sich später als Irrtümer erweisen, sind große Unsicherheitsfaktoren

Wenn Sie Geschäftsleuten Kostenvoranschläge geben, weil sie nicht verstehen, worum es geht, nehmen sie es als Ihr Versprechen , ihnen ein Produkt in einer bestimmten Zeit und zu einem bestimmten Preis zu liefern .

Wenn Ihr Projekt klein ist (z. B. ein paar Wochen oder Monate), Sie gute Anforderungen haben, Sie gute Spezifikationen haben, Sie wissen, wie Sie es bauen werden, Sie kennen die Leute, die es bauen werden, und die Marktbedingungen sind dann stabil Was auch immer Sie im Voraus schätzen, es könnte sogar passieren, und alle sind glücklich. Hurra!

Aber die meisten Projekte sind nicht klein. Anforderungen, auch wenn gut nicht alles zu 100 % abdecken kann, Teammitglieder können sich ändern, Marktbedingungen können sich ändern, weil Sie für einen längeren Zeitraum arbeiten, nicht nur für ein paar Wochen oder Monate, Sie haben mehr Risiken und sind gezwungen, mehr zu verdienen Annahmen usw., so dass eine heute vorgelegte Schätzung in sechs Monaten nicht viel wert ist.

Leider nehmen Geschäftsleute die Schätzung als gegeben hin und planen alle möglichen anderen Dinge rund um das Produkt (Einführungsveranstaltungen, Verwendung als Abhängigkeit für andere Geschäftsaktivitäten, Zuweisung von Budgets für andere Dinge usw.). Wenn Sie schließlich nicht rechtzeitig liefern, fliegen viele ihrer Pläne aus dem Fenster. Und es ist natürlich deine Schuld.

Natürlich können Sie im Voraus einen Kostenvoranschlag abgeben und dem Unternehmen das geben, worum es gebeten hat, aber Sie werden sie unwissend lassen und sie werden am Ende Pläne machen, die auf etwas basieren, das möglicherweise nicht passiert.

Erziehen Sie sie also:

• was eine Schätzung ist. Geben Sie einen Bereich an, keine Zahl;
• welche Risiken bestehen, welche Wahrscheinlichkeiten sie haben und wie sich dies auf die Schätzung auswirkt;
• welche Annahmen Sie getroffen haben und was passieren wird, wenn sie sich als falsch erweisen;
• warum Schätzungen fast immer falsch sind (über das Thema wurde viel geschrieben);
• und warum aufgrund der vorherigen Punkte ein iterativer und inkrementeller Ansatz besser funktioniert . Nennen Sie auch andere Vorteile (auch zu diesem Thema wurde viel geschrieben).

Wenn Sie sie darüber aufklären, warum Sie einen agilen Ansatz bevorzugen, und wenn sie verstehen, werden sie wissen, was sie zu erwarten haben, und mit Ihnen zusammenarbeiten, wenn die Dinge aus dem Ruder laufen, und sie können dann ihre Pläne und Ziele entsprechend anpassen. Wenn Sie ihnen einfach den Kostenvoranschlag geben, wie sie ihn gefragt haben, werden sie Ihnen nur die Schuld geben, wenn die Dinge aus dem Ruder laufen, und darauf bestehen, dass Sie ihnen das geben, was Sie versprochen haben, als Sie es versprochen haben, weil andere Pläne gemacht wurden, die davon abhängen.

Dies ist ein riesiges Thema, aber die Highlights wären folgende:

1) Es ist Wasserfall, nicht Scrum. Sie erstellen ein Design, erstellen Anforderungen und planen die Implementierung. Die Tatsache, dass Sie agile Begriffe verwenden, sorgt nur für Verwirrung. Das ist jetzt keine Verurteilung. Vielleicht sind Sie ganz gut im Umgang mit Wasserfall, aber die Begriffe Scrum und XP sorgen nur für Verwirrung.

2) Ein Teil des Sinns von Scrum ist, dass Sie das Produkt nach jedem Sprint versenden können, sodass die Diskussion darüber, wann es fertig sein wird, sehr unterschiedlich ist. Es wird in jedem Sprint durchgeführt und mit jedem Sprint umfassender. Das Unternehmen kann entscheiden, die Finanzierung der Arbeit einzustellen, sobald es genug hat oder festgestellt hat, dass sich der Fortschritt nicht in eine Richtung bewegt, die es unterstützen kann.

3) Sie können in Scrum mithilfe von Burn-up-Diagrammen eine Art Prognose erstellen. Ich sage „irgendwie“, weil ein Teil des Sinns von Scrum darin besteht, sich anzupassen. Das Burn-up-Diagramm basiert auf dem, was Sie heute wissen, und es wird sich ändern. In den gesündesten Fällen wird ein Burnup-Diagramm normalerweise verwendet, um Fragen zu beantworten wie: Wie wahrscheinlich ist es, dass das Produkt bis zu diesem Datum diese Merkmale aufweisen wird. Das ist etwas anders als die Frage „Wann wird es fertig sein“, aber dieser kleine Unterschied ist sehr wichtig.

Es ist üblich, dass Unternehmen der IT ein gewisses Maß an Misstrauen entgegenbringen, insbesondere wenn sie zuvor von der IT enttäuscht wurden. Wenn Sie ihr Vertrauen gewinnen, wird sich die Situation höchstwahrscheinlich ändern und sie werden Ihnen den Rücken freihalten. Dafür müssen Sie:

1. Verstehen Sie sie und ihre Schmerzpunkte, sprechen Sie ihre Sprache, fühlen Sie mit ihnen. Wenn sie erkennen, dass Sie einer von ihnen sind, werden sie Ihnen mehr vertrauen. Dafür müssen Sie die Domäne studieren, ihre Arbeitsabläufe lernen.
2. Erfüllen und übertreffen Sie ihre Erwartungen. Dafür sind gute UX-Fähigkeiten zusammen mit einem starken Entwicklerteam erforderlich.

Zuerst müssen Sie nach ihren Regeln spielen und Schätzungen abgeben. Aber sobald Sie anfangen zu liefern und ihren Respekt zu gewinnen, werden sich die Dinge ändern.

Und wenn Sie Schätzungen abgeben, vergessen Sie nicht zu erwähnen, dass Sie nach der ersten Implementierung bereit sind, ihr Feedback zu hören. Und wenn sie ihre Meinung ändern oder Vorschläge haben, sprechen Sie sie gerne an. Sie erhalten ihre Schätzung und Sie erhalten Ihre Agilität.

Das hängt natürlich alles von der Organisation ab. Einige Unternehmen (insbesondere große) haben möglicherweise strenge Richtlinien, und selbst wenn das Unternehmen agil sein möchte, haben sie nicht unbedingt die Mittel und Befugnisse, um die Regeln zu ändern.

Nichts an Scrum hindert Sie daran, eine langfristige Schätzung zu erstellen. Der Scrum-Ansatz erleichtert diese Prognosen in mehrfacher Hinsicht. Backlog-Items sind normalerweise so konzipiert, dass sie unabhängig und schätzbar sind, und die Tatsache, dass das Lieferdatum in Scrum immer das Ende eines Sprints ist, bedeutet, dass Ihre Schätzungen nur auf den nächsten Sprint genau sein müssen.

Prognosen können natürlich falsch sein. Es besteht immer die Möglichkeit unvorhergesehener Arbeiten, Verzögerungen oder Umfangsänderungen, aber das gilt unabhängig von Ihrem Ansatz und hat nichts mit Scrum zu tun.