0

UML als Kommunikationsmittel

Ich habe in den letzten Wochen die UML als Kommunikationsmittel für mich entdeckt. Angefangen mit Activity Diagramme, die ich in Visio gezeichnet habe, über Use Case und Sequence Diagramme.
Ich rede an dieser Stelle aber nicht von UML als Modellierungssprache um daraus fertigen Code zu generieren oder gar erweiterte Ansätze wie MDD/MDA. Ich spreche von der UML als Mittel zur Kommunikation mit Stakeholdern oder Entwicklern.

Für mich der derzeit wichtigste Diagramm-Typ ist das Activity Diagramm. Das nutze ich zur Prozesserhebung und Modellierung. Es ist zwar komplexer als beispielsweise ein Sequence Diagramm, allerdings bietet es die Möglichkeit alternative Szenarien im Ablauf darzustellen. Diese Diagramme zeichne ich mit dem altbekannten Microsoft Visio. Allerdings nutze ich nicht die mitgelieferten Stencils, sondern die von Pavel Hruby, welche sich für das einfache Zeichnen ohne Validieren besser eignen. Zudem unterstützen diese Stencils die UML 2.2 und sind für alle gängigen Visio Versionen frei erhältlich.

Für die Sequence Diagramme nutze ich die Webanwendung Websequencediagrams.com. Ich habe bisher noch kein einfacheres Tool gefunden, um diese Art von Diagrammen zu erstellen. Besonders gefällt mir die Möglichkeit den Style einzustellen.  Für diejenigen, die weitere UML-Diagramme online erzeugen möchten, bietet sich die Website yuml.me an. Dort kann man neben Use Case Diagrammen auch Class- und Activity Diagramme erzeugen.  Alle Schaubilder können mittels URL in Webseiten, Wikis und Blogs eingebunden werden, was den einfachen Sketching und Kommunikations-Charakter unterstreicht.

So kann man mit diesen einfachen grafischen Methoden das Productbacklog detaillieren und User Stories für die einzelnen Sprints vorbereiten.

0

Gemischte Serviceteams.

lego-people

Ich habe mich während der Weihnachtsferien ein wenig mit dem Groovy Framework Grails auseinander gesetzt und bin positiv überrascht. Ich war auf der Suche nach einer einfachen Möglichkeit RESTful Webservices an einem Beispiel darzustellen und Grails war hier das Tool der Wahl. Das bringt mich aber zu meinem eigentlichen Thema nämlich die Wahl der Technik.

In der IT wird häufig noch strategisch vorgegeben welche Technologie eingesetzt wird. Sei es die Programmiersprache, das Framework, der Anwendungsserver oder die Datenbank. Gründe dafür sind häufig die Lizenzkosten, das vorhandene know-how oder einfach der Einfluss der „grauen Eminenzen“. Die Betroffenen wissen meist, dass es einen „besseren Weg“ gibt den Job zu erledigen, der sich aber nicht so gut in das Gesamtkonstrukt einfügt. Das Ergebnis ist zumeist ein frustriertes Entwicklungs- oder Administrationsteam.
Eine Lösung könnte der Blick auf das seit Mitte Oktober 2009 existierende SOA Manifesto sein. Insbesondere die ersten drei Punkte halte ich in diesem Zusammenhang für nennenswert:

  • Geschäftswert über technische Strategie
  • Strategische Ziele über projektspezifischen Nutzen
  • Immanente Interoperabilität über maßgeschneiderte Integration

Das schreit doch gerade danach das beste Tool für den Job einzusetzen. Wenn es da nicht die unterschiedlichen Bereiche für einen Softwaresystem gäbe. Nämlich die Entwickler auf der einen Seite und die Administratoren auf der anderen. Es liegt in der Natur der Sache, dass der Admin ein gehöriges Wort bei der Technologie mitreden möchte, wird er doch in der Nacht aus dem Bett geklingelt. Ein konservatives Vorgehen ist hier also angebracht. Die Entwickler hingegen möchten natürlich die neusten Frameworks oder sonstigen Technologien einsetzen, damit sie ihre Arbeit effektiver erledigen können. Allerdings liegt aus meiner Sicht genau hier das Problem. Durch die Aufteilung in Entwicklung und Betrieb verfolgt man nicht den ganzheitlichen Ansatz. Gilt es doch eine Software zu erstellen und zu betreiben, die einen Geschäftswert erzielt – einen Service also.

Warum sollten dann nicht auch gemischte Teams, die für die Entwicklung und den Betrieb von Services zuständig sind, sich auch das beste Tool aussuchen dürfen? Diese spezialisierten Einheiten könnten sich die Programmiersprache, den Anwendungsserver oder die Datenbank frei aussuchen und damit vermutlich effektiver arbeiten. In großen Unternehmen wie beispielsweise Amazon wird das so praktiziert. Die kleinen Einheiten sind dort für die Entwicklung und den Betrieb zuständig und dabei nicht an bestimmte Infrastruktur gebunden – außer der Amazon EC2 (Elastic Compute Cloud).

Und wenn man den SOA-Gedanken noch nicht für tot hält, dann ist das sicherlich ein Schritt in die richtige Richtung.

0

SCRUM und Kanban bei Xing

Ich habe seit längerem bereits keine Beiträge mehr verfasst. Das soll sich nun wieder ändern. Allerdings steige ich hier nur mit einem Verweis auf eine Präsentation von Xing ein, die Traian Kaiser und Mark Weber zum SCRUM Day 2009 vorgestellt haben.  Der Informationsgehalt ist ohne Tonspur nicht allzu groß, aber sehenswert ist sie dennoch.

3

Scrum – ein Erfahrungsbericht von Xing

Auf dem Xing Blog habe ich drei Artikel gefunden, in denen Traian Kaiser über die Einführung von Scrum berichtet.
Hintergrund dabei ist natürlich, die damit verbundene Möglichkeit, Kundenwünsche zeitnah umzusetzen und die Ship It!-Strategie besser verfolgen zu können.

Das größte Hindernis bei der Einführung von Scrum bestand wohl darin, die agilen Werte richtig zu kommunizieren und die neuen Rollen den vorherrschenden Jobbeschreibungen zuzuordnen.

Das benötigte Wissen haben die Projektmanager und einige Lead Engineers durch Scrum-Trainings erhalten.  Traian Kaiser beschreibt weiter, dass die Prozesse im Unternehmen und der Ablauf der Produktentwicklung  angepasst werden mussten – sich die Umstellung aber  insgesamt gelohnt hat, und sie nun für die Zukunft gerüstet sind.

So kann also eine Scum-Einführung in einem Unternehmen aussehen.  Die beschriebenen Hindernisse, wie das Verinnerlichen der agilen Werte, ist sicherlich eine der größten Herausforderungen für ein Unternehmen, welches nach Scrum arbeiten möchte.  Ich habe die Erfahrung gemacht, dass es tatsächlich schwierig ist Scum in Reinform anzuwenden.  Daher bediene ich mich vereinzelter Konzepte von Scrum und nenne es Scrumish ;-)

Die Artikel sind alle mal lesenswert und zeigen, dass es nicht so einfach ist, Scrum unternehmensweit einzuführen.