Agile Softwareentwicklung bei KMS

Softwareunternehmen müssen schnell und flexibel neue Funktionen und eventuelle Fehlerbehebungen bereitstellen. Dies erwartet nicht nur der Kunde, es wird auch durch die enorme Geschwindigkeit gefordert, mit der sich die IT-Branche in den vergangenen Jahren entwickelt hat.

Der Begriff „agil“ ist schon seit Längerem eines der großen Schlagworte bei Entwicklungs- und Projektmanagementmethoden, nicht nur in der Softwareentwicklung. In der Vergangenheit wurde überwiegend auf Wasserfallmodellen gearbeitet. Sie verlangen im Vorfeld viel Spezifikationsarbeit und erlauben während der einzelnen Umsetzungsphasen wenig Eingriffsmöglichkeiten. Fehler und insbesondere Fehlinterpretationen der Anforderungen wurden somit viel zu spät erkannt.

Insbesondere die Softwareentwicklung unterliegt einem stetigen und schnellen Wandel. Der Entwicklungsprozess muss somit fortlaufend optimiert werden. Agile Methoden und Frameworks helfen dabei, komplexe Prozesse zu strukturieren und die Produktivität von Entwicklerteams zu erhöhen, während gleichzeitig die Qualität der entwickelten Software steigt.

Selbstkritisch ist zu erwähnen, dass dies bei weitem nicht immer gelingt; am Ende sind agile Methoden auch nur ein Ansatz von vielen. Welcher Ansatz für das jeweilige Unternehmen sinnvoll ist, hängt vom Team, dem Produkt und nicht zuletzt von den Kundenanforderungen ab. Eine Anpassung der agilen Methoden an die wirklichen Bedürfnisse ist daher essenziell.

Die Erkenntnis, dass Abweichungen vom Plan eher die Regel als die Ausnahme sind, bildet die Grundlage für agiles Projektmanagement. Oft sind die Anforderungen an das Produkt bzw. das Projektergebnis zu Projektbeginn noch nicht klar genug definiert. Agil zu sein bedeutet dabei, in kleinen Schritten vorzugehen, statt alle Teilbereiche eines Projekts präzise vorzubereiten und sequenziell abzuarbeiten.

Um die abgeleiteten Werte und Prinzipien des Agile Manifestos in der Praxis umzusetzen, sind nach und nach verschiedene Techniken entstanden, die wiederum in sogenannten agilen Methoden praktisch umgesetzt wurden. In der Wissenschaft sind mehr als 30 Methoden definiert, die sich teilweise stark ähneln. Aus der Softwareentwicklung sind diese Methoden nicht mehr wegzudenken. Inzwischen werden solche Konzepte auch vermehrt auf Projekte außerhalb der Softwareentwicklung übertragen.

Für die agile Methode Scrum, die bei KMS zum Einsatz kommt, ist neben den Rollen, die die jeweiligen Personen im Team wahrnehmen, vor allem der Prozess kennzeichnend. Am Anfang steht dabei eine Produktidee. Die grobe Vorstellung vom Produkt, Modul oder der Teillösung, die im Projekt erarbeitet werden soll, wird zum Auftrag.

Scrum zeichnet sich vor allem durch regelmäßige und wiederholbare Arbeitsabläufe aus. Diese Zyklen werden Sprint genannt und sind zeitlich begrenzt (bei KMS drei Wochen). Der Produktverantwortliche (Product Owner) kann innerhalb dieses Entwicklungszyklus keine Änderungen an den für diesen Zeitraum geplanten Anforderungen vornehmen, da diese das Entwicklerteam in seiner Arbeit stören würden.

Die Ausnahme bildet die Behebung kritischer Fehler. Während eines Sprints nimmt der Product Owner seine Vorstellungen (Stories) von der weiteren Entwicklung in Abstimmung mit den internen und externen Interessensgruppen (Stakeholder) in das sogenannte Product Backlog auf und sieht sie somit für kommende Sprints vor.

Wie sich diese theoretischen Ansätze in der Praxis bei KMS darstellen, soll im Folgenden anhand eines typischen Arbeitstages in der Entwicklungsabteilung geschildert werden:

Morgens wird mit einem Daily Stand-up-Meeting gestartet. Dabei werden neue, eventuell vom Kunden über den Support gemeldete Probleme bewertet und bei kritischen Themen sofort in das Sprint Backlog mit aufgenommen. So kann zeitnah ein Bugfix erfolgen. Zusätzlich werden die Aufgaben (Tasks) aus den geplanten Stories, die am jeweiligen Tag implementiert werden, kurz durchgesprochen, eventuell gegenseitige Unterstützung im Team angeboten und aufgetretene Probleme bei der Umsetzung des vergangenen Tages diskutiert. Anschließend erfolgt im Team die Implementierung der Tasks.

Im Backlog Refinement, das nicht an jedem Tag stattfinden muss, werden die vom Product Owner geplanten Themen aus dem Product Backlog hinsichtlich des geschätzten Aufwands bewertet. Dies ist einerseits wichtig, um die spätere Umsetzung besser terminieren zu können, andererseits bildet dies auch die Grundlage für den Vertrieb zur Angebotserstellung. Es werden auch technische Spezifikationen zur Umsetzung vorgenommen, sodass diese bei einer späteren Zuordnung zu einem Sprint beim Sprint Planning nur noch implementiert werden müssen.

Gegen Ende des Arbeitstages werden Tasks, die seitens der Entwickler freigegeben sind, final getestet und eingecheckt, sodass diese Themen über einen automatisierten Prozess nachts als Live Update allen Kunden zur Verfügung gestellt werden. Dazu gibt es eine Definition of Done, die klar festlegt, wann eine Aufgabe als fertiggestellt gilt. Anhand des Burn-Down-Charts haben das Team und auch der Product Owner jederzeit die Möglichkeit, den Arbeitsstand des Teams einzusehen und frühzeitig bei Unregelmäßigkeiten gegenzusteuern.

Am Ende eines Sprints findet eine Review statt. Dabei werden den Stakeholdern die fertigen und lieferbaren Stories präsentiert, sodass die Inhalte und Neuerungen verstanden und im Gespräch eventuelle Schwachstellen erkannt werden. Darüber hinaus erfolgt eine Retrospektive, bei der im Sinne eines kontinuierlichen Verbesserungsprozesses die Themen, die gut und schlecht gelaufen sind, offen diskutiert und daraus Maßnahmen abgeleitet werden. Im anschließenden Sprint Planning des neuen Sprints werden anhand der Stories aus dem Product Backlog, die zuvor vorbereitet worden sind und somit einen hohen Reifegrad haben, die Themen des neuen Sprints zusammengestellt. Dabei ist wichtig, dass das Team nur so viele Punkte im Sprint plant, wie man sich anhand der fachlichen Themen und der aktuell verfügbaren Kapazität zutraut.

Durch die agile Softwareentwicklung hat KMS die Fähigkeit, schnell und effizient auf veränderte Anforderungen aus den jeweiligen Kundenprojekten zu reagieren. Die Umsetzung kleiner, überschaubarer Stories mit schneller Rückmeldung durch die Stakeholder vermeidet im Allgemeinen Mehrfachimplementierungen aufgrund eventueller Fehlinterpretationen. Dabei sind stets alle Aktivitäten auf die Kundenbedürfnisse ausgerichtet. Dies ermöglicht sowohl die schnelle Reaktion auf eventuelle Fehler, die durch ein Daily Delivery rasch auf den Kundensystemen bereitgestellt werden kann, als auch Produkterweiterungen und Neuentwicklungen, die über mehrere Sprints hinweg entstehen und somit zeitnah an unsere Kunden ausgeliefert werden.