Projekt einrichten: Neues Projekt anlegen

Nachdem Sie in der vorherigen Blogserie erfahren haben, wie Sie objectiF RPM an Ihre Bedürfnisse anpassen können, geht es in der neuen Serie mit dem Thema „Agiles Projektmanagement“ weiter. Sie erfahren, wie Sie mit objectiF RPM Ihre Projekte vorbereiten, planen, durchführen und kontrollieren. Wir beginnen heute mit der Vorbereitung: die Einrichtung eines neues Projekts in objectiF RPM.

Das Einrichten eines Projekts erfordert im Wesentlichen drei Schritte:

• Projekt anlegen mit Hilfe der Vorlage,
• dem Projekt Mitarbeiter zuordnen,
• die per Vorlage erzeugte initiale Projektplanung anpassen an die spezifischen Vorgaben für Ihr Projekt.

Was sich hinter dem ersten Schritt konkret bei der Arbeit mit dem Tool verbirgt, erfahren Sie jetzt:

Projekt anlegen

Um ein Projekt anzulegen, gehen Sie in die Backstage-Ansicht. Dort finden Sie die Funktion Anlegen mit der Option Neues Projekt.

Ein neues Projekt in objectiF RPM anlegen

Wenn Sie Neues Projekt anklicken, wird der Projekt-Wizard geöffnet, der Sie in zwei einfachen Schritten beim Anlegen eines Projekts unterstützt:

Im ersten Schritt geben Sie dem Projekt einen Namen. Sie müssen außerdem ein Projektkürzel festlegen. Sie werden es später in den automatisch erzeugten IDs der Artefakte Ihres Projekts wiederfinden. Wählen Sie im Feld Anzeigen unter die Organisationseinheit aus, zu der Ihr Projekt gehört. Bestimmen Sie, welche Vorlage für Ihr Projekt verwendet werden soll. Als Anwender können Sie selbst Projektvorlagen entwickeln, die auf Ihre spezifischen Projekttypen zugeschnitten sind. Für agile Projekte ist das allerdings nicht notwendig. Dafür finden Sie im Tool bereits geeignete Vorlagen.

Wählen Sie für größere Vorhaben die Vorlage für ein agiles, skalierbares Projekt. Mit dieser Vorlage sind Sie später, wenn Ihr Projekt wächst, sehr einfach in der Lage, neue Teams in das Projekt aufzunehmen. Die zweite angebotene Vorlage für ein agiles Projekt sollten Sie nur dann verwenden, wenn Sie ganz sicher sind, dass Sie im Projekt nur mit einem Team arbeiten werden.

Es ist übrigens grundsätzlich möglich, unternehmenseigene Projektvorlagen zu erstellen und sie an dieser Stelle zur Auswahl anzubieten. Dazu können Sie ganz neue Vorlagen aufsetzen oder die vorhandenen modifizieren und zu Ihrem Standard „umbauen“. Aber zurück zum Anlegen eines Projekts:

Mit Weiter geht es zum zweiten Schritt: Legen Sie den Starttermin Ihres Projekts fest. Geben Sie außerdem den Namen der fachlichen Domäne ein, für die als erstes Anforderungen ermittelt werden sollen. Dann brauchen Sie noch einen Namen für das erste Release, den ersten Sprint und das erste Team, das zum Einsatz kommt. Bilden Sie diese Namen nach den bei Ihnen üblichen Namenskonventionen. Achtung: Wählen Sie die Namen sorgfältig und vergewissern Sie sich, dass Sie sich nicht vertippt haben. Die Namen fließen in viele Artefakte ein, die durch die Vorlage erzeugt werden. Nachträgliches Ändern macht wirklich keinen Spaß.

Einstellungen zum neuen Projekt

Durch die Verwendung der Vorlage für Ihr Projekt ist fast alles da, was Sie brauchen:

Das Projekt besitzt bereits eine erste Aktivitätengliederung – wir sprechen auch von einem Projektstrukturplan oder einer Work Breakdown Structure. Sie besteht aus:

• den Aktivitäten Ziele und Strategie festlegen und Requirements Engineering,
• einer Aktivität für die Entwicklung des ersten Release – man spricht auch von einem Release-Container,
• einer Teamaktivität als Sammelaktivität für die Sprints eines ersten Teams,
• einer Aktivität für den ersten Sprint des ersten Teams.

Release, Team und Sprint sind so benannt, wie Sie es im Projekt-Wizard vorgegeben haben. Für das Projekt und seine Aktivitäten werden Annahmen in Hinsicht auf ihre Dauer, ihren Aufwand und die beteiligten Mitarbeitergruppen gemacht. Der Anpassungsaufwand ist – wie Sie später sehen werden – minimal im Vergleich zu dem, was per Vorlage im Projekt angelegt wird. Öffnen Sie in einem neu angelegten Projekt die Themenleiste. Darin sehen Sie vieles von dem, was die Vorlage mitgebracht hat, so zum Beispiel:

• einen Projektplan als Gantt Chart unter dem Thema Planung und Steuerung,
• spezielle Sichten für die Release-Planung, nämlich Anforderungen <Domänen-Name> / <Release-Name> Backlog sowie Anwendungsfälle <Domänen-Name> / <Release-Name> Backlog ebenfalls unter dem Thema Planung und Steuerung,
• die Domänen-Backlogs für Anforderungen und Anwendungsfälle unter dem Thema Anforderungen,
• Sichten auf das erste Release in der Themengruppe für das Release. Dazu gehören das Release als Gantt Chart, eine spezielle Backlog-Sicht <Release-Name> : Team-Backlogs für die Teamplanung und Auswertungen zur Earned Value Analyse,
• Dashboards mit Kennzahlen auf unterschiedlichen Planungsniveaus,
• Sichten in der Themengruppe für das erste Team. Auch hier gibt es wieder die Übersicht der Aktivitäten des Teams – also seine Sprints – als Gantt Chart, eine spezielle Planungssicht, mit der aus dem Team-Backlog User Stories in das oder die Sprint-Backlogs des Teams übernommen werden können, sowie das User Story Board für den ersten Sprint des Teams. Auf dem User Story Board kann übrigens auch ein Burn-up Chart für den Sprint aufgerufen werden. Und schließlich ist auch wieder die Übersicht zur Earned Value Analyse als vorbereitetes Chart verfügbar.

Projektansicht mit Gantt Chart

Soweit zur Aktivitätsseite. Auch auf der Seite der Ergebnisse werden eine ganze Reihe von „Dingen“ per Vorlage initial angelegt. Dazu gehören unter anderem:

• in der Produktesicht die Ordnerhierarchie für die Artefakte des Requirements Engineering und der Planung und Steuerung des Projekts sowie ein Ordner für externe Dateien,
• in der Produktesicht die Ordnerhierarchie für die Artefakte des Requirements Engineering und der Planung und Steuerung des Projekts sowie ein Ordner für externe Dateien,
• eine Vielzahl an vorbereiteten Auswertungen, die Sie nach Bedarf konfigurieren können,
• vorbereitete – ebenfalls anpassbare – Dokumente, in die Sie Projektartefakte hinein-generieren können.

In der Produktesicht werden speziell Ordner für die Artefakte des ersten Release, des ersten Teams und des ersten Sprints angelegt (siehe nachfolgende Abbildung). Neben vorbereiteten Auswertungen und Sichten befinden sich darin unter anderem vorbereitete Elementgruppen. Sie dienen dazu, Revisionen von Entwicklungsständen zum Beispiel am Release-Ende zu erzeugen, oder anders ausgedrückt, um Basislinien oder Baselines zu ziehen. Außerdem enthält die Produktesicht bereits Ordner für die Tests von Release 1 bzw. von den Ergebnissen des ersten Teams.

Produktesicht von objectiF RPM

Vielleicht fragen Sie sich jetzt: „Und was mache ich beim zweiten Release? Muss ich da all diese Dinge mit der Hand anlegen?“ Das müssen Sie natürlich nicht. Denn die Vorlage hat für Ihr Projekt noch etwas anderes, äußerst Nützliches im Gepäck: Muster. Sie helfen Ihnen, im weiteren Projektverlauf nach Bedarf Folgendes anzulegen:

• eine zusätzliche fachliche Domäne,
• ein neues Release,
• ein weiteres Team,
• einen neuen Sprint für ein Team.

Bei der Anwendung dieser Muster werden für ein Release, Team und Sprint neben den zugehörigen Aktivitäten für die Projektplanung auch Gantt Charts, Backlogs, Elementgruppen, Planungssichten und Auswertungen angelegt, die – wie oben beschrieben – schon für das erste Release, das erste Team und den ersten Sprint per Projektvorlage erzeugt wurden. Wie Sie die Muster anwenden, darauf gehen wir später ein.

Was müssen Sie nach dem Anlegen eines Projekts als erstes tun? Nun, Ihr Projekt braucht zunächst einmal Mitarbeiter. Wie Sie Mitarbeiter dem Projekt zuordnen, erfahren Sie im nächsten Blog-Beitrag.

Haben Sie bereits Fragen oder Anmerkungen zum Anlegen eines neuen Projektes? Dann melden Sie sich bitte bei uns. Wie immer stehen wir unter service@microtool.de bzw. 030/467086-20 sehr gerne zur Verfügung.

Hinweis:

Alles Wichtige zu objectiF RPM auf einen Blick haben wir für Sie im objectiF RPM Whitepaper zusammengestellt.