Ist der Mangel an funktionalen Anforderungen agil?

10

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?

Landeeyo
quelle
1
Wird das alte System verwendet, bis das neue System es ersetzt, oder werden beide Systeme gleichzeitig verwendet, wobei das neue System nach und nach die Funktionen des alten Systems ersetzt?
Greg Burghardt
1
@ GregBurghardt zweite Option
Landeeyo
1
Was plant Ihr Team zu tun? Wirst du sie sammeln, mit Geschäftsleuten sprechen usw.?
Filip Milovanović
2
Denken Sie auch daran, dass Sie nur zwei der drei Einschränkungen beheben können: Zeit, Aufwand und Umfang. Wenn die Zeit festgelegt ist (wie Sie in Ihrem Kommentar gesagt haben) und der Aufwand festgelegt oder zumindest begrenzt ist (ist Ihr Chef bereit, unendliche Entwickler einzustellen?), Ist keiner der beiden Bereiche festgelegt, und Sie sollten in der festgelegten Zeit tun, was Sie können das Sie haben (das ist, was Scrum mit Sprints macht), oder Sie sollten Fehler akzeptieren und
weitermachen
3
Ich würde das eigentlich als zerbrechlich bezeichnen.
Mason Wheeler

Antworten:

21

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
Greg Burghardt
quelle
Tolle Antwort, Greg. Sehr vernünftige, professionelle Sichtweise. Leider gibt es einige Details, die die Situation noch verschlimmern - die Frist für einen Teil des Systems ist aufgrund externer Anforderungen festgelegt. Wie auch immer, als allgemeine Richtlinie ist es ein guter Rat.
Landeeyo
6
@ Landeyo: Das ist eine schwierige Situation, wenn man eine vernichtende Frist hat. Umso wichtiger ist es, zu kommunizieren, dass mangelnde Anforderungen dazu führen, dass Sie die Frist verpassen. Das Risiko, die Frist nicht einzuhalten, könnte der Treibstoff sein, der benötigt wird, um Ihnen das zu bieten, was Ihr Team benötigt.
Greg Burghardt
1
Obligatorischer Dilbert
Mason Wheeler
Diese Geschichte wird seltsamer, als ob die Hälfte davon erfunden wäre. In der Softwareentwicklung gibt es keine festgelegten Fristen. Die Frist ist an dem Punkt, an dem der Finanzier des Projekts ungeduldig wird und das Vertrauen in ein gutes Ergebnis verliert. Dann wird der Stecker gezogen und dieser Moment ist nie im Voraus bekannt. Agil zu sein bedeutet, dass Sie sicherstellen, dass dieser Moment eher früher als später kommt, und dem Finanzier viel Geld sparen, was als schnelles Scheitern bekannt ist.
Martin Maat
16

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.

Karl Bielefeldt
quelle
1
Man könnte sicherlich argumentieren, dass diese Art von Situation perfekt für Agilität geeignet ist. Sie haben ein schwach verstandenes System, das Sie ersetzen möchten. Verstehen Sie also ein kleines Bit (Akzeptanzkriterien), erstellen Sie dieses kleine Bit (Sprint) und erhalten Sie Feedback (Demo). Aufschäumen, ausspülen, wiederholen.
Bryan Oakley
4

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.

amon
quelle
1

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.

Guy Schalnat
quelle
0

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.

Mark R.
quelle
0

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.

Luke Puplett
quelle