A new blog – a new perspective

It’s the first of january 2016. Do I think about new year resultions? Sure! Is this blog one of them? Probably…

It’s not my first blog, but I think I needed a restart – a new perspective. I don’t know what impulse gave this new, clean space for my thoughts birth. But more and more I feel it is time to leave a lot of things behind. For the readers of my previous blog (same url) this post should explain what will be different and why I threw hundreds of brilliant posts away (okay, more like 30 not so clever posts I guess…). For my new readers this is a great start to read about the purpose of this blog and planned posts.

Verantwortung übernehmen – Das Team und weitere nützliche Rollen

Neben der generellen Übernahme von Verantwortung für den Gesamtprozess, die Selbstorganisation und die Sprint-Ergebnisse habe ich sehr gute Erfahrungen mit der Definition weiterer Rollen im Team gemacht.

So sollte möglichst jedes Teammitglied bei größeren Projekten eine ganz spezielle Rolle einnehmen und sich zusätzlich zu seinen normalen Verantwortungen um dieses eine Thema kümmern.

Sinnbildlich gesprochen bekommt jedes Teammitglied einen Hut aufgesetzt. Ich habe dies gerne zu Projektbeginn am Projekt-Board visualisiert. So gab es für jede vorhandene Rolle eine farbige Karte. Die Teammitglieder durften sich selber ihre Rollen aussuchen und eine Karte mit ihrem Foto oder ihrem Namen an die entsprechende Rolle heften.

Die Rollen sollten individuell auf die eigene Organisation und die benötigten Arbeitsprozesse zugeschnitten werden. Ebenfalls wird nicht jede Rolle in jedem Projekt benötigt. Hier sollte die Auswahl gemeinsam und pragmatisch auf das Projekt zugeschnitten getroffen werden.

Dabei bedeutet die Übernahme einer Rolle nicht, alle damit verbundenen Schritte selbst auszuführen. Es geht lediglich darum die Verantwortung für den Prozess zu übernehmen und das Team auf Probleme und notwendige Schritte hinzuweisen. In größeren oder langfristigen Projekten ist es sinnvoll die Hüte nach einer gewissen Zeit zu tauschen.

Einige häufig genutzte Rollen erkläre ich im Folgenden.

Kanban in a Nutshell 2/2

Hier unser zweiter Teil der Serie “Kanban in a Nutshell”. Den ersten Teil findet ihr hier:

Kanban in a Nutshell – Einführung

1.1.1       Drei Grundprinzipien und fünf Kerneigenschaften

Das Kanban-System basiert auf drei einfachen Grundprinzipien und 5 Kerneigenschaften. Außer diesen abstrakten Regeln wird nichts vorgegeben. Damit eignet sich Kanban perfekt, um sich an bestehende Prozesse anzuheften ohne dabei große Änderungen im ersten Schritt zu verlangen. Die drei Grundprinzipien sind

Kanban in a Nutshell 1/2

Wie bereits für eXtreme Programming (Artikelserie) beleuchten wir andere Methoden als Scrum in kurzen Artikelserien. Heute geht es weiter mit Kanban. Wir teilen diese Serie in 2 Teile:

  • Einführung
  • Grundprinzipien und Kerneigenschaften

Einführung

Kanban kommt ursprünglich aus der Automobil-Produktion und wurde später für die Softwareentwicklung abstrahiert. Diese Methodik basiert dabei auf einigen wenigen Regeln und Prinzipien und ist sehr flexibel im Einsatz. Grundsätzlich verspricht Kanban schnellere Durchlaufzeiten für Tasks und durch eine effiziente Visualisierung Engpässe sichtbar zu machen.

Warum bist du so agil wie meine Oma?

Kürzlich in einer Retrospektive. Das Team sollte Fragen an den vergangenen Sprint formulieren. Diese wurden auf Karten gesammelt und anschließend in der größeren Runde diskutiert, gruppiert und bewertet. Neben Fragen wie “Funktioniert Pair Programming für uns?” oder “Haben die zeitnahen Fachtests dieses Mal besser funktioniert?” ist eine Frage besonders aufgefallen: Ein Entwickler fragte “Wieso bist du so agil wie meine Oma?“.

