Informationsarchitekten, Designer und Scrum

Bei der Verwendung von Scrum in der Softwareentwicklung werden die genauen Spezifikationen für die Umsetzung von Anforderungen recht kurzfristig innerhalb eines Sprints durchgeführt. Der Product Owner definiert, welches Problem gelöst werden soll, das Team erarbeitet häufig erst “Just-in-Time”, wie die Lösung ausschaut. Genau dieses “Just-in-Time”-Arbeiten stellt Informationsarchitekten und Designer vor eine große Herausforderung.
Inken Petersen und Patrick Roelofs haben für die IA-Konferenz 2009 in Hamburg eine Präsentation genau zu diesem Thema erstellt und bieten 8 Tipps, die bei einer erfolgreichen Integration der Informationsarchitekten in Scrum-Teams helfen sollen.

A List apart empfiehlt dazu:

“Best practice” suggests that designers should research iteration n+2, design iteration n+1, support iteration n and review iteration n-1.

Aber auch hierbei sollte darauf geachtet werden, dass eine enge Kommunikation mit den Entwicklern stattfindet und nicht “im stillen Kämmerlein” gearbeitet wird.

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

About these ads

Über Paul Herwarth von Bittenfeld
Paul Herwarth von Bittenfeld arbeitet seit 2003 bei //SEIBERT/MEDIA intensiv mit Software-Entwicklungsteams als Product Owner und ScrumMaster zusammen. Seit 2007 zeichnet er als Bereichsleiter für die Tochtergesellschaften TwentyFeet GmbH, Gartentechnik.com GmbH und naturkostaktiv GmbH verantwortlich. In den letzten Jahren begleitete er die Einführung von Scrum und Kanban in mehreren Teams und die Einführung agiler Methoden und Vorgehensweisen auf Unternehmensebene sowohl bei //SEIBERT/MEDIA selbst als auch als Agile-Coach in Kundenprojekten. Sein Spezialbereich ist das Produktmanagement und die Vermarktung von Internetanwendungen unter Anwendung agiler und schlanker (lean startup) Vorgehensweisen.

2 Antworten auf Informationsarchitekten, Designer und Scrum

  1. Thomas sagt:

    ““Best practice” suggests that designers should research iteration n+2, design iteration n+1, support iteration n and review iteration n-1.”

    Das ist mir nicht ganz klar. Bedeutet es, dass Designer zwei Sprints vorher mit dem Research, einen Sprint vorher mit der Umsetzung und im Sprint n das Dev-Team bei der Umsetzung unterstützen sollen?

  2. Ja, genau so ist es gemeint. Das nimmt dem Product Owner an dieser Stelle ein Stück der Flexibilität bzw. kann dazu führen, dass Arbeit durchgeführt wird, die später verworfen werden muss. Insofern ist das ein kleiner Abstrich von dem Prinzip, dass die Spezifikation der Stories erst im Sprint durchgeführt wird. Es widerspricht auch Mike Cohn, der das Design erst sehr spät im Prozess realisiert sehen möchte, da das Design schnell die Offenheit für unterschiedliche Lösungsansätze zerstört. Ich denke, dass es Sinn macht, das für jede Story einzeln zu durchdenken. Muss da viel im Design gemacht werden? Ist die Usability an dieser Stelle sehr entscheidend? Wenn das mit ja zu beantworten ist, kann das vorgeschlagene Vorgehen ein Lösungsansatz sein.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Verbinde mit %s

Follow

Bekomme jeden neuen Artikel in deinen Posteingang.

Schließe dich 915 Followern an

%d Bloggern gefällt das: