Getting done your non-functional requirements – Scrum, XP und GTD effektiv kombinieren

Thomas Starz

Der Vortrag steht als PDF Dokument zum Download bereit.

Product Owners, also diejenigen, die die Anforderungen an Software definieren, konzentrieren sich typischerweise auf die Definition von funktionellen Anforderungen (functional requirements). Dazu benutzen sie z.B. User Stories. Aber ein typischer Product Owner definiert keine nicht-funktionalen Anforderungen (non-functional requirements) und hat auch wenig Anhaltspunkte, Geschäftsnutzen damit zu verbinden. Das stellt Teams vor das Problem, ob Aufgaben wie Arbeiten an der Infrastruktur, Automation, oder Änderungen am Entwicklungsprozess im Backlog reflektiert werden sollen und, wenn ja, wie.

Um Projekte zum Erfolg zu führen, müssen Teams auch nicht-funktionale Anforderungen adressieren können. Methoden wie Getting Things Done (GTD) liefern nützliche Empfehlungen, wie dieses Problem gelöst werden kann; zum Beispiel "Schreibe alles auf, um es aus dem Kopf zu bekommen". Scrum fordert, Prioritäten kontinuierlich zu überprüfen, jegliche Arbeit zu schätzen, und sich darauf zu konzentrieren, Dinge zu erledigen; leichtgewichtiges Tracking und verläßliche Akzeptanz-Kriterien inklusive.

In der Session werden Erfahrungen und Empfehlungen vorgestellt, die Teams helfen können, ihre nicht-funktionalen Anforderungen zu effektiv zu behandeln.

Inhalt:

• Einführung zu Strategien und Praktiken der Selbstorganisation.
• Beispiele, wie die grundlegenden Mechanismen von Scrum die Selbstorganisation "to get things done" unterstützen
• Beispiele, wie Projekt-Aufgaben und persönliche Aufgaben integriert werden können
• Reale Beispiele nicht-funktionaler Anforderungen und wie diese in der Praxis behandelt wurden – erfolgreiche und weniger erfolgreiche Versuche
• Eine aktive Diskussion mit den Zuhörern, was die wichtigsten Punkte sind, die für die Behandlung von nicht-funktionalen Anforderungen beachtet werden müssen

Ziel ist es, den Zuhörern zu vermitteln, welche Praktiken angewandt und/oder sinnvoll kombiniert werden können, um funktionelle und nicht-funktionelle Anforderungen in einem Projekt so effektiv wie möglich zu behandeln.

 

Nach dem Studium der Elektrotechnik an der Uni Karlsruhe begann ich 1986 als Programmierer für Micro-Controller für Bankensysteme im IBM Entwicklungslabor in Böblingen. Nach verschiedenen Aufgaben als Programmierer, technischer Autor, Teamleiter und Projektleiter begann ich ca. in 2002, mit agilen Methoden zu arbeiten, zunächst mit Praktiken des eXtreme Programming. Später kam ich zu Scrum und zertifizierte ich mich als Scrum Master und Scrum Practitioner. In 2007 übernahm ich als Teamleiter und Scrum Master ein lokales Scrum Team, um ein komplett neues Produkt zu entwickeln.