Scope Creep in Agile managen

TL;DR

Scope Creep ist ein Projektrisiko und muss kontrolliert werden. In agilen Frameworks ist der Umfang jedoch eher eine variable als eine feste Einschränkung. Um ein effektiver Agilist zu sein, muss man die Unterschiede zwischen Umfang und Änderungskontrolle verstehen und wissen, wie man ein gegebenes agiles Framework richtig anwendet, um Änderungen (was ein zentraler Wert ist) anzunehmen, ohne das Gesamtprojekt zu gefährden.

Dies beinhaltet im Allgemeinen Kooperationsvereinbarungen, iterationsbasierte Änderungskontrolle, Transparenz und effektive Kommunikation mit den Interessengruppen. Agile Praktiken wollen keine Umfangsänderungen im Maisfeld; Stattdessen passen sie andere Einschränkungen an, um die Kosten der Änderung sichtbar zu machen, damit das Unternehmen fundierte strategische Entscheidungen treffen kann.

Umfang verwalten

[I]Wenn Sie verhindern, dass es im Projekt zu einem Scope Creep kommt, wie können Sie dann sagen, dass das Projekt agil ist?

In einem agilen Framework ist Scope Creep wirklich ein Problem, das dadurch verursacht wird, dass neue oder ungeplante Arbeit in die Mitte einer Iteration eingefügt wird, anstatt dem Gesamtprojekt Scope hinzuzufügen. Alle agilen Frameworks lösen dies durch formelle Prozesse und Zeremonien. Bei Scrum zum Beispiel:

1. Neue Arbeiten sollten generell nur während des Sprint Plannings eingeführt werden.
2. Neue Arbeit, die Vorrang vor der aktuellen Arbeit hat, erforderte eine vorzeitige Beendigung des aktuellen Sprints und eine Rückkehr zur Sprint-Planung.
3. Neue Arbeiten für das Projekt müssen vom Product Owner in Zusammenarbeit mit den Stakeholdern priorisiert werden, sodass der Bereichszuwachs auf Projektebene durch Konsens darüber gesteuert wird, dass die vorgeschlagene Arbeit für die Projektziele relevant ist.
4. In Scrum sind Iterationen ein festes Zeitfenster mit relativ festen Kosten (ohne Kapitalkosten), aber der Umfang ist eine variable Einschränkung.
5. „Scope Creep“ im traditionellen Geschäftssinn verlängert die Gesamtlaufzeit des Projekts. Indem Sie dem Projekt einen Umfang hinzufügen, wirken Sie sich auf den Zeitplan aus (im Allgemeinen verlängern Sie ihn). Dies gelingt Ihnen durch Transparenz und effektive Kommunikation mit Stakeholdern.

Kanban und Lean haben ähnliche Mechanismen zur Bewältigung von Veränderungen. Der Punkt ist, dass es kein kostenloses Mittagessen gibt. Das Hinzufügen von Umfang fügt dem Projekt Kosten oder Zeit hinzu.

Kompromisse

Unter dem Projektmanagement-Dreieck versteht man allgemein ein Set von Schiebereglern aus Umfang, Zeitplan und Kosten. (NB: Es gibt andere Modelle, aber dieses ist das gebräuchlichste.)

Der Punkt dieser Metapher ist, dass Sie die Qualität verwalten, indem Sie die Schieberegler anpassen, aber sie sind voneinander abhängig. Sie können Kosten, Zeitplan und Umfang nicht gleichzeitig festlegen, sodass ein erhöhter Umfang im Allgemeinen auch die Kosten und den Zeitplan eines Projekts erhöht, während häufig die Gesamtqualität verringert wird, da die Organisation versucht, den Umfang zu erhöhen, ohne die Kosten zu erhöhen oder den Zeitplan zu verlängern.

Als Projektmanager müssen Sie in der Lage sein, die Kompromisse für das Projekt zu artikulieren. In Ihrem speziellen Fall müssen Sie ein tieferes Verständnis dafür haben, wie diese Kompromisse in einem agilen Kontext getroffen werden und welche Tools Ihr Framework für die Verwaltung und Kommunikation dieser Kompromisse bereitstellt.

Normalerweise antworte ich, indem ich sage, dass die Anforderungen klar definiert werden müssen, bevor das Projekt beginnt, und wenn es während des Projekts zu Änderungen kommt, muss es einen Änderungskontrollprozess durchlaufen, an dem das Änderungskontrollgremium usw. beteiligt ist

Ihre Gesprächspartner haben Recht – das ist nicht agil.

Der Sinn von Agile ist, dass sich Anforderungen ändern. Ihr Verständnis des Problems ändert sich. Ihr Marktverständnis ändert sich. Das Ding, von dem Sie dachten, dass Sie es im Januar bauen müssten, ist nicht das Ding, von dem Sie wissen, dass Sie es im Juni bauen müssen.

Wenn Sie darauf bestehen, Ihre Anforderungen im Voraus zu definieren, wird eines von zwei Dingen passieren:

1. Sie werden nach Spezifikation bauen und feststellen, dass Sie das Falsche gebaut haben
2. Sie ignorieren die Anforderungen und machen den Prozess der Anforderungsdefinition zu verschwendeter Mühe und die Anforderungen selbst zu einem toten Dokument

(Es gibt bestimmte Ausnahmen , die außergewöhnlich gut verstandene technische Probleme, außergewöhnliche Einschränkungen und außergewöhnliche Budgets beinhalten. Wenn sie Ihnen diese Fragen stellen, sind Sie mit ziemlicher Sicherheit nicht an einem dieser Projekte beteiligt.)

Jetzt: Scope Creep. In einem reibungslosen agilen Prozess gibt es in erster Näherung kein Scope Creep. Es gibt neue Spielräume – neue Prioritäten und neue Anforderungen, die zu neuen Aufgaben führen – aber es gibt kein Kriechen .

Das erste Problem mit Scope Creep in einem traditionellen Prozess ist, wenn die Organisation sich selbst belügt. Sie haben versprochen, die Merkmale F bis zum Zeitpunkt T in einer bestimmten Qualitätsstufe Q zu liefern . ( Q wurde wahrscheinlich nie explizit gemacht, und Sie wollten wahrscheinlich sowieso nie T machen, aber egal.) Aber jetzt haben Sie F stillschweigend neu definiert , um F+1 , F+2 , bis hin zu who zu bedeuten weiß, 2F , 3F Mühe wert, ohne jemals explizit Kompromisse zu T oder Q einzugehen . Also wird T ausrutschen, undQ wird ausrutschen, aber niemand gibt zu, dass niemand außerhalb der Entwicklungsorganisation überhaupt weiß, dass es passiert, also irgendwann nach der Crunch Time, wenn Sie es sich endlich eingestehen und Ihren Stakeholdern endlich die schlechten Nachrichten überbringen, werden sie (zu Recht ) schlagen ihre Deckel auf.

Dies ist das Problem, das Ihr Change Control Board usw. verhindern soll – dieser Kreislauf von Verleugnung und Ausrasten.

Aber selbst mit einem Änderungskontrollprozess, der die Organisation ehrlich hält, haben Sie ein anderes Problem. Sie haben sich vorgenommen, F by T zu liefern , und jetzt haben Sie den Umfang erweitert und den Zeitplan verschoben, und Sie sind auf dem besten Weg, 3F by 3T zu liefern . Aus Sicht des Entwicklungsteams ist alles in Ordnung.

Die größere Organisation steckt jedoch in großen Schwierigkeiten, weil Sie keine Software ausgeliefert haben. Sie verlieren Umsatz (oder Mindshare bei einem Open-Source-Projekt) an Ihre agileren Konkurrenten, selbst wenn sie nur Funktionen im Wert von F/2 ausgeliefert haben. Sie verpassen die Gelegenheit, Feedback von Benutzern zu erhalten, sodass Ihre Annahmen darüber, welche Funktionen Ihre Benutzer wünschen, nicht der Realität entsprechen, und wenn Sie schließlich 3F ausliefern , werden Sie wahrscheinlich herausfinden, dass es nicht was ist Sie wollen; Sie haben 1F–2F an Mühe verschwendet und haben weitere 2F–3F vor sich, nur um aufzuholen.

Aus diesem Grund sagt das Agile Manifest , dass funktionierende Software das wichtigste Maß für Fortschritt ist. Im Grunde ist agile Entwicklung ziemlich einfach:

• Du baust ein kleines Ding
• du versendest es
• Sie bauen das nächste kleine Ding

Bei den Details geht es darum, herauszufinden, was das nächste kleine Ding sein sollte, und sicherzustellen, dass es auf einem akzeptablen Qualitätsniveau gebaut wird.

Wo Agile scheitert, geschieht dies oft in Form von Scope Creep. Dieses kleine Ding wird größer, und die Zeit, die es braucht, um es zu versenden, wird länger, und dann wird es noch größer, und als Nächstes wissen Sie, dass Sie seit drei Monaten nichts mehr versendet haben und selbst wenn Sie immer noch tägliche Standups haben ( oder Scrums) und die Aufteilung der Arbeit in Iterationen (oder Sprints) können Sie sich nicht mehr ehrlich als agil bezeichnen.

Verschiedene agile Praktiken wehren sich auf unterschiedliche Weise gegen dieses Problem.

Test-First-Design, testgetriebene Entwicklung, kontinuierliche Integration und kontinuierliche Bereitstellung stellen bei richtiger Anwendung sicher, dass die Software immer versandbereit ist.

Planungspoker auf hoher Ebene und Aufgabenschätzung auf niedriger Ebene ermutigen Entwickler, Features zu durchdenken und sicherzustellen, dass sie und der Product Owner ein gemeinsames Verständnis haben, bevor sie mit der Entwicklung beginnen.

Die iterative Entwicklung (wobei neue Aufgaben nur an Iterationsgrenzen in den Arbeitsstrom aufgenommen werden können) begrenzt die Änderungsrate des Umfangs, gibt den Produktbesitzern einen Anreiz, Features zu durchdenken, bevor sie die Entwickler bitten, sie zu liefern, und minimiert den Entwickler-Thrash – den kognitiven Peitschenhieb und den Overhead für Kontextwechsel aus Ihrem Flow herausgezogen zu werden, um eine Aufgabe fallen zu lassen und eine andere zu beginnen. Geschwindigkeitsverfolgung und evidenzbasierte Planung halten Ihre Iterationen realistisch.

Lean-/Kanban-artige Prozesse machen Iterationen überflüssig, sondern „ziehen“ Features nur dann aus dem Backlog, wenn die Entwickler bereit sind, daran zu arbeiten – das heißt, nachdem ihr vorheriges Feature in die Qualitätssicherung übergegangen und/oder ausgeliefert wurde.

Der wahre Weg, Ihren Interviewern zu antworten, besteht darin, die Frage auf sie umzudrehen. Worüber machen sie sich wirklich Sorgen, wenn sie „Scope Creep“ sagen? Sind sie besorgt, dass das Produkt nicht rechtzeitig versendet wird? Haben sie Angst, dass die Qualität darunter leidet? Sind sie besorgt über Burnout der Entwickler? Sind sie besorgt über all das oben Genannte und darüber, dass sie es nicht herausfinden werden, bis es zu spät ist? Dies sind verwandte, aber unterschiedliche Anliegen, und ein guter Prozess wird sie alle auf verwandte, aber getrennte Weise angehen.

In der Lean-Welt sagt man, wenn man die Ursache eines Problems finden will, sollte man immer fünfmal nach dem „Warum“ fragen . Fragen Sie Ihre Interviewer, warum sie sich für Scope Creep interessieren, und Sie werden Ihre Antwort finden.

tldr; Agile verschiebt den Fokus auf das Entdecken und Erstellen einer Lösung für die Bedürfnisse des Kunden. Agile Werte „Auf Veränderungen reagieren statt einem Plan zu folgen“, weil man „sich ändernde Anforderungen willkommen heißen muss“, um „Veränderungen zum Wettbewerbsvorteil des Kunden zu nutzen“

Es kann hilfreich sein, mit einem Verständnis des klassischen Modells des Eisernen Dreiecks, auch bekannt als Projektmanagement-Dreieck, zu beginnen. Die Grundlage ist, dass es drei zu kontrollierende Attribute gibt (Umfang, Kosten und Zeit), die sich alle auf die Qualität auswirken.

Schauen wir uns zunächst das klassische Projektmanagement an. Am Anfang steht der Umfang fest, dann hofft der PM, Kosten und Zeit richtig einschätzen zu können. Sind alle Anforderungen geschrieben, kann die Arbeit beginnen. Wenn Änderungen und Probleme auftreten, muss etwas angepasst werden. Eine gängige Lösung besteht darin, mehr Personen hinzuzufügen, siehe The Mythical Man-Month , was die Kosten erhöht. Sobald ein Projekt beginnt, werden realistischerweise auch die anderen beiden Aspekte (Kosten und Zeit) festgelegt; jede Erhöhung auf eines der beiden gilt als Fehlschlag. Das primäre Ergebnis ist ein Mangel an Qualität, oft auch über dem Budget und verspätete, manchmal nicht erfüllte Vereinbarungen, sehr häufig nicht die Erfüllung der Kundenanforderungen oder das Verpassen der Marktchance.

