Fragen zu Scrum...

Nein, das is doch keine "User-story" oder? Ich dachte "user- stories" sind nur anforderungen aus sicht des users? nicht aus sicht des entwicklers!?

oder kann man das so sehen:

ein user will ne awendung die irgendwas kann( user story) ... und der entwickler definiert dann 1000 task umd au dieser story erst makl ein allg. konzeot zu entwickeln?

oder sind user-stories nicht nur anforderungen aus sicht des usser?

hustbaer

@NullBockException
Möchtest du wissen wie man das in der Realität macht (was dann auch Firmen inkludiert wo SCRUM nur so annäherungsweise Pi*Daumen umgesetzt wird), oder willst du wissen was die "reine" SCRUM Lehre dazu sagt?

Zum ersten könnte ich dir ein paar Sätze schreiben. Zum zweiten nicht.

Hey Hustbear..
ja ich werde evtl. in ne Firma wechseln die SCRUM verwendet um sofrware projekte umzusetzen.. und ich hab da kaum oder gar keine erfahrung drin, weil ich in denn bisherigen firmen sowas nicht wirklich angewendet wurde^^

Ich will nur bisschen vorbereitet sein

Lupo4u2

NullBockException schrieb:

oder sind user-stories nicht nur anforderungen aus sicht des user?

theoretisch hast du recht, praktisch hat das noch keine Firma konsequent durchgezogen in der ich beschäftigt war.
Das geht meistens auch gar nicht vernünftig, wenn man komplexe Produkte hat wo es unterschiedliche 'User' Gruppen gibt...
z.b. kann auch der Entwickler ein User sein und dann hast du eine Anforderung à la "Entwicklungsumgebung auf XYZ umstellen"...

Aus meiner Sicht, der des Testers, ist Scrum einfach nur schrott, wenn es nicht vernünftig gemacht wird... und bisher habe ich es noch nirgends vernünftig im Einsatz erlebt.
(Wurde aber bei den Firmen, bei denen ich damit zu tun hatte, auch gerade erst eingeführt)

Für einen Entwickler mag das ganz nett sein, weil er relativ frei arbeiten kann und 'User-Stories' so umsetzen kann, wie er es für richtig hält.
(Sofern der PO wenig technisches Wissen hat und keine konkreten Anforderungen stellt)
Aber mich nervt es, wenn ich keine konkreten Anforderungen für die Qualifizierung habe. ^(ja, leicht genervt right know)^

Von daher kannst du dich schlecht bis kaum vorbereiten. Du wirst sehen wie die Firma es umsetzt und dich dann anpassen.

rapso

Lupo4u2 schrieb:

Aus meiner Sicht, der des Testers, ist Scrum einfach nur schrott, wenn es nicht vernünftig gemacht wird...

wie wuerdest du denn in der perfekten situation seine anforderung in scrum umgesetzt sehen?

fuer mich war bisher validate dass entwickler auch user sind, da es implizite task dependencies gibt. wenn du jetzt sagst, dass es in der perfekten welt nicht so sein sollte, wueste ich nicht wie sein beispiel richtig aufgeloest wird. der "echte user" wird ja wohl kaum anfordern dass er ein technisches design konzept moechte.

Shade Of Mine

Eine User Story hat erstmal gar nichts mit den technischem Design zu tun.

"Ich will mich einloggen können"

ist zB eine User Story. Dazu gibt es dann die Anforderungen die notwendig sind:

Sprich: Login Dialog, Userverwaltung, User Authentifizierung

Und da geht man dann weiter durch: Was braucht man alles für "Login Dialog"? Texte, Grafiken, Design, Fenster Erstellen, das Programm muss gestartet werden. etc.

User Stories sind toll aber nur ein Teil der Arbeit.

Cpp_Junky

Ach in der Realität ist das doch eh 50/50 SCRUM/Extreme-Programming ^^

Lupo4u2

Das beispiel aus dem ursprünglichen Post könnte man so lösen:
User Story: der User kann drucken
Akzeptanz-kriterium:
- druck einzelner Seite möglich (task)
- druck mehrerer Seiten möglich (task)
- druck einer Auswahl möglich (task)
- etc...

Da man in diesem Fall aber jeden einzelnen task auch separat testen kann, könnten das genauso gut User-Stories sein...
weil: User Story == Requirement (in meiner perfekten Welt)
-----------------

Ich würde ein neues SCRUM Projekt, soweit möglich im vorhinein spezifizieren:
(Ich bin also jetzt der Product-Owner)
Ich habe ein Spezifikation geschrieben bzw. vom Kunden erhalten
Jeder Punkt in der Spezifikation wird zu einer User-Story.
Jede User-Story ist detailiert von mir beschrieben. (Funktionalität, Erwartungen, UI, etc)
Um das komplette Projekt zeitlich zu planen würde ich User-Stories für Meilensteine (oder Epics heisst es bei Scrum glaube ich) zusammenfassen.
Dann wird nach und nach jedes Epic abgearbeitet.

Sobald eine User-Story in einem Sprint geplant ist, ist sie fix.
Das heisst ein Tester kann ab diesen Zeitpunkt Tests basierend auf den Akzeptanzkriterien entwickeln um eben diese Story später zu validieren.

Bearbeitete Stories werden von meinem Tester validiert und geschlossen oder rejected wenn noch Fehler gefunden wurden.

Dieses Konzept funktioniert aber nur bedingt:
- wenn das Endprodukt nur aus meinem Produkt besteht und es somit keine Abhänbgigkeiten von anderen Scrum Teams gibt...
- Wenn ich als PO weiss was ich will und zudem technisches Verständnis habe.
- Wenn ich als PO konkrete Erwartungen an mein Produkt habe
- Wenn mein(e) Tester zuverlässig sind
- Wenn meine Entwickler korrdiniert werden. (Jemand muss das Team anführen)
- Wenn alles schriftlich gemacht wird.

Wie ich es bisher erlebt habe:
- PO hat keine Ahnung was er will
- beispiel User Storys:
- erstelle GUI XYZ (mit Eingabefeldern für x1,x2,x3 --> was mit den Daten später passiert überlegen wir uns noch)
- Datenverbindung schneller machen
- Workshop: ZYX
- User Story bearbeitet, vom PO abgenommen, dabei diverse Akzeptanzkriterien ignorieren.
Danach: testen - Akzeptanzkriterium nicht erfüllt - Fehlereintrag kommentarlos ablehnen
Begründung: das wurde schliesslich während der bearbeitung (intern, also ohne mich) mündlich besprochen, das wir es jetzt anders machen.
- während des Sprint fliegt Story X raus, dafür machen wir Story Z...
- task: 'refactoring' ist in fast jedem sprint drin...

P.S. Andere Verfahren funktionieren übrigens genauso wenig, wenn in der international agierenden Firma wie in einer Garagenfirma gearbeitet wird...

Tyrdal

Dein Idealfall klingt stark nach dem Wasserfallmodell ...

Lupo4u2 schrieb:

Wie ich es bisher erlebt habe:
- PO hat keine Ahnung was er will
- beispiel User Storys:
- erstelle GUI XYZ (mit Eingabefeldern für x1,x2,x3 --> was mit den Daten später passiert überlegen wir uns noch)
- Datenverbindung schneller machen
- Workshop: ZYX
- User Story bearbeitet, vom PO abgenommen, dabei diverse Akzeptanzkriterien ignorieren.
Danach: testen ...

Bei Scrum gibt es doch keinen Tester der nach dem Sprint das Feature prüft. Das Entwicklungsteam enthält den/die Tester und liefert beim Sprintende ein fertig getestetes Produkt ab.

NullBockException schrieb:

Wenn ich aber nun eine Software neu konzepiere, muss doch zuerst mal ein Design-Konzept also. der generelle Aufbau (technische Sicht) teilweiße implementierungs design bestehen, damit ich bspw. ne "User Story" => Der User soll drucken können! umsetzen kann oder?

Wie Scrum bei einer wirklich neuen Software funktionieren soll weiß ich auch nicht. Laut Theorie soll ja nach jedem Sprint eine funktionierende Software rausfallen. Wenn man nicht gerade eine 0815 (Web)Anwendung schreibt, bei der die Architektur durch das Framework schon vorgegeben ist und man per Knopfdruck eine Basisanwendung hat, halte ich es für unrealistisch, dass man in 2 oder 3 Wochen eine neue Architektur entwirft und auch noch grundlegend bis zu einer "fertigen" Software entwickelt, die man einem User vorführen und geben kann.