Ursula Meseberg

Ursula
Meseberg

About the Author

Agiles Requirements Engineering – zweite Etappe: Das Requirements Backlog – Kundenanforderungen zusammenführen

Written by Ursula Meseberg on 4/24/2014 8:45:00 AM

Unsere jährliche Anwenderkonferenz steht vor der Tür. Ich freue mich darauf, am 14. und 15. Mai in Berlin spannende Gespräche mit den Anwendern unserer Tools zu führen. Und ich freue mich auf die vielen kleinen und großen Aha-Erlebnisse: „So werden unsere Tools auch genutzt ... wow, sogar das kann man damit machen ... daran hatten wir noch gar nicht gedacht.“ Gerade weil unsere Softwareprodukte intensiv genutzt und in spezifischen Situationen eingesetzt werden, haben die Anwender viele Wünsche, Ideen und Anforderungen – und das nicht nur zur Anwenderkonferenz. Wie wir mit den Kundenanforderungen umgehen, die uns in unterschiedlicher Form erreichen, wie wir sie analysieren und so festhalten, dass sie auf den Kunden zurückführbar bleiben, habe ich in meinem letzten Beitrag Agiles Requirements Engineering – erste Etappe: Kundenanforderungen verstehen beschrieben.  

Auf der heutigen zweiten Etappe des Agilen Requirements Engineering geht es darum, wie man die Anforderungen vieler Kunden zusammenführt, oder besser gesagt, wie wir das bei der Weiterentwicklung unserer Produktlinie konkret tun.

Grundlage ist ein zentrales Requirements Backlog in in-Step RED. Wie das Backlog strukturiert ist, wie eine Kundenanforderung in Backlog Items zerlegt wird und wie dieser Vorgang nachvollziehbar bleibt – das zeigt dieser kurze Film:

Ein Stück des Weges ist geschafft. Aber einige wichtige Fragen sind noch offen: Wie geht das mit dem Priorisieren der Backlog Items? Können die Epics im Requirements Backlog für die Release-Planung benutzt werden? Wenn ja, wie? Wie kommen wir zum Product Backlog, mit dem wir die agile Entwicklung steuern? Bleibt der Weg der Kundenanforderung bis zum Schluss nachvollziehbar? Und wie funktioniert das mit der Sprint-Planung? Demnächst geht es weiter mit:

Etappe 3: Von Epics im Requirements Backlog zu User Stories im Product Backlog.

Etappe 4: Vom Product Backlog in die Sprint-Planung. 

 

Tags: , ,

Agiles Requirements Engineering – erste Etappe: „Wir hätten da gerne noch...“ – Kundenanforderungen verstehen

Written by Ursula Meseberg on 3/26/2014 9:01:00 AM

Unsere Kunden erzählen keine Geschichten

Wenn Sie Softwareprodukte entwickeln, dann kennen Sie das: Anforderungen von Kunden können jede nur erdenkliche Form besitzen – von einer E-Mail mit ein paar Sätzen der Art „Wir hätten da gern noch ...“ bis zu einem umfangeichen Lastenheft. User Stories, die direkt in die agile Entwicklung einfließen können, "erzählen" unsere Kunden nur selten.

Im Beitrag Agiles Requirements Engineering – gibt’s das überhaupt? habe ich ein Framework für agiles Requirements Engineering im Vorfeld agiler Softwareentwicklung vorgestellt. Ausgehend von Kundenanforderungen – in welcher Form auch immer – liefert es in kurzen Iterationen User Stories für das Product Backlog. Hier ist noch einmal der Ablauf im Überblick:

Das Analysieren und Zerlegen der Kundenanforderungen, das Verwalten von Anforderungen, Epics und User Stories in mehreren Backlogs – ist all das praktikabel? Bleibt jederzeit transparent und nachvollziehbar, was aus einer Anregung, Idee oder Anforderung eines Kunden geworden ist? Für die Lösung, die ich Ihnen vorstellen möchte (und die wir selbst in unserer Produktentwicklung praktizieren), lautet die Antwort auf beide Fragen ja. Das liegt nicht zuletzt an der Tool-Unterstützung durch das neue in-Step RED.

Ich lade Sie zu einer kleinen Reise ein: Begleiten Sie eine Kundenanforderung durch das Requirements Engineering bis hin zur spezifizierten Komponente. Die Reise führt über das Requirements Backlog zum Product Backlog und schließlich zur Sprint-Planung. Und sie führt Sie mitten hinein in in-Step RED.

Heute geht es auf die erste Etappe ...

More

Tags: , ,

Agiles Requirements Engineering – gibt’s das überhaupt?

Written by Ursula Meseberg on 3/4/2014 8:40:00 AM

Agiles Requirements Engineering – ist das nicht ein Widerspruch in sich? Heißt Requirements Engineering denn nicht, eine Unmenge an Dokumentation zu erzeugen, eine Anforderungsspezifikation, die leicht auf viele Hundert Seiten anwachsen kann? Eine Spezifikation, für die dann irgendwann Redaktionsschluss ist. Sorry, liebe Stakeholder, Änderungen werden nicht mehr angenommen. Dagegen ist Dokumentation bei agiler Entwicklung doch gar nicht nötig? Anforderungen sind es auch nicht. Dafür gibt es ja die kurzen, knappen User Stories. Und basiert agil nicht auf dem Prinzip, ständig alles wieder zu ändern? Das passt doch nicht zusammen – oder?

Richtig ist ...

  • User Stories für die agile Softwareentwicklung fallen nicht vom Himmel. In größeren Projekten ist eine Analyse der Stakeholder, ihrer Ziele und Anforderungen notwendig, um User Stories zu finden, die zu erwartungskonformen und wertschöpfenden Lösungen führen. Das Requirements Engineering bietet dafür die geeigneten Mittel.
  • Das Agile Manifest wertet funktionierende Software höher als Dokumentation. Damit erklärt es Dokumentation aber nicht für nutzlos.
  • Änderungen der Anforderungen sollten immer willkommen sein – wie in den agilen Prinzipien formuliert. Denn Rahmenbedingungen wechseln, Stakeholder lernen dazu, der Bedarf ändert sich. Änderungen sollten auf möglichst kurzem Weg mit wenig Zeitverzug in die Entwicklung einfließen.

Vergessen wir Mythen, Missverständnisse und Vorurteile. Agilität und Requirements Engineering sind keine unvereinbaren Gegensätze. Im Gegenteil. 

In diesem Beitrag gebe ich Ihnen einen Überblick über einen Prozess – oder sagen wir besser ein Framework – für agiles Requirements Engineering. In kommenden Beiträgen werde ich das Framework detaillieren und Ihnen zeigen, wie wir es für unsere eigene Entwicklung ausgeprägt und mit in-Step RED unterstützt haben. So viel sei verraten: Mit in-Step RED geht das richtig gut. Die Entwicklung wird leicht nachvollziehbar und für alle Beteiligten transparent. 

Ein Blick in das „wahre“ Leben: So haben wir unsere agile Entwicklung und unser Requirements Engineering mit 
in-Step RED organisiert: Oben rechts eine Sicht auf die offenen User Stories. Darunter die Sicht auf einen Sprint. Wie Sie am Datum und dem Status der Stories erkennen, ist er bereits erfolgreich abgeschlossen.

More

Tags: , ,

in-Step RED – Wenn Sie eigene Ausdrucksmittel bei der Anforderungsanalyse brauchen

Written by Ursula Meseberg on 11/28/2013 8:45:00 AM

Eigene Stereotypen definieren – am Beispiel des Systemkontextdiagramms

Heute zeige ich Ihnen, wie Sie die Ausdrucksmittel individuell erweitern können, die Ihnen in-Step RED für die modellbasierte Analyse von Anforderungen bietet. Der Schlüssel dazu ist die Definition eigener Stereotypen. Damit können Sie Modellelementen eine neue oder veränderte Bedeutung geben. Wenn Sie sich mit der UML auskennen, dann kennen Sie diese Erweiterungstechnik. In in-Step RED können Sie sie auf viele Artefakte anwenden, nicht nur auf die der UML. Wie das geht, sehen Sie am Beispiel des Systemkontextdiagramms.

Am Anfang des Weges durch das Requirements Engineering …

