Müssen Sie Ihren Chef noch überzeugen und benötigen ein paar gute Argumente? In diesem Artikel habe ich beschrieben, in welchen Situationen ein Wiki einen deutlichen Mehrwert für ein Unternehmen bietet.

Redaktionelle Engpässe vermeiden

Ein wesentlicher Unterschied zwischen einem Intranet und einem Wiki ist, dass ein Intranet oftmals nur von einer kleinen Personenzahl im Unternehmen aktualisiert wird. Dadurch fehlt die Dynamik der Inhalte und daraus resultierend die Attraktivität für die Mitarbeiter. Im Gegensatz dazu lebt ein Wiki davon, dass jeder Mitarbeiter seinen Beitrag leisten und sein Wissen sehr leicht darin einbringen kann – wodurch eine Fülle von aktuellen Informationen zu unterschiedlichsten Themen entstehen kann: Projektinformationen und Dokumentationen, Team- oder Abteilungsaktivitäten, eine FAQ oder Knowledge Database zu Produkten, Diskussionen- oder Wissensaustausch zu Veränderungen im Unternehmen sind die am häufigsten anzutreffenden Wiki-Themen. Informationen und Wissen werden somit nicht nur verwaltet, sondern leben und es entsteht ein übergreifender Austausch und eine effiziente Zusammenarbeit.

Informations-Silos wie E-Mail oder Netzlaufwerke bremsen die Produktivität

Wo war noch das letzte Meeting-Protokoll abgelegt? Irgendwo in den verschachtelten Ordnerstrukturen des Netzlaufwerks oder doch irgendwo im Postfach? Die Suche nach Dokumenten oder Informationen nimmt laut einer Studie (Hidden Costs of Information Work: A Progress Report) der IDC ca. 20% der Arbeitszeit ein.
Erstellen und verteilen Sie alles im Wiki, wo es an einem Ort zugänglich und durchsuchbar ist. Durch die zentrale Informationsquelle bekommen Sie von Kollegen zu Aufgaben die besten Ergebnisse.
Vermeiden Sie Informations-Silos zwischen Teams, Abteilungen und Individuen und es entsteht crowd-sourcing in Ihrer Organisation.
Eine Spezifikation kann z.B. von mehreren Personen gleichzeitig im Wiki erstellt und überprüft werden. Die entstandenen Wiki-Seiten können bei Bedarf später über einen Export in ein einzelnes Dokument überführt werden.
Weiterhin werden nicht selten Diskussionen über E-Mail geführt, die sich dann zeitlich überschneiden, zu unterschiedlichen Zeitpunkten in der Diskussion Empfänger raus- oder hinzugenommen werden und dadurch sehr schnell der Überblick verloren geht.
Im Wiki können Diskussionen, wichtige Entscheidungen und Argumente über Kommentare dauerhaft festgehalten und zu einem späteren Zeitpunkt nachgelesen werden.

Wikis ergänzen ein Dokumentenmanagementsystem

Auch wenn ein Wiki sehr viele Funktionalitäten aus dem DMS-Umfeld mitbringt, so bleibt es immer noch ein Wiki und sollte als solches verstanden werden. Wer also ein z.B. OpenText, Filenet oder eine Lösung wie d.evelop sie bietet nutzt, wird die umfangreichen Workflow- und Genehmigungsfunktionalitäten im Wiki vermissen. Den Charme eines Wikis machen aber gerade die Flexibilität und Einfachheit aus – die in Kombination mit einfacher Erlernbarkeit zu höherer Akzeptanz führen.

Dateien, die im Wiki abgelegt werden, dienen voranging dem Wissensaustausch und der Dokumentation von Ergebnissen in der täglichen Zusammenarbeit. Wichtige Funktionalitäten für den Umgang mit Dokumenten, die z.B. das Confluence-Wiki sehr gut gelöst hat, sind:

• Einfaches hinzufügen von Dokumenten per Drag & Drop.
• Versionierung von Dokumenten mit Änderungshistorie.
• Volltextindizierung.
• Inhalte aus Office-Dokumenten unkompliziert in Wiki-Dokumente integrieren oder direkt aus dem Wiki heraus bearbeiten.

Durch diese Funktionen und die Möglichkeit, Dokumente im entsprechenden Kontext auf Wiki-Seiten einzubetten, bekommt ein Unternehmenswiki eine andere Bedeutung und lässt sich daher sehr gut ergänzend neben einem Dokumentenmanagement betreiben.

Zusammenarbeit wird vereinfacht und Veränderungen sind transparent

In vielen Organisationen liegen wertvolle Informationen an vielen verschiedenen Orten verteilt. Mitarbeiter haben nur wenige Möglichkeiten herauszufinden, dass es diese Informationen gibt und wo es sie gibt.

Wenn wir wüssten, was unser Unternehmen weiß, könnten wir Kundenwünsche besser erfüllen, innovative Produkte früher anbieten, schneller auf Marktveränderungen reagieren und unsere Produktivität steigern. Kurz gesagt: Wir könnten schneller besser werden.

Ein Wiki ist dazu prädestiniert, Informationen mit anderen zu teilen und das Finden von Informationen zu vereinfachen. Mit Funktionen, die z.B. eine Liste aller zuletzt bearbeiteten Inhalte auf dem Wiki-Dashboard zeigen, erfahren Mitarbeiter welche Änderungen von anderen Kollegen vorgenommen wurden oder sie können sich automatisch über Änderungen in ausgewählten Wiki-Seiten informieren lassen.

Eine der Hemmschwellen bei der Einführung von Wikis, ist die Fucht vor Fehlern beim ändern oder kommentieren von Wiki-Seiten. Sind diese erst überwunden, entsteht eine neue Form der Zusammenarbeit. Nicht nur die Verfügbarkeit von Informationen wird verbessert, sondern auch die Qualität und Glaubwürdigkeit der Informationen verbessert sich.

Sicherer Schutz von zu schützenden Bereichen

Wikis sind für gewöhnlich sehr offen und leben von der Transparenz. Dennoch gibt es in der Regel in jeder Organisation zu schützende Inhalte. Die Personalabteilung möchte z.B. eingehende Bewerbungen im Wiki ablegen und diese Informationen nur eingeschränkten Benutzern freigeben oder Kunden sollen nur eingeschränkten Zugriff auf Projektinformationen erhalten.

In einem Wiki können Benutzerberechtigungen auf Inhaltsebene und Funktionalitätsebene vergeben werden. Es sollte in jeder Organisation abgestimmt werden, wie stark Reglementierungen auf Berechtigungsebene tatsächlich benötigt werden, denn die Transparenz ist ein kritischer Erfolgsfaktor für die erfolgreiche Einführung eines Unternehmenswikis. Risiken in Bezug auf Manipulation von Seiten sind geringfügig – Jederzeit kann nachvollzogen werden, wer was wann geschrieben hat und über die Änderungshistorie können fehlerhafte Änderungen einfach rückgängig gemacht werden.

Fazit:
Es gibt viele Gründe die für den Einsatz von Wikis in Unternehmen sprechen. Wirklich belastbare ROI-Berechnungen, die den Einsatz von Wikis rechtfertigen, habe ich bisher noch nicht kennengelernt. Jedoch hat laut einer Umfrage noch kein Unternehmen ein Wiki wieder abgeschaltet – im Gegenteil: Der Nutzen eines Wiki wurde laut dieser Umfrage von Jahr zu Jahr größer.

Wir bei codecentric setzen das Confluence-Wiki schon seit Jahren ein und nutzen es ausgiebig zur Projektdokumentation, als Knowledge Database und Intranet. Confluence ist bei uns zu einem festen Bestandteil unserer Zusammenarbeit geworden und als Werkzeug nicht mehr wegzudenken. Unsere Erfahrungen, die wir bei unseren Kunden gemacht haben zeigen, dass sich durch Wikis die in diesem Artikel beschriebenen positiven Unternehmenseffekte einstellen.

Sollten Sie in Ihrem Unternehmen auch gerade vor einer Wiki-Einführung stehen oder auch generell Fragen und Anregungen zu Wikis haben, würde ich mich über einen Kommentar oder eine Kontaktaufnahme freuen.

