Und wieder mal Sommer, wieder mal Hamburg, wieder mal SEACON. Diesmal mit neuer Programmstruktur: 45-Minuten-Blöcke statt unterschiedlich lange Slots. Und das dann thematisch aufgeteilt auf die Themen Projektmanagement, Geschäftsprozesse und Architektur. Bei aller Schwierigkeit, die Veranstaltungen in die Themen immer eindeutig einzuordnen – aus meiner Sicht insgesamt eine deutliche Verbesserung zu den letzten Jahren. Ein deutlicher Zuwachs bei den Teilnehmenden (in Zahlen, nicht einzeln beim Gewicht…) spricht denn auch für die Qualität der Konferenz. Offensichtlich kommt das Format an und steigt die Beliebtheit, zusammen mit dem Bekanntheitsgrad. Schwärme ich da gerade? Vielleicht ein bisschen, naja, Hamburg ist ja auch so schön, da kann ich schon mal überschwänglich werden…
Zahlen
Über 170 Teilnehmerinnen und Teilnehmer, ca. 60 Sprecherinnen und Sprecher, 14 Abkürzungen, 6 Arbeitsblöcke pro Konferenztag, 5 Leute im Fachbeirat, 3 Tracks für Fachbeiträge, 2 Tage. Und ein paar Prozente: 12 % Frauenanteil bei den Teilnehmenden, 15 % bei Vortragenden.
Für alle Pedantinnen wie mich habe ich hier die 14 Abkürzungen aus der Programmübersicht mal aufgelistet: BPMN 2.0, TDD 2.0, TDD, NoSQL, WPT, VMs, DSLs , DSDM, TOGAF, ABAP, HTML5, SOA, BPM, JPA.
Beiträge
Vorweg: Die Beiträge, die ich besucht habe, waren allesamt gut bis exzellent! Der Schnitt der interessanten Vorträge liegt für mich persönlich eh sehr hoch. Bei allen vier Konferenzen, die ich mittlerweile besucht habe, musste ich nur einmal den Raum verlassen, weil der Redner gar nicht gut war und das Thema gar nicht gut rüberbrachte. Ist aber schon länger her und deswegen sage ich hier nicht mehr, wer oder was das war. Wer’s wissen will, kann mich gern fragen (mail – zeitung.informatica-feminale(bei)web.de).
Eröffnungskeynote „Learnings und Evolution zum agilen Vorgehen am Beispiel der Entwicklung für mobile Endgeräte“
In dieser Keynote erklärte Marc Schachtel, wie bei Parship die mobilen Varianten entwickelt wurden. Unter den gelernten Schlüssen gab es auch den, wie man Dienstleister auswählt und mit Outsourcing umgehen sollte, damit man nicht dieselben Fehler macht. Vorher jedoch stand die Umstellung der Organisationsstruktur und die Teamzusammenstellung.
Am Anfang war… die weiße Mauer. Oder konkret: Das Produktmanagement war von der Softwareentwicklung getrennt. Dass das nicht so gut funktiert, könnt Ihr Euch denken. Oder habt es selbst schon leidvoll erfahren. Für die Umstellung der IT wurde also als erstes mal in den Scrumbanteams auch die Produktentwicklung positioniert. Getrennt war dann noch die Qualitätssicherung. Das allerdings sollte aus gutem Grund so sein: Damit die Gewichtung gewahrt bleibt und die Tests nicht der Entwicklung unterzuordnen. Dazu gibt es einen eigenen Fachvorgesetzten für die Qualitätssicherung. Dessen Leute sind jedoch in die einzelnen Scrumbanteams integriert.
Was die Architekturentscheidung angeht, so hat man bei Parship auch dazu etwas gelernt: „Mobile Apps gehören mit zur Anwendungsarchitektur und sind Teil des Produkts.“
Als nächstes kam die Zielvorstellung. Ein paar Ziele, und die klar fokussiert: Produkt auch für Mobilgeräte zugänglich machen, Tablets bedienen, UX vereinheitlichen (sic!) und Vertriebsweg über App Store.
Und was Outsourcing angeht, so gilt: „Lass Dir nicht alles (!) aus der Hand nehmen.“ Soll heißen: Falls Du Teile outsourcst, ist fremd entwickeln oder programmieren lassen OK, allerdings musst Du selbst die volle Mitsprache haben (das ist entscheidend) und der Code muss Dein Eigentum sein (und nicht dem Dienstleister gehören und auch nicht nur als Blackbox-Anwendung zur Verfügung stehen bzw. sichtbar sein). Tja, manches lernt sich eher schmerzlich.
Kriterien für agile Dienstleister
- agiler Vertrag – kein Festpreisfixvertrag
- nah bei – keine interkulturelle Barriere, keine langen Reisen und keine Zeitverschiebung
- am besten in der Nachbarschaft – das erhöht die persönliche Kommunikationsfrequenz ;-)
OK, das mit der Nachbarschaft war dann Zufall, keine 50 m weiter in derselben Straße jemanden zu finden, dazu braucht man schon eine extrem eng gepackte Infrastruktur wie in Hamburg. Nett ist es trotzdem.
Take away
- „Agilität ist wirklich produktiv nur dann, wenn das Unternehmen mitzieht.“ Gilt auch für Geschäftspartner!
- „Eine mobile Applikation ist keine Commodity, sondern Teil Deines Produkts.“
- „Mach nur Verträge, die Du selbst auch erfüllen kannst!“
Fazit: Guter Überblick über Vorgehen, Ideen, Hindernisse, deren Überwindung und neue Wege
„TOGAF in 45 Minuten – Enterprise Architecture Management agil und pragmatisch“
Was ist überhaupt Unternehmensarchitektur? Diese Definition gab’s gleich am Anfang: Unternehmensarchitektur = Menschen + Prozesse + IT
TOGAF bedeutet „The Open Group Architecture Framework“ und ist das, wonach es klingt: ein großes Rahmenwerk, auf Papier dick und schwer. Gut, dass das Duo von oose uns die Kernpunkte zusammengesucht hat: Von der Strategie & Vision (Stichwort: Analyse) über die Architekturkonzeption, die Konsolidierung & Migration zur Umsetzung & Anpassung. Aus Strategie & Vision leitet man „Fähigkeiten“ (Capabilities) ab, z. B. Qualitätsmanagement, Controlling oder Applikations(neu)entwicklung. Diese Fähigkeiten bewertet man in vier Kategorien (s. Spalten recht im Bild):
Später beschreibt man die Geschäftsszenarien und modelliert die Prozesse dazu. Aus den Prozessen wiederum kann man Services ableiten (Ableitungsregeln: wiederverwendbar und von 1 Person als 1 Ding in 1 Zeiteinheit machbar). Grobe Services lassen sich jetzt noch verfeinern. Irgendwann ist man so durch alles durch – und betrachtet, was man gefunden hat: Was gibt es, was kann so bleiben, was muss geändert werden (und wie)?
Am Ende der Analyse folgt die Evaluierung möglicher Lösungen. Als Kriterien dienen können z. B. das Datenmodell (es gibt eine Lücke), die Anpassbarkeit (auch eine Lücke gefunden?), die Integrationsfähigkeit und natürlich der Preis. Ist eine Lösung ausgewählt, geht es in die normale Umsetzung. TOGAF legt nah, dass das interne TOGAF-Team in regelmäßigen Architekturrunden mit gemischter Stakeholdergruppe die Steuerung der IT mit dem Management/der Geschäftsführung, mit internen ITlern und und IT-Dienstleistern zu überprüfen und ggf. zu ändern.
So lässt sich das Ziel erreichen, eine grundsolide Technologie- und Prozessstruktur für die IT-Strategie zu schaffen, den Geschäftserfolg zu stützen und die Balance zwischen Geschäftsinnovation und IT-Innovation herzustellen. TOGAF hilft so dabei, die IT an die Unternehmensstrategie anzudocken, den Überblick zu schaffen, der Komplexität beherrschen hilft, und Synergien zu nutzen.
Und wie sieht man das alles? Bei oose haben sie es auf drei Dokumentationsorte aufgeteilt: Wiki mit Verweisen auf erstellte Dokumente, Deliverables in Subversion und Modelle im Enterprise Architect.
Was ich hier im Vortrag gelernt hab, ist nicht nur, was TOGAF ist, und wie man der unzähligen Elemente Herr wird, sondern auch, dass ich bei Gelegenheit mal mit einer Heatmap arbeiten könnte…
Fazit: Gute Einführung in die Thematik
Business-Talk „Do Androids Dream of Electrik Sheep?“
Schick! Inklusive einer Live-Vorführung des Leap (s. auch Zeitungsartikel „The Leap: Spielzeug oder Zukunft?“ vom 2. Juli 2012).
Was kann unser liebes Smartphone noch alles außer telefonieren, spielen und den Fahrplan ausspucken? Peter Friese hat uns in der Mittagspause nett unterhalten. Er arbeitet als Software Engineering Consultant für Zühlke Engineering. Seine Schwerpunkte liegen auf modellgetriebener Softwareentwicklung, plattformübergreifender Entwicklung von mobilen Anwendungen sowie Eclipse als Plattform. Er ist Committer für eine Reihe von Open Source Projekten, unter anderem Xtext und Applause. Außerdem bloggt er auf www.peterfriese.de und twittert unter @peterfriese.
Und? Was kann das Telefon denn jetzt? Zum Beispiel könnte es mit der richtigen Software einen beliebigen Tisch und das eingebaute Mikro verbinden. Für Tablets gibt es das schon: Virtuelles Schlagzeug aufrufen, ein bisschen einnorden, dann los. Klopft man jetzt auf den Holztisch (nicht auf den Touchscreen!!!), erklingt zum Klopfen auch noch dieses Metalldings, das beim Schlagzeug immer Tsching macht. Achja, das ist das Crashbecken. Ka-tschoing!
Oder Gyroskope + Kalender + Busfahrplan: Das Handy merkt, wenn ich anfange zu renne. Denn ich will ja den Bus erwischen. Das Handy gibt mir dann einen Hinweis, dass ich es bei der Geschwindigkeit doch nicht mehr schaffe…
Oder so:
Fazit: Macht Spaß!
„Usability Engineering als Innovationsmethodik – die vielen Gesichter einer Schnittstellendisziplin“
Eric Fehse hat das gewichtigste Argument dafür, Usability Engineering von Beginn des Projekts an zu involvieren, geliefert: Problem genau verstehen und dann das richtige Produkt dazu entwickeln. Es hätte nur noch prominenter dargestellt werden können. Insgesamt war es um Einiges zu schnell präsentiert… manche Folien waren ratzfatz eingeblendet und dann wieder wech. Schnellsprechen schadet der Glaubwürdigkeit! Wär schade ums Thema.
Hier noch der Design-Thinking-Ansatz und das Ablaufdiagramm: Beobachten, Beschreibungen, Layout/Gerüst, Tests (mit Wiederholungen, wo nötig) …
… und raus kommt …voilá …
… die Designlösung, die die Anforderungen trifft.
Wollen wir das nicht alle? Software, die das tut, was wir brauchen? Immerhin gibt es hier einen Ansatz, der die Umsetzung in der Praxis Wert ist!
(Nein, das ist nicht neu, aber trotzdem wahr.)
Fazit: Fundiertes KnowHow, leider etwas durchgehechelt.
Pecha Kucha „Wie agil willst kannst Du sein?“
Kai Rüstmann erklärt: Agil, ja… aber
Welcome Change: Ständige Änderungen als Prinzip. Das heißt auch, immer und immer wieder zu refaktorieren. Und es erleichtert die Langlebigkeit der Produkte. Agil arbeiten heißt, auch auf Beziehungen zu achten. Zum Beispiel die zwischen Team und Kunde. Oder eher: Kunde als Teammitglied.
Verschiedene Methoden ans Unternehmen anpassen, zugeschnitten auf die Organisation: Nur dann kann’s funktionieren. Leider fallen aber oft auch die unangenehmen Teile der Methode raus. Tja. Ins Bein geschossen. So läuft’s natürlich nicht: Wo sich die Organisation ändern müsste, aber nicht will, verwässert die Methode. Was bleibt? Wenig Erfolg und schimpfen auf das agile Vorgehen.
Fazit: Mitreißend!
Pecha Kucha „Wie Sie Ihr Scrum-Team zur Verzweiflung treiben können“
Was bekommt man, wenn man sich Gesundheitsrichtlinien vornimmt, umdreht und dann sieht, was rauskommt? Diesen kurzen Vortrag. Scrumbut-Implementierung: „Wir machen Scrum, ja, aber…“ Da gibt es manchmal die paradoxe Intervention als Methode – so flexibel wie Wasser in einem Wasserfall ;-)
Was also kann man alles falsch machen?
- Plan und Ausführung trennen
- Rückmelden nur unspezifisch (wenn überhaupt)
- Aufgabenpakete vorschnüren (vage, damit man später behaupten kann, so wäre es nicht gemeint gewesen)
- Taylorismus extrem (wichtige Scrumelemente wegschneiden)
- viele gleichförmige und sich wiederholende Aufgaben für Entwickler
- Kooperation unterbinden, Teeküche abschaffen!
- Freiheitsgrade reduzieren, Mauern stützen und verstärken, Kontrolle ausweiten
- Verantwortung begrenzen, stark gegliederte Hierarchien drumherum
- zentral entscheiden durch machtvolle Linie
- Fügsamkeit durch Willkür erhöhen
- Einzelleistung feiern und in den Vordergrund rücken (da sieht das Team mal, was geht)
Und im Ernst? Übertriebener Taylorismus und unterbundene Selbstorganisation machen krank. So jedenfalls ist es auf Basis der Gesundheitsrichtlinien durchaus zu verstehen.
Pecha Kucha „SOAgil kann BPM sein“
Wie lebt eine Story? So:
Und was sollte man fragen, wenn man die Story verstehen will? Das:
Tja, und dass es neben Story Maps noch die BMP Story Maps gibt. Hmmmm, vielleicht geht da was, mal sehen.
Und irgendwann kommt dann auf einen der Entwickler der Integrationsfrosch zu, nachdem der Wartungs- und Betriebszonk schon vergeben ist. Was habe ich noch erfahren? Auf der Planungswand passen bis zum Boardende die User Storys (bzw. die komplette Story Map) für den aktuellen Sprint, rechts daneben laufen noch ein paar Karten für den nächsten Sprint. Und auf der Tür hängen die Sachen, die gar nicht mehr passen – physikalisch limitierende Übersicht.
Aber das ist ja schon der nächste Vortrag („Ein Offline-Sprint mit dem agilen Werkzeugkoffer“) …
Weitere Stichwörter hier: dotmocracy-Ideen-Karten für die Pinnwand, Cruismastree mit grünen bzw. roten Lämpchen (je nachdem, ob die Tests durchlaufen), Buildampel (je nachdem, ob der Build klappt) und Spaß gemacht hat auch das.
Fazit: Pecha Kucha lohnt immer
Open Space: „Wieviel Dokumentation braucht man in agilen Projekten?“
Was soll ich sagen? Als der Themenvorschlag kam, war ich begeistert – schließlich hatte ich mir genau die Frage auch mitgebracht. Mein eigener Vorschlag „Agile Verträge/Verhandeln: intern mit Management und extern mit Dienstleistern“ fiel mir spontan nach der Eröffnungskeynote ein, wo das kurz angerissen wurde. Leider gab es da noch nicht so viele Best Practices. Bin gespannt, ob das nächstes Jahr schon anders aussieht… Zurück zur agilen Dokumentation (ja, die gibt es! Man muss nur das agile Manifest richtig lesen):
Besonders interessant für mich: Die Tipps zu den Wiki-Erweiterungen, die aus einem undurchsuchbaren Dschungel eine semantisch geordnete Ablage machen können. Fürs MediaWiki ist das das Semantic Media Wiki, und für Confluence gibt es seit 2012 auch eine neue semantische Erweiterung. Ach ja: Das Sharepoint-Wiki ist nicht als Wiki einzuordnen. Auch sowas lernt man nebenbei beim Open-Space (hab ich’s doch gewusst)!
Auch noch interessant: Dokumentation als Teil der Definition of Done. Und sie entsteht nicht einsam am Schreibtisch der technischen Redakteurin, sondern das Team ist mit gefordert. Klar, denn woher soll die Doku sonst wissen, was während des Codens (natürlich aus gutem Grund) noch geändert wurde?
Behaviour Driven Design kann auch helfen. Nach dem Muster „Given.. when… then…“ schreibt man auf, zu welchem Zweck man etwas tut und bei welchem Ereignis man welches Ergebnis erwartet.
Was die Granularität angeht, kann eine Dreiteilung nützlich sein: Konzept (grober Ablauf), Referenz (zum Nachschlagen) und Handlungsanweisung (mit Details). Und manchmal macht es vielleicht einen Unterschied, etwas Terminologie zu nennen statt Glossar. Gucken dann Entwickler eher mal da rein?
Wer codet und Literatur zum Thema sucht, sollte mal „Clean Code“ ansehen. Darin ist das Speaking-Code-Principle beschrieben. Übrigens muss die Doku genau wie der Code immer wieder refaktoriert werden, je agiler, desto selbstverständlicher. Auch dann gibt es immer wieder veraltete Doku, klar. Genau wie es veralteten und fehlerhaften Code gibt. Die echte Welt ist eben immer noch da draußen und nicht in dem kleinen grauen Kasten vor mir.
„Akzeptanzkriterien von User Stories mit Behaviour Driven Development kann jeder!“
Merkmale des agilen Anforderungsmanagements:
- XP – eXtreme Priorisierung
- nach Geschäftswert
- Erkenntnisse aus dem letzten Sprint einbeziehen
- ggf. re-priorisieren
- Reviews
- Mehr Tests automatisieren
- Anforderung ist gleichzeitig Test
- vorher erstellen
- Direkte Kommunikation (face-to-face, „Nein! – Doch! – Nein! Ach!“)
- Ausführbare Spezifikation
- three amigos: Tester, Entwicklerin, Product Owner
- gemeinsam (in Workshops) niederschreiben
- User Story beschreiben + Akzeptanzkriterien = Szenario… Szenario… Szenario (Entwicklerteam + PO + ScrumMaster)
- Format BDD
- narrativ
- Given… when… then…
- Given: Kontext, Voraussetzungen, Inputparameter
- When: Ereignis
- Then: Ergebnis, gewünschtes Verhalten
- formuliert wie User Story (als <rolle> möchte ich <was> tun, um <was an geschäftswert> zu erreichen), nur umgedreht, Geschäftswert zuerst
- Kombi ist erlaubt (s. Codebeispiel auf dem Foto)
- Java: http://jbehave.org/
Fazit: Interessant, sollten sich die Entwickler nebenan mal ansehen
Links
Agiles Manifest: http://agilemanifesto.org
TOGAF: http://en.wikipedia.org/wiki/The_Open_Group_Architecture_Framework
Free Pacman: http://www.freepacman.org/
Klassiker Eliza http://de.wikipedia.org/wiki/ELIZA als App (to come): http://elizaapp.com
Do Androids Dream of Electric Sheep? http://en.wikipedia.org/wiki/Do_Androids_Dream_of_Electric_Sheep%3F
Blog von Peter Friese: http://www.peterfriese.de
dotmocracy: http://dotmocracy.org/sheets
Holger Koschek: http://holger.koschek.eu
Der Foerster und die Selbstorganisation: http://holger.koschek.eu/2013/05/17/der-foerster-und-die-selbstorganisation/
Noch ein Blog: http://www.denksplitter.de/
Wikis mit gescheiter Suche: http://blog.hallowelt.biz/2012/08/21/mediawiki-vs-confluence-keine-frage-der-features/
Behaviour Driven Design in Java: http://jbehave.org/
„Ein Plädoyer für haptische agile Tools“: http://blog.holisticon.de/2012/06/mit-herz-und-hand/#more-5779
Literaturtipps
- „Enterprise Architecture Management“ von Inge Hanschke (Hanser 2011)
- „Clean Code“ von Robert Martin (Prentice Hall, englisch)
- „Dokumentation in agilen Projekten“ von Andreas Rüping (dpunkt)
- „Theorie U: Von der Zukunft her führen: Prescencing als soziale Technik“ von Claus Otto Scharmer
Mehr Artikel zur SEACON 2013 gibt es
Maria
Autor: 
Leider ist das Buch nicht gut gemacht. Nicht wirklich. Schade drum. Dass Führungskräfte mit einer hohen Kompetenz beim Fragenstellen wünschenswert sind, daran zweifle ich nicht. Im Gegenteil. Der Anfang startet ganz tief drinnen in der Theorie. Erstes Thema: Was ist eigentlich eine Frage? Inklusive 
Viele Aspekte zur Teamführung sind hier kurz, aber auf den Punkt erklärt. Die Darstellung üblicher Abläufe und Probleme sowie möglicher Hindernisse ist gut. Der Abschnitt zu Konfliktpotenzialen hat mich besonders überzeugt. So kann es sinnvoll sein, einen Konflikt zu provozieren. So wird die Auseinandersetzung sichtbar und frisst sich nicht unbewusst durch die Gruppe. Ist das erfolgreich, kann man sich über gegenseitiges Verständnis, Horizonterweiterung und mehr Handlungsoptionen freuen. Und noch mehr dazu: Konflikte als wichtiger Faktor für die Zusammenarbeit, Teamtraining als ständige Aufgabe, Umgangsformen (ja, auch die!) – mit einem vorbildlichen Beispiel für ein kooperatives und leistungssteigerndes Teamprofil. Auch das Teambarometer gefällt mir; es dient dazu, das Teamklima zu ermitteln, um latente Störungen zu thematisieren oder überhaupt Änderungsbedarf festzustellen.
Da geht’s darum, mit alten Hasen „mitzulaufen“. Studis als Beobachter folgen einer Person im Berufsleben, gehen mit in Besprechungen, sind beim Telefonieren, beim Schreiben, beim Modellieren, beim Emailabarbeiten etc. dabei. Dafür muss sich zuvor ein Unternehmen finden – und natürlich einzelne Leute, denen das Verfolgtwerden nichts ausmacht.
