Ist es möglich, flexibel agil mit Projekten umzugehen, bei denen sowohl die benötigte Zeit als auch die eingesparte Zeit geschätzt werden müssen?

Als jemand, der zuvor effektiv mit Agile zusammengearbeitet hat, versuche ich, meine derzeitigen Arbeitgeber von seinen Vorteilen zu überzeugen. Das Management besteht jedoch darauf, dass wir weiterhin in der Lage sind, Vorausschätzungen vorzunehmen, um den geschäftlichen Wert von Projekten zu bewerten.

Die meisten meiner Kunden sind interne Kunden, und ich wurde kürzlich damit beauftragt, Teams aufzusuchen und sie nach Ideen für die Automatisierung von Geschäftsprozessen zu fragen. Ich musste dann herausfinden, wie viel Zeit sie dafür benötigten, herausfinden, wie viel Zeit die Lösung einsparen würde, und die gesamte Entwicklungszeit abschätzen. Auf diese Weise könnten Manager versuchen zu messen, wie effektiv eine Lösung in Bezug auf die Zeitersparnis ist.

Es scheint mir jedoch, als gäbe es keine Möglichkeit, diese Anforderung "agil" anzugehen. Flexible Anforderungen bedeuten, dass nicht nur Schätzungen der benötigten Zeit falsch sind, sondern auch Schätzungen der potenziellen Zeitersparnis. Ich erklärte es, erklärte, warum es wahrscheinlich problematisch sei, sagte aber, es sei nicht verhandelbar.

Die Frage, wie man Agile-Entwicklung an (Wasserfall-) Kunden verkauft, enthält einige nützliche Ratschläge, wie man Agile an externe Kunden "verkauft". Ich versuche nicht, es an externe Kunden zu verkaufen: Ich versuche herauszufinden, wie ich die Anforderungen des internen Managements am besten vereinbaren kann, während ich an einer Methodik festhalte, die meiner Meinung nach gut funktioniert.

Gibt es eine Möglichkeit, diese Aufgabe auf flexible Weise anzugehen, sodass ich zumindest einige Vorteile von Agile behalten kann?

Wie in anderen Antworten angegeben, hat das Management das Recht, vor einem Projekt eine hochrangige Schätzung zu erhalten. Sie sind nicht unangemessen, um den ROI zu ermitteln.

Einer der Ansätze, die ich an Agile mag, ist jedoch, dass der Umfang eines Projekts nicht festgelegt ist. Die Größe kann zunächst auf Feature- und Epic-Ebene festgelegt werden. Anschließend kann das Unternehmen den ROI anhand der wichtigsten Features ermitteln. Vielleicht hat die schicke Benutzeroberfläche mit Schnickschnack einen geringen Geschäftswert, aber die Workflow-Engine für die Bearbeitung von Ansprüchen hat einen hohen ROI.

Wenn Sie das gesamte Projekt zusammenfassen, ist es schwieriger, den ROI zu erreichen, als wenn Sie sich auf die gewünschten geschäftskritischen Funktionen konzentrieren.

Folgendes habe ich getan:

Nehmen Sie Ihre PSP-Meilensteine ​​und verwandeln Sie diese in eine lieferbare Funktion

Auf diese Weise können Sie Ihr Projekt in Mini-Teilprojekte mit unterschiedlichem Geschäftswert einteilen. Jeder von ihnen sollte für sich allein stehen, was den geschäftlichen Wert anbelangt.

T-Shirt Größe die Bemühung auf Eigenschaften

Dies ist ein sehr einfacher Weg, um eine ungefähre Vorstellung davon zu bekommen, wie groß oder involviert ein bestimmtes Feature sein könnte. Möglicherweise haben Features mit niedrigem Wert immer noch einen großen ROI, wenn sie wie einfache Gewinne aussehen.

Teilen Sie ein Feature in Geschichten auf

Gehen Sie die Übung durch, um eine kleine Funktion zu finden, die gut verstanden wird, und teilen Sie sie zunächst in Geschichten auf. Schätzen Sie diese Geschichten nach Punkten. Jetzt hast du eine Basis wo

Klein -> 40 Punkte

