Workshop agile Basics
Im ersten Workshop wurden uns von Francesco die Unterschiede zwischen dem agilen Vorgehensmodell und dem Wasserfallmodell gezeigt. Diese beide Vorgehensmodelle werden häufig in der Softwareentwicklung eingesetzt. Das Wasserfallmodell ist ein lineares Vorgehensmodell, das in 5 aufeinanderfolgenden vordefinierten Phasen aufgeteilt ist. In diesem Modell wird jede Phase nur einmal durchlaufen und gilt als Vorannahme für die nächste Phase.
Nachteile des Wasserfallmodells
Durch die starre Vorgehensweise innerhalb dieses Modells fehlt es bei der Umsetzung an Flexibilität. Dies kann zu großen Problem führen, wenn sich die Anforderung im Laufe des Projekts ändern. Der Kunde hat bei diesem Modell nur eine sehr eingeschränkte Sicht auf das Projekt und die zu entwickelnde Softwareanwendung, da der Kunde kein fester Bestandteil des täglichen Projektgeschäfts ist.
Der Kunde bekommt die Softwareanwendung erst relativ spät zu sehen. Das kann dazu führen, dass das Produkt bei der Auslieferung nicht seinen Vorstellungen entspricht. Hat der Kunde Änderungswünsche, muss das ganze Team wieder bei den Anforderungen beginnen, da alle Phasen miteinander verknüpft sind. Dies ist sehr aufwendig und kostenintensiv. Im Wasserfall haben die unterschiedlichen Rollen auch in der Regel feste Aufgabenbereiche.
Agile Vorgehensmodell Scrum
Dann gibt es noch das Scrum Vorgehensmodell. Der englische Begriff, Scrum stammt aus dem Rugby und bedeutet so viel wie „dichtes Gedränge“. Bei Scrum wird sehr viel Wert darauf gelegt, das gesamte Projekt gemeinsam als verknüpftes Team anzugehen und nicht als Einzelspieler mit festen Aufgabenbereichen.
Hier wird im Gegensatz zur Wasserfallmethode sehr viel Wert draufgelegt, mit dem Kunden als ein Team zusammenzuarbeiten. Es ist nicht unüblich, dass sich der Kunde und das Scrum Team sogar ein Büro teilen. Das hat den Vorteil, dass man besser und schneller auf individuelle Wünsche oder Veränderungen des Kunden eingehen kann und der Kunde nah am Projekt ist und so eine sehr gute Sicht auf den Status und die Ergebnisse hat. Vor allem ermöglicht dieses Vorgehen einen kontinuierlichen Austausch auf kurzem Weg.
In dem nächsten Abschnitt schauen wir uns die Scrum-Rollen und Zeremonien genauer an.
Scrum Rollen
Product Owner (PO)
Der Product Owner fungiert als Bindeglied zwischen dem Kunden und dem Entwicklungsteam. Er ist dafür verantwortlich, die Anforderungen des Kunden zu erfassen und sie ans Entwicklungsteam weiterzugeben. Er stellt dem Stakeholder nach einem aktuellen Sprint Zyklus den Prototyp vor und arbeitet Kritik oder Wünsche in den Product Backlog ein. Dieser Prozess wird Refinement genannt.
Scrum-Master:
Dieser ist in erster Linie verantwortlich, dass Scrum eingehalten wird und er schützt das Team vor Störungen von außen. Er schlichtet auch, wenn es zu Streitigkeiten innerhalb des Teams kommt.
Entwicklungsteam
Das Team besteht aus Testern, Programmierern, Business Analysten, UX Designern. Es bekommt vom Product Onwer die Anforderungsliste (Backlog) genannt vorgelegt und entscheidet selbst, wie sie damit im weiteren Schritt, dem Sprint vorgeht. Das Team sollte möglichst klein sein, um eine bessere Kommunikation zu gewährleisten. Ideal sind 6- 9 Mitglieder.
Scrum-Zeremonien:
Im agilen Vorgehensmodell Scrum gibt es die fünf nachstehenden Zeremonien:
- Sprint Planning
- Sprint
- Daily
- Sprint-Review
- Sprint-Retrospektive
Scrum – Sprint Planning
Product Owner ermittelt anhand des Product Backlogs, welche Aufgaben die höchste Priorität besitzen und gibt das Sprint-Ziele bekannt. Diese werden dann in das Sprint Backlog gezogen und besprochen, falls etwas nicht klar ist.
Product Owner, Scrum Master und das Team bestimmen die Dauer des Sprints, aber wenn Sie sich nicht einigen können, hat der Scrum Master das letzte Wort und legt die Dauer fest.
Scrum – der Sprint
Sprints haben immer eine gleichbleibende Dauer, auch Timebox genannt. Sie können von 1 bis maximal 4 Wochen andauern – 2 Wochen haben sich oft etabliert. Dort werden die Tickets aus dem Sprint Backlog bearbeitet. Sind sie Tickets geschlossen, werden sie ins Sprint-Review gezogen.
Daily Scrum
Scrum Team bespricht in max.15 Minuten täglich Fortschritte und eventuelle Hindernisse. Damit alle Teammitglieder eine Übersicht über den aktuellen Status quo des Sprints haben und bei Hindernissen einander unterstützen können. Die folgenden Punkte werden besprochen:
- Was habe ich gestern gemacht?
- Was werde ich heute machen?
- Gibt es Impediments?
Sprint-Review
Das Sprint-Review findet am Ende jedes Sprints statt. Es werden die Sprintergebnisse vorgestellt. Kunden und/oder Stakeholder können ihr Feedback dazu geben und das Product Backlog wird dementsprechend angepasst.
Sprint-Retrospektive
Fehler und Schwächen werden besprochen. Wie kann man die Arbeit des Teams optimieren? Welche Prozesse waren gut? Welche Tools hilfreich? Am Ende sollte jedoch mindestens ein Verbesserungsvorschlag im Sprint-Backlog aufgenommen werden.
Basics Frontend & Backend für Tester
In diesem Workshop hat uns Jakob erklärt, was ein Frontend und was ein Backend ist. Als Frontend bezeichnet man den Teil einer Webapplikationen, die User sehen können wie beispielsweise: Schriften, Farben, Texte, Menüs, Buttons, Tabellen.
Es setzt sich aus den Technologien HTML, CSS und Javascript zusammen. HTML ist für die Strukturierung und den Aufbau der Website verantwortlich. CSS ist für das grafische Design der Website zuständig. JavaScript erweckt dann die Seite zum Leben, damit es möglich ist, mit der Website zu interagieren.
Wenn wir uns beispielsweise auf Facebook einloggen, sendet das Frontend eine Anfrage (Request) an das Backend, genauer gesagt an einen Webservice. Webservices können mit anderen Webservices kommunizieren, um die Anfragen vom Frontend zu verarbeiten und als Antwort (Response) zurück ans Frontend zu schicken.
Für die Response gibt es verschieden Status Codes, die jeder von uns schon mal gesehen haben sollte. z.B.: 400 Bad Request/ 401 Unauthorized/ 200 OK.
In den meisten Fällen tauscht das Frontend mit den Webservices Daten im JavaScript-Object-Notation-Format aus. Dann gibt es noch die sogenannten HTTP Verben: Put, Get, Post, Delete.
Weitere Lernpakete (User Stories)
Mein Team und ich hatten noch verschiedene Tickets, die wir alleine abarbeiten sollten. Eins davon war eine einstündige Test-Session beim Gruyère Login. Damit unsere Coaches einen Einblick in unsere initiale Herangehensweise bekommen, sollten wir einfach mal darauf los testen und ausprobieren, wie wir so etwas angehen würden.
Bei der zweiten User Story sollten wir uns bei verschiedenen Crowdtesting Seiten anmelden und den Einstiegstest durchführen. Ich habe mich bei Test IO angemeldet und über einen Zeitraum von einer Woche, vier verschiedene Fehlerberichte eingereicht. Die Anforderungen bei Test.io waren sehr unklar und ohne wirkliches Feedback wurden meine eingereichten Fehlerberichte abgelehnt. Diese Erfahrung haben auch weiter Teilnehmer meines Teams gemacht, dies hat uns sehr demotiviert.
Nach Absprache mit Jakob und Francesco sollten wir uns dann bei einer alternativen Crowdtesting Seite anmelden und es erneut versuchen. Gesagt, getan, bei Testbirds angemeldet und siehe da, es klappte auf Anhieb. Der Bug Report wurde angenommen. Ich habe sogar gutes Feedback bekommen, was mich stolz machte und mich sehr erleichterte.
Alles in allem, war es ein sehr aufregender Sprint im Lernkonzept der Qcademy, mit kleineren und größeren Hürden, die zu meistern waren. Ich bin auf den nächsten Sprint sehr gespannt und hoch motiviert.
