Müssen Sie funktionierende Software in einer agilen Timebox/Sprint liefern?

Über die vier Werte hinaus sind auch diese Prinzipien relevant:

Unsere höchste Priorität ist es, den Kunden durch frühzeitige und kontinuierliche Lieferung wertvoller Software zufrieden zu stellen.

Und

Stellen Sie häufig funktionierende Software bereit, von ein paar Wochen bis zu ein paar Monaten, wobei Sie kürzere Zeiträume bevorzugen.

Und

Funktionierende Software ist das primäre Maß für den Fortschritt.

Die Vorteile der agilen Softwareentwicklung werden am besten durch die häufige Bereitstellung von funktionierender Software realisiert.

Es ist auch wichtig darauf hinzuweisen, dass Timeboxes der agilen Softwareentwicklung nicht eigen sind. Die Wörter „iterativ“, „inkrementell“, „Iteration“ und „Timebox“ kommen nirgendwo im Manifest vor. Einige Methoden basieren jedoch auf Timeboxes – Extreme Programming und Scrum sind zwei beliebte Frameworks, die Timeboxes verwenden. Andere nicht – Kanban kann mit einem kontinuierlichen Fluss verwendet werden.

Sie müssten die Ersteller jeder Methode fragen, warum sie Timebox-Iterationen verwenden. Es gibt einige Vorteile, insbesondere für weniger reife Teams, um sicherzustellen, dass alle Dinge, die passieren müssen, auch tatsächlich passieren. Wenn verschiedene Ereignisse und Aktivitäten just-in-time stattfinden, ist es leicht, Ereignisse zu vernachlässigen oder zu kurz zu bringen.

Das Ergebnis jeder Iteration hängt vom Framework ab. Beispielsweise fordert Scrum Product Backlog Items, die den Status des Produkts ändern, das in jedem Sprint fertiggestellt werden soll. Andere Methoden haben möglicherweise nicht diese strenge Definition. Sie könnten eine Methode definieren, die Wert liefert. Verschiedene "zweigleisige" Methoden definieren auch den Wert in Bezug auf die Ermittlungs- und Bereitstellungsarbeit.

Ich würde Ihren Produktentwicklungsprozess als agil bezeichnen, wenn er den Werten und Prinzipien des Manifests für agile Softwareentwicklung folgt. In Bezug auf die Häufigkeit der Softwarelieferung besteht die einzige Anforderung in der Häufigkeit von „ein paar Wochen bis ein paar Monaten“. Ob Sie Timeboxen verwenden oder nicht oder am Ende jeder Timebox funktionierende Software liefern, macht Sie nicht agil oder hindert Sie daran, agil zu sein.

Müssen Sie funktionierende Software in einer agilen Timebox/Sprint liefern?

Wenn Sie ein Softwareprodukt mithilfe von Sprints erstellen, sollten Sie in jedem Sprint funktionierende Software liefern. Der Sinn eines Sprints besteht darin, eine Kadenz von Aktivitäten und einen Inspektionspunkt zu haben, an dem Sie sich ansehen, was Sie erstellt haben, Feedback sammeln, Ihr Verständnis basierend auf den erhaltenen Eingaben und dem aktuellen Kontext anpassen und Ihre nächsten Schritte in Richtung Ihres Ziels planen Ziel. Wenn Sie nicht in jedem Sprint funktionierende Software produzieren, verpassen Sie diese Gelegenheit zur Überprüfung und Anpassung.

Es kann jedem Team passieren, ab und zu einen schlechten Sprint zu haben und am Ende kein Inkrement auf das Produkt zu liefern, das ist nicht wirklich ein Problem, es kann vorkommen. Aber wenn es ständig passiert, verlieren Sie viele Möglichkeiten herauszufinden, ob Sie das Richtige bauen. Zwölf Monate später haben Sie ein Produkt, das der Kunde nicht verwenden kann, und Ihnen wird gesagt, Sie hätten es vom ersten Monat an anders machen sollen, wenn Sie nur etwas für Ihre Arbeit vorzuweisen hätten.

Allerdings ... führen Sie mit diesen Fragen eine interessante Perspektive ein:

• Bedeuten die obigen Gedanken, dass ein agiler Sprint/eine agile Timebox keine funktionierende Software liefern muss, sondern nur etwas Funktionierendes, wobei Arbeiten als etwas definiert ist, das eine Produkthypothese testen kann?
• Gibt es Grenzen, wenn ein Sprint etwas liefert, das eine Produkthypothese testen kann? Am Beispiel eines Sprints, der Geschäftsregeln testet, könnte ein Sprint nur die auf Papier niedergeschriebenen Geschäftsregeln liefern und dann eine Person aussenden, um mit einem Endbenutzer zu interagieren und die Eingaben des Endbenutzers zu berechnen, indem sie die Regeln befolgt und misst, ob der Endbenutzer davon abgeleitet hat Wert aus der Ausgabe?

Ich habe Ihre Frage im Titel mit "Wenn Sie ein Softwareprodukt erstellen" beantwortet und ja gesagt. Wenn es sich bei Ihrem Produkt um Software handelt, wird das nächste Inkrement oder die nächste Verbesserung des Produkts natürlich in Form von Software vorliegen. Was Sie mit den anderen Fragen fragen, sieht für mich eher nach einer explorativen Studie oder einer Entdeckungsaktivität aus, um festzustellen, was in Ihr Softwareprodukt aufgenommen werden sollte.

In diesem Fall könnten Sie einen Spike in Ihrem Sprint verwenden, um die explorative Studie durchzuführen. Dann liefern Sie am Ende des Sprints einige Funktionen im Softwareprodukt (wegen der Spitze nicht so viel wie bei anderen Sprints) sowie das Ergebnis Ihrer Studie (in Form von Papierformularen oder so). Sie können dann das neue Formular des Produkts und die Papierformulare verwenden, um zu entscheiden, was als nächstes zu tun ist (was Sie der Software hinzufügen möchten, wenn Sie weitere explorative Studien benötigen, können die Papierformulare möglicherweise verbessert, geändert usw. werden, um besser zu sammeln Informationen usw.).

Falls der Spike die Zeit des gesamten Sprints verschlingt, würde ich die Sprints pausieren, während ich nicht an der Software arbeite. Die neue Arbeit, die Sie dem Softwareprodukt hinzufügen, muss eine Art "Definition of Done" respektieren, damit sie sicher für Kunden freigegeben werden kann, und dies muss von Sprint zu Sprint gelten. Wenn einer Ihrer Sprints Papierformulare produzieren würde, dann haben diese nichts mit Ihrer „Definition of Done“ für Softwarefunktionen zu tun. Es passt also nicht ganz zu den anderen Sprints, die Software produzieren. In diesem Fall gehen Sie zurück zu einer Spitze von weniger Zeit, oder (persönlich) würde ich eine andere Produktspur dafür verwenden:

• ein Software-Track, um das Produkt zu entwickeln und Software bereitzustellen;
• Ein explorativer Track, der Informationen, Wissen und Einblicke darüber liefert, was als nächstes in Ihr Softwareprojekt einfließen sollte.

Sie können dann wie folgt zwischen diesen Spuren wechseln:

oder so:

So behältst du den Überblick, musst nicht verschiedene Ergebnisse mit der gleichen „Definition for Done“ mischen, deine Metriken geraten nicht von einem Sprint zum anderen durcheinander usw. Beide Tracks können auch weitergehen gleichzeitig, wenn Sie Leute haben, die an dem Softwareprodukt arbeiten können, während andere auf der Suche nach Erkenntnissen mit Papierformularen herumspielen.

Dies ist natürlich mehr Arbeit und erfordert mehr Koordination als die Verwendung eines Spikes mit anderen Arbeiten auf einer einzelnen Spur.

Ein noch einfacherer Ansatz wäre, Kanban zu verwenden und auf Sprints, Spikes und Tracks ganz zu verzichten und einfach an der nächsten Sache zu arbeiten, die benötigt wird und Wert bringt (seien es Papierformulare, Interviews mit Benutzern oder der Einbau von Funktionen in die Software). Entscheiden Sie sich dann für eine Kadenz, um einige Inspektionspunkte einzuführen, damit Sie immer noch Feedback sammeln und Ihre nächsten Schritte in Richtung Ihres Ziels anpassen können.

Wie bereits von anderen erwähnt, sind Sprints Teil von Scrum. Sie haben nichts mit Agilität zu tun.

Früher hat Scrum Guide die Ideen klar formuliert, aber je weiter wir gehen, desto undurchsichtiger wird es*. Der aktuelle Scrum Guide sagt, dass wir bis zum Ende des Sprints ein Inkrement liefern müssen, und das Inkrement bezieht sich auf den „Wert“. Es scheint, dass die Autoren versuchen, eine große Anzahl von Situationen mit einem Tool abzudecken, und deshalb versuchen sie, nicht genau zu sein. Also ... ich denke, dass das Dokument selbst versucht, nein zu sagen - Sie müssen am Ende des Sprints keine neue Funktionalität für PRD freigeben. Aber was die meisten Leute für Scrum halten – würde zu einem Release am Ende jedes Sprints führen.

Warum haben wir Sprints?

Das ist eine großartige Frage. Und ich hoffe, dass Sie (und alle anderen) eines Tages erkennen, dass wir sie nicht brauchen.

Sprints ermöglichen es uns, ein Projekt durch kleinere Arbeitspakete, die häufig geliefert werden, anzugehen.

