Cucumber im wahren Leben? (Umfrage)

Community DE
1

Hallo,

nutzt von Euch im Kundenprojekt jemand Cucumber und hat es dabei auch
geschafft, dass sein Kunde die Features selbst schreibt?

Oder alternativ der Kunde die Features korrekturliest + versteht +
absegnent? Formuliert Ihr/Eurer Kunde dabei in Englisch oder Deutsch[1]?

(reine Neugier…)

Grüße & frohe Ostern,
Roland

[1] http://tinyurl.com/c2gfjp

–
Moriz GmbH
Hedwig-Dransfeld-Allee 14
80637 München

Tel: 089/78795079 (AB)

Vertretungsberechtigter
Geschäftsführer:
Roland M.

Registergericht: Amtsgericht München
Registernummer: HRB 174 294
USt-ID: DE260422784

2

2009/4/11 Roland M. [email protected]:

Hallo,

nutzt von Euch im Kundenprojekt jemand Cucumber und hat es dabei auch
geschafft, dass sein Kunde die Features selbst schreibt?

Oder alternativ der Kunde die Features korrekturliest + versteht +
absegnent? Formuliert Ihr/Eurer Kunde dabei in Englisch oder Deutsch[1]?

Ich erwarte es nicht, dass der Kunde die Specs selbst schreibt, und
halte es auch nach wie vor fuer eine Illusion, dass dies jemals
effektiv funktionieren wird. Tests sind fuer mich auch mit Cucumber
noch Entwicklersache. Es hat mit FIT und Fitnesse nicht funktioniert,
und wird auch trotz der Einfachheit von Cucumber Entwicklersache
bleiben.

Ich schliesse es nicht aus, dass man dem Kunden angewoehnt, seine
Spezifikationen schon so nah wie moeglich am Feature-Style zu halten,
aber es wird da meistens immer noch einen Gap geben, den man selbst
fuellen muss.

Absegnung durch den Kunden ist wiederum eine andere Sache. Schoen
lesbar und, so gut geschrieben, auch nachvollziehbar. Allerdings ist
von Kundenseite immer eher das Endprodukt interessant, was eben den
kompletten Auftritt inkl. Web-Oberflaeche beinhaltet.

Ich schreibe grundsaetzlich meine Features auf English, bin da aber
auch leidenschaftslos. Wenn nun ein Kunde daher kommt und sie gern auf
Deutsch oder LOLcatz haben will, soll’s mir auch recht sein.

So sieht’s da bei mir aus. Ich find das alles auch nicht schlimm,
Testen mit Cucumber macht einfach Laune.

YMMV.

Cheers, Mathias

3

Hallo Mathias,

Mathias Meyer schrieb:

Oder alternativ der Kunde die Features korrekturliest + versteht +
absegnent? Formuliert Ihr/Eurer Kunde dabei in Englisch oder Deutsch[1]?
…

Allerdings ist
von Kundenseite immer eher das Endprodukt interessant, was eben den
kompletten Auftritt inkl. Web-Oberflaeche beinhaltet.

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.

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”)

Typische negative Extrembeispiele die ich in den letzten Jahren in
meinem Umfeld beobachten durfte:

Aus Entwicklersicht:

“Kunde weiss nicht was er will”
“Kunde will immer weitere Änderungen”
“Kunde nervt total, hat keine Ahnung”
“Kunde will nicht bezahlen / hat kein Geld”
“Kunde hält mich hin”
“Ich ignoriere meinen Ex-Kunden und habe die Zeit abgeschrieben”

Aus Kundensicht:

“Freelancer braucht so lange / ist so teuer”
“Freelancer versteht das Problem nicht”
“Freelancer denkt nicht mit”
“Freelancer ist unzuverlässig”
“Freelancer fragt wiederholt Fragen anstatt zu programmieren”
“Wir suchen einen richtig guten Experten, weil der davor zu schlecht
war”

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?

unrealistisch?

Hashrocket/Obie sind da wohl recht aktiv dabei. Aus .de sind mir
ähnliche Beispiele bis jetzt nicht bekannt - deshalb meine Fragen.

