Die Idee hierzu geht auf Erfahrungen und Anregungen aus einem räumlich zerstreuten agilen Projekt zurück. Wenn die Projektmitglieder alle in einem Raum sitzen, bekommen sie viele auch nicht fachliche Informationen der anderen Beteiligten mit. Beispielsweise dass ihr Mac abgestürzt ist oder was sie im Urlaub gemacht haben. Die für die fachliche Arbeit vermeintlich irrelevanten Informationen sind wichtig für funktionierende soziale Interaktionen. Und ohne eine funktionierende Beziehungsebene leidet auch der arbeitsrelevante Austausch und die fachliche Kooperation.
In dem besagten agilen Projekt arbeiteten die Beteiligten räumlich verteilt. Nach einer kurzen initialen Kennlernphase an einem gemeinsamen Ort gab es nur noch gelegentliche persönliche Treffen. Alles andere lief über E-Mail, Telefon und Videokonferenzen. Und es wurde fleißig gezwitschert!
Abgesehen vom Nachrichtenaustausch bei bestimmten Großereignissen ist Twitter ist eine Plattform, auf der vorwiegend persönliche, oft gar banale und für den Arbeitskontext irrelevante Informationen ausgetauscht werden. Daher wird Twitter auch vielfach gering geschätzt. Vermutlich ist es auch eher eine Plattform älterer Menschen – angeblich ist der Anteil der unter 25-Jährigen vergleichsweise gering.
Auch für den direkten Freundeskreis bedarf es wahrscheinlich Twitter nicht, da diese Personen sich öfter persönlich treffen, simsen und telefonieren. Twitter ist ein gutes Medium, um mit den Freunden und Bekannten aus der zweiten und dritten Reihe in Kontakt zu bleiben. Also solchen Personen, die man oftmals schon einige Zeit kennt, die man aber eher seltener oder nur in ganz speziellen Kontexten trifft. Hier kann Twitter helfen, mehr und vor allem kontinuierlich mitzubekommen, was der andere gerade so macht oder denkt.
Und genau diesen Effekt können sich agile Projekte zu Nutze machen, um den sozialen Kontakt zu den entfernten Kollegen zu halten. Die “Kontakttemperatur” kann gehalten werden. Diesen Effekt spüre ich jetzt auch in unserer unternehmensinternen Kommunikation. Bis zum Frühjahr dieses Jahres hatten wir oose-intern jeden Freitag von 8.15 bis 9.00 Uhr ein Jourfix veranstaltet, zu dem alle Mitarbeiter eingeladen waren und das vor allem von Trainern/Beratern, Vertriebsmitarbeitern und teilweise dem Sekretariat genutzt wurde. Auch der eine oder andere Bewerber oder Geschäftsfreund hat schon mal zugehört, um uns besser kennen zu lernen. Inhaltlich hat jeder ganz kurz erzählt, was er in der Woche gerade besonderes gemacht oder erlebt hat oder was in der nächsten Woche ansteht. Der Vertrieb hat über alle neuen Anfragen, abgegebene Angebote oder eingegangene Aufträge berichtet. In einem Unternehmen, in dem viele Mitarbeiter einen nennenswerten Teil auswärts arbeiten, ist dieser Austausch sehr wichtig, um in Kontakt zu bleiben, Verständnis für einander zu gewinnen, sich gemeinsam zu freuen oder zu ärgern usw.
Dieses Treffen haben wir aus verschiedenen Gründen abgeschafft bzw. ausgesetzt. Zeitgleich haben wir begonnen, mit Twitter zu experimentieren. In den ersten Wochen war es ein kleiner Kreis, der dann langsam wuchs, und seit kurzem haben auch die letzten Skeptiker zumindest ein Twitter-Konto und sind passive Nutzer. Für mich hat sich Twitter als eine ernstzunehmende Alternative zu dem Jourfix herausgestellt. Es hat sogar ein paar Vorteile. Es ist zeitnäher/aktueller, inhaltlich knapper aber oftmals vielfältiger, ich versäume nichts, die Tweets bleiben erhalten und sind recherchierbar. Nichtsdestoweniger fand ich das persönliche Treffen am Freitag schöner.
Und es gibt es natürlich auch ein paar Nachteile. Vor allem die Öffentlichkeit. Grundsätzlich haben alle oose-Beteiligten ein geschütztes Twitterkonto, also eines, bei dem explizit freigegeben werden muss, wer mitlesen darf. Und viele Mitarbeiter haben dann zusätzlich ein zweites öffentliches Konto. Die vertraulichen Infos gehen dann nur über die geschützten Konten – und auch dort eher mit Umschreibungen wie “der große HH-Kunde” oder “mein Lieblingskunde” etc., da wir Twitter nicht über den Weg trauen und davon ausgehen, dass unsere Konten mit krimineller Energie zu knacken wären. Um uns und unsere Kunden zu schützen, verklausulieren wir die Botschaften soweit notwendig – verstehen uns aber trotzdem.
So sehr ich das alte persönliche Treffen vermisse, so sehr möchte ich doch das interne Gezwitschere auch nicht mehr aufgeben. Sobald wir länger Erfahrungen damit haben, berichte ich vielleicht noch mal mehr.
Bernd Oestereich

   

Gemeinsam mit Conrad Bock vom NIST, James Odell, BAE Systems und MEGA habe ich bei der OMG eine Vereinfachung der UML im Bereich der Verhaltensmodellierung vorgeschlagen.
Derzeit hat die UML drei unterschiedliche Verhaltenskonzepte, deren Gemeinsamkeiten von der UML kaum berücksichtigt werden. Hierzu zählen die Aktivitäten, die Zustandsautomaten und die Interaktionen (Sequenzdiagramme). Damit ich Ihnen unseren Vorschlag blogartig kurz vorstellen kann, müssen Sie sich gut anschnallen, da ich direkt in das Metamodell der UML aufsteige.  Wenn Ihnen das zu schnell geht oder wenn Sie mehr Details erfahren möchten, können Sie hier unseren vollständigen Vorschlag inklusiver Einführung und Beispielen nachlesen.
Aktivitäten enthalten Aktionen, Zustandsautomaten Zustände und Interaktionen enthalten wieder Interaktionen. Das allgemeine Konzept, dass ein Verhalten Schritte enthält, ist nicht in der UML abstrahiert. Gleiches gilt für die Beziehung zwischen den Schritten. Aktionen werden mit Kontrollflüssen in eine Reihenfolge gebracht, Zustandsübergänge sind Transitionen und Interaktionen haben eine Ordnungsbeziehung. Das allgemeine Konzept, dass Verhalten ein anderes Verhalten als Vorgänger hat oder während eines anderen Verhaltens ausgeführt wird, ist in der UML nicht berücksichtigt.
Die folgende Abbildung zeigt das verallgemeinerte Verhaltenskonzept:

Unser Vorschlag enthält noch einige weitere Aspekte, die Sie hier nachlesen können.  Diese Ideen fließen mit in die Weiterentwicklung der UML bei der OMG ein.
oose ist direkt an der Entwicklung der UML beteiligt. Wir möchten damit die Interessen der Projekte vertreten und Ihnen erstklassige Informationen liefern. Daher haben wir auch zusätzlich noch eine eigenen Vorschlag zur Verbesserung der UML eingereicht. Sie können unsere Ideen hier finden.
Tim Weilkiens

   

Gestern erreichte mich eine Frage zum “agilen Festpreis”, wie wir ihn im APM-Buch und im Artikel über Preis- und Vertragsmodelle beschrieben haben: “Wie kann ein solches Kalkulations- und Bemessungsverfahren aussehen? Und: Eine Aufwandschätzung in Arbeitsstunden ist für uns leider nicht möglich, da wir diese Information gegenüber unserem Kunden aus kommerziellen Gründen nicht offenlegen wollen.”
Meine Antwort: Welches Bemessungsverfahren Sie nehmen ist für den agilen Festpreis nicht entscheidend. Nehmen Sie bspw. Function Points, Widget Points, Use Case Steps, LOC oder Gummibärchen (XP).
Mit Transparenz nennen Sie Ihrem Kunden den Gesamtpreis (z.B. 500.000 €) und welche Menge von Kalkulationseinheiten sie hierfür liefern (z.B. 50.000 LOC). Dann kann ihr Kunde daraus ableiten, dass Sie 10 €/LOC berechnen. Wenn Sie dann eine hinzu- oder hinausgehende Anforderung schätzen und ihm bspw. 50 LOC als Preis nennen, hat das einen Wert von 500 €.
Ohne Transparenz geht es auch, allerdings mit einer Einschränkung: Solange Sie wirklich nur bis zum Projektende den Saldo ausgleichen wollen, der Preis also wirklich fest bleibt, reicht es, wenn Sie für rein- und rausgehende Anforderungen nur die Bemessungsgröße (z.B. LOC) nennen. Sie dürfen jedoch den Gesamtumfang (50.000 LOC) nicht verraten, sonst kann Ihr Kunde nachrechnen.
Würden Sie aber den Gesamtpreis mittendrin ändern, bspw. weil ihr Kunde den Auftrag erweitern möchte, dann dürften Sie ihm nur den Preis (€), aber nicht die Bemessungsgröße (LOC) mitteilen. Sonst könnte er auch hierüber nachrechnen.
Bitte überschätzen Sie die Zählweise oder Genauigkeit des Verfahrens nicht. Wichtiger als die tatsächliche Größe und die Frage welches Verfahren Sie anwenden ist vielmehr, dass Sie dieses Verfahren während der gesamten Projektlaufzeit und für alle rein/rausgehenden Anforderungen reproduzierbar und einheitlich anwenden können. Daher funktioniert es bspw. auch mit Planning Poker (Scrum).
Sofern Sie den agilen Festpreis intransparent anwenden, braucht ihr Kunde mehr Vertrauen zu Ihnen als bei transparentem Verfahren.
Bernd Oestereich