Story-Requirements – ein Gedankenspiel

Erstellt am 2 Oktober 2012
von Schreibe einen Kommentar

Spätestens seit sich die agile Softwareentwicklung als alltagstaugliche und in einigen Entwicklungsbereichen auch als alternative Vorgehensweise durchgesetzt hat, sind die User Stories fester Bestandteil der Entwicklung. Die Requirements sind aber als Entwicklungsartefakt nicht ausgestorben. So existieren in vielen Unternehmen beide Artefakte – User Story und Requirement – nebeneinander, quasi stellvertretend für die agile und die klassische Welt. Lassen Sie sich mit dem nun folgenden Gedankenspiel auf eine mögliche Verschmelzung dieser Artefakte ein.

Die Diskrepanz zwischen Anforderung und Implementierung

Erstellt am 25 September 2012
von Schreibe einen Kommentar
This entry is part 1 of 3 in the series Anforderung und Implementierung

Man kennt den klassischen Weg, Anforderungen zu spezifizieren: ein Spezifikationsdokument mit den Kundenanforderungen wird erstellt (oft “Lastenheft” genannt), dann ein Dokument, das die Umsetzung der Kundenanforderungen beschreibt (oft “Pflichtenheft” genannt).

Ist damit sichergestellt, dass die Implementierung korrekt sein wird?

Rollenkonflikte in agilen Umgebungen

Erstellt am 18 September 2012
von Schreibe einen Kommentar

Mit der Einführung von Scrum werden die Rollen Scrum Master, Product Owner und Entwicklungsteam neu eingeführt. Im Fokus dieses Beitrages steht der Product Owner. Der Product Owner ist verantwortlich für den Produkterfolg und für den Wert, den die Arbeit des Entwicklungsteams liefert (Scrum Guide). Der Product Owner tritt dem Entwicklungsteam als Kunde bzw. als Kundenstellvertreter (Kundenproxy) gegenüber. Er alleine entscheidet und verantwortet welche Anforderungen wann umgesetzt werden. Damit übernimmt er die Aufgaben des Anforderungsmanagers, des Produktmanagements, des Business Analysten oder des Projektleiter (entscheiden Sie bitte selbst, welche Rollen in Ihrem Unternehmen diese Aufgaben wahrnehmen). Die Anforderungen definiert der Product Owner selbst, gemeinsam mit dem Entwicklungsteam oder erhebt sie bei seinen Stakeholdern.

________ Retrospektive ________

Erstellt am 28 August 2012
von Schreibe einen Kommentar

Für Scrum bereit, das Board an der Wand, Cards die jeder mag.
Wertvoll die Zeit, das Heft in der Hand, Conversation jeden Tag.

Die Story ist klar? Der Sprint in Gang, die Tasks bleiben aber liegen.
Confirmation ist rar, dem Product Owner ist bang,
das Inkrement kann so keiner kriegen.

Das Desaster ist da, das Team ist frustriert, niemand will es begreifen.
Architekt denkt Hurra, weil Software nicht funktioniert
– die Organisation muss reifen!

Nichts hat sich verbessert, meint der Kunde sauer, warum will mich keiner verstehen?
Wissen verwässert, technische Schulden auf Dauer
 – ohne gutes RE, wird es auch agil nicht gehen.

Optimal und doch schlecht

Erstellt am 21 August 2012
von Schreibe einen Kommentar

„Vor 6 Monaten haben wir SCRUM eingeführt, uns Berater und Coaches ins Haus geholt und alle geben ihr Bestes. Und trotzdem sind wir nicht schneller in der Entwicklung geworden und die Qualität läßt immer noch zu wünschen übrig. Wie kann das sein?“

Da kann man nur eines mit Sicherheit sagen: SCRUM ist nicht schuld daran. Möglicherweise sind auch die Berater nicht schuld daran, auch wenn Einkäufer dazu tendieren, die billigsten Angebote anzunehmen. Hinter dem ausbleibenden Erfolg steckt typischerweise ein ganzes Bündel von Ursachen, zu denen die Angst vor Neuem, Missverständnisse, Ignoranz, ungenügende Information, Karrieredenken und Silo-Mentalität gehören. Ich möchte heute auf ein Problem näher eingehen, das in den genannten Ursachenkategorien verankert und überall anzutreffen ist. Wer Entscheidungen trifft, glaubt häufig, die bestmögliche Entscheidung zu treffen – aber sehr häufig ist dieses „bestmöglich“ nur das beste für diese Person selbst oder ihre Abteilung, nicht aber für die Gesamtorganisation. Es ist eine lokale Optimierung.

Agilität ist keine Ansichtssache

Erstellt am 19 Juni 2012
von Schreibe einen Kommentar

Wir sind mittlerweile recht gut darin, Informationen zu analysieren und zu verwalten (z.B. Anforderungen), komplexe Strukturen in einfachere Substrukturen herunterzubrechen etc., also darin, statische oder strukturelle Komplexität zu meistern. Warum tendieren dann „große“ Systeme (v.a. Softwaresysteme) dazu, immer „schlechter“ zu werden mit einem stetig anwachsenden Fehlerberg?

Agilität beginnt im Kopf

Erstellt am 15 Mai 2012
von Schreibe einen Kommentar

In der Softwareentwicklung will heute praktisch jeder agil sein. Das klingt modern und dynamisch. Liest man die Werte, die hinter dieser Idee stecken (agiles Manifest), versteht man leicht, warum.

  • Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
  • Funktionierende Software ist wichtiger als umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlung
  • Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans

Es liegt aber im Wesen des Menschen, Ideen (auch gute) falsch zu verstehen – manchmal auch absichtlich, um eigene Interessen zu verfolgen.

Mit Scrum mehr Meetings und Administration?

Erstellt am 1 Mai 2012
von Schreibe einen Kommentar

Befragt man Entwicklungsteams und andere Beteiligte im Unternehmen, was sich seit der Einführung von Scrum geändert hat, erhält man überraschend oft die Aussage: Wir haben jetzt noch mehr Meetings und mehr Aufwand für Administration. Das ist erstaunlich. Woher kommt dieser Eindruck? Sehen wir uns doch die Scrum Meetings (oder gemäß Scrum Guide die „Events“) einmal genauer an.

Agiles Spezifizieren: Just in Time für User Stories

Erstellt am 31 Januar 2012
von Schreibe einen Kommentar

Es ist mir schon fast unangenehm, das Wort agil nun auch in diesem Kontext zu verwenden. Jedoch halte ich es für notwendig, einen genaueren Blick darauf zu werfen, was bei der Spezifikation von Anforderungen in einem agilen Umfeld zu beachten ist. Zu oft sehe ich, dass nun statt umfangreichen Spezifikationen noch umfangreichere Mengen von umfangreichen User Stories entstehen.

Agiles Arbeiten bedeutet für alle Beteiligten – nicht nur für Requirements Engineers – an vielen Stellen ein Umdenken.

Akzeptanzkriterien für User Stories definieren – aber nur wie?

Erstellt am 6 Dezember 2011
von 1 Komment

Haben Sie sich auch schon mal gefragt, ob es eine Möglichkeit gibt, Akzeptanzkriterien mit Hilfe eines systematischen Vorgehens zu definieren? Oder wollen Sie eine Basis für Ihre Akzeptanztests schaffen, um festzustellen, ob Ihr System oder Ihre entwickelte Software den Kundenerwartungen entspricht?