Je verteilter heute in Organisationen gearbeitet wird desto wichtiger ist es, sich Mechanismen zu Nutze zu machen, die sicherstellen, daß von einem Dokument nicht unterschiedliche Versionen im Umlauf sind. Die Mechanismen sind heute vielfältig, und reichen vom expliziten filebasierten Locking bis zum impliziten absatzbasierten Locking. Aber auch hier gilt wieder: Ohne Disziplin hilft die schönste Technik nichts…und schon geistern wieder unzählige Versionen ein und desselben Dokumentes per e-mail umher!

Alleine ein Dokument zu erstellen ist einfach: Man schreibt den Text, editiert ihn und speichert ihn abschließend lokal bei sich wieder ab. Wenn man weiterschreiben möchte öffnet man das Dokument wieder, editiert wieder, speichert wieder und so weiter. Gelegentlich wird das File dann noch in den Backup-Mechanismus geworfen, um für den Fall der Fälle gerüstet zu sein.

Doch eine Anforderung wird hier bereits nicht erfüllt: Verfügbarkeit einer Versionshistorie: Wie sah das File vor 1 Woche aus? War die Grafik gestern auch schon kaputt? Der alte Text klang doch irgendwie besser! Die Lösung ist einfach und wird heute immer noch häufig gebraucht: Jede abgespeicherte Version erhält als Postfix das Datum. Also z.B. Testkonzept_V2011-10-23.doc. Doch schon hier zeigt sich ein Problem: Es bedarf einer hohen Disziplin, das konsistent über alle Versionen hindurchzuhalten. Alleine, wenn das Namensschema einmal verletzt ist besteht die hohe Gefahr, daß man beim nächsten Mal mit einer alten Version weiterarbeitet!

Und dann das Problem, wenn man das Dokument zum Review jemandem schickt:: Streng genommen muß dann folgendes gelten: Man sperrt sich mental seine eigene Datei, weil man die Datei ja zum Review jemandem anderes gegeben hat. Das schlimmste, was jetzt passieren kann, ist, daß man selbst die Datei weiterverarbeitet und dann das Feedback des Reviewers gar nicht mehr umsetzen bzw. einordnen kann, weil sich die Ursprungsversion, auf die sich das Review bezieht, bereits geändert hat. Dieses Sperren wird in der IT als Locking bezeichnet. Ohne technische Hilfsmittel muß man es sich schlichtweg merken, daß man an einer Datei nicht weiterarbeiten kann. Mit entsprechenden technischen Mitteln ist’s noch einfacher: Man schickt dem Reviewer nur einen Link auf diese technische Infrastruktur, und sobald dieser das File editieren will, lockt er sich das File: Die technische Infrastruktur stellt dann sicher, daß kein anderer mehr die Datei ändern kann. Außerdem realisieren diese Infrastrukturen (als Beispiel sei hier nur Subversion aufgeführt) auch die Versionierung, d.h. sämtliche Alt-Stände sind jederzeit verfügbar.

Soweit die Theorie: In der Praxis passiert es immer wieder, daß von irgendwo Kopien als e-mail verschickt werden. Beispiel: Der Reviewer hat die Datei gelockt und schickt die überarbeitete Version als e-mail an den ursprünglichen Autor. Die technische Infrastruktur verhindert aber immer noch, daß irgendein anderer die Datei zentral ändern kann….gegen e-mail-Kopien ist allerdings auch da kein Kraut gewachsen.

Was ist der Grund dafür: Häufig ist es die fehlende Online-Verbundenheit: Wenn ich nicht online bin, habe ich keinen Zugriff auf die zentrale Locking-Infrastruktur. Wenn ich also weiß, daß ich gleich einen 2h-Flug habe und diese Datei ändern möchte, besteht das Risiko, daß ich mir eben mal eine Kopie mache, die ich dann ändere. Zwar könnte ich nach dem Landen das direkt wieder gerade ziehen, einfacher ist es meist jedoch, die Änderungen kurz als e-mail zu verteilen. Auch hier: Ein diszipliniertes Vorgehen sind anders aus!

Ein weiteres Problem ist, daß immer nur das gesamte File gelockt werden kann. Das ist aber meist gar nicht notwendig, da ich z.B. eventuell noch an der Einleitung schreibe, mein Kollege aber am Kernkonzept. Hierfür bedarf es noch modernerer Mittel. Beispiel Sharepoint und Office 2010: Die Granularität des Sperrens wird hier durch Sharepoint verfeinert: Wenn ich in einem Absatz Text ändere wird implizit dieser Absatz für mich geblockt. Ist jemand anderes zu gleichen Zeit im selben Dokument, kann er immer noch das gesamte File ausschließlich meines Absatzes ändern. Das ganze geht natürlich nur, wenn beide Parteien (können auch beliebig viele sein) online sind. Dieses Locking geschieht entgegen der oberen technischen Infrastruktur implizit, d.h. der Nutzer muß nichts mehr machen.

Ähnlich arbeitet Google-Docs: Auch hier können beliebig viele Personen an ein und demselben Dokument arbeiten…sogar im selben Absatz. Jede Änderung wird automatisch bei jedem anderen User mit nachgezogen.

Und sind damit alle Probleme gelöst? Nein, weil die Online-Notwendigkeit nicht immer erfüllt werden kann, so daß man sich vor dem Flug eben doch noch schnell einen Abzug von Google-Docs macht, der anschließend irgendwann mal ins zentrale Google-Doc zurückgespielt wird, wo allerdings schon ganz andere Änderungen durchgeführt wurden.

Also, verteiltes Arbeiten hat einige Anforderungen an eine zentrale Dokumenteninfrastruktur:

• Feingranulares Locking (implizit oder explizit)
• Offline-Verfügbarkeit mit anschließender automatischer Synchronisation
• Versionshistorie
• DISZIPLINIERTE ANWENDER….und das ist die größte Anforderung!

Für die ersten drei Anforderungen gibt es genügend Werkzeuge, auch aus dem Open-Source-Bereich. Größtes Problem ist und bleibt die vierte Anforderung: Ohne Disziplin hilft das alles nicht! Aber das sollten wir Q-Manager und Tester ja haben…oder haben Sie etwa heute schon Word-Files oder Powerpoints per e-mail verschickt?