WTF ist Scrum?

 

Einleitung

Scrum! Agile! Time to market! Seit neuestem werden einem diese Begriffe ins Gesicht gedrückt, wenn man über Softwareentwicklung spricht. Wie mein damaliger Software Engineering Dozent immer gesagt hat: „Wir sind Scrum! Wir sind agil! Wir programmieren in Sprints! Wir haben oft Releases! Und wir haben Spass dabei!“

Scrum also, hm?

Das Ziel von Scrum ist es, den höchsten Value für das Business in kürzester Zeit zu bringen. Alle Anforderungen werden als Einträge im „Product Backlog“ gesammelt. In regelmässigen Meetings bespricht das Team dann, welche der Anforderungen in den nächsten Sprint einfliessen sollen – und somit in das „Sprint Backlog“ überführt weden. Ein „Sprint“ dauert dann zwischen zwei bis vier Wochen und hat das Ziel, dass man am Ende dieser Ziet ein vorzeigbares Ergebnis hat. „Sprint“ ist dabei nicht wörtlich gemeint: Es soll nicht blindlings losgerannt und Code umgesetzt werden.

Am Ende eines Sprints wurde hoffentlich das Ziel erfüllt und ein Mehrwert im Projekt geschaffen.

wtfistscrum

Die Regeln von Scrum

1. Sprints sollen möglichst kurz sein und es erlauben, neue Software in einem Bereich von zwei bis vier Wochen zu liefern. Alle zwei Wochen wird dabei entschieden, ob man ein Feature veröffentlichen kann oder es in den nächsten Sprint kommt.

2. Das Business setzt die Prioritäten und das Entwicklerteam organisiert sich selber, um auf möglichst intelligente Weise die am höchsten Priorisierten Anforderungen umzusetzen.

3. Anstatt dass das ganze Team die ganze Zeit zusammen an einer Aufgabe arbeitet, macht ein Scrum Team die ganze Zeit viele kleine Dinge (Bezogen auf Requirements, Design, Code, Testing).

4. Wenn das Team lossprintet, darf es während eines Sprints nicht gestört werden. Dazu gehören alle möglichen Einflüsse von aussen („Kannst Du nicht schnell…“, „Ich brauche nur kurz…“). Auch sollten die Tasks innerhalb eines Sprints während eines Sprints nicht geändert werden. Ein Sprint sollte sauber beendet und der folgende Sprint sauber neu aufgeplant werden.

5. Ein Scrum Team besteht typischerweise aus 5-9 Personen.

6. Das Ziel ist es, Leute mit unterschiedlichen Erfahrungen in das Team zu bringen ( = Cross functional). Dazu gehören alle Arbeitsgruppen wie Programmierer, Tester, Designer etc.

Zeremonien in Scrum

1. Sprint Planning
– Analysiere und evaluiere das „Product Backlog“
– Das Team wählt das Ziel des nächsten Sprints -> „Sprint Goal“. Dies geschieht anhand der Erfahrungen mit den bisherigen User Stories und der Story Poitns, die das Team während eines Sprints umsetzen kann.

2. Sprint Review
– Dies geschieht am Ende des Sprints
– Es wird angeschaut, was während des aktuellen Sprints erreicht wurde.
– Relativ informell: Dauert nicht länger als zwei Stunden und braucht keine Powerpoint-Präsentation

3. Sprint Retroperspektive
– In diesem Meeting soll festgestellt werden, was funktioniert und was nicht.
– Es geht typischerweise 15-30 Minuten und wird nach jedem Sprint durchgeführt
– Wenn etwas funktioniert, soll man mehr davon machen, funktioniert es nicht, macht man davon weniger.
– Das ganze Team soll an diesem Meeting teilnehmen.

4. Daily Scrum Meeting
– Kurzes, tägliches Meeting. So kurz, dass man dabei stehen kann.
– Jeder Mitarbeiter erzählt: „Was habe ich gestern gemacht? Was werde ich heute machen? Mit welchen Problemen kämpfe ich momentan?“

