Aktuelle Themen und Informationen

Agiles Testen bei Scrum

Thema vom Januar 2013

Agile Entwicklung mit Scrum definiert die Entwicklungszeit auf zeitlich befristete Sprints (Hinweis: Sprints sind nicht per se 4 Wochen lang). Qualitätssicherung und Testaktivitäten müssen demzufolge mit der Integrationssequenz Schritt halten. Dies auf allen Testebenen (von Unit-Test, Integrationstest bis zum Systemtest)! Aus Teststufen werden somit Testaktivitäten, die in „Mikrozyklen“ innerhalb von 24 Stunden ablaufen. Allen Beteiligten liegt so stets das tagesaktuelle, vollständige Bild über Entwicklungsstand und Produktqualität vor. Fehler und mögliche Korrekturen werden unmittelbar oder spätestens im Daily Scrum diskutiert, priorisiert und umgesetzt. Entscheidend ist hier auch die Zusammenarbeit zwischen Entwickler und Tester.

Das heisst, dass Unit-Tests und Integrationstests innerhalb weniger Minuten automatisiert in jedem Build ablaufen. Auch Systemtests sind parallel zur Feature-Entwicklung zu schreiben umso „Test First“ auch im Systemtest erfolgreich anwendet zu können. Um den Zyklus einhalten zu kommen kümmert sich das Projektteam um die Automatisierung der Systemtests, dass alle nötigen Systemtests - als Teil einer Continuous Integration oder im Nightly-Build - automatisiert mitlaufen.

Product Backlog (Definition of Ready)
Backlog Items werden auch aus Testsicht erstellt und die Verwendbarkeit für den Test sichergestellt. Man hält fest, wie die Akzeptanztests am Ende des Sprints gestaltet werden. Die Testbarkeit ist zu berücksichtigen und der Tester kann (eher muss?) bei der Erstellung der Akzeptanzkriterien mitwirken. Auch die Realisierbarkeit von User Stories ist zu prüfen. Man vermeidet so unfertige oder nicht testbare Stories, die das Sprintziel gefährden.

Definition of Test
Die „Definition of Test“ ist ein schlankes Testkonzept, das Sprint für Sprint aktualisiert wird und damit den Anforderungen des Produkts, der Organisation und des Teams jederzeit gerecht wird. Man formuliert in Kurzform die wesentlichen Regeln für den Test. Hier wird festgelegt, wie und wo Tests und Testergebnisse dokumentiert werden, welche Methoden und Werkzeuge wie eingesetzt werden und die für das Projekt optimale Teststrategie vereinbart.

Sprint Backlog und Test First
Dies zeigt auf, wie Tester und Entwickler Backlog Items gemeinsam in Entwicklungs- und Test-Tasks planen, den Umfang schätzen und diese mittels Pair Programming, Pair Testing und dem Prinzip des „Test First“ realisieren. Was umfasst das Prinzip „Test-First“ genau?

Definition of Done
In der DoD wird die gemeinsame Sicht des Teams festgehalten, welche Kriterien zu erfüllen sind, damit am Sprintende eine Story dem Product Owner als „fertig“ demonstriert werden kann. Das umfasst Implementierungsarbeiten ebenso wie Dokumentation und Test in einem jeweils individuell abgestimmten, durch die Teamcharta und die Definition of Test festgelegten Umfang. Das gemeinsame Verständnis von „fertig“ sorgt für hohe Planungssicherheit, konstruktive Zusammenarbeit und hohe Produktqualität.

Tested & shippable product
Am Ende jedes Sprints liegt somit ein potentiell auslieferbares Produkt vor. Durch permanentes Testen und durch systematische Erfassung, Bewertung und Prognose des Fehleraufkommens sorgt man dafür, dass das Ergebnis eines Sprints wirklich „shippable“ ist – jedes Mal.

Projekte nach Scrum

Thema von Juni 2012

