Story Splitting Revisited

Erstellt am 23 Juli 2013
von Schreibe einen Kommentar

Vor kurzem habe ich an dieser Stelle das Story Splitting Flowchart von Richard Lawrence vorgestellt, eine gute, praktische Hilfe zum Schneiden von Use Stories. Heute möchte ich die darin enthaltenen Pattern um zwei weitere ergänzen, die sich schon in mehreren Projekten als sehr hilfreich erwiesen haben.

Warum ist es so schwer, ein Scrum-Team zu bilden?

Erstellt am 25 Juni 2013
von 2 Kommentare

Eine typische Organisationsform für System- und Softwareentwicklung sind Komponenten-Teams. Entwickler werden um Komponenten herum gruppiert, es gibt ein Team für Komponente X und eines für Komponente Y; dann gibt es auch oft Spezialteams wie ein GUI-Team oder ein Test-Team. Eine andere weitverbreitete Organisationsform ist die Einteilung in Silos, Pools oder Services entlang der Disziplinen, also…

Slice it nice

Erstellt am 2 April 2013
von Schreibe einen Kommentar

Wer sich schon einmal mit der Frage herumgeschlagen hat, wie man User Stories sinnvoll schneiden kann, kennt meist auch das Story Splitting Cheat Sheet von Humanizing Work. Kennen Sie auch den Story Splitting Flowchart von Richard Lawrence? Zu finden unter: http://www.richardlawrence.info/splitting-user-stories/ Für die praktische Arbeit sehr brauchbar. Probieren Sie es aus!

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.…

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…

Anforderungen und Design Patterns

Erstellt am 8 Mai 2012
von Schreibe einen Kommentar

Es ist mittlerweile unbestritten, dass Modellierung ein fester Bestandteil des Repertoires eines Anforderungsexperten sein sollte. Software-Designer arbeiten vorwiegend mit Modellen. Ihr Verhältnis zu Anforderungen ist nicht immer ungetrübt und die Zusammenarbeit von Anforderungsexperten und Designern damit nicht immer leicht.

Reif, reifer, aber nicht überreif – Teil 2

Erstellt am 14 Februar 2012
von Schreibe einen Kommentar
This entry is part 2 of 2 in the series HOOD Capability Model

Dies ist der zweite Beitrag einer Blogserie, die sich dem HOOD Capability Model (HCM) widmet. Andere Modelle, wie CMMI® oder SPICE®, haben zwar unsere Fähigkeiten verbessert, Systeme aus Anforderungen zu entwickeln, nicht aber unsere Fähigkeiten, Anforderungen aus Kunden zu entwickeln (siehe Teil 1 – Informationsmodell: welche WARUM-Anforderungen gibt es und wie leite ich die WAS-Anforderungen…