Kategorie: Software Entwicklung

Geschäftsgetriebene Testautomatisierung mit Richie und Jogi

Anlässlich des QS-Tags 2024 in Frankfurt am Main sprachen Richard Seidl („Richie“) und ich über die Implementierung der geschäftsgetriebenenen Testautomatisierung in einem Versicherungsunternehmen.

Open Source Software und deren Herausforderungen

Open Source Projekte brauchen eine starke Firma im Hintergrund, damit das Projekt langfristig überleben kann. Das ist zumindest meine Erkenntnis.

Es gibt auch die Möglichkeit durch eine Foundation, Stiftung o.ä. das zu schaffen, nur dann müssen genügend Sponsoren dauerhaft einzahlen wollen – also auch am Ende nichts anderes als würde es eine Firma selbst bezahlen, nur teilt man sich das kommerzielle Risiko mit anderen.

Die Community trägt gerne etwas bei, aber hauptberuflich Beschäftigte müssen von irgendwoher bezahlt werden. Das ist beim OpenOffice.org-Fork LibreOffice, Mozilla, Linux und deren Derivaten (Ubuntu) u.a. sehr gut zu sehen.

Wenn sich das Modell oder das wirtschaftliche Ziel ändert…

Manchmal ändern sich die Modelle und writschaftliche Interessen der Sponsoren hinter den Projekten und da gibt es dann die, die das gut machen und manche, die das total verreißen. Ich kann mich noch erinnern, als Sun Microsystems bei OpenOffice.org das Lizenzmodell änderte. Verlässlich war nur die Veränderung…. und irgendjemand fühlte sich immer auf den Schlips getreten.

Nun haben SmartBear und Tricentis auch OSS unter ihren Fittichen und da sieht man auch wieder, dass manche Firmen es können und andere eben nicht – Quelle: Dawid Dylowicz:

Damit wird es sichtbar, was manche IT-Manager auch von OSS abhält: Die Verlässlichkeit oder das einzugehende Risiko zu reduzieren.

Das Argument „(…) sollten wir nehmen, ist Open Source“ zieht manchmal bei Entwickelnden und Testenden, aber selten bei Entscheidern.

Insofern entscheide ich bspw. bei Werkzeugen/Software nicht danach, welches Lizenzmodell dahinter steckt und der Preis für das Werkzeug spielt auch eine Rolle, aber, entscheident ist eigentlich:

Erfüllt die Software meine Anforderungswünsche?!

Nur weil etwas open source ist, ist es nicht automatisch „gesetzt“, „umsonst“ und es nutzen auch nicht „alle“!

Vielmehr würde, wenn eine Software open source gestellt worden ist, die Transparenz gefördert und Fehlfunktionen oder auch Sicherheitslücken könnten von vielen gefunden werden. Das Projekt selber unterliegt aber natürlich wirtschaftlichen Interessen! Die, die als Sponsor auftreten wollen damit etwas erreichen. Open Source ist genauso wenig Demokratie, wenn diese nicht gelebt wird! Tote OSS Projekte findet man zu Hauf, wie auch vermeidlich „open“, wo nur der Code hingeschmissen wird, aber sonst niemand anderes auf die Weiterentwicklung  Einfluss hat.

Oftmals ist auch die open source Variante die kleine Schwester von „umständlich“, „hässlich“ und „Lockangebot“, wie im Fall von SOAP UI und ReadyAPI. Letzteres ist deutlich moderner, leistungsfähiger, aber eben nur Ersteres ist OSS….

Beim Selenium-Test-Framework bekommt man die API „umsonst“, aber der Support geht über Sponsoren und die wollen eben auch Geld verdienen. Viele Wekzeuge, die sich der API in den Unterbau gezogen haben, sind auch mitnichten open und schon gar nicht kostenlos.

Also, bitte, argumentiert mit der Leistungsfähigkeit der anzuschaffenden Software und blickt auch hinter das Sponsoring-Modell, denn, wie man oben schön sehen kann, kann es binnen eines Monats mit „open“ ganz schnell vorbei sein.

TACON – Die Konferenz zur Testautomatisierung 26.- 27.9.23 in Leipzig

Du bist in der Software-Entwicklung tätig und interessiert an aktuellen Themen rund um Testautomatisierung? Dann haben wir eine tolle Nachricht für dich!

Am 26. und 27. September findet die TACON in Leipzig statt. Hier werden unter anderem die folgenden spannenden Themen behandelt:

  • Testautomatisierung in agilen Teams
  • Cloud Testing
  • Qualität von ‚Infrastructure as code‘
  • Automatisiertes Performance- und Lasttesting mit und ohne Cloud
  • Testautomatisierung mit AI und von AI
  • Automatisierte Security-Tests
  • Barrierefreiheit automatisiert Testen gemäß Barrierefreiheitsgesetz (EU-Norm)
  • DevOps & DevSecOps

Die Konferenz bietet eine großartige Gelegenheit, um sich mit anderen Experten auszutauschen, Wissen zu teilen und sich über die neuesten Trends und Technologien im Bereich der Testautomatisierung zu informieren.

Wenn du dich in diesem Bereich engagierst und innovative Lösungen entwickelst, dann melde dich gerne mit deinem Beitrag zum call for presentations, wir bieten dir die passende Bühne.

Das Programmkommitee Karin Vosseberg, Dirk Huberty und Jörg Sievers, sowie das Team der TACON Softwareforen Leipzig freuen sich auf dich!

Vormerken: 1. & 2. September 2023 QS Barcamp in Hamburg

Auch 2023 wollen wir am 1. und 2. September wieder das QS[Bar]camp in Hamburg bei oose veranstalten – das Format bleibt: Barcamp, also

  1. Tag: Vortrag + Grillen
  2. Tag: Frühstück + open space.

Wer auf dem Laufenden bleiben möchte, gerne bei LinkedIn der Gruppe QS Barcamp beitreten.

MacUpdater 3 BETA

Für diejenigen unter Euch, die ihre Applikationen auf ihrem Mac auf dem neuesten Stand halten wollen, können mit MacUpdater 3 (BETA) mal schauen, wie einfach das geht.

Ein wirksamer Schutz gegen Angriffe ist es, die installierten Programme auf Stand zu halten.

Ich habe 2020 an der deutschen Übersetzung mitgewirkt und Feedback an corecode.io wird auch heute immer noch freundlich entgegen genommen.

Helft mit, das wohl beste 3rd Party-Updaterprogramm im Mac-Universium besser zu machen!

Einflussfaktorschätzung – Wie man in der Softwareentwicklung schätzen kann

Ich habe diesen Artikel am 11. Juni 2016 in Englisch geschrieben, aber ich denke, es macht Sinn, diesen auch mal auf deutsch zu veröffentlichen und etwas zu erweitern. Das Thema ist nach wie vor aktuell.

In einem Tweet, als ich noch auf Twitter aktiv war, habe ich zugestimmt, dass ich kein Excel für meine Arbeit beim Testen verwenden möchte. Ich hasse Excel (wahrscheinlich weil ich mit Lotus 1-2-3 angefangen hatte)…

My test manager says „I don’t wanna get back to the 90s“ when talking about Excel for managing tests. No further comment.

— (((Robert Strauch))) (@shrubbytester) 10. Juni 2016

und Michael Bolton antwortete später in demselben Thread:

@osxjogi … Monte Carlo simulation. Example: https://t.co/VkYCEHAAD1 @shrubbytester @ThomasPonnet

— Michael Bolton (@michaelbolton) 10. Juni 2016

Ich schrieb also auf, wie ich mit Code-Entwickler.innen Aufwandsschätzungen durchführe, die dicht an die Realität kommen können. Wir haben da so unsere Erfahrungen mit größeren (vorrausschauend über 18 Monate Projektzeit) als auch in kleineren Projekten angewendet und die Faktoren unseren Bedürfnissen angepasst. Es ist also keine starre Regel, sondern basiert auf den Erfahrungen im jeweiligen Projekt und wurde immer mal wieder aktualisiert.

Allgemein

Es gibt zwei Aspekte in der Betrachtung:

  1. Schätzung der Aufwände für die Codeerstellung (Produktionscode, Klassen- und Methodentests, Dokumentation, Integrations- und Systemtest, interne Abnahmeaktivitäten) – dies ist bei der Methode vorrangig das Schätzungsziel.
  2. Schätzung der Aufwände für zusätzliche Arbeiten, wie Projektmanagement, Testzyklen und externe Akzeptanztests

Schätzung der reinen Codeerstellung als Grundlage

