#knowledge-management

How to: How do you keep track of applications for specific purposes #answer #dev #fix

How do you keep track of applications for specific purposes

I tend to have a handful of ‘core’ applications that cover most of what i need. On the other hand, there tend to be some programmes that i need once in a blue moon, and i’m finding that i’m forgetting what they are. At one point i had a wiki for it, but i’m curious how other people handle the problem.

So, what’s the means that you use…

Und diesmal ist auch wirklich der Weg das Ziel: Learning-Logs für agile Softwareentwicklungsteams

Oder:  Wozu noch man Prototypen noch nutzen kann

Letzte Woche meldete sich eine Freundin bei uns. Sie und ihr Team haben von einem Kunden den Auftrag bekommen, einen Prototyp zu programmieren. So weit so gut, möge man denken, das Ziel des Prototyps wäre Technologien gegeneinander abzuwägen, Usability-Patterns zu testen oder eine Architektur zu evaluieren. Weit gefehlt. Bei diesem Projekt ist nicht der Code oder das Ergebnis das Ziel.

Die Erfahrungen, die auf dem Weg zum Prototyp liegen, sind das Ziel.

Nicht der Prototyp selbst, nicht die Software wird gewünscht, sondern die Erfahrungen, Lessons-Learned und Best-Practices, die auf dem Weg zu diesem Prototyp gesammelt wurden. Der Kunde wünscht sich am Ende des Projektes einen Erfahrungsschatz. 

Wie setzt man dieses Projektziel um ? Zunächst einmal stellt man sich die Frage, was den nun konkret gewünscht ist und erarbeitet werden soll. 

Was ist ein Erfahrungsschatz und wie wird ein solcher am Ende eines Projektes übergeben ?

Spannend verpackt in einer Kiste mit goldenen Beschlägen, vergraben unter tausend Jahren alten Bäumen und markiert  auf einer Karte, der man Schritt für Schritt folgen kann ?

So ähnlich. Wie in jedem guten Projekt hat der Auftraggeber die Erwartungshaltung und den Anspruch auf ein ordentliches Ergebnis: in diesem Fall eine saubere und gut strukturierte Dokumentation der Inhalte und Ergebnisse. Was aber sind die Inhalte und Ergebnisse ? 

Wie sich zeigt, kann die Vorgehensweise des Continous-Knowledge-Exchange (siehe unseren Artikel "Brainsharing" in der iX, Mai 2011) weiterhelfen:

Schritt 1: Definiere das Ziel.

Ok, es soll ein Prototyp gebaut werden. Aber für was ? Um Erfahrungen zu sammeln und diese zu dokumentieren. So weit so gut, aber tatsächlich sind wir noch sehr schwammig unterwegs. Meist legen die Projektmitglieder halbblind vor Begeisterung für neue Technologien und der Aussicht auf eine prototypische Spielwiese ohne große Reflektion sofort los. Weil man ja weiß, wie es geht und es dem Kunden nur noch vorführen muss, wie in einer Theateraufführung.

Einen Schritt zurück. Wir müssen sicherstellen, das wir den Kunden nicht in das falsche Theaterstück setzen: Das Ziel muss klar definiert sein. Hierzu ist es notwendig, sich mit dem Kunden vorab über das gewünschte Ergebnis auszutauschen. In den meisten Fällen kennt der Kunde das Ergebnis auch nicht, deshalb sind erste Vorschläge gefragt. Eventuell ist ein Workshop zur Zieldefinition notwendig (i.d.R. sind 2 Stunden ausreichend, sehr viel weniger sollten es aber auch nicht sein).

Dabei müssen mindestens folgende Fragen geklärt werden:

- Wie sollen die gesammelten Erfahrungen dargestellt werden ?

- In welcher Form liefern wir das Projektergebnis (Word, Wiki, PlainText, PowerPoint, ...)

- Gibt es Bereiche, die besonders wichtig sind und fokussiert betrachtet werden sollte (Backend vs. Frontend, evtl. bestimmte Technologien oder Entwicklungsmethodiken wie agile Vorgehensweise) ?

- In welcher Form sollen sie strukturiert werden (falls eine erste grobe Strukturierung bereits gewünscht ist) ?

- Wer sind die Wissensträger, die beteiligt werden müssen ?

- Welche Erfahrungen wurden bereits in der Vergangenheit gemacht und sind diese relevant ?

- Welche Projektmitglieder müssen sollen eingebunden werden (nicht zu viele, evtl. reicht es aus einige lediglich initial zu konsultieren und um ihre Meinung zu bitten)

und ... die Mutter aller Fragen bei der Zieldefinition:

- Welche Entscheidungen will der Kunde auf Basis des gewonnenen Erfahrungsschatzes in Zukunft treffen können ?

Die Antwort auf diese Frage schließt Sätze des Kunden die mit "jetzt weiß ich aber immer noch nicht ... " beginnen aus und deshalb muss sie vor dem Start des Projektes glasklar definiert werden. Am besten: niederschreiben und an die Wand hängen.

Schritt 2: Iteratives Einsammeln des Erfahrungsschatzes

Jetzt erst beginnt der Entwurf und die Entwicklung des Prototyps und damit das Einsammeln des Erfahrungsschatzes.

Ein Erfahrungsschatz ist eine Sammlung von Erfahrungen, Lessons-Learned und Best-Practices.

