Clean Code Developer

Das Buch “Clean Code” kennen vielleicht einige Programmierer schon. Seit längerem gibt es auch die passende Initiative dazu.

Die Clean Code Developer setzen sich mit dem Schreiben von gutem Code auseinander. Reflektieren ihr tägliches Handeln und stellen Liebgewordenes gern mal infrage. Persönlich habe ich Martins Buch schon vor einigen Jahren gelesen und bin 2009 auf die Initiative gestoßen und das Infragestellen ist mir auch nicht fremd. Hinzu kommt, dass jeder Scrum Master auch ein Wanderprediger ist (Hallo Falk!) und als solcher natürlich sein Evangelium verbreiten möchte. Also? In unserer Firma moderiere ich derzeit einen sechsteiligen Workshop zu diesem Thema. Die ersten Folien findet man in der Dropbox

Clean Code Developer – Roter Grad

Scrum und Continuous Integration

Nachdem mir ein Bekannter (Hallo Alex!) mitgeteilt hat, dass mein Blog schon auf Platz 5 der Suchergebnisse von “Scrum Continuous Integration” steht, möchte die dürftigen Infos die man bisher finden konnte noch etwas erweitern.

Scrum hat als Grundprinzip, dass man ständig lieferfähig ist. In der Regel liefert man die Ergebnisse des letzten Sprints aus. Ggf. muss oder möchte man noch einen gesonderten Test-Sprint machen in dem superkomplizierte nicht-automatisierbare Integrationstests durchgeführt werden. Letzteres ist insbesondere bei der SW-Entwicklung für Geräte interessant.
Bei mir/uns haben sich Jenkins und buildbot als CI Server gut gemacht. Jenkins gefällt mir besser, da er leichter zu erweitern ist und es schon ganz viele Plugins gibt (für git, Sonar, ClearCase uvm.). Nach jedem git push läuft Jenkins los und macht einen clean build. Den Installer kann man sich (wenn man weitere Tests durchführen möchte) vom Server holen und loslegen. Nach dem Build werden die Metriken (Unittest, Code Coverage, PDM, FindBugs) in Sonar eingepflegt. Dort erkennt man dann auch Schwachpunkte und hat vor allem einen Verlauf über die Zeit.

Scrum benötigt IMHO CI, da sonst weder schnell noch effizient ein Liefergegenstand vorliegt und zeitnahes Feedback fehlt.

Git branching best practices

Was ist ein gutes Vorgehensmodel beim Entwickeln mit git. Wir arbeiten in mehreren Projekten mit git. Features oder auch Bugfixes werden in eigenen Branches entwickelt und dann zurück integriert (merge). Beim Integrieren bietet es sich an, die

--no-ff

Option zu wählen und auf das fast-forward zu verzichten. Continue reading

Scrum “lernen”

Nachdem ich im letzten Jahr ein Projekt als ScrumMaster begleitet habe, möchte ich heute ein paar lesenswerte Bücher und Internetseiten vorstellen. Vor ein paar Jahre las ich das Buch Scrum: Produkte zuverlässig und schnell entwickeln (Amazon Link zur neuesten Auflage) von Boris Gloger. Nachdem das Projekt im letzte Jahr abgeschlossen war, habe ich dann auch mal einen Kurs bei Boris besucht. Ich muss sagen: es war super. Boris Gloger ist seit 2004 Scrum Trainer und hat schon einiges gesehen; das merkt man auch an seinem Training. Es ist abwechslungsreich, mit vielen Anekdoten aus dem echten Leben gespickt und man wird aktiv eingebunden. Höhepunkt war das Scrum Cooking am Abend des ersten Trainingstages. Hier konnten wir als Team das soeben gelernte umsetzen und gemeinsam drei Gänge kochen. Nach einer kurzen Nacht ging es dann am Folgetag weiter. So interessant ein Training auch ist, man muss Scrum in der Praxis anwenden können und dürfen um Scrum auch leben zu können. Hier hilft also nur: become agile – do Scrum! Im Übrigen benötigt man für Scrum keine elektronischen Helferlein. Eine Stellwand oder ein Whiteboard reichen völlig. Dazu PostIts und Stifte – fertig ist das Toolset ;) Wer ganz neu anfängt und sich allein fühlt sollte sich einen Trainer suchen oder einen Scrum Stammtisch besuchen. Für letzteres helfen sicher google oder auch xing.

Scrum allein ist natürlich nur die halbe Miete. Es nützt nichts, wenn im Team kein (Selbst)Verständnis für einen ordentlichen Entwicklungsprozess vorhanden ist. Mit ordentlich meine ich soetwas wie Test-Driven Development, sinnvolle Testumgebungen und Testauswahl (siehe auch xUnit Test Patterns: Refactoring Test Code), Continuous Integration (siehe Projekte automatisieren), das Beheben von Fehlern VOR der Implementierung neuer Funktionen … Diese Liste lässt sich noch fortführen, aber Details dazu gibt es ein anderes Mal.

Wer neu ist bei Scrum oder sich mal schnell einlesen möchte:

Wer Lesenswertes kennt, darf dies gern in einem Kommentar verlinken ;)