Ist der Mangel an funktionalen Anforderungen agil?

Heutzutage will jeder agil sein. In jedem Team, mit dem ich zusammengearbeitet habe, war die Form von Agilität anders. Einige Dinge sind häufig - wie tägliche Stand-Ups oder Planungen, andere Teile variieren jedoch erheblich.

In meinem aktuellen Team gibt es ein Detail, das mich stört. Es fehlen funktionale Anforderungen. Es gibt nicht nur keine schriftliche Form von Erwartungen, sondern auch in den Aufgaben ist ziemlich vage definiert, was zu tun ist.

Ziel des Projekts ist es, das alte System mithilfe neuer Technologien neu zu schreiben. Das alte System hat auch keine vernünftige Dokumentation. Natürlich gibt es keinen aktuellen. Die Beschreibung der Anforderungen durch die Geschäftsinhaber lautet: Machen wir es in der neuen Implementierung genauso wie in der alten. Es scheint vernünftig, ist es aber nicht. Ein altes System ist eine Art Spaghetti-Code, und das Extrahieren von Geschäftsanforderungen ist kostspielig. Es scheint, dass sich die Situation negativ auf die Planung auswirkt. Sicher ist es anfällig für Fehler und Bugs bei der neuen Implementierung (ohne einige Details).

Daher denke ich: Ist es wirklich agil, keine Geschäftsanforderungen zu haben, wenn ein altes System neu geschrieben wird?

Unabhängig davon, ob funktionale Anforderungen agil sind oder nicht, ist dies ein Rezept für eine Katastrophe. Sie können ein System nicht neu erstellen, wenn Sie nicht wissen, wie dieses System funktioniert.

Sie müssen dem Geschäftsinhaber mitteilen, dass Sie keine Ahnung haben, wie das alte System funktioniert.

Am besten arbeiten Sie mit Ihrem Geschäftsinhaber oder einigen erfahrenen Benutzern zusammen, um die aktuellen Geschäftsprozesse zu verstehen und Ihre eigenen Abnahmetests zu entwickeln. Wenn Sie mit einigen Endbenutzern arbeiten können, erhalten Sie möglicherweise mehr Feedback zur Funktionsweise des alten Systems.

Andernfalls müssen Sie einige Erkundungstests in einer Umgebung ohne Produktion durchführen, um Ihre eigenen Anforderungen zu erfassen. Wenn ein Geschäftsinhaber oft sagt, dass es wie das alte funktioniert, sind sie zeitlich begrenzt und können Ihnen nicht so helfen, wie es ein Geschäftsinhaber tun sollte. Sie benötigen das Fachwissen einiger erfahrener Benutzer oder viele manuelle Tests, um zu verstehen, wie das alte System funktioniert.

Informieren Sie den Geschäftsinhaber darüber, dass ein Mangel an Anforderungen und Verständnis für das alte System die Zeit für den Wiederaufbau erheblich verlängert - etwa dreimal so lange oder länger. Angesichts des erhöhten Zeitplans und der höheren Kosten wird der Geschäftsinhaber Ihnen entweder das erforderliche Fachwissen zur Verfügung stellen, um Anforderungen schneller zu erfassen, oder entscheiden, dass das Umschreiben derzeit wirtschaftlich nicht machbar ist.

Sie erhalten eine der folgenden Möglichkeiten:

• Richtige Anforderungen und ein schnellerer Entwicklungszyklus
• Zeit, Anforderungen zu sammeln und die Software neu zu erstellen
• Ein neues Projekt, das Ihre Karriere nicht schwarz markiert

Agile ändert nicht die Notwendigkeit funktionaler Anforderungen, aber es ändert im Allgemeinen, wie Sie sie erfassen . Der nicht agile Weg besteht darin, dass jemand einen langen Prozess durchläuft und Ihnen dann eine Art Dokument gibt, das alle Anforderungen an das System enthält.

Die agile Möglichkeit, Anforderungen zu erfassen, besteht darin, gemeinsam die Anforderungen für ein kleines Inkrement des Systems festzulegen, es zu erstellen, dann Feedback zu erhalten und das nächste Inkrement durchzuführen. In Ihrer Situation, in der Sie Probleme haben, die Geschäftsinhaber dazu zu bringen, den Prozess einzuleiten, würde ich zunächst einen halben Tag damit verbringen, den Teil des alten Systems zu erkunden, an dem Sie als Nächstes arbeiten möchten, und eine Liste mit Fragen zu den Anforderungen erstellen.

