Posts tagged ‘FDD’

XP-Days Germany 2010 in Hamburg

Die XP-Days Germany finden dieses Jahr vom 25.-27.11.2010 in Hamburg statt. Der Call for Sessions ist raus: http://www.xpdays.de/twiki/bin/view/XPDays2010/CallforSession

Wie schon in den letzten Jahren gibt es einen offenen Review-Prozess für die Einreichungen. In diesem kann jeder Feedback zu den Einreichungen geben und die Einreicher können auf Basis des Feedbacks ihre Einreichungen verbessern. Es lohnt sich also, seine Vorschläge sehr früh einzureichen. Iterativ können sie dann während des Review-Prozesses verbessert werden.

May 26, 2010 at 6:59 pm Leave a comment

Color Modeling

Color Modeling ist die Modellierungstechnik, die Feature-Driven-Development (FDD) vorschlägt – aber nicht verpflichtend macht. Aber auch außerhalb von FDD kann Color Modeling sehr nützlich sein. Ich habe es (in adaptierter Form) in Scrum/XP-Projekten eingesetzt.
Insgesamt finde ich, dass die Technik zu wenig bekannt ist und unterschätzt wird. Daher freut es mich, dass jetzt eine gute Erläuterung zu Color Modeling mit ein paar Erfahrungswerten aufgetaucht ist.

November 7, 2008 at 2:07 pm Leave a comment

Sind Aufwandsschätzungen Verschwendung?

Bei InfoQ findet sich ein interessanter Artikel, in dem die Frage diskutiert wird, ob Aufwandsschätzungen Verschwendung sind. Im Sinne des Lean Thinking sind Aufwandsschätzungen auf jeden Fall Verschwendung. Sie gehen schließlich nicht in die entwickelte Software ein.
Allerdings: Leider kann man nicht jede Verschwendung sofort beseitigen. Mitunter benötigt man die Verschwendung als Zwischenergebnis oder zur Kontrolle seines Projektes. Viele agile Projekte können daher bisher nicht auf die Verwendung “Aufwandsschätzung” verzichten. Das Unternehmen allokiert beispielsweise auf klassische Weise Budgets und muss daher Projektkosten prognostizieren. Oder man hat mit unsäglichen Festpreisverträgen zu tun. Oder man weiß nicht, wie man sonst vernünftig Projektfortschritt messen – also Release Burndown Charts zeichnen – kann. In diesem Sinne wäre es gefährlich, jetzt einfach auf Aufwandsschätzungen zu verzichten.
Allerdings zum Allerdings: Das Ziel bleibt trotzdem bestehen. Nur, weil wir im Moment nicht wissen, wie wir Verschwendung loswerden können, bedeutet es nicht, dass wir die Verschwendung für alle Zeit akzeptieren müssen. Wir müssen stattdessen kontinuierlich an dem Problem arbeiten und uns (häufig schrittweise) einer Lösung nähern.
Ein erster Schritt könnte darin liegen, alle Stories auf dieselbe Größe zu normieren. Das wird im InfoQ-Artikel auch vorgeschlagen, ist bei FDD schon länger gängige Praxis und hat sich auch in unseren Projekten bereits bewährt. Dann muss man nicht mehr schätzen und zusammenrechnen, sondern nur noch zählen.
Und dann kann man sich überlegen, wie man auch noch das Zählen einspart. Diese Einsparung liegt zunächst wahrscheinlich im Bereich von max. 1 Stunde / Woche je Team. Das ist nicht wirklich berauschend. Aber die Einsparung hätte erhebliche – postitive – Seiteneffekte, bzw. Voraussetzungen. Damit man nicht mehr schätzen und zählen muss, muss sich das Unternehmen wandeln weg von Kostenorientierung hin zur Nutzenorientierung. Bei nutzenorientierter Perspektive interessieren mich erstmal die Kosten nicht. Ich priorisiere – möglichst gleich große – Stories nach ihrem Geschäftswert. Wenn mein Bauchgefühl mir sagt, dass die noch übrig gebliebenen Stories weniger Geschäftswert schaffen als mein Team kontinuierlich kostet, ist das Projekt eben zuende. Fertig. So einfach könnte Softwareentwicklung sein und wenn man dem InfoQ-Artikel glauben schenken darf, ist sie das bei einigen Unternehmen auch.