... liegt bereits der erste Stolperstein: Wenn man den Kontext des geplanten Systems nicht richtig versteht, fehlen am Ende möglicherweise wichtige Funktionen und Schnittstellen.

Schon als noch niemand von Requirements Engineering oder Business Analysis sprach und man noch Systemanalyse machte, kannte man im Rahmen der Strukturierten Analyse nach DeMarco das Kontextdiagramm. Es zeigte das geplante System seine externen Schnittstellen und den Informationsfluss dazwischen.

Ein "klassisches" Informationsflussdiagramm für den Systemkontext, erstellt mit case/4/0

In in-Step RED haben Sie gleich drei Möglichkeiten, den Kontext eines Systems zu modellieren.

  • Für technische Systeme ist das Blockdiagramm der SysML häufig das geeignete Instrument.
  • Wenn Sie Prozesse automatisieren, sind Use-Case-Diagramme der UML für die Kontextmodellierung meistens das Mittel der Wahl.
  • Und dann gibt es noch einen Allrounder, der dem klassischen Kontextdiagramm sehr nahe kommt: das Systemkontextdiagramm.

Und das sehen wir uns einmal näher an.

Systemkontextdiagramm in RED

Mit in-Step RED können Sie in einem Systemkontextdiagramm Folgendes abbilden:

  • das geplante System (als Kästchen vom Stereotyp «PlannedSystem»),
  • Personen, die mit dem System interagieren (als «Actor»),
  • Systemkontextelemente, d.h. Systeme, Prozesse oder Ereignisse im Umfeld des geplanten Systems, die im Austausch mit dem System stehen bzw. darauf einwirken, (dargestellt als rot umrandete Kästchen vom Stereotyp «SystemContextElement»),
  • Regeln, d.h. Gesetze, Standards oder Dokumente, die Einfluss auf das System haben (gelb umrandete Kästchen vom Stereotyp «SystemContextRule»),
  • Systemkontextelemente oder Regeln, die als irrelevant für das System erkannt wurden (grau umrandete Kästchen).

Das entspricht dieser Einteilung der „Welt“:

Zur Begrifflichkeit

Wie ein solches Diagramm aussieht und was Sie tun können, wenn Sie mit dem Stereotyp «SystemContextElement» nicht auskommen, sehen Sie in diesem kurzen vertonten Film:

 

Tags: , ,

in-Step RED – Muster für die Projektplanung und Projektarbeit entwickeln und anwenden

Written by Ursula Meseberg on 11/19/2013 8:31:00 AM

Im Beitrag Das neue in-Step RED – Planen mit Mustern hat Yvonne Kaiser Ihnen vor Kurzem hier ein Video präsentiert. Es zeigt, wie man Muster bei der Projektplanung mit unserer neuen Software für anforderungsbasierte Projekte benutzen kann. Mit Mustern können Sie sich als Projektleiter, Requirements Engineer, Entwickler und Tester die Projektarbeit erleichtern. Die Anwendung eines Musters nimmt Ihnen viele routinemäßige Schritte ab. Dabei sind Sie nicht auf die Muster angewiesen, die Sie in in-Step RED nach der Installation vorfinden. Wenn Sie eine Idee haben, wie Sie sich oder Ihrem Projektteam „das Leben“ leichter machen können, dann erstellen Sie einfach selbst neue Muster.

Einfach? Ja, das ist tatsächlich einfach. Den Beweis dafür möchte ich heute antreten. Ich zeige Ihnen in einem kurzen vertonten Video, wie ein Muster angelegt wird, das folgenden Zweck erfüllt: Mit dem Muster können Sie zu einer bestehenden Anforderung Testfälle und Testaktivitäten anlegen. Was dabei im Detail an Nützlichem entsteht, sehen Sie sich am besten im Film (ca. 10 Minuten) an.

Natürlich bleibt nach der Musteranwendung noch etwas zu tun: Jeder erzeugte Testfall muss noch spezifiziert werden. Das geschieht formularbasiert. Hier sehen Sie das Formular.

Die Anforderung, zu der der Testfall erzeugt wurde, ist im Formular referenziert – dafür hat das Muster gesorgt.