Schauen wir uns nun die agile Philosophie an. Anstatt zu Beginn einen vollständigen Satz von Spezifikationen (Umfang) zu erstellen und dann zu versuchen, Kosten und Zeit vorherzusagen, wird der Kernbedarf identifiziert. Ein Rückstand wird erstellt, um die Wünsche darzustellen: Wünsche, die tatsächliche Anforderungen sein können oder nicht. Diese Liste wird dann nach Wert für den Kunden geordnet. Die Entwicklung beginnt mit den Kernstücken mit dem höchsten Wert. Dabei ist zu beachten, dass sich der Fokus bereits auf eine Lösungs- (bzw. Produkt-) Denkweise und Herangehensweise gegenüber der klassischen Projektmentalität verlagert hat. Das Team arbeitet in kleinen Zeitfenstern, festen Kosten und Zeit, um die Lösung in kleinen, qualitativ hochwertigen und nutzbaren Schritten bereitzustellen. Der Umfang ist flexibel, da Anpassungen vorgenommen werden, wenn der Kunde und das Team besser verstehen, was tatsächlich benötigt wird; sie fügen hinzu, was ursprünglich an den Begierden fehlte, und entfernen, was jetzt als unnötig oder von geringem Wert erkannt wird. Die Arbeit kann am Ende jeder Iteration aufhören, wenn das richtige Maß an Funktionalität (Umfang) erreicht ist.

Im Agile-Manifest wird dies mit diesem Prinzip beschrieben:

Einfachheit – die Kunst, die Menge an nicht erledigter Arbeit zu maximieren – ist entscheidend.

Produkt Management

Scope Creep im Backlog sollte vom Product Owner verwaltet werden. Dies ist also eine Planung, bevor das Entwicklungsteam mit der Arbeit daran beginnt. Geschäftsziele erreichen, nicht nur Softwarefunktionen. Product Owner könnten so etwas wie Impact Mapping üben, um herauszufinden, wie sich neue Features auswirken, um zu beweisen, dass das Feature nicht nur nett zu haben ist, z. B. Scope-Creep.

Entwicklungsteam

Entwickler können Scope-Creep mit Test-Driven Development verhindern. Tests können Unit-Tests oder Akzeptanzkriterien sein. Denken Sie zuerst darüber nach und "dokumentieren" Sie, was Sie bauen möchten, bevor Sie es bauen, genau wie Ihre Anforderungen, aber just-in-time.

Eine Möglichkeit, wie XP'er sich ehrlich halten würden, besteht darin, darauf zu bestehen, dass sie einen fehlgeschlagenen Komponententest schreiben (der die Notwendigkeit von Komplexität demonstriert), BEVOR sie dem System die zusätzliche Komplexität hinzufügen.

http://www.agilenutshell.com/yagni

Implementieren Sie dann nicht mehr Funktionalität als nötig, um einen der Tests zu bestehen.

Kurz YAGNI (You Ain't Gonna Need It). Dies sollte sowohl für den Funktionsumfang funktionieren als auch die Tendenz der Entwickler einschränken, ein System zu überkonstruieren.

Ich denke, auf diese Frage gibt es je nach Kontext unterschiedliche Antworten.

CodeGnome hat den Umfang "außerhalb des Sprints" auf hoher Ebene gut abgedeckt - fügen Sie im Grunde Elemente zum Rückstand hinzu und erweitern Sie entweder das Projekt oder lassen Sie andere Funktionen fallen.

Innerhalb des Sprints ist diese Frage etwas subtiler. Ich finde es wichtig, zwischen „Scope Creep“ und „Gold Plating“ und „Change from learning“ zu unterscheiden.

Scope Creep und Gold Plating sollten außerhalb des Sprints verschoben werden – und wie oben gehandhabt werden. Das Team hat ein gesetztes Ziel mit Geschichten mit Akzeptanzkriterien, und aufgrund der Natur agiler Projekte sind die Anforderungen oft vage, wenn die Arbeit in einen Sprint gezogen wird. Während der Entwicklung tauchen im Laufe der Arbeit oft viele Fragen auf: "Sollen wir X als Teil davon machen?" Wo es wichtig ist, das Team zu coachen, um die Prinzipien der Maximierung der nicht erledigten Arbeit zu befolgen und effektiv daran zu arbeiten, das Minimum zu liefern, um die Story und das Sprint-Ziel zu erreichen.

„Scope Change“ ist jedoch die Essenz des Werts, den Agile liefert. Das Lernen aus einem Sprint kann das Product Backlog vollständig verändern, sodass Sie viel mehr Wert liefern können als zuvor geplant, in der gleichen oder potenziell weniger Zeit. Indem man früh etwas herausbringt und Feedback erhält, werden die enormen positiven Gewinne der Agilität sichtbar, und dies ist eher ein positives als das potenziell negative Element des traditionellen Scope Creep.

Zuerst müssen Sie genau bestimmen, was sie mit „Scope Creep“ meinen , da die genaue Bedeutung von verschiedenen Personen als unterschiedlich angesehen werden kann.

Bedeuten sie überhaupt keine Umfangsänderungen?

• Es ist wirklich schwierig, dies „agil“ zu nennen. Während es immer noch möglich sein könnte, Zeit und/oder Budget zu ändern, wäre die Tatsache, dass Sie nicht in der Lage sind, sich ändernde Kundenanforderungen zu akzeptieren, ein massiver Projektgeruch in jedem agilen Projekt.

Bedeuten sie, dass der Umfang nicht zunimmt , aber es ist in Ordnung, Sachen herauszunehmen und wieder einzusetzen?

• Das ist ziemlich einfach; Wenn eine Bereichsänderung erforderlich ist, müssen Sie nur bestimmen, was aus dem Bereich entfernt werden soll. Normalerweise wäre eine andere Option, Zeit oder Kosten hinzuzufügen (obwohl Zeit in vielen Fällen die einzig hilfreiche ist, da viele Möglichkeiten, Geld in ein spätes Projekt zu werfen, sei es durch neue Teammitglieder oder neue Technologie, es erst später fällig machen zu anfänglichen Sunk-Time-Kosten). In diesem Fall wäre dies jedoch ein „Scope Creep“, und daher besteht Ihre einzige wirkliche Option darin, den Scope zu verwalten, sowohl das Hinzufügen als auch das Entfernen aus dem Scope für eine Nettoänderung von Null (oder negativ, wenn sich herausstellt, dass Sie es wirklich tun brauchte dieses riesige Merkmal X doch nicht, also können Sie es leicht durch das kleinere Merkmal Y ersetzen).

Bedeuten sie, dass jede Art von Bereichsänderungen in Ordnung ist, aber nicht zu oft oder außer Kontrolle gerät?

• Dies ist ebenfalls einfach, wenn auch auf andere Weise. Sie brauchen einfach ein rigoroses Änderungsmanagementverfahren, bei dem jede einzelne Änderung des Umfangs richtig/gründlich bewertet und entsprechend reagiert wird (ob diese Reaktion Zeit verlängert, etwas anderes aus dem Umfang nimmt, eine andere Lösung findet oder einfach nur ablehnt die Umfangsänderung).

Es könnte eine andere Bedeutung geben, die sie beabsichtigen, wenn sie "Scope Creep" verwenden, aber ich denke, die oben genannten drei sind die häufigsten. Wenn alles andere fehlschlägt, geben Sie alle vorgefassten Meinungen auf und denken Sie nur darüber nach, welche Art von Reaktion innerhalb der gegebenen Einschränkungen notwendig wäre, um einen Mehrwert für das Projekt, das Unternehmen und den Kunden zu schaffen. Letztendlich geht es bei Agile darum, Werte zu schaffen.

Meine Meinung (IANASM) ist, dass es so etwas wie "Scope Creep" nicht gibt. In Agile sollten Sie für einen kurzen Zeitraum (der aktuelle Sprint in Scrum-Begriffen) an den wertvollsten Funktionen für das Unternehmen arbeiten.

Es sollte einen Arbeitsrückstand geben, der Eigentum des Product Owners ist, und er hält ihn in der Reihenfolge, was als nächstes am wertvollsten ist.

Wenn neue Informationen auftauchen, steht es dem Product Owner frei, diese Arbeitsliste neu zu ordnen und bestimmte Funktionen gegenüber anderen Funktionen auf der Grundlage dessen, was er zu diesem Zeitpunkt weiß, neu zu priorisieren.

Wenn der aktuelle Sprint/die aktuelle Iteration abgeschlossen ist, übernimmt das Team den nächsten Satz von Funktionen, von denen es glaubt, dass sie sie in der nächsten Iteration vervollständigen können.

Das Konzept ist, dass diese Iterationen lang genug sein sollten, um eine Reihe von Funktionen vollständig „fertig“ zu machen (nach der Definition Ihres Teams von „fertig“ – dh für die Produktion bereitgestellt), aber nicht so lange, dass Änderungen am Unternehmen nicht berücksichtigt werden auf schnell genug.

Scrum spricht zumindest davon, einen Sprint beenden zu können, bevor er fertig ist, aber es ist eine teure und störende Operation, sodass es nicht aus einer Laune heraus getan werden sollte.

Agile sollte die Verpflichtung zu einer Reihe von Arbeiten und einen Zeitraum für diese Arbeit ausbalancieren, der die Produktbesitzer nicht nervös macht, dass sie nie „das nächste Ding“ bekommen werden.

Bei Agile dreht sich alles um Praktiken, die mit sich ständig ändernden Anforderungen arbeiten. Es wird davon ausgegangen, dass die Anforderungen und der Plan auch in drei Monaten mit hoher Wahrscheinlichkeit suboptimal sind, weil:

• Der Kontext ändert sich
• Meinungen und Standpunkte reifen oder ändern sich
• Der Versuch einer Lösung ist eine Lernerfahrung, die neue Einblicke in das Problem und die möglichen Lösungen gibt

Dies ist ein Zitat aus Extreme Programming Explained :

XP ist ein Weg der Verbesserung zur Exzellenz für Menschen, die zusammenkommen, um Software zu entwickeln. Es unterscheidet sich von anderen Methoden durch:

• Seine kurzen Entwicklungszyklen führen zu frühem, konkretem und kontinuierlichem Feedback.
• Sein inkrementeller Planungsansatz, der schnell zu einem Gesamtplan führt, der sich voraussichtlich während der gesamten Lebensdauer des Projekts weiterentwickeln wird.
• Seine Fähigkeit, die Implementierung von Funktionen flexibel zu planen und auf sich ändernde Geschäftsanforderungen zu reagieren.
• Seine Abhängigkeit von automatisierten Tests, die von Programmierern, Kunden und Testern geschrieben wurden, um den Fortschritt der Entwicklung zu überwachen, das System weiterentwickeln zu lassen und Fehler frühzeitig zu erkennen.
• Seine Abhängigkeit von mündlicher Kommunikation, Tests und Quellcode, um die Systemstruktur und -absicht zu kommunizieren.
• Seine Abhängigkeit von einem evolutionären Designprozess, der so lange dauert, wie das System besteht.
• Seine Abhängigkeit von der engen Zusammenarbeit aktiv engagierter Personen mit gewöhnlichem Talent.
• Seine Abhängigkeit von Praktiken, die sowohl mit den kurzfristigen Instinkten der Teammitglieder als auch mit den langfristigen Interessen des Projekts zusammenarbeiten.

Es gibt hier viele gute Antworten, aber ich dachte, ich würde versuchen, eine kürzere Antwort zu geben, um zu sehen, ob es helfen würde.

Scope Creep gibt es nicht. Es gibt nur tieferes Verständnis.

Das setzt nur einiges voraus:

1. Sie und Ihr Kunde vertrauen einander genug, um häufig zusammenzuarbeiten
2. Wenn Sie eine feste Lieferung haben, können Sie den Umfang flexibel anpassen
3. Wenn der Umfang festgelegt ist, können Sie bei der Lieferung flexibel sein
4. Sie bauen das auf, von dem Sie wissen , dass es für Ihre Kunden wertvoll ist
5. Sie versenden nicht $#^!

Einer wird für zwei und drei benötigt. Vier und fünf bilden die Nummer eins. Es ist ein harmonischer Zyklus, der dem Agilen Manifest treu bleibt und den Scrum verkörpert.

Ich habe dies hier erweitert , wenn Sie tiefer graben möchten.