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)