Agilität in termingesteuerten Umgebungen praktizieren

Die einzige Möglichkeit, die Sie haben, besteht darin, den Aspekt der Transparenz und des „Arbeiten an den wichtigen Funktionen – Umfang“ von Agile zu nutzen. Die Frist ist so festgelegt, dass Sie nur herausfinden können, was wirklich benötigt wird und was das Minimum für die Markteinführung ist (der Verkauf sagt alles, aber das ist selten der Fall).

Transparenz schafft Vertrauen in das Team und zeigt der Organisation, was im gegebenen Zeitrahmen realistisch zu erreichen ist. Darüber hinaus kann dies später nützlich sein, wenn Sie über neue Geschäfte verhandeln.

Die Arbeit am Umfang ist in jedem Projekt unerlässlich, insbesondere in agilen (es gibt eigentlich nichts anderes zu tun, da Zeit und Ressourcen festgelegt sind, der einzige bewegliche Teil sollte der Umfang sein). Versuchen Sie in Ihren Sprints, mehr über den Business Case zu erfahren und herauszufinden, was Ihr Team liefern kann, damit der Kunde seine Ziele erreicht.

Es gibt immer Fristen (bei Agilität geht es nicht darum, ohne sie zu arbeiten), und Ihr Ziel sollte es sein, herauszufinden, wie Sie bei Bedarf einen echten Mehrwert liefern können. Das ist eine schöne agile Herausforderung.

Agile funktioniert gut in einer termingesteuerten Umgebung, solange der Umfang flexibel ist.

Bei Agile arbeiten wir typischerweise mit einem priorisierten Backlog von Anforderungen. Dies stellt sicher, dass, wenn wir auf eine Frist hinarbeiten, zuerst an den wichtigsten Funktionen gearbeitet wird. Je näher wir der Vereinbarung kommen, desto unwichtiger wird das Feature, an dem wir arbeiten werden. Es ist möglich, dass wir nicht alle gewünschten Arbeiten bis zum Stichtag fertigstellen, aber wir können sicher sein, dass die Arbeit, die wir nicht erledigen, eine geringere Priorität hat als die Arbeit, die wir liefern.

Es hilft auch, wenn wir im Laufe des Projekts regelmäßig Releases machen. Dies hilft den Stakeholdern (wie den Vertriebsmitarbeitern und den Kunden), konkrete Fortschritte zu sehen. Auf diese Weise können Erwartungen verwaltet werden.

Was Ihren zweiten Punkt betrifft, verwendet Scrum einen Ansatz namens „Release-Planung“. In Ihrer Situation würden Sie dies tun, indem Sie Anforderungen in Ihr Backlog aufnehmen, die die Funktionalität abdecken, die Sie für die Veröffentlichung (oder welchen Meilenstein Sie auch immer erreichen möchten) erwarten. Dies mag zunächst wie der nicht agile Ansatz erscheinen, eine Vorabspezifikation zu haben. Aber mit Agile behandeln wir das Backlog als eine dynamische Liste, die häufig aktualisiert wird. Das ist einer der Gründe, warum wir in Scrum eher mit User Stories arbeiten, die oft nur aus einem einfachen Satz bestehen. Wir fügen den Geschichten erst Details hinzu, wenn wir uns der Zeit nähern, in der wir daran arbeiten werden.

Anstelle einer starren, detaillierten Vorabspezifikation haben wir also eine weitaus weniger detaillierte, dynamische Liste von Anforderungen.

Sie können dem Kunden den gewünschten Projektfahrplan anbieten, indem Sie den Rückstand und die Geschwindigkeit des Teams verwenden, um die potenziellen Punkte aufzuzeigen, an denen die Funktionalität abgeschlossen sein wird. Wichtig ist, dass Sie Ihrem Kunden erklären müssen, dass diese Roadmap nicht in Stein gemeißelt sein wird. Es wird während Ihres Fortschritts kontinuierlich überprüft, wobei das von ihnen bereitgestellte Feedback und alle angeforderten Änderungen berücksichtigt werden. Betrachten Sie es als eine sehr dynamische Roadmap, die ständig verbessert wird.

