Neulich ging es ja hoch her in den Kommentaren zu meinem Schätz-Beitrag. Deshalb hier eine Aufgabe, anhand der ich ein wenig Licht auf mein Vorgehen beim Umgang mit Anforderungen werfen möchte. Die Aufgabe stammt von einem Entwickler aus einer Email-Kommunikation rund um das Schätzen:
Der Kunde stellt Kaffeemaschinen her, deren Komponenten der Besteller individuell zusammenstellen kann. Auf Grund eines Lieferantenwechsels muss ein Teil (z.B. die Tassenheizplatte) durch ein leicht modifiziertes anderes Teil ersetzt werden. Ob das Teil verbaut ist, hängt von der konkreten Bestellung ab.
Der Kunde benötigt nun eine Software, mit der er zu jeder Zeit feststellen kann, bis zu welcher Bestellung sein Lagerbestand des alten Teils noch reicht und ab welcher das neue verbaut werden muss.
Außerdem sagt der Kunde: Die Bestellungen bekommt man aus dem System XY- DB, Tabelle soundso, die Information welche Teile bei welchen Komponenten verbaut werden, kann man in der Applikation soundso nachsehen (z.B. bei einem SOA-Service oder einem Mainframe).
Und nun kommt ihr :-) Wer mag, überlegt mal, wie er die Anforderungen umsetzen würde. Dabei geht es nicht um die Implementation (“Wie kann ich mit .NET auf einen Mainframe zugreifen?”), sondern um die Planung(sschritte) und die Interaktion mit dem Kunden. Wann sieht der Kunde welche Funktionalität?
Welche Phasen würdet ihr durchlaufen? Wie käme Schätzen ins Spiel? Wann wäre Auslieferung?
Klar, die Anforderungen sind sehr allgemein; deshalb können eure Überlegungen auch nur sehr pauschal sein. Dennoch könnt ihr etwas draus machen und hier vielleicht in Kommentaren skizzieren, wie das aussähe. Ich stelle dann in den nächsten Tagen meinen Ansatz vor.
3 Kommentare:
Da noch niemand reagiert hat, mache ich mal den Anfang:
Um ehrlich zu sein, erster Schritt wäre, den Kunden zu bitten, mir das Problem noch mal genauer zu schildern, das hab ich nämlich nicht verstanden, beziehungsweise es gibt ein paar Unklarheiten, mir ist das zu durcheinander formuliert.
Meine spontane Antwort wäre: Wenn Teil x durch x1 ersetzt wird, dann genügt mein Bestand von x für so viele Aufträge, wie von x noch vorhanden ist (wenn für jeden Auftrag jeweils ein x gebraucht wird).
Also: Noch 27 x da, dann reicht das noch für 27 Aufträge, danach brauche ich x1.
Aber so simpel wird's ja wohl nicht sein ;-).
Ich habe das Problem also offensichtlich noch nicht verstanden. Aber bevor ich das nicht habe, kann ich nicht sinnvoll schätzen oder gar sagen, was ich in welcher Reihenfolge liefern würde.
Insofern die Bitte um nochmalige, etwas ausführlichere Erklärung ;-).
@Golo: Netter Versuch, nicht mit einer Beschreibung deiner Schritte beginnen zu müssen ;-) Aber tu es trotz deiner Unsicherheit mal. Sie über die Lücken hinweg. Ich tue es auch. Es wird keine Verfeinerung der Anforderungen geben. Friss sie - oder lass es.
Ich bin überzeugt, man kann hier sehr wohl auf allgemeinem Niveau Schritte aufzeigen. Das werde ich auch tun.
Zweiteilige Antwort:
a) In einem "Real-World-Szenario" würde ich es an genau der Stelle lassen. Wenn der Kunde nicht bereit ist, mir die Anforderung so zu erklären, dass ich sie verstehe, kann ich nur raten, was er will - und das will ich nicht, weil ein positives Ergebnis dann bestenfalls ein Glücksfall ist. Dazu müssen nicht alle Details vorliegen, aber ich muss das Grundproblem verstanden haben.
b) Wenn ich darüber mal hinwegsehe (was ich wohlgemerkt nur deshalb mache, weil es rein fiktiv ist und als Beispiel dienen soll), dann wäre mein Vorgehen auf Basis der genannten unscharfen Anforderungen ungefähr folgendes:
- Rollen identifizieren (Kunde, Entwicklung, Materialplaner, ...)
- Wissen identifizieren (Welche Rolle weiß was worüber, welche Resourcen speichern Wissen)
- Bedürfnisse identifizieren (Welche Rolle will welches Ziel erreichen)
Auf dieser Basis kann ich dann Stories schreiben, welche Rolle welches Ziel erreichen will, und an wen oder was sie dazu herantreten muss. Anders formuliert:
- Gewünschte Stories identifizieren (WER will WAS, WOZU)
- Akzeptanzkriterien und Testfälle definieren
Diese Aktionen müssen so weit aufgesplittet werden, dass sie unabhängig voneinander sind, testbar, dass ihre Umsetzung klar messbar ist an Hand der Akzeptanzkriterien, und sie müssen jeweils einen Wert für den Auftraggeber darstellen - es gibt also kein rein technisch motiviertes Feature.
Als nächstes ist die Frage, welches Abrechnungsmodell vereinbart wurde. Wird ein Fixpreis oder eine Fixzeit verlangt, muss ich zunächst schätzen, um sagen zu können, ob ich das gewünschte in der Zeit und zu dem Preis liefern kann. Wird nur Fixscope verlangt, muss ich nicht zwingend schätzen, da dann einfach gilt: "It's done when it's done". Natürlich kann ich dann trotzdem schätzen, wenn der Auftraggeber denn gerne mal zwischendurch eine Abschätzung hätte, ich muss es aber nicht vorher durchführen.
Als nächstes:
- Stories mit dem Auftraggeber besprechen
- Auftraggeber priorisiert
Dann geht die "eigentliche" Arbeit los, sprich, die Implementierung (wobei ich mit "Implementierung" nicht nur das reine Codieren meine, sondern auch Architektur, Planung, UI-Entwürfe, Tests, ...).
Während ich an einer Story arbeite, kann der Auftraggeber die übrigen nach Belieben umpriorisieren - nur die eine, an der ich gerade arbeite, die ist fix und wird durchgezogen (und nicht mittendrin abgebrochen).
Zu Deinen Fragen:
- Wann sieht der Kunde welche Funktionalität: Das kann er selbst entscheiden, indem er entsprechend priorisiert, was ihm am wichtigsten ist (wie er das macht, ob er nach Business Value, nach Risiko, oder nach sonstwas geht, ist mir dabei egal).
- Welche Phasen würde ich durchlaufen: Grob gesagt - Rollen identifizieren / Resourcen identifizieren / Bedürfnisse identifizieren / Stories schreiben / Akzeptanzkriterien und Tests schreiben / (Schätzen) / Stories priorisieren lassen / Iterativ umsetzen
- Wann wäre Auslieferung: Wenn der Kunde sagt, dass er ausliefern will. Nach jeder Story muss ein auslieferbares Produktinkrement vorliegen. Stichwort Continuous Deployment.
So, ich hoffe mal, dass ich nichts vergessen habe, aber ungefähr so würde mein Vorgehen aussehen.
Kommentar veröffentlichen
Hinweis: Nur ein Mitglied dieses Blogs kann Kommentare posten.