August 13, 2008 at 5:34 pm Leave a comment

Können Anwender/Fachexperten modellieren?

Auf diese Frage hätte ich früher mit einem klaren “Nein” geantwortet. Inzwischen mehren sich aber deutlich die Anzeichen, dass sie mit entsprechender Unterstützung vielleicht doch viel mehr können, als zumindest ich früher dachte.

  • In Feature-Driven-Development sind die Fachexperten beim Color Modeling mind. sehr stark in die Erstellung fachlicher Klassenmodelle involviert.
  • Bei InfoQ ist ein Artikel erschienen, der beschreibt, wie die Fachexperten selbst mit Domain Driven Design fachliche Klassenmodelle erstellt haben, die die Entwickler dann auch genau so umgesetzt haben.

Der InfoQ-Artikel hat mir auch nochmal eine Situation in Erinnerung gerufen, die wir vor 2 oder 3 Jahren in einem Projekt hatten. Wir hatten zeitliche Ereignisse an Wasserzählern modelliert (Einbau, Wechselung, Eichung etc.). Es wurde irgendwann im Projekt klar, dass wir das Modell ändern müssen. Der Code war schwer verständlich und sträubte sich gegen Änderungen.

In der Diskussion über das Zielmodell haben sich zwei Fronten im Team gebildet, die sich auch nicht von selbst auflösten. (Dass die Fronten entstanden sind, halte ich heute für ein Sympton eines tieferliegenden gruppendynamischen Problems, aber das ist hier nicht das Thema.)
Wir haben ziemlich viel Zeit in die Diskussion gesteckt, ohne zu einem Ergebnis zu kommen. Irgendwann habe ich einen Fachexperten einfach mal die beiden Modelle skizziert und gefragt, ob er etwas beitragen kann. Konnte er. Er hat gesagt, dass beide Modelle nicht so gut passen und ein drittes skizziert. Dieses Modell leuchtete dem ganzen Team schnell ein und wir haben die Änderungen durchgeführt. Tatsächlich beseitigte das Modell des Fachexperten unsere Probleme im System.

August 1, 2008 at 4:15 pm Leave a comment

Grails-Anwendung: Team-Radar ist Live

In einem früheren Post habe ich von den positiven Erfahrungen geschrieben, die Sebastian und ich zusammen mit Grails gemacht haben. Jetzt ist die zugehörige Anwendung online: Das it-agile Team-Radar führt ein Mini-Assessment für die Einführung agiler Vorgehensweisen durch. Bisher unterstützt Team-Radar Scrum. Andere agile Methoden wie eXtreme Programming und Feature Driven Development sind in Planung.

March 17, 2008 at 2:48 pm 2 comments

Lastenheft vs. User Stories

Im Lastenheft beschreibt der Kunde, welche Aufgaben ein zu erstellendes Softwaresystem unterstützen muss. Anscheinend gewinnt es zur Zeit eine stärkere Bedeutung, insbesondere im Verhältnis zum Pflichtenheft – im Pflichtenheft beschreibt der Softwarehersteller, wie er die Software gestalten wird.

Diese höhere Bedeutung des Lastenheftes liegt vor allem an Kommunikationsproblemen zwischen Fachabteilungen und Softwareentwicklern. Die von den Softwareentwicklern geschriebenen Pflichtenhefte sind für Fachabteilungen größtenteils unverständlich und daher keine geeignete Basis für die Vereinbarung des zu entwickelnden Systems.

