Ich wurde gefragt, was ein Team tun sollte, wenn die Art des Projekts vertikale Schnitte in ihren zu liefernden Geschichten ausschließt.
Die Definition von „inkrementeller Entwicklung“ finden Sie hier: https://www.agilealliance.org/glossary/incremental-development/
Ganz oben in diesem Dokument steht Folgendes:
In einem agilen Kontext bedeutet dies, dass jede nachfolgende Version des Produkts verwendbar ist und jede auf der vorherigen Version aufbaut, indem sie für den Benutzer sichtbare Funktionen hinzufügt.
Ich hatte vor kurzem eine Anfrage des Formulars:
Was passiert in einem agilen Projekt, wenn die Art der zu erstellenden Software einfach keine Vorgängerversion hat, auf der aufgebaut werden kann, und daher keine brauchbare Folgeversion liefern kann? Zum Beispiel Softwareschichten in einem Mobiltelefon, die noch kein „Telefon“ haben, zu dem sie gehören können, und die höchstwahrscheinlich keine Benutzereingaben beinhalten und einfach einen Dienst für andere Funktionseinheiten bereitstellen.
Kurz gesagt, wie können Sie INVEST implementieren, wenn es den Anschein hat, dass die Geschichte nicht genug Tiefe hat, um dies zu tun?
(Ich habe zuvor einen Scrum Master erlebt, der bei einem Webprojekt eine vollständige DB-to-UI-Arbeit für jede Story durchgesetzt hat – buchstäblich – und ja, das hat viel Reibung verursacht.)
Nach den ersten paar Sprints sollte sich ein Scrum-Produkt immer in einem potenziell freigabefähigen Zustand befinden. Das bedeutet von Natur aus , dass es bei einer Sprint-Demo immer etwas zu demonstrieren gibt, aber Sie müssen möglicherweise kreativ sein und „um die Ecke denken“, um es zu finden. Behandeln Sie Demos während der Sprintplanung als erstklassige Arbeitsergebnisse, um die Entwicklung von Demonstrationen einfacher und intuitiver zu gestalten.
Was passiert in einem agilen Projekt, wenn die Art der zu erstellenden Software einfach keine Vorgängerversion hat, auf der aufgebaut werden kann, und daher keine brauchbare Folgeversion liefern kann? Zum Beispiel Softwareschichten in einem Mobiltelefon, die noch kein „Telefon“ haben, zu dem sie gehören können, und die höchstwahrscheinlich keine Benutzereingaben beinhalten und einfach einen Dienst für andere Funktionseinheiten bereitstellen.
Dies ist ein häufiges Missverständnis darüber, was „iterativ“ oder „inkrementell“ in einem agilen Kontext bedeutet. Es bedeutet in keiner Weise, dass Sie eine frühere Version der Software haben müssen; Das bedeutet, dass zukünftige Versionen auf der Arbeit aufbauen können (und sollten). Agile Projekte profitieren stark von emergentem Design und agile Frameworks werden dafür optimiert.
APIs und Middleware können wie jede andere Software in kleinen, testbaren Schritten wachsen und sich weiterentwickeln, also gibt es nichts, was gegen eine Investition in solche Systeme spricht. APIs und Middleware können ähnlich wie herkömmliche Software versioniert, modifiziert und erweitert werden.
Es gibt nichts, was APIs oder Middleware inhärent ist, was sie daran hindert, in einem potenziell freigabefähigen Zustand gehalten oder demonstriert werden zu können. Solche Systeme sollten immer noch etwas können, und wenn Sie es testen können, können Sie es auch demonstrieren.
Was viele Leute jedoch zu verwirren scheint, ist die Schwierigkeit, neue Funktionen in einem Produkt zu demonstrieren, das sich nicht leicht für visuelle Präsentationen eignet. Dies erfordert oft etwas mehr Kreativität und agile Testerfahrung, als viele Shops zu Beginn ihrer agilen Reise haben. Einige gängige Lösungen umfassen:
Verwendung ausführbarer Tests für die Demonstration.
Gurke ist ein gutes Beispiel dafür. Zu sehen, wie gut geschriebene Tests (und damit verhaltensbeschreibende Dokumentationen) grün werden, ist eine vollkommen gültige Demonstration für viele Arten von Software.
Nutzen Sie Ihren Entwicklungs- oder QA-Testrahmen für Demonstrationen.
Fast jede Art von TDD/BDD oder Continuous Integration erfordert ein gewisses Maß an Testabstraktion. Mocks, Stubs, Fixtures und Factories stehen oft stellvertretend für andere Teile der „echten“ Architektur, selbst bei Integrationstests. Nichts hindert Sie daran, solche Techniken zu verwenden, um die Funktionalität von API- oder Middleware-Clients in Ihren Sprint-Demos herauszuarbeiten.
Erstellen Sie einen „Demo-Client“.
Der Punkt ist, zu zeigen, dass Ihr Produkt etwas tut. Wenn Sie es nicht vor Ort zeigen können, können Sie zumindest ein Modell oder einen Simulator erstellen, der zeigt, wie ein API- oder Middleware-Client mit Ihrem Code interagieren würde. Demonstrieren Sie diese Interaktion!
Dokumentation, Tortendiagramme und andere visuelle Hilfsmittel.
Die Sprint-Demo soll den Fortschritt zeigen und Stakeholder-Feedback einholen, um es in zukünftige Sprints einfließen zu lassen. Während alle Abstraktionen undicht sind, können Sie sich immer sekundäre Artefakte zunutze machen, wenn Sie sich wirklich keine andere Möglichkeit vorstellen können, Ihren Arbeitszuwachs zu demonstrieren. Führen Sie die Leute durch Code, Commit-Verlauf, lebendige API-Dokumentation wie Swagger oder andere Dinge, die einen gültigen Überblick über den aktuellen Zustand des Produkts bieten.
Scrum schreibt vor, dass Arbeitsinkremente demonstriert werden, schreibt aber nicht vor, wie die Demonstrationen durchgeführt werden müssen. Es gibt keine Vorschrift, dass eine Demo eine Tastatur oder eine grafische Oberfläche erfordern muss. Wenn es für das Produkt relevant ist, können Skywriting oder Interpretationstanz für die Demonstration genauso legitim sein.
Das Ziel des Frameworks ist es, traditionelle Statusberichte zu vermeiden und den Stakeholdern „mehr Show, weniger Tell“ zu bieten. Wenn das Team keine Möglichkeit findet, das Arbeitsinkrement zu demonstrieren, wird es wohl auch für sie sehr schwer sein, es zu testen.
TDD/BDD-Frameworks funktionieren am besten, wenn Sie die Tests zuerst entwerfen, anstatt Ihre Tests nachträglich zu schreiben; Es erleichtert das Testen und stellt sicher, dass das Produkt von Anfang an getestet werden kann . Sprint-Demos sind nicht anders. Während der Sprint-Planung sollte das Team berücksichtigen, wie es plant, die Arbeit in seinen User Stories und Schätzungen auf der Vorderseite und nicht auf der Rückseite zu demonstrieren.
Manchmal kann die Planung um Demonstrationen herum die Art und Weise ändern, wie Sie Geschichten aufteilen oder wie Sie die Arbeit planen oder schätzen. Wenn ja, großartig! Das bedeutet, dass Sie das Framework nutzen.
Behandeln Sie Demos als erstklassige Arbeitsergebnisse, nicht als nachträgliche Einfälle. Wenn Sie die Arbeit auf diese Weise umgestalten, wird der beste Weg, die Arbeitsschritte zu demonstrieren, normalerweise selbstverständlich.
tl;dr; Gib dein Bestes. Versuchen Sie, immer validiertes Wissen oder nutzbare Funktionalität zu produzieren. Suchen Sie immer nach Benutzerfeedback. Schwitzen Sie nicht, wenn Sie keine gute Option sehen.
Der Zweck dieser Praxis bestand darin, Produktinkremente eines Produkts herzustellen. In der Agilität wollen wir die Vorstellung loswerden, dass wir die „richtige“ Lösung kennen und sie nur noch codieren müssen. Das ist fast nie der Fall.
Dieses Video erklärt die verschiedenen Arten der Prozesssteuerung und Scrum setzt empirische Maßstäbe. ( https://www.youtube.com/watch?v=S-VaiB3uPdk ) Darin ist das Ziel immer, einen nächsten kleinen Schritt zu machen und zu sehen, wie viel näher uns das unserer Antwort bringt. Das Entwerfen einer Datenbank ist großartig, wenn wir uns in einer definierten Prozesssteuerung befinden, weil wir bereits sicher wissen, was alle Schritte sind, und es nur eine Frage des Durcharbeitens ist. Es ist schrecklich für die empirische Prozesskontrolle, weil man wenig oder gar nichts daraus lernt. Sie wissen, dass Sie gearbeitet haben, aber es gibt keine Möglichkeit zu sagen, ob es die richtige Arbeit ist.
Wenn Sie sich also fragen, was der nächste Schritt ist und wie Sie das nächste Produktinkrement nutzen, um etwas darüber zu erfahren, wie Ihr Kunde das Produkt verwenden wird und was „erledigt“ für Sie wirklich bedeutet, sind Sie wahrscheinlich auf der richtigen Weg, auch wenn Sie am Ende keine UI-Funktionalität programmieren.
Daniel