In unseren Projekten setzen wir auf User Stories , um die Anforderungen einer Anwendung zu spezifizieren. Im Unterschied zu Use Cases verschieben sich die Details der Anforderungen vom geschriebenen Wort, hin zum gesprochenem Wort (Gespräche/Diskussionen mit dem Kunden). Über Jahre habe ich in Projekten mit Use Cases gearbeitet und war nie wirklich zufrieden:
- Man konzentriert sich zu stark auf das Ausfüllen eines Use Case Templates und weniger auf den Inhalt. Das Template muss meistens vollständig gefüllt sein, damit es den formalen Abnahmekriterien der Qualitätssicherung (Quality Gates) erfüllt.
- Die Erstellung von Use Cases dauert lange und es sind häufig viele Leute beteiligt, die die Dokumente reviewen, erweitern und anpassen. (Deshalb ist es auch so wichtig bei Use Case Templates eine Versionierungs-Tabelle auf Seite 1 zu haben)
- Da Use Cases alle Details, Ausnahmen und Varianten der Funktionalität enthalten (zumindest denkt man das) und als Input für die Implementierung dienen, setzt man als Entwickler meistens 1:1 das um, was in den Uses Cases steht. Am Ende (und das kann schon mal 1 Jahr später beim Abnahmetest sein) merkt man dann, dass man die Dinge nicht richtig verstanden hat, Details fehlen oder sich die Dinge einfach im Laufe der Zeit geändert haben. (Ich weiß, dass einem auch bei Use Cases niemand verbietet miteinander zu reden, aber wenn man als Entwickler schon eine vollständige Spezifikation hat, dann kann man diesen „lästigen“ Teil einfach vermeiden und sich hinter dem Word Dokument verstecken)
User Stories hingegen sind nur ein Ankerpunkt für eine Funktionalität. In Kombination mit automatisierten Akzeptanztests und viel Kommunikation werden Sie zu einem sehr guten Ersatz für Use Cases. Wichtig: Man muss kommunizieren, denn die User Story selbst ist nicht ausreichend.
Gut, aber was hat das jetzt mit Mockups und dem Titel dieses Blog Eintrags zu tun?
Neben den aufgeschriebenen Anforderungen werden in den meisten Fällen auch die Masken einer Anwendung spezifiziert. Die gängigsten Dokumentationsformen die ich gesehen habe sind Powerpoint und Excel – oft kombiniert mit einer genauen Feldbeschreibung in Word. Bei einem Kunden habe ich auch schon mal eine vollständige UML Maskenbeschreibung gesehen – jede Maske war als UML Diagramm modelliert, mit allen Feldern, Typen und Plausibilitäten. Mehrere Mannjahre Aufwand steckte in diesen Modellen. Die Entwickler konnten wenig damit anfangen und haben dann HTML Prototypen gebaut und diese mit dem Fachbereich besprochen.
Eins haben diese Excel, Powerpoint und UML Masken gemein: Sie kosten sehr viel Zeit!
Deshalb möchte ich hier einmal Mockups als Alternative vorstellen. Mockups stehen im Grunde für einfache Zeichnungen der Masken – so wie man Sie auch mal schnell am Whiteboard macht, um mit Kollegen über Inhalte zu diskutieren. Nur das die Mockups digital erstellt werden, so dass man Sie einfach verändern und erweitern kann. Hier ein Beispiel für ein Mockup (Screenshot von Balsamiq ):
Neben Webseiten kann man auch Fat Clients oder auch mobile Anwendungen zeichnen, wie diese Mockups einer iPhone App zeigen:
Die Vorteile von Mockups sind ähnlich wie die von User Stories: Wenig Details, aber die wichtigen Ankerpunkte sind vorhanden. Bei den Excel, Photoshop Designs, die man sonst so erstellt, hat man nämlich das selbe Problem wie mit Use Cases: Am Ende sehen die Masken auch tatsächlich so aus wie in Excel…und das muss nicht unbedingt benutzerfreundlich sein.
So ein Mockup erstellt man am Besten gemeinsam mit dem Kunden zu einer User Story. Mit einem Werkzeug wie Balsamiq dauert die Erstellung eines oben dargestellten Mockups ca. 5 Minuten!
Die Vorteile liegen aus meiner Sicht auf der Hand:
- Man fokussiert sich auf die wichtigen, inhaltlichen und strukturellen Fragen und nicht auf die Details, ob die Farbe auch die richtige ist oder eine Line etwas dicker sein sollte.
- Der kreative Prozess wird nicht durch kompliziertes Arbeiten mit einem Tool unterbrochen. Man kann die Mockups auch während einer User Story Diskussion zeichnen, um das Verständnis zu schärfen.
- Die Erstellung der Mockups ist mindestens so einfach wie an einem Whiteboard zu malen (und wer meine Zeichnungen schon mal gesehen hat, der wird wissen, dass sie deutlich besser zu lesen sind).
- Man kann sie gemeinsam mit Kunden, Analysten und Fachbereichen erstellen, Dinge schnell verändern und „hin und her ziehen“
- Den Styleguide überlässt man den Spezialisten: Grafiker und Designer, die sich damit auskennen und für die ein Mockup ein guter Input ist.
Wir führen gerade Balsamiq bei uns in den Projekten ein. Es integriert sich in Jira und Greenhopper , so dass man direkt an einer User Story das Mockup online anhängen kann.
Ich bin begeistert von der Einfachheit und dem hohen Nutzen von Mockups und kann Euch nur empfehlen es selber einmal auszuprobieren oder vorab eines der Videos anzuschauen.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Mirko Novakovic
21.2.2014 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Mirko Novakovic
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.