How we do Scrum

Erst mal einige Fakten:

Sprintlänge: 2 Wochen
Sprint Planning: Montags 10:15 - 12:15
Daily Scrum:10:15 - 10:30
Sprint Review: Freitags 10:15 - 12:15
Sprint Retrospektive: 12:15 - 13:15
Team: 4
Product Owner: ich :-(
Scrum Master: auch ich

und die ersten Erfahrungen:
Zu Beginn des Projektes hatte ich geglaubt auf das Review und die Retrospektive zunächst verzichten zu können. Nach ein paar Sprints bin ich aber zu der Überzeugung gekommen, das das Fehlen dieser beiden Meetings zu Problemen führt.
Das erste Problem ist die Feststellung, ob ein bestimmtes Sprint Item wirklich fertig ist. Ohne das Review mussten wir uns auf die jeweilige Aussage des Entwicklers verlassen, wobei hier auch die verschiedenen Definitionen des Begriffs "Fertig" problematisch sind. Dieses Problem versuchen wir durch eine Art TeamVertrag (TeamCharter) zu beheben. Den Vertrag haben wir allerdings erst letzte Woche aufgesetzt, daher gibt es bisher noch keine positiven Ergebnisse (Einige Bestandteile der Definition werden jedenfalls noch nicht umgesetzt). Insgesamt habe ich aber den Eindruck, das jetzt mehr Unit-Tests geschrieben werden. Ich weiß allerdings nicht, ob dies unbedingt mit der Definition von "Fertig" zu tun hat.

Das zweite Problem durch das Fehlen der Sprint Retrospektive ist, das sich keiner kaum jemand Gedanken um den Prozess an sich macht. Der Prozess wurde als unveränderbar angesehen (so mein Eindruck). Die Einführung der Retrospektive allein hat allerdings auch noch keinen durchschlagenden Erfolg gehabt. Die Retrospektive begann bisher immer erstmal mit Schweigen. Ein paar Punkte, die ich mir in den vergangenen zwei Wochen aufgeschrieben hatte (entweder weil sie mich selbst gestört hatten oder weil einer der anderen diese mal im Daily Scrum erwähnt hatte) führten aber zu einer gewissen Art von Diskussion, bei der dann auch weitere Punkte aufgetaucht sind. Insgesamt also eine recht erfreuliche Entwicklung.

Das nächste mögliche Problem ist die Tatsache, das ich Teammitglied, PO und SM in Personalunion bin. Dies führt zu erheblichen Interessenkonflikten (und ziemlich viel Stress :-))). Da ich unseren Kunden überzeugen konnte ab nächste Woche als PO zu fungieren, hoffe ich mittelfristig "nur" Teammitglied und SM zu sein.
Dem zukünftigen PO habe ich heute morgen eine kurze Einführung in Scrum gegeben und ihm gezeigt wie man das Product Backlog (z.Z. ScrumWorksBasic) bearbeitet. Technisch ist dies für ihn warscheinlich kein Problem aber ich habe das Gefühl, das ich mit ihm im Laufe der Woche noch einige Male telefonieren muss, damit der Detaillierungsgrad der Einträge einigermassen passt.

Method in a common class

Suppose I have something like a "common" method. Something like

"addCharacters(String str, Character, character, Integer length)"

which adds characters at the beginning of a string until it reaches a certain length.

At the moment, I need that special method only in one place (class), but I or somebody else might need that method in the future in one ore more other classes in the same project.

My question is now: Do I put that method in the class where I already need it at the moment or do I put that method in some kind of common class (a utility class of some sort).

The advantage of the first solution would be that I could easily modify the method without thinking of the impact on other parts of the system. It could even delete it without anybody noticing.

The disadvantage of this solution is that somebody else who needs the same or similar functionality probably won't find the method in that special class. He will probably start implementing a similar method in a different class. This could lead to several different implementations in the same project, which have to be refactored in the future.

Is there a general answer to that question? I think there isn't. But which circumstances could influence the decision? Size of the project?

greetings alex

Merge vom Release Branch auf den Trunk

Stehend auf dem Trunk
Bei From den entsprechenden Branch auswählen.
Bei From die Revision bei der Erzeugung bzw. bei dem letzten Merge des Branches auswählen
Bei To die letzte Revision auf dem Branch (müßte iegntlich Head sein)

Merge von Branch auf Trunk:
Stehen auf Trunk.
From Trunk(Head)
To Branch (Head) (Checkbox angeklickt)

Merge von Trunk auf Branch:
Stehen auf Branch
From: Trunk (Revision)
To: Branch (Head) (Checkbox nicht angeklickt)