Setzen Sie sich dann mit Ihren Geschäftsinhabern zusammen und stellen Sie ihnen die Fragen. Einige Fragen sind für sie leicht zu beantworten, andere sind für Sie einfacher, wenn Sie sich den Code ansehen, und andere sind in beiden Fällen schwer zu beantworten. Teilen Sie die schwierigen Fragen in immer kleinere Teile, bis Sie etwas erreichen, das beantwortet werden kann.

Das Ziel ist es, gerade genug von Ihren Fragen zu beantworten, um etwas aufzubauen, Feedback zu erhalten und den Prozess neu zu starten. Denken Sie daran, je kleiner Ihre Änderungen und je kürzer Ihr Feedback-Zyklus ist, desto weniger wichtig ist es, wenn Sie das Falsche bauen.

Das Erfassen von Anforderungen ist ein wesentlicher Bestandteil jedes (erfolgreichen) Softwareprojekts. Das Schreiben einer Anforderungsspezifikation ist dies jedoch nicht.

• Ein dokumentationsorientierter Ansatz kann wie ein Spiel mit chinesischem Flüstern enden: Ein Fachexperte äußert eine Anforderung, ein Analyst schreibt sie auf, ein Entwickler versucht, etwas zu schreiben, das der Beschreibung des Analysten entspricht, der Endbenutzer ist verwirrt, weil die Software dies nicht tut lösen ihr Problem nicht.

  Agile Techniken legen nahe, dass Entwickler Anforderungen direkt von den Fachexperten, normalerweise den Endbenutzern, einholen sollten. Hierfür gibt es eine Vielzahl von Techniken, z. B. durch ein Beispielszenario mit dem KMU. Entwickler sind gut darin, Randfälle zu erkennen und das KMU zu bitten, zu klären, wie sich die Software in diesem Randfall verhalten soll.

• Anstatt alle Anforderungen im Voraus zu erfassen (und damit große Missverständnisse zu riskieren), werden agile Teams wahrscheinlich mit einem kleinen Teil der Anforderungen beginnen, einen Prototyp erstellen und diesen verwenden, um Feedback für die nächste Iteration zu sammeln.

• Da sich das Verständnis der Anforderungen im Laufe der Zeit ändert, ist eine statische Anforderungsspezifikation nicht mehr aktuell. Wie kann dies verhindert werden?

  Indem Sie Anforderungen als ausführbare Tests ausdrücken. Es stellt sich heraus, dass „lesbare Spezifikation“ und „ausführbare Tests“ keine exklusiven Konzepte sind, sondern ein und dasselbe Dokument sein können. Zum Beispiel können Gurken und andere Ideen aus dem BDD-Bereich hier sehr hilfreich sein.

Wenn Sie ein altes System neu schreiben, kann das ursprüngliche System eine hervorragende Quelle für Anforderungen sein. Aber welche Aspekte sind relevant? Werden die Nischenfunktionen überhaupt genutzt? Welche Fehler müssen aus Kompatibilitätsgründen erneut implementiert werden? Es gibt normalerweise keine Problemumgehung, um mit den Endbenutzern zu sprechen.

Ein herumliegendes funktionierendes System kann auch sehr hilfreich sein, um die neue Software zu testen, aber das hat nichts mit agilen Bedenken zu tun.

Beachten Sie, dass Projekte mit festem Umfang und fester Zeit und drohenden Fristen das Gegenteil von Agilität sind. Der normale agile Ansatz besteht darin, einen Teil der Funktionalität auszuwählen und diesen zuerst bereitzustellen und dann zu iterieren. Die wichtigsten Dinge werden zuerst erledigt, weniger wichtige Dinge später (oder nie). Wenn alles wichtig ist und so schnell wie möglich erledigt werden muss, ist nichts wichtig und es ist unwahrscheinlich, dass das Projekt etwas liefert.

