microTOOL blog

Das südlichste in-Step

blog@microTOOL.de — Tue, 22 May 2012 09:15:00 +0200

Vor gut zwei Monaten kam ein Kollege zu mir: “Sag mal, hast du im April noch Zeit, zu einem Kunden zu fahren." Ja, hatte ich. "Allerdings gibt es dabei zwei – naja – Besonderheiten: Erstens bist du eigentlich nur drei Tage gebucht. Du solltest aber mindestens fünf einplanen. Denn zweitens liegt dein Einsatzort ziemlich weit im Süden ... ."

Des Rätsels Lösung: Der Kunde war die Firma mCel, ein Mobiltelefonunternehmen. Und der Einsatzort war – Maputo, die Hauptstadt von Mosambik. Da musste ich gar nicht lange überlegen ...

Ich habe spontan „Ja“ gesagt. Da ich bisher weder in Mosambik noch irgendwo sonst in Afrika war, hieß es jetzt, Reiseführer studieren – sie enthalten leider nur wenige Informationen über Mosambik –, im Internet recherchieren, impfen lassen und Visum besorgen. Dann war es soweit: Am Ostermontag flog ich über Frankfurt und Johannesburg nach Maputo. Ich war gespannt, was mich dort erwarten würde.

Bei der Ankunft in Maputo fällt sofort das moderne Terminalgebäude des Flughafens auf, das im Zusammenhang mit der Fußball WM 2010 in Südafrika gebaut wurde. Und obwohl auf dem Flughafen zurzeit nur etwas mehr als 10 Flüge am Tag starten, wird nebenan schon ein weiterer Terminal gebaut. Hier herrscht ganz offensichtlich Aufbruchstimmung.

Ein Fahrer von mCel erwartete mich am Flughafen und brachte mich ins Hotel. Die ersten Eindrücke auf der Fahrt dorthin waren durchaus zwiespältig. Rund um den Flughafen fährt man – für europäische Verhältnisse – durch ein sehr armes Viertel. Mein Hotel hingegen lag im ruhigen Diplomatenviertel – ausgestattet mit allem Komfort und Pool direkt gegenüber:

Zum Verarbeiten der ersten Eindrücke blieb mir nicht viel Zeit. Am nächsten Morgen ging es gleich mit der Arbeit beim Kunden los. Wie würde man mich dort aufnehmen?

In Mosambik werden über 40 Sprachen gesprochen. Amtssprache ist Portugiesisch. Aber alle mCel-Mitarbeiter, mit denen ich zu tun hatte, sprachen – wie ja fast überall in der IT – Englisch. Ich wurde sehr herzlich von den mCel-Mitarbeitern empfangen. Und schnell war klar: Auch hier im für uns so fernen Afrika füllen Businessprozesse und Projektmanagementstandards viele Ordner. Aber diese Standards werden bei mCel nicht nur aufgeschrieben, sondern auch umgesetzt.

Was konnte ich dazu beitragen? Am ersten Tag habe ich zusammen mit den zuständigen IT-Mitarbeitern die in‑Step Serverkomponente installiert und den Ausrollprozess für die in-Step Clients vorbereitet. Außerdem haben wir uns ausgiebig über Themen der technischen und fachlichen Administration des Systems ausgetauscht. Es hat Spaß gemacht, mit den IT-lern von mCel in-Step zum Laufen zu bringen.

Für den zweiten Tag hatte ich einen Einführungskurs in die Grundkonzepte von in-Step vorbereitet. Mein Zuhörerkreis setzte sich aus Projektleitern, Projektmitarbeitern und IT-Mitarbeitern zusammen. Dieser Tag war für alle Beteiligten wohl der anstrengendste. Es galt, sehr viele Informationen in relativ kurzer Zeit zu vermitteln bzw. aufzunehmen. Aber ich denke, das haben wir gemeinsam gut gemeistert.

Am dritten Tag haben wir und uns dann einen typischen Projektmanagementprozess von mCel vorgenommen und begonnen, ihn auf der Basis der in-Step CoreProcess Edition zu implementieren. Dabei ging es nicht darum, den Prozess komplett abzubilden, sondern das am zweiten Tag Gelernte praktisch anzuwenden und über verschiedene Möglichkeiten der Umsetzung zu diskutieren. Am Ende des Tages hatten wir eine solide Basis für die weitere Arbeit mit in-Step bei mCel geschaffen.

Aber auch am südlichsten Einsatzort von in-Step wird nicht rund um die Uhr gearbeitet. Den Abend des dritten Tages habe ich mit einigen Kursteilnehmern in einem Restaurant am Strand verbracht, wo wir hervorragende Meeresfrüchte- und Fischgerichte genießen konnten.

Mit Musikbegleitung haben wir dann diese abwechslungsreiche Zeit ausklingen lassen.

Am nächsten Tag hieß es für mich dann, wieder nach Hause zu fliegen. Leider blieb nur noch ein halber Tag. Ich nutzte ihn für einen langen Strandspaziergang am Indischen Ozean.

17 Reise-Stunden später war mein erster Einsatz auf dem afrikanischen Kontinent zu Ende.

Inzwischen erreichen mich immer wieder E-Mails mit spannenden Aufgaben und Fragen aus Mosambik. Ein Zeichen dafür, dass man bei mCel intensiv mit in-Step arbeitet. Vielleicht ergibt sich ja noch einmal die Möglichkeit für eine Dienstreise nach Mosambik …

Auswahl leicht gemacht: Produkte referenzieren

blog@microTOOL.de — Tue, 15 May 2012 08:21:00 +0200

In in-Step können Sie von einem Produkt auf andere Produkte verweisen. Solche Produktreferenzen werden gern benutzt, um Abhängigkeiten zwischen Produkten darzustellen und nachverfolgen zu können. In den mit in-Step ausgelieferten Anwendungsbeispielen und Projektvorlagen wird so z.B. die Beziehung von Anforderungen und Testfällen abgebildet.

Was steckt dahinter? Derartige Beziehungen können Sie ganz einfach einrichten. Sie benötigen lediglich in der entsprechenden Kategorie – im Bild sehen Sie die Kategorie für Anforderungen (REQUIREMENT) – eine Eigenschaft vom Typ Produkt.

Haben Sie in der verwendeten Instanzkategorie eine solche Eigenschaft definiert, klappt das Anlegen der Produktreferenzen wunderbar. Einziges Manko, Sie müssen die Auswahl aus allen in in-Step verwalteten Produkten treffen. Besser wäre es, wenn an dieser Stelle nur "passende" Produkte – also hier Testfälle – zugeordnet werden könnten.

Das heißt: Die Auswahl müsste bei der Zuordnung eingeschränkt werden. Doch wie geht das am besten?

Kategorie des zugrundeliegenden Produkttyps anpassen

Als Erstes benötigen Sie eine gleichnamige Eigenschaft in der Kategorie des zugehörigen Produkttyps. Bleiben wir bei unserem Beispiel von Anforderungen, die Testfälle referenzieren sollen. In der Kategorie von Anforderungen (REQUIREMENT) gibt es die Eigenschaft Testfälle vom Typ Produkt. Dann benötigen Sie in der Kategorie des zugrundeliegenden Produkttyps (Anforderung) ebenfalls eine Eigenschaft Testfälle.

Doch welche Kategorie hat der Produkttyp? Am besten schauen Sie in den Eigenschaften nach – mit Gehe zu/Produkttyp im Kontextmenü einer Anforderung ist das schnell erledigt:

Bei Anforderungen finden Sie dort als Kategorie standardmäßig PRODUCTTYPE_REQUIREMENT.

Dieser Kategorie fügen Sie nun ebenfalls eine Eigenschaft Testfälle hinzu. Sie muss vom Typ Produkttyp sein.

Die Kardinalität bestimmt, ob der Eigenschaft später einer oder mehrere Produkttypen zugewiesen werden können. Da Sie ausschließlich Testfälle zuordnen wollen, wählen Sie hier die Kardinalität 1.

Produkttyp anpassen

Haben Sie die Kategorie entsprechend angepasst, finden Sie im Eigenschaftendialog beim Produkttypen für Anforderungen unter Weitere Eigenschaften den Eintrag Testfälle. Hier können Sie jetzt den Produkttyp der Produkte auswählen, die in dieser Eigenschaft referenziert werden sollen. Anhand des gewählten Produkttyps werden dann im Projekt die in den Anforderungen unter Testfälle zur Auswahl angebotenen Produkte gefiltert. Dort werden also nur noch Produkte des hier eingestellten Produkttyps angeboten.

Zuordnung leicht gemacht

Sie können es sofort ausprobieren. Öffnen Sie eine Anforderung – sei es über das Formular oder den Eigenschaften-Dialog – und weisen Sie unter Testfälle ein Produkt zu. Sie werden sehen, die Auswahl der angebotenen Produkte beschränkt sich nun auf die Testfälle in Ihrem Projekt.

So machen Sie den Mitglieder Ihres Teams die Arbeit leicht – und natürlich können Sie das bei allen Arten von Referenzen tun. Kleiner Tipp: Bei den Anforderungen finden Sie gleich mehrere Beispiele dazu.

Die NutzerKonferenz 2012: Tag 0 & 1 im Schnelldurchlauf

blog@microTOOL.de — Thu, 10 May 2012 11:20:00 +0200

Der Dialog über den Wandel sollte die microTOOL NutzerKonferenz 2012 bestimmen. Deshalb gab es das erste Novum schon am Tag vor der Konferenz: Einen Workshop mit 14 Kunden, die ihre Wünsche und Fragen zu in-Step 5 stellen und an unsere Pinnwände heften konnten. An einige der vielen Moderationskärtchen konnten wir schon einen Haken machen und versprechen: Yes, we can.

Wir sind auf dem richtigen Weg. Ein prima Gefühl, um in den ersten Konferenztag zu starten und in großer Runde von der neuen Produktlinie zu berichten. Bernd Nawrot eröffnete den Tag und gab einen Einblick in die Entwicklung. Die Vision von einer integrierten Lösung für Projektmanagement und Requirements Engineering wird konkret.

Erste sichtbare Ergebnisse zeigten Mario Müller und Daniel Braune direkt im Anschluss: in-Step 5 mit neuer Oberfläche. Jede Menge Fortschritte, von denen man profitieren will, aber was wird aus all den Projekten in in-Step 4? Und den individuellen Erweiterungen? Die Sorgenfalten auf den Stirnen im Publikum glätteten sich schlagartig, als die einfache Migration live am Beispiel erklärt wurde. Weitere gute Neuigkeiten: Kundenspezifische Erweiterungen, die microTOOL erstellt hat, werden im Rahmen der Wartung migriert. Zudem wird in-Step 4 solange gewartet, wie die Kunden es im produktiven Einsatz haben - 2014, 2015, 2016, ... Die klare Botschaft: "Nehmen Sie sich die Zeit für einen Umstieg auf in-Step 5, die Sie brauchen."

Bei den ersten Kundenvorträgen wurde es mobil – auf der Schiene. Axel Velarde, Prozessmanager bei der VOITH Turbo Scharfenberg GmbH, berichtete von seiner "Verkupplung“ mit in-Step. Seine Mission lautete: Das Excel-Tabellen-Datenchaos von 320.000 Dateien in 100.000 Ordnern in einem Konfigurationsmanagementsystem aufzulösen. Dokumente für Audits auffindbar machen, Qualitätsnormen durch Prozesse abbilden. Noch ist er nicht am Ende seiner Reise, aber dem Ziel schon ein gutes Stück näher.

Um Normen, Sicherheit und Langlebigkeit ging es auch beim Vortrag von Carsten Seedorff von der BBR Baudis Bergmann Rösch Verkehrstechnik GmbH. Er entwickelt dort mit in-Step sicherheitsrelevante Systeme. Sein Fazit lautete: „Ein Gutachter möchte Transparenz - wir auch.“ Da verwundert es nicht, dass die Tool-Auswahl auf in-Step fiel - damit z.B. die Stellwerk-Technik der Zugspitzbahn auch in Zukunft reibungslos funktioniert.

Wer hätte uns den Wandel schmackhafter machen können als Karin Boden von SQS Software Quality Systems, die seit ihrem Auftritt bei der NutzerKonferenz 2011 nicht nur Namen und Firma gewechselt hat, sondern auch im Schnellverfahren in-Step zusätzlich zu objectiF bei Ihrem früheren Arbeitgeber, der Allianz, eingeführt hat. So konnte Sie auch stolz resümieren: Wir haben es getan! Ihr Rezept für erfolgreichen Wandel lautet: sich „ein Bild machen“ und mit Ideen, Herz, Mut, Verstand, Tools und Prozessen immer neue Gipfel erklimmen.

Auf dem Weg zum Gipfel muss man viele Meilensteine passieren. Bei der letzten NutzerKonferenz wähnten wir uns der Fertigstellung des Requirements Modellers bereits recht nahe. Doch der Scope des Tools wuchs stetig und damit auch der Entwicklungsaufwand. Das Ergebnis wird ein Tool für professionelles Requirements Engineering sein. Ursula Meseberg und Enrico Fritz stellten uns den Weg zu „guten Anforderungen“ mit dem Requirements Modeller vor und ernteten viel positives Feedback. Ausprobieren kann man das Tool demnächst auch. Weitere Informationen folgen in Kürze.

Leute mitnehmen - das kann Frank Linge. Beim Publikum der NutzerKonferenz hat es jedenfalls geklappt. Welche Hürden er beim Ausrollen von SAP mit in-Step bei Smurfit Kappa überwinden musste, wie man PRINCE2® mit Scrum kombiniert und auch noch das Management zufriedenstellt, das alles schilderte er in sehr unterhaltsamer Weise. Immerhin: das erste Projekt hat er bereits mit in-Step gestemmt.

Zu guter Letzt zeigte Thorsten Jähnig von profi.com noch eine Lösung zur Verknüpfung und Synchronisierung von Anforderungen in in-Step mit Test Cases im HP Quality Center.

Es war ein Tag voller spannender Geschichten über Projekte, Management Skills und das oft zitierte „Tal der Tränen“, aus dem man Veränderungsunwillige herausholen muss. Mehr Seemannsgarn über die Navigation von Projekten wurde auch auf der abendlichen Bootstour ausgetauscht.

In den kommenden Wochen werden wir einige Video-Mitschnitte von Vorträgen hier im Blog veröffentlichen. Vorbeischauen lohnt sich!

Anforderungen zentral sammeln und auf einzelne Projekte verteilen

blog@microTOOL.de — Thu, 03 May 2012 07:25:00 +0200

in-Step für projektübergreifendes Anforderungsmanagement konfigurieren

Aus organisatorischer Sicht kann es wünschenswert sein, Anforderungen aus unterschiedlichen Quellen zu sammeln und in einem zentralen Pool zu erfassen, um sie dann gezielt auf einzelne Projekte zu verteilen. Ein typisches Beispiel ist das Sammeln und Umsetzen von Kundenanforderungen in der Produktentwicklung. An diesem Beispiel zeige ich Ihnen heute, wie Sie als Administrator in-Step für projektübergreifendes Anforderungsmanagement einrichten.

Ein typischer Fall aus der Praxis

Stellen Sie sich dazu folgende Situation vor: Alle Kundenanforderungen werden bei Ihnen in einem eigenen Projekt, dem Kundenanforderungsprojekt, gesammelt. Dort werden sie von den Kunden selbst und/oder von Ihnen als Hersteller abgelegt. Die Anforderungen werden dann vom Produktmanager bewertet, priorisiert und in die Produktentwicklung eingeplant. Die Entwicklung selbst erfolgt – sagen wir – nach Scrum. Das heißt, aus den Anforderungen im Kundenanforderungsprojekt müssen Stories in den Entwicklungsprojekten werden.

Wie richten Sie als Administrator in-Step nun so ein, dass der Produkmanager zukünftig Anforderungen aus dem Kundenanforderungsprojekt mit wenigen Klicks als Stories in ein Entwicklungsprojekt übernehmen kann?

Wenn Sie mit in-Step arbeiten, kennen Sie die Möglichkeit, innerhalb von Projekten Produkte von anderen Produkten abzuleiten. Genau diese Funktionalität können Sie hier nutzen – nur auf projektübergreifender Ebene.

Das müssen Sie als Administrator einmalig vorbereiten

Die Stories im Entwicklungsprojekt sollen später natürlich noch „wissen“, aus welcher Kundenanforderung sie hervorgegangen sind. Das ist z.B. notwendig, um eine Rückmeldung an diese Kundenanforderung zu senden oder zu dieser navigieren zu können. Als Erstes ergänzen Sie deshalb die Kategorie für Stories um eine Eigenschaft vom Typ Produkt, in der auf die Kundenanforderung verwiesen werden kann.

Das sieht dann etwa so aus:

Als Nächstes benötigen Sie die Komponente, die die Funktionalität, Produkte von anderen abzuleiten, bereitstellt. Und zwar brauchen Sie diese in dem Entwicklungsprojekt, also dem „Ziel“. Als Administrator können Sie unter Projekt/Komponenten prüfen, ob die benötigte Komponente bereits im Projekt registriert ist. Zu finden wäre sie dann unter CommandServer mit dem Namen … für Produkte (CoreProcess, systemweit).

Ist diese Komponente im Entwicklungsprojekt noch nicht vorhanden, fügen Sie sie dort hinzu: Dazu klicken Sie auf Registrieren und wählen aus dem in-Step Installationsverzeichnis die CoreProcExtension.dll aus. Es werden Ihnen nun verschiedene Komponenten zur Registrierung angeboten. Sie benötigen wie gesagt den CommandServer … für Produkte (CoreProcess, systemweit). Markieren Sie das zugehörige Kontrollkästchen.

Ein Klick auf OK und Sie finden ihn in der Liste der CommandServer des Projekts.

Ist der Commandserver registriert, haben Sie alle Voraussetzungen geschaffen, um den Befehl für die Übernahme von Anforderungen als Story in das Entwicklungsprojekt zu definieren.

Befehl hinzufügen

Wählen Sie nun den CommandServer … für Produkte (CoreProcess, systemweit) in der Liste aus und klicken Sie auf Konfigurieren. Sie erhalten einen Dialog mit allen bisher konfigurierten Befehlen.

Mit Neuer Befehl können Sie hier eigene Befehle definieren. Wählen Sie Produkt ableiten im Untermenü und los geht’s:

Der Konfigurationsdialog gibt Ihnen die Möglichkeit, den Befehl bis ins Kleinste zu detaillieren. Unter Beschriftung geben Sie den Namen an, den der Befehl haben soll – in unserem Beispiel also Kundenanforderung übernehmen. Mit genau dieser Beschriftung erscheint der Befehl dann später im Kontextmenü einer Anforderung. Der Name ist der interne Name des Befehls und ergibt sich automatisch aus der Beschriftung.

Bei den Einstellungen zum Quellprodukt stellen Sie alles Notwendige zu dem Produkt ein, das als Grundlage für das Ableiten dient, in diesem Fall also zu den Anforderungen aus dem Kundenanforderungsprojekt. Sie wählen also als Produkttyp Anforderung aus. Eine referenzierende Eigenschaft geben Sie in diesem Beispiel nicht an, weil Sie dafür ja in der Story eine Eigenschaft definiert haben. Auch ein zu empfangendes Ereignis brauchen Sie im Moment nicht. Hier wäre denkbar, der Kundenanforderung durch ein entsprechendes Ereignis zu signalisieren, dass sie in das Entwicklungsprojekt übernommen wurde und auf diese Weise deren Zustand zu ändern.

Bei den Einstellungen zum abgeleiteten Produkt wählen Sie als Produkttyp Story. Hier geben Sie nun die referenzierende Eigenschaft an. In unserem Beispiel ist das die Eigenschaft Kundenanforderung, die Sie zu Beginn angelegt haben. Auch hier geben Sie im Moment kein Ereignis mit.

Schließlich müssen Sie noch definieren, in welchem Zustand sich eine Anforderung befinden muss, damit der Befehl sichtbar ist. Wählen Sie unter Sichtbar im Zustand die Zustände aus, in denen Sie den Befehl benötigen. Entscheiden Sie sich hier z.B. für den Zustand definiert.

Als letzten wichtigen Punkt wählen Sie aus, welche Eigenschaften der Anforderung in die Story übernommen werden sollen. Behalten Sie die Standardeinstellung bei, werden alle Eigenschaften mit gleichem Namen und Typ aus der Anforderung in die Story übernommen.

Nach Bestätigung mit OK finden Sie den neuen Befehl in der Liste der verfügbaren Befehle.

Eins ist jetzt noch zu beachten: Sie müssen die Rollen auswählen, für die der Befehl angeboten wird. Nur Mitarbeiter mit der geforderten Rolle können diesen Befehl dann ausführen. Auf diese Weise stellen Sie sicher, dass nicht jeder Mitarbeiter neue Stories aus Anforderungen ableiten kann.

Den Befehl haben Sie konfiguriert, doch wo finden Sie ihn? Natürlich auf den Anforderungen – nur sind die ja in einem eigenen Projekt. Was Sie brauchen, ist eine systemweite Sicht. Die definieren Sie sich jetzt.

Systemweite Sicht anlegen

Legen Sie eine neue systemweite Sicht vom Typ Produkte oder Produkte (Oracle) an.

Diese Sicht wird gefiltert nach dem Produkttypen Anforderung und dem Zustand definiert. Auf anderen Produkten wird der neue Befehl ja auch gar nicht angezeigt.

Als Datenquelle wählen Sie das Kundenanforderungsprojekt, aus dem die Anforderungen stammen, aus denen Stories abgeleitet werden sollen.

Und bei den Menüpunkten geben Sie den CommandServer an, in dem Sie den Befehl konfiguriert haben.

Haben Sie sich die Spaltenkonfiguration der Sicht auf der Registerkarte Allgemein genau angeschaut? Dann denken Sie vielleicht, dass in der Sicht nur sehr wenige Informationen angezeigt werden. Insbesondere fehlen Ihnen spezielle, in den Anforderungen definierten Eigenschaften wie z.B. die Anforderungsnummer. Genau die will der Produktmanager bestimmt sehen? Kein Problem. Dazu benötigen Sie die Informationen aus dem Kundenanforderungsprojekt. Sie werden dort in der Kategorie REQUIREMENT gespeichert – nur die gibt es in dem Scrum-Projekt nicht. Mit einem kleinen Trick können Sie diese Kategorie in das Entwicklungsprojekt übernehmen. Dann können Sie auch diese Eigenschaften als Spalten in Ihrer Sicht auswählen.

Wie das geht, habe ich in meinem letzten Beitrag Ein Stück Prozessmodell aus einem in-Step-Projekt in ein anderes übernehmen beschrieben. Wenn Sie diesem Trick anwenden, könnte die Sicht beispielsweise so aussehen:

Sie haben in-Step jetzt so konfiguriert, dass der Produktmanager es von nun an beim Verteilen der Anforderungen ganz leicht hat:

So übernimmt der Produktmanager mit wenigen Klicks zentrale Anforderungen als Stories in ein Scrum-Projekt

Dazu öffnet er die von Ihnen definierte Sicht der Kundenanforderungen, wie in obiger Abbildung. Die dort angezeigten Anforderungen kann er jetzt mit dem neuen Befehl Kundenanforderung übernehmen als Stories in das Entwicklungsprojekt übernehmen. Führt er das Kommando aus, erhält er einen Dialog, in dem er Namen und Zielverzeichnis der jeweiligen Story bei Bedarf anpassen kann.

Mit dem Klick auf OK wird die Story angelegt.

Die übrigen drei Anforderungen will er eins zu eins in das Entwicklungsprojekt übertragen. Dazu kann er alle drei gleichzeitig auswählen.

Zu den Anforderungen gibt es jetzt vier Stories im Product Backlog des Scrum-Projekts. Damit kann der Product Owner genauso verfahren, wie er das üblicherweise in seinem Entwicklungsprojekt tut.

Mit diesem Plus: Über Gehe zu im Kontextmenü kann man zwischen Kundenanforderung und Entwicklungsstory navigieren und so jederzeit den aktuellen Entwicklungsstand zu einer Kundenanforderung abfragen oder die Kundenanforderung zu einer Entwicklungsstory ansehen.

Probieren Sie es aus. Ich helfen Ihnen gern dabei.

Projektübergreifendes Anforderungsmanagement mit in-Step

blog@microTOOL.de — Tue, 24 Apr 2012 09:02:00 +0200

Synergien schaffen: dritter Mitschnitt vom in-Step Workshop in Hamburg (Video)

Im dritten Video vom in-Step Workshop in Hamburg zeigen wir Ihnen ein mögliches Szenario für projektübergreifendes Anforderungsmanagement mit in-Step: w3flex – unsere virtuelle Beispielfirma – bietet individuelle Lösungen auf Basis eines unternehmenseigenen Standardprodukts an. Dabei müssen Anforderungen aus Kundenprojekten mit den Anforderungen an das unternehmenseigene Standardprodukt koordiniert werden. Das bedeutet zum Beispiel, dass Anforderungen an das Standardprodukt auch in Kundenprojekten zugeordnet werden und dort in die Aufwands-, Termin- und Kostenplanung einfließen.

Wenn Sie den vorhergehenden Mitschnitt vom Workshop in Hamburg schon gesehen haben, wissen Sie, dass es in einem Kundenprojekt bei w3flex ein Kostenproblem gibt. Maren Kämmler – in der Rolle einer Projektleiterin bei w3flex – geht der Ursache auf den Grund. Sie zeigt Ihnen an einem konkreten Beispiel, wie projektübergreifendes Anforderungsmanagement mit in-Step Synergien schafft und in diesem konkreten Fall eine neue Risikobewertung möglich macht.

Zum Schluss noch ein Tipp für Sie: Passend zum Thema wird Steffi Fritz Ihnen nächste Woche zeigen, wie Sie in-Step für projektübergreifendes Anforderungsmanagement konfigurieren. Schritt für Schritt erläutert Sie Ihnen, wie Sie in in-Step Anforderungen aus unterschiedlichen Quellen in einem zentralen Pool sammeln und von dort auf einzelne Projekte verteilen.

Projektübergreifendes Controlling mit in-Step

blog@microTOOL.de — Tue, 17 Apr 2012 08:15:00 +0200

Mit in-Step ist es möglich, einen Projektplan mit angepasster Ressourcen- und Kostenplanung zu erstellen. Während der Projektlaufzeit nutzen die Projektmitarbeiter dann die in das Werkzeug integrierte Zeiterfassung, um erbrachte Arbeitsaufwände für die jeweiligen Aktivitäten zurückzumelden. Aber auch während der Projektdurchführung sollen Arbeitsabläufe sowie der Einsatz von Ressourcen optimiert werden. Dazu kann der Projektcontroller spezifische Sichten nutzen, um Abweichungen von gesetzten Terminen, einem Soll/Ist-Vergleich des Ressourceneinsatzes oder Veränderungen in der Kostenstruktur zu ermitteln.

Eigentlich alles „kalter Kaffee“ – denn all diese Funktionen stehen ja bereits in in-Step zur Verfügung. Spannender wird es, wenn

das Projektcontrolling durch eine zentrale Stelle der Organisation durchgeführt wird, um die Daten für die Analyse zu sammeln und somit auch einen Beitrag für das strategische Projektcontrolling zu liefern.
der Projektcontroller für ein Programm oder eine Projekt/Teilprojekt-Planung zuständig ist, wo er Daten aus mehreren (aufeinander abgestimmten) Projekten auswerten muss.

Für solche Fälle möchte ich Ihnen eine neue Funktion von in-Step nicht vorenthalten, die eine Aufwands- sowie Kostenauswertung auch über Projektgrenzen hinweg möglich macht.

Diese Lösung wird Bestandteil des neuen in-Step 4.10 sein. Sie können sie aber auch schon mit der aktuellen Version 4.9 von in-Step verwenden: Am Ende dieses Blog-Beitrags finden Sie dazu einen Download-Link.

Die neue Funktion besteht im Wesentlichen aus zwei Komponenten:

Einer neuen Sicht für die systemweite Auswertung, die es Ihnen ermöglicht, Plan- sowie Ist-Aufwände (und Kosten) für Organisationseinheiten und Projekte zu ermitteln.
Einer Excel-Vorlage, die mittels einer Makro-Funktion die eingegebenen Daten nach Projekt, Aktivität und Nutzer strukturiert und somit die Analyse und den Soll/Ist-Vergleich auf der Basis von Pivot-Funktionen ermöglicht.

Den Einsatz zeige ich Ihnen jetzt an einem kleinen Beispiel:

In der Organisation w3flex (also in unserer fiktiven Beispiel-Firma) gibt es ein neues Kundenprojekt namens „Mobility Europe“. Es besteht aus dem Hauptprojekt sowie Teilprojekten für Sensorik, Software und Industrielle Fertigung (siehe Abbildung 1).

Abbildung 1: Das Projekt „Mobility Europe“ mit seinen Teilprojekten

Karl-Heinz Schmidt ist der Gesamtprojektleiter, der den Teilprojektleitern Vorgaben bezüglich Termin-, Ressourcen- und Kostenplanung macht.

In der Organisationseinheit „Mobility Europe“ soll der Controller von w3flex die Auswertung durchführen können. Dazu benötigt unser Controller Peter Lichtenstein das Recht, alle Arbeitszeiten der Projekte der Organisationseinheit zu sehen (siehe Abbildung 2).

Abbildung 2: Dem Controller Peter Lichtenstein das Recht zuweisen, alle Arbeitszeiten der Projekte der Organisationseinheit zu sehen

Für Peter Lichtenstein ist eine neue Sicht konfiguriert, die es ihm ermöglicht, für die Projekte von „Mobility Europe“ die entsprechenden Plan- und Ist-Zeiten der Mitarbeiter strukturiert nach Projekt und Aktivität aufgelistet zu bekommen (siehe Abbildung 3). Diese Sicht ist verknüpft mit der genannten Excel-Vorlage. Die Einzelschritte der Konfiguration für die Sicht können Sie dem beiliegenden PDF-Dokument entnehmen.

Abbildung 3: Die neue Sicht Controlling

Nach dem Klick auf die Sicht öffnet sich dann ein Excel-Dokument. Darin werden – nach Projekt und Aktivität strukturiert – die Plan- und Ist-Zeiten der Mitarbeiter aufgelistet (siehe Abbildung 4). Mittels der Makro-Funktion Daten formatieren kann daraus dann eine flache Liste generiert werden, die eine Pivot-Auswertung für den Soll/Ist-Vergleich ermöglicht.

Abbildung 4: Das erzeugte Excel-Dokument mit Plan- und Ist-Zeiten der Mitarbeiter

Nach Formatierung der Daten erfolgt dann im Datenblatt „Pivottabelle“ der Soll/Ist-Vergleich der Mitarbeiter (siehe Abbildung 5). So lässt sich z.B. tabellarisch sowie grafisch ermitteln, wo Abweichungen zwischen den Soll- und den Ist-Zeiten liegen.

Abbildung 5: Soll/Ist-Vergleich der Mitarbeiter im Datenblatt „Pivottabelle“

Die beigefügte Excel-Vorlage mit den Berechnungen ist sicher nur ein einfaches Beispiel für eine solche Analyse. Probieren Sie es doch einmal aus und nutzen Sie in-Step auch für das projektübergreifende Controlling. Hier der Download-Link aller Komponenten für in-Step v4.9 mit Installationsanleitung:

http://www.microTOOL.de/service/in-Step/49/14/Tools/inStepTimeManExtension.zip

Haben Sie weiterer Vorschläge für die Auswertung? Wir freuen uns auf Ihr Feedback.

Projektübergreifendes Ressourcenmanagement mit in-Step

blog@microTOOL.de — Tue, 10 Apr 2012 09:53:00 +0200

Der unternehmensweite Blick: zweiter Teil unserer Mitschnitte vom in-Step Workshop in Hamburg (Video)

Der Liefertermin rückt näher? Sind weitere Mitarbeiter verfügbar? Wo freie Kapazitäten stecken, zeigt in-Step zum Beispiel im Ressourcenpool. Mitarbeiter, die noch über freie Kapazitäten verfügen, können gleich ins Projekt geholt werden. Denn mit in-Step können Ressourcen unternehmensweit gemanagt und gezielt auf einzelne Projekte verteilt werden.

Der Blick auf alle Projekte einer Organisation zeigt aber noch viel mehr …

Im zweiten Videomitschnitt vom Workshop in Hamburg demonstriert Mario Müller Ihnen – in der Rolle eines Projektmanagers bei unserer fiktiven Firma w3flex –, wie Sie in-Step jederzeit über den Stand aller Projekte in Ihrem Unternehmen informiert und wie Sie über Projektgrenzen hinweg steuernd eingreifen können.

Kunst trifft Osterhase

blog@microTOOL.de — Thu, 05 Apr 2012 09:31:00 +0200

Ein surrealer Ausflug in eine Kunstgeschichte und eine Hommage an den Osterhasen.

Viele Künstler haben sich in ihren Bildern dem Motiv des Osterhasen genähert. Manche auf individuelle Weise, andere inspiriert durch prägende Maler ihrer Zeit. Einige Werke wurden nie veröffentlicht, andere Bilder kennt jedes Kind und manche Schätze sind gar nur wenigen Kunstkennern ein Begriff.

Keith Haring erregte erstmals öffentliche Aufmerksamkeit mit seinen Kreidezeichnungen in der New Yorker Metro. Die Darstellung des "Radiant Baby" wurde zu seinem Symbol. Das Bild des "Radiant Rabbit" (Hase mit dem Strahlenkranz) entstand ungefähr zur selben Zeit und hätte leicht zu seiner bekanntesten Darstellung werden können.

1983 lernte Haring Andrej Warhola alias Andy Warhol kennen.

Anfang der 1950er entwickelte Warhol eine Technik des drop and dripping, bei der er mit Tinte und Tusche gezeichnete Motive von Engeln, Schmetterlingen, Katzen oder Osterhasen mit einem Blatt Löschpapier kopierte und auf ein neues Blatt übertrug. Gemeinsam mit Freunden malte er diese Arbeiten auf "Colouring Parties“ aus. Er suchte neue Ideen und konzentrierte sich hierbei auf triviale Elemente der Popkultur wie Hollywood-Stars oder Cartoon- und Comicfiguren wie Superman und Micky Maus. Seine "Farbigen Hasen" sind der Inbegriff der Pop Art.

Schon bald musste Warhol aber feststellen, dass andere Künsterkollegen wie Robert Rauschenberg oder Roy Lichtenstein ähnliche Motive malten. Als sich Roy Lichtenstein nach expressionistischen und surrealen Versuchen der Pop Art zuwandte, gelang ihm 1961 der Durchbruch mit dem Bild "Look Mickey". Sein Stil wurde der industrielle Stil des gedruckten Comics, heute leicht zu erkennen an den "gleichmäßigen Farbpunkten". Doch Lichtenstein war auch ein Meister der Linien, eindrucksvoll zu sehen in seinem Bild "Easter Bunny in the Meadow".

Die von Roy Lichtenstein weiterentwickelte Maltechnik "Benday Dots" (benannt nach dem amerikanischen Künstler Benjamin Day) ist heute auch ein Terrain von Damien Hirst. Hirst war 1988 Gründungsmitglied der Londoner Künstlerbewegung Young British Artists und wurde vor allem durch einen in Formaldehyd eingelegten Tigerhai, ein ebenso eingelegtes Schaf, einen mit Diamanten besetzten menschlichen Schädel sowie durch das Werk "Rabbit for the Love of Dots" bekannt.

Den Farbpunkten von Hirst und den Linien von Lichtenstein setzt der schweizerische Maler und Grafiker Richard Paul Lohse seine konkreten Flächen entgegen. Mit seiner horizontal-vertikalen Gliederung von Farbfeldern schafft er eine strukturelle Ordnung. Diese Ordnung hebt er in seiner Kreation "Da lang Hase" bewusst auf und schafft einen geradezu revolutionären und enthusiastischen Ausbruch von Vorfreude.

Ein anderer Vertreter der Farbfelder und -flächen, der niederländische Maler Piet Mondrian, geht mit seinem berühmten "Hasen=frei" noch einen wichtigen Schritt weiter. Nicht die Hasen erzeugen einen visuellen Widerstand gegen die Fläche, sondern der Osterhase selbst wird zum Farbträger. Die Silhouette des Hasen formt dabei einen bewussten Kontrast. Unbewiesen ist, ob das heutige Bemalen von Ostereiern im Werk von Mondrian seinen Ursprung hat.

Wassily Kandinsky war ebenfalls bekannt für sein ausgeprägtes Empfinden von Farbe und Form. Er ordnete Farben Bedeutungen zu und versuchte sogar, die Zugehörigkeit bestimmter Farben zu bestimmten Formen wie Kreisen, Dreiecken und Quadraten zu beweisen. Mit zunehmendem Abstraktionsgrad seiner Bilder entwickelte Kandinsky Formen von Improvisationen, bspw. in seinem Werk "Farbklänge mit Hase".

Im Gegensatz zu den Improvisationen von Kandinsky verwendete Joan Miró Symbole für Mond, Sterne, Vogel, Auge, Frau und Hase. Als Vertreter der Klassischen Moderne gehört Miró mit seinen fantasievollen Motiven zu den populärsten Künstlern des 20. Jahrhunderts. Er schuf mit über 2000 Ölbildern und 3500 Grafiken eine große Anzahl an Werken. "Conejito de Pascua" entstand laut Eintrag in seinem Notizbuch auf Mallorca, als er beim Einschlafen wieder einmal eine Erscheinung an der Decke sah.

Ohne dass seine Bilder der Pop Art zugeordnet werden können, gilt Jasper Johns als ein Wegbereiter der Pop Art. Durch den Transfer alltäglicher Motive in die Kunst nimmt Johns die späteren Konzeptionen von Lichtenstein oder Warhol im Ansatz vorweg. So ist es wenig verwunderlich, dass auch Jasper Johns schon früh in verschiedenen Variationen von "Flag" bzw. "Three Flags" andere Elemente wie bspw. Osterhasen integrierte.

Sämtliche Informationen in diesem Beitrag schrammen bestenfalls an einer surrealen Kunstgeschichte entlang. Wer sich über Kunst und die Geschichte seiner Vertreter informieren möchte, sollte dringend andere Quellen bemühen. In der Realität und Gegenwart wünschen wir Ihnen, Ihren Familien und Freunden aber auf jeden Fall schöne und bunte Ostertage.

Viele Grüße und viel Sonnenschein

Michael Schenkel

in-Step Prozess-Templates nutzen: Projekt initialisieren, Team zusammenstellen, Termine planen, los geht‘s

blog@microTOOL.de — Tue, 03 Apr 2012 06:59:00 +0200

So setzen Sie ein Projekt mit in-Step auf (Video)

Wieder einmal war unser Workshop-Team unterwegs: In Frankfurt, Düsseldorf, Hamburg, München und Wien haben wir in-Step unter dem Motto Integriertes Anforderungs- und Projektmanagement mit V-Modell XT, PRINCE2, Scrum & eigenen Prozessen vorgestellt. Die Kamera haben wir diesmal in Hamburg aufgestellt.

Thema dieses Beitrags ist die Nutzung einer eigenen Prozessvorlage mit in-Step. Dafür gehen wir ganz an den Anfang eines Projekts. Unsere fiktive Firma, der Softwarehersteller w3flex hat einen neuen Auftrag bekommen. Ein neues Projekt also, das mit in-Step geplant und durchgeführt wird. Je nach Vorgabe des Auftraggebers können Projekte mit in-Step nach einem Standard wie dem V-Modell XT, PRINCE2 oder Scrum durchgeführt werden. Macht der Auftraggeber keine Vorgabe, kommt bei w3flex ein organisationsinterner Prozess zum Zug.

Eigene Prozesse können in in-Step als Template für alle Projekte bereitgestellt werden. Das spart immens viel Planungsaufwand, sorgt für gleiches Vorgehen und einheitliche Ergebnisse in den Projekten. Von der Projektinitialisierung bis zum Beginn der ersten Aktivität sind es dann nur wenige Mausklicks. Im Film zeigt Ihnen Michael Schenkel – in der Rolle eines Projektleiters – wie Sie so ein Template nutzen:

Wie könnte es weitergehen? Ein Anforderungsanalytiker könnte sich ans Werk machen, die ersten Anforderungen erstellen oder schon formulierte aus einem Word-Dokument importieren. Dann könnte er z.B. ein Lastenheft erzeugen. Wenn Sie Lust haben, können Sie sich genau das in einem Videomitschnitt von den Workshops aus dem vergangenen Jahr anschauen: Anforderungsmanagement mit in-Step: So entsteht ein Lastenheft.

Ein weiterer Beitrag vom Workshop in Hamburg folgt demnächst. Schauen Sie doch wieder mal hier vorbei.

Ein Stück Prozessmodell aus einem in-Step-Projekt in ein anderes übernehmen

blog@microTOOL.de — Thu, 29 Mar 2012 09:44:00 +0200

Standen Sie schon einmal vor der Aufgabe, Teile eines Prozessmodells aus einem Projekt in ein anderes zu übernehmen? Zum Beispiel, weil Sie für Ihre Formulare Produkttypen aus einem anderen Prozess verwenden wollten? Die benutzerdefinierten Eigenschaften der Instanzkategorien von Formularen können viele benutzerdefinierte Eigenschaften haben. Die möchte man ungern noch einmal erfassen. Gleiches gilt für Zustandsautomaten, die ja oft eine gewisse Komplexität erreichen.

Kurz: Sie wollten nicht den gesamten Prozess Ihres Projekts durch einen anderen ersetzen, sondern lediglich einen kleinen Ausschnitt aus einem anderen Prozessmodell für Ihr Projekt übernehmen. Nur, auf den ersten Blick haben Sie in in-Step keine spezielle Funktion gefunden, mit der Sie diese Aufgabe erledigen können? Mit einem kleinen Trick geht es ohne großen Aufwand.

Ein Beispiel

Nehmen wir einfach ein Scrum-Projekt. Stellen Sie sich vor, dass Sie sich dort in einer systemweiten Sicht auch die Anforderungen aus einem anderen Projekt ansehen möchten und zwar inklusive diverser benutzerdefinierter Eigenschaften, wie z.B. der Anforderungsnummer. Diese Eigenschaft wird Ihnen aber bei der Spaltendefinition der Sicht nicht zur Auswahl angeboten, weil die zugehörige Kategorie REQUIREMENT in diesem Projekt gar nicht bekannt ist. Das heißt: Sie brauchen auch in Ihrem Scrum-Projekt die Kategorie REQUIREMENT.

So sieht die Kategorie REQUIREMENT in dem Projekt aus, in dem Sie die Anforderungen pflegen:

Verwendet wird diese Kategorie vom Produkttyp Anforderung als Instanzkategorie.

Beide Dinge lassen sich nicht "mal eben so" exportieren und in einem anderen Projekt wieder einfügen. Aber, jetzt kommt der Trick.

Der Trick

Eine entsprechende Exportfunktion gibt es in in-Step schon. Sie ist allerdings zurzeit nur für Aktivitätstypen definiert. Sie können sie trotzdem nutzen, um Ihre Aufgabe zu lösen. Legen Sie für den Export Ihrer Kategorie einen „Dummy“-Aktivitätstyp an. Er benötigt keine besonderen Eigenschaften. Und damit er im Projekt nicht "stört", geben Sie ihm die Kardinalität "0".

In der Liste der Aktivitätstypen taucht nun auch Ihr „Dummy“-Aktivitätstyp auf.

Ist der neue Aktivitätstyp markiert? Dann können Sie gleich in der Symbolleiste auf die Schaltfläche Produktfluss klicken. Legen Sie im Produktfluss-Dialog einen Ein- oder Ausgangstypen für den „Dummy“-Aktivitätstypen an. Dafür verwenden Sie einen Produkttypen, der die benötigte Kategorie als Instanzkategorie besitzt, in unserem Fall also den Produkttyp Anforderung.

Speichern Sie Ihre Angaben mit OK.

Auf diese Weise haben Sie eine Abhängigkeit zwischen dem „Dummy“-Aktivitätstyp und der in Ihrem Projekt benötigten Kategorie geschaffen. Jetzt müssen Sie im Kontextmenü des „Dummy“-Aktivitätstyps nur noch Exportieren wählen. Nach Eingabe des Namens wird die Exportdatei von in-Step erzeugt und Sie erhalten umgehend eine solche Erfolgsmeldung:

Und so kommt die Kategorie REQUIREMENT in Ihr Scrum-Projekt

Nun wechseln Sie in das Projekt, in dem die Kategorie REQUIREMENT benötigt wird – in unserem Beispiel ist das ein Scrum-Projekt. Die Liste der Aktivitätstypen könnte dort etwa so aussehen:

Wählen Sie nun im Kontextmenü des obersten Aktivitätstypen Importieren. Nachdem Sie die von Ihnen erzeugte Export-Datei für den Import ausgewählt haben, können Sie noch einige Dinge optional einstellen.

In unserem Fall behalten Sie die Standardeinstellungen bei und starten den Import gleich mit OK. Der Ablauf des Import-Prozesses wird in einem eigenen Fenster protokolliert.

Sie sehen, dass neben dem „Dummy“-Aktivitätstyp und dem Produkttyp Anforderung noch weitere damit verbundene Objekte übernommen wurden. Prüfen Sie gleich einmal den Erfolg Ihrer Arbeit.

In der Liste der Aktivitätstypen finden Sie in Ihrem Scrum-Projekt nun einen neuen Aktivitätstyp.

Und in der Liste der Produkttypen gibt es jetzt auch in Ihrem Scrum-Projekt den Produkttyp Anforderung .

Schauen Sie auch in den Kategorien nach.

Sie sehen, Sie haben Ihr Ziel erreicht: Die Kategorie REQUIREMENT wurde erfolgreich importiert. Sie können sie nun nach Belieben in Ihrem Scrum-Projekt verwenden.

Übrigens: Die Dummy-Aktivität kann wieder gelöscht werden. Auch andere Objekte, die beim Import mitgekommen sind, aber nicht benötigt werden, können Sie einfach wieder entfernen.

Anforderungsgerechte Systeme = anwendergerechte Systeme?

blog@microTOOL.de — Thu, 22 Mar 2012 07:31:00 +0200

User Modelle im Requirements Engineering (mit Video)

Kennen Sie das? Sie arbeiten an den Requirements für ein System und kommen nicht recht weiter: Was soll die Funktion genau tun und wie wichtig ist sie für den Anwender? Wer ist „der Anwender“ überhaupt? Würde der Anwender im Kontext dieser Funktion nicht auch gern …? Sie tun sich schwer, den tatsächlichen Bedarf der Anwender zu benennen, und können niemanden fragen, weil Sie z. B. Softwareprodukte für den Markt entwickeln – wie wir?

Was nützen in einer solchen Situation ingenieurmäßige Artefakte, wie die aussagestarken Requirements Diagramme der SysML™? (Ich habe sie Ihnen in meinem vorletzten Beitrag über den neuen objectiF^® Requirements Modeller, an dem wir gerade arbeiten, vorgestellt.)

Ein Requirements Diagramm nach OMG SysML™: Es integriert die Anforderungstexte in ein Modell und zeigt unter anderem die „Enthält“- und „Ist-Abgeleitet-Aus“-Beziehungen zwischen den Requirements

Sicher, Modelle helfen als Strukturierungs- und Kommunikationsmittel bei der Entwicklung anforderungsgerechter Systeme. Aber auch bei der Entwicklung anwendergerechter Systeme?

Ja, wenn man sie mit Instrumenten aus einer ganz anderen Welt kombiniert …

Beim Usability Engineering abgeguckt

Ich habe Ihnen schon davon berichtet (unter anderem in diesem Beitrag), wie wir versuchen, das Fehlen der Anwender in unseren Teams durch eine etablierte Technik aus dem Usability Engineering zu kompensieren: mit User-Modellen oder Personas.

Personas sind lebendige Beschreibungen fiktiver Anwender eines Systems. Sie sind also Anwender, die es in der Realität zwar nicht gibt, die es aber geben könnte. Eine Persona repräsentiert eine Anwendergruppe. Die Personas mit ihren Zielen, ihrem Bedarf und ihrem Verhalten sollen die Projektbeteiligten immer im Kopf haben – egal, ob sie Anforderungen ermitteln, die Systemarchitektur entwerfen, codieren oder testen.

So sollen Personas wirken: Alle im Team haben bei der Arbeit ein einheitliches Bild der Anwender im Kopf und können sich besser in sie hineindenken

Wir haben uns auf diese Technik eingelassen. Wir haben Personas mit Blick auf unsere Produkte entwickelt. Es wird vielfach empfohlen, Personas im firmeneigenen Intranet zu dokumentieren. Haben wir gemacht. Liest keiner. Und selbst wenn: Kann keiner so richtig einordnen. Deshalb haben wir Workshops mit den Projektteams durchgeführt und die Personas einzeln vorgestellt. Im Anschluss daran sind die Personas dann in die Teamräume „eingezogen“. In Form von Plakaten sind sie jetzt bei der Arbeit präsent.

Wer sind unsere Anwender? Jede Anwendergruppe wird durch eine Persona „vertreten“ – direkt am Arbeitsplatz der Entwickler

Jetzt haben alle Mitarbeiter unsere Personas als Repräsentanten der Anwender immer vor ihren Augen. Aber ein Schritt fehlt noch.

Welche Persona „braucht“ welche Anforderungen?

Wie kann man beim Ermitteln und Analysieren der Anforderungen festhalten, welche Anforderung von welcher Persona stammen könnte? Erst wenn man diesen Zusammenhang hergestellt hat, können sich die Entwickler bei der Realisierung der Anforderungen auf den spezifischen Bedarf der Persona einstellen.

Um die Dokumentation der Personas mit den Ergebnissen des Requirements Engineering zusammenzuführen, haben wir uns eine „private“ Erweiterung der SysML™ Requirements Diagramme geschaffen. Sie ermöglicht es, im Requirements Diagramm festzuhalten, welche Persona welche Anforderung ganz besonders braucht. Schauen Sie selbst:

Das Requirements Diagramm wird vom Requirements Engineer an die Softwareentwickler weitergereicht. Für die Softwareentwickler stellt es die Beziehung zwischen den Personas – von denen inzwischen ein lebendiges Bild in den Köpfen existiert – und den zu bauenden Funktionen her.

Den Anwendern des objectiF^® Requirements Modellers wird diese Erweiterung übrigens auch zur Verfügung stehen.

Dieser Beitrag geht auf einen Erfahrungsbericht mit dem Titel „Mit der Kraft der Personas: User-Modelle im Requirements Engineering“ zurück, den ich in der vergangenen Woche auf der Requirements Engineering Tagung ReConf 2012 in München gehalten habe.

Verantwortung auf Raten – oder Projektmanagement nach PRINCE2

blog@microTOOL.de — Thu, 15 Mar 2012 12:14:00 +0200

PRINCE2® ist eine strukturierte Projektmanagement-Methode, die sich aus einem Standard britischer Behörden entwickelt hat und inzwischen international weit verbreitet ist. Auch wir stellen ein wachsendes Interesse an PRINCE2® und der in-Step PRINCE2 Edition fest. Deshalb habe ich Ihnen hier die Merkmale dieser Methode einmal zusammengefasst. "PRINCE2® in a Nutshell" sozusagen.

Was macht diese Projektmanagement-Methode aus? Wesentliche Unterscheidungsmerkmale zu anderen PM-Methoden sind einerseits die strikte Orientierung an der geschäftlichen Rechtfertigung des Projektes (Business Case) sowie die Steuerung über Managementphasen, an deren Ende das weitere Vorgehen anhand der Phasenergebnisse, des Business Case und des Projektplanes beschlossen wird.

Durch die starke Bindung des Projekts an den Business Case liegt die Projektverantwortung in PRINCE2®-Projekten stärker in der Managementebene. Der Projektleiter hat hier eine eher koordinierende Tätigkeit und trägt nur die Verantwortung für die jeweilige Managementphase.

Prinzipien

Die folgenden Prinzipien stehen im Mittelpunkt der PRINCE2®-Projekte

Fortlaufende geschäftliche Rechtfertigung

Voraussetzung für ein PRINCE2®-Projekt ist immer ein vertretbarer Grund, welcher im Business Case Dokument festgehalten wird.

Lernen aus Erfahrung

Zum Projektstart werden Erfahrungen aus ähnlichen, vergangenen Projekten gesammelt. Im Projektverlauf sollten die gemachten Erfahrungen dokumentiert werden.

Definierte Rollen und Verantwortlichkeiten

In PRINCE2®-Projekten gibt es immer eine definierte Projektmanagement-Teamstruktur, diese legt die Aufgaben- und Verantwortungsbereiche der Teammitglieder fest.

Steuern über Managementphasen

PRINCE2®-Projekte werden in Phasen unterteilt. Zum Abschluss jeder Phase wird stets anhand des Business Case geprüft, ob und wie das Projekt fortgeführt wird.

Steuern nach dem Ausnahmeprinzip

Die Entscheidungsbefugnisse liegen bei PRINCE2®-Projekten in den unteren Management-Ebenen, solang sie sich im Rahmen bestimmter Toleranzbereiche bewegen.

Produktorientierung

in den Projekten steht die Definition, Lieferung und Qualität der Produkte im Mittelpunkt. Bei der Planung werden immer zuerst die Produkte definiert, erst dann die Aktivitäten.

Anpassen an die Projektumgebung

PRINCE2® kann in Bezug auf Größe, Umfeld, Komplexität, Wichtigkeit, Potenzial und Risiken eines Projektes angepasst werden.

Themen

Themen bilden die Grundlage für die im Rahmen des Projektes erstellten Dokumente und beantworten die zentralen Fragen zum Aufbau und Verlauf des Projektes.

Business Case - Warum?

Der Business Case liefert die geschäftliche Rechtfertigung des Projektes.

Organisation - Wer?

PRINCE2® definiert vier Management-Ebenen.

Ein Alleinstellungsmerkmal vom PRINCE2® ist, dass die Gesamtverantwortung für Projekte nicht allein bei einer Management-Ebene liegt, sondern von einem Project Management-Team wahrgenommen wird, welches sich aus den drei Ebenen Lenkungsausschuss (Project Board), Projektleiter (Project Manager) und Teamleiter (Team Manager) zusammensetzt.

Die Aufgaben und Verantwortungen für die einzelnen Prozesse, Themen und Ausnahmen des Projektes und die daraus resultierenden Informationsflüsse zwischen den Beteiligten am Project Management Team sind klar definiert.

Qualität - Was?

Zur Gewährleistung hoher Qualitätsansprüche wird in PRINCE2®-Projekten eine Qualitätsmanagement-Strategie aufgestellt.

Pläne - Wann?

Plane werde für verschiedene Planungsebenen (Projekt, Phase, Ausnahmen, Team) erstellt.

Risiken - Was wenn?

Der Lenkungsausschuss legt einen Risikomanagement-Strategie fest.

Änderungen - Was ist die Auswirkung?

Die Konfigurationsmanagement-Strategie und das KM-System sind die Basis des Änderungsmanagements.

Fortschritt - Wo stehen wir? Wohin bewegen wir uns? Sollen wir weiter machen?

Das Prinzip „management by exception“ liefert einen wichtigen Beitrag zu Fortschrittskontrolle. Dadurch führen Überschreitungen der definierten Toleranzwerte automatisch zur Eskalation in die nächste Managementebene, wo das weitere Vorgehen dann bestimmt werden muss.

Wenn die Toleranzwerte sinnvoll definiert wurden, so sollte das Projekt geführt durch diese „Leitplanken“ auf einem stabilen Pfad verlaufen.

Weiter werden die Fortschritte im Rahmen der Managementphase oder an definierten Prüf- und Entscheidungspunkten kotrolliert.

Prozesse

Die verschiedenen Schritte des Projektmanagements werden in den Prozessen beschrieben.

Jedes PRINCE2®-Projekt muss jeden dieser Prozesse in irgendeiner Form durchlaufen. Das bedeutet, dass die Prozesse auf die Anforderungen des Projektes zugeschnitten werden. Es darf aber kein Prozess weggelassen werden.

Vorbereitung eines Projekts (SU)

In diesem Prozess werden Projektauftraggeber und Projektmanager, der Business Case-Entwurf wird erstellt und es werden Projektlösungsansätze ausgewählt.

Lenken eines Projekts

Dieser Prozess erstreckt sich über die Dauer des gesamten Projekts und regelt unter anderem die Freigabe von Phasen- oder Ausnahmeplänen und den Projektabschluss.

Initiieren eines Projekts (IP)

Im Rahmen dieses Prozesses werden die Projektsteuerungsmittel eingerichtet, der Projektplan erstellt und der Business Case verfeinert.

Steuern einer Phase

Der Prozess zur Phasensteuerung gibt Arbeitspakete frei und prüft deren Status, ebenso wie den Status der Phase insgesamt. Die abgeschlossenen Arbeitspakete werden entgegengenommen.

Managen der Produktlieferung

Der Prozess der Produktlieferung beschäftiget sich mit dem annehmen, ausführen und abliefern der Arbeitspakete.

Managen eines Phasenübergangs (SB)

In diesem Prozess geht es um den Abschluss einer Phase und die Vorbereitung der nachfolgenden Phase.

Abschließen eines Projekts (CP)

Der Prozess zum Abschluss des Projektes bereitet den planmäßigen Abschluss vor oder – wenn das Projekt vorzeitig beendet wird – den vorzeitigen Abschluss.

Viele Punkte, die es zu bedenken gilt …

Mit unserer in-Step PRINCE2 Edition können wir Sie bei der Planung und Durchführung Ihrer PRINCE2®-Projekte unterstützen. Ihre Projektstruktur können Sie schnell und effizient mit unserem integrierten PRINCE2® Projektplanungs-Assistent aufbauen. Und nicht nur die Struktur ist dann schon definiert, auch die notwendigen Dokumente (Produkte) zu Ihren Projektphasen sind automatisch vorbereitet. Sie können also gleich loslegen!

Probieren Sie es aus.

Tastaturkürzel für das Versionsmanagement mit in-Step in MS Word

blog@microTOOL.de — Thu, 08 Mar 2012 09:29:00 +0200

Heute mal wieder ein kleiner Tipp zum Thema in-Step und MS Word: In MS Word haben Sie die Möglichkeit, Tastenkürzel zum Ausführen von Befehlen zu konfigurieren. Entsprechend können Sie auch die Befehle von in-Step mit Tastenkürzel versehen.

Als Beispiel möchte ich Ihnen zeigen, wie ich die Tastenkombination Strg+Shift+A mit der Ausleih-Funktion von in-Step verknüpfe. Das geht in MS Word 2007/2010 aber auch in älteren Word-Versionen.

Sie arbeiten mit MS Word 2007/2010?

Ich öffne ein beliebiges Word-Dokument und wechsle dann in die Word-Optionen über Datei/Optionen (MS Word 2010) bzw. Office-Symbol/Word-Optionen (MS Word 2007).

In den Word-Optionen wechsle ich dann auf Menüband anpassen (MS Word 2010) bzw. Anpassen (MS Word 2007):