Es mag den Anschein haben, dass der Kunde diesen Ansatz nicht mögen wird, da er eine gewisse Unsicherheit beinhaltet. Wenn Sie es Ihren Kunden jedoch sorgfältig erklären, stellen Sie möglicherweise fest, dass sie die Vorteile dieses Ansatzes verstehen, z. B. die Flexibilität, Änderungen vorzunehmen und konkrete Fortschritte in Form von Zwischenversionen zu sehen.

Problem 1:

Als Lösung für Problem 1 sollten Sie den Kunden in den Prozess einbeziehen . Als Teil von Scrum hat jeder Sprint eine Sprint-Review, die aus zwei Teilen besteht: einen, in dem Sie dem Kunden das Ergebnis dessen zeigen, was getan wurde, und einen, in dem das Team den Sprint überprüft, um zu sehen, was gut gelaufen ist und was verbessert werden muss (auch bekannt als die Retrospektive).

Die Verkaufsabteilung sollte dem Kunden gegenüber sehr deutlich machen, dass es sich bei der Frist um eine Schätzung handelt und dass der Kunde Teil des Prozesses wird, indem ihm schrittweise Demonstrationen der geleisteten Arbeit gegeben werden, damit er währenddessen Feedback geben kann. Wenn Sie einen Kunden haben, der nicht Teil des Prozesses sein möchte, wird die Lösung von Problem 1 fast unmöglich.

Außerdem wird das Image des Unternehmens leiden, solange der Vertrieb Versprechungen macht, deren Einhaltung höchst unwahrscheinlich ist. Sie müssen zu der Einsicht gebracht werden, dass es besser ist, einen späteren Termin zu haben und manchmal mit der Arbeit vorher fertig zu sein, als einen früheren Termin zu versprechen und sich mit Ausreden mehr Zeit erkaufen oder den Umfang des Projekts einschränken zu können Termin machen.

Idealerweise sollte das Team bei der Festlegung der Frist mithelfen: Zuerst erhält das Vertriebsteam die Anforderungen des Kunden, dann setzt das Team diese Anforderungen in Geschichten und Aufgaben um und schätzt grob ab, wie viel Zeit für deren Fertigstellung benötigt wird Schließlich fügen Sie und/oder das Vertriebsteam dieser Schätzung einige Sprints hinzu, um die Frist für den Kunden festzulegen. Wenn das Team nicht ausschließlich aus Schulanfängern besteht, sollte ihnen ihre Erfahrung (ob im aktuellen Team oder in einem anderen Team) helfen, diese sehr grobe Schätzung vorzunehmen, und wenn das Team zusammenbleibt, werden sie immer besser darin .

Problem 2:

Wie Sie meiner Lösung zu Problem 1 entnehmen können, stimme ich nicht ganz zu. Der Beginn des agilen Prozesses besteht darin, die Bedürfnisse des Kunden zu ermitteln und diese auf hoher Ebene zu definieren. Sobald dies erledigt ist, sollte man mit dem Kunden zusammenarbeiten, um die hochrangigen Brocken in konkretere Teile aufzuteilen, und die Priorität dieser konkreten Teile sollte bestimmt werden.

Basierend auf diesen Informationen kann das Team eine konkretere Schätzung der Arbeit vornehmen, die erforderlich sein wird, um die Stories zu erfüllen, und auf dieser Schätzung können Sie eine Roadmap aufbauen: die Abhängigkeiten ermitteln, sie mit den mit dem Kunden ausgearbeiteten Prioritäten kombinieren und jetzt können Sie eine allgemeine Roadmap definieren. Diese Roadmap wird die Realität nicht überleben, aber sie sollte ein guter Anhaltspunkt sein.