In Ihrer Situation ist das Fehlen von Anforderungen kein agiles Merkmal, sondern eher ein durchschnittlicher Fall von organisatorischer Dysfunktion. Wenn das Projekt erfolgreich sein soll, müssen Sie einen Weg finden, um diese Funktionsstörung zu beseitigen. Fordern Sie den Geschäftsinhaber beispielsweise auf, kein vollständiges Anforderungsdokument zu verfassen, sondern ein Meeting einzurichten, in dem er seine Anforderungen für das wichtigste Feature erläutert. Sie können sich das alte System für Details ansehen. Implementieren Sie dann diese Funktion und iterieren Sie.

So haben wir es gemacht. Wir haben mit den Besitzern gesprochen. Wir haben mit den Managern gesprochen. Wir haben mit den Benutzern gesprochen, die die Arbeit erledigen. Was wir fanden, indem wir uns an den Schreibtisch eines Benutzers setzten und zuschauten (und Fragen stellten), war erstaunlich nützlich. Die Manager wussten, mit welchen Benutzern wir uns zusammensetzen sollten.

Wir stellten fest, dass einige Teile des Systems in der Tat sehr gut funktionierten und wir leicht genug Anforderungen schreiben konnten, um mit dem Entwerfen, Codieren und Testen von Fällen usw. zu beginnen, aber andere Teile hatten einige unangenehme Problemumgehungen, die die Benutzer auf dem Boden verwendeten. was den Managern und den Eigentümern nicht bewusst war. Für diese Teile des alten Systems gingen wir zurück zum Geschäft und sprachen ein wenig über Workflow und Prozesse, bevor wir die kleineren Aufgaben festlegen und sie so in die Einheiten aufteilen konnten, die unsere agile Methode wollte.

Während Agile einige Teile des Systems schnell in Angriff nehmen konnte, mussten andere etwas mehr nachdenken und dokumentieren, bevor wir anfangen konnten.

Anforderungen in einem agilen Framework sammeln und niemand hat User Stories erwähnt? Eine User Story ist im Wesentlichen eine allgemeine Definition dessen, wozu die Software in der Lage sein sollte. In der Regel kann jedes Feedback oder jede Anfrage des Unternehmens oder des Endbenutzers als User Story geschrieben werden. ... Sie können sich Akzeptanzkriterien als funktionale Anforderungen vorstellen, die eine User Story unterstützen.

Diese Frage deutet darauf hin, was mit der agilen Bewegung schief gelaufen ist. Es ist keine Schuld der Person, die die Frage stellt; Ich falle die ganze Zeit in diese Falle, weil mich jahrelanges Unternehmensleben dazu ausgebildet hat.

Die Falle, von der ich spreche, ist der Gedanke, dass es eine vorgeschriebene und korrekte agile Art gibt, Dinge zu tun. Dies könnte daran liegen, dass die Leute denken, dass Agile existiert. Sie können nicht tun Agile mehr als Sie können tun Pragmatische.

Keine "Funktionsspezifikationen" oder was auch immer zu haben, klingt besorgniserregend, ist es aber möglicherweise nicht. Wie viele Details benötigen Sie, um zu beginnen? Sicherheit und Leistung sind die offensichtlichen, die von vornherein bekannt sind und sich durchgehend anwenden. Ist es ansonsten eine Options Pricing Engine oder eine Uhr-App?

Wird es eine kontinuierliche Veröffentlichung, Diskussion, Lernen, Zurückgehen und Ändern der Software geben? Bauen Sie Soft ware oder Hardware?

Entwickler, die in einem Wasserfallprozess arbeiten, werden häufig erst zu einem späteren Zeitpunkt involviert, was ein Problem darstellt. Wenn sie früher oder von Anfang an einbezogen werden, sind sie mit unklaren, undefinierten und halbherzigen Dingen vertraut, was langjährige Entwickler zu verärgern scheint, obwohl es tatsächlich Teil ihrer Aufgabe ist, Fragen zu stellen, wie z. B. "Was sind die?" funktionale Anforderungen für dieses Ding, das wir bauen werden? "

Beim Erkennen von Lücken im Plan geht es nicht darum, Fehler zu finden, sondern nur um Softwareentwicklung.

Aus diesem Grund liebe ich Guys Antwort.