Das Muster, das hier entstanden ist, gehört zu den Erweiterungsmustern. Es erweitert ein vorhandenes Element um neue Elemente samt Beziehungen.

Das Prinzip eines Erweiterungsmusters

Es gibt noch weitere Mustertypen. Deshalb werden wir das Thema hier noch mehrfach aufgreifen.

Tags: , ,

in-Step RED – Wie geht es denn unserer Organisation?

Written by Ursula Meseberg on 9/26/2013 8:48:00 AM

Wie ist die Auslastung unserer Mitarbeiter? Haben wir noch freie Kapazität? Wie viele Kundenanforderungen liegen uns vor, die wir noch nicht bearbeiten? – Linienmanager, Multiprojektmanager und Programmmanager brauchen Antworten auf Fragen wie diese. Und das nicht nur projektbezogen, sondern auch aus Sicht der gesamten Organisation oder einzelner Organisationseinheiten.

in-Step RED – unsere neue Software für anforderungsbasierte Produktentwicklung, die ich Ihnen in meinem letzten Beitrag erstmals vorgestellt habe – bietet Ihnen als Anwender die Möglichkeit, auf Organisationsniveau Analysen durchzuführen. Diese Analysen in Form von Charts und tabellarischen Auswertungen sind in in-Step RED bereits vorbereitet. Sie können sie mit wenigen Klicks konfigurieren und zum Beispiel das gewünschte Auswertungsintervall und den Auswertungszeitraum festlegen, wie es die nachfolgende Abbildung an einem Beispiel zeigt. Als Anwender können Sie außerdem eigene wiederverwendbare Abfragen erstellen, die Ihnen mit jedem Aufruf aktuelle Daten liefern. 

Bereitstellung von Ressourcen – ein Beispiel für ein konfigurierbares Chart

Wenn Sie strategische Entscheidungen auf Organisationsebene treffen müssen, ist oft ein Blick auf sämtliche Meilensteine der geplanten und bereits laufenden Projekte hilfreich. Diesen Blick bietet Ihnen die organisationsweite Roadmap. Daneben ist die Roadmap ein Hilfsmittel zur schnellen und einfachen Navigation in ein Projekt  –  z.B. in den aktuellen Projektplan als Gantt Chart oder direkt zu den Ergebnissen, die an einem Meilenstein eines Projekts vorliegen müssen. Letzteres sehen Sie in dem kurzen Film (2:30 Minuten), mit dem ich Ihnen die organisationsweite Roadmap vorstellen möchte:

Haben Sie Lust bekommen, mehr von in-Step RED zu sehen? Dann laden wir Sie zu einer der Veranstaltungen auf unserer Product Launch Tour ein – in Leipzig, Stuttgart und München. Wir freuen uns auf Sie und auf Ihr Feedback zu in-Step RED.

Tags: , ,

in-Step RED kommt! Ein erster Blick in die neue Software

Written by Ursula Meseberg on 8/27/2013 8:28:00 AM

Ab Mitte September gehen wir mit unserer neuen Software in-Step RED auf Product Launch Tour kreuz und quer durch Deutschland. Ich lade Sie heute schon ein, einen ersten Blick auf in-Step RED zu werfen. Was ist in-Step RED und was ist das Besondere daran? 

 

 

in-Step RED bietet einem Team, das Produkte, Software & Systeme entwickelt, eine gemeinsame Arbeitsumgebung. Als Projektleiter finden Sie darin genau die Instrumente, die Sie für die Projektplanung brauchen, zum Beispiel Gantt Charts oder Ressourcendiagramme. Als Linienmanager verschaffen Sie sich schnell einen Überblick über die Ressourcenauslastung – auch über Projektgrenzen hinweg – und haben u.a. die Möglichkeit zur Earned Value Analyse.

Aber für erfolgreiche Produktentwicklung braucht man mehr als Planungs- und Controlling-Instrumente. Man braucht eine klare Zielorientierung und das Wissen darüber, was die Stakeholder wirklich wollen – also möglichst präzise Anforderungen.

