May
07
2009

SAPERION benutzt Scrum als Hilfsmittel beim Entwickeln von ECM-Produkten im Rahmen agiler Softwareentwicklung

Wir nutzen im Rahmen der Software -und Produktentwicklung (u.a. für die JCR-Implementierung)  das agile Entwicklungsmodell Scrum.

Scrum ist ein iterativer und inkrementeller Prozess für die Produktentwicklung und die Organisation von Teams. Dadurch werden die anfallenden Aufgaben schneller und mit höherer Qualität erfüllt. Dies gelingt durch eine hohe Eigenmotivation, denn mit Scrum legt das Team selbst fest, welche Aufgaben auf welche Art und Weise erledigt werden. Alle auftretenden Kundenanforderungen werden mit Hilfe des Scrum-Frameworks iterativ priorisiert und schnell realisiert. So weit die Theorie.

Und das klappt tatsächlich. Natürlich gab es die üblichen Schwierigkeiten bei der Umstellung. Sich täglich zu treffen und über das zu reden, was man gerade arbeitet, ist nicht jedermanns Sache.  Doch nach der Einführungsphase sind alle Beteiligen von der Methode überzeugt. Es ist natürlich einiges an Disziplin im täglichen Doing und ein gewisser Zeitaufwand für die allmorgentlichen Meetings erforderlich. Doch das Ergebnis überzeugt. Doch zurück zur Theorie:

Welche Rolle übernimmt eigentlich die Qualitätssicherung im Scrum Prozess?

Schema von Scrum. Quelle von http://www.controlchaos.com/

Schema von Scrum. Quelle von http://www.controlchaos.com/

Bei iterativ-inkrementeller Entwicklung werden Anforderungen, Entwurf, Entwicklung und Test in einer Reihe kürzerer Entwicklungszyklen durchlaufen. Das wachsende System kann auf verschiedenen Stufen als Teil der Entwicklung getestet werden.

Bei diesen Testabläufen ist nicht nur die QA gefragt, sondern auch der Entwickler mit seinen Unit Testverfahren.

Laut Scrum sind ja alle Beteiligten für die Qualität des Produktes verantwortlich. Aber eine Verlagerung dieser Verantwortung auf einen Tester hat neben der Verteilung des Aufwandes einen klaren Vorteil: eine unabhängige Sichtweise von geschulten, professionellen Testexperten.

Die Qualitätssicherung im Sinne von Scrum ist demnach keine abgegrenzte Abteilung mehr, sondern immer ein Teil vom Entwicklungszyklus.

Das schöne für uns in der Qualitätssicherung ist dabei, dass wir wesentlich enger mit der Entwicklung zusammenarbeiten. Wir wissen worum es bei den einzelnen Tasks geht und sind auch wesentlich näher an den Kundenanforderungen. Es hört sich zwar etwas kitschig an: Aber wir arbeiten jetzt als ein Team an den Anforderungen unserer Kunden.

In jedem Entwicklungslebenszyklus findet man einige Charakteristika für gutes Testen:

  • Zu jeder Entwicklungsaktivität gibt es eine zugehörige Aktivität im Testen.
  • Jede Teststufe hat Testziele, die spezifisch für diese Stufe sind.
  • Die Analyse und der Entwurf der Tests für eine Teststufe sollten während der zugehörigen Entwicklungsaktivität beginnen.
  • Die Tester sollten im Reviewprozess der Entwicklungsdokumente (Anforderungen, Analyse und Design) eingebunden werden, sobald eine Vorabversion eines der Dokumente verfügbar ist.

Auf Kommunikation zwischen den am Prozess teilhabenden Teams wird sehr viel Wert gelegt. Im DailyMeeting mit der Entwicklung werden Fehler oder Fehlverhalten positiv kommuniziert. Denn dadurch können Schwierigkeiten bzw. Kommunikationsprobleme zwischen Testern und Entwicklern, Analysten und Designern vermieden werden. Dies gilt für die Reviewphase,als auch für die Test-Phase.

Werden Fehler während der Testphase gefunden\analysiert und behoben, so spart dies Zeit und Geld zu einem späteren Zeitpunkt (in der Produktion) und verringert das Risiko.

Insgesamt kann ich zusammenfassend sagen, dass wir mit Scrum die Softwarequalität tatsächlich steigern konnten und wesentlich näher an den Kundenanforderungen sind. Durch die Einbeziehung von Kunden und Partner in die Tests konnten wir zudem auch die gefühlte Zufriedenheit bei eben diesen Kunden und Partnern deutlich erhöhen.

Ergänzung vom 14.01.2011:

Wir konnten nun die Früchte unseres Muts zur Einführung von SCRUM ernten. Unsere Kunden haben uns von Platz 7 auf Platz 2 in der Kundenzufriedenheit auf dem deutschen ECM-Markt gehievt:

SAPERION überzeugt im ECM-Kundenmonitor von Pentadoc

Post to Twitter Post to Delicious Post to Digg Post to Facebook Post to MySpace

Download PDF

10 Comments »

  • Hallo Herr Zorn,

    schöne, kompakte Beschreibung von SCRUM. Mir persönlich gefällt an diesem Entwicklungsmodell vor allem die tägliche, knackig kurze Kommunikation. Gerade da gibt es leider oft Probleme in Projekten. Es wird zwar viel geschrieben und gesprochen, aber oftmals nicht wirklich miteinander kommuniziert.

    Ich bin überzeugt, das Sie auf diesem Weg die Qualität deutlich steigern können.

    Viele Grüße aus Chemnitz

    Uwe Naumann

    Comment | 8 May 2009
  • Als ehemaliger Entwickler von SAPERION kann ich das nur bekräftigen, was Stefan geschrieben hat. Ich glaube SCRUM ist das Beste, was den Entwicklungsteams je passiert ist. (nach Entwicklung von Java :)) Es minimiert das typische (Entwickler-)Problem: “Ich bin fast fertig.” Denn durch die Entwicklungssprints ist das Zieldatum nicht mehr “irgendwann in einem Jahr” sondern spätestens nach 4 Wochen.

    Man sollte sich trotzdem bewußt sein, dass SCRUM nur ein Hilfmittel zum Zweck ist. Gerade wenn es um Themen geht, welche man überhaupt nicht kennt, ist eine Abschätzung als Entwickler sehr schwer. Oft hilft einem dort auch nicht die Gliederung in atomare Stories. In diesem Fall sollte man in Absprache mit Product Management eine Research-Task für die Story erstellen. Im nächsten Sprint hat man dann oft die benötigten Erfahrungen, um eine grobe Abschätzung tätigen zu können.

    Viele Grüße,
    Daniel

    P.S: Ohne Werbung machen zu wollen, aber das die beste Qualität die wir jemals hatten. Danke an QA&DEV! Unser Demosystem rennt nur so :)

    Comment | 18 May 2009
  • Nach fast 2 Jahren können wir feststellen, dass nicht nur am Ende eines Sprints eine potentiell auslieferbare Version zur Verfügung steht, sondern das tägliche Build so gut ist, dass diese als frühes Beta in unseren eigenen Teams genutzt wird, um Präsentationen vorzubereiten. Ich kann mich an Zeiten erinnern, in denen das Presales Team gerne ist auf des Service Pack 1 gewartet hat, um das zugegeben sehr komplexe Demo-System zu updaten.
    Welche Vorteile mit SCRUM auch bei anderen Firmen erzielt wird, zeigt dieser sehr aktuelle Artikel von der Allianz:
    http://www.sigs-datacom.de/fileadmin/user_upload/zeitschriften/os/2009/01/hastreiter_roberts_OS_01_09.pdf

    Comment | 21 February 2010
  • Dr. Martin Bartonitz

    Hier gibt ews noch ein sehr schönes Beispiel für die selbstoragnisierenden SCRUM-Teams, wo ein Manager 40 Mitarbeitern den Freiräume gibt, die gesteckten Ziele immer besser zu erreichen:
    http://www.microtool.de/blog/post/Was-sind-eigentlich-selbstorganisierende-Teams.aspx

    Comment | 15 July 2010
  • Dr. Martin Bartonitz

    “SCRUM ist von einem sozial ausgewogenen Team abhängig. Dominante Einzelcharaktere stören das selbstorganisierende Team und wirken negativ auf die Produktivität.”
    Zu lesen in der Enzyklopädie für Wirtschaftsinformatik im Oldenburger Wissenschaftsverlag im Artikel “agile Vorgehensmodelle:
    http://www.enzyklopaedie-der-wirtschaftsinformatik.de/wi-enzyklopaedie/lexikon/is-management/Systementwicklung/Vorgehensmodell/Agile-Vorgehensmodelle

    Comment | 15 July 2010
  • Daniel Manzke

    Eine weitere Case-Study, welche zeigt, das SCRUM nicht nur in Firmen funktioniert, wo es nur ein Entwicklungsteam gibt, findet man hier: http://bit.ly/a69tgp
    Hier schreibt der CTO von ImmobilienScout24 über die Erfahrungen aus der Einführung und der Weiterentwicklung zu “SCRUM 2.0″.

    Comment | 10 August 2010
  • Dr. Martin Bartonitz

    Das Ende der Superstars ist eingeleutet, so meint SOA-Experte Frank Joecks in seinem Kommentar auf dem Portal des BPM-SOA Center:
    http://www.bpm-soa-center.com/index.php?option=com_content&view=article&id=68:superstars&catid=6:publikationen&Itemid=8

    Comment | 19 August 2010
  • [...] nicht aus den Augen verloren werden. Ein besonders gut funktionierendes Beispiel ist die agile SCRUM Methodik, wie sie anfangs in Entwicklungsteams eingeführt wurde, aber inzwischen in beliebigen anderen [...]

    Pingback | 28 December 2010
  • Dr. Martin Bartonitz

    Interview mit dem SCRUM-Miterfinder Ken Schwaber in der CIO:
    Denken und Arbeit völlig anders
    Warum Scrum-Einführungen scheitern

    Comment | 12 January 2011
  • [...] möglich sein. Daher werden sich agile Methoden des gemeinsamen Arbeitens, wie sie sich mit SCRUM in der Software-Entwicklung inzwischen etabliert haben, auch in allen anderen kreativen Bereichen [...]

    Pingback | 5 April 2012

RSS feed for comments on this post. TrackBack URL

Leave a comment


+ six = 14

Theme: TheBuckmaker.com Web Templates | Bankwechsel Umschuldung, Iplexx IT Solutions