Dieser Erfahrungsschatz wird während der Entwicklungsphase in der zeitlichen Reihenfolge des Auftretens niedergeschrieben.

Wichtig ist es, gelerntes so schnell als möglich zu erfassen, bevor das Wissen verloren geht. Vor allem in einem Umfeld, in dem neue Technologien zum ersten Mal erprobt werden, ist die Menge an neuen Erfahrung sehr groß und die Gefahr des Verlorengehens ebenso. Deshalb: 

Alles sofort aufschreiben ("Capture knowledge before it gets lost").

Dabei ist es unerheblich, dass das Wissen noch nicht in einer "reinen" und finalen Version vorliegt. Sammeln ist wichtiger als aufbereiten (das kommt später). Sammeln ist wichtiger als strukturieren (auch das kommt später). Zunächst muss sichergestellt werden, dass nichts verloren geht.

Kontinuierlicher Austausch zwischen Projektmitgliedern und iterative Verfeinerungen

Bereits während der Iteration des Sammelns tauschen sich die Mitglieder des Projektes regelmäßig ihre Erfahrungen aus. Auf Basis der erfassten und noch "rohen" Wissenseinheiten wird das gesammelte Wissen verdichtet, doppelte Einheiten werden aussortiert, Unklarheiten geklärt. Dieser Austausch dient auch dazu, die Priorität einer Wissenseinheit festzulegen. Ist das eben gelernte wirklich wichtig für den Kunden und sein gewünschtes Ziel ? Was einem selbst wichtig erscheint, ist im Licht des Kundenwunsches plötzlich nichtig und klein. Für die Erreichung dieser Sichtweise ist die Reflektion der Projektmitglieder gefragt und notwendig. Es geht nicht ohne.

In diesen Austauschen entstehen auch erste Ideen für eine Kategorisierung. Vorschläge für die Kategorien werden an Wissenseinheiten angeheftet. Diese Kategorisierung muss nicht final sein und wird sich weiterentwickeln (wir arbeiten iterativ !).

Wichtig ist, dass der tägliche Austausch über das vorher Gelernte täglich stattfindet.

Der Austausch kann kurz sein und sollte ähnlich einem Standup bei Scrum verlaufen (i.d.R aber länger, bis zu einer Stunde sind einzuplanen). Wichtig ist, dass direkt im Anschluss die bisher erfassten Wissenseinheiten bereinigt, angereichert, korrigiert, ergänzt oder kategorisiert werden. Nur dann sind die Eindrücke aus den Austauschen noch frisch vorhanden sind. Jedes Projektmitglied korrigiert seine eigenen Wissenseinheiten.

Schritt 2.2 findet solange im Wechsel mit Schritt 2.1 statt, bis das mit dem Kunden vereinbarte Ziel erreicht ist. Dies ist nicht notwendigerweise die Fertigstellung des Prototypen maßgeblich, evtl. kann das Ziel dies bereits vorher erreicht sein.

Schritt 3: Dokumentation der Ergebnisse

Meine Damen und Herren, wir verlassen nun unsere iterativen Loopings und setzen zum Landeanflug an.

In diesem Schritt wird aus den gesammelten Wissenseinheiten und Lessons-Learned ein "Enddokument" erstellt. 

Im Unterschied zu den Phasen vorher wird dieses durch einige wenige (i.d.R. nicht mehr als zwei) Personen verfasst. 

Es ist Pflicht, dass diese Personen auch bei der Sammlung des Wissens aktiv dabei waren, da sonst die Reibungsverluste zu groß sind.

Die Dokumentation soll den Wünschen, Ansprüchen und formalen Aspekten (Templates, Logos) des Kunden entsprechen.

Diese Phase stellt das reine "Zusammenschreiben" dar, eine Anreicherung des Wissens ist hier nicht mehr vorgesehen, da dies in Phase 2 geschehen ist. Die in den Schritten vorher angelegte Kategorisierung kann als Maßgabe für die Kapitel des Dokumentes dienen. 

Learning-Logs als fester Bestandteil des Entwickleralltags

Learning-Logs können nicht nur bei der Entwicklung von Prototypen erstellt werden, sie können in den Alltag eines Entwicklungsteams integriert werden. Jeder Entwickler sucht und findet Lösungen zu Problemen, behebt Fehler und lernt neue Technologien, Tools oder Vorgehensweisen kennen.

Learning-Logs sollten fester Bestandteil eines jeden Entwicklungsteams werden.

Stefan Wendel we:namix GmbH

Nicht ganz ohne Stolz hier die Vorankündigung auf die morgen erscheinenden aktuelle Ausgabe der iX (Ausgabe Mai 2011).

Unter dem Titel "Brainsharing" wird der Prozess des kontinuierlichen Wissenstransfers dargestellt. Vielen Dank an die Redakteure und Mitarbeiter des Heise-Verlages für die Erstellung der gelungenden Grafiken und letztendlich für die Idee des "Brainsharing"-Titels.

Eine Online-Version kann unter

http://www.wisdomclouds.com/artikel

eingesehen werden. Wir bitten um Verständnis, dass dieser Artikel aus Copyright-Gründen nicht heruntergeladen, sondern lediglich ausgedruckt werden kann.

Kritik, Fragen, Anregungen, Meinungen zu diesem Thema ? Wir stehen gerne für eine Diskussion zur Verfügung:

stefan [a t] wisdomclouds.com

Viel Spass beim Lesen!