Jira, Confluence, Fisheye und Crucible – Erste Erfahrungen

Nachdem die Einführung von Fisheye und Crucible zuerst mit Skepsis aufgenommen wurde – „Es wird alles immer formaler!“ – hat es sich – trotz anfänglicher Widerstände – „Wir brauchen das bei uns im Scrum-Team nicht, wir machen unsere Code-Reviews wie immer!“ – inzwischen etabliert. Ein Vorteil gegenüber „klassischen“ Code-Reviews sind die Übersichtlichkeit, Nachvollziehbarkeit und Vollständigkeit.

Vor allem in unserem aktuellen Projekt gibt es hohe Qualitätsstandards und die Sicherung dieser will dokumentiert sein. Das kann man grundlegend natürlich auch durch einen Schritt „Review“ im Workflow von Jira erreichen, dort hat man dann allerdings nur dokumentiert, dass man ein Review durchgeführt hat, aber nicht was man dem Review unterzogen hat! Bei Fisheye und Crucible bekommt man alle zugehörigen Codestellen angezeigt und muss diese auch alle einem Review unterziehen. Die Qualität des Reviews liegt damit zwar immer noch beim Reviewer, aber sowohl dieser als auch die Qualitätssicherung kann sich sicher sein, dass der Reviewer keine Codestellen vergessen hat. Mit der Einführung von Fisheye und Crucible hat man es nun leichter, seine Definitions of Done (DoD) zu dokumentieren und dies gegenüber Interessierten auch zu kommunizieren.

Im aktuellen Projekt hatten wir im letzten Sprint-Review einen Gast aus der Qualitätssicherung, welcher sich – ausser dem aktuellen Fortschritt – natürlich vorrangig für die Aspekte der Qualitätssicherung interessierte. Leider waren wir darauf nicht explitzit vorbereitet und konnten ihm dies nicht innerhalb unserer Sprint-Dokmentation zeigen. Dank Fisheye und Crucible konnten wir ihm die gewünschten Informationen aber schnell präsentieren und seinen Informationshunger stillen.

In der Sprint-Dokumentation des aktuellen und der kommenden Sprints ist die Verlinkung zu den entsprechenden Code-Änderungen und der zugehörigen Reviews nun ein fester Bestandteil und wurde bei den vorhergehenden Dokumentationen ebenfalls hinzugefügt. Damit stehen nun auch diese Aspekte der Qualitätssicherung – immer aktuell und transparent – allen Interessierten zur Verfügung, ohne dass dies zu gesondertem Aufwand führen würde, wie dies bei einer ansonsten gesonderten Erfassung der geänderten Sourcen und deren Reviews erforderlich wäre.

Abschließend noch etwas zu Confluence: Ich mag es, auch wenn mir manche Dinge als nicht so offensichtlich oder umständlicher erscheinen, als z.B. bei MediaWiki. Einen Anchor zu setzen ist z.B. – meines Erachtens – komplizierter und die Verlinkung zu einer Überschrift ist auch nicht immer direkt eingängig.

Doch genug der Kritik, für mich überwiegen die Vorteile, wie z.B. die unkomplizierte und übersichtliche Erstellung von Tabellen, der Verlinkung von Bereichen und der Makros für Diagramme – um nur einige zu nennen.

Die „Community-Features“ sind ein nettes Gimmick, sollten aber nicht dazu verleiten Inhalte zu transportieren, sondern sollen sie dazu dienen, diese Inhalte zu verbreiten bzw. annoncieren oder diskutieren. Gerne dürfen Informationen oder auch Inhalte dort initial erscheinen, es sollte nur nicht vergessen werden, diese dann auch in der  „Wiki-Struktur“ festzuhalten um die Information und Inhalte nicht zu fragmentieren.

Alles in allem ist das bisherige Fazit positiv.

Schreibe einen Kommentar