© saicle/Shutterstock.com
Agile Methoden

Kolumne: A² - alles Agile


Besonders in der agilen Softwareentwicklung ist Refactoring ein integraler Bestandteil des Softwareentwicklungsprozesses und beschränkt sich nicht auf spezifische Phasen oder Zeiten. Die Zielsetzung des Refactorings darf bei diesem Prozessschritt nicht außer Acht gelassen werden. Refactoring findet nicht zum Selbstzweck statt. Es empfiehlt sich, sowohl beim manuellen als auch beim automatischen Review nur vorher abgestimmte Regeln zu kontrollieren. Vielfach werden die Coderegeln etc. schon vor dem Reviewarbeitsschritt durch das Team festgelegt. Dabei gilt es, Regeln, die für ein Projekt als nicht sinnvoll empfunden werden, herauszufiltern. Werden Regeln aufgestellt, die vom Team nicht akzeptiert werden, können sie zwar durchgesetzt werden, behindern aber einen qualitativen Reviewprozess. Ziel ist es, die Codequalität zu verbessern, um Wartung und Erweiterbarkeit effizienter gestalten zu können. Insgesamt muss der Aufwand, um das zu erreichen, um ein Vielfaches geringer sein als der Aufwand für die Wartung/Erweiterbarkeit ohne diese Regeln.

Automatisierte Tests und Unit Tests unterstützen das Refactoring in besonderem Maße. Nach jedem Refactoring-Schritt stellen sie sicher, dass der veränderte Codeteil die bedienten Requirements nach wie vor abbildet.

Story Cards

Im klassischen Projektmanagementprozess wie etwa dem V- oder dem Wasserfallmodell werden sämtliche Requirements in der Spezifikationsphase erfasst und in entsprechenden Dokumenten festgehalten. Oft sind das Lasten- und Pflichtenhefte, die je nach Projekt entsprechend umfangreich werden können. Auch im agilen Projektmanagement gibt es Spezifikationsphasen, allerdings nicht allumfassend für das gesamte Projekt, sondern lediglich – wie z. B. im Scrum-Prozess – vor jedem Sprint.

Ein Hilfsmittel, das in dieser Phase Anwendung findet, sind die Story Cards. Mit ihnen wird den Stakeholdern die Anforderung genommen, ein vollumfängliches Lastenheft zu erstellen, das unter anderem schon technische Aspekte betrachtet. Auf einer Story Card wird jeweils eine User Story beschrieben, die darlegt, welche Funktionalität aus Usersicht gewünscht ist. Das geforderte Verhalten des zu erstellenden Systems wird durch prosaische Kurzbeschreibungen spezifiziert. Durch diese Art der Darlegung wird es den Stakeholdern erleichtert, die Beschreibung in ihrer eigenen Sprache zu verfassen, ohne zum Beispiel technische Fachbegriffe zu benutzen.

Story Cards finden sich unter anderem im Scrum-Prozess wieder, bei dem am Anfang eines Sprints vom Team zusammen festgelegt wird, welche Storys im Sprint umgesetzt werden. Um sie angemessen ein- und abschätzen zu können, ist es unabdingbar, dass pro Story – und demzufolge pro Story Card – nur kleine Teilaspekte des Gesamtsystems betrachtet und niedergeschrieben werden. Die Storys sollten hierbei so gestaltet sein, dass sie für sämtliche am Softwareentwicklungsprozess Beteiligten verständlich sind. Ist das nicht der Fall, müssen diese Missverständnisse zeitnah adressiert und kommuniziert werden. Auf diese Weise rückt auch bei den Story Cards wiede...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang