Agile Softwareentwicklung mit Screenreader

Agile Softwareentwicklung mit Screenreadern

Einleitung

Viele fragen sich jetzt, was denn bitte das Eine mit dem Anderen zu tun hat. Habe ich etwa lange Weile und will Banalitäten verkünden?

In der Tat nicht. Wer die agilen Prozesse kennt, weiß dass man dort sehr schnell mit Hilfsmitteln wie Kärtchen, Pinwänden etc. arbeitet. Das wirkt sich auch auf die Software aus, die diese Prozesse unterstützt - sie sehen grafisch recht ansprechend aus und man kann flux Stories in andere Sprints verschieben - mit der Maus meine ich.

Eine zugängliche Software finden

Ich habe as große Glück, dass eine Software bei mir im Team nur dann eingesetzt wird, wenn ich die bedienen kann. Mit Idiologie hat das nur wenig zu tun. Jeder Handgriff, den mir jemand anderes abnehmen müsste kostet Zeit, macht uns unflexibler und ist eben doof. Und so lange es noch eine Auswahl gibt, warum nicht versuchen die Anforderungen zu erfüllen? Bei der Evaluierung sind viele Produkte über die Accessibility-Klinge gesprungen. Mal eine kurze Liste mit den unzugänglichen Anwendungen:

• VersionOne
• Lösungen die von uns entwicklt wurde n und adaptiert wurden
• und noch einige Namen, die mir gerade nicht einfallen, weil die Evaluierung nach ein paar Minuten vorbei war.

Neben der Accessibility-Klinge kam die Prozessklinge zum Einsatz. Viele Tools unterstützen den Prozess nicht ausreichend, sind zu unflexibel oder haben andere gravierende Probleme. Dazu gehört z.B., auch das sonst ganz nette Agilo. Es handelt sich dabei um eine auf Trac - was ja sonst ganz gut zugänglich ist, aufgesetzte Software. Die Tatsache, dass ein Benutzernicht Mitglied mehrerer Projekte/Teams sein kann, war der Todesstoß. Zudem ist die Projekteinrichtung gelinde gesagt eine Katastrophe. Auch hier gab es noch andere Produkte, deren Evaluierung ebenfalls sehr schnell beendet war.

Derzeit evaluieren wir schon seit einer ganzen Weile das Produkt TinyPm [[1]]. Bislang hat die Prozessklinge noch nicht geschnitten und die Accessibility-Klinge nur leicht gekratzt. Es gibt dort eine Art Stundenzettel, auf dem man die Arbeiten zu den einzelnen Tasks der Stories buchen kann. Die Übersicht zeigt ein paar ineinander verschachtelte Tabellen, die einen raschen Überblick für sehende darbieten. Dort kann denn auch per Klick auf die richtige Stelle eine Zeit eingegeben werden. Mit JAWS - und wohl auch mit anderen Screenreadern, ist hier kein Weiterkommen. Allerdings hat der Support mittlerweile versprochen, eine einfache Formular-Eingabe zu ermöglichen. Apropos Zeit: Auch das Eingeben von Start- und Endzeit eines Tasks ist nicht so konfortabel, man muss sie als Screenreadernutzer in einem Format yyyy-mm-dd hh:mi eingeben. Etwas blöd, aber effizient nutzbar.

Der Prozess

Alles wichtige zu SCRUM und agiler Softwareentwicklung findet sich unter [[2]]. Hier deshalb nur ein kurzer Überblick für die, denen das ganze bislang nichts sagt: - Jede Benutzeranforderung wird als sog. User Story aufgenommen. User Stories beschreiben eine Funktionalität rein aus Benutzersicht. Beispiel: Als Benutzer kann ich in einer beliebigen Anwendung über den Screenreader alle Werkzeugleisten trainieren lassen. Die Werkzeugtexte werden abgelegt und sind anschließend jederzeit per Tastendruck abrufbar. Eine solche User Story wird vor der Entwicklung in sog. Tasks aufgeteilt - also technische Teilaufgaben, um die Funktionalität umzusetzen,. Dazu gehören Doku, Testen, erforschen geeigneter Wege zur Umsetzung, die Umsetzung selbst etc. Eine Usr Story wird ín Punkten abgeschätzt, die eine Art maßstab für Komplexität und Risiko darstellen. Tasks hingegen werden in Stunden abgeschätzt. Die Entwicklung läuft immer in sog. Iterationen oder Sprints ab. Diese sind i.d.R. gleich lang und einem Sprint werden eine Anzahl von User Stories zugewiesen. Am Ende des Sprints sollen die User Stories fertig sein. Das Entwicklerteam verspricht die Umsetzung der User Stories innerhalb des Sprints. Die Halde aller User Stories nennt man Productbacklog - die Sammelstelle für die Arbeit in einem Sprint Sprintbacklog. Viele Teams schreiben die Stories etc. auf Karten und heften sie an Pinnwände etc. Das macht die 'Arbeit etwas haptischer und der Entwickler hat neben der Kaffeemaschine endlich noch einen anderen Fußweg.

Fazit

Agile Softwareentwicklung ist blind nur mit einer Abbildung der Stories etc. in einer Software machbar. Die haptische Variante würde zu viele Anpassungen/Änderungen bedeuten z.B. taggen der einzelnen Kärtchen etc., weil man oft die Kartemn lesen, verschieben und barbeiten muss. Als einzige wirklich nutzbare Software ht sich bislang TinyPm herausgestellt.