Als Requirements Engineer oder Anforderungsanalytiker finden Sie in in-Step RED zahlreiche Hilfen für das Ermitteln und Beschreiben von Anforderungen. Sie reichen von Systemkontext- und Zieldiagrammen bis zu den klassischen Elementen der UML® und SysML®. Anforderungen erfassen Sie formularbasiert und, wenn Sie wollen, die Testfälle gleich dazu. Dokumentation erzeugen Sie auf Knopfdruck. Und natürlich wird für alle Ergebnisse automatisch eine Änderungshistorie fortgeschrieben. Als Produktmanager priorisieren Sie die Anforderungen und verschaffen sich mit Hilfe von Auswertungen jederzeit einen Überblick über den Stand der Arbeit.

Klar, sowohl für das Projektmanagement als auch für die Anforderungsanalyse gibt es zahlreiche Werkzeuge. Das Besondere an in-Step RED ist, dass es beide Disziplinen miteinander verbindet: das Requirements Engineering und das Projektmanagement. So entsteht Synergie. 

Anforderungsbasiert Planen

Ein Beispiel: Für Sie als Projektleiter hat der direkte Zugriff auf die Ergebnisse des Requirements Engineering ganz praktischen Nutzen. Die Anforderungen mit allen Informationen über Priorität, Zustand und geschätztem Aufwand stehen Ihnen bei der Projektplanung unmittelbar zur Verfügung. Das bedeutet, dass Sie bei einem iterativen, inkrementellen Vorgehen, wie es heute in vielen Projekten üblich ist, einer Iteration mehrere Anforderungen einfach per Drag & Drop zuordnen können. Die Anforderungen bringen den geschätzten Aufwand mit, sodass die Auswirkungen dieser Zuordnung auf die Iterationsplanung im Gantt Chart und in der Ressourcenauslastung sofort sichtbar werden, ohne dass Sie irgendetwas dazu tun müssen.

Musterbasiertes Gliedern eines Projekts

Bevor Anforderungen einer Iteration zugeordnet werden können, muss es überhaupt Iterationen geben, d.h. ein Projekt muss zunächst strukturiert und verfeinert werden. Um ein Projekt in Aktivitäten und Meilensteine zu gliedern, ihre Reihenfolge zu bestimmen, die Ablage der Ergebnisse zu organisieren, Konfigurationen und vorstrukturierte Ergebnisse anzulegen, Beziehungen zu bestehenden Produktkomponenten herzustellen ..., bietet Ihnen in-Step RED eine sehr mächtige Technik an: das Strukturieren von Projekten mithilfe von Mustern. Muster bilden modular Wissen – Ihr Wissen – über die Verfeinerung oder Erweiterung beliebiger Projektinhalte ab. In Muster "verpackt" ist das Wissen organisationsweit wiederverwendbar. So definieren Sie Standards für Ihre Projekte orientiert an Ihren eigenen Best Practices.

Muster werden immer kontextorientiert angeboten. Das macht ihre Anwendung denkbar einfach. Schauen Sie selbst: 

 

 

Nachvollziehbare Anforderungen

„Haben wir diese Anforderung schon realisiert und wenn ja, durch welche Komponente, welches Systemelement?“ – eine typische Frage in jedem Entwicklungsprojekt. Mit in-Step RED haben Sie volle Traceability. Sie beginnt  bei den Stakeholderzielen und reicht über die Anforderungen bis zu den Elementen der Systemarchitektur.

Skalierbare Architektur

Ihre Projekte sind groß? Sie haben Projektteams an mehreren Standorten? Die Arbeit im LAN auf einer gemeinsamen Datenbank, der Datenaustausch zwischen Standorten, die nicht online verbunden sind, der Zugriff über den in-Step RED Web-Client per Internet-Browser – all das ist möglich. Sie entscheiden über die Form der Arbeit. 

Egal, ob mit dem Windows-Client (links) oder dem Web-Client per Internet-Browser (rechts) - Sie haben Zugang zu Ihren Projekten über eine weitgehend identische Benutzeroberfläche

Wenn Sie dieser kurze Einblick neugierig gemacht hat, dann laden wir Sie ein: Kommen Sie doch zu einer der Veranstaltungen auf unserer Product Launch Tour für in-Step RED in Düsseldorf, Frankfurt, Berlin, Leipzig, Stuttgart, München-Unterschleißheim und Hannover.