Beachten Sie, dass der Kunde manchmal darauf besteht, dass alles die gleiche Priorität hat, dass alles bis zum Abgabetermin erledigt sein muss. Dies ist niemals wahr: In einer Tabellenkalkulations-App ist die Fähigkeit der App, Berechnungen durchzuführen, sicherlich wichtiger als die Fähigkeit des Benutzers, einen Farbwähler zu haben, mit dem die Zellen in der Tabelle diese Farbe annehmen.

Denken Sie im Allgemeinen an das Projektmanagement-Dreieck !

Wenn das Projekt ein Festpreis ist, die Frist feststeht und der Umfang feststeht, kann nur noch die Qualität variieren. Wenn der Kunde ein qualitativ hochwertiges Produkt will, müssen SieFlexibilität in mindestens einem Punkt zu haben: Kosten, Zeitplan oder Umfang. Dieses Dreieck hat sich immer wieder bewährt, so zu tun, als würde es für Ihr Unternehmen nicht gelten, ist eine Illusion. Helfen Sie Ihrem Vertriebsteam, dies zu verstehen, arbeiten Sie zusammen, um einen Prozess zu etablieren, der für das Unternehmen funktioniert und für die Kunden akzeptabel ist. Unweigerlich verlieren Sie dadurch einige potenzielle Kunden, aber bedenken Sie, dass es höchstwahrscheinlich unmöglich gewesen wäre, sie von Anfang an zufrieden zu stellen. Anstatt den guten Namen des Unternehmens zu riskieren (und die potenziellen Ressourcen, die erforderlich sind, um das Produkt um jeden Preis vor Ablauf der Frist fertigzustellen...), ist es vorzuziehen, mit Kunden zusammenzuarbeiten, die die Realität der Softwareentwicklung verstehen.

Da ich von der Entwicklerseite komme, weiß ich, dass Verkäufer, die Himmel und Erde versprechen, ein ernstes Problem darstellen, insbesondere wenn sie winzige Funktionen und Gadgets versprechen, die wenig tatsächlichen Wert haben, aber tief in die Architektur und Prämissen des Systems eingreifen.

Es dauert einige Zeit (viele Monate), die Sprintgeschwindigkeiten von Teams zu bestimmen, und selbst dann sind sie nur Durchschnittswerte. Wenn Sie altmodische Zeitschätzungen mit einer optimistischen, durchschnittlichen und pessimistischen Zahl machen (z. B.: 2,3,7 Tage), ist die pessimistische Zeit oft etwa doppelt so lang und mehr als der Durchschnitt, aber Sie müssen es nehmen, wenn Sie es machen wollen eine Verpflichtung, die fast die Chance eines russischen Roulette-Kopfschusses hat, die Frist zu verpassen.

Es scheint, dass entweder Ihre Kunden in der Machtposition sind, Ihr Unternehmen zu sehr riskanten oder unmöglichen Verpflichtungen zu drängen, oder Ihr Unternehmen ist in Bezug auf Wachstum zu gierig und verspricht absichtlich mehr, als es bewältigen kann. Im ersten Fall ist es sehr riskant, weil die Kunden am Ende den Preis nicht bezahlen oder sogar Strafen fordern können. Wenn die Verkäufer keine angemessenen Fristen und ausreichend flexible Konditionen aushandeln können, ist das Unternehmen dem Untergang geweiht. Letzteres mag eine Weile funktionieren, ist aber gefährlich, da der Ruf Schaden nimmt und die Entwicklung gezwungen sein kann, technische Schulden in Form von wirklich schlechtem, überstürztem Code zu erstellen, der unmöglich zu warten, sehr schwer zu verbessern und reines Glücksspiel ist es funktioniert richtig.

Man kann Entwickler nicht hexen oder sie mit einer Peitsche schneller machen, ihre Fähigkeiten sind begrenzt. Vielleicht erlaubt Ihnen Agilität, auf eine Konsolenanwendung mit Eingabe von Befehlen und Parametern herunterzuskalieren, anstatt eine schicke GUI zum Stichtag zu haben (und den Rest vielleicht später zu machen), aber wenn es wirklich unmöglich ist, werden die Mitarbeiter den Schwarzen Peter weitergeben einander für die unvermeidliche Katastrophe.

Was auch immer Sie tun, versuchen Sie niemals, wirklich nie , Schätzungen zu unterbieten oder Entwickler dazu zu drängen, unmögliche Verpflichtungen einzugehen! Ihre Schätzungen sind ernsthafte Anforderungen, und Sie würden sie dazu drängen, darüber zu lügen. Dies würde zudem alle durch den Scrum-Prozess gewonnene Planbarkeit zunichte machen. Denken Sie daran, dass Entwickler für Softwaredesign und -programmierung da sind, keine Politiker und nicht dazu da, sich Druck zu widersetzen, sodass sie möglicherweise dem Druck nachgeben und einen niedrigeren Kostenvoranschlag akzeptieren, da sie wissen, dass sie eine solche Verpflichtung niemals erfüllen können! Jeder weiß, dass der eigentliche Arbeitsaufwand nicht mit Druck niederzuschlagen ist!

Sie haben das gleiche Problem wie bei jeder Methode. Sie laufen Gefahr, diese Frist zu verpassen!

Eine Kundenspezifikation im Voraus zu haben, ist tatsächlich ein Bonus, weil sie Ihre Erfolgskriterien definiert.

Aglie rät davon ab, im Voraus zu planen, da dies die Veränderungen bei der Erzielung von Geschäftswert beeinträchtigt. In Ihrem Fall müssen Sie dies nicht tun, sondern nur das erreichen, was angefordert wurde.

1: Stellen Sie sicher, dass Sie Ihre Frist einhalten, indem Sie *rücksichtslos* über das minimal mögliche Produkt nachdenken, das der Spezifikation entspricht. Wenn die Farbe nicht angegeben ist, ist es das, was der Entwickler an diesem Tag eingegeben hat. Wenn sie keine Antwortzeiten angegeben haben, melden Sie keinen Fehler für langsame Seiten. Du musst wirklich brutal sein, auch wenn du denkst, dass es scheiße ist. Funktionen nicht hinzufügen/ändern

2: Ziel ist es, mindestens 75 % der erlaubten Projektzeit zu beenden. Wenn Sie nicht auf dem richtigen Weg sind, machen Sie sich Sorgen.

3: Bei 50 % sollten Sie dieses Mindestprodukt fertig haben. Puh! Vertraglich sind Sie sicher. Zeigen Sie dem Kunden, dass Sie noch 25 % der Zeit haben, um auf „Bugs“ und Optimierungen zu reagieren, es schön und den Kunden glücklich zu machen, aufzupolieren usw.

4: Sperren Sie bei 75 % und beginnen Sie mit der Live-Schaltung/Bereitstellung, was auch immer. Dadurch werden immer wieder neue Bugs aufgedeckt. Sie haben noch 25% Spielraum, wenn Sie keine Probleme, neuen Funktionen, unerwarteten Krankheiten usw. hatten, um diese zu beheben. In der Praxis fragen Sie den Kunden nach weiteren 2 Wochen und den FTP-/Firewall-/Richtlinientexten, die er Ihnen letzten Monat versprochen hat.

Ich war noch nie in einem agilen Projekt ohne Deadline. Vielleicht hatte ich einfach nur Pech, aber um das Budget im ersten Fall zu bekommen, braucht man den Business Case, der eine Frist hat ...

Aus meiner Erfahrung in der Arbeit mit Agile geht es bei Fristen um die Verwaltung des Umfangs, der Teamgeschwindigkeit und der Erwartungen der Stakeholder. Ich habe Agile-Monte-Carlo-Prognose und -Tracking mit guten Ergebnissen verwendet. Zuerst in einer ziemlich komplexen Excel-Tabelle und dann durch Erstellen der folgenden Lösung. Probieren Sie es aus und lassen Sie mich wissen, was Sie denken!

https://agilemontecarlo.com/