Verwalten von Meilensteinen und Web-Entwicklungsprojekt

Nun, es kommt darauf an. Sie haben nicht angegeben, wie groß das Projekt sein soll, wie viele Programmierer arbeiten werden und wie oft Sie planen, zu liefern.

Das heißt, wir verwenden Trac in einem großen Projekt, das mehrere Jahre umfasst und aus einer Anzahl kleinerer Teilprojekte besteht.

• Meilensteine ​​ sind als Punkte definiert, an denen wir einige Funktionen im Teilprojekt zur Auslieferung bereithalten. Der erste Meilenstein in jedem Teilprojekt ist normalerweise der längste. In der Regel benennen wir Meilensteine ​​als "Teilprojektname v0.01". Versionen sind nur in Schritten von 0,01, 0,02, ... Wenn wir alles, was für das Teilprojekt erwartet wird, implementieren, markieren wir den letzten Meilenstein als v1.00. Nachfolgende Fehlerbehebungen gehen zu einem Meilenstein, den wir als "Teilprojektname - v1.00 - bugfix"

markieren

• Milestone-Beschreibung enthält nur eine Liste neuer Funktionen oder Fehlerbehebungen. Dokumentation ist in Wiki und in Tickets geschrieben.

• Trac Wiki hat normalerweise mindestens eine Seite über neue Funktionen, die in einem bestimmten Meilenstein implementiert werden. Es ist normalerweise eine höhere Beschreibung des erwarteten Verhaltens der Anwendung. Oft gibt es Beispiele für erwartete Ergebnisse, die die Anwendung erzeugen sollte.

• Tickets enthält eine detaillierte Beschreibung der Funktion oder des Fehlers, die implementiert werden müssen.

  • Fehlerbericht-Tickets enthalten eine Beschreibung des Fehlers und Schritte zur Reproduktion (fast immer).
  • Feature-Tickets enthalten eine detaillierte Beschreibung des Features, das implementiert werden muss. Ein Ticket enthält Arbeit für bis zu 6 Stunden . Wenn wir eine Arbeit planen, teilen wir die Merkmale in einen Bereich von 1 bis 6 Stunden Arbeit. Wenn wir schätzen, dass diese Funktion mehr Zeit benötigt, teilen wir sie in mehrere Tickets auf, so dass jede von ihnen in 1-6 Stunden Arbeit passt. Wir haben 6 Stunden gewählt, weil wir der Meinung sind, dass dies die Spitze ist, die wir mit einem Fehler von nicht mehr als 30% schätzen können (was bedeutet, dass diese 6-Stunden-Schätzung fast immer im Bereich von 4-8 Stunden durchgeführt werden kann). Natürlich gibt es Ausnahmen von diesen Statistiken. Nach unserer Erfahrung liegt der Hauptgrund für falsche Schätzungen in schlechten Spezifikationen, die wir geschrieben haben. Das passiert fast immer, weil wir (Entwickler) die geschäftlichen Anforderungen unserer Nutzer missverstehen.

• Es gibt wenige Trac-Plugins zur Schätzung und Zeiterfassung. Überprüfen Sie diese Seite: Ссылка . Wir verwenden Timing And Estimation Plugin . Sie können die geschätzte Zeit für das Ticket und die Zeit, die für die Bearbeitung des Tickets aufgewendet wird, eingeben. Dann können Sie Berichte darüber erhalten, wie viel Zeit Sie für Tickets / Meilensteine ​​aufgewendet haben und wie viel Zeit Sie dafür benötigen.

Nach zwei Jahren können wir ziemlich genau abschätzen, wie viel Zeit für die Arbeit benötigt wird. Wenn wir die Bedürfnisse und Anforderungen der Benutzer richtig verstehen, können wir in der Regel den versprochenen Zeitrahmen einhalten. Derzeit zeigen unsere Statistiken, dass wir die benötigte Zeit für Tickets um 10% überschätzen.

Ein kleiner Vorbehalt: Ich habe keine Ahnung von Trac ... oder SVN. Ich denke, deine Meilensteine ​​sollten nicht vom Versionskontroll- / Fehlerverfolgungssystem gesetzt werden.

Typische Meilensteine ​​sind nur wichtige Ereignisse in Ihrem Projekt. Sie sollten für alle Interessengruppen von Bedeutung sein. Die Fertigstellung eines wichtigen Ergebnisses ist ein Meilenstein. Die Fertigstellung einiger Features ist nicht möglich. Abmelden bei allen Plänen und Verträgen ist ein wichtiges Ereignis, aber die Fertigstellung von 10 Modellen ist nicht möglich.

Ich neige dazu, den Zeitplan und die Aufgaben für die Arbeit mit dem Team zu verwenden. Aktivieren Sie Aufgaben, wenn sie erledigt sind. Für alle anderen berichte ich nur über Meilensteine. Werden wir bis zum 15. Mai UAT machen? Ja, das sind wir.

