On 11.04.2009, at 18:21, Roland Moriz wrote:
Klar, das Endprodukt zählt. Aber die Anforderungen müssen doch in
irgend einer, wenn auch kurzen und informellen Form, festgehalten
werden.
Dafür könnte Cucumber doch ein recht pragmatischer Weg sein wenn man
den Kunden mit ins Boot zieht. Ausserdem keine "toten Dokumente" die
keiner mehr liest sobald man loslegt.
Tote Dokumente sind immer ein grosses Problem, von grossen
Spezifikationen bin ich auch kein Fan. Die sind schon ueberholt, wenn
man ueberhaupt anfaengt Code zu schreiben. Von daher bevorzuge ich
Tools wie Pivotal Tracker, die das Story-Denken foerdern unabhaengig
vom Tool was letztenendes fuer Akeptanztests verwendet wird.
Hat man das intus, ist Schritt 2 der Push in Richtung Cucumber nur
natuerlich. Wenn man das hinkriegt, top, aber ich denke, ein gewisser
Gap zwischen Kunden-Szenarios und tatsaechlich notwendigen Szenarios
wird immer bestehen.
Wenn man ausschliessslich pro Stunde abrechnet, kann einem zwar eine
"Auf Zuruf"-Spezifikation zunächst einmal egal sein. Spätestens wenn
dann aber das Kundenbudget erschöpft und das Resultat nicht seinen
Wünschen entspricht, kommen die Probleme: Man ist den Kunden los und
trägt ggf. einen schlechten Ruf davon (oder imho schlimmer: "die
Technologie (Rails) war schuld")
Ich denke dass das aber auch ein Problem ist, wie man mit dem Kunden
die Dinge von Anfang an plant und angeht. Es ist einfach der
klassische Kampf zwischen time-boxed/iterativ und festen Anforderungen
bzw. End-to-end-Entwicklung in vorgegebenem Budget bzw. Zeitrahmen.
Es ist eher die Frage welche Argumente man seinen Kunden anbringt, um
eher Qualitaetsgetrieben zu arbeiten (und damit iterativ, was auch mit
festen Budgets gut vereinbar ist wenn man's richtig anstellt). Welche
Tools man dafuer verwendet, so meine Ansicht, sollte dem Kunden egal
sein. Ich persoenlich habe es noch nicht erlebt, dass es jemand auf
die Technologie schob. Die ist eh nie das Problem, aber das ist ein
ganz anderes Thema.
Wenn "wir" also den Anspruch haben technisch bessere Wege (TDD/BDD,
agil (Scrum, XP, usw)) zu gehen als bisher im Marktsegment üblich,
so sollten wir doch auch versuchen im Bereich der
Projektspezifikation mit unseren Kunden professionellere Wege zu
gehen? oder?
Wie bereits gesagt denke ich, dass das einfach unabhaengig von den
verwendeten Tools ist. Man wird nicht umhin kommen, Details aktiv und
detailliert mit dem Kunden durch zu gehen. Sprint-Meetings finde ich
dafuer ideal. Die dauern lange und sind ermuedend, aber dafuer ist
einfach das gemeinsame Ziel, die Details so tiefgehend wie noetig und
moeglich zu spezifizieren und in Storys zu packen, so dass am Ende
jedem klar sein sollte, was zu tun ist.
Selbst wenn man pro Stunde abrechnet, sollte man diesen Weg gehen, ich
nehm das Wort professionell nicht gern in den Mund, aber so oder so
waere es genau das, mit dem Kunden die Dinge vorher detailliert
durchzusprechen.
Ich denke einfach nicht, dass sich diese Probleme mit Tools loesen
lassen, sie koennen allerdings einen kleinen Teil dazu beitragen. Mag
bloed klingen, aber miteinander reden loest die Probleme noch am
besten, so offen wie moeglich und so oft wie noetig, gerade um oben
erwaehnte Gaps zu schliessen.
Ich bitte die philosophisch langen Ausfuehrungen zu entschuldigen. Das
sind einfach meine Erfahrungen mit dem Thema, wenn jemand andere hat,
ich lass mich gern eines besseren belehren.
Cheers, Mathias
--
http://paperplanes.de
http://twitter.com/roidrage
_______________________________________________
rubyonrails-ug mailing list
[email protected]
http://mailman.headflash.com/listinfo/rubyonrails-ug
