BWL 4 Startups

Wissenswertes für Unternehmer

Was man von professionellen Softwareentwicklern erwarten kann - Teil 2

Es folgt der zweite Teil von Uncle Bobs Demanding Professionalism in Software Development mit 8 weiteren Forderungen. An Ende des Beitrags befinden sich Anmerkungen, wie sich einige der Thesen umgesetzen liesen.

They cover for each other

Die Absicht ist, dass wenn John von einem Bus überfahren wird oder längere Zeit ausfällt, sein Team ohne Unterbrechung weiterarbeiten kann. Dazu müssen sich natürlich die anderen an Johns Baustellen auskennen.

“Jeder kann auf der Position des anderen Spielers spielen.”

Regelmäßige Code Reviews bieten Entwicklern die Möglichkeit, sich auszutauschen und mit fremden Quellcode auseinanderzusetzen.

QA will find nothing

Der Entwicklungszyklus läuft in vielen Softwareunternehmen folgendermaßen ab: Nach Fertigstellung eines Milestones wird die Software an die QA-Abteilung gereicht. Dort wird die Anwendung auf die Anforderungen überprüft und eine Fehlerliste, oft auch ein ganzer Fehlerkatalog, zurück an die Entwicklungsabteilung gegeben.

Ein solches Vorgehen ist ineffizient. Einerseits ist zum Zeitpunkt der Fehlerbeseitigung die Anwendungsentwicklung fortgeschritten, was die Korrektur von Designentscheidungen erschwert. Andererseits muss der Entwickler zwischen Baustellen wechseln. Letztes ist ebenfalls nicht trivial, da er sich so gleich zwei Mal in den Code einarbeiten muss, einmal beim Beheben des Bugs und dann erneut beim Wechsel in die aktuelle Entwicklungsphase. Daher lautet das Ziel:

“We expect QA to find nothing.” – Die gesamte QA-Abteilung muss um Ihre Anstellung fürchten.

Die Umsetzung kann anhand von Acceptance-Tests geschehen, mit deren Hilfe zum Zeitpunkt der Implementierung überprüft werden kann, ob die Anwendung das tut, was von ihr erwartet wird. So lässt sich die Funktionalität bereits zum Entwicklungszeitpunkt sicherstellen und Fehler frühzeitig abfangen.

Extreme quality

Ein etwas schwammiger Appell. Es geht darum, dass jeder Mitarbeiter am Ende des Tages mit einem guten Gefühl nach Hause geht:

“God, I did a good job today.”

Man möchte nicht, dass er sich mit einem schlechten Gewissen plagt: “Das könnte uns später auf die Füße fallen.” und in absehbarer Zeit Schwierigkeiten bereitet. Der Code sollte so flexibel und sauber wie möglich sein. “Bad code slows you down.” Außerdem sollten entstandene Probleme systemisch gelöst werden, was ein erneutes Auftreten verhindert. Eine Forderung, die meiner Meinung nach für alle Bereiche eines Unternehmens gilt.

Honest estimates

Fragt man einen Schriftsteller, wie lange er für das Schreiben des nächsten Kapitels benötigt, lautet eine ehrliche Antwort “Ich habe keine Ahnung”. Ähnlich verhält es sich bei der Softwareentwicklung. Dennoch benötigt man für die Planung eine Aufwandsschätzung. Eine schlechte Antwort wäre: 3 Wochen. Besser: Die Umsetzung könnte 1 Woche, sie könnte 10 Wochen, wahrscheinlich wird sie 3 Wochen betragen. Relevant sind das Intervall und die Form der Kurve. Es ist die Aufgabe es Entwicklers, diese Zeitabschätzung zu geben.

They say no

Die schlechteste Antwort von Entwicklern auf die Frage “Könnt Ihr das Features X bis zum Termin Y umsetzen?” lautet “Wir werden es versuchen.”. Eine wünschenswerte Antwort ist “Ja”. Ein Ja ist gut, solange es realistisch und glaubhaft ist. “Ich werde es versuchen.” ist destruktiv, da sie keine Festlegung beinhaltet und psychologisch die Tür zur Prokrastination eröffnet. Die Entwicklung wird aufgeschoben, halbherzig begonnen und nicht zu Ende geführt.

Daher lautet bei unrealistischen und unsicheren Planungszielen die richtige Antwort “Nein”. Der Manager kann das Feature in einen anderen Milestone verschieben und der Programmierer von der mentalen Todo-Liste streichen. Ein Entwickler sollte sich nicht zu einer Antwort des Managers hinreißen lassen. Es ist seine Aufgabe dies zu entscheiden, da er am Ende mit der Umsetzung beauftragt wird und nicht der Manager, Chef oder Kunde.

Automation

Es mag überflüssig erscheinen, einem Programmierer, dem Patron der Automatisierung, zu erklären, dass repetitive Tätigkeiten ineffizient sind. Dennoch findet man bei vielen Entwicklerteams einen hohen Anteil an manuellen Einsatz beim Compilieren, Deployen und Testen von Software. Wiederkehrende Aufgaben, wie eben das Aufsetzen eines Testsystems, Ausführen eines Buildscripts müssen mit einem Knopfdruck erledigt sein. Dazu wurden Computer erfunden!

Continous aggressive learning

Stetiges und aggressives Lernen unterscheidet einen professionellen Softwareentwickler von einem mittelmäßigen “Ich habe das schon immer so gemacht”-Entwickler. Im Buch The Mystical Man-Month wird ein Unterschied bei der Produktivität vom Faktor 10 berichtet, der einen Guten von einem schlechten Programmierer unterscheidet.

Beschäftigt werden sollte sich mit neuen Sprachen, Libraries und Methoden. Der effiziente Weg dazu ist Lesen: Bücher, Blogs und Quellcode.

Mentoring

“If you want to learn something, read about it. If you want to understand something, write about it. If you want to master something, teach it.” — Yogi Bhajan

Das Zitat bringt es auf den Punkt. Als Lehrer ist man gezwungen sich mit der Materie tiefer auseinanderzusetzen als Anwender. Oft genügt es, etwas nur anzuwenden, das Motorrad zu fahren oder die Funktionen aufzurufen. Jemand der unterrichtet, muss hingegen technische Details, Abläufe und die Funktionsweise begreifen, um diese plausibel zu erklären. Vorträge, Screencasts und Pair Programming sind Formen des Unterrichts.

Anmerkung

Viele von Uncle Bobs Forderungen zielen auf TDD ab. Der typische TDD Zyklus lautet: Test –> Entwicklung –> Refactoring. Ist jede Zeile Code die geschrieben wurde durch einen Test abgedeckt, muss sich ein Entwickler keine Sorgen darum machen, ob er bei Änderungen etwas zerstört. Er bekommt sofort Feedback. Bei TDD entstehen fast von selbst Klassen und Methoden, die einfach zu testen sind und dementsprechend viele Abstraktionsschichten beinhalten. Diese wiederum begünstigen den Umbau der Software bei Änderungen von Anforderungen seitens des Auftraggebers. Im Idealfall benötigt das Hinzufügen neuer Features in eine bestehende Anwendung genauso viel Zeit, wie würde man sie in eine neue, frische Anwendung implementieren.