Continuous Deployment mit git, codeship.io und nightwatch.js bei youhear.it

Im November sprechen Christof und ich von youhear.it auf der Webcon über unsere Entwicklungsumgebung und Prozesse. Heute möchte ich jedoch bereits einen kleinen Vorgeschmack geben und einen wichtigen Teil unseres Entwicklungsprozesses vorstellen: Den Deployment-Prozess.

Wir versuchen in der Entwicklung von youhear.it möglichst nah an einen kontinuierlichen Prozess ranzukommen. Die bekanntesten Vertreter sind Continuous Integration (CI) und Continuous Deployment (CD). Beim Continuous Deployment geht es darum, automatisiert und ohne manuelle Eingriffe Änderungen, Bugfixes und neue Features in das Live-System zu integrieren.

Wie sieht das in der Praxis aus? Sobald wir eine Änderung auf unserem Produktionsbranch vornehmen, werden folgende Schritte durchgeführt:

  • Die Installationsskripte werden geprüft (npm install und bower)
  • Die Unittests werden ausgeführt
  • Alle Javascript-Dateien werden einem code linting unterzogen

Wenn das alles reibungslos funktioniert hat, kommt das eigentliche Deployment:

  • Überspielen der Daten auf das Staging-System und Installation dort
  • Ausführung von Selenium-Tests
  • Wenn Tests erfolgreich: Überspielen der Daten auf das Live-System
  • Kurze Selenium-Tests ob die Basis-Funktionen korrekt funktionieren und die Seite ansprechbar ist

Auf diesem Weg reicht jederzeit in der Entwicklung ein kurzes git push um etwas in das Live-System zu integrieren. Die Tests und Sicherheitsmaßnahmen sind dabei eine ausreichende Sicherung um nicht durch Unachtsamkeit die Anwendung kaputt zu machen.

Welche Tools, Schritte und Einstellungen nutzen wir dafür im einzelnen?

git