Grüße,Roland

4

Mathias Meyer schrieb:

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

…das klassische billig/schnell/pfuschig (“Lo-Fi”) gegen
qualitativ/nachhaltig/preiswert (“Hi-Fi”) oder was man dafür hält.

Manchmal habe ich den Eindruck, dass wir mit Rails in Deutschland
irgendwo zwischen PHP- (oft ein Bsp. für “Lo-Fi”) und J2EE-Projekten
(für “Hi-Fi”) verloren gehen weil der Qualitätsanspruch bei
Webanwendungen in .de - imho, ymmv! - nicht besonders hoch zu sein
scheint. Großkonzerne und Bestandsprojekte mit Tiefgang einmal
ausgenommen.

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?

…

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.

Das stimmt und gehört dazu, hat den Nachteil (falls ausschliesslich nur
geredet wird) das einer das Besprochene zu Papier/Datei bringen und
abzeichnen lassen muss falls es die andere Seite später “vergessen”
sollte bzw. für Teammitglieder die nicht dabei sein können.

Dieser Aufwand bleibt üblicherweise beim Dienstleister hängen und ist im
“Kleinkundensegment” oft schwer bis überhaupt nicht abzurechnen.

Manchmal bekomme ich von Personen (oft mit namhaften IT/Startup
Hintergrund) Anfragen ala “Was verlangt Ihr um xy.com nachzubauen?”. Das
ist auch bei einer Nachfrage die einzige “Spezifikation” die die Person
hat und darauf von mir eine sinnvolle Antwort bzw ein detailliertes
Angebot haben möchte.

Da fällt es mir ernsthaft schwer eine Antwort zu verfassen.

Geht man also bei so einer Anfrage davon aus, dass der Kunde einem nicht
für das Ausarbeiten einer Spezfikation bezahlen kann/möchte, so könnte
man Ihm zumindest sagen “spezifiere es möglichst in diesem
cucumber-format - und melde Dich dann damit noch einmal”.

Die vielleicht 10% die das dann wirklich machen werden Kunden weil sie
ernsthaftes Interesse haben. Vielleicht bin ich da auch naiv und solche
Anfragen sind zu 100% “Junk”.

Im Übrigen mag ich den Pivotal Tracker intern auch sehr, allerdings
nehme ich an, dass Kunden mit so einer Anwendung bei der
Initialspezifikation mehr “Probleme” haben, als mit simplen Textdateien
(Auch wenn der Vergleich beider dramatisch hinkt, ich weiss).

Ich bitte die philosophisch langen Ausfuehrungen zu entschuldigen.

Im Gegenteil - ich finde es prima sich auch über solche Dinge
unterhalten zu können. International (ok, USA-lastig) gibt es dafür eine
rails-business Mailingliste auf Google - vielleicht wäre sowas auch
für uns in .de sinnvoll?

Grüße,Roland

5

On 11.04.2009, at 18:21, Roland M. 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://twitter.com/roidrage

6

On 11.04.2009, at 20:15, Roland M. wrote:

Ich hab da unterschiedliche Erfahrungen gemacht. Egal wie, mein
Qualitaetsanspruch ist hoch, und das ist eine meiner
Grundvoraussetzungen fuer ein Projekt. Die Frage nach Testing
existiert fuer mich einfach nicht, und diesen Spirit versuche ich auch
weiter zu vermitteln.

Ich kann deinen Eindruck persoenlich nicht wirklich bestaetigen, und
ich will auch keine Seitenhiebe auf PHP und J2EE von mir lassen, ich
hab beides selber bis zum Umfallen gemacht, und in beiden Leuten der
lo-fi und hi-fi Schlages getroffen. Das ist einfach unabhaengig von
Sprache und Tools. So fremd mir PHP mittlerweile ist, so ordentlich
wird es dennoch eingesetzt bei riesigen Seiten (Flickr z.B.)

Das stimmt und gehört dazu, hat den Nachteil (falls ausschliesslich
nur geredet wird) das einer das Besprochene zu Papier/Datei bringen
und abzeichnen lassen muss falls es die andere Seite später
“vergessen” sollte bzw. für Teammitglieder die nicht dabei sein
können.

Dieser Aufwand bleibt üblicherweise beim Dienstleister hängen und
ist im “Kleinkundensegment” oft schwer bis überhaupt nicht
abzurechnen.

Versteh ich gut, und hier ist halt Vertrauen eine Sache, und eben
ausreichende Ausfuehrung fuer Vertragsgeschichten die andere. Es
bedarf keiner ausgiebigen Ausfuehrung von Features um gemeinsam zum
Ziel zu kommen, ich baue dabei immer darauf, dass beide Seiten mit
Vernunft zum Ziel kommen wollen. Hat bisher auch immer funktioniert.

Konstanter Kontakt und Ruecksprache bzw. regelmaessige Demos helfen
hier ungemein bei Risikominimierung fuer beide Seiten.

so könnte man Ihm zumindest sagen “spezifiere es möglichst in diesem
cucumber-format - und melde Dich dann damit noch einmal”.

Es waere schon beinahe unverantwortlich hier ohne weitere
Ausfuehrungen eine Antwort zu geben, und ich bin da voll on par mit
der Herangehensweise entweder zuerst um detailliertere Ausfuehrungen
von Features zu bitten, oder mit dem Kunden zusammen diese zu
entwickeln. Klar ist letzteres auch eine finanzielle Frage, aber so
oder so mache ich keine Angebote ohne konkrete Vorstellungen, auf die
ich meine Abschaetzungen aufbauen kann.

In meiner Erfahrung hilft es den Kunden in die richtigen Richtungen zu
stossen, und unterstuetzend zur Seite zu stehen, ob Cucumber oder
nicht. Wenn er keine Idee hat, wie man Storys definiert, hilft man ihm
eben dabei.

Es ist ein Zwiespalt, gerade im Kleinkundensegment, aber hier muss man
Kompromisse finden. Dem Kunden kann man z.B. klar machen, dass man mit
einer gut formulierten Listen von Storys wesentlich effektiver zum
Ziel kommt, auch wenn der Anfangsaufwand vielleicht etwas groesser ist.

Die vielleicht 10% die das dann wirklich machen werden Kunden weil
sie ernsthaftes Interesse haben. Vielleicht bin ich da auch naiv und
solche Anfragen sind zu 100% “Junk”.

Ich habe aehnliche Anfragen auch schon erlebt, aus denen dann auch
tatsaechliche Projekte geworden sind, allerdings erst nachdem die
Details genauer mit dem Kunden erarbeitet wurden.

Im Übrigen mag ich den Pivotal Tracker intern auch sehr, allerdings
nehme ich an, dass Kunden mit so einer Anwendung bei der
Initialspezifikation mehr “Probleme” haben, als mit simplen
Textdateien (Auch wenn der Vergleich beider dramatisch hinkt, ich
weiss).

Hier ist wiederum die Frage der gemeinsamen Verwendung. Wenn man
zusammen mit dem Kunden von Anfang an auf sowas wie Pivotal Tracker
setzt (ich find auch Karteikarten super, aber je nach Entfernung zum
Kunden macht sich eine einfache Online-Loesung schon ganz gut), dann
gewoehnt auch der sich dran. Alles ein Idealfall, aber ist eine Sache
der gemeinsamen Eingewoehnung. Einfach vorwerfen sollte man ihm das
Tool sicher nicht, sondern eher gemeinsam die Verwendung zusammen mit
den Storys erarbeiten.

Im Gegenteil - ich finde es prima sich auch über solche Dinge
unterhalten zu können. International (ok, USA-lastig) gibt es dafür
eine rails-business Mailingliste auf Google - vielleicht wäre sowas
auch für uns in .de sinnvoll?

Ich denke das hier passt schon als Medium. Werden ja nicht allzu viele
Diskussionen dieser Art bis dato abgehalten, wobei ich natuerlich neue
Medien fuer neue Diskussionen immer begruesse.

Cheers, Mathias

http://twitter.com/roidrage