Auf der Suche nach dem Qualitäter Stefan Roock stefan.roock@it-agile.de Twitter: StefanRoock Danke für den Titelvorschlag an Arne Roock In diesem Vortrag geht es um die interne Systemqualität. Als Beispiel wird agiles Vorgehen verwendet. Die Aussagen sind aber unabhängig vom konkret gewählten Vorgehen gültig.
Kennen Sie das? public float runde(float wert) { // irgendjemand müsste hier mal aufräumen wert = wert * 100; float d = wert - (int) wert; if (d == 0.0f) { return wert / 100; } else if (d > 0) { return (wert - d) / 100; } else if (d < 0) { return (wert + d) / 100; } return 0; // kann eigentlich nicht passieren } Das ist Java-Code - der verwendete Font hat zu den Großbuchstaben geführt. Lesen Sie den Code ein paar Minuten. Was tut der Code? Funktioniert er? Gibt es solchen oder so ähnlichen Code bei Ihnen?
Und das? Das ist der Red-Green-Refactor-Zyklus der testgetriebenen Entwicklung (TDD: Test Driven Development). Kennen Sie TDD? Wenden Sie TDD an? Literatur: Test Driven Development by Example von Kent Beck
Und das? S.O.L.I.D. Während TDD ein Ansatz zum Vorgehen ist, beschreibt S.O.L.I.D. Entwurfsprinzipien für Code. Wer kennt S.O.L.I.D.? Wer wendet S.O.L.I.D. an? S: Single Responsibility Principle - Jede Entwurfseinheit (z.b. Klasse) hat genau eine Verantwortlichkeit und damit nur einen Grund, sich zu ändern. O: Open-Closed-Principle - Entwurfseinheiten sind offen für Änderungen und gleichzeitig geschlossen/stabil gegenüber ihren Klienten. L: Liskov Substitution Principle - Objekte eines Subtyps müssen überall dort einsetzbar sein, wo der Supertyp erwartet wird. Subtypen müssen ausreichend verhaltensähnlich zu ihren Supertypen sein. I: Interface Segregation Principle - Interfaces werden nach Verwendungszusammenhängen definiert und nicht aus Sicht der Implementation. Zu einer KundeDAO-Klasse sollte es also kein IKundeDAO-Interface geben. Stattdessen sollte es z.b. IKundensuche geben. Die Interfaces werden aus Sicht der Klienten definiert. D: Dependency Inversion Principle - High-Level-Konzepte dürfen nicht von Low-Level- Implementationen abhängen. Low-Level-Implementationen ändern sich sehr häufig und diese Änderungen ziehen häufig Änderungen an den High-Level-Konzepten nach sich. Außerdem sind die High-Level-Konzepte dann schwerer wiederverwendbar. Stattdessen soll man die Abhängigkeiten umdrehen - die Low-Level-Implementationen sollen von den High-Level- Konzepten abhängen. Das kann man in Java z.b. über Interfaces machen. Wichtig ist dann, dass die Interfaces zu den High-Level-Konzepten gehören und nicht zu den Low-Level- Implementationen. Hört sich trivial an? Ist es aber nicht. Die klassische 3-Schichten- Architektur verletzt z.b. das Dependency-Inversion-Principle: Die Fachlogik (High-Level) hängt von der Datenhaltung (Low-Level) ab.
Hilft es? Wenn Sie TDD und S.O.L.I.D. anwenden: Hilft es oder kommt der am Anfang gezeigte Code auch bei Ihnen vor?
Kurz vor Sprintende ToDo Doing Done Ich habe hier mal ein Sprint-Burndown für die ersten 7 Tage eines 2-wöchigen Sprints mitgebracht. Die Balken stellen den Restaufwand je Tag dar, die grüne Linie die sogenannte Ideallinie. Man sieht hier, dass es sehr unwahrscheinlich ist, dass das Sprintziel noch erreicht werden kann.
Gerade noch geschafft ToDo Doing Done Hier hat es das Team aber doch noch geschafft. Gerade rechtzeitig zum Sprintende wurde noch das ganze Sprint-Backlog abgearbeitet. Wie konnte das noch klappen? Möglicherweise hat das Team Überstunden geschoben. Wahrscheinlicher ist, dass es Qualität geopfert hat.
Durch das Opfern der Qualität ist eine Lücke entstanden zwischen dem, was das Team tatsächlich schaffen konnte (obere blaue Linie) und dem, was es vorgibt, geschafft zu haben (untere grüne Linie).
Technische Schuld Diese Lücke nennt man technische Schuld. Das Team hat technische Schulden gemacht, um vorgeben zu können, dass es das Sprintziel erreicht hat.
Velocity: Velocity: z.b. 20 z.b. 15 Storypoints Storypoints Das Aufnehmen technischer Schulden belastet das Team gleich dreifach für die Zukunft: 1. Der niedrig-qualitative Code behindert bei der weiteren Entwicklung und macht das Team langsamer. 2. Es wird immer mehr Code auf Basis des niedrig-qualitativen Codes gebaut, so dass das Aufräumen immer teurer wird. 3. Das Sprint-Burndown und die Velocity in Story-Points gaukelt eine unrealistisch hohe Produktivität vor und lädt dazu ein, im nächsten Sprint wieder zuviel einzuplanen.
Mit einem Wort: Katastrophe Mit einem Wort: Eine Katastrophe Technische Schuld verbrennt Geld in einer kaum vorstellbaren Geschwindigkeit.
Dann lasst uns das mal visualisieren. ToDo Doing Done ToDo Doing Done Wir sind fertig. Eigentlich müsste man mal... Und jetzt? Stellen wir uns die Situation zum Sprintende im Daily-Scrum vor. Das Team meldet wir sind fertig. Wenn man genau zuhört, hört man häufig noch Sätze mit eigentlich : In der Kundenklasse sieht es noch etwas unschön aus. Dort müsste man eigentlich mal aufräumen. Diese Sätze sagen deutlich aus, dass der Sprint doch nicht fertig ist. Für die Eigentlich-Sätze müsste man eigentlich Tasks erstellen und in die Spalte ToDo ans Taskboard hängen. Müsste man eigentlich... Dann tut es doch. Der ScrumMaster muss diese Eigentlich-Sätze identifizieren und dafür sorgen, dass sie in Tasks transformiert werden. Dann ist die tatsächliche Situation visualisiert und transparent: Das Team ist gar nicht fertig. Es hängen noch Tasks unter ToDo. Im Sprint-Review muss man sagen, dass man nicht fertig ist. Das ist erstmal unangenehm, eröffnet aber die Chance, den nächsten Sprint besser zu planen. Wer glaubt, dass so ein Vorgehen bei ihm im Hause durchsetzbar ist? Ja? Dann macht es doch bitte!
Culture Eats Strategy for Breakfast Das Ausspruch Culture eats strategy for breakfast wird meist Peter Drucker zugeschrieben. Demnach nützen alle strategischen Anstrengungen nichts, solange sie nicht mit der Unternehmenskultur harmonieren. So verhält es sich auch mit vielen Qualitätsoffensiven in Softwareunternehmen. Alle lobenswerten strategischen Programme zur Qualitätsverbesserung werden von der Unternehmenskultur aufgefressen. Es muss also ein Kulturwandel geschafft werden. Der unangenehme Teil dieser Erkenntnis ist, dass man mehr Qualität nicht einfach von oben verordnen kann und dass so ein Kulturwandel in der Regel mehrere Jahre dauert. Das angenehme Teil der Erkenntnis ist, dass man mit dem Kulturwandel auch von unten beginnen kann.
Berufsehre Aus meiner Sicht ist ein essenziell wichtiger Schritt auf diesem Weg, so etwas wie Berufsehre für Softwareentwickler zu etablieren. Wir sind stolz auf unseren Code.
Manifesto for Software Craftsmanship Not only working software, but also well-crafted software Not only responding to change, but also steadily adding value Not only individuals and interactions, but also a community of professionals Not only customer collaboration, but also productive partnerships That is, in pursuit of the items on the left we have found the items on the right to be indispensable. http://manifesto.softwarecraftsmanship.org Dafür gibt es sogar ein eigenes Manifest. Kennen Sie dieses Manifest? Nur 19 Hamburger haben es bisher unterzeichnet. Haben Sie es unterzeichnet? Wenn Sie mehr Qualität wollen, unterzeichnen Sie das Manifest!
Clean Code Ebenfalls im Craftsmanship-Bereich anzusiedeln ist Clean Code. Das Buch von Robert Martin ist aus meiner Sicht auch für sehr erfahrene Entwickler absolut lesenswert. Darüber hinaus gibt es die Möglichkeit, über das grüne Clean-Code-Armband seine Craftsmanship-Überzeugung auch sichtbar zu machen. Zeigen Sie mit dem Armband, dass Sie für sauberen Code eintreten. Das Unterschreiben von Manifesten und das Tragen grüner Armbänder finden Sie albern? Bedenken Sie bitte: Symbole und Artefakte sind wesentliche identifizierende Elemente von Kulturen. Wenn Sie einen Kulturwandel hin zu Berufsehre und Craftsmanship wünschen, können sie diesen tatsächlich durch das Unterschreiben des Manifests und durch das Tragen des Armband beschleunigen!
ADAPT creating Awareness increasing Desire developing Ability Promoting successes Transferring the implications of X to the rest of the organization
Weinbergs Strategie Weinberg beschreibt eine historische Begebenheit, von der nicht ganz sicher ist, dass sie sich so zugetragen hat. Demnach hat die USA im Rahmen zunehmender Industrialisierung eine zunehmende Umweltverschmutzung, insbesondere der Flüsse festgestellt. Es wurde ein Gremien eingerichtet, das sich um dieses Problem kümmern sollte. Es sprach mit unter anderem mit Henry Ford, was er empfehlen würde. Der Geschichte nach hat Ford eine ganz einfache Regelung empfohlen: Jeder darf soviel Wasser entnehmen, wie er möchte und damit tun, was er will. Es muss lediglich die gleiche Menge Wasser flussaufwärts wieder einleiten. Ein Regelungskreis oder wie man heute sagen würde: eine Feedbackschleife. Dieses Prinzip lässt sich auch vielfältig auf Qualitätsaspekte in der Softwareentwicklung anwenden.
Feedbackschleifen? 1.Wartungsteams 2.Team je Projekt 3.Fluktuationen im Team 4....
CSD: Certified Scrum Developer 2 Tage Grundlagen (z.b. CSM) 3 Tage CSD 13.-15.10.2010 in Hamburg 22.-24.11.2010 in Hamburg Mitte Dezember in Hamburg Die Scrum-Alliance hat neben den Kursen zum Certified Scrum Master und zum Certified Scrum Product Owner seit kurzem ein Zertifizierungsprogramm für Scrum Entwickler (CSD: Certified Scrum Developer). Die ersten Kurse dieses Zertifierungsprogramms laufen jetzt an. In Hamburg wird es Kurse im Oktober, November und Dezember geben. Nähere Informationen bekommen Sie bei it-agile: info@it-agile.de
Danke für die Aufmerksamkeit