Agile Softwareentwicklung und (Bugfixing)Änderungswesen

[fastjack]

Ich wollte diejenigen mal was fragen, die schon seit längerem agile Softwareentwiklung "leben". Wie läuft das mit dem Änderungswesen und Bugfixing innerhalt einer Iteration?

Bei uns läuft das folgendermaßen:
Die Iteration geht über zwei Wochen. Es werden Zettel mit Aufgaben zu Userstories erstellt, Zeiten gepokert etc. Aufgaben werden gestrichen oder verschoben, wenn der Zeitrahmen nicht ausreicht.
Nach zwei Wochen sind alle Zettel verarbeitet und eine Art Release wird erzeugt. Zwischendurch wird natürlich auch getestet, meistens von den Enwicklern selbst. Das Release wird von anderen Personen als den Entwicklern getestet.
Dabei können Änderungswünsche entstehen, Bugs auftauchen oder auch Ideen zu völlig neuen Sachen aufkommen.
Bisweilen war das so, das alles auf einer Art Liste zusammengefaßt wurde und "zwischendurch" abgearbeitet werden sollte. Zwischendurch darum, weil ja schon jetzt die nächste Iteration beginnt, also neue Zettel erstellt werden, neu gepokert wird usw.
Als Entwickler hat man nun neue Zettel + Änderungsliste + Bugliste + "neue Ideen"-Liste zu verarbeiten. Das kommt mir ein wenig spanisch vor, ich bin aber auch kein Experte für agile Entwicklung.

Wie macht man das bei Euch?

 

[bygones]

der entwickler sollte keine Aenderungsliste + bugliste + neue Ideen vor sich haben die er dann mal so miteinarbeitet.

Der sprint master und der Product owner entscheiden was in welchen sprint rein soll. tauchen in einer iteration neue Sachen auf so werden diese protokolliert und beim meeting angesprochen. Wenn dann entschieden wird dass dies zu tun ist wird auch entschieden wann.
Kommt ein Blocker ins Spiel so muss entschieden werden was von den anderen "Zetteln" dafuer weg soll.

Die iteration sollte so weit wie moeglich sauber gehalten werden.

 

[fastjack]

@bygones danke.

Wie funktioniert das eigentlich mit den "Zetteln" bei Euch. Benutzt Ihr da Zettel, Pappkärtchen, oder Softwarelösungen?