Bei der ersten Frage kommen mir direkt die Sätze “Lauffähige Software ist wichtiger als ausführliche Dokumentation” und “Der Quellcode ist die beste Dokumentation (da immer aktuell)” in den Sinn. Nun schränkt das Agile Manifest direkt ein, dass Dokumentation nicht unwichtig, lauffähige Software eben nur wichtiger ist. Und die Aussage bzgl. des Quellcodes bezieht sich auf die Dokumentation wie und nicht was eine Software macht. Daher spricht nichts gegen eine solche Dokumentation. Im Gegenteil, der Qualitätsanspruch und die damit notwendige Qualitätsicherung machen eine solche Dokumentation sogar zwangsläufig erforderlich.

Eine Prüfung der Umsetzungsqualität erfolgt durch den Vergleich der Anforderungen mit dem Verhalten der realisierten Software. Und dies gilt nicht nur für gerade umgesetzte Anforderungen, sondern auch für alle schon früher umgesetzten Anforderungen (solange sie sich nicht explizit ändern oder wegfallen). Daher wird eine Beschreibung des erwarteten Verhaltens der Software benötigt.

Akzeptanzkriterien und Testfälle

Im agilen Umfeld (mit User Stories) werden Anforderungen meist durch Akzeptanzkriterien genauer beschrieben. Hierbei wird für eine Ausgangssituation (Given) und ein Ereignis (When) ein Verhalten der Software (Then) zugeordnet. Wie offen oder genau die Ausgangssituation, das Ereignis oder das Verhalten dabei beschrieben sind, variiert. Beispiele hierfür können sein:

• “Ein deuscher Benutzer ist angemeldet, wenn er in einem beliebigen Textfeld Text mit deutschen Rechtschreibfehlern eingibt, wird die fehlerhafte Stelle unterstrichen.”
• “Das System befindet sich in einem konsistenten Zustand, wenn ein Benutzer die GUI bedient, bleibt das Sytem immer benutzbar und konsistent.”
• “Es gibt im Sytem ein Kundenunternehmen mit einer Kontaktperson, wenn der Benutzer eine neue Kontaktperson zu diesem Unternehmen mit gleichem Namen und Vornamen erfasst, zeigt das System einen Warnhinweis einer möglichen Doppelerfassung an.”

Dabei sind diese Akzeptanzkriterien nicht von der Umsetzung des Produkts oder eines Testumfelds abhängig. Jede weitere umgesetzt User Story erweitert oder verändert die Menge der Akzeptanzkriterien des Gesamtproduktes. Neben den Akzeptanzkriterien der User Stories gibt es auch “unausgesprochene” Kriterien, die gar nicht explizit erwähnt werden und meist sehr offen formuliert werden, z.B. “Egal was passiert, keine unbehandelten Fehler/Speicherlecks/Abstürze” oder “Lesbare und übersichtliche Benutzeroberflächen”.

Um die Qualität der aktuellen Umsetzung zu prüfen, werden für die Akzeptanzkriterien explizite Testfälle erzeugt. Diese berücksichtigen das aktuelle Testumfeld (wie Technologien und Testdaten) in dem die aktuelle Umsetzung getestet wird. Je offener ein Akzeptanzkriterium formuliert ist, desto mehr Testfälle werden benötigt (und um so schwieriger wird es, sinnvolle Testfälle zu formulieren). Um die Qualität zu überprüfen, muss die Menge dieser Akzeptanztests durchgeführt werden. Eine manuelle Ausführung dieser Tests ist schon nach kurzer Projektlaufzeit nicht mehr regelmäßig möglich. Daher werden möglichst viele dieser Tests automatisiert.

Was könnte jetzt als “Dokumentation der Anforderungen” dienen?

Die Liste der Akzeptanzkriterien ist im Grunde eine gute Dokumentation. Sie erfordert aber ein hohes Maß an Disziplin und Aufwand, um aktuell gehalten zu werden. Dies wird wahrscheinlich gerade im Projektstress als erstes ausgelassen werden. Dadurch kann sie sowohl nicht mehr zur aktuellen Umsetzung, als auch nicht mehr zu den aktuellen Testfällen passen.

