Zwei Jahre zurück. Ein Tag im Projekt „KN FreightNet“. Wir entwickeln die neue Ecommerce-Plattform - das „Schaufenster von Kühne + Nagel“. Man ist stolz ein Teil dieses Projekts zu sein, dem agilen Flaggschiff im Konzern. Aber schauen wir uns das mal genauer an. Wir haben ein agiles Team in dem:
- jede Woche Stories diskutiert werden, damit sie jeder „versteht“ und „estimaten“ kann
- einige Stories ziemlich lange in einzelnen Spalten am Board verweilen
- in der Retro die Probleme mit der Kaffeemaschine oder der viel zu lauten Tür zum Flur diskutiert werden
- selbverständlich automatisierte Tests geschrieben werden (… wenn der Code fertig ist)
- TDD und Pair Programming „da wo es sinnvoll ist“ zum Einsatz kommen
…
Obwohl vieles schon ein Fortschritt im Vergleich zu früheren Wasserfallprojekten war, kommt einem manches noch nicht so recht optimal vor. Wobei genau hilft uns nun die Story Estimation? Warum machen wir eigentlich kein Test Driven Development mehr obwohl wir sogar wissen, dass es in der Anfangszeit mal gut funktioniert hat? Derartige Fragen tauchten von Zeit zu Zeit immer wieder auf. Jedoch verharrte man in den etablierten Verhaltensmustern. Sie funktionierten ja auch… irgendwie.
Doch wie sieht es heute aus? Wir haben mittlerweile tatsächlich einiges geändert. Heute sehen wir uns als „agileres Team“ in dem:
- alle wirklich gemeinsam zur selben Zeit am gleichen Feature arbeiten
- Standups und Stories im Grunde zunehmend überflüssig werden
- jedes neue Feature mit der Frage nach einem Akzeptanztest und jeder Test mit dem Formulieren der Assertion beginnt
- Know-How Austausch und kontinuierliche Verbesserung der Arbeitsweise automatisch stattfindet
…
…ach ja und am Wichtigsten: wir haben einfach mehr Spaß an der Arbeit und können uns kaum noch vorstellen wie vor zwei Jahren zu arbeiten. Obwohl wir uns im Konzernumfeld bewegen haben wir nun eine Evolutionsstufe erreicht die uns erlaubt die Werte und Prinzipien der Agilität gemeinsam zu (er)leben statt einfach nur einem agilen Prozessmodell zu folgen.
okay Story und Scenarios (Testfälle) haben wir, was dann?
Implementierung „Glue Code“
Serenity BDD mit JBehave
neben Integration anderer BDD Frameworks vor allem mit portspezifischen Testframeworks wie Selenium oder RestAssured
Strukturierungshilfe mit Steps
integriertes Reporting
„Spring“ der Testframeworks
funktioniert bisher sehr gut
Verweis: Historie an Testframeworks
Fixen des fehlschlagender Akzeptanztests (langer loop)
Beginn TDD Cycle mit erstem Unit Test:
früher unterschiedlichstes Herangehen:
Sturkturkommentare //Given-//When-//Then
dann Builder, Mocks etc.
am Ende auch eine Assertion
„ich hab den Code doch schon im Kopf“
Problem: kein Cycle, kein Flow, wie schützt man sich nicht zuviel zu machen?
Lösung: zu allererst die Assertion schreiben
erfordert ein Umdenken bei einigen und fühlt sich sperrig an
aber dafür macht man nicht „zu viel“ auf einmal
kontinuierliches Refactoring notwendig
erstmal code schreiben um den Test zu fixen obwohl man weiss das man ihn gleich refaktorisiert erfordert Umdenken in den Köpfen
Design
Design hat sich wirklich geändert
während TDD Code Duplikation zuzulassen erfordert Umdenken
mit Abstraktion erst beginnen wenn sich tatsächlich sichtbare Muster im Code bilden statt YAGNI
Code spezifischer und i.d.R. besser verständlich als generischer Code
aber Entscheidung für Code Transformationen anfangs häufig Quelle für (Grundsatz-)Diskussionen
timer (story dazu)
baby steps ( story dazu )
value stream map
Flavors / GuideLines (Code of Conduct)
die liebe IDE; jeder hat seinen eigenen rechner (erzwingt häufige commits)
selbstläufer
mathias
scatterplott