Projekte haben laufend mit Änderungen zu tun, teilweise" kämpfen" die Unternehmen permanent mit Veränderungen. Unsere Erfahrungen bei verschiedenen Unternehmungen zeigen, dass sequenziell aufgesetzte Projekte zu Beginn sehr schwammig formuliert sind (fehlender Projektsetup) und Fortschritte nur schwer (da keine KPI vorhanden) nachzuvollziehen und zu messen sind. Hinzu kommt nicht selten, dass sich sowohl grundlegende Elemente wie Entwicklungssprachen, Hardware, Prozesse und Kundenanforderungen im Laufe des Projekts ändern. Eine Studie der Standish Group hat ergeben, dass nur 16% aller IT-Projekte erfolgreich sind. Folglich enden 84% aller IT-Projekte mit überzogenen Zeitplänen, überzogenen Budgets oder mit nicht fertiggestellten Funktionen.
Aufgrund dieser Tatsachen hat heute ein Unternehmen das IT-Projekte realisiert zwei Möglichkeiten:

  • Die erste Möglichkeit ist die Akzeptanz der Tatsache, dass sein Projekt mit einer Wahrscheinlichkeit von 84% länger dauert als geplant, teurer wird als veranschlagt und nicht abgeschlossene und unfertige Funktionen erhält. In jedem Fall wird sich die Begeisterung der Unternehmung in Grenzen halten.
  • Die zweite und logischere Vorgehensweise besteht in der aktiven Steigerung der Erfolgsquote von Projekten.

Hier kommt Scrum ins Spiel. atama verfolgt konsequent bei der Durchführung von Projekten den Scrum-Ansatz. Scrum (Deutsch ein Gedränge) beschreibt einen Spielzug im Rugby, der auf den ersten Blick wie ein unüberschaubares Gedränge wirkt, tatsächlich aber sorgsam einstudiert ist. Der Ansatz basiert auf wenigen klaren Regeln welche es erlauben, auf geänderte Anforderungen kontrolliert, aber flexibel zu reagieren. Eine zentrale Bedeutung bei der Durchführung von Projekten hat hierbei die Selbstorganisation und die Kommunikation innerhalb der Teams. Ein Projektleiter der bestimmt wer was wann zu tun hat, gibt es nicht. Vielmehr entscheidet das Team in verschiedenen Meetings selbst, was realistisch in einem bestimmten Zeitraum umsetzbar ist. Zur Förderung der Kommunikation und Weiterentwicklung des Teams werden verschiedene Meetings als Instrumente eingesetzt: Die Sprint-Planungssitzung, Daily Scrum, Sprint Review und Sprint Retrospektive. Dank der Einhaltung klar definierter Regeln werden diese Meetings nicht zum Zeitfresser, sondern gewährleisten eine klare Anforderungsbeschreibung, die frühzeitige Erkennung von Problemen und deren Lösung sowie eine kontinuierliche Verbesserung der Arbeitsabläufe und damit der Ergebnisse.
Nun stellt sich nur noch die Frage, welche Vorteile diese Vorgehensweise für eine Unternehmung hat, welche das Projektvorgehen auf Scrum umstellt. Zunächst führt Scrum zur klaren und nachvollziehbaren Steigerung der Mitarbeiterzufriedenheit. Die Selbstorganisation der Teammitglieder führt zu einer verbesserten Teamarbeit und zu weniger Arbeitsdruck dank wirklich realistischer Aufwandsschätzungen. Doch auch für den Auftraggeber oder der interne Sponsor hat Scrum viele Vorteile. Er wird durch den Entwicklungsprozess der auf kurzen festen Zeitintervallen basiert, aktiver in die Entwicklung mit einbezogen und enthält keine unfertigen Funktionen. Durch die strikte Priorisierung der Anforderungen, durch Vermeidung von Fehlleistungen und Überlastung sowie durch frühzeitige Problemerkennung und permanente Qualitätskontrolle stellt Scrum die Einhaltung von „Time to Market“, Qualität und Produktivität sicher. Nicht zuletzt dient Scrum somit auch den wirtschaftlichen Interessen.

Schneller mit Agilität?

Thema vom März 2012

Die rasante technologische Entwicklung, schnelle Änderungen von Kundenwünschen und wachsendes Qualitätsbewusstsein stellen die Softwareentwicklung täglich vor neue Herausforderungen. Mit einer agilen Vorgehensweise wie Scrum lassen sich diese Änderungen jedoch einfacher meistern. Agile Entwicklungsmethoden sind dabei sich durchzusetzen. Auf Scrum setzen heute nicht nur viele Grosskonzerne aus der Industrie und dem Dienstleistungssektor. Auch im Bundesumfeld hat Scrum Einzug gehalten und ist nun ein fester Bestandteil. Das Vorgehensmodell bietet nicht nur einen Prozessrahmen für agile Produktentwicklungen, sondern die Flexibilität welche die Teams heute benötigen, um das Tempo und die Qualität von Entwicklungsprojekten verbessern zu können. Der Unterschied von Scrum zu traditionellen Vorgehensweisen, wie sie etwa vorn Wasserfall-Modell oder vom V-Modell beschrieben werden, ist nicht komplexer als bei anderen Vorgehen. Im Grunde geht es darum in der Praxis das selbstbestimmende Arbeiten rsp das selbstorganisierende Team um zusetzten.

Scrum basiert auf anderen Prozessen und Rollen als traditionelle Vorgehensmodelle. Ein wesentliches Element von Scrum ist der Sprint. Damit werden zwei- bis vierwöchige Iterationen bezeichnet, an deren Ende ein funktionsfähiges Produkt Inkrement vorhanden ist. Ein Sprint beginnt mit der Auswahl von Aufgaben durch das Entwicklungsteam im Rahmen einer Planungssitzung. Während der Entwicklung arbeitet das Team die Aufgaben selbstorganisiert ab. Ein tägliches Kurzmeeting, das „Daily Scrum Meeting" dient der Koordination und dem Wissenstransfer im Team. Da am Ende ein lauffähiges Inkrement stehen soll, wird innerhalb des Sprints auch getestet. Ein Sprint endet mit einem Review und einer Retrospektive. In der „Retro“ wird der Sprint reflektiert und nach Verbesserungsmöglichkeiten gesucht. Scrum ist damit auch durch einen kontinuierlichen Verbesserungsprozess gekennzeichnet.

Neben den Teammitgliedern existieren zwei weitere Rollen. Dies sind der Product Owner und der ScrumMaster. Der Product Owner ist für die Strategie des Entwicklungsprojekts zuständig. Zu seiner Arbeit gehören die Releaseplanung sowie die Formulierung und die Priorisierung von Auftraggeber aus denen sich das Team je Sprint einig zur Bearbeitung auswählt. Der Product Owner spricht nicht nur direkt mit den Stakeholdern, sondern auch dem Team. Er nimmt an den Planungs- und Review Meetings teil. Gegenüber dem Team repräsentiert er damit die Stakeholder. Der ScrumMaster coacht das Team und unterstützt in der Bearbeitung von Problemen. Er schafft zudem ein optimales Projektumfeld. Konkret macht er Vorschläge, wie sich bestimmte Herausforderungen meistern lassen. Er motiviert, unterstützt die Kommunikation im Team und greift bei Konflikten ein. Gleichzeitig schützt er das Team vor äusseren Interventionen, so dass das Team in Ruhe arbeiten kann.

Wie gross der Wandel ist welcher Scrum erfordert, hängt von der Kultur und der Praxis der Zusammenarbeit der jeweiligen Unternehmung ab. Deswegen müssen die Prozesse auf das jeweilige Unternehmen angepasst werden. Unterschätzten darf man aber den Wandlungsprozess nicht und man soll ihm genügend Aufmerksamkeit widmen. Nur so lässt sich Scrum gewinnbringend in hierarchisch strukturierten Unternehmen umsetzten. Bewährt hat sich beim „Umbau“ solcher Organisationen neben einer engen Betreuung der betroffenen Mitarbeitenden vor allem die Pilotierung. Eine erste Einführung von Scrum gelingt am besten mit einem Kernteam, welches dann zum Ausgangspunkt der Veränderung für das gesamte Unternehmen wird. Wie umfassend die Veränderungen sein sollen, den Scrum erfordert, hängt von der Kultur und der Zusammenarbeit im Projekt ab.

Um den wichtigen Wettbewerbsfaktor „time-to-market“ zu beschleunigen, beschliessen laufend Unternehmungen Scrum einzuführen. Dies mit dem klaren Ziel schneller auf die aktuelle Marktsituation reagieren zu können und neuartige Funktionalitäten schneller für das eigene Angebot zu realisieren. Der Veränderungsprozess dauert gemäss unseren Erfahrungen rund ein Jahr. In dieser Zeit wurden die Mitarbeitenden zum Teil intensiv gecoacht und betreut. Es sind einige „Vieraugengespräche“ notwendig, in denen das neue Modell und die Gründe der Einführung diskutiert wurden. Darüber hinaus wurde die Teambildung unterstützt, beispielsweise mit einem Wochenende in einem Sporthotel. Nicht zuletzt konnten die Teammitglieder den Veränderungsprozess mitgestalten. Da der Einführungsprozess von Scrum eine Organisation grundlegend verändern kann, sind die Anforderungen an das Projektteam entsprechend hoch. Es muss Scrum verstehen und sollte zudem über Erfahrung mit Veränderungsprozessen verfügen. Denn der Prozess muss nicht nur massgeschneidert werden, die während der Einführung immer wieder auftauchenden Herausforderungen lassen sich mit Erfahrung auch besser und schneller meistern. Da Scrum neue Rollen in eine Organisation einführt, ist durch die Veränderung auch das Selbstverständnis der Mitarbeitenden in Bezug auf ihre Aufgabe und ihre Position betroffen.

Unsere Erfahrungen haben uns aufgezeigt, dass es bei Scrum nicht Grundlegend um Schnelligkeit geht: Dank Scrum kann man laufend auf Veränderungen innerhalb und ausserhalb des Projekts reagieren. Dank dieser Agilität werden die Termine gehalten und gegen Aussen der relevante „time-to-market“ Präsenz wahrgenommen. Dieser Umstand wird schlussendlich als Schnelligkeit und Agilität wahrgenommen.

Agile Vorgehen und Scrum

Thema vom Januar 2012

Scrum ist ein Framework für das Management komplexer Projekte und stellt heute eine der bekanntesten agilen Methoden dar. Durch seine einfache Struktur und klar definierten Rollen lassen sich die Scrum-Prinzipien schnell lernen, produktiv einsetzen und so die Vorteile von Agilität schnell ausnutzen.

Was versteht man unter Scrum?

Im Mittelpunkt von Scrum steht das selbstorganisierende Team. Um dem Team eine störungsfreie Arbeit zu ermöglichen, gibt es den ScrumMaster, der als Methodenfachmann dafür sorgt, dass der Entwicklungsprozess nicht zerbricht. Der ScrumMaster stellt auch die Schnittstelle zum Produktverantwortlichen rsp. dem Product-Owner dar, dem die Aufgabe zukommt, Anforderungen zu definieren, zu priorisieren und auch zu tauschen. In Scrum ist dabei klar geregelt, wann der Produktverantwortliche neue oder geänderte Anforderungen beauftragen darf - so gibt es ungestörte Entwicklungszyklen von 4 Wochen (einem sogenannten Sprint), in denen ihm untersagt ist, das Team zu "stören". Während eines Sprints wird deshalb der Product Owner seine Vorstellungen von der weiteren Entwicklung ins Product Backlog eintragen und so für kommende Sprints einplanen.

Welche Vorteile bietet Scrum?

Scrum ist einfach zu lernen und lässt sich rasch einsetzen. Somit kann Scrum häufig den ersten Schritt darstellen, um Entwicklungsprojekte agil zu machen. Darüber hinaus definiert Scrum klare Rollen und einen gut strukturierten, aber dennoch flexiblen Entwicklungsprozess. Bei aller Klarheit bleibt stets die Möglichkeit erhalten, Besonderheiten und Erfahrungen des eigenen Projektes zu berücksichtigen und sich so seinen individuellen Scrum-Prozess zu erarbeiten.

Herausforderung beim Coaching von verteilten Teams

Thema vom Oktober 2011

Bei agilen Methoden dreht es sich um Teams die zusammenarbeiten, um Software zu entwickeln. Als Scrum Master können wir Ihrem Team von den ersten Schritten mit agilen Methoden bis zum Ausschöpfen des ganzen agilen Potenzials helfen. Die Kunst des agilen Coachings von verteilten Teams besteht darin die Situation und die Werte, die der agilen Softwareentwicklung zugrunde liegen, zu verstehen sowie herauszubekommen, wie man die beiden miteinander kombinieren kann.

Beim Coaching geht es um das Arbeiten mit Menschen. Diese Menschen arbeiten an Projekten und in Teams und diese Teams befinden sich innerhalb einer Organisation. Jede Person, jedes Projekt, jedes Team und jede Organisation ist anders, so dass wir nicht exakt vorhersagen können, was Sie in Ihrer Situation tun sollten. Stattdessen geben wir allgemeine Ratschläge die Sie befolgen können, und Anregungen zu den verschiedenen Optionen, die Sie haben. Wir können Ihnen keine Formeln bieten die immer funktionieren, weil keine zwei Situationen gleich sind. Je nach Kontext geben wir einem Team den genau entgegengesetzten Ratschlag desjenigen, den wir einem anderen Team erteilt haben. Zum Beispiel würden wir normalerweise empfehlen, dass der Projektmanager am täglichen Standup teilnimmt, allerdings ist es auch schon vorgekommen, dass wir davon abgeraten haben.

Die atama Scrum Master und Coachs agieren aus Erfahrungen von unterschiedlichen Projekten und unterstützen Sie mit Tipps die Sie einsetzen können, wenn Ihr Vorhaben der von uns beschriebenen Situation ähnelt. Sie werden immer selbst entscheiden, ob Sie unseren Rat auf Ihr Team anwenden. Zeit und Erfahrung sind nötig, um ein effektiver agiler Coach zu werden. Wir helfen Ihnen und Ihren Teams Fallen im Projekt zu vermeiden und bieten Ihnen ein Vorgehen, um sich zu verbessern. Wir sind Ihr Lieferant für Inspirationen und Ideen.

Was macht ein agiler Coach in Ihrer Unternehmung?

Unser Ziel ist es, ein produktives agiles Team aufzubauen, das selbst denkt. Es reicht nicht, den Leuten zu zeigen, wie man agil ist. Oft müssen alte Angewohnheiten ablegt werden bevor man tatsächlich effektiv in einem agilen Team tätig werden kann. Unsere Coachs begleiten das Team bis sie ihren eigenen Weg gefunden haben. Beim Coaching verteilter Teams untersuchen wir die einzelnen Bereiche damit Sie die Dinge sehen, die man zu tun hat:

Beobachten: Augen und Ohren offen halten und beobachten wie das Team arbeitet. Wir denken über die zugrunde liegenden Ursachen nach.

Feedback: Das Team berichtet was wir beobachtet haben. Wir helfen dem Team das Feedback in seine Arbeitsweise einzubinden damit es die Probleme selbst erkennt.

Ausbilden: Wir suchen nach Möglichkeiten zum Lernen anzuregen. Wir veranschaulichen wie man agil ist, indem wir aus anderen Projekten erzählen und Trainingseinheiten durchführen.

Moderieren: Wir machen es leicht agil zu sein, indem wir den Weg für konstruktive Kommunikation und Zusammenarbeit ebnen.

Unterstützen: Wir sind da wenn das Team hängt und ermutigen es weiterzumachen und helfen ihm, aktiv zu bleiben.

Das sieht nach einer ganzen Menge aus, allerdings muss man diese Dinge nicht alle auf einmal tun. Unsere Scrum Master und Coachs gehen schrittweise vor und verursachen nicht gleich ein Chaos mit vielen Veränderungen. Sie werden feststellen, dass das Geheimnis des Erfolgs im Prinzip darin besteht, die richtige Einstellung zu entwickeln. Fragen Sie uns für ein Coaching an.

zurück zu Aktuelles