git als Versionsverwaltungssystem (und Alternative zu Subversion oder CVS) sollte jedem Entwickler ein Begriff sein. Dennoch gibt einem git relativ wenig zur Projektorganisation vor. Wir setzen auf das git flow Modell (https://github.com/nvie/gitflow). Eine gute Einführung in git flow findet man unter http://nvie.com/posts/a-successful-git-branching-model/.

Hieraus ergibt sich folgende Branch-Struktur:

  • Master (entspricht immer der Live-Version)
  • Develop (aktuell stabiler Entwicklungsstand)
  • Feature-Branches (werden nach Fertigstellung in develop gemerged)
  • Hotfix-Branches (werden für schnelle Änderungen direkt in den Master gemerged)
  • Release-Branches (Um einen definierten Stand von develop zur Produktionsreife zu bringen)

Um nun ein deployment auf den live Server zu starten reicht folgender Befehl:

git push origin develop

Bei youhear.it setzen wir in codeship (siehe weiter unten) zwei verschiedene Konfigurationen ein. Jeder push auf den Master Branch führt alle oben beschriebenen Schritte des Deployments durch. Ein push des develop-branches hingegen hört nach dem Selenium-Test auf dem staging-Server auf.

Als externes repository nutzen wir bitbucket (wir integrieren auch unser JIRA direkt damit).

codeship.io

cs_logo

Codeship.io ist ein richtig cooler Service der uns eine Menge abnimmt (sobald er einmal sauber eingerichtet ist 😉 ). Ziel ist es dem ganzen Team eine einheitliche Integrations-Plattform zu bieten, die den Code nach jedem commit prüft und ggf. in die Staging- oder Produktionsumgebung überspielt. Dabei spielt codeship extrem gut mit unserem Workflow und unserer anderen Tools zusammen. Durch eine direkte Bitbucket-Anbindung ist die Verknüpfung zu git schnell gemacht. Anschließend muss man nur noch definieren, welche Test-Schritte ausgeführt werden sollen und welche Schritte für das Deployment nötig sind. Sind diese Einstellungen gemacht kann man sich live ansehen wie das Projekt gebaut wird und sieht sofort ob alles geklappt hat (grün) oder nicht (rot). Besonders klasse gelöst im rot-Fall: Man kann sich per ssh in die build-Maschine einwählen und fehlgeschlagene Builds auf der Konsole debuggen!

codeship1

 

Unser Integration-Skript für das Frontend:

nvm install 0.10.26
nvm use 0.10.26
npm cache clear
npm cache clean
rm -rf ./~npm
rm -rf /home/rof/.npm/
npm update -g
npm set registry https://registry.npmjs.org/
npm install -g grunt-cli bower grunt karma-coverage istanbul
npm install
bower install
grunt --force
grunt jshint
grunt karma

Besonders beachten sollte man dabei folgende Zeilen:

npm cache clear
npm cache clean
rm -rf ./~npm
rm -rf /home/rof/.npm/
npm update -g
npm set registry https://registry.npmjs.org/

Diese paar Zeilen haben mich fast 2 Tage gekostet und mir einige graue Haare eingebracht. Ich war schon drauf und dran codeship an den Nagel zu hängen. Das Problem: Der build schlug random-mäßig fehl, noch weit bevor der eigentliche Applikationscode ausgeführt wurde, bei npm install. Doch auch hier hat sich eine Stärke von codeship gezeigt, der spitzen Service. Ich habe bisher auf jede meiner Mails innerhalb von 2 Stunden eine kompetente und freundliche Antwort erhalten und konnte so Probleme schnell fixen. In diesem Fall hätte ich mich wohl nicht so lange selbst die Zähne ausbeißen sollen…

Und abschließend hier noch unser Deployment Skript:

git remote add staging dokku@###.###.###.##:youhearit
git push staging develop:master
npm install nightwatch -g
cd ..
nightwatch
git remote add prod dokku@xxx.xxx.xxx.xxx:youhearit
git push prod master

Und das war es schon! Jeder commit landet nun nach erfolgreichen Test auf dem Server und ist online. Für die Installation und das Management des Deployments auf Server-Seite nutzen wir Dokku. Das führt aber für diesen Artikel etwas zu weit.

nightwatch.js

nightwatch

Das letzte Tool in unserem Stack das ich vorstellen möchte ist nightwatch.js. Der Eine oder Andere kennt vielleicht bereits Selenium. Selenium ist letzlich ein headless Browser, also ein Internet-Browser, nur ohne Bedienoberfläche wie man das vom Chrome oder Firefox kennt. Dieser Browser erlaubt einem Skripte auszuführen, die einen realen Benutzer vortäuschen. Ich kann also Testszenarien sehr fachlich definieren:

  • Rufe URL www.google.de auf
  • Überprüfe das der Titel der Seite “Google” ist
  • Tippe “nightwatch” in das Suchfeld ein
  • Schicke das Formular ab
  • Überprüfe ob die Ergebnisseite den Text “The Night Watch” enthält

Der Code sieht dazu wie folgt aus:

module.exports = {
  "Demo test Google" : function (client) {
    client
      .url("http://www.google.com")
      .waitForElementVisible("body", 1000)
      .assert.title("Google")
      .assert.visible("input[type=text]")
      .setValue("input[type=text]", "nightwatch")
      .waitForElementVisible("button[name=btnG]", 1000)
      .click("button[name=btnG]")
      .pause(1000)
      .assert.containsText("#main", "The Night Watch")
      .end();
  }
};

Einfach, oder?

Zusammenfassung

Wir glauben in der Kombination von git, codeship.io, dokku und nightwatch einen günstigen, einfach handhabbaren und gut laufenden Prozess gefunden zu haben den wir jedem Startup ans Herz legen können. Wir haben uns damit viel Stress genommen und können uns voll auf die Entwicklung konzentrieren ohne zu viele Randthemen ständig im Auge haben zu müssen.

Als Projektleiter von Großprojekten und vor allem Projekten im Finanz-Sektor bin ich es gewohnt mit maximal einer Lieferung pro Monat auszukommen und extrem viel Aufwand in der Testplanung und Testdurchführung zu betreiben. Ein agiler, schlanker Prozess wie oben beschrieben erlaubt es uns mehrmals täglich Produktionscode zu releasen ohne dabei Kopfschmerzen haben zu müssen.

 

Schätzwerte im Projektverlauf korrigieren

Von Zeit zu Zeit müssen Schätzungen im Projetverlauf nachträglich korrigiert werden, um neuere Erkenntnisse zu berücksichtigen. Dabei werden ausschließlich Anforderungen angepasst, dessen Größe sich verändert hat. Wurde eine Anforderung hingegen wider Erwarten nicht innerhalb eines Sprints wie geplant abgeschlossen wird diese Fehlplanung über eine Anpassung der Velocity, und nicht über eine Anpassung der Schätzung vorgenommen.

Dabei werden auch keine Anforderungen geteilt, wenn zum Beispiel eine User Storie zur Hälfte umgesetzt wurde, aber nicht vollständig bis zum Sprint-Ende realisiert werden konnte. Scrum verfolgt dabei das all-or-nothing-Prinzip. Entweder eine Story wird komplett, inklusive aller Akzeptanzkriterien und Tests fertiggestellt und durch den Kunden abgenommen oder sie zählt überhaupt nicht und es werden auch keine Teilpunkte für diese Anforderung gegeben. Meistens werden die halbfertigen Anforderungen im nächsten Sprint fertiggestellt und die Velocity gleicht sich im Durchschnitt wieder an.

Einen Sonderfall stellen Stories dar, die in einer Iteration nur halb umgesetzt werden konnten, und erst in einer späteren Iteration fertiggestellt werden. Hier werden für den bereits erledigten Teil entsprechend viele Punkte gutgeschrieben und die [glossary id=’1577′ slug=’user-story’ /] sinnvoll geschnitten, sodass der noch offene Teil mit einer neuen Schätzung wieder ins [glossary id=’1572′ slug=’product-backlog’ /] geschrieben wird und wie eine normale Anforderung behandelt wird.

Umgang mit User Stories für visuelle Anforderungen

User Stories ([glossary id=’1577′ slug=’user-story’ /]) fokussieren vor allem darauf, wie der Nutzer mit dem System interagiert und welche Funktionalitäten das System dem Anwender zur Verfügung stellt. Die visuellen Anforderungen gehen dabei etwas verloren und sind schwerer in dieser Form zu erfassen und auch zu schätzen.

Daher ist es für Projekte mit einem Schwerpunkt im Design von Vorteil die visuellen und kommunikativen Anforderungen in einem separaten Konzept zu vereinbaren und das [glossary id=’1572′ slug=’product-backlog’ /] für die eigentliche Funktionalität zu nutzen. Das bedeutet aber nicht, dass das Design keinen wertvollen Input zum Product Backlog liefern kann. Für die Schätzungen und Detaillierungen der einzelnen Features spielen die Gewerke Konzeption und Design nach wie vor eine ebenso zentrale Rolle wie die Entwicklung selbst. Lediglich der übergeordnete Styleguide, das grobe Layout und die kommunikativen Ziele und Paradigmen des Projektes werden an separater Stelle festgehalten und gepflegt.

Nicht alle Multimedia-Projekte basieren auf Features

Vom Grundsatz müssen User Stories nicht nur reine Funktionalitäten beschreiben. Jedoch passt dieses Verfahren auf Features sehr gut, während es in abstrakteren Bereichen weniger geeignet ist. So lässt sich eine Video-Produktion sicher mit User Stories beschreiben, jedoch klingen „Als Betrachter möchte ich über das Unternehmen informiert werden“ und „Als Betrachter möchte ich die Credits im Abspann sehen“ doch etwas gestelzt. Ein klassisches Storyboard funktioniert hier wahrscheinlich besser.

Daher gilt auch hier wieder: Das richtige Tool für das richtige Projekt. Auf die meisten Webprojekte und gerade auf größere Plattformen und Applikationen passt die Anforderungsanalyse und – Verwaltung mit Hilfe von Product Backlog und User Stories sehr gut, aber für kleinere und andersartige Projekte müssen vielleicht Sonderformen und gänzliche andere Tools hinzugezogen werden.

Geeignete Punktsequenz für Schätzen in abstrakten Größen

Bei der Zuordnung von [glossary id=’1585′ slug=’story-points’ /] ist es hilfreich, eine fest definierte Punktesequenz, also eine Menge von vorgegebenen Schätzwerten, zur Hilfe zu nehmen. Diese Punktesequenz sollte den Umstand berücksichtigen, dass Anforderungen mit zunehmender Größe nur noch sehr ungenau geschätzt werden können. Während man durchaus zwischen einer Anforderungen mit einem Story Point und einer mit zwei Story Points differenzieren kann (immerhin liegt hier ein Unterschied von 100% vor) würde eine Schätzung von 65 Punkten nur minimal von einer Schätzung von 66 Punkten abweichen. Eine Differenzierung in dieser Größenordnung würde lediglich Genauigkeit suggerieren.

In der Praxis wird dazu eine Punktesequenz basierend auf der Fibonacci-Reihenfolge benutzt. Diese Sequenz ist exponentiell ansteigend und wird so genau wie die Anforderungen mit zunehmender Größe ungenauer. Die Schätzwerte sind 1, 2, 3, 5, 8, 13, 20, 40, 100.

Während die Werte 1 bis 13 noch recht genaue Aussagen über die Größe einer Anforderung zulassen, beschreiben die Werte 20 bis 100 eher Epics oder Themen.

Die einzelnen Schätzwerte sind dabei sinnbildlich als Gefäße zu betrachten. Das kleinste Gefäß, was lediglich Anforderungen mit einem Story Point enthält; das nächste Gefäß ist etwas größer und kann Anforderungen mit 2 Story Points beinhalten usw. Dies hilft der schnellen Einsortierung. Wichtig ist dabei das Verständnis im Umgang mit Zwischengrößen. Schätze ich einen Eintrag des Backlogs auf doppelt so groß wie einen anderen mit 2 Story Points, so käme ich rechnerisch auf 4 Story Points. Dafür ist aber kein Gefäß vorgesehen. Daher stecken wir die Anforderung in das Gefäß für 5 Story Points und geben ihr diesen Schätzwert. Auf diese Weise wird die steigende Ungenauigkeit bei Schätzungen abgefangen.

Dabei sollte der Inhalt des Gefäßes eher als Sand und weniger als Flüssigkeit verstanden werden. Füllen wir 14 Liter Wasser in einer Gefäß, das 13 Liter Platz bietet wird der Inhalt nicht ganz hinein passen. 14 Liter Sand würden aber eventuell passen, da sich der überschüssige Sand noch etwas türmen kann bevor er herunterfällt. Damit soll verdeutlicht werden, dass ein gesundes Augenmaß wichtig ist und diese Gefäße vor allem der möglichst schnellen Einschätzung von Anforderungen dienen. Es spielt für den Projektverlauf und die Planung keine Rolle, ob eine Anforderung mit 14 oder mit 13 Story Points bewertet wurde.

Die Benutzung einer solchen Punktesequenz erspart viel Diskussion und bildet die Realität sehr gut und auf einfache Weise ab ohne die Genauigkeit zu verfälschen.

eXtreme Programming in a Nutshell 4/4 – XP-Techniken

Das ist nun der vierte und letzte Teil der Serie “eXtreme Programming in a Nutshell”. Die ersten Teile findet ihr hier:

XP-Techniken

Um das Einhalten der Prinzipien und Werte, die XP vorgibt, zu vereinfachen, definiert XP 14 Techniken (ursprünglich 12 durch Kent Beck, allerdings sind Standup-Meetings und Retrospektiven mittlerweile fester Bestandteil des Frameworks).

Kunde vor Ort

Auch XP versucht den Kunden und den Anwender möglichst eng in den Projektprozess zu integrieren. Dabei ist das Ziel, die Anforderungen des Kunden und Anwenders zu verstehen, und nicht eine schriftliche Spezifikation des Systems vom Kunden überreicht zu bekommen.

Planungsspiel

Auch XP ist ein iterativer Prozess. Im Planungsspiel, äquivalent zum Sprint-Planning in Scrum, wird ein Satz von Anforderungen für die nächste Iteration ausgewählt, geschätzt und priorisiert.

Standup-Meetings

Täglich trifft sich das gesamte Team zu einer festgelegten Zeit, um sich kurz über den aktuellen Status und Probleme auszutauschen. Das Meeting sollte nicht länger als 15 Minuten dauern.

Kurze Releasezyklen

Neue oder geänderte Funktionalitäten sollen kurzfristig nach der Fertigstellung in das Produktiv-System released werden, damit dem Anwender schnell die Bugfixes und neuen Features zur Verfügung gestellt werden können und im Gegenzug schnell Feedback dazu artikuliert werden kann.

Retrospektive

Regelmäßig werden Retrospektiven ([glossary id=’1622′ slug=’retrospektive’ /]) mit dem gesamten Team durchgeführt um den reinen Entwicklungsprozess auf den Prüfstand zu stellen und hier eine stetige Verbesserung zu erzielen.

Metapher

Ähnlich einer Projekt-Vision soll das Projekt mit einigen kurzen Metaphern auf den Punkt gebracht werden, die als Richtlinie für Entscheidungen aller Art dienen.

Gemeinsame Verantwortlichkeit

Das komplette Team ist für die Qualität des Ergebnisses, die Zufriedenstellung des Kunden und den Entwicklungsprozess verantwortlich. XP geht sogar so weit, und macht jedes Teammitglied für den kompletten Quellcode verantwortlich und fördert die Arbeit jedes Einzelnen an allen Komponenten. Dadurch soll es jedem Entwickler ermöglicht werden auch für einen Team-Kollegen einzuspringen.

Fortlaufende Integration

Neue oder geänderte Komponenten werden möglichst frühzeitig integriert und somit dem gesamten Team zur Verfügung gestellt. So können diese den neuen Code schneller für ihre eigene Arbeit am Projekt nutzen und Abhängigkeiten werden früher sichtbar.

Programmierstandards

Damit Verantwortung für den gemeinsamen Code übernommen werden kann, muss ein einheitlicher Programmierstandard sichergestellt sein. Dafür entwickeln Teams oder Unternehmen eigene Coding-Guidelines.

Nachhaltiges Tempo

Die Auslastung des Teams soll möglichst gleichbleibend sein. Dabei werden Überstunden in XP-Projekten nur in geringem Maße toleriert. Freiraum und geregelte Arbeitszeiten bedeuten Zufriedenheit und Ausgeglichenheit des Mitarbeiters und fördern Kreativität.

Testen

XP fordert von allen Ergebnissen der Entwicklung eine Qualitätssicherung durch die Durchführung von Tests. Zum einen durch automatisierte Tests und interne Prüfungen der Akzeptanzkriterien, zum anderen durch Live-Tests mit dem Anwender.

Einfaches Design

Es wird die einfachste Lösung für die Entwicklung angestrebt. Diese kann schneller umgesetzt und leichter getestet werden.

Refactoring

Permanentes Refactoring, also die Umstrukturierung des Codes um einen guten Programmierstil zu wahren, erleichtert die spätere Wartung und Weiterentwicklung.

Programmieren in Paaren

XP sieht vor, immer in Paaren vor einem Computer zu sitzen ([glossary id=’1645′ slug=’pair-programming’ /]) und gemeinsam ein Feature zu realisieren. Dadurch wird Wissen schneller verteilt und die Qualität der Software erhöht.

Navigate