Die automatisierten Tests und die Liste der nicht automatisierten Testfälle haben dagegen den Charme, dass sie bei der Qualitätsprüfung zumindest teilweise auf Aktualität geprüft werden. Ein fehlgeschlagener Test kann auf einer fehlerhaften Umsetzung des Produkts oder auf einen fehlerhaften Testfall beruhen. Beides könnte aber auch falsch sein und so zueinander passen, dass der Test erfolgreich ist. Dies kann zu einem systemischen Problem werden, da gerade eine enge Zusammenarbeit von Produktentwicklern und Testentwicklern die Wahrscheinlichkeit für diesen Fall erhöht. Dies ist  natürlich noch stärker der Fall, wenn es sich bei beiden Rollen um dieselbe Person handelt. Gerade im agilen Teamsetup, mit Entwicklern und Testern im selben Team, ist das nicht sonderlich ungewöhnlich. Weiterhin stellt sich die Frage, wie vollständig die Anforderungen durch die Tests beschrieben werden. Schon die Akzeptanzkriterien werden nicht alle Anforderungen vollständig beschreiben und die Testfälle werden nicht die Akzeptanzkriterien vollständig abdecken. Gerade bei sehr offen formulierten Akzeptanzkriterien, sind brauchbare Tests nicht immer einfach zu finden. Ein weiteren Nachteil der Testfälle ist, dass sie eine hohe Abhängigkeit zur Testumgebung haben, was bedeutet das sie ohne diese Umgebung nur begrenzt Sinn ergeben. Damit wird auch die Testumgebung mit Ihren enthalten Testdaten zu einem dauerhaften “Artefakt” des Projekts, welches persistiert und kontinuierlich gepflegt werden muss. Während der Umsetzungsphase eines Projekts ist dies meist gewährleistet, aber in den folgenden Wartungsphasen wird der dadurch entstehende Aufwand oft vergessen (und nicht betrieben).

Ergebnis

Um die Qualität von Software zu beurteilen, ist eine Dokumentation der umgesetzten Anforderungen erforderlich. Wenn man nicht durch andere externe Bedingungen (z.B. Normen oder Unternehmensrichtlinien) zu einer dokumentenlastigen Form gezwungen wird, kann meiner Meinung nach sowohl die  Menge der Akzeptanzkriterien, als auch die auf diesen basierenden Testfälle ein brauchbares Format darstellen. Dies ist aber nicht ohne Kosten, denn je nachdem, welche Form man für sein Projekt wählt, ist zusätzlicher Aufwand zu betreiben.

Wie beschreibt Ihr was eine von Euch entwickelte Software kann und was nicht?

MongoDB ist eine hochskalierbare, Dokumenten-orientierte NoSQL-Datenbank des Herstellers 10gen. Mehr Details finden Sie auf der MongoDB-Homepage: http://www.mongodb.org. Eine kurze Einleitung, die die ersten Schritte mit MongoDB erklärt, findet Sie in diesem Artikel.

Ich bin der Meinung, dass die aktuelle NoSQL-Bewegung mehr als ein Hype-Thema ist, das in wenigen Jahren wieder vergessen sein wird. Der Bedarf an hochskalierbaren, stets verfügbaren (Web-)Anwendungen steigt stetig an. Klassische relationale Datenbanksysteme stoßen dabei vermehrt an ihre Grenzen. Daher beschäftige ich mich seit einiger Zeit verstärkt mit MongoDB.

MongoDB User-Gruppe Düsseldorf

Vor kurzem habe ich eine regionale User-Gruppe zum Thema MongoDB gegründet. Ziel dieser Gruppe ist der regelmäßige Informationsaustausch zwischen MongoDB-Usern aus dem Großraum Düsseldorf (und auch gerne darüber hinaus). Wir wollen im Rahmen einer Vortragsserie unsere MongoDB-Projekte vorstellen, diskutieren und unsere Erfahrungen weitergeben. Die Homepage dieser Gruppe finden Sie unter

https://www.xing.com/net/mongodb-dus/

Ich freue mich auf neue Mitglieder und vor allem auf den Erfahrungsaustausch.

Die Folien findet Ihr hier:

Fallstricke im agilen Anforderungsmanagement

Während meines Vortrages und auch bei denjenigen Vorträgen, denen ich beiwohnen konnte, hat sich mir der Eindruck aufgedrängt, dass gar nicht wenige Teilnehmer eine regelrechte Aversion gegen agile Methoden haben. Dies äußerte sich durch lautstarken Beifall, wenn ein Redner etwas gegen “Agil” sagte und andersherum vernehmliche Unmutsäußerungen, wenn agile Methoden “zu gut” wegkommen. (Siehe z.B. den aktuellen Chaos Report der Standish Group, erreichbar über Mike Cohn’s Blog  http://blog.mountaingoatsoftware.com/agile-succeeds-three-times-more-often-than-waterfall , den ich in meinem Vortrag kurz angesprochen habe.)

Nun befinden wir uns ja immerhin im Jahre 11 nach dem agilen Manifest und agile Methoden kann man nicht mehr “nur” als Trends oder seltsame Arten der Softwareentwicklung für komische Menschen/Firmen betrachten, die nicht ernst zu nehmen sind.

Wie kann es also sein, dass -zumindest für meinen Eindruck- nach wie vor derartige Vorbehalte bzgl. agilen Vorgehensweisen existieren?

Kann es vielleicht daran liegen:

• Es gibt Bedenken hinsichtlich neuen Rollen?
• Bestehende Claims werden verteidigt?
• Sind die agilen Werte und Prinzipien nicht bekannt?
• Wurden agile Vorgehensweisen halbherzig eingeführt und scheiterten?
• Will man liebgewonnene Verhaltensmuster und Arbeitsweisen nicht ändern?

Wie ist Eure Erfahrung zum Thema althergebrachtes Vorgehen vs. agile Methoden?

Bisher bei LOST JBehave

Ein kurzer Rückblick: In JBehave werden Tests in Sätzen in natürlicher Sprache verfasst, die zur Ausführungszeit auf korrespondierende Methoden abgebildet werden. Folgendes Beispiel stammt aus der JBehave Dokumentation (übersetzt):

@When("der Artikelpreis $preis ist")
@Aliases(values={"der Artikelpreis $preis beträgt"
             "der Artikelpreis $preis entspricht"}) // mehrere Aliase
public void derPreisIst(double preis) {
    // ...
}

Diese Methode wird aufgerufen, wenn in einer Test-Story eine der folgenden Zeilen steht:

• Wenn der Artikelpreis 10 ist
• Wenn der Artikelpreis 10 beträgt
• Wenn der Artikelpreis 10 entspricht

Die Bereitstellung dieser verschiedenen Formulierungen, die jeweils das identische technische Verhalten auslösen, ist für Tester aus verschiedenen Gründen von großem Vorteil. Zunächst muss sich der Autor der Tests nicht exakt an die genaue Schreibweise eines Testschritts erinnern, um die gewünschte Operation auszulösen. Diesem Problem ließe sich mit besserer Editorunterstützung begegnen, z. B. mit dem JBehave Eclipse Plugin.

Darüber hinaus – und meiner Meinung nach ist dies der wichtigere Aspekt – erlaubt es, Test-Stories zu verfassen, die sowohl einfacher zu lesen, aber auch zu schreiben sind. Eine strikte Beschränkung auf genau eine gültige Formulierung pro Testschritt reißt Testautoren tendenziell aus dem Schreibfluss.

Im oben genannten Beispiel ist die Ähnlichkeit zwischen den drei Alternativen sehr deutlich. Sie beginnen alle mit der gleichen Einleitung, gefolgt von einer Variablen $preis, sowie einem jeweils unterschiedlichen Wort am Ende.

Diese Wiederholung von Text führt zu erheblicher Unordnung im Java Source und ist eine hervorragende Quelle für später schwer zu findende Copy und Paste Fehler.

Neu: jetzt mit noch mehr Varianten

Um dem Wiederholungsproblem zu begegnen, schlug ich den JBehave Autoren eine erste Idee vor und stellte einen Patch bereit, um deren Umsetzbarkeit zu demonstrieren. Nach einer kurzen Diskussion – in deren Verlauf mir die Unzulänglichkeiten meines ersten Ansatzes klar wurden – entstand die Idee einer allgemeineren Muster-Syntax. Die Implementierung derselben habe ich als Patch zur Verfügung gestellt, und sie wird Teil des 3.6er Releases sein. Sie erlaubt das oben genannte Beispiel wie folgt zu vereinfachen:

@When("der Artikelpreis $preis {ist|beträgt|entspricht}")
public void derPreisIst(double preis) {
    // ...
}

Der Wert der @When Annotation enthält nun ein paar geschweifter Klammern, das mehrere an dieser Stelle zulässige Worte einschließt. Intern erzeugt JBehave alle Permutationen, die sich durch diese Option ergeben und behandelt sie gleichwertig, so als wären sie explizit ausformuliert. Natürlich ist diese Syntax auch in “normalen” @Alias Deklarationen möglich.

Es ist durchaus möglich, mehr als einen dieser Blöcke mit Optionen in einer Schritt-Definition mit @Given, @When oder @Then zu verwenden. Hier ein etwas komplexeres Beispiel:

@Then("{Muss|Sollte|Soll} A $x sein, {außer|es sei denn} es ist {Teil von|enthalten in} {der |}Liste $y")

Wenn man das kurz durchrechnet, ergeben sich daraus insgesamt 24 Permutationen (oder eben “Varianten”, wie sie im JBehave Sprachgebrauch Einzug gehalten haben):

• Drei mögliche Werte für das erste Klammernpaar (“Muss”, “Sollte”, “Soll”)
• Zwei mögliche Werte für das zweite Klammernpaar (“außer”, “es sei denn”)
• Zwei mögliche Werte für das dritte Klammernpaar (“Teil von”, “enthalten in”)
• Zwei mögliche Werte für das vierte Klammernpaar (“der” und ein Leerstring, womit das Wort “der” an dieser Stelle effektiv optional wird)

Diese Varianten alle einzeln in den Source zu schreiben wäre sowohl initial als auch aus Wartungssicht nicht praktikabel. Die neue, sehr prägnante Schreibweise erlaubt es hingegen, dem Entwickler das Leben deutlich zu erleichtern, und gleichzeitig den Testautoren ein großes Maß an Flexibilität einzuräumen.

Das Eclipse Plugin

Gemeinsam mit Arnauld, dem Autoren des JBehave Eclipse Plugin (Sourcecode hier), habe ich außerdem dafür gesorgt, dass im Plugin eine Snapshot Version von JBehave aufgenommen wurde, die die Varianten-Syntax unterstützt. Damit lässt sich ausprobieren, wie sich das Schreiben von Tests unter Ausnutzung des neuen Features anfühlt. Allerdings ist zu beachten, dass zur Ausführung der Testfälle derzeit noch kein JBehave Release zur Verfügung steht. Hierfür muss man sich die JBehave Quellen von GitHub clonen und selbst einen Snapshot bauen.

Sollten Sie das in der Vergangenheit (insbesondere unter Windows) schon einmal versucht haben, und dabei gescheitert sein, dürfte interessant sein zu wissen, dass das zugrundeliegende Problem dabei inzwischen behoben sein sollte.

Einsatzbereit

In den vergangenen Wochen habe ich das neue Feature in einem Kundenprojekt produktiv eingesetzt und keine Probleme festgestellt – von daher gehe ich davon aus, dass es sich um eine produktiv einsetzbare Funktion handelt. Da sich Snapshot Versionen naturgemäß häufig und ggf. deutlich unterscheiden, lässt sich daraus allerdings keine allgemeingültige Freigabe ableiten. Hier ist also Vorsicht geboten, und je nach persönlicher Einstellung oder Unternehmensvorgabe könnte es angebracht sein, für den tatsächlichen Einsatz auf das finale JBehave 3.6 Release zu warten.

Nichtsdestotrotz hoffe ich, dass dieses neue Feature Anklang finden wird. Über jede Art von Feedback würde ich mich freuen.

Update: Nur ein paar Tage nach der Veröffentlichung dieses Beitrags wurde das 3.6 Release freigegeben. Jetzt steht dem Einsatz dieses neuen Features also nichts mehr im Wege.