In diesem Bereich findet man bei beiden Word-Versionen am unteren linken Rand die Option Tastenkombinationen:

Dort klicke ich auf Anpassen. Im Folgedialog kann ich nun für einzelne Befehle eine Tastenkombination festlegen.

Hinter jedem unserer Befehle für das Versionsmanagement in in-Step liegt ein Makro. Um zum Beispiel ein Tastenkürzel für den Ausleihen-Befehl festzulegen, kann ich mir also einfach unter der Kategorie Makros den passenden Befehl aussuchen:

Die Tastenkombination gebe ich an, indem ich die entsprechenden Tasten drücke:

Bevor ich die Zuordnung übernehme, muss ich noch festlegen, in welcher Vorlage ich diese Tastenkombination verwenden möchte. Da ich den Befehl in jedem Dokument über diese Tastenkombination ausführen möchte, speichere ich die Zuordnung in der Normal.dotm.

Vorsicht: Dadurch überschreibt man u.U. die Tastenkombination für einen Befehl, die standardmäßig angeboten wird. In meinem Fall wäre es das Öffnen der Schriftarten.

Wollen Sie die Zuordnung wieder aufheben, können Sie dies über denselben Dialog vornehmen.

Sie verwenden noch eine ältere Version?

Kein Problem: Über den Hauptmenübefehl Extras/Anpassen gelangen Sie bei Word 2003 in den Anpassungsdialog. Auf der Registerkarte Befehle finden Sie die Schaltfläche Tastatur:

Sie gelangen zu einem ähnlichen Dialog wie in MS Word 2007/2010, der sich genauso nutzen lässt:

Solche Tastaturkürzel machen Ihre Arbeit mit in-Step noch schneller. Also: Hit the buttons!

in-Step & Scrum in der Praxis: Wenn zu einer erledigten Story noch eine neue Task hinzukommt

blog@microTOOL.de — Tue, 28 Feb 2012 08:30:00 +0200

Storys entsprechen in einem Scrum-Projekt den Kundenanforderungen. Sie beschreiben die zu realisierenden Funktionen aus Anwendersicht und werden bei der Sprintplanung mit in-Step in einzelne Aufgaben, die Tasks, zerlegt. Scrum ist ein agiler Prozess, der auf Flexibilität und selbstorganisierte Teams setzt, um die Storys im Dialog mit dem Auftraggeber zeitnah umzusetzen. Und da kann schon einmal Folgendes passieren: Eine Story ist bereits erledigt, aber noch nicht abgenommen, und jetzt hat sich noch eine neue Task ergeben. Zum Beispiel könnten sich wie hier Änderungen hinsichtlich der Browserkompatibilität ergeben haben: Da soll die zu erstellende Anwendung nun nicht nur Standard-Browser, sondern auch mindestens eine Mobil-Version unterstützen.

Wäre es da nicht schön, wenn Sie wie in diesem Screenshot der erledigten Story einfach eine neue Task hinzufügen könnten und der Zustand der betreffenden Story gleich von erledigt zurück zu in Bearbeitung wechseln würde? Wie Sie das erreichen, zeige ich Ihnen heute. Zwei Dinge müssen Sie tun:

den Zustandsautomaten für Storys anpassen und
den Menübefehl zum Anlegen von Tasks neu konfigurieren

Und das geht so…

Zustandsautomaten anpassen

Als Erstes müssen Sie den Zustandsautomaten für Storys – standardmäßig heißt er in in-Step … für Story – bearbeiten.

Legen Sie auf der Registerkarte Ereignisse – mit einem Klick auf Hinzufügen – ein neues Ereignis an, das Sie wie hier z.B. Task angelegt nennen.

Dann fügen Sie für das Ereignis auf der Registerkarte Zustandsübergänge einen Zustandsübergang von erledigt nach in Bearbeitung hinzu. Entfernen Sie auch gleich das Häkchen in der Spalte Sichtbar, denn dieser Übergang soll nicht im Kontextmenü von Storys angeboten werden.

Weitere Änderungen sind am Zustandsautomaten nicht erforderlich. Sie müssen die Einstellungen nur noch mit OK bestätigen.

Befehl zum Anlegen einer Task neu konfigurieren

Öffnen Sie anschließend den Komponentendialog mit Projekt/Komponenten im Hauptmenü von in-Step und markieren Sie dort den CommandServer … für Produkte (CoreProcess).

Klicken Sie auf Konfigurieren, um die verfügbaren Befehle anzuzeigen. Um zu einer Story eine neue Task anzulegen, wird der Befehl NewTaskforthisStory verwendet.

Ein Doppelklick auf den Namen zeigt die aktuelle Konfiguration des Befehls. Wählen Sie dort unter Einstellungen zum Quellprodukt bei Zu empfangendes Ereignis das neue Ereignis Task angelegt aus, denn dieses Ereignis soll nun beim Anlegen einer Task an die zugehörige Story geschickt werden.

Damit der Befehl Task zu dieser Story anlegen im Kontextmenü einer erledigten Story angeboten wird, muss außerdem erledigt in der Liste Sichtbar im Zustand unter Weitere Einstellung erscheinen.

Übernehmen Sie die geänderte Einstellung mit OK und schließen Sie alle Dialoge.

Zukünftig wechselt in Ihrem Projekt eine erledigte Story automatisch in den Zustand in Bearbeitung, wenn Sie ihr mit Task zu dieser Story anlegen eine neue Task hinzufügen.

Viel Spaß beim Ausprobieren!

in-Step meets SharePoint: Arbeiten mit CMIS Repositories

blog@microTOOL.de — Tue, 21 Feb 2012 09:26:00 +0200

Teil 5: Eigenschaften beliebiger Produkte editieren – Die CMIS-Schnittstelle (Fortsetzung)

In Teil 4 der "in-Step meets SharePoint"-Pentalogie haben Sie gesehen, wie in in-Step abgelegte Dokumente von SharePoint aus nicht nur angesehen, sondern auch bearbeitet werden können. Die technische Grundlage dafür ist CMIS.

Fast alle hierarchischen in-Step-Produktsichten können als CMIS-Repository veröffentlicht werden. Damit können alle Produkte in SharePoint geändert werden. Es lassen sich auch die benutzerdefinierten Eigenschaften dieser Produkte direkt in SharePoint bearbeiten – und das ist sehr wichtig.

Beispiel: Risikomanagement

Ein Risiko ist z.B. ein typisches Produkt aus in-Step, das sich rein über seine Eigenschaften definiert. Sind Sie schon neugierig, wie sich diese Risiken in SharePoint bearbeiten lassen? Kann man von SharePoint aus vielleicht sogar neue Risiken anlegen?

Am besten sehen Sie sich das selbst an. Wir haben wieder einen kurzen Film für Sie vorbereitet. Er beginnt in in-Step mit der Veröffentlichung der Risikosicht via CMIS. SharePoint-seitig wird dann im CMIS Consumer Web Part eingestellt, dass auf die Risiko-Sicht als Repository zugegriffen werden soll. Und schon sind die Risiken des Projekts auch in SharePoint sichtbar.

Dann wird in SharePoint ein neues Risiko anlegt – mit Namen und der benutzerdefinierten Eigenschaft Eintrittswahrscheinlichkeit. Sie wollen die Eintrittswahrscheinlichkeit auch in SharePoint in der Listendarstellung sehen? Gute Idee, dann blenden Sie einfach die Spalte mit ein.

Der Blick zurück nach in-Step zeigt: Das neue Risiko ist wohlbehalten in in-Step angekommen.

Mehrere Sichten für das Bearbeiten von Produkten bereitstellen

Wenn Sie mehrere Sichten aus in-Step auf Ihren SharePoint-Seiten verfügbar machen wollen, aber nicht zwischen Repositories umschalten möchten, können Sie auch mehrere Instanzen des CMIS Consumer Web Parts einsetzen. Allerdings erlaubt SharePoint pro Seite nur einen CMIS Consumer Web Part. Sie müssten die Sichten auf entprechend viele SharePoint-Seiten verteilen.

Zum Nachlesen

Die Serie "in-Step meets SharePoint" ist mit diesem Beitrag abgeschlossen. Zur Abrundung haben wir für Sie noch eine kompakte Funktionsübersicht für die in-Step SharePoint-Extension und die in-Step CMIS-Extension erstellt. Wenn Sie die Funktionen, die diese Extensions bereitstellen, kurz und knapp zusammengefasst nachlesen möchten, können Sie das PDF (399,51 KB) hier herunterladen .

Ich freue mich auf Ihre Fragen und Anregungen zur Arbeit mit in-Step und SharePoint.