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.

Über Paul Herwarth von Bittenfeld
Lean & Agile IT-Unternehmer. Partner bei //SEIBERT/MEDIA & Founder von Rhein-Main-Startups.com. Weitere Erfahrungen in der Geschäftsführung von TwentyFeet GmbH, Gartentechnik.com GmbH, new-in-town GmbH und naturkostaktiv GmbH sowie hunderten Kundenprojekten gesammelt.

2 Responses to Informationsarchitekten, Designer und Scrum

  1. Thomas says:

    „“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 )

Google+ Foto

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

Twitter-Bild

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

Facebook-Foto

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

w

Verbinde mit %s

%d Bloggern gefällt das: