Scrum at BSI

BSI-Mitarbeiter tragen die Scrum-Philosophie ins Unternehmen: Pragmatismus, Selbstorganisation und Transparenz für Kunden, die ein agiles Vorgehen wünschen.

Rasch ändernde Marktbedingungen und komplexe Kundenbedürfnisse stellen hohe Anforderungen an die Softwareentwicklung. Einige Projekte sind so komplex, dass sie sich im Voraus weder in große abgeschlossene Phasen noch in einzelne Arbeitsschritte teilen lassen. Gewisse Kunden wünschen sich daher ein agiles Vorgehen bei der Entwicklung. BSI begegnet dieser Herausforderung mit Scrum.

Drei BSI-Mitarbeiter haben den Certified Scrum Master Course bei Peter Stevens und Andreas Schliep absolviert und tragen diese neue Entwickler-Philosophie ins Unternehmen hinein. BSI-Kunden können nun zwischen unterschiedlichen Vorgehensweisen bei der Softwareentwicklung wählen.

Doch was ist Scrum?

Scrum ist das derzeit weitverbreiteste Vorgehensmodell zur agilen Softwareentwicklung. Es ist ein team-basiertes Vorgehen, um komplexe Systeme und Produkte zu entwickeln. Scrum basiert auf dem folgenden «Agilen Manifest», das u.a. von Ken Schwaber und Jeff Sutherland mitformuliert wurden:

  1. Individuen und Interaktionen gelten mehr als Prozesse und Tools.
  2. Funktionierende Programme gelten mehr als ausführliche Spezifikation.
  3. Die stetige Zusammenarbeit mit dem Kunden steht über Verträgen.
  4. Der Mut und die Offenheit für Änderungen steht über dem Befolgen eines festgelegten Plans.

Oder wie die beiden Autoren es fordern: «Wir suchen nach besseren Wegen, Produkte zu entwickeln, indem wir es selbst praktizieren und anderen dabei helfen, dies zu tun.»

Das Vorgehen rückt Pragmatismus und Transparenz in den Vordergrund und setzt auf die Selbstorganisation und Eigenverantwortung in interdisziplinären Teams. Scrum ist beliebt, weil es bei sehr einfacher Methodik sehr komplexe Systeme zu bauen ermöglicht. Es eignet sich speziell für visionäre, komplexe Projekte mit vielen Anforderungen. Zu Beginn eines solchen Projektes steht eine klare Vision, was man erreichen will – die konkreten Anforderungen an das zu bauende Produkt sind aber meist noch vage. Für genau solche Situationen bietet Scrum optimal Hand. Die Vorteile für den Kunden sind offensichtlich:

-        Sicherheit, dass das Wichtigste und Dringlichste als erstes umgesetzt wird

-        schnelle Einführungszeit

-        enorme Transparenz während der Produktentwicklung

-        Flexibilität, man gibt kein Geld aus für Funktionalität, die nicht gebraucht wird

-        Hindernisse werden rasch eskaliert und pro-aktiv beseitigt

-        starke Einbindung und Mitbestimmung des Kunden in den Prozess

 

Inkrementelles Vorgehen

Das inkrementelle Vorgehen besteht im Wesentlichen aus drei Rollen, drei Meetings, vier einfachen Grundsätzen und vier Artefaken, die es einem Team ermöglichen mit grösstmöglicher Effizienz zu arbeiten.

Stakeholder können jederzeit neue Anforderungen in Form von User Stories in das so genannte Product Backlog einbringen. Das Team – verantwortlich für die Umsetzung – schätzt den Aufwand der Stories in so genannten Story Points. Das Product Backlog steht unter der unter der Hoheit des Product Owners. Dieser priorisiert die Einträge gemäss dem wirtschaftlichen Mehrwert der einzelnen User Stories.

Im Sprint Planning Meeting vereinbaren Product Owner und Team welche der Stories im nächsten Sprint umgesetzt werden. Ein Sprint dauert zwischen 2 und 4 Wochen. Das Team verpflichtet sich dazu das vereinbarte Ziel zu erreichen. Die Auswahl der Stories nennt man Sprint Backlog.

Danach geht das Team an die Arbeit und setzt bis zum Ende des Sprints die im Sprint Backlog enthaltenen Stories um. Täglich trifft sich das Team zum Daily Scrum, um sich über den Stand der Arbeit auszutauschen und eventuelle Hindernisse publik zu machen.

Aufgaben werden nicht verteilt, jedes Team-Mitglied nimmt sich selbstständig dem, am nächst wichtigen, noch nicht erledigten Task an. Dadurch wird das Wissen auf das ganze Team verteilt und die Selbstorganisation gefördert. Unterstützt wird das Team vom Scrum Master; er hilft dem Team die Scrum-Regeln einzuhalten und vor allem die auftauchenden Hindernisse zu beseitigen.

Zur Visualisierung des Backlogs und der Tasks wird das Task Board und zur Visualisierung des Fortschrittes das Burndown Chart verwendet.

Am Ende eines Sprints wird fertige, getestete Software ausgeliefert und im Sprint Review Meeting präsentiert. Feedback kann hier von jedem Stakeholder abgegeben werden und fliesst in das Product Backlog ein.

Das Team trifft sich danach zur Retrospektive und bespricht, was gut und was schlecht funktioniert hat und wie man der Prozess weiter verbessert werden kann.

 

Interessiert? Morten Pedersen freut sich auf Ihre Fragen.

 

Links

Das Agile Manifest: http://agilemanifesto.org/

Scrum Alliance: http://www.scrumalliance.org/

Datum
Kategorie