Genau dieses Kommunikationsproblem adressieren auch die agilen Methoden, aber mit anderen Mitteln als dem Lastenheft. Bei den agilen Methoden wird das statische Lastenheft quasi durch
einen Lastenheft-Generator ersetzt. Dieser Lastenhaft-Generator ist ein Mitarbeiter des Kundenund heißt ja nach gewählter Nomenklatur mal Kunde (XP) und mal Produktverantwortlicher (Scrum).
Dieser Produktverantwortliche hat die Aufgabe, jeweils soviele Anforderungen zu generieren, wie zur Zeit realisiert werden können. Er generiert das Lastenheft quasi während der Projektarbeit. Dabei wird auf persönliche Kommunikation zwischen Produktverantwortlichem und Entwicklern gesetzt, um Kommunikationsprobleme zu vermeiden.

Damit übertragen agile Vorgehensweisen die Prinzipien der Just-In-Time-Production auf die
Softwareentwicklung: Die Anforderungen sind genau in dem Moment definiert, in dem sie benötigt werden.

Die Vorteile dieser Vorgehensweise liegen auf der Hand: Es wird keine lange Vorlaufphase für
die Definition des Lastenhaftes benötigt. Man kann sofort mit der Softwareentwicklung beginnen, sobald der Bedarf entdeckt wurde. Der Produktverantwortliche kann auf veränderte Rahmenbedingungen sofort reagieren – er muss ja nicht massenhaft bereits definierte Anforderungen ändern. Die Kosten auf Kundenseite sinken, weil der Produktverantwortliche immer nur genau die Anforderungen definiert, die auch realisiert werden. Es wird kein Aufwand in die Definition von Anforderungen gesteckt, die dann doch nicht realisiert werden. Erste Versionen der Software kann der Produktverantwortliche begutachten, daraus lernen und die Generierung weiterer Anforderungen mit dem Gelernten abgleichen.

Allerdings ist diese agile Vorgehenweise nicht für alle Kunden sofort umsetzbar – genau so wenig, wie es der westlichen Industrie gelungen ist, Just-In-Time-Production vom einen Tag auf den nächsten umzusetzen. Die Problematik bei der agilen Softwareentwicklung liegt in der Rolle des Produktverantwortlichen. Es ist durchaus eine Herausforderung, die Anforderungen genau zeitgerecht (eben Just-In-Time) zu definieren. Generiert der Produktverantwortliche die Anforderungen zu langsam, hat das Entwicklerteam kostenpflichtigen Leerlauf oder muss mit undurchdachten Anforderungen arbeiten. Generiert der Produktverantwortliche die Anforderungen zu schnell, liegen sie auf Halde.
Je mehr Anforderungen auf Halde liegen, desto größer die Gefahr, dass ein Teil der Anforderungen gar nicht realisiert wird. In diesem Fall hat der Produktverantwortliche seine wertvolle Arbeitszeit umsonst investiert. Anforderungen auf Halde wären in der Nomenklatur der Just-In-Time-Production Verschwendung.

Die Definition und die Realisierung von Anforderungen im Fluss zu halten entspricht genau dem Flow-Gedanken aus dem Just-In-Time-Production. Die einzelnen Produktionseinheiten in eine Fabrik entsprechend einzustellen, heißt Production Leveling. Und genau diese Herausforderung besteht auch bei agilen Softwareprojekten.

Eine große Hürde ist dabei häufig die Organisationsstruktur des Kunden. Muss der Produktverantwortliche sehr viele Parteien einbeziehen, ohne dass es sehr klare Strukturen gibt, gleicht seine Aufgabe dem sprichwörtlichen Hüten von Flöhen. Es besteht ein hohes Risiko, dass ein ziemlich inkonsistentes System entsteht.

Tatsächlich mag in solchen Fällen das Lastenheft doch die bessere Variante sein. Das gilt
allerdings nur, wenn der Lastenheft-Autor auch ausreichend Zeit für all die Abstimmungen
zur Verfügung hat. Unter Zeitdruck erstellte Lastenhefte neigen zu undurchdachten Anforderungen. Da sie statisch festgeschrieben sind, ist der Kunde dann mit dem Lastenheft wiederum schlechter bedient als mit dem agilen Produktverantwortlichen.

Zwischen dem Produktverantwortlichen im Sinne von Scrum oder XP und dem klassischen Lastenheft gibt es aber auch Zwischenstufen. FDD liefert mit der vorgeschalteten gemeinsamen Modellierungsphase einen guten Ansatzpunkt. Das Projekt wird dabei in Abschnitte von maximal 6 Monaten unterteilt. Für jeweils einen solchen Abschnitt findet eine Upfront-Analyse/-Modellierung statt. Dadurch wird die Gefahr von Inkonsistenzen reduziert. Natürlich bezahlt man das, indem man nicht mehr so schnell auf neue Erkenntnisse reagieren kann, wie mit XP oder Scrum. Man ist aber immer noch schneller und leichtgewichtiger unterwegs als mit dem klassischen Lastenheft.

June 26, 2007 at 5:54 pm Leave a comment

FDD-Reisebericht: Features beschreiben und organisieren

Im Feature-Driven-Development werden feingranulare Features für Planung, Realisierung und Tracking verwendet. Dabei gilt, dass ein Feature maximal 2 Wochen Realisierungszeit benötigen darf. Meistens sind die Features aber viel kleiner (z.B. 1 Tag).

Interessant ist, dass FDD ein festes Beschreibungsschema für Features hat:

<Aktion> <Ergebnis> <Objekt>

So entsteht ein einfacher Satz wie “Berechne Summe der Auftragspositionen”.

Damit man in großen Projekten die Übersicht nicht verliert, werden Features zu Feature-Sets zusammengestellt. Dabei empfiehlt sich eine feste Richtlinie, wie Feature-Sets gebildet werden. FDD schlägt für Geschäftsanwendungen vor, Feature-Sets nach Geschäftstätigkeiten zu bilden, z.B. “Auftragsannahme”.

Hat man es mit sehr vielen Feature-Sets zu tun, werden diese wiederum in Major Feature-Sets gruppiert, wieder nach einer festen Richtlinie. FDD schlägt für Geschäftsanwendungen vor, Major Feature-Sets nach Geschäftsbereichen zu organisieren, z.B. “Einkauf”.

In meinem aktuellen Projekt haben wir die Anforderungen auf das FDD-Schema umgestellt und damit einige positive Erfahrungen gemacht:

  • Wir verwalten unsere Anforderungen in einem Issue-Tracker (Mantis). Der FDD-Satz bildet die Zusammenfassung der Anforderung. Dadurch sind i.d.R. die Zusammenfassungen in einer Übersichtsliste so aussagekräftig, dass man in Diskussionen die Details gar nicht mehr braucht. Früher sind wir mit der Übersichtsliste der Anforderungen und dem Ausdruck der Details zu jeder Anforderung in Abstimmungsmeetings gegangen. Heute haben wir nur noch die Übersichtsliste dabei. Es ist alles viel übersichtlicher geworden.
  • Durch die Feature-Beschreibungsform fällt leicht auf, wenn man versehentlich mehere Dinge in einer Anforderung zusammengeworfen hat. Man trennt Anforderungen eher auf und das Risiko sinkt, dass man was Wichtiges übersieht (versteckte Features).
  • Durch das Feature-Beschreibungsschema sind unsere Features kleiner geworden. Insbesondere haben wir keine Features mehr, die sehr groß sind. Das ist besonders wichtig, weil wir gerade die großen Anforderungen immer wieder gnadenlos unterschätzt haben.
  • Wenn Anwender / Kunden Anforderungen beschreiben, passen die Beschreibungen in der Regel nicht ins FDD-Schema und in den Details finden sich häufig auch mehrere Anforderungen. Wir formen die Anforderungen dann in die FDD-Form um.
  • Die Gruppierung in Feature-Sets ist für das Tracking mit Parking-Log-Diagrammen sehr nützlich. In Mantis setzen wir die Kategorien als Feature-Sets ein und verwenden als Richtlinie Feature-Set=Geschäftstätigkeit.
  • Major-Feature-Sets bilden wir in Mantis als eigene Projekte an.

June 15, 2007 at 8:04 am Leave a comment

Older Posts