Dies ist eine Grundlage für den Vergleich mit anderen Funktionen

Ordnen Sie allen Features Story-Punkte zu

Vergleichen Sie Ihr kleines Feature mit anderen Features. Beispielsweise,

Mittleres Feature Y fühlt sich doppelt so groß und anstrengend an wie Small Feature X mit 40 Story-Punkten.

Mittleres Feature Y besteht wahrscheinlich aus 80 Story-Punkten. Fahren Sie fort, bis Sie für alle Funktionen Story-Punkte erhalten, die auf einem hohen Niveau geschätzt werden.

Schätzen Sie die Geschwindigkeit Ihres Teams

Bestimmen Sie anhand Ihres Entwicklungsteams, wie viele Story Points dieses Team in einem bestimmten Sprint effektiv liefern kann. Wenn Sie mit diesem Team bereits Agile-Projekte durchgeführt haben, ist dies ein guter Anfang. Wenn Sie keine solche Vorgeschichte hinter dem Team haben, führen Sie mit Ihrem Team eine nachgebildete Sprintplanung durch, in der Sie sich mit Ihrem kleinen Feature befassen, das Sie detailliert beschrieben haben. Welche stündlichen Schätzungen geben die Leute für ihre Aufgaben in diesen Geschichten an?

Verwenden Sie die Gesamtzahl der Story Points als die durchschnittliche potenzielle Geschwindigkeit Ihres Teams, basierend darauf, wie viel Arbeit das Team in 2 Wochen leisten kann!

Finden Sie Ihr voraussichtliches Abschlussdatum

Wenn sich Ihr Team in der Schein-Sprint-Planung sicher fühlt, 25 Story Points in einem Sprint zu liefern, und Ihr gesamter Rückstand 300 Story Points für die goldene Cadillac-Version Ihres Projekts entspricht, dann würde Ihr Team idealerweise 12 Sprints oder 24 Wochen brauchen alles vervollständigen.

Jetzt ist es ganz einfach, die Ressourcenkosten Ihres Teams in Dollar pro Woche umzurechnen, um die Kosten für den ROI im Vergleich zum Geschäftswert zu ermitteln. Die Verhandlungen über die wichtigsten Funktionen können fortgesetzt werden, und dann wird Ihr Projektmanagement im Grunde genommen zu einem Knapsack-Problem.

Dies ist kein Problem mit "Management". Es ist eine unabdingbare Voraussetzung, vor dem Start die Kosten und den Nutzen eines potenziellen Projekts abschätzen zu können. Wie könnte sonst jemand wissen, was es wert ist, getan (oder versucht) zu werden?

Warum dann Agile?

Ich würde argumentieren, dass agile Methoden keine Unsicherheit bedeuten. Vielmehr ist Agile ein Argument dafür, dass Ungewissheit unvermeidlich ist, und die detaillierten Spezifikationen und Schätzungen traditioneller Methoden führen zu falscher Gewissheit - was sehr kostspielig sein kann.

Einige wichtige Punkte in Bezug auf die Zeitschätzung:

• Änderungen der Anforderungen während eines Projekts sind unvermeidlich. Agile berücksichtigt dies, anstatt so zu tun, als würde sich nichts ändern.
• Detaillierte Spezifikationen enthalten häufig Konstruktionsmängel, die erst in der Projektphase aufgedeckt werden. Dies kann größere Änderungen in einem traditionellen Projekt bedeuten als in einem agilen.
• Eine Zeitschätzung basierend auf "Wie groß ist das ganze Projekt?" ist wahrscheinlich genauso genau wie die Aufsummierung der geschätzten Zeit für viele detaillierte Anforderungen.
• Das Wichtigste, was zu guten Schätzungen führt, ist ein Zyklus aus Schätzungen, Messungen und Überprüfungen, der auf jeden konsistenten Prozess angewendet werden kann.
• Die Schätzung "Arbeit gespart" wird eher von den Hauptanforderungen für das Projekt als von den Details abhängen, daher bezweifle ich, dass Agile der Fähigkeit, dies abzuschätzen, großen Schaden zufügen würde.

Aktualisieren:

Um es zu verdeutlichen: Ihre Antwort an Ihre Vorgesetzten scheint zu lauten: "Wir können die Zeitersparnis oder den gesamten Entwicklungsaufwand mit Agile nicht sehr gut einschätzen, da es flexibel ist." Ich denke, das ist falsch. Ich glaube, dass diese Schätzungen bei Verwendung eines agilen Prozesses genauso gut gemacht werden können, da die Unsicherheit ohnehin vorhanden ist. Und natürlich ermöglicht Agile einen flexibleren und reaktionsschnelleren Prozess im Verlauf des Projekts.

Dies ist sicherlich einer der schwierigsten Aspekte bei der Einführung von Agile

"Management braucht noch Zeitschätzungen"

Mein Ansatz ist:

• Pad 300%. Das alte Sprichwort von 300% ist nützlich, wenn Sie sich in einer Situation befinden, in der es nicht möglich ist, auf Managementebene wirklich agil zu sein. Dies ist vielleicht kein "agiler Ansatz", sondern ein Kompromiss für diese Situation. Sie können ein paar Mal vorbeikommen - aber rechnen Sie nicht damit!

• Bitten Sie um eine Überprüfung, die auf der Arbeit basiert, die auf der Hälfte des Projekts geleistet wurde. Projektieren Sie, wann Sie fertig wären, basierend auf der geleisteten Arbeit. Sprechen Sie dann mit dem Management und überlegen Sie, was Sie opfern müssen - Funktionalität oder Qualität - angesichts der Zeit, die aufgrund von Vermutungen zu Beginn des Projekts festgelegt wurde.

• Stellen Sie sicher, dass Sie mit dem Management an den ausgeführten Funktionen und der Qualität zusammenarbeiten, damit diese tatsächlich diese Entscheidungen treffen

• Nehmen Sie den Ablauf für dieses Projekt und lassen Sie das Übliche zu - versäumte Fristen, beeinträchtigte Qualität, ausgebrannte und gestresste (und möglicherweise verstorbene) Mitarbeiter, die das Projekt verlassen. Wenn das nächste Projekt der Phase ansteht, besprechen Sie diese "Nebenwirkungen".

• Konzentrieren und demonstrieren Sie die Vorteile eines "echten" agilen Ansatzes. Sprechen Sie über die Verbesserung der Qualität. Sprechen Sie über die Möglichkeit, spät am Tag Änderungen vorzunehmen, bis diese in Produktion gehen. Über weniger Nacharbeit gesprochen. Sprechen Sie über eine geringere technische Verschuldung, die die Entwicklung letztendlich zum Stillstand bringen wird. Machen Sie Analogien zur realen Welt, zum Beispiel können wir einen Ölwechsel an jedem Tag aufschieben, aber lange genug aufschieben, und der Motor leidet, arbeitet schlecht und bläst schließlich eine Stange.

• Halten Sie Ihren Lebenslauf und das verknüpfte Profil auf dem neuesten Stand. Wenn Sie nach einigen Fällen keine Unterstützung durch das Management erhalten, fahren Sie fort. Einige Organisationen werden nicht in Ihren Argumenten aufgeführt, wechseln Sie also zu solchen, die dies tun. Nannte es Darwinismus Beschäftigung;)

Ich denke, Sie machen falsche Annahmen über die agile Entwicklung. Flexibilität und sich ändernde Anforderungen sind buchstäblich in das Agile Manifest integriert .

Begrüßen Sie sich ändernde Anforderungen, auch spät in der Entwicklung. Agile Prozesse nutzen den Wandel zum Wettbewerbsvorteil des Kunden.

Flexible (sprich: sich ändernde) Anforderungen sind in Agile willkommen. Zugegeben, wenn Sie die meisten Entwickler fragen, werden sie eine Einschränkung hinzufügen, dass die Änderung angemessen sein muss. Ein Team zu bitten, ein 3D-Spiel zu erstellen und dann die Anforderungen an ein "Kontrollsystem für einen Kernreaktor" zu ändern, ist ein bisschen viel. Das Hinzufügen, Entfernen oder Ändern von Anforderungen im Rahmen des Projekts ist jedoch völlig in Ordnung.

Die Frage ist, wie Sie mit sich ändernden Anforderungen umgehen? Die typische Antwort ist, kurze Iterationen zu verwenden, damit Sie Kursanpassungen frühzeitig vornehmen können, bevor Sie zu viel Zeit verschwenden. Es zwingt das Team außerdem, Anforderungen in kleinere Teile zu zerlegen, damit jeder sie besser verstehen und in angemessenem Zeit- und Arbeitsaufwand umsetzen kann.

Einfachheit - die Kunst, den Umfang der nicht geleisteten Arbeit zu maximieren - ist von entscheidender Bedeutung.

Mir gefällt auch dieses Agile-Prinzip. Normalerweise bedeutet dies, dass ein Team sich bemühen sollte, nur die Dinge zu liefern, die durch rücksichtslose Effizienz notwendig sind. Zum Beispiel: Wenn der Kunde denkt , dass er etwas braucht, es aber faul zu sein scheint, suchen Sie nach Informationen. Vielleicht haben die Endbenutzer wirklich keine Verwendung dafür, so dass die Arbeit nicht erledigt werden sollte.

Ich denke jedoch, dass Ihre Frage einen anderen Aspekt dieses Prinzips berührt. Software dient im Allgemeinen dazu, einen manuellen Prozess zu automatisieren. Die Software selbst ist vorhanden, um den Arbeitsaufwand für die Endbenutzer zu maximieren.

Das Messen des Arbeitsaufwands, den Software den Endbenutzern erspart, ist auf jeden Fall eine angemessene Messgröße. Ich habe das in meiner Karriere selbst gemessen. Tatsächlich ist es eine entscheidende Komponente einer Kosten-Nutzen-Analyse: Wie viel Aufwand wird das Softwareprojekt für die Implementierung aufwenden, verglichen mit dem Aufwand, den das Endprodukt den Endbenutzern erspart.

Dies ist absolut kompatibel mit der Agile-Entwicklungsphilosophie (oder jeder anderen) und Ihr Management sollte dies unbedingt akzeptieren.

Ja, Beweglichkeit hat einige Vorteile.

• Es ermöglicht Geschäftsleuten, ihre Meinung während des Fluges zu ändern.
• Es schützt das Unternehmen in gewisser Weise vor den ständig schlechten Schätzungen des Ingenieurs.
• Es liefert früh und häufig einen Wert, bevor die endgültige Vision erreicht ist.
• Dies erspart Ihnen einen Teil der Planungskosten, die oft ohnehin zu einem schlechten Plan führen .
• Es ist super cool. Recht?

Sie müssen jedoch noch einigermaßen genaue Vorausschätzungen abgeben.

Wenn Sie dies nicht tun, fordern Sie das Unternehmen effektiv auf, in Ihr Produkt zu investieren, ohne den Nachweis zu erbringen, dass Ihr Produkt die ursprüngliche Investition überhaupt wert ist .

Und ich kann es jetzt hören.

Ich habe es schon mal gehört. Ich bin mir ziemlich sicher, dass ich es schon einmal gesagt habe:

Oh - aber Haow !? HAOW blickt ein bloßer Sterblicher wie ich in das Schicksal solcher Dinge! Dinge, die nur die Götter selbst erahnen und lenken können. Dinge, die sterbliche Menschen nur im tiefsten Schlummer träumen und bei Tagesanbruch vergessen können! Oh tyrannische Führungstypen, HAOW können solche Ansprüche erfüllt werden !?

Verwenden Sie Ihre bisherigen Leistungen als Richtschnur und seien Sie ehrlich .

• Haben Sie genug Gespräch mit dem Stakeholder und / oder Endbenutzer, um festzustellen, wie komplex das Produkt und / oder seine Hauptkomponenten im Verhältnis zu anderen Hauptkomponenten sind, an denen Sie gearbeitet haben. Machen Sie eine erste relative Punktschätzung.
• Erhöhen Sie diese Zahl um das historische Ausmaß der Bereichsänderungen und der Fehlerfälle, die Sie in der Vergangenheit gesehen haben.
• Wenden Sie Ihre historische Geschwindigkeit auf die Punktschätzung an, um eine ungefähre Zeitachse zu erhalten. Wenden Sie einen vernünftigen Unsicherheitskegel an .
• Überprüfen Sie Ihre Einschätzung und Ihr Verständnis des Projekts erneut. Seien Sie zuversichtlich, dass Sie bereit sind, auf der Grundlage Ihrer Einschätzung eine Entscheidung über die Bewältigung eines Projekts zu treffen.

Zeigen Sie den Stakeholdern abschließend Ihren Unsicherheitskegel, geben Sie Ihre Vermutungen und Bedenken an und belassen Sie ihn dabei.

Abgesehen davon würde ich auch vorschlagen, eine objektive heuristische Punktschätzung zu erstellen, um Sie und / oder die normalen Schätzungen Ihres Teams auf ihre Richtigkeit zu überprüfen.

Sie können diesen Schätzwert als N-te Stimme bei der Planung des Pokers oder zur Bestätigung Ihres privaten Schätzwerts verwenden, wenn Sie alleine unterwegs sind. Zum Beispiel mein Team neigt etwa 1 Punkt pro Minute zu schätzen lose technische Diskussion über eine Geschichte zu entdecken. Dies ist besonders dann hilfreich, wenn Ihr Bauch sagt, dass eine Geschichte 5 Punkte hat, Sie aber 20 Minuten gebraucht haben, um zu verstehen, was zu tun ist. Dies ist normalerweise ein guter Indikator dafür, dass immer noch Komplexität und Missverständnisse auftauchen.

Ich habe noch nie in einem Unternehmen gearbeitet, das konstant gute Zeitschätzungen vorweisen konnte, und ich habe auch noch nie mit jemandem zusammengearbeitet, der behauptet, dies getan zu haben. Die Suche zeigt Ihnen, dass die Schätzung ein ungelöstes Problem in der Branche ist.

Ich würde versuchen, mich für die Messung der Geschwindigkeit anhand abstrakter Story-Punkte zu beteiligen, und wenn Sie das nicht können, würde ich Ihre Schätzungen mehr auffüllen.

Agile ist eine großartige Lösung für eine ganze Reihe von Problemen, aber trotz der Vorschläge einiger Evangelikalen ist es nicht die einzige und nicht immer die richtige Lösung.

Ihr angegebener Fall ist einfach kein agiles Problem:

Vor kurzem wurde ich beauftragt, Teams aufzusuchen und sie nach Ideen für die Automatisierung von Geschäftsprozessen zu fragen. Ich musste dann herausfinden, wie viel Zeit sie dafür benötigten, herausfinden, wie viel Zeit die Lösung einsparen würde, und die gesamte Entwicklungszeit abschätzen. Auf diese Weise könnten Manager versuchen zu messen, wie effektiv eine Lösung in Bezug auf die Zeitersparnis ist.

Sie müssen die Kosten und den Nutzen der Automatisierung einiger Geschäftsprozesse ermitteln. Dies ist keine flexible Aufgabe, die sich ändern kann, sondern ein spezifisches Problem mit einer spezifischen Lösung. Sie erstellen eine Liste mit einer beliebigen Anzahl von Geschäftsprozessen, und für jeden werden die Kosten für die Automatisierung, die Kosten für die Nichtautomatisierung und der geschätzte Nutzen der Automatisierung veranschlagt. Das Management vergleicht dies mit seinen Budgets, Ressourcen, Anforderungen und strategischen Zielen und bestimmt, welche dieser Prozesse (falls vorhanden) zu automatisieren sind. Wenn Sie gewissenhaft sind, haben Sie ausgewählte Aufgaben hervorgehoben, die potenziell einen niedrigeren ROI aufweisen, jedoch die Kosten für andere Phasen senken und so den Gesamt-ROI verbessern. Möglicherweise haben Sie auch verschiedene Wege zur Erreichung der Automatisierung identifiziert, einschließlich interner und ausgelagerter maßgeschneiderter Entwicklung (mithilfe von agilen und / oder Wasserfalltechniken), Kauf von Standardlösungen, mithilfe von Drittanbietern und so weiter. Dieser gesamte Prozess war in den 90er Jahren als Business Process Re-Engineering bekannt.