Vierter JUG Saxony Day

Ich war heute auf dem JUG Saxony Day in Dresden. Ach ich hab jetzt gar keine gro├če Lust viel zu schreiben:

WAR SUPER und HAT SICH GELOHNT! ­čÖé

Mein pers├Ânliches Highlight war der Vortrag “Rundungsfehler” von Michael Wiedeking aber auch bei “├ťber den bewussten Umgang mit Nichtwissen in IT-Projekten” von Prof. Dr. Tobias Br├╝ckmann habe ich mir so einiges mitgenommen.

Hier meine Mitschrift:

(Ich habe vor Ort blind mitgemarkdownt und das ganze dann nach einem kurzen Review nur in html-umgewandelt – es w├Ąre sehr erstaunlich, wenn sich keine Tippfehler f├Ąnden)

1. Keynote

2017-09-29
Radisson Blue Hotel Radebeul

Er├Âffnung

500 Besucher, 90 Studenten
#JSD2017

Keynote – Software Architektur f├╝r alle!? – Software Architektur wird Entwicklerstil

Stefan Z├Âllner / embarc

  • The accidental Architecture – paper von Grady Boch

Entscheidungen und Konzepte

  1. Interaktion mit Benutzern und Fremdsystemen
  2. Unter der Haube
  3. Entwicklung und Weiterentwicklung
  4. Ziel Umgebung und Betrieb

Architekturbewertung:

  1. Entscheidungen absichern
  2. Risiken kennen aufdecken
  3. Zielerreichung pr├╝fen
  4. Kompromisse finden
  • Arc42
  • ATAM

Qualit├Ątsmerkmale

  • Reliability (Zuverl├Ąssigkeit)
  • Maintainability (Wartbarkeit)
  • Usability (Nutzbarkeit)
  • Functionality
  • Security
  • Compatiblity
  • Performance
  • Portability

Wechselwirkungen zwischen Qualit├Ątsmerkmale:

  • Effizienz vs Portablilty
  • Sicherheit vs. Usability

Architekturvision

  • f├╝r den Projekterfolg kritische Architekturaspekte
  • f├╝r die Entwicklung unumst├Â├člich wichtel Rahmen

Prinzipien vs. Konkrete Vorgaben – im Team vereinbaren

arc42

Gliederungsvorschlag zur Architekturdoku

  1. Einf├╝hrung und Ziele
  2. Randbedigungen
  3. Kontextabgrenzung
  4. L├Âsungsstrategie
  5. Bausteinsicht
  6. Laufzeitsicht
  7. Verteilungssicht
  8. Konzepte
  9. Entwurfsentscheidunge
  10. Qualit├Ątsszenarien
  11. Risiken
  12. Glossar

Softwarearchitektur: Stufen

  1. Zuf├Ąllig
  2. Explizit
  3. Nachvollziebar
  4. Wirkungsvoll
  • Wo finde ich die Struktur?
  • ├ťbergreifende Konzepte?
  • Kommunikation? Wie beantwortet Ihr Fragen nach Architekturans├Ątzen, – Konzepten, – Entscheidungen?

Risikogetriebene Architektur

“You should play as much attention to software arch. a single it contributes risk to the overall Projekt…”

Literatur

Architektur Spicker

Blog


2. ├ťber den praktischen Umgang mit Nichtwissen in IT-Projekten

Prof. Dr. Tobias Br├╝ckmann (CampusLab)

Nichtwissen, Unwissenheit, Unsicherheit

  • Softwareentwicklung ist Wissenserwerb und dessen ├ťbersetzung in Programmcode
  • Software repr├Ąsentiert das Wissen zum Zeitpunkt der Implementierung.

“gesunder Menschenverstand”

  1. Unbewusste Inkompetenz
  2. Bewusste Inkompetenz
  3. Bewusste Kompetenz
  4. Unbewusste Kompetenz (gesunder Menschenverstand => hilft nur den Profi)

