Agile Software Development mit Bugtracker, Subversion, CI und Unit-Tests (Sebastian Rieschel)

Jan: Dies ist der erste Gastbeitrag in meinem Blog. Er ist geschrieben von Sebastian Rieschel, einem Mitgründer von smava. smava ist ein Marktplatz für Kredite von Mensch zu Mensch. Ich freue mich sehr, dass Sebastian die Zeit gefunden hat für diesen Blog zu schreiben, weil er viel Ahnung von Projektleitung und Software-Entwicklung hat und mich sehr gerne mit ihm austausche.

Sebastian: Wie auch schon Jan in seinem ersten Post klargestellt hat, möchte ich mich als Gastautor auch gleich mal von einem eventuellen allgemeingültigen, wenn nicht sogar wissenschaftlichen Anspruch freisprechen. Wie auch Jan bin ich einfach tagtäglich mit der Entwicklung von Software in einem Startup beschäftigt, und möchte hier vorstellen, was wir bei uns bei smava als sinnvoll und zweckmäßig definiert haben.

Planung
Den Anfang in unserem Software Planungs- und Entwicklungsprozess macht eine möglichst umfassende und idealerweise auch schon in Teilaufgaben zerlegte Feature-Definition, die in unseren Bugtracker eingestellt wird. In diesem kann man praktischerweise zu jedem Feature Teilaufgaben festhalten, und diese auch unterschiedlichen Leuten zuweisen.

Ich als Planer stelle dann einen Release-Plan auf, in dem ich grob festlege, welche Key-Features zu welchem Zeitpunkt ausgerollt werden sollen. Diesen Plan kann ich mithilfe von sog. „Versions“ und einem Bündel an sog. “Issues” (Features oder Bugs) pro Version, die ich diesen zuordne, im Bugtracker abbilden. Zu Beginn der Produktion einer Version wird sich dann im Team zusammengesetzt, alles nochmal durchgesprochen und Aufwände plausibilisiert und dann gehts los.

Produktion
Ein Entwickler weist sich selbst ein Issue zu, protokolliert den Arbeitsaufwand und den Fortschritt im Bugtracker. So ist auch eine Überprüfung der Soll- und Ist-Aufwände möglich. Sämtliche Code-Änderungen werden in unser Code Versioning System Subversion unter Bezugnahme auf den Bugtracker-Eintrag im Commit Kommentar vorgenommen, was es möglich macht im Bugtracker unter dem Feature sämtliche hierfür notwendigen Änderung am Code wieder einzusehen.

Das funktioniert bei uns super mit einem kleinen Entwicklerteam, da das Caching der Information auch sehr zeitnah erfolgt. In größeren Setups solls damit aber auch schon mal Performance Probleme geben. Ein Entwickler, der den letzten Commit zu einem Feature gemacht hat, setzt im Bugtracker den Workflow-Schritt des Features auf “erledigt”.
Nach dem Commit springt unser Continuous Integration Server Cruisecontrol an, der Subversion alle 5 Minuten auf neue Commits checkt. Gibt es etwas neues, so wird sofort der Codestand compiliert, die Unit Testsuite läuft einmal drüber. Waren sowohl build als auch Tests erfolgreich, so bekommen alle eine “Build successful” E-Mail und eine Zip-Datei liegt zum Deploy auf die internen Test-Systeme bereit. Geht irgendwas schief (der Compiler oder ein Unit Test), erhalten alle ein “Build failed!”, was super für den sozialen Druck ist, der Schuldige ist in der Regel durch lauthalses “Er wars! Er wars” Schreien innerhalb von Sekunden gefunden.

Testing
Der compilierte Build wird dann auf ein Internes Testsystem deployed und dann “von Hand” durchgetestet.
Zunächst finden gezielte Tests der Features statt, um die Umsetzung zu prüfen und ggf. Feedback an die Entwickler zu geben. Dieser Test erfolgt anhand aller “erledigter” Bugtracker-Features, die dann entweder “geschlossen” werden (d.h. erfolgreich umgesetzt und getestet) oder eben “erneut geöffnet” mit einem Kommentar zurück an den Entwickler.
Gegen Ende der Produktion kommt ein Testprotokoll hinzu, anhand dessen die gesamte Applikation getestet wird. Das Protokoll ist einfach ein Excel-Sheet, das pro Release auf die Testerfordernisse angepasst wird, und alle Prozesse Schritt für Schritt enthält, die ein User ausführen kann.

Ein Mitarbeiter absolviert alle Testfälle (jaa, das dauert eine ganze Weile), und muss die erfolgreiche Absolvierung abzeichnen und unterschreiben. Erst wenn sowohl alle Features geschlossen sind, als auch das Protokoll absolviert, gilt die Produktion als abgenommen.

Fazit
Auf diese Art wird ein Arbeitsablauf erreicht, der wunderbar asynchron und deshalb weitesgehend effizient ist. Allenfalls kurz vor live deploys kann die Schleife aus Test > Nachbesserung > Retest usw. etwas bremsen, da in dieser Zeit i.d.R. nicht schon mit Features des nächsten Releases begonnen werden kann, da diese sonst mit compiliert werden würden. Auch dieses Problem könnte man durch geschicktes Branching umschiffen, dafür sind wir jedoch meist zu faul beschäftigt. Nach einem Live-Release wird ein sogenannter “Branch” in Subversion angelegt, der die Version des Code-Standes zum Deploy Zeitpunkt festschreibt und damit jeden deploy reproduzierbar macht.
Mit diesem Setup laufen wir jetzt schon seit einiger Zeit recht komfortabel. Im Moment sind wir dabei weitere Tools zur Messung der Abdeckung des Codes durch unit Tests und einiger weiterer Key Performance Indicators einzuführen, so z.b. das Verhältnis aus auf Bugs verwendete Zeit zu Features pro Produktion. Denn wie in anderen Bereichen auch wollen wir uns in der Software-Entwicklung stetig verbessern, was zumindest aus meiner Sicht die Grundvoraussetzung für den Erfolg ist.

Links
Subversion http://subversion.tigris.org/
Continuous Integration http://cruisecontrol.sourceforge.net/

This entry was posted on Mittwoch, November 7th, 2007 at 4:57 pm and is filed under Gastbeiträge, Managing Teams. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.