Hallo Frank,
Pivo benutzen wir schon - eben von diesem Produktowner
vorgeschlagen :)
Soweit ich weiss gibt es auch sonst kein Lean-Management Tool ohne
moantliche Kosten ... oder?
wir haben auch mal mit dem pivotal-tracker rumgespielt, sind dann aber
irgendwann auf redmine umgestiegen. Nicht ganz so luxuriös in der
Planung wie pivotal, aber man hat alles unter einem Dach (Tickets,
Zeiterfassung, wiki, sourcecode (commits können/bei uns: müssen)
Tickets referenzieren usw. großes Plus ist die Konfigurierbarkeit. Ein
Manko ist die Planung/Schätzung - wir lösen das momentan mit etwas
unzuverlässigen Daumenregeln (kleine Meilensteine, ein Ticket
entspricht einem Function-Point und dann werden die Tickets
gezählt...) Aber das ganze ist ja rails, wenn einem was nicht passt,
kann man ein plugin schreiben oder es direkt hacken...
XPlanner(http://www.xplanner.org/) fällt mir noch ein, das sich noch
an den guten alten Story-Cards orientiert und ziemlich umfangreiche
Tools zur Planung, Schätzung und zum Tracking hat, aber etwas hässlich
war, als ich das letzte Mal reingeschaut habe (auch schon wieder ne
Weile her). Aber zumindest kann man es runterladen und selber
installieren (und wer will&keine Angst vor Java hat, kann es auch
hacken, ist Open Source)....
aber Features von solchen Tools scheinen mir gar nicht so überragend
wichtig zu sein: Auf längere Sicht ist wohl eher so, dass sich aus dem
riesigen Feature-Set nur ein zwei Kernaufgaben rauskristallisieren -
und für alles andere werden die Daten eh nicht gepflegt (benutzt
jemand wirklich mingle? in echt? Für länger? Und ohne Karteileichen zu
produzieren?)...
Ich habe tatsächlich inzwischen das Gefühl, das es besser ist, den
Kunden seine Wünsche "irgendwie" aufschreiben zu lassen anstatt ihn in
das Connextra Format zu pressen. Gerade die deutsche Variante klingt
sehr nach Mathe-Studium :)
Ich werde glaube ich alles unterhalb von Cucumber (Rspec, Screw.Unit,
TestUnit) lieber selber für mich abbilden, damit ich auch in sechs
Monaten noch ein Gutes Gefühl habe, wenn ich an das - dann ja schon
alte - Stück Software ran muss.
vor kurzem hab ich noch einen Vortrag über Cucumber gehört, in dem der
Vortragende sagte, er hätte seinen Kunden dazu gebracht die specs zu
schreiben. Ich halte das noch immer für ein schönes Märchen....
Wichtig scheinen mir die Sichtbarkeit und die Verbindlichkeit zu sein,
aber dass eine Kunde wirklich die features schreibt, scheint mir da
doch eher die Ausnahme zu sein: Die einfachen Beispiele sind zwar
nachvollziehbar, aber am Ende dann doch nicht realistisch und ein ein
Real-World-Szenario so zu schreiben, dass es robust ist und die
Anforderung allgemein genug beschreibt, finde ich immer noch nicht
trivial - und einem Kunden zu erklären, warum das so und das andere
anders beschrieben werden soll, je nachdem, wie es implementiert ist,
halte ich eh nicht für realistisch.
Ich bin da meistens schon froh, wenn ich den Kunden irgendwie
einbeziehen kann, und sei es nur mit der ganzen einfach Anforderung:
Schreib ein Ticket. Freiform ist gut. Ich weiß nicht, wie eure
Erfahrungen sind, aber bei uns arbeiten die Leute eher mit, wenn man
sie nicht zu sehr in ein Korsett zwängt: Wir haben mal mit vielen
Feldern auf einem Feature-Ticket angefangen (wenn sich noch jemand an
die Use-Case-Templates von Alistair Coburn erinnert, dann habt ihr ne
ungefähre Vorstellung, wie sehr man sich da austoben kann) - aber das
meiste davon wurde nie benutzt. Schade und unsauber und
unterspezifiziert, ja - aber so ist die Realität. Simple is beautiful
und mittlerweile frage ich dann einfach gezielt nach und schreibe ggfs
einen Kommentar in das Ticket, aber den Kunden mit so was zu
befrachten halte ich für ziemlich aussichtslos. Je einfacher die
Werkzeuge sind, desto mehr steigt die Wahrscheinlichkeit, dass sie
auch nach der ersten Demo und dem Verfliegen der Anfangseuphorie noch
benutzt werden...
Zusamengefasst: Je simpler die Tools sind, desto besser. Hauptsache,
alles wird *irgendwie* erfasst und das sauber strukturierte BDD-Land
fängt bei uns erst hinter dem Zaun an, über das der Kunde nur seine
Tickets wirft...
Soviel zu meinen 2ct - mich würde auch interessieren, wie ihr die BDD-
Ansätze in der Praxis durchzieht und wieviel oder wie wenig Tool ihr
dabei einsetzt....
Viele Grüße&ein schönes Rails-Jahr
Stefan
----
stefan frank
vierundsechzig.de
software&service
weberstr. 10
69120 heidelberg
tel. +49 (0) 6221 7277049
mobil +40 (0) 173 2383390
mail s.fr...@vierundsechzig.de
www.vierundsechzig.de
_______________________________________________
rubyonrails-ug mailing list
rubyonrails-ug@headflash.com
http://mailman.headflash.com/listinfo/rubyonrails-ug
