Lohnt es sich, im Sprint-Planning Stunden für Tasks zu schätzen?
Die Frage diskutiere ich immer wieder mit Teams, denn in der Regel ist es eines der ersten Dinge, die ich Teams abgewöhne. Der Verzicht auf die Schätzung von Stunden für einzelne Tasks im Planning führt eigentlich immer zu einem besseren weil fokussiertem Planning.
Warum man die Stundenschätzung nicht unbedingt benötigt und warum das Planning dadurch häufig besser wird, will ich im Folgenden erklären.
Weiterlesen
Diese Woche habe ich mich mit einem Kunden über den Nutzen von Burndown Charts zum Messen des Fortschritts eines Sprints unterhalten. Die Diskussion war sehr interessant, daher möchte ich die Essenz daraus in diesem Artikel teilen.
Ausgangspunkt war dass in einem Scrum-Projekt gemessen werden sollte, ob das Sprint-Ziel in Gefahr ist. Die altbekannte These “Was ich nicht messen kann, kann ich auch nicht managen” war dabei die Leitidee. Diese Leitidee teile ich im Prinzip. Einen Burndown Chart während eines Sprints halte ich aber nicht für hilfreich, insbesondere nicht, um eine Gefährdung des Sprint-Zieles abzulesen.
Warum nicht?
Messen kann man in Scrum, ob eine Story fertig ist. Fertig ist sie, wenn sie der Definition of Done genügt und der Product Owner sie sich in einem Review angeschaut und akzeptiert hat. Der Review durch den Product Owner erfolgt üblicherweise im Sprint Review am Ende eines Sprints. Natürlich könnte man das auch während des Sprints machen, aber im Sprint soll das Team möglichst ungestört arbeiten.
Das Sprint-Ziel ist erreicht, wenn alle Stories, auf die sich das Team committed hat, am Ende des Sprints der Definition of Done genügen und vom Product Owner akzeptiert sind.
Weiterlesen
Warum testet man Software?
Man will Sicherheit gewinnen, dass die Funktionalitäten, die man realisieren möchte, korrekt umgesetzt sind.
Warum fühlt sich Test Driven Development so gut an?
Es erlaubt, in extrem kurzen Zeitabständen Feedback über die geleistete Arbeit zu erhalten.
Das können, so glaube ich, alle unterschreiben, die in agilen Projekten unterwegs sind.
Für kaum eine andere Tätigkeit im Bereich der Software-Entwicklung interessieren sich die Management-Etagen so sehr wie für das Testen. Ich frage mich schon lange, warum das so ist. Vielleicht liegt es daran, dass “grüne” Tests Sicherheit vermitteln. Ebenso wie eine hohe Anzahl von Tests. In jedem Fall kann es nicht daran liegen, dass durch Tests der Business Value gesteigert wird.
Es kann hunderte grüner Testfälle geben, ohne das ein Projekt deshalb erfolgreich ist. Erfolgreich ist ein Projekt aber nur, wenn die Software läuft. Und Software bekommt man am besten – und am schnellsten – zum Laufen, in dem man schnelles, nachvollziehbares Feedback erhält. Wie beim Test Driven Development.
Warum also werden viele Testwerkzeuge danach ausgewählt, dass sich wunderbare Reports erstellen lassen, Test-Templates und Test-Prozesse abgebildet werden, das Test-Management der Test-Designs für die Test-Spezifikationen, die während der Test-Analyse enstehen und innerhalb der Test-Ausführung nach der Test-Automatisierung die Grundlage für Testfälle bilden?
Warum schaut man nicht einfach, wie man schnelles Feedback ohne lange Deployment-Zyklen realisieren kann.
Warum macht man sich in diesem, für den Erfolg so entscheidenden Bereich, von proprietären Tools abhängig, die nur einen Bruchteil dessen leisten, was benötigt wird?
Warum setzt man nicht ausschließlich auf Werkzeuge, die einem Entwickler in weniger als 3 Minuten Feedback geben ohne einen gigantischen Testprozess starten zu müssen?
Warum setzt man im 21. Jahrhundert, einer Zeit, in der Kommunikation zwischen Individuen hoch geschätzt wird und als wertvoll erkannt ist, auf Werkzeuge, die Tester in Teams ausgrenzen und eher am Testen hindern?
Im Agilen Manifest steht als erster Grundsatz: “Individuals and interactions over processes and tools”.
Warum ist es so schwer, diesem Grundsatz bei der Auswahl von Test-Tools zu folgen?
Das alles interessiert mich wirklich sehr.
Die meisten Teams, denen ich bisher begegnet bin, teilen das Sprint Planning in einen ersten und einen zweiten Teil. Im ersten Teil stellt der Product Owner die Items aus dem Backlog vor, die im den nächsten Sprint entwickelt werden sollen. Das Team hat die Möglichkeit fachliche Fragen zu stellen und der Product Owner antwortet. Im Planning II zerlegt das Team die Stories in Tasks. So weit, so gut.
Die fachlichen Fragen des Teams hat der Product Owner im Planning I beantwortet. Aber was ist mit den technischen Fragen? Über diese stolpern die meisten Teams während des Planning II. Oft passiert es dann, dass sich einzelne Teammitglieder vor ihren Computer setzen und in den Tiefen des Quellcodes abtauchen – nur, um dann für den gesamten Rest des Plannings nicht mehr aufzutauchen. Das ist ärgerlich für den Rest des Teams.
Manche Teams lösen das über ein Pre-Planning der Stories im Sprint davor. Allerdings das Pre-Planning zu verschwendeter Zeit führen, nämlich dann, wenn Stories doch nicht in den nächsten Sprint kommen.
Um diese Situationen zu vermeiden, habe ich mit meinen Teams eine Phase zwischen Planning I und Planning II eingeführt.
Weiterlesen
Redmine steht ab sofort in der aktuellen Version 1.4.6 für die aktuellen openSUSE-Versionen zur Verfügung.
Das RPM ist mit SQLite unter openSUSE 12.1 getestet.
Die Version 1.4.6 von Redmine setzt Rails 2.3.14, Rack 1.1.1 sowie RubyGems <= 1.8 voraus. Außerdem wird für Redmine 1.4.x noch Ruby OpenID benötigt, dass in der Version 2.1.8 ebenfalls in meinem Repository verfügbar ist.
Wichtig: Wenn Redmine aus den openSUSE Repositories installiert werden soll, muss das das Repository home:gerritbeine:ruby eine höhere Priorität haben, als das Repository devel:languages:ruby:extensions. Höhere Priorität bedeutet einen niedrigeren Zahlenwert in der Repository-Verwaltung!
Die aktuelle Rails Version kann aus dem Ruby-Repository des Build Service bezogen werden.
Für VPN Verbindungen bevorzuge ich eigentlich OpenVPN, das ich auch in vielen Konstellationen seit langer Zeit einsetze. Leider gibt es einige Geräte, die OpenVPN nicht unterstützen.
Diese Geräte unterstützen aber meistens Microsofts PPTP, das zwar bei weitem nicht so sicher ist, aber von einigen Geräten als einziges Protokoll unterstützt wird.
Als begeisterter LDAP-Nutzer konnte ich es natürlich nicht lassen, den pptpd mit einer LDAP-Authentifizierung zu konfigurieren.
Weiterlesen
Auch 2013 biete ich wieder einige Seminar bei Open Source School an.
Das klassische UML Seminar ist durch das Seminar Modellierung von Software ersetzt worden. Die Inhalte können hier nachgelesen werden.
Zum Thema Test Driven Development gibt es wieder eine Veranstaltung für Java-Entwickler und eine für PHP-Entwickler.
Neu im Programm ist Arbeiten mit Legacy Code. Auch zu diesem Thema biete ich das Seminar für Java-Entwickler und für PHP-Entwickler an.
Außerdem habe ich mir Gedanken gemacht, wie ich meine Erfahrungen aus den Welten der Software Architektur und der Agilen Softwareentwicklung weitergeben kann. Dabei ist das Seminar Agile Softwarearchitektur entstanden, zu dem die Inhalte hier nachgelesen werden können.
Redmine steht ab sofort in der aktuellen Version 2.0.4, für die aktuellen openSUSE-Versionen zur Verfügung. Ich freue mich über Feedback und Tests des Packages, das als Package redmine2 auf dem Repository http://download.opensuse.org/repositories/home:/gerritbeine:/ruby/ installiert werden kann.
Die Version 2.0.4 von Redmine setzt Rails 3.2.6 und Rack 1.1.1 sowie RubyGems <= 1.8 voraus.
Die aktuellste Rails Version kann dabei aus dem Ruby-Repository des Build Service bezogen werden.
Redmine 2.0.4 wird die letzte Version von Redmine 2.0 sein, zukünftig wird nur noch Redmine 2.1 weiterentwickelt werden. Die Probleme mit dem Startscript, die bei Version 2.0.3 aufgetreten sind, sind hoffentlich gefixt.
Dennoch bitte ich um Tests und Feedback.
Sobald das Paket stabil ist, werde ich das Update auf Version 2.1.3 angehen und die Konfiguration für mod_passenger vorbereiten.
Redmine steht ab sofort in der aktuellen Version 1.4.5 für die aktuellen openSUSE-Versionen zur Verfügung.
Das RPM ist mit SQLite unter openSUSE 12.1 getestet.
Die Version 1.4.5 von Redmine setzt Rails 2.3.14 und Rack 1.1.1 sowie RubyGems <= 1.8 voraus.
Die aktuellste Rails Version kann dabei aus dem Ruby-Repository des Build Service bezogen werden.
Den VMware ESXi 5 mit Nagios zu überwachen ist ein Kinderspiel – wenn man die notwendigen Kniffe kennt.
Damit ich sie nicht vergesse, schreibe ich sie hier als Artikel in mein Blog 
Zunächst ist es notwendig, einen User zu erstellen, mit dem sich der Nagios authentifizieren kann. Das passiert ganz altmodisch mit
useradd -s /bin/true monitoring -g users
Dabei sollte man die Shell auf /bin/true setzen, um ein Login über SSH oder an der Konsole zu verhinden. Der User muss auf jeden Fall in der Gruppe users sein, sonst funktioniert der Zugriff über die Web Services nicht. Der nächste Schritt ist das Setzen eines Passwortes für den Benutzer, das passiert mit dem Befehl
passwd monitoring
Der passwd-Befehl von VMware generiert ein ziemlich langes, kryptisches Passwort, das man direkt verwenden kann. Beide Kommandos weisen darauf hin, dass sie deprecated sind und man an ihrer Statt vim-cmd verwenden soll. Die Anlage funktioniert aber auf diesem Weg nach wie vor wunderbar.
Weiterlesen