Eine Frage, die in Projekten immer wieder auftaucht. Warum? Weil beispielsweise das Management möchte, dass schneller entwickelt wird. Die Basis-Architektur der Software nicht mehr zeitgemäß ist oder die Dokumentation fehlt…

Ken Schwaber macht immer wieder deutlich, dass die Software-Entwickler für die Qualität des Codes verantwortlich sind. In seinen Büchern, sowie auch in einer älteren Präsentation Canary in a Coal Mine, versucht er ein Bewußtsein dafür zu schaffen. Ziel ist es, Verständnis und Professionalität zu steigern, um schlechtem Code und aufwendige Wartungsarbeiten vorzubeugen. Solides Handwerk und Nachhaltigkeit, sieht er als die Schlüssel zum Erfolg. Wie schon berichtet, kommt die Entwicklung des Software Craftsmanship dieser Forderung nach. Der Titel, der kürzlich auf InfoQ erschienenden Präsentation From good to great Developer, unterstreicht nochmals die Aktualität des Themas.

Auf der anderen Seite spielt die Definition of Done eine wesentliche Rolle, um den Anspruch an gutem Code gerecht zu werden. Done definiert, was ein Projektteam damit meint, wenn es sich auf die Fertigstellung einer Story verpflichtet. Die Definition sollte entsprechende – mit dem Team verabschiedete und abgestimmte – Richtlinien enthalten, die festhalten wann Fertig auch wirklich fertig ist. Kelly Walters hat hierfür eine 10 Punkte Liste aufgestellt:

• Code produced (all ‘to do’ items in code completed)
• Code commented, checked in and run against current version in source control
• Peer reviewed (or produced with pair programming) and meeting development standards
• Builds without errors
• Unit tests written and passing
• Deployed to system test environment and passed system tests
• Passed UAT (User Acceptance Testing) and signed off as meeting requirements
• Any build/deployment/configuration changes implemented/documented/communicated
• Relevant documentation/diagrams produced and/or updated
• Remaining hours for task set to zero and task closed

Diese Liste der “Done-Kritierien” kann auch 30, 60 oder 90 Punkte enthalten.

Es wird deutlich: Disziplin und die Einhaltung von Abläufen stehen zur Lösung des Problems im Vordergrund… Story für Story.

Über den Autor

Momentan als Projektmanager und Agiler Coach in Hamburg tätig, unterstütze ich Scrum und Kanban Teams bei der Bewältigung ihrer alltäglichen Herausforderungen. Zudem bin ich mit dem Coaching von Mitarbeitern betraut und laufend bestrebt, in den Austausch mit Anwendern agiler Methoden zu treten.