Typen von Unsicherheit

  1. Produkt-Unsicherheit (Was?)
  2. Methoden-Unsicherheitn (Wie? )
  3. Stakeholder-Unsicherheit (Wer?)
  4. Dom├Ąnen-Unsicherheit (Worin?)

Ebenen von Unwissenheit

  1. Lack of Ignorance – Fehlen von Unwissenheit
  2. Lack of Knowledge – Fehlen von Wissen (ich wei├č das ich etwas bestimmtes nicht wei├č)
  3. Lack of Awareness – Fehlen von Bewusstsein (ich wei├č, das ich irgend etwas nicht wei├č)
  4. Lack of Process – Fehlen eines Prozesses (ich wei├č, dass ich etwas nicht wei├č, aber nicht, woher ich das wissen bekomme)

Ziel der Softwareprozesses

Ebene 1: Fehlen von Unwissenheit zum Zeitpunkt der Implementierung.

Typische Fehlermuster in der Praxis

Prinzip des perfekten Autodidaktikers

Was beschrieben / gesagt wurde gilt als vermittelt und verstanden

Prinzip der unklaren Probleme

  • Jeder Stakeholder hat anderes Problem
  • Jeder Stakeholder hat andere Vorstellungen von den Problemen der anderen

Prinzip der einfachen Verf├╝hrung

Fokus auf Dinge, die man gut kennt

Prinzip der Axiomatic von dokumentierten Annahmen

  • Was mit viel Aufwand dokumentiert wurde, wird nicht mehr hinterfragt – gilt als richtig
  • Dokumentierte Annahmen sind fix, ├änderungen schwer

Prinzip der zwanghaftgen Vollst├Ąndigkeit

  • Erst wenn etwas wirklich vollst├Ąndig ist, ist es gut.
  • Nur das Detail z├Ąhlt, der ├ťberblick ist nicht wichtig.

Prinzip des ├╝berlagerten Wissen

  • Verschwendung vieler Ressourcen f├╝r das Anlegen gro├čer Lagerbest├Ąnd an Wissen
  • Lagerbest├Ąnd ist schnell ├╝berlagert und wertlos

Wissen hat ein Haltbarkeitsdatum

Prinzip der Missachtung von Erkenntnisprozessen

  • Keine M├Âglichkeit auf gewonnene Erkenntnisse zu reagieren
  • Stigmatisierung von Erkenntnissen als Fehler

Prinzip der maximalen Distanz zum Kunden

Prinzip der Eigengefangenheit

“Dem Experten im Umgang mit einem Hammer erscheint jedes Problem als ein Nagel.”

Prinzip der Umm├Âglichkeit der eigenen Meta-Perskektive

Reflektor des eigenen Handelns bzgl. Des Wertbeitrags

Techniken zur Gewinnung und Verwaltung

Annahme: Wissen ist wertvolle Ressource

  • selten Uhren in Meetingr├Ąumen
  • Wie teuer war das Meeting? Wieviel Wissen w├╝rde gewonnen?

Verwaltung des Wissens (Lagerbest├Ąnd)

  • Definition of Ready (Spec vor der Entwicklung)
  • Definition of DONE

Veranschaulichen von Unwissen

  • Kategorien statt vermeintlicher Pr├Ązision (Sch├Ątzungen in Shirt gr├Â├čen M statt 54,034)
  • Explizite Ungenauigkeit statt vorget├Ąuscht Wissen
  • Aktuellen Stand der Erkenntnisse reflektieren (regelm├Ą├čig Neusch├Ątzen und Repriorisierung)

Steuern auf Basis von gewonnene Wissen

  • Annahmgesteuert vs. Erkenntnissgesteuert

3. Agiles Sefi

Jan Gentsch & Julia Dellnitz

  • Arbeit am Produkt / im Team
  • Arbeit am Unternehmen
  • Arbeit an sich selbst (Vormachen) – inspect & adapt

Feedback

  • bekommen Negatives Feedback tut oft weh
  • geholt Feedback f├╝hlt sich besser an

Feedback selbst einholen

Agile Selfie


4. Ein Agile Knigge f├╝r Entwicklerteams

Lena M├╝ller-Ontjes & Beginn Haider (Mach AG)

Prozesse ├Ąndern hei├čt sich selbst ├Ąndern!

Userstories

INVEST-Methode

  • Indeendent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable

Sprintplanung

  • Team ├╝bernimmt und unterst├╝tzt bei Erstellung von Stories
  • Fehler vermeiden statt Fehler finden
  • Hinterfragen
  • Besprochene dokumentieren
  • Keine Entwickler-Anleitung
  • Alles was das Team macht steht am Board
  • Work-in-Progress-Beschr├Ąnkung
  • QA ist Teil des Teams
  • Der Sprint ist und bleibt stabil (Aufgaben / Dauer)
  • Wissensinseln vermeiden

Retrospective

  • Nur f├╝r Teammitglieder!
  • Aktive Teilnahme aller Mitglieder
  • Moderator notwendig
  • Fokus ist nur der letzte Sprint
  • Keine Opferhaltung
  • Ma├čnahmen dokumentieren

Abnahme

  • Abnahme ist keine zweite QA
  • Konflikte eingehen -> alles muss auf den Tisch

Fazit

  • Vertrauen schaffen
  • Methoden einsetzen
  • L├Âsungsorientiert denken
  • Sprint-Alzheimer verhindern
  • Feedback geben

5. Serverless

J├Ârg Adler, Benjamin Otto (Mercato)

Cloud ist nicht nur Rechenleistung und Speicher sonder auch Servses

  • Infrastructure (IaaS)
  • Platform (PaaS)
  • Function (FaaS)

Tool to check: artillery

Function as a Service

  • alle Ressourcen beim Cloudanbieter
  • DEV stellt nur Code bereit
  • keine Persitenz
  • anbieterspezifisch
  • schnell scallierbar

AWS Lambda

  • functions can be bound to S3-buckets (eg. called on file-upload)
  • mehrere Sekunden f├╝r Start eines Lambdas
  • 2800 Lambdas – rund 40 TFlops (ca. 7 Cent/Sek)
  • JavaSDK von Amazon (Github: aws-lambda-java-libs)
  • Limits
  • Heap max. 1.5 GB
  • Laufzeit max. 5 Minuten

Kosten

  • Kostenalarme m├Âglich (cloud-watch)
  • deutlich preiswerter als Docker in elastic cloud

Serverless framework

CLI-tool zum Bauen und Deployen von serverless functions

Demo mit Lambda-Beispiel

-> in Erg├Ąnzung: https://www.golem.de/news/open-source-oracles-serverless-plattform-versteht-auch-aws-lambda-1710-130447.html


6. Rundungsfehler

Michael Wiedeking (Mathema Software GmbH)

Gleitkommazahlen

  • Je gr├Â├čer die Zahl, desto gr├Â├čer die Ungenauigkeit (logarithmisch wird der Abstand der darstellbar Zahlen gr├Â├čer)
  • Je mehr gr├Â├čer die Mantisse, desto genauer die Darstellung (… kleiner die Abst├Ąnde)

Rechnen mit Gleitkommazahlen

Wenn eine Zahl nicht darstellbar ist, dann nimm die n├Ąchst gelegene -> Problem der Unterschiedlichen Abst├Ąnde -> Fehler bei gro├čen Zahlen gr├Â├čer

Je nach Zahl treten gro├če Fehler auf: 0.1 + 0.1 + 0.1 + 0.1 = 0.5

Fehler h├Ąngt ab von:
* Abstand von den existierenden Zahlen
* => Gr├Â├če der Zahlen

=> Reihenfolge der Rechnung ist wichtig (Zwischenergebnisse k├Ânnen nicht darstellbar sein)