Da Meilensteine ​​Werkzeuge für die Berichterstattung an Sponsoren und andere Stakeholder sind, sollten Sie sie als das festlegen, was sie für wichtig halten. Meine Sponsoren werden wissen wollen, wann ein bestimmter Kernsatz von Features fertiggestellt ist. Das ist ein Meilenstein. Sie werden wissen wollen, wann UAT abgemeldet wird, das ist ein Meilenstein.

Stellen Sie zu wenige Meilensteine ​​ein und niemand wird wissen, wie Sie bis zum Ende voranschreiten. Stellen Sie zu viele ein und der Wert wird verloren gehen.

Es gibt keine Zauberformel, aber Projekte mit Hunderten von Aufgaben und Tausenden von Arbeitsstunden können nur vier Meilensteine ​​haben.

alt text http://officeadd.in/ Bilder / Artikel / ProjectMilestones-scribblea.png

Entschuldigung, das bezieht sich nicht direkt auf Trac und SVN, aber hoffentlich gibt Ihnen das eine ungefähre Vorstellung davon, wie Meilensteine ​​allgemein verwendet werden. Oh und Entschuldigung im Voraus für die Übernutzung von Comic Sans ... yuck.

Wenn Sie Ihren Meilenstein auf 1,0 setzen, ist das in Ordnung, aber Sie sollten frühere Meilensteine ​​definieren - machen Sie sie wöchentlich, wenn es ein gutes Intervall für Sie ist, und nummerieren Sie sie entsprechend. Für ein 4-wöchiges Projekt würden vielleicht 0,2, 0,5, 0,7 und 1,0 funktionieren. Listen Sie die relevanten Bits für jeden Meilenstein auf: "Design complete", "Coding complete", "Testing complete" usw. Wenn Sie nicht zielgerichtet sind, beginnt die eigentliche Projektverwaltung!

Ich sehe, Sie haben mehrere Möglichkeiten und ein paar Entscheidungen zu treffen.

Sie könnten über Feature Driven Development nachdenken. Sie könnten trac verwenden, um die Kommunikation zu unterstützen, anstatt diese Kontrolle. Grobkörnige Aufgaben, feinkörnige Tickets und frühe Versionen.

Machen Sie eine Liste der zu entwickelnden Features und geben Sie an, dass die Veröffentlichung, sagen wir ... Version 1.0, stattfindet, wenn alle Features entwickelt und getestet werden. Machen Sie Regenschirm-Karten für alle Eigenschaften. Es sind grobkörnig und werden Entwicklungsrhythmus definieren.

Definieren Sie nun basierend auf der Anzahl der geplanten und geplanten Funktionen einige Meilensteine. Der erste Meilenstein sollte mindestens ein Feature enthalten, da das Ziel eines Meilensteins darin besteht, das Projekt zum Testen und Feedback zu erstellen. Definieren Sie einen oder mehrere Meilensteine, um zu markieren, wann alle Funktionen abgeschlossen sind, nennen Sie sie "Beta", "Release Candidate" oder was auch immer.

Wenn während der Entwicklung feinkörnigere Aufgaben erforderlich sind, scheuen Sie sich nicht, sie zu erstellen. Und machen Sie die Regenschirm-Aufgaben von diesen neueren Tickets abhängig.

Ein Fehlerbericht muss nicht unter diesen sein und kann so viele Details enthalten wie nötig. Diese sind feinkörnig. Diese werden nicht Entwicklungsrhythmus definieren. Eine Ausnahme ist ein Bug Squashing Sprint, um Showstopper zu eliminieren. Veröffentlichen Sie die Namen der Entwickler mit mehr zugewiesenen und nicht behobenen Fehlern, um sie zur Lösung der Probleme zu zwingen.

Ein Teil des Prozesses zum Erstellen eines Meilensteins, einer Betaversion oder eines Veröffentlichungskandidaten markiert die Quelle, um den Prozess wiederholbar zu machen und Fehler zu erkennen, selbst wenn sich die Stammquelle bereits geändert hat. Bei SVN besteht der übliche Weg zum Tag darin, die Stammquelle in ein Verzeichnis auf "Tags" zu kopieren und sicherzustellen, dass niemand in diesen Zweig einsteigt.

Ich glaube, dass eine Versionsnummer mit zwei Nummern für die meisten Fälle ausreicht. Die erste Nummer steht für Kompatibilität und die zweite für die Freigabe. Aber es gibt mehrere Variablen innerhalb einer Versionsnummer: Quellkompatibilität, Binärkompatibilität, Bugfix-Level, Release, Companion-Produktversion (ala oracle), Protokollkompatibilität, etc.