Übrigens, falls Sie sich fragen: „RED“ – hat das auch eine Bedeutung? Ja, RED steht für Requirements Engineering & Development – ein Tool eben für alle, die gemeinsam Produkte entwickeln.

Tags: , , ,

Das haben wir im Juli besonders gern geteilt

Written by Ursula Meseberg on 8/13/2013 8:35:00 AM

Trotz Sommer, Hitze, Urlaubszeit haben sich auch im Juli wieder viele Autoren an den Schreibtisch gesetzt und Erfahrungen, Meinungen und Tipps in ihren Blogs veröffentlicht. Einiges davon haben wir auf Social Media Plattformen geteilt. Hier eine kleine Auswahl:

Risikomanagement ...

... wird leider viel zu selten thematisiert. Das meint nicht nur Michael Schenkel, der das Thema hier im Blog in den letzten Wochen gleich zweimal aufgegriffen hat. Wenn man sich gründlich umschaut, findet man durchaus Interessantes dazu. Eine kompakte Einführung in die methodischen Grundlagen nach PMBOK liefert zum Beispiel die Website PM StudyCircle (PMSC):

What is Risk Management?

Dazu gibt es eine ebenfalls lesenswerte Fortsetzung, die sich mit dem Planungsaspekt beim Risikomanagement beschäftigt:

A Short Guide to Project Risk Management Plan

Kennen die „Agilen” eigentlich kein Risikomanagement? Manchmal hat man diesen Eindruck. Aber der Eindruck täuscht. Das beweist dieses kurze Video (9:16 min.) aus der agilen Projektpraxis einer skandinavischen Online-Bank unter dem Titel:

Manage Risk and Expectations in Agile

Was nützt das beste Risikomanagement, wenn man nicht weiß, wo man mit einem Projekt hin will. Da hilft der Business Case. Einen starken Beitrag dazu finden Sie auf ModernAnalyst.com unter dem Titel:

Projects and the taxi ride

Requirements Engineering: WIE und WARUM

Auch zum Requirements Engineering haben wir wieder einige interessante Beiträge gefunden. So zum Beispiel diesen im HOOD-Blog:

Requirements Engineering findet in Scrum kontinuierlich statt – wir nennen es nur nicht so Ja!

Viele Beiträge beschäftigen sich mit der Frage, WIE man gute Anforderungen schreibt. Es ist sicher nützlich, sich die grundlegenden Regeln immer wieder vor Augen zu halten, wie sie zum Beispiel auf der Website Business Analyst Learning zusammengetragen wurden. Eine Liste zum Fortschreiben:

15 Tips for Writing Better Requirements

Statt nach dem WIE, fragt der nachfolgende Beitrag erst einmal nach dem WARUM (mit vielen vertiefenden Links):

Why Write Requirements

Wie macht man Anforderungen für die Kommunikation z.B. mit Stakeholdern für diese leichter „verdaulich“? Darauf antwortet der Artikel auf Requirements.net:

How to Detect Requirement Flaws

Und wir haben übrigens genau das passende Tool dazu: den objectiF Requirements Modeller :-)

Zum Abschluss zwei spezielle Tipps

Vielleicht kennen Sie Jim Highsmith – ein „methodisches“ Urgestein der Softwareentwicklung und Buchautor u.a. von Agile Project Management: Creating Innovative Products, Addison-Wesley, 2nd Edition, 2009. Hier sind zwei Fundstücke von seiner Website mit jeweils ungewöhnlichem Blickwinkel:

Über die Monster der (Prozess-)Vergangenheit: Sind sie besiegt?

Once Upon a Time before Agile

Alles, was wir in IT-Projekten produzieren, ist irgendwie Text, sagt Jim Highsmith und rät:

Writing to Learn

Lesen allein macht ja auch schon Spaß. Sehen wir mal, was der August so bringt. Folgen Sie uns doch einfach auf Twitter

Kleiner Nachtrag: Wenn's in Ihren Projekten mal  nicht so richtig klappt - hier ein letzter Link

Tags: , , ,

23. microTOOL NutzerKonferenz: „Erfüllung rechtlicher Anforderungen aus dem Kartellrecht mit in-Step“ (Video)

Written by Ursula Meseberg on 7/16/2013 9:10:00 AM

Vortrag von Jens Wolf, Smurfit Kappa Paper Services B.V., Roermond, Niederlande

Normalerweise wird das Projektmanagement-Tool in-Step eingesetzt, um die Kernprozesse der Software- und Systementwicklung, wie Projekt- und Anforderungsmanagement, Test-, Qualitäts- und Risikomanagement etc., zu unterstützen. Wie gesagt: normalerweise. Es gibt aber auch ganz andere, spannende Anwendungsfälle – wie diesen hier:

Zur Umsetzung einer konzerninternen Policy, die auf Basis von rechtlichen Vorgaben aus dem Kartellrecht abgeleitet wurde, entschied man sich bei Smurfit Kappa innerhalb des RPE Clusters, einem Verbund aus mehreren Papierfabriken und einer Serviceorganisation, neue Wege zu gehen. Elementare Punkte der internen Policy sind die Registrierung und Verfolgung von Verbandssitzungen sowie möglicher Besuche von Wettbewerbern in eigenen Werken. Hierbei stehen die lückenlose Dokumentation und die Archivierung von Schlüsseldokumenten im Vordergrund. Zusätzlich müssen unterschiedliche Genehmigungsprozesse eingehalten werden.

Ungewöhnlich – aber ein Fall für in-Step: Die Umsetzung der kartellrechtlichen Anforderungen wurde mit einem speziell entwickelten in-Step Template implementiert. Interessante und inspirierende Eindrücke vermittelt Ihnen dieser Anwenderbericht, der auf der Nutzerkonferenz im April 2013 in Berlin vorgetragen wurde (26:04 Minuten).

Wer ist der Referent?

Dipl.-Wirt.-Ing. (FH) Jens Wolf ist seit 2010 bei Smurfit Kappa Paper Services tätig. Als Process Manager liegen seine Schwerpunkte auf Prozessanalysen und -optimierungen sowie dem Projektmanagement. Hierbei greift er auf seine langjährigen Erfahrungen aus der Automobilzuliefererindustrie zurück, in der er als Qualitätsingenieur und als Projektingenieur beschäftigt war. Innerhalb des Smurfit Kappa RPE-Clusters (Papierfabriken in Deutschland, Niederlande und Tschechien) unterstützt er bei der Einführung von Projektmethoden und Standards (u. a. auch in-Step); im Rahmen von Prozessoptimierungen konzeptioniert und implementiert er aber auch neue Lösungsansätze.

Wir danken Jens Wolf für die Erlaubnis, seinen Vortrag hier zu veröffentlichen.

Das war's für dieses Jahr von der NutzerKonferenz

Das ist das letzte Video von der diesjährigen microTOOL NutzerKonferenz hier im Blog. Sie hätten gern mehr Einblicke in die Anwendungspraxis unserer Tools? Dann laden wir Sie herzlich ein, persönlich dabei zu sein – auf der 24. microTOOL NutzerKonferenz am 14./15. Mai 2014 in Berlin.

Sie möchten sich nicht nur einmal in Jahr sondern öfter mit anderen Anwendern austauschen? Dann kommen Sie doch in die microTOOL-Nutzergruppe auf XING. Wir freuen uns auf Sie.

Für die Erstellung unserer Konferenzfilme danken wir:

Aaike Stuart
StuartFilm
www.stuartfilm.nl

Tags: , , , ,

Das haben wir im Juni besonders gern geteilt

Written by Ursula Meseberg on 7/9/2013 9:07:00 AM

Von all den Artikeln über Projektmanagement und Requirements Engineering, die wir im Juni auf den Social Media Plattformen geteilt haben, sind mir einige besonders im Gedächtnis geblieben. Hier eine kleine Auswahl. Vielleicht sind Anregungen für Sie dabei.

Dreimal Scope Creep

Eine (Wieder-)Entdeckung war für mich die Autorin Ellen Gottesdiener, deren Buch Requirements by Collaboration: Workshops for Defining Needs seit dem 28. August 2007 (Amazon vergisst nie!) in unserer Bibliothek schlummert. Sie hat dem Thema Scope Creep, also der unkontrollierten Verschiebung bzw. kontinuierlichen Vergrößerung des Scopes eines Projekts, zwei Blog-Beiträge gewidmet. Im ersten Beitrag beschreibt sie das Problem an einem lebendigen Beispiel aus ihrer Projektpraxis. Im zweiten geht es dann um die Mittel, mit denen dieses Phänomen verhindert werden kann.

Rope Your Scope: Reining in Scope Creep (Part I)

Rope Your Scope: Reining in Scope Creep (Part II)

Um dasselbe Thema geht es auch in der Whiteboard Session (einem kurzen Video) auf ProjectManager.com mit dem Titel:

Controlling Scope on Projects

Anforderungen – Stoff für unendliche Geschichten

Wie beschreibt man Anforderungen richtig? Welche Granularität müssen sie haben? Welche Perspektive, welche Sprache wählt man? Egal, ob agil gearbeitet wird oder nach „schwergewichtigen“ Vorgehenskonzepten, diese Fragen bewegen viele Autoren im Netz. Hier sind zwei interessante Antworten:

Aufschlussreich, weil an einem konkreten Beispiel aus der Entwicklung technischer Systeme, dieser Beitrag aus dem HOOD-Blog:

Die geeignete Lösungsdichte – Welche Frage hätte ich dem Kunden stellen sollen?

Und aus der agilen Welt:

5 Common User Story Mistakes von Roman Pichler.

Übrigens: Wenn Ihnen der Artikel von Roman Pichler gefällt, dann können Sie natürlich weiter in seinem Blog stöbern. Aber am besten lesen Sie gleich sein Buch Agiles Produktmanagement mit Scrum: So entwickeln Sie Produkte, die begeistern (Addison-Wesley 2012). Es ist dünn genug für jeden Urlaubskoffer und – noch platzsparender – auch als Kindle-Edition erhältlich.

Fünfmal agil

Unser Interesse an „agilen" Themen kommt nicht von ungefähr. Wir entwickeln selbst nach Scrum – natürlich unterstützt durch die in-Step Scrum Edition :-) . Deshalb sind die nachfolgenden Beiträge, die sich mit der Bildung und der Verantwortung von Scrum-Teams auseinandersetzen, aus unserer Sicht eine Empfehlung wert:

Warum ist es so schwer, ein Scrum-Team zu bilden? aus dem HOOD-Blog.

Effektive Wege, um Entscheidungen im Team zu treffen aus dem BorisGloger Blog.

Und aus dem Process Improvement and Measurement BLOG:

Agile Teams Making Decisions: Leadership and Decisions

Agile Teams Making Decisions: Servant Leaders

Agile Teams Making Decisions: Decision Making Prerequisites

Daily Process Thoughts nennt Thomas M. Cagley Jr., der Autor der letztgenannten Beiträge, seine Blog-Serie, in der er fast täglich Themen aus dem Projektmanagement aufbereitet. Als Coautor des 2010 erschienenen Buches Mastering Software Project Management: Best Practices, Tools and Techniques (J Ross Pub Inc , 2010) geht ihm der Stoff vermutlich nicht so schnell aus.

Wie steht’s um Ihr persönliches Zeitmanagement?

Ist Ihr persönliches Zeitmanagement verbesserungsfähig? Wenn ja, haben Sie es schon mit Personal Kanban probiert? Zum Kennenlernen dieser Technik hören Sie doch mal hier rein:

Personal Kanban – Warum ich jetzt effektiver bin, ein Podcast der Zukunftsarchitekten.

Von meinem Versuch mit Personal Kanban habe ich hier im Blog in einem früheren Beitrag schon einmal berichtet. Das damals empfohlene Buch Personal Kanban von Jim Benson und Tonianne DeMaria Barry ist in diesem Jahr im dpunkt.verlag auf Deutsch erschienen und übrigens ebenfalls dünn genug fürs Reisegepäck. Eine Kindle-Ausgabe gibt’s auch.

Viel Spaß beim Lesen.

Tags: , , ,