Schneider Scrumster

Praxis der agilen Softwareentwicklung
4. Auflage 2017
ISBN: 978-3-7450-7685-1
Verlag: epubli
Format: EPUB
Kopierschutz: 6 - ePub Watermark

E-Book, Deutsch, 116 Seiten

Wenn Sie sich schon einmal gefragt haben, ob das eigentlich normal ist, dass bei Ihnen im Scrum Team so gut wie jede User Story über mehrere Sprints bearbeitet werden muss, dann sind Sie hier genau richtig. Hier finden Sie sich und Ihr Team vielleicht sogar in einem der Praxisbeispiele wieder. Das soll Ihnen die Augen dafür öffnen zu erkennen, was schiefläuft. Selbsterkenntnis ist bekanntlich der erste Schritt zur Besserung. Die Umsetzung von 'lean and agile' in die Praxis ist nicht trivial. Es warten viele Fallstricke und Sackgassen auf uns. Im Gegensatz zu Startups, die agile Methoden ohne Vorbehalte und ohne Vorgeschichte mit großem Erfolg einfach nutzen können, hat eine traditionsreiche Firma die Herausforderung ihre bestehenden Methoden und Prozesse auf 'agil' umzustellen. Dies hat großen Einfluss darauf, wie agil und erfolgreich man sein kann. Untersuchungen und Thesen darüber, wann und warum auch agile Methoden scheitern können, sind rar.

Achim Schneider hat über 30 Jahre praktische Erfahrung in der Softwareentwicklung. Er hat kommerzielle Vorhaben in unterschiedlichen Branchen und in unterschiedlichsten Rollen geleitet, verantwortet oder begleitet. Er ist zertifizierter Professional Scrum Master® nach scrum.org, zertifizierter Professional Scrum Product Owner® nach scrum.org, zertifizierter SAFe® Agilist (SA) nach dem Scaled Agile Framework® und Senior Project Manager. Seine praktischen Erfahrungen in Bezug auf die Anwendung von lean & agil sind Grundlage für dieses Buch.

Autoren/Hrsg.

Schneider, Achim

Leseproben

Platz 10 - Working Software
Funk­tio­nie­ren­de Soft­wa­re ist schon im agi­len Ma­ni­fest pro­kla­miert und eine Grund­vor­aus­set­zung agi­ler Me­tho­den, um er­mit­teln zu kön­nen oder bes­ser ge­sagt, um mes­sen zu kön­nen, was man schon er­reicht hat. Bewährtes in neuem Look
Ganz neu ist die­se Er­kennt­nis al­ler­dings nicht. Ins klas­si­sche Pro­jekt­ma­na­ge­ment über­tra­gen han­delt es sich hier­bei um „ear­ned va­lues“ oder auf Deutsch den „Fer­tigs­tel­lungs­grad“, ein Werk­zeug des Pro­jekt­con­trol­lings, um den Pro­jekt­fort­schritt zu ver­fol­gen. Eine Be­wer­tung des Pro­jekt­fort­schritts er­folgt in agi­len Me­tho­den wie Scrum am Ende je­des Sprints. Die agi­le Grun­d­an­nah­me
Je­der Sprint stellt eine In­ve­s­ti­ti­on dar und ver­folgt das Ziel, dem er­hoff­ten Er­geb­nis einen Schritt näher zu kom­men. Ab­bil­dung 5 Die agi­le Grun­d­an­nah­me Nach je­dem Sprint soll in agi­len Vor­ge­hens­mo­del­len über­prüft wer­den, was tat­säch­lich er­reicht wur­de. Das so ent­stan­de­ne agi­le Ar­te­fakt ist „wor­king soft­wa­re“. Un­sicht­bar und nur in der un­be­wuss­ten Wahr­neh­mung der Be­tei­lig­ten be­fin­det sich die agi­le Grun­d­an­nah­me. Es wird grund­sätz­lich da­von aus­ge­gan­gen, dass In­ve­s­ti­tio­nen, die „funk­tio­nie­ren­de Soft­wa­re“ als Er­geb­nis ha­ben, dau­er­haft er­hal­ten blei­ben, weil Soft­wa­re, die ein­mal funk­tio­niert, kei­nem „Ver­schleiß“ un­ter­liegt. Ein­mal von der War­tung die­ser Soft­wa­re ab­ge­se­hen, ist das die agi­le Grun­d­an­nah­me. Trifft das eigentlich zu?
Ob die­se Grun­d­an­nah­me tat­säch­lich zu­trifft, hängt nun im We­sent­li­chen von Ih­rem Um­feld ab, in dem Sie sich be­we­gen. Ein Sprint wird in al­ler Re­gel zu­nächst in ei­ner Ent­wick­lungs­um­ge­bung entste­hen. Ob in die­ser Um­ge­bung auch die Be­wer­tung hin­sicht­lich „wor­king soft­wa­re“ an­ge­s­tellt wird oder nicht, bes­timmt maß­geb­lich, ob schon alle nöti­gen In­ve­s­ti­tio­nen ge­tätigt sind oder nicht. Tipps zu Wor­king Soft­wa­re
Prü­fen Sie, wel­che un­aus­ge­spro­che­nen An­nah­men in Ih­rem Um­feld exis­tie­ren und fin­den Sie einen trans­pa­ren­ten Um­gang da­mit. Legen Sie es doch fest
Der Be­griff „wor­king soft­wa­re“ muss also für Ihre Ver­hält­nis­se de­fi­niert wer­den, da­mit je­dem klar ist, was er be­deu­tet und was eben nicht. Ein Bei­spiel hier­für könn­te sein: Wor­king soft­wa­re be­deu­tet für uns, dass das Pro­dukt in der Ent­wick­lungs­um­ge­bung in­stal­liert und be­nutz­bar ist. Will man das noch deut­li­cher for­mu­lie­ren, kann man auch be­schrei­ben, was nicht un­ter „wor­king soft­wa­re“ zu verste­hen ist: Wor­king soft­wa­re hat bei uns die Ei­gen­schaf­ten, dass die­se noch nicht auf ei­ner „Sta­ging-Um­ge­bung“ (Test-, In­te­gra­ti­ons-, Re­fe­renz- oder Pro­duk­ti­vum­ge­bung) be­reit­ge­s­tellt wur­de, noch nicht an den späte­ren Be­trei­ber über­ge­ben wur­de und noch nicht mit ei­nem Bes­tell- und Ab­rech­nungs­pro­zess ver­se­hen ist und da­mit noch kei­nen kom­mer­zi­el­len Bei­trag zum Ge­schäft­s­er­geb­nis lie­fern kann. Weitere „working“ Aspekte
Ab­hän­gig von Ih­rem Um­feld tref­fen hier wei­te­re oder an­de­re Aspek­te zu. So­fern kei­ne kla­re und von al­len Be­tei­lig­ten ver­stan­de­ne und ak­zep­tier­te De­fi­ni­ti­on von „wor­king soft­wa­re“ vor­han­den ist, be­we­gen Sie sich auf höchst ris­kan­tem Bo­den. Tipps zu Wor­king Soft­wa­re
De­fi­nie­ren Sie „wor­king soft­wa­re“. Ho­len Sie in Ih­rem Um­feld die Ak­zep­tanz zur De­fi­ni­ti­on von „wor­king soft­wa­re“ ein und er­gän­zen Sie da­mit Ihre De­fi­ni­ti­on of Done. Stim­men Sie zu­sätz­li­che Back­log-Ein­trä­ge für „wor­king soft­wa­re“ aus Ent­wick­lungs­sicht mit dem Pro­duct Ow­ner ab. Extreme Programming
Der Be­griff „wor­king soft­wa­re“ wur­de durch die agi­le Me­tho­de des Ex­tre­me Pro­gram­ming ge­prägt. Dort be­deu­tet er, dass eine Soft­wa­re voll in­te­griert, ge­tes­tet, zum Kun­den aus­ge­lie­fert oder in der Pro­duk­ti­ons­um­ge­bung in­stal­liert wer­den kann. Ab­bil­dung 6 Ex­tre­me Pro­gram­ming Das be­deu­tet aber nicht, dass die­se Soft­wa­re feh­ler­frei läuft und frei von Ab­stür­zen ist. Es be­deu­tet nur, dass Unit Tests ge­macht und grund­le­gen­de Qua­li­täts­si­che­rung be­trie­ben wur­den und man sich da­von über­zeugt hat, dass sie grund­sätz­lich läuft. Ob die­se „ex­tre­me“ Fest­le­gung eine für Ihre Ver­hält­nis­se adäqua­te De­fi­ni­ti­on von „wor­king soft­wa­re“ ist, müs­sen Sie für sich prü­fen. Mogeln ist verlockend
Vie­le Scrum Teams ma­chen zu­sätz­lich den Feh­ler, bei der Be­wer­tung ih­res Sprin­t­er­geb­nis­ses zu mo­geln. Bei­spiels­wei­se wird halb­fer­ti­ge Soft­wa­re, die z.B. mit tech­ni­schen Schul­den („tech­ni­cal debt“) be­las­tet ist, als „wor­king soft­wa­re“ de­kla­riert, ohne dass eine User Sto­ry zur Be­sei­ti­gung der tech­ni­schen Schuld mit dem Pro­duct Ow­ner ver­ein­bart und in den Pro­duct Back­log ein­ge­s­tellt wird. Das ist dann so, als hät­te das Team die tech­ni­sche Schuld un­ter den Tep­pich ge­kehrt. Ab­bil­dung 7 Tech­ni­cal debt Das führt dazu, dass das Ma­na­ge­ment an­nimmt, dass et­was ab­ge­schlos­sen ist und kei­ne späte­ren In­ve­s­ti­tio­nen mehr be­nötigt, was real be­trach­tet nicht stimmt. Transparenz gewinnt
Die Grün­de da­für, dass die Soft­wa­re am Ende ei­nes Sprints nicht wirk­lich fer­tig ist, sind viel­schich­tig, aber letzt­lich doch un­er­heb­lich. Ent­schei­dend für alle Be­tei­lig­ten ist, dass das Scrum Team am Ende je­des Sprints scho­nungs­los trans­pa­rent macht, was funk­tio­niert und was nicht. Schön­re­den ist zwar ver­lockend, aber nicht die Lö­sung. Das holt einen später wie­der ein. Tipps zu Wor­king Soft­wa­re
Sor­gen Sie für Trans­pa­renz bei der Be­reits­tel­lung von wor­king soft­wa­re. Typisch „working“
Auf dem Bild „Wor­king Soft­wa­re“ ist eine ty­pi­sche, als „wor­king“ de­kla­rier­te Soft­wa­re ab­ge­bil­det. Die­se wird von al­len Sei­ten ge­stützt, ist zu­sam­men­ge­flickt, weist Lücken oder Löcher wie ein Schwei­zer Käse auf und passt an den Schnitts­tel­len kaum zu­sam­men. Wird dies nicht trans­pa­rent ge­macht, so löst dies eine Ket­ten­re­ak­ti­on aus. Push oder Pull
Wie kommt es ei­gent­lich in agil ar­bei­ten­den Teams dazu, dass et­was fer­tig wird? Der we­sent­li­che Un­ter­schied zur gän­gi­gen Ar­beits­wei­se ist, dass Ar­beit nicht „zu­ge­wie­sen“ wird (Push-Prin­zip). Es gibt nie­man­den, der den Team­mit­glie­dern eine Auf­ga­be zu­teilt. Viel­mehr ho­len sich die Team­mit­glie­der die Auf­ga­ben aus dem Back­log, so­bald sie da­für Ka­pa­zi­täten zur Ver­fü­gung ha­ben (Pull-Prin­zip). Wann eine Auf­ga­be zur Be­ar­bei­tung aus­ge­wählt wird, hängt da­mit vom in­di­vi­du­el­len Fort­schritt der Team­mit­glie­der und vom Fort­schritt des gan­zen Teams ab. Ab­bil­dung 8 Push- oder Pull-Prin­zip Unfertiges vermeiden
Aus der tra­di­tio­nel­len Fer­ti­gungs­in­dus­trie wis­sen wir, dass un­fer­ti­ge Pro­duk­te ge­bun­de­nes Ka­pi­tal dars­tel­len. Da­her ist je­des Fer­ti­gungs­un­ter­neh­men be­strebt, den Be­stand an nicht fer­tig­ge­s­tell­ten Er­zeug­nis­sen mög­lichst ge­ring zu hal­ten. Ein an­de­res Bei­spiel wäre: Es soll eine Brücke über einen Fluss ge­baut wer­den. Un­ge­fähr zur Hälf­te der Bau­zeit be­schließt das Team, mit dem Bau ei­ner zwei­ten Brücke zu be­gin­nen. Das führt dazu, dass der Bau an der ers­ten Brücke lang­sa­mer vor­an­geht und an der zwei­ten Brücke nicht mit vol­ler Kraft ge­baut wer­den kann. Die in die Brücken in­ve­s­tier­te Ar­beit kann nicht dazu ge­nutzt wer­den, den Fluss zu über­que­ren. Sie kön­nen sich vors­tel­len, was pas­siert, wenn Sie den Bau ei­ner drit­ten Brücke par­al­lel be­gin­nen. Über­tra­gen auf die agi­le Soft­wa­re­ent­wick­lung be­deu­tet dies, dass eine an­ge­fan­ge­ne Auf­ga­be Ka­pi­tal bin­det. So­lan­ge die Auf­ga­be nicht fer­tig­ge­s­tellt wur­de, kann die in die Auf­ga­be in­ve­s­tier­te Ar­beit in kei­nen Nut­zen um­ge­wan­delt wer­den. Der Nut­zen hat hier na­tür­lich zwei Aspek­te. Zum einen ist der Nut­zen ge­meint, den po­ten­ti­el­le Kun­den aus dem fer­tig­ge­s­tell­ten Pro­dukt er­zie­len kön­nen, und zum an­de­ren ist na­tür­lich der po­ten­ti­el­le Ge­winn ge­meint, der mit der Ver­mark­tung des fer­tigs­tell­ten Pro­dukts er­zielt wer­den kann. Da­her sind un­fer­ti­ge Tasks so­zu­sa­gen...