Die letzten Tage habe ich auf der REConf-Konferenz verbracht. Hier berichte ich über diejenigen Vorträge, die ich besucht habe. Sicher habe ich auch gute Vorträge verpasst, da immer vier Sitzungen parallel liefen.
12.03.2019
Key Note Vortrag von Gunther Dück: "Core Competence Shift Happens"
Es ist nicht so, dass Dück jedes Mal denselben Vortrag hält. Die Beispiele wechseln. Aber die Botschaft bleibt dieselbe: Fürchtet euch vor der Zukunft! Digitalisierung, Automatisierung, McDonaldisierung und Künstliche Intelligenz werden die Arbeitsplätze auffressen. Bewegt euch also, ihr Firmen, seid innovativ! Die deutschen Firmen und Regierung rügt Dück für ihre "Ambitionslosigkeit und teilnehmende Beobachtung".
Auf menschliche Berater kann man schon lange verzichten, weil sie als Flachbildschirmrückseitenberater ihre Vorschläge sowieso von einem Bildschirm ablesen, ohne sie zu verstehen. Lesen kann der Kunde auch selbst. Je mehr der Kunde Selfservice nutzt, umso deutlicher werden am Schalter ausschließlich komplexe Fragen gestellt, die den normalen Mitarbeiter überfordern.
Die drei Stufen der Kampfkunst - Shu - Ha - Ri - wendet Dück auf die Softwareentwicklung an. Shu heißt, man beherrscht alle Griffe. Auf der Stufe Ha kann man tatsächlich kämpfen. Und Ri bedeutet, dass man die Kampfkunst neu erfindet. Die Ausbildung erfolgt in der Reihenfolge Shu -> Ha -> Ri, Innovation umgekehrt: Der Meister erfindet etwas Neues, das dann anderen beigebracht und letztlich so in Einzelschritte zerlegt wird, dass auch der Mitarbeiter auf Shu-Niveau diese Arbeit ausführen kann. Shu ist Code-and-deliver, Scrum ist Ha. Dafür benötigt man darum auch ein Team, das auf diesem Niveau steht.
Im Berufsleben gibt es Hunde und Katzen. Manager sind meist Hunde: Sie lieben Meetings, Belohnungen und Kennzahlen, und lassen sich durch einen Bonus motivieren. Typische Managementtechniken wie auch die agile Softwareentwicklung gehören zur Hundekultur. ITler sind aber normalerweise Katzen. Sie machen am liebsten in Ruhe ihre Arbeit. Meetings und Belohnungen sind ihnen egal.
Der Vortrag enthält wenig konstruktive Vorschläge, aber diese konnte ich dann doch entdecken:
- Autos "in die Cloud"! Der durchschnittliche PKW hat eine Auslastung von 4%. Keine andere teure Maschine würde man so schlecht nutzen, sondern würde in die Cloud gehen. Darum muss auch für PKWs der Trend zum Mietauto oder Taxi gehen, dem "Auto in der Cloud". Spätestens wenn das selbstfahrende Auto kommt, das von Profis gewartet werden sollte, die sicherstellen, dass immer die neusten Sicherheitsupdates installiert werden. Das intelligente Auto, das keine Zusammenstöße mehr verursachen wird, kann dann ruhig aus Pappe sein. Das selbstfahrende Auto wird tatsächlich die bisher häufigsten Unfallursachen durch einen Code-Zweizeiler beseitigt: Halte die Geschwindigkeitsbeschränkung ein, halte Abstand zum Vordermann. Betrunkene und unaufmerksame Fahrzeuginsassen bereiten dann auch keine Probleme mehr.
- SpaceX baut Raketen viel billiger als die ESA. Ist das unfaires Preisdumping oder ist das Innovation?
***
David Evans: "Telling Better Stories"
Don´t be a template Zombie!
User Stories are like plastic: They are cheap, useful, everyone uses them, but they are not optimal or sustainable.
A user story describes who, what and why. The distinction between what (function) and why (business benefit) is important.
Bad user stories are:
- As a product owner... (such stories manage excuses)
- As the database, I want... (a database experiences no business benefit)
- As a user, I want to be locked out of the system after three incorrect password attempts (How hard do you really want this as a user?)
- As a stakeholder, I require the preconstruction phase of the project management plan to be completed. (This defines a non-agile process.)
Evans proposes two alternative templates:
why, who, what: In order to ... , as a ..., I want...
hypothesis-based assumptions: we believe that ... (what) for ... (who) will achieve ... (why)
How to improve your work with user stories:
Make sure that the why is not too high, but can directly be achieved by the what.
The why must not be just a rewording of the what.
There must be real user motivation.
Give each story a short title for reference. A good form is "verb + key word from the what", like "add sales tax". The verb must describe what the system does, not what the programmer does.
Use a value map to visualize the why.
Describe the current situation, because this defines what is to be done to implement the story.
Therefore, Evans proposes this new template:
in order to <improve an outcome, here use the nodes from the value map>
for <someone who matters>,
we will <new product behavior, feature or output>
whereas currently <status quo>
Blog post here: https://tinyurl.com/BetterStoriesBlog
***
Magali Balaud: Wie die Einbindung von Kunden Feedback zu besserer Software Entwicklung beitragen kann: Eine Startup Perspektive
Ohne den Begriff zu verwenden, werden hier ein Vorgehen und Techniken aus Lean Startup dargestellt. Beschrieben wird der Fall eines Startups mit der Idee, in Ostafrika Produkte aus realen Läden in sozialen Netzwerken durch einen Chatbot zu verkaufen, insbesondere Kleidung. Folgende Techniken wurden anhand dieses Beispiels vorgestellt:
- Ein Benutzerinterview, um einen Prototypen zu evaluieren. Tipps für eine gute Interviewdurchführung wurden gegeben.
- Wizard of Oz Prototyp des Chatbots, wobei die Antworten nicht von einer Maschine, sondern im Prototypen noch von einem Menschen gegeben werden.
- Personas
- Analyse der User Journey auf vier Ebenen: Aktion, Gefühl, Problem, Bedarf.
***
M. Junker und D. Freudenstein: SpecMate - Auf Knopfdruck von Anforderungen zu Tests
Aus Anforderungen sollen oft Tests hergeleitet werden. Dabei treten diverse Probleme auf:
- Änderungen von Anforderungen
- Anforderungen sind unverständlich
- Die Testerstellung ist aufwändig
- fehlende Werkzeugunterstützung für das Testdesign
Die Lösung: eine gemeinsame Sprache für Anforderungen und Test.
Das Tool dafür ist SpecMate von Qualicen, das systematisch Testfälle aus Spezifikationen herleitet und für Testabdeckung sorgt.
Aus textuellen Anforderungen (z.B. Regeln) wird ein Modell erstellt (z.B. Ursache-Wirkungs-Graph oder Aktivitätsdiagramm), daraus eine Testfallspezifikation (z.B. als Entscheidungstabelle mit Input und Output) und daraus eine Testprozedur.
Es wurde auch schon getestet, ob aus textuellen Anforderungen automatisiert Modelle generiert werden können. 78% dieser Testfälle konnten mit wenigen (1-2) Änderungen so verwendet werden.
SpecMate ist Open Source.
https://www.qualicen.de/blog/?p=503
***
Uwe Valentini: "Fehler sind die Meilensteine auf dem Weg zum Erfolg" (Key Note)
Im Vergleich der Luftfahrt mit der Medizin zeigt sich schnell, dass sie sich massiv in ihrem Umgang mit Fehlern unterscheiden. In der Luftfahrt werden Unfälle durch Blackboxen protokolliert und später detailliert ausgewertet. Anschließend werden die Prozesse verbessert, damit derselbe Fehler nicht erneut auftritt. In der Medizin gibt es keine solche Fehlerkultur, mit der Folge, dass hier ständig Menschen unnötig sterben. Eine solche Fehlerkultur würde der Informatik auch gut tun.
***
Kim Lauenroth: "Beyond RE is Digital Design"
Die Digitalisierung verläuft in drei Phasen:
1.) digitization: Daten werden in digitale Formate überführt.
2.) digitalisation: Prozesse werden digital.
3.) digital transformation: digitale Geschäftsmodelle.
Requirements Engineering wurde in der ersten Phase erfunden und ist nun angeblich nicht mehr zeitgemäß für das, was kommt. Stattdessen wird Digital Design bzw. Digital Engineering nötig. Darum wird das IREB diesen Herbst ein neues Zertifikat als Digital Design Professional herausbringen. Auch Advanced Levels sind angedacht.
Gut gefallen hat mir dieses Zitat: "Software wird schneller hart als Beton."
www.digital-design-manifest.de
www.digitaldesign.org
***
13.03.2019
Ursula Meseberg: Beyond Agile RE: Der Business Agilität den Weg bereiten
Während am Abend zuvor der Beruf des Requirements Engineers durch den Digital Designer ersetzt wurde, wurde in dieser Key Note am Morgen der Beruf des Business Analysten durch den Digital Business Analyst ersetzt, der an die agile Welt angepasst ist. Da die Digitalisierung die bisherigen Wertschöpfungsmodelle auf den Kopf stellt, muss dies auch genauso revolutionäre Folgen für die Geschäftsprozessanalyse haben.
***
Michael Jastram: "Entwicklungsmuster für den Umgang mit Änderungen"
Änderungen sind normal und zu erwarten. Als Beispiel nannte Jastram IoT. Hier haben nur 4% die Sicherheit bereits eingebaut. Alle anderen werden sich also ändern müssen.
In diesem Vortrag ging es um Prozessmuster für das Änderungsmanagement. Diese Muster (Patterns) bringen das zusammen, was für Änderungen nötig ist: Menschen, Prozesse / Methoden und Tools.
Ein Pattern hat folgende Inhalte:
- intend
- also known as
- motivation
- applicability
- structure
- consequences: benefits and liabilities
- implementation
- related patterns
Konkret vorgestellt wurde das Beispiel-Muster "Branche and Merge".
Bisher hat die Datenbank 20 Patterns in vier Kategorien: structural, quality, process, change management.
https://se-trends.de/umgang-mit-aenderungen/
***
Andreas Vogelsang: Requirements Engineering for Machine Learning
In der traditionellen Softwareentwicklung werden Algorithmen spezifiziert und implementiert. Diese werden zuvor durch das Requirements Engineering beschrieben. Im Machine Learning funktioniert das anders.
Bei Klassifizierungsalgorithmen gibt es vier Fälle bei den Ergebnissen zu unterscheiden: true positives, false positives, true negatives, false negatives. Mit Hilfe der Kenngrößen accuracy, precision und recall kann die Qualität der KI gemessen werden. Je nach Anwendung kann es wichtiger sein, dass recall hoch ist oder precision. Je nachdem, welcher Schaden durch einen Irrtum entsteht. Hinzu kommen als weitere Qualitätsanforderungen an die KI:
- freedom of discrimination
- explainability
- accessibility
- confidentiality
***
Weitere Vortragszusammenfassungen finden Sie bei Kollege Nikolaas Döbel hier:
https://anforderungsbuero.de/expedition-reconf-2019/