Sprints allein erleichtern keine häufigen Releases. Sie können dies auch ohne sie tun. Darüber hinaus können Sie oft schneller liefern als Sprints. Sie können Just-in-Time und/oder Continuous Delivery verwenden, um Software viel häufiger zu veröffentlichen, als Sie es mit Sprints tun würden.

Was ich beschreibe, ist nur eine Produktentwicklungsmethodik, und Agile ist eine Teilmenge davon.

Agile Entwicklung bedeutet einfach, dass Sie Ihren Prozess verbessern, wenn Sie sehen, wie Sie ihn verbessern können. Es ist keine Methodik, es ist eine Denkweise, die es ermöglicht, Ihren Prozess zu erstellen/zu ändern.

Das Aufschreiben von Geschäftsregeln ist nur eine Dokumentation, die nicht so nützlich ist wie eine funktionierende Software. Bezieht sich auf den nächsten Punkt.

Das Schreiben von Anforderungen (scheint so zu sein, was Sie mit Dokumentation meinen) könnte ein Sprungbrett für eine funktionierende Software sein, die später erledigt wird. Also sicher - die funktionierende Software ist besser, weil es bedeutet, dass mehr Arbeit geleistet wurde. Sowohl bei kontinuierlichen Methoden (ToC, JiT, CD) als auch bei zeitbasierten Ansätzen (Wasserfall, Scrum) schreiben Sie zuerst Anforderungen, dann schreiben Sie Software.

Agiles Manifest, wenn es um Software-over-Documentation geht, bezieht sich auf:

1. Dev-Prozesse, bei denen Sie, wenn Sie etwas tun möchten (Code zum Testen senden, in einer Umgebung bereitstellen, Konfiguration ändern usw.), eine Menge Dokumentation ausfüllen müssen. Es geht also um Bürokratie.
2. Fälle, in denen Sie viele Anforderungen im Voraus schreiben würden, bevor Sie sie implementieren. Und das ist nicht cool, denn nach Ihrer ersten Veröffentlichung werden Sie feststellen, dass Sie viele Fehler gemacht haben und viele dieser Anforderungen nutzlos sind. In ToC & JiT bezieht sich dies auf die Begriffe "unfertige Arbeit", "in Arbeit", "Inventarkosten" - je mehr Sie getan haben, was nicht freigegeben wird, desto mehr bremst es Sie aus.

Das Erstellen der beschriebenen Schichten in der Reihenfolge (Geschäftsregeln, Code, der diese Regeln berechnet (die normalerweise im Backend vorhanden sind), Benutzeroberfläche) ist ein Wasserfall und führt die Risiken des Wasserfalls ein.

Wasserfall kann vieles bedeuten. In den meisten Fällen beziehen sich die Leute auf Entwicklungsprozesse, die selten veröffentlicht werden (z. B. einmal in 6 Monaten). Und das ist nicht unbedingt schlecht! Einige Projekte erfordern viel Nachdenken, Modellieren, Simulieren und Testen, bevor sie live gehen. Es gibt Anwendungsfälle für Wasserfall (mehr als viele Leute denken).

Sie erwähnen immer wieder "Benutzereingaben" - aber das ist NICHT das, was wir brauchen, um großartige Software zu entwickeln. Wir brauchen Informationen . Und je nach Projekt können die wichtigsten Informationen variieren:

• Machbarkeit: Sind wir sicher, dass wir eine solche Idee wirklich umsetzen können - vielleicht ist die Technologie noch nicht da? Oder vielleicht ist die Technologie da, aber die Idee ist unerschwinglich teuer/langsam/umständlich.
• Bildung: Je mehr wir implementieren (nicht unbedingt veröffentlichen), desto besser verstehen wir die Domäne und die Idee
• Investition: Sind wir sicher, dass wir für diese Idee finanziert werden? Vielleicht brauchen wir einen Prototyp und keine echte Software in RPD.
• Und natürlich die typischen Ziele wie: Sind wir sicher, dass wir die Probleme unserer Nutzer lösen? Das ist der Fall, der definitiv von häufigen Veröffentlichungen profitieren würde.

Dies kann sich auch auf die Phase beziehen, in der sich das Projekt befindet. Am Anfang bräuchten wir zB viel Vorarbeit (manche Projekte brauchen 6 Monate, andere 3 Jahre). Aber nachdem die anfängliche Arbeit erledigt ist, möchten wir möglicherweise häufiger veröffentlichen. Und das nicht nur wegen des Feedbacks. Vielleicht haben wir einen Fehler gemacht und möchten ihn bald beheben, oder das Marketing braucht diese Funktion schnell, weil sie es bereits versprochen haben.

*Es sieht so aus, als würden sie versuchen, ihre Spuren zu verwischen, denn jedes Mal, wenn ich versuche, die 1. Version des Scrum Guide zu finden, wird es immer schwieriger :)