Die Organisation muss einen Entwicklungsprozess erarbeiten, umsetzen und aufrechterhalten, der dafür geeignet ist, die anschließende Produktion und Dienstleistungserbringung sicherzustellen. Bei der Bestimmung der Phasen und Steuerungsmaßnahmen für die Entwicklung muss die Organisation die benötigten dokumentierten Informationen bereitstellen, um zu bestätigen, dass die Anforderungen an die Entwicklung erfüllt wurden.
ISO 9001, Kapitel 8.3

Der prozessorientierte Ansatz der Qualitätsmanagementnorm ISO 9001 (2015) macht es zwingend notwendig, mindestens die Produktionsprozesse im Unternehmen zu dokumentieren. Wir produzieren Software, entweder direkt als Gewerk nach Spezifikation für einen Kunden oder indirekt als Berater beim Kunden, der individuell entwickelte Software für seine eigenen Produktionsprozesse benötigt. Darum unterscheiden wir grundsätzlich zwei Arten von Produktionsprozess: Die Entwicklung von Individualsoftware und die Beratung für Individualsoftware.

Jeder Prozess ist ein wichtiger Baustein in unserer QM-Dokumentation in Confluence. Der Steckbrief eines Prozesses enthält eine Kurzbeschreibung. In weiteren Abschnitten erfassen wir wichtige Qualitätsziele, Risiken und Chancen und geben einen Überblick über die Tätigkeiten, die von Personen entsprechend ihrer Rolle durchgeführt werden. Mindestens einmal pro Jahr nutzen wir ein internes Audit, um die Prozesse zu überprüfen und Qualitätsziele, Risiken und Chancen zu aktualisieren.

Im Produktionsprozess für die Beratung für Individualsoftware müssen wir uns als Dienstleister in den Prozessen des Kunden bewegen. Unser eigener Prozess beschreibt daher nur jene Tätigkeiten, die für unser Unternehmen relevant sind, z.B. Arbeitszeiterfassung, Vorgehen bei Angeboten und die Leistungsabrechnung. Bei unseren Kunden treffen wir beispielsweise auf Scrum, Kanban oder das V-Modell.

Scrum ist ein Prozessmodell zur agilen Softwareentwicklung. Der Fortschritt eines Projektes wird täglich und für alle sichtbar festgehalten und Hindernisse schnell erkannt. Die Anforderungen an das Produkt werden nicht ein und für alle Mal im Vorfeld festgelegt, sondern nach jedem Sprint neu bewertet und priorisiert. Scrum besteht aus nur wenigen Regeln. Diese beschreiben fünf Aktivitäten, drei Artefakte und drei Rollen. Der Ansatz von Scrum ist empirisch, inkrementell und iterativ. Scrum ist für Teams mit einer Größe von drei bis neun Entwicklern konzipiert.

https://de.wikipedia.org/wiki/Scrum

https://www.scrum.org/resources/scrum-guide

https://www.scrumalliance.org/learn-about-scrum/the-scrum-guide

Kanban ist ursprünglich eine Methode der Produktionsprozesssteuerung. Es wurde als Prozessmodell für die Softwareentwicklung adaptiert. Aufgaben werden visualisiert, die Anzahl paralleler Arbeiten begrenzt. Vorrangiges Ziel ist ein kontinuierlicher störungsfreier Ablauf von parallelen Tätigkeiten in der Softwareentwicklung. Kanban ist auch eine Arbeitsphilosophie, deren Motor das Streben nach ständiger Verbesserung ist. Anders als Scrum hat Kanban keine Sprints mit fester Länge und keine Vorschriften für die “Größe” einer Aufgabe.

https://de.wikipedia.org/wiki/Kanban_(Softwareentwicklung)

http://www.kanban-plakat.de/

Das V-Modell ist ein phasenorientiertes Prozessmodell für die Softwareentwicklung. Phasen der Entwicklung werden den Phasen für den Test gegenübergestellt. So ergibt sich das namensgebende “V” mit der Phase Entwicklung an der Spitze. Zwischen den Phasen gibt es definierte Übergänge, z.B. die Phase Anforderungsanalyse wird mit der Bereitstellung einer Fachkonzeption für die Entwicklung abgeschlossen. Das V-Modell ist an die jeweiligen Bedürfnisse anpassbar. Im V-Modell werden Aktivitäten und Ergebnisse definiert, aber keine strikte zeitliche Abfolge gefordert. Insbesondere fehlen die für klassische Wasserfallmodelle typischen Abnahmen am Ende einer Phase.

