Klicke auf der Übersichtsseite Deiner Projekte auf "Projekt hinzufügen":
Gib Deinem Projekt einen klaren, eindeutigen Namen. Und falls Du möchtest, füll noch eine aussagekräftige Beschreibung ein. Die restlichen Einstellungen sind im Moment noch nicht wichtig. Du kannst sie leer lassen und das Projekt nun hinzufügen.
Damit landest Du auf der Übersichtsseite Deines neuen Projektes. Hier siehst Du zusammengefasst die wichtigsten Informationen zum aktuellen Stand des Projektes. Schau Dir die Übersichtsseite eines öffentlich einsehbaren Demo-Projektes an.
InhaltsverzeichnisWie wir alle wissen, stimmt diese alte Weisheit ganz speziell auch für IT-Projekte: Die Spezifikation ist das Fundament für eine erfolgreiche Umsetzung. Deshalb begleitet Yulup Dich und alle anderen Team-Mitglieder während der ganzen Dauer des Projektes: schon vom Beginn der Konzeption und auch während des Betriebs.
Wechsle nun bei Deinem neu erstellten Projekt in den Bereich "Spezifikation" — hier zum Vergleich beim Projekt des Bankomaten.
Falls Du mit der Benutzung des Editors und seinen Yulup-spezifischen Eigenheiten schon vertraut bist, kannst Du direkt mit den Personas beginnen.
Beim Spezifizieren von Personas, User Stories und BDD Scenarios hilft Dir ein integrierter Editor. Du kennst solche sicher in ähnlicher Form von Office-Anwendungen oder anderen Web-Applikationen.
Der Editor kann Text fett oder kursiv darstellen, und es können Bilder oder Listen eingefügt werden. Du kannst aber auch Kommentare oder Code-Snippets einfügen.
InhaltsverzeichnisPlatziere den Cursor an der Stelle, an welcher Du den Kommentar einfügen willst. Oder Du markierst den Textabschnitt, welchen Du kommentieren möchtest.
Danach kannst Du über den Kommentar-Knopf in der Werkzeugleiste einen Kommentar erstellen.
Dies ist auch über den Menu-Eintrag unter 'Einfügen' möglich.
Wenn die Maus auf dem Kommentar positioniert ist, wird der Autor und der Zeitpunkt des Kommentars angezeigt. Dies funktioniert während des Bearbeitens und auch danach.
Nachdem die Änderungen gespeichert sind, kannst Du die Kommentare mit einem Klick auf einen Kommentar ein- und ausblenden.
Um einen Kommentar zu löschen, markierst Du ihn mit der Maus und löschst dann die Selektion. Falls noch blaue Markierungen stehen geblieben sind, selektierst Du diese und löschst sie mit der Funktion 'Formatierung entfernen' im Menu 'Format', siehe auch nächster Abschnitt.
InhaltsverzeichnisWo gehobelt wird, fallen Späne. Und die Späne wollen dann auch einmal weggewischt sein. So kannst Du alle Formatierungen eines Textabschnittes entfernen:
Du markierst den gewünschten Textabschnitt mit der Maus und wählst im Menu unter 'Format' die Funktion 'Formatierung entfernen' aus.
InhaltsverzeichnisWenn Du im Umgang mit HTML-Code vertraut bist, kannst Du auch direkt den Quelltext einer Persona, einer User Story oder eines BDD Scenarios bearbeiten. Im Menu 'Werkzeuge' findest Du dazu die Funktion 'Quelltext'.
Diese öffnet ein Fenster, in welchem der HTML-Source-Code des Textes bearbeitet und dann übernommen werden kann.
Beachte jedoch, dass nicht alle HTML-Tags erlaubt sind: Nicht zulässige Tags werden automatisch wieder entfernt.
InhaltsverzeichnisManchmal kann es hilfreich sein, z.B. ein BDD Scenario mit einem Code-Snippet zu illustrieren. Dies machst Du am einfachsten mit Hilfe des Knopfes zum Einfügen von Programmcode.
Oben im Fenster zum Einfügen oder Bearbeiten von Programmcode wählst Du die entsprechende Programmiersprache aus. So werden die Keywords des Code-Snippets richtig eingefärbt (Syntaxhervorhebung).
So, nun kannst Du richtig loslegen!
InhaltsverzeichnisMit Vorteil entwickelst Du zuerst Personas. Eine Persona ist ein Archetyp einer spezifischen Gruppe von Benutzern des umzusetzenden Software-Projektes.
Personas helfen Euch, die Anforderungen an Eure Software aus der Perspektive der Benutzer zu betrachten. Und nicht aus derjenigen des Produkt-Managers, des Projektleiters oder des Entwicklers. Gib Deinen Personas ein "Gesicht", das heisst u.a. einen einprägsamen Namen. Dann formulierst Du die Erwartungshaltung der Persona an die zu erstellende Software. Am besten besprecht und ergänzt Ihr die Personas anschliessend im Team. Beispiel-Personas aus dem Bankomaten-Projekt.
Jetzt kannst Du für jede der Personas deren typische (Haupt-)Tätigkeiten beschreiben. Jede einzelne Tätigkeit wird in Form einer sogenannten User Story abgebildet. Diese sind nach einem klaren Schema (Wer macht was und warum) aufgebaut. Etwas formaler lautet das Schema:
"Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>"
Beispiele von User Stories:
Als Autor möchte ich nach dem Start der Anwendung mein zuletzt bearbeitetes Dokument sehen, um gleich weiterarbeiten zu können.
Als Kunde der Bank möchte ich jederzeit am Bankomaten Geld abheben können, um unabhängig von Öffnungszeiten zu sein.
Eine User Story beschreibt, was eine Persona mit der zu erstellenden Software machen will und was das Ziel der Handlung ist. Dies jedoch ohne dabei allzu tief in die Details zu gehen. Letztere werden erst später in den BDD Scenarios abgebildet.
Beispiel-User-Stories aus dem Bankomaten-Projekt.
| Buchstabe | Bedeutung | Beschreibung |
|---|---|---|
| I | Independent (unabhängig) | Die User Story sollte in sich abgeschlossen sein, so dass sie nicht von anderen User Stories abhängig ist. |
| N | Negotiable (verhandelbar) | User Stories können solange verändert und umgeschrieben werden, bis sie zur Umsetzung fix eingeplant sind. |
| V | Valuable (nützlich) | Eine User Story muss den Anwendern (Personas) Mehrwert bieten. |
| E | Estimable (quantifizierbar) | Der Aufwand eines Backlog-Elementes sollte abschätzbar sein. |
| S | Small (klein) | User Stories sollten so klein sein, dass es möglich ist, diese mit einem gewissen Mass an Zuverlässigkeit einzuplanen oder zu priorisieren. |
| T | Testable (prüfbar) | Die User Story muss genügend Informationen bereit stellen, um das Schreiben von BDD Scenarios oder das Erstellen von Tests zu ermöglichen. |
BDD Scenarios beschreiben detaillierter, wie sich eine bestimmte Funktionalität unter bestimmten Bedingungen verhält. Mit BDD Scenarios werden auch die Akzeptanzkriterien für User Stories festgelegt. BDD steht dabei für Behaviour Driven Development, welches den Fokus auf Verhalten getriebenes (und testorientiertes) Entwickeln setzt. Yulup ermöglicht, die Ergebnisse des Requirement Engineerings resp. der Spezifikation in einer für alle involvierten Personen verständlichen Form und Sprache sowie über alle Projektphasen hinweg einzusetzen. Bei Bedarf kannst Du sie fortlaufend weiter entwickeln.
Im Gegensatz zu den User Stories (Wer macht was und warum) legen BDD Scenarios das "Wie" fest. Du definierst, was genau geschieht, wenn im Rahmen einer vorbestimmten Situation eine Aktion ausgelöst wird. BDD Scenarios sind ebenfalls gemäss einem einfachen, vorgegebenen Schema aufgebaut:
"Angenommen <Vorbedingungen>, wenn <Aktion>, dann <Ergebnis>"
Typischerweise werden zu einer User Story eine Handvoll BDD Scenarios erfasst, um die User Story genauer zu spezifizieren.
Die BDD Scenarios bilden später auch die Grundlage für die Informationsarchitekten, Designer, Texter und Programmierer, um die entsprechenden Funktionalitäten zu erstellen. Ebenso bilden sie die Basis für das Testing sowie die Abnahme.
Beispiel-BDD-Scenarios aus dem Bankomaten-Projekt.
| Buchstabe | Bedeutung | Beschreibung |
|---|---|---|
| S | Spezifisch | BDD Scenarios müssen eindeutig definiert sein (nicht vage, sondern so präzise wie möglich). So überlappen sich die BDD Scenarios nicht und es wird klar, ob sie zur User Story beitragen. |
| M | Messbar | BDD Scenarios müssen überprüfbar sein. Das heisst letztendlich, "können wir es als erledigt markieren?" Dies beinhaltet u.a. "verhält es sich wie gefordert?", "waren die Tests erfolgreich?" oder "wurde ein Refactoring gemacht?". |
| A | Attraktiv | User Stories werden für den Entwickler in BDD Scenarios aufgeteilt. Sie müssen jedoch den zukünftigen Nutzern (Personas) einen Mehrwert bieten. |
| R | Realistisch | BDD Scenarios müssen möglich sein. Der Verantwortliche des BDD Scenarios sollte überzeugt sein, dieses umsetzen zu können. |
| T | Terminiert | Zu jedem BDD Scenario gehört eine klare Vorstellung bezüglich des benötigten Aufwands, so dass auch klar wird, wenn diese Vorgabe nicht eingehalten werden kann und zusätzliche Ressourcen benötigt werden oder das Scenario weiter aufgeteilt werden muss. |
Yulup gibt Dir beim Anlegen eines neuen Projektes die Möglichkeit, aus verschiedenen Schematas für User Stories und BDD Scenarios auszuwählen. Je nach Schema ist die Wortwahl etwas anders. Dadurch resultiert dann ein etwas anderer Schreib- und Lesefluss. Und die User Stories und BDD Scenarios können allenfalls etwas schneller geschrieben werden.
Welche Variante Du verwenden willst, kannst Du ganz frei entscheiden. Ebenso ist es möglich, die Sprache für die Spezifikation unabhängig von der Sprache der Benutzeroberfläche zu wählen.
Yulup ist mit Deinem Source Code Repository verknüpft. Sobald Änderungen im Repository stattfinden, werden diese auch in Yulup im Bereich "Änderungen" angezeigt.
Dort kannst Du nun eine Programm-Datei mit Tests verknüpfen. Diese Tests können automatisierte Tests sein. Es kann aber auch ein BDD Scenario sein, das zuvor im Bereich "Spezifikation" erfasst worden ist. Ab sofort werden nun bei jeder Änderung an dieser Datei einerseits die automatisierten Tests durchgeführt und das Resultat in Yulup angezeigt. So seht Ihr auf einen Blick, was geklappt hat und was nicht. Andererseits werden alle Tests, die manuell durchgeführt werden müssen, im Bereich "Hängige Tests" gelistet.
InhaltsverzeichnisTesting, we will never do enough of it.
Was für den Radrennsport gilt, ist leider auch für die meisten Software-Projekte genauso wahr. Meist stehen zu wenig Zeit und Ressourcen zur Verfügung, um z.B. nach einem Update sämtliche Funktionalitäten einer Software zu testen.
Hier hilft Euch Yulup, weil es Euch genau die Tests auflistet, die nach einer Änderung gemacht werden müssen. Alle anderen Tests müssen gar nicht durchgeführt werden, weil sie durch die Änderung nicht betroffen sind.
Wenn Testing jetzt schon einen fixen Platz in Deinem Projektplan hat, dann weisst Du, wie aufwändig dies sein kann. Yulup wird Euch jedoch helfen, den Testing-Aufwand markant zu reduzieren.
Und falls Du bis jetzt den Eindruck hattest, das Testing würde oft etwas vernachlässigt, wird Yulup Euch aufzeigen, was Ihr testen solltet (und was nicht getestet werden muss).
Der Bereich "Hängige Tests" zeigt Dir die noch pendenten, manuellen Tests. Und zwar für jeden im Source Code Repository vorhandenen Branch. Du kannst dort dann auch gleich — sobald ein Test abgearbeitet worden ist — dessen Resultat entsprechend nachführen.
About Yulup
Made with in Zurich:
