Was ist die Definition von „Projekt“ in agilen Einstellungen?

Die Definition eines Projekts in agilen Begriffen unterscheidet sich nicht von der eines Projekts in traditionellen Begriffen. Der Unterschied besteht darin, wie das Projekt ausgeführt und ausgeführt wird und welche Werte hinter dem Projekt stehen.

Gemeinsam

Sowohl agile Projekte als auch traditionelle Projekte:

• einen Anfang und ein Ende haben
• kann durch Zeitplan, Umfang oder Budget eingeschränkt sein
• sollte für ein einzelnes Produkt gelten; (Lasst uns nicht über Symantik diskutieren)
• intern erstellt oder von externen Anbietern ausgeführt werden
• Teil eines größeren Programms oder Portfolios von Arbeiten sein
• ein Produkt liefern
• beschäftigen sich mit Risikomanagement und Risikominderung
• Wenn Sie sich PRINCE2 und PMBoK ansehen, fördern beide iterative Ansätze in Form von Stufen oder Phasen. Die meisten agilen Frameworks tun dies.

Unterschiede

Agile erkennt an, dass wir mit komplexen Technologien und Anforderungen in einer Welt voller Unsicherheiten und Mehrdeutigkeiten umgehen. Dabei ist der Ansatz eher eine empirische Prozesssteuerung als eine definierte Prozesssteuerung. Es ermöglicht dem Team, sich an Herausforderungen anzupassen.

Die Arbeit wird in sehr kurzen Iterationen durchgeführt, die 30 Tage nicht überschreiten, um das Risiko dieser Komplexitäten und Unsicherheiten zu mindern. Herkömmliche Projekte können jahrelang ohne Phasen laufen, oder Phasen können mehrere Monate dauern. Agile Praktiker meinen, dass dies viel zu lang ist und viel zu viele Risiken damit verbunden sind.

Die meisten Agile-Praktiken folgen Lean-Prinzipien, um Verschwendung zu vermeiden und nur das zu erstellen, was benötigt wird. Agile Praktiker erkennen, dass Vorabanforderungen normalerweise zu großen Mengen an Verschwendung führen; zB 64 % der Funktionen werden selten oder nie verwendet – Standish Group Research.

Die meisten Menschen werden nicht agil, da es schwierig ist. Der Grund dafür ist, dass wir alle dazu erzogen wurden, mit definierten Prozessen zu arbeiten und diese Prozesse zu kontrollieren. Diese Denkweise zu durchbrechen, um komplexe Projekte mit empirischer Prozesskontrolle zu bewältigen und zu managen, erfordert viel Energie und Engagement. Es hat sich als sehr zuverlässiger Weg erwiesen, mit Softwareprojekten umzugehen, erfordert jedoch eine Änderung.

Ich habe einige Podcasts zu Projektmanagement und Scrum erstellt, die diese Unterschiede im Detail hervorheben. Vielleicht möchten Sie Google verwenden, um diese zu finden.

Unabhängig vom zu liefernden Mechanismus (gemäß der Antwort von @Brett) schlage ich vor, dass die Definition eines Projekts so einfach ist wie "ein Projekt ist eine Aktivität, die der Organisation einen messbaren Wert liefert, indem sie entweder den Umsatz steigert, die Kosten senkt oder die Effizienz verbessert".

Jedes Projekt, das Sie liefern, sollte leicht quantifizierbar sein, warum Sie es tun.

Wie sich agile Projekte von Wasserfallprojekten unterscheiden

Um näher darauf einzugehen, was @Brett Maytom PST auf der Seite der Unterschiede gesagt hat:

1. Minimieren Sie das Projektrisiko : Wenn Sie Funktionen haben, die ein hohes Risiko darstellen (ein einzigartiges Wertversprechen, das noch nie zuvor erstellt wurde), können Sie diese frühzeitig planen, um zu validieren, ob es überhaupt machbar ist. Wenn Sie feststellen, dass der Bau entweder nicht möglich oder zu kostspielig ist, können Sie die Realisierbarkeit des Projekts überdenken.

2. Schnelles Feedback : Agile Projekte produzieren am Ende jedes Sprints „auslieferbare Funktionsinkremente“. Sie können dies also bereitstellen und Geschäftsanwender dazu bringen, damit zu spielen, Usability-Tests durchzuführen und Beta-Kunden anzumelden, um frühzeitig Feedback zu erhalten. Dies gibt Ihnen die Möglichkeit, die Richtung zu ändern oder das Projekt sogar abzubrechen, bevor Sie den gesamten budgetierten Betrag in das Projekt stecken. Bei Wasserfallprojekten erhalten Sie ein lieferfähiges Produkt erst am Ende des eigentlichen Projektabschlusses – der selbst über dem Budget und hinter dem Zeitplan liegen kann.

3. Wertverhandlung : Wenn wir eine Schätzungssitzung durchführen, ist unser Product Owner zu oft überrascht. Einige Dinge, die der PO für schwierig hielt, entpuppen sich als einfache Einstellung in der Bibliothek, für die sich die Entwickler entschieden haben. Während andere, die einfach genug aussehen, eine umfangreiche benutzerdefinierte Codierung erfordern. Wenn man sich die Schätzung ansieht, kann unsere Bestellung einige Funktionen fallen lassen und andere niedriger priorisieren. Bei Wasserfallprojekten sind die Anforderungen, sobald sie geschrieben sind, in Stein gemeißelt (vorbehaltlich der Änderungskontrolle, was schmerzhaft ist).

Im Projektmanagement liefern Sie ein Projekt, während Sie in Agile ein Epic liefern. Projekte haben ein definiertes Start- und Enddatum, während Epics Produkte mit definierten Akzeptanz- oder Erledigungskriterien anstelle eines Datums haben.

IMO sollte der Begriff Projekt nicht in Agile verwendet werden. Sie sollten die Teams darauf abstimmen, ähnliche Begriffe und Rollen zu verwenden, damit allgemeine Verfahren und Praktiken von allen verstanden und vereinbart werden können. Wenn Sie jedoch nach dem äquivalenten Begriff zu Project in Agile suchen, wäre dies Portfolio Epic oder Epic.

Ich würde empfehlen, sich mit Safe for Lean Enterprises zu befassen, um ein umfassendes Verständnis dafür zu erhalten, wie mehrere Teams und Produkte unter einem gemeinsamen Portfolio Epic ausgerichtet werden können, das auf das Unternehmen ausgerichtet ist.

Ein weiterer zu berücksichtigender Punkt ist die Perspektive eines Projekts oder Epos in Agile. Es sollte bekannt sein, dass Teams nicht an Epics oder Projekten arbeiten, sie arbeiten an Produkten, die eine Funktion oder ein Element sein könnten. Direktoren (Produktmanager) und Führungskräfte arbeiten auf Epic- oder Projektebene. Wenn sie nach dem Status eines Epic suchen, möchten sie wissen, wie viele Funktionen für ein bestimmtes Produkt vollständig sind. Das eigentliche Product Delivery Team hat möglicherweise keinen Überblick über das gesamte Epic, sondern nur über die Produkte und Funktionen, die es liefert.