Jahresendcyber in Bielefeld

Jahresendcyber - Workshops Talks und gute Laune am 27.+28.12.2022 in Bielefeld bei digitalcourage

Da der CCC ja leider ausfällt und zu regionalen Veranstaltungen aufgerufen hatte, musste Ersatz her, dachten sich die Privatsphären-Schützer.innen und Netzaktivist.innen von digitalcourage und nun treffen sich halt die Häcksen und Hacker in Bielefeld.

Digitalcourage lädt zum Jahresendcyber ein: am 27.–28. Dezember öffnen sie ihre Studioräume in der Marktstraße 26, Bielefeld. Es wird ein Programm aus Vorträgen, Talk-Runden, Workshops und Aktionen geboten. Es soll geredet, gelernt, mit Technik experimentiert und über Politik reflektiert werden.

UPDATE: Es fiel krankheitsbedingt leider aus, aber über FireShonks (siehe unten) sind einige Veranstaltungen gelaufen, die man auch nachträglich noch abrufen kann.

Einige Events können, dank der R3S-Crew, außerdem auf dem Kanal der FireShonks gesendet werden.

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.

    Dropbox kauft Boxcryptor

    Es gibt manchmal Nachrichten, die ich nicht lesen möchte. Secomba, Hersteller von Boxcryptor und deren CEO Andrea Pfundmeier, galt immer mein Respekt, da sie eine sehr einfach zu bedienende, über Anbietergrenzen hinweg nutzbare und aus Deutschland stammende Verschlüsselungslösung für die Cloud angeboten haben.

    Leider wurde das „geistige Eigentum“, die IP, nun an DropBox, Inc. (USA) verkauft. Auch wenn ich als Kunde bei der Secomba verbleibe, so können andere nicht mehr direkt mit dem europäischen Verschlüsselungsanbieter arbeiten, da Neuverträge sicherlich nur noch mit der US-amerikanischen Mutter gemacht werden können. Was das heißt, muss ich nicht beschreiben: Die „Drei-Buchstaben-Organisationen“ haben Zugriff auf das was bei DropBox, Inc. abgehen wird und Hintertüren dürften vorrangig das Ziel der US-Behörden sein.

    Nun wäre es wieder an der Zeit nach Alternativen zu suchen. Weihnachten geht es nun los: Cryptomator verspricht selbiges wie Boxcryptor und ist zudem OSS (open source software).