Die Rollen in Scrum

1. Product Owner
– Definiert die Features des Produkts.
– Entscheided über Release Date und Inhalt.
– Ist verantwortlich für die Profitabilität des Produkts (ROI).

2. Scrum Master
– Stellt sicher, dass die Scrum Werte und Vorgehen korrekt angewendet wird.
– Schafft Hindernisse aus dem Weg und schützt das Team vor externen Einflüssen.
– Stellt die Kooperation zwischen allen Rollen sicher (Team – Business – Andere Schnittstellen etc.).
– Arbeitet mit dem Product Owner zusammen. Moderiert das Team (Daily Scrum Meeting).

3. Team
– Arbeitet in den Sprints

Fazit

Ich persönlich bin immer noch ein wenig skeptisch, wenn Personen von Scrum wie von einem heiligen Gral der Softwareenwticklung schwärmen. Besonders in einer grossen Firma bin ich noch nicht überzeugt, dass all diese Elemente ineinandergreifen. In einer kleinen bis mittleren Bsude – dort kann ich es mir durchaus vorstellen. Ich schulde es mir persönlich aber noch, in einer kleinen Firma mit „fully agile“ Vorgehen zu arbeiten.

Project noise level – Der Lärm der Anarchie

Der Project noise level ist ein Modell aus der Scrum-Welt – Erstellt von Ralph Stace in „Strategic Management and Organizational Dynamics“. Darin geht es um die Handhabung vorhandener oder zu verwendender Technologie in Verbindung den jeweiligen Anforderungen an ein Projekt.

Die vier „Project noise level“ Stufen

Man stellt also Technologie den Anforderungen gegenüber. Dabei gibt es vier Stufen:

projectnoiselevel

1. Ist die zu verwendende Technologie relativ sicher und hat man ein Einverständnis zu den Anforderungen, ist alles sehr simpel.

2. Sind Technologie und die Anforderungen weniger sicher, ist es eher Kompliziert.

3. Ist die Technologie eher ungewiss und die Anforderungen noch unklar, ist es ein komplexes Projekt.

4. Hat man überhaupt keinen Plan, ist es pure Anarchie.

Welche Stufe ist zu priorisieren?

Im optimalsten Fall kann der Kunde genau sagen, was er will. Ist dann die Technologie noch bekannt, die für die Umsetzung verwendet werden soll, sind die Randbedingungen schon gegeben und der Weg für die Lösung ist schon gelegt. Diese Projekte können aber schnell in die Sparte „langweilig“ abrutschen, wenn die Projektmitarbeiter zuwenig gefordert werden.

Ziel sonst ist daher, in die Bereiche Kompliziert oder Komplex zu kommen. Bei einem komplizierten Projekt ist das agile Ziel wahrscheinlicher, dass man bereits nach zwei Wochen funktionierenden Code hat. Bei einer gewissen Komplexität sind gegebenfalls noch Workshops mit Spezialisten nötig, um diese Komplexität aufzulösen.

Bei der Anarchie ist jegliche Hoffnung verloren und Sie tun sich den besten Gefallen, wenn Sie sich möglichst schnell vom Projekt entfernen 😉

Was ist „Process Control Theory“ und welche zwei Ausprägungen gibt es?

Bei Process Control Theory handelt es sich um zwei Ansätze, um Prozesse zu kontrollieren und verwaltbar zu machen.

Die zwei Ausprägungen dabei sind folgende:

1. Definiert – Simple Prozesse mit unauffälligem „Noise“, wiederholbar

2. Empirisch – Komplexe, laute („noisy“) Prozesse, nicht wiederholbar

Fazit

Gedanken über den Project noise level oder die Process Control Theory können helfen, das Ausmass eines Projektes einzuschätzen und sich Gedanken darüber zu machen, wie man besonders am Anfang des Projektes vorgehen sollte.

Das Decorator Pattern ist wirklich praktisch!

Mit dem Decorator Entwurfsmuster kann man auf einfache Art eine bestehende Klasse um eine Funktionalität erweitern, ohne diese Klasse verändern zu müssen. Und was ganz cool ist: Man kann auch Decorators von Decorators von Decorators machen, um beliebig viele Zusatzfunktionen ineinander zu verschachteln. Decorateception! (Ob das dann noch übersichtlich ist, ist eine Frage für einen weiteren Blogeintrag).

Das Decorator Pattern zeigte mir auch wieder einmal die Flexibilität, die hinter Interfaces steckt.

Das Grossbuchstaben-Problem

Ich habe eine Applikation, die von einer Klasse Mitarbeiter den Namen holt. Das Doofe ist jetzt aber, dass der erste Buchstabe immer klein geschrieben ist, ich benötige ihn aber gross geschrieben. Und was noch doofer ist: Es ist mir technisch unmöglich, diese Klasse nachträglich zu ändern.

Was kann ich also machen?

decoratorpatterngliffy-problem

Klick mich für das Bild in gross

Die Lösung visualisiert

Die Lösung ist einfach: Ich packe eine neue Klasse MitarbeiterDecorator um die Klasse Mitarbeiter. Und was beinhaltet diese Klasse? Sie implementiert dasselbe Interface Person wie Mitarbeiter. Konkret bedeutet dies, dass die Decoratorklasse diesselben Methoden wie Mitarbeiter implementieren muss. Der Clou dabei ist nun, dass ich im Decorator einen Mitarbeiter erstelle, und in jeder Methode vom Decorator jeweils die gleiche Methode von Mitarbeiter aufrufe.

getName() vom MitarbeiterDecorator ruft also getName() vom Mitarbeiter auf.

Und nun kann ich entweder vor oder nach diesem Methodenaufruf beliebige Funktionen einfügen, um den Namen zu verändern. In diesem Fall füge ich nach dem Holen vom Namen im MitarbeiterDecorator noch eine Logik ein, die sicherstellt, dass der erste Buchstabe gross geschrieben ist.

decoratorpatterngliffy-loesung

Klick mich für das Bild in gross

Lösung in einem Codebeispiel

Die wichtigen Codestücke für dieses Beispiel sind folgende:

1. Der aufrufenden Applikation gebe ich statt einem Mitarbeiter einen MitarbeiterDecorator zurück – in den ich den Mitarbeiter gleich reinsetze, um dessen Methoden aufrufen zu können.

Aus

return mitarbeiter;

wird

return new MitarbeiterDecorator(mitarbeiter);

Die neue Klasse MitarbeiterDecorator sieht dann folgendermassen aus:

public class MitarbeiterDecorator implements Person {

private Mitarbeiter mitarbeiter;

public MitarbeiterDecorator(Mitarbeiter mitarbeiter){
    this.mitarbeiter = mitarbeiter;
}

public String getName(){

    // rufe die Methode der Mitarbeiterklasse auf
    String name = mitarbeiter.getName();

    // Stelle hier sicher, dass der erste Buchstabe gross ist
    name = Character.toUpperCase(name.charAt(0)) 
    + name.substring(1, name.length());

    return name;
}
}

Warum sind hier Interfaces so cool?

Im Codebeispiel sieht man, warum hier Interfaces eine geniale Erfindung sind: Die Aufruferapplikation programmiert (gemäss genereller programmierempfehlungen) gegen das Interface Person. Ich kann nun einfach statt des Mitarbeiters den MitarbeiterDecorator zurückgeben – Da beide Klassen „Personen“ sind, stört das die Aufruferapplikation nicht.

Fazit

Ich hoffe, das Beispiel hat die Genialität des Decorator Pattern darlegen können. Ich möchte hier noch ergänzend sagen, dass man das Pattern auch mit einer abstrakten Klasse statt einem Interface machen kann.