https://de.wikipedia.org/wiki/V-Modell

http://www.v-modell-xt.de/

Gerade in großen Unternehmen prägen die Strukturen der Geschäftsfelder, Fachabteilungen und Linienorganisation immer noch die Arbeitsweise in den Projekten. Agilität und Digitalisierung sind mittlerweile bei allen Kunden oft zu hörende Schlagworte. Die Realität führt aber zu Prozessmodellen, die intern mit Scrumban oder Scrumfall bezeichnet werden. “Agile” wird plötzlich zum wertlosen Modewort. Die Wirksamkeit speziell von Scrum geht sehr häufig verloren.

In unserem eigenen Produktionsprozess für die Entwicklung von Individualsoftware spielen agile Methoden eine zentrale Rolle. In der Regel setzen wir auf Scrum als Prozessmodell. Wie die Erfinder von Scrum es fordern, befolgen wir ausnahmslos alle Regeln und besetzen alle Rollen – so viele sind es ja nicht. Wir sparen uns darum auch eine Beschreibung von Scrum in der QM-Dokumentation. Scrum gehört bei uns zum Handwerkszeug jedes Entwicklers.

Natürlich gibt es auch so kleine Projekte, bei denen der Einsatz von Scrum keinen echten Mehrwert darstellt und die Regeln eher lästig sind. Klein bedeutet beispielsweise, dass es nur einen einzelnen Entwickler gibt, kein Team. Klein bedeutet auch, dass die Projektlaufzeit sehr kurz bemessen ist.

Die Projektverantwortlichen können für jedes Projekt individuell entscheiden, welches Prozessmodell sie einsetzen. In der Projektseite wird diese wichtige Entscheidung dokumentiert. Fällt die Wahl auf Scrum, dann reicht ein kurzer Hinweis. In jedem anderen Fall enthält die Projektseite eine Kurzbeschreibung des vereinbarten Prozesses. Außerdem wird die Abweichung, d.h. Scrum nicht einzusetzen, angemessen begründet.

Es hat sich gezeigt, dass speziell für Projekte im “Wartungsmodus” der Einsatz von Scrum nicht mehr so vorteilhaft ist. Die Aufgaben der Wartung lasten kein Team mehr aus. Die Aufgaben – in der Regel die Behebung von Fehlern in der Software – sind schwer einzuschätzen und müssen unabhängig von ihrer “Größe” in den meiste Fällen behoben werden. Es passiert daher nicht selten, dass ein junges Projekt mit Scrum startet. Ist das Projekt erfolgreich und das Produkt wird eingeführt, wechselt das Projekt in das Prozessmodell Kanban.

In allen Fällen aber gilt als Mindestanforderung für jedes unserer Projekte die Erfassung der durchgeführten Aufgaben in JIRA. Das ist notwendig für einen Nachweis der eigenen Leistung gegenüber unseren Kunden.

Die Verwendung von JIRA ist aber keine zusätzliche Belastung. Bei einem Projekt mit Scrum als Prozessmodell verwenden wir eine Story im Backlog nicht nur für die Priorisierung der Aufgaben und die Planung der Sprints, sondern auch für die Abrechnung der Leistung. JIRA kann ein Backlog und einen Sprint sehr gut darstellen. Scrum erfordert sowieso eine Messung der Geschwindigkeit (englisch: velocity) des Teams. Der Product-Owner braucht diese Information für eine belastbare Roadmap. Dem Team hilft diese Information für eine zuverlässigere Zusage (englisch: commitment) zum Inhalt eines Sprints.

Auch ein Projekt ohne Scrum profitiert von JIRA, wenn es sich an Kanban als Prozessmodell orientiert. JIRA zeigt alle Aufgaben in einem Board mit den Spalten “geplant”, “in Arbeit” und “erledigt”.

Wir erfüllen die Anforderungen der Qualitätsmanagementnorm durch den Einsatz agiler Prozessmodelle. Wir beherrschen unseren Entwicklungsprozess. Wir haben Scrum oder Kanban nicht selbst erfunden, aber wir sind mit ihnen erfolgreich. Die dokumentierte Information, die bestätigt, dass die Anforderungen an die Entwicklung erfüllt wurden, befindet sich in JIRA.