[Ben]

Hallo,
ich bin gerade beim interessierten Surfen *g* hierüber gestolpert:
http://trac.edgewall.org/roadmap

Und irgendwie schoss mir die Frage in den Kopf. Wie genau legt man eigentlich bei einer roadmap eines Projekts die milestones fest?
Wenn man dem Link folgt sieht man ja so Balken.
Die Tickets/Probleme/Bugs/ToDos/whatever, als Beispiel http://trac.edgewall.org/query?statu...lestone=0.10.1, sind nun ja einem Meilenstein zugewiesen.

Die Frage ist aber nun, wie schon erwähnt, wie legt man am günstigsten und effektivsten fest, welcher Bug zu welchem Meilenstein gehört?

Ich bin für Meinungen und eine hilfreiche Diskussion dankbar.

Grüße, Ben.

[WarrenFaith]

Meilensteine sind ja im Klartext nur Definitionen, zu welchem Zeitpunkt was fertig sein muss. Fertig heisst in dem Falle reif für die Produktion (so das was ich hier in der ersten Woche auf Arbeit so gelernt hab).
Bugs zuordnen würde für mich einfach heißen, dass Bugs zu Features, die eigentlich schon fertig sind, zum nächsten Meilenstein behoben sein müssen. Wenn ein Modul schon entwickelt wird, aber der zuständige Meilenstein erst nach den nächsten X Meilensteinen kommt, so wird sicherlich eher die schwere des Bugs gemessen um zu sagen, es reicht für den letzten Meilenstein oder es ist was kritisches, dann zum nächsten.

[xardias]

ich würde auch empfehlen die meilensteine möglichst klein in ihrem umfang zu halten.
Lieber wenige Funktionen im ersten Meilenstein, aber die Funktionen die man hat möglichst Bugfrei, und Funktionsfähig.
Das ist vor allem in den ersten Meilensteinen sehr schwierig finde ich. Man hat ein Ziel vor Augen und muss sich dann erstmal soweit zurück besinnen bis man dieses Ziel in viele kleinere Schritte aufteilen kann.

[WarrenFaith]

Der erste Meilenstein hat eh erstmal gar nichts mit der Programmierung zu tun.
Bei dem jetzigen Projekt auf Arbeit war der erste Meilenstein: "Projektplanung/Konzeption stehen"
Dann wird ein Prototyp geschrieben, dann wird der Weggeschmissen und anhand der Erfahrung mit dem Prototyp alles neu programmiert.
Das sind die großen Meilensteine, es gibt aber Gruppenintern natürlich weitere kleinere, die aber halt nur Gruppenintern interessant sind und die Projektleitung nicht interessieren.

[Waq]

Der ideale Meilenstein ist wahrscheinlich gar keiner.
http://steve-yegge.blogspot.com/2006...-agile_27.html (längerer Artikel, die relevanten Stellen sind etwas verteilt, ich meine den Grundtenor "Zeitpläne sind böse")

Wenn man dann einen Meilenstein macht (was häufig auch sinnvoll ist), sollte dieser wohl keine Bugs des Typs "showstopper" haben. Alles weitere, v.a. was reingehört, sollte sich direkt aus der Beantwortung der Frage ergeben: "Warum brauchen wir einen Meilenstein?"

[Ben]

Danke für den Link. Werde ich mir durchlesen, aber nicht mehr heute.

[Nachtrag]
Länglich ist gut ... erst mal 'ne Pause machen.

[xardias]

Schaut interessant aus. Ich glaube ich kenne noch viel zu wenige aspekte von extreme programming, agile und testdriven development und so

[Basti]

Zitat von xardias

ich würde auch empfehlen die meilensteine möglichst klein in ihrem umfang zu halten.

Blos nicht!

http://bunkandrambling.com/blog/arti...omic-episode-4

Basti

[WarrenFaith]

der kürzeste Abstand bei uns ist von Freitag auf Montag.... Freitag abschalten der alten Site, Montag anschalten der neuen...

[Ben]

Zitat von Basti

Blos nicht!

http://bunkandrambling.com/blog/arti...omic-episode-4

Basti

Des ist geil. hahaha ...