Software Engineering Blog

Vor ein paar Tagen habe ich ja schon einmal den Vortrag von Alan Atlas über die Einführung von Scrum bei Amazon berichtet, über die der bei ImmobilienScout24 gesprochen hat.

Marion Eickmann von agile42 hat Altas kurz danach zum Berliner Scrumtisch eingeladen und das auch in ihrem Blog mit Fotos dokumentiert. Aus dem Blog heraus kann man auch die Präsentation herunterladen.

Isabel Drost hat sich die Zeit genommen und Atlas' Vortrag in Ihren Blog ausführlich dokumentiert.

Alexander Kriegisch von Scrum-Master.de hat dem "Scrum on a Page" von William c. Wake aktualisiert und über seine Homepage uns allen zur Verfügung gestellt.

Scrum-On-A-Page faßt kurz für den täglichen Gebrauch die Scrum-Rollen, den Prozess und die wichtigsten Inhalte der Meetings und die Scrum-Artefakte zusammen.

Hier geht es zum Download...

Für alle aus dem Raum Berlin und an Scrum-Interessierte dürfte interessant sein, daß die OOSE im nächsten Jahr auch ein Scrum-Master-Seminar mit der Möglichkeit zur Zertifizierung in Berlin durchführt. Für mich auf jeden Fall die Gelegenheit, mich als Scrum Master zertifizieren zu lassen, ohne nach Hamburg zu fahren. Eigentlich aber auch schade.

Hier geht es zur Anmeldung für das Berliner Seminar.

Im Sophisten-Blog hat Alexander Lindner einen Tipp veröffentlicht, wie Aktionen in Entscheidungstabellen leicht zu referenzieren sind. Die Idee ist ziemlich gut. Hier geht es zum Blog-Eintrag.

Probleme treten oft an unerwarteten Stellen auf. Ursache hierfür ist nur zu oft unser eigenes Wissen oder Können. Dinge die wir nach unserem Wissen „richtig“ angehen, Standards, die wir unbewußt einhalten, weil wir sie verinnerlicht haben, setzen wir auch stillschweigend bei anderen voraus.

Ein kleines Beispiel: In einem Projekt hatte ich die Leitung für ein russisches Outsourcing-Projekt in dem win Wissensmanagementsystem für einen deutschen Automobilbauer umzusetzen war. Die Spezifikation wurde von unserem deutschen Partner erstellt, während wir für die reine Umsetzung uns verantwortlich zeichneten. Da unserem Partner die personellen Ressourcen für die Spezifikation fehlten wurde auf externe Beraterressourcen für dieses Projekt zugegriffen. Schnell wurde klar, daß dies das erste Spezifikationsprojekt des eingestellten Beraters war.

Da wir die Thematik schon aus einem Vorgängerprojekt kannten, war dies nicht allzu schwerwiegend. Vieles wußten wir aus dem Kontext und die Architektur wurde fest durch ein Framework des Kunden vorgegeben. Nur die Use Cases keine stabile Bezeichnung hatten, das machte uns das Leben schwer, da wir unsere Arbeitspakete auf Basis der Use Cases zusammenstellten. Ein Arbeitsauftrag war bei uns beispielsweise die Umsetzung der Anwendungsfälle „Projekt anlegen“, „Projekt bearbeiten“ und „Projekt freigeben“. Nur konnte sich die Benennung der Anwendungsfälle auch ändern und tat dies auch. Dies sollte eigentlich auch kein Problem sein, wenn es für jeden Anwendungsfall eine eindeutige Nummer gibt wie beispielsweise UC-223, nur wurden die Use Cases anfangs über die Kapitelnummern identifiziert. Sie ahnen es sicherlich schon. Sobald ein neues Kapitel in das (Word-)Dokument eingefügt wurde, änderten sich natürlich auch die Kapitelüberschriften und damit konnte über die Zeit Uses Case 3.2.2 unterschiedliche Anwendungsfälle beschreiben. Später wurde dies auch geändert, doch war dies auch ein langwieriger Prozess.

Was kann man daraus lernen:

• Setze nie voraus, daß Dein Gegenüber über das gleiche Wissen verfügt wie Du, sondern schaffe eine gemeinsame Wissensbasis.
• Halte Anwendungsfallbezeichner immer stabil und ändere sie nie. Sie bilden in anwendungsbezogenen Projekten eine Grundlage für die Kommunikation zwischen allen Beteiligten.

Bei Gelegenheit schreibe ich etwas darüber, wie eine Use Case-ID gebildet werden kann und wie mit man mit ihnen umgehen sollte.

Bei der Durchsicht meiner Mails bin ich auf den letzten JavaBlackBelt-Newsletter gestoßen. War bisher nur der Gelbe Gürtel ohne eigenen Beitrag zur Sammlung von Prüfungsfragen zu erreichen, kann jetzt der Grüne Gürtel erreicht werden. Für die nächst höheren Gürtel müssen Mitglieder aber weiterhin neue Beiträge zur Fragensammlung leisten.
(weiterlesen...)

Bei der Erhebung von Anforderungen kommt man immer wieder mit den sogenannten Stakeholdern in Berührung, die neuerdings eingedeutscht auch Hutträger genannt werden. Beim Umgang mit diesen Stakeholdern gilt es immer, deren Interesse zuberücksichtigen, also herauszufinden, welche Anforderungen an unsere Software gestellt werden.

Interesse dabei ist ein Begriff, der umgangssprachlich viel eingesetzt wird, jedoch selten bewußt hinterfragt wird.

Sprachlich gesehen leitet sich Interesse wie viele Fremdwörter aus dem lat. Verb „interesse“ ab, welches für an etwas teilnehmen steht. Später wird es im römischen Schadensrecht als Terminus eingeführt und erlebt später im Mittelalter als Wort für Nutzen, Vorteil und Gewinn verwendet eine Renaissance. Klar tritt dies auch heute noch im englischen Wort für Zinsen hervor. Überprüfen Sie das doch mal mit Hilfe von Leo...

Steht am Anfang eines Projekte die Erhebung von Anforderungen, müssen diese oft mühsam bei den Stakeholdern einholt werden. Die meisten Anforderungen, die bei der Erstellung von Software umsetzen werden müssen, sind direkt oder indirekt auf die Interessen der beteiligten Stakeholder zurückzuführen. Die Geschäftsführung braucht unsere Software, um ihre Produkte besser vermarkten zu können. Der Sachbearbeiter Krüger möchte schnell wichtige Daten wiederfinden, am besten genauso wie auf dem Excel-Sheet, daß er in den letzten Jahren erstellt hat und der Abteilungsleiter Herr Pachulke muß bei jeder Besprechung dabei sein. Dabei erscheinen bestimmte Anforderungen oder Verhaltensweisen auf den ersten Blick nicht sinnvoll oder die Konsequenz mit der auf bestimmte Forderungen bestanden wird, erschwert den Ausgleich zwischen unterschiedlichen Anforderungen. Hier ist es hilfreich zu wissen, welche drei Dimensionen der Begriff Interesse besitzt:

1. Individuelle Dimension
2. Materielle Dimension
3. Ideele Dimension

Die individuelle Dimension umfaßt unsere Antriebe und Bedürfnisse, wie beispielsweise nach Zuwendung, Anderkennung und Stolz sowie Orientierung. Die materielle Dimension umfaßt alles, was auch die Erzielung von Nutzen - oder anders gesagt Mehrwert - ausgerichtet ist. Die dritte Dimension geht darüber hinaus und zielt auf rein inmaterielle Punkte wie Ideologien und Rechtfertigungen ab, mit denen wir unser Handeln und Tun rechtfertigen.

Mit diesem Wissen gewappnet, kehren wir noch einmal zu unserem kleinen Einführungsbeispiel zurück und versuchen alle Stakeholder, zugegeben vereinfacht, in eine der drei Dimensionen einzuordnen: Die Geschäftsführung hat eindeutig materielle Interessen. Unsere Software soll helfen, den Umsatz des Unternehmens sicherzustellen, weshalb ihre Interessen der materiellen Dimension zuzuordnen sind. Herr Krüger besteht auf einen Maskenaufbau analog zu seinem Excel-Sheet. Er ist überzeugt, in den letzten Jahren den optimalen Aufbau mit allen wichtigen Anforderungen gefunden zu haben. Hier sind wir in der ideelen Dimension, sein Excel-Sheet spiegelt seine Sicht der Dinge wieder. Abteilungsleiter Pachulke ist in jeder Sitzung anwesend, um seinen Status in der Firma zu sichern, auch wenn seine Anwesendheit eigentlich nicht erforderlich ist.

Versuchen Sie doch einmal mit Hilfe dieser Dreiteilung ein aktuelles Problem aus ihrem Projektumfeld einzuordnen. Vielleicht findet sich ja darüber eine Lösung.