Die Methode basiert auf der Annahme, dass erfahrene Code-Entwickler.innen ihre eigene Arbeitszeit für die zu erledigenden Aufgabe sehr gut enschätzen können, also: Codierzeit, nicht aber den Rest. Die Schätzung steigt an, wenn die Einflussfaktoren größer werden, die die/der Entwickler.in nicht unter Kontrolle hat.

Die folgende Tabelle

  • ist erfahrungsbasiert und keine „das ist DIE Lösung“, sondern in Summe wird das Ganze ganz gut passen, wenn man mehrere Entwicklungszyklen hat
  • beschreibt den zusätzlichen Aufwand, der zur reinen Schätzung des Codierens hinzukommen muss (Schätzung = 1)

    Einflussfaktoren für die Codeentwicklung

    Code-Entwickler.in erstellt Codezusätzlicher
    Aufwand
    zur reinen Codeschätzung    		Anmerkungen und Erklärungen
    ohne Verwendung von fremden Code1Normales Verhalten in einem Entwicklungsteam
    mit der Verwendung von Open-Source-Code innerhalb des Unternehmens/Projekts2z.B. Code aus anderen Gruppen im Unternehmen verwenden - Wissen lässt sich leicht übertragen
    mit der Verwendung von Open-Source-Code von außerhalb des Projekts/Unternehmens3 - 5; 3 ist normal, 5 der schlimmste Fallz.B. Verwendung eines (im Projektteam) unbekannten Open-Source-Frameworks oder extrem hohe Performance-Anforderungen
    mit der Verwendung von geschlossenem Quellcode3 - 5; 3 nicht oft, 5 normalz.B. die Verwendung eines Closed-Source-Frameworks wie es ist
    mit der Notwendigkeit, Closed-Source-Software (Drittanbieter) für die Integration zu verwenden5 - 9Integrieren z.B. eines Dienstes, dessen Erreichbarkeit man nicht vom Projektteam kontrollieren kann

    Beispiele:

    1. Die/Der Entwickler.in schätzt 6 Arbeitstage für die reine Codeentwicklung. Die/Der Entwickler.in muss eine oder mehrere Klassen verwenden, die bereits Teil des Projekts sind. 
      1 x 6 Arbeitstage kommen hinzu. Zusammenfassend beträgt die Schätzung für die Erledigung der Aufgabe 12 Arbeitstage für den Code, die Unit-Tests, die Dokumentation, die Integration und die interne Abnahme. Wenn man es genauer haben muss, sollte man die Aufgabe in kleinere Stücke zuerlegen, aber das ist zumeist dann in der Schätzungsphase eine besondere Herausforderung.
    2. Der Entwickler schätzt 5 Arbeitstage für die reine Codeentwicklung. Der Entwickler muss ein Open-Source-Framework eines Drittanbieters verwenden. Das Wissen im Projektteam ist nahezu null. 3 x 5 bis 5 x 5 Arbeitstage kommen hinzu. Zusammenfassend erhalten Sie dann eine Schätzung von 20-30 Arbeitstagen für alle erforderlichen Arbeitsaufgaben.

    Das mag für die/den eine.n oder andere.n sehr hoch gegriffen sein, aber es hat sich immer wieder und wieder gezeigt, dass die Schätzungen durch eben derartige Einflussfaktoren die Aufwände in die Höhe treiben. Product Owner, die das nicht auf dem Zettel haben, wundern sich, warum die Schätzungen immer so weit von der Realität abweichen.

    Das berühmte Schätzen mit „Gummipunkten“ ist auch eine Übersetzung von derartigen Einflüssen, da die Komplexität geschätzt wird, jedoch nicht nachvollziehbar gesagt wird, wodurch diese denn beeinflusst wurde.

    SheHacksPurple Security-Kurse durch Bright-Übernahme kostenfrei

    Buchcover Alice & Vob learn Application Security
    Buchcover Alice & Bob learn Application Security

    Tanya Janca (She hacks purple) hat ihre Firma “We hack purple” an Bright verkauft, einem Hersteller eines SAST-Tools. Das wäre nun nichts so tolles, aber ihre Kurse, wie man Application Security angeht, sind nun KOSTENFREI und kosteten vorher mehrere hundert Dollar/Kurs! (Quelle)

    Tanyas Buch „Alice & Bob learn Application Security“ (Wiley) hilft sehr gut in das Thema Application Security einzutauchen, daher sind ihre Kurse ebenfalls für Einsteiger gut geeignet.

    https://community.wehackpurple.com/

    1993 – oder wie hacke ich mich selbst

    Nachdem ich nun mein Programm von 1995 wiedergesehen habe, war nun die Aufgabe schwieriger, denn das erste von mir selbständig entworfene und programmierte Lotus 1-2-3-Makro-„Programm“ ist von 1993, also aus der Windows 3.1-Ära.

    Da schon das Archiv nicht unter der Windows 11/ARM-Emulation sich entpacken wollte, wollte ich meine SunPCi-Karte in Betrieb nehmen. Windows 2000 müsste von der Kompatibilität noch einigermaßen passen. Zudem wusste ich nun, dass eine DE-Version von 1-2-3 unabdingbar ist, da man schon in den 90ern bei der IBM (und bei anderen) nichts von guter Lokalisierung wusste (die Makro-Sprache war mit übersetzt und lief daher nicht in anderen Sprachen!).

    SunBlade 1000 mit XVR 1000-Grafikkarte und eben jener SunPCi III-Karte (AMD Athlon-Prozessor und 8GB auf der Co-Prozessorkarte) gestartet und Software besorgt… ohweia, Sun Microsystems hat immer den alten Kram preisgegeben, aber snOracle natürlich nicht 🙁 Also recherchiert und unter The Vintage Technology Digital Archive fündig geworden (Danke!). Um die compressed Dateien nun zu entpacken, kann man das tar-Programm von UNIX nicht nehmen 🙁 Also OpenCSW angesteuert und die GNU-Version besorgt. Man glaubt es kaum, aber das Ding lief beim ersten Start…. 
    Nun noch Windows 2000 besorgen. DAS war allerdings dann echt eine Herausforderung, da es wohl die OEM-CD-ROM sein musste, aber ich wurde fündig beim Internet Archive, leider ohne Seriennummer, also ging die Suche weiter, aber man wird fündig und rj22y-w6ywf-tdh77-w7tpt-ggw62 öffnete dann die Tür zur Windows 2000-Welt….und der Spaß
    konnte beginnen…. Nur leider musste ich, damit ich überhaupt irgendwas installieren konnte, erst einmal das Service Pack 4 installieren. Nun die SmartSuite von Lotus 1-2-3 auf deutsch und ab dafür. Aber…. ich hatte 1993 meine eigene Passwortroutine gebaut und  nicht, wie 1995 die Standard-Passwort-Dateisicherung genommen…. und wer erinnert sich an Passwörter von 1993. Idee… Mittels HEX-Editor einfach mal die Datei durchforsten…
    Jo, ich konnte mich an mein Passwort erinnern. Wer Lust hat, kann es suchen und, nein, es ist nicht „Passwort“.

    Starten und stauen und wieder enttäuscht werden…. normalerweise öffnet das Programm mit eigenen Menüs, so wie beim Unfall-Programm, aber dieses hier ist von 1993 und da wurde der {MenüErstellen <Menüname>}-Befehl aus der Windows 3.1-Version (Lotus 1-2-3 Release 5) entfernt 🙁 Egal. Einen ersten Eindruck sieht man, aber die vollständige „Schönheit“ wird erst zu sehen sein, wenn aus Pinneberg die 7×3,5″ Disketten, die ich bei eBay erstehen musste, angekommen und installiert sein werden…. to be continued…

    Die Aufnahme ist über vnc gemacht worden, da ich zwischenzeitlich RealVNC 4.1.3 auf der Windows 2000-Instanz installiert habe.

    Unfall 95 – und die Erinnerungen an Lotus 1-2-3 auf einem M1 lebendig machen

    Weihnachten ist immer so die Bastelzeit, also die Zeit, die ich als junger Hacker quasi 24h am Tag hatte. Ich wollte seit Jahren meine für meinen ehemaligen Ausbildungsbetrieb in der Tabellenkalkulation Lotus 1-2-3 geschriebenen Makro-Programme „ResQ“ (Reklamationsstatistik Qualitätssicherung) und „NUS“ („NORDSEE“ Unfallstatistik) mit heutigen Augen ansehen…

    Lotus 1-2-3 war das „naturwissenschaftlichere“ Excel von IBM und wurde seinerzeit unter DOS, Windows (3.x), OS/2 uvm. Betriebssystemen angeboten (damals hatte man wenigstens eine Auswahl).

    Die „NORDSEE“ (ja, die Fischrestaurants gehörten seinerzeit zum Konzern, sowie eine Frosterei (später frozen fish international), Räucherei und die Frischfisch-Abteilung (heute Deutsche See)) hatte mich gefragt, ob ich während meiner Semsterferien die für die Berufsgenossenschaft notwendige Unfallstatistik zu erstellen.

    NUS war wohl das zweite Programm, aber das erste wo die Anforderungen quasi auf dem Tisch lagen und ich keinen Bock hatte, den Mist von Hand auf Papier zu bringen. Die Aushilfen in den Jahren zuvor haben die Daten auf einem Endlosdruckerausdruck (abwechselnd grün-weiß – Höchststrafe als HSV-Fan!) manuell (IBM = immer besser manuell) abgeschrieben und nach Formel in die einzelnen Statistiken überführt.

    Ich hatte damals ein altes, nur noch am Strom funktionierendes Laptop mit riesigem Netzteil (ich meine der war sogar ausgeliehen) und in meiner Studentenbude einen WYSE-PC mit IBM OS/2 drauf. Also habe ich damals schon „nächtliches HomeOffice“ gemacht, da die technischen Möglichkeiten einfach besser waren und in meiner Bude auf dem Firmengelände nur die Probleme ausgebügelt.

    Die für mich zuständigen Sicherheitsingineure (einen kannte ich aus meiner Ausbildung, der andere war eigentlich mit der Umsetzung des Hochregallagerbaus beschäftigt) fanden meine Arbeit geil und, da damals die Erfassung der BG-Unfälle die Zeit der Sekretärinnen frass, fragte man mich (ich meine ein Jahr später), ob ich da was machen könne…. und das müsste die Version sein, die ich nun auf der Diskette fand.

    Die Sekretärin musste fortan nun nicht mehr alles in die Schreibmaschine tippen und bei einem Fehler nochmal anfangen, da die BG-Unfallbögen ein Mehrfachdurchschlag waren, sondern sie konnte die Daten wieder laden, korrigieren und noch einmal aus dem Drucker den aktuellen Bericht drucken lassen. Ebenso konnte sie die Statistik selbst tagesaktuell laden.

    Wie schon immer, keine Daten, sondern nur das Programm auf der Diskette!

    Für meine Herausforderung das Programm zu starten ist 2021 nicht unbedingt der beste Zeitpunkt, da ich keinen x86/INTeL-basierten Mac mehr habe, DOS besitze ich maximal noch als Emulator oder in der PCi-Karte auf meiner SPARC und Lotus 1-2-3 ist eher ein Antqiquariatsartikel und Passwortcracker auf *.wk4-Dateien sind bestimmt auch nicht an der Tanke zu haben.

    Läuft! Auf einem M1-MacBook mit Windows 11 (Parallels) Lotus 1-2-3 9.8.0208.1200 (2002)

    Zum Einsatz kommen folgende Komponenten (und viel Zeit)

    1. Parallels Desktop 17.1.1 für Mac (auf einem Apple Silicon M1)
    2. Windows 11 (kommt mit Parallels Desktop)
    3. Elcomsoft Advanced Lotus Password Recovery 2.12.1784.0 (2018)
    4. Lotus 1-2-3 (in der Lotus Smartsuite) als ISO aus dem Internet Archive
    • Das ISO als CD in Parallels anbinden, damit Windows 11 es lesen kann.
    • das enthaltene .msi-Programm zur Installation starten und sehr lange warten
    • Die Installation, trotz drei Fehler bis zum Ende durchführen
    • Elcomsoft installieren in Windows 11 und die *.wk4-Datei Laden – binnen SEKUNDEN wurde mein dreibuchstabiges Passwort „bgn“ gefunden 🙂
    • 1-2-3 aus Windows starten
    • Datei laden und bgn als Passwort eingeben
    • voilà – unter einem ARM-Prozessor ein steinaltes x86-Programm in einer virtualisierten Windows 11-Umgebung gestartet

    Für ResQ muss ich wohl doch die PCi-Karte in der SunBlade 1000 (2002 Sonderedition) zum Laufen bringen, da das *.exe-Archiv unter Windows 11 nicht extrahiert werden kann. Mal sehen, ob ich dieses Jahr noch dazu motiviert bin 🙂

     

    Agile Testing Days 2021 meine Highlights 2. Konferenztag

    For my non-German-speaking quality colleagues: Please use deepl.com Thx!

    Der erste Tag war nicht durch den zweiten zu toppen, auch weil ich abreisen musste, aber schön war es dennoch, denn es ist die Idee zwischen Nathalie, Björn (Evertest, Belgien) und mir entstanden, in einer belgisch-deutschen Koperation eine Session für die kommenden Agile Testing Days zu bauen, da uns der Aspekt „Wie kann man Ideen testen?“ doch mal näher beleuchtet werden sollte.

    Am zweiten Tag bin ich, anstatt zu laufen, bei Janet mit am Lean Coffee-Tisch gelandet. Die Probleme sind oftmals dieselben, aber leider sind die Firmen nicht dieselben: Wie bekommt man die Verantwortung für Qualität in die Köpfe aller im Team.

    Even though I was late due to the covid test and registration, I learned something during the lean coffee this morning. Thanks #AgileTD pic.twitter.com/AW8TFi33bi

    — Bart The Tester (@bartthetester) November 17, 2021

    Jutta hat es sehr schön aufgezeigt: Soziale, ökonomische und eben auch die bekannten Umgebungsaspekte zusammen ergeben Nachhaltigkeit.

    Now the story of how Chef developers rebelled against the contract with ICE and that had a real impact – it will not be renewed. Shows us that people have more power than they think and we must all be responsible for our part towards sustainability. @JuttaEckstein #AgileTD pic.twitter.com/eNK5A10WiA

    — João Proença (@jrosaproenca) November 17, 2021

    Ich fand es beeindruckend, dass die Entwickler.innen von CHEF damit gedroht hatten, den Code auszubauen, den die Heimatschutzbehörde der USA leider völlig losgelöst von den Werten der erschaffenden Menschen eingestzt hat. Anderes Beispiel, das Jutta nicht genannt hatte: Die Story im Sommer 2018 von Google und dem „Maven-Projekt“ hatte zur Folge, dass nun Jeff Bezos und die Microsofties das Drohnenprojekt betreuen, aber eben nicht Google. Da haben sich Mitarbeiter.innen auch mal dagegen gewehrt an so einem Mist mitwirken zu müssen und zumindest meinen Respekt eingeheimst.

    Crowd Testing – eine andere Welt

    Ich persönlich bin selbst auch in einer „crowded Tester-Community“, aber ich wusste gar nicht wie konzentriert der Markt auf ein paar globale Player zusammen[gekauft|geschrumpft] wurde. Ich war bei einem Vortrag, der spärlich besucht war, um mich mal auf den neuesten Stand bringen zu lassen. Mitlerweile sind die Plattform-Anbeiter (gerade was die mobilen Devices angeht) verbandelt mit den TaaS-Anbietern, aber ansonsten ist m.E. da alles wie man es sich für einen END-Abnahmetest das so vorstellt.

    Quality Dojo

    „What’s a quality dojo“ by @zfordreitz is about to start #AgileTD pic.twitter.com/C0MrZmVYrj

    — Tobias Geyer (@the_qa_guy) November 17, 2021

    Zed hat die Regeln, die bei ihm angewendet werden schön erklärt, sodass ich auch an unser Team noch was übermitteln kann, was wir ggf. auch mal in Betracht ziehen könnten. „Hopp-on-hopp-off ohne erklären zu müssen warum“ fand‘ ich schon mal inspirierend. Schön, dass nun immer mehr Firmen das Training auch als Bestandteil der Arbeit ansehen. Nur durch ständiges Training wird man eben besser.

    Risk Storming

    Risk storming with @TestSphere by @isleoftesting described by @jrosaproenca #AgileTD pic.twitter.com/fN8MdJIPrs

    — Göran Kero (@ghkero) November 17, 2021

    João Proença hat dafür schon die Nominierung fürs kommende Jahr (bei mir persönlich) gewonnen, denn auch ich trainiere gerne Risk Storming, weil es eines der effizientesten Methoden ist, dem Team die wichtigsten Risiken bewusst zu machen. Die ganze Keynote „Limitless with our Boundaries“ war toll, denn es ist gut eine Auswahl zu haben, aber die Anwender.innen oder Entwickler.innen immer vor einer schier unendlichen Auswahl von Möglichkeiten zu stellen, ist, wie er eindrucksvoll dargstellt hat, nicht immer die beste Idee.

    Der Tag 2 war kürzer wegen der Bahnfahrt, aber es waren zwei sehr lehrreiche Tage und anscheinend hatten auch die anderen Unicorns ihren Spaß.