Barrierefreiheit in IT-Produkten nachrüsten

Im ersten Post unserer Reihe über Barrierefreiheit hat euch Amina letzte Woche über die rechtlichen Vorgaben für Barrierefreiheit von Software-Produkten informiert.  Wie dort erwähnt, müssen alle Software-Produkte bis 2025 (mit einer potentiellen Verlängerung von fünf Jahren) auch für Menschen mit körperlichen oder geistigen Beeinträchtigungen zugänglich und benutzbar sein.

Die gesetzliche Vorgabe ist eine Sache. Mindestens genauso wichtig sollte es Betreibern von IT-Produkten aber sein, diese so barrierefrei zu gestalten, dass sie bestmöglich auch von Menschen mit (vorübergehenden oder dauerhaften) Einschränkungen genutzt werden können. Denn letztendlich zahlt Barrierefreiheit auf eine Erweiterung der Zielgruppe um zuvor vollständig oder teilweise exkludierte User ein. Barrierefreiheit kann ein deutlicher Vorteil gegenüber Mitbewerbern sein und damit den Erfolg des Produkts vergrößern.

Gerade entstehende und zukünftige Software-Produkte sollten Barrierefreiheit daher direkt mit einbeziehen und implementieren. Barrierefreiheit sollte als fester Bestandteil der zu erfüllenden Anforderungen angesehen werden und im gesamten Lebenszyklus des Software-Produkts berücksichtigt und optimiert werden.

Doch wie sieht es aber mit dem Nachrüsten bereits bestehender Software-Produkte aus? Wie kann hier Barrierefreiheit nachträglich implementiert und kontinuierlich gewährleistet oder gar verbessert werden?

Weiterlesen

Wie wir OKR in unsere Teamarbeit integriert haben

Das partizipative Zielsystem OKR (Objective and Key Results) erlebt in meiner Wahrnehmung einen wachsenden Zuspruch. Viele Artikel und Blogposts befassen sich mit der hypothetischen Implementierung des OKR-Framework in Organisationen. Denn eine finale Blaupause für die Implementierung von OKR gibt es nicht. Sie ist von Organisation zu Organisation unterschiedlich und hängt von einer Menge Faktoren, wie z. B. Größe, Hierarchie, Struktur, Kultur, Flexibilität und Reifegrad ab. Ich möchte anhand eines Beispiels erläutern, wie OKR in unsere Teamarbeit integriert wurde.

Weiterlesen

EKS-Fuckups – und was wir daraus lernen

Einen vollständig verwalteten Kubernetes-Service wie EKS zu nutzen, ist eine gute Idee. Einiges an Komplexität und Aufwand im Betrieb wird dadurch überflüssig oder auf ein Mindestmaß reduziert.

Natürlich gibt es auch Stolpersteine. Und Dinge, die man so nicht auf dem Schirm hatte. Was haben wir erfahren? Welchen Herausforderungen standen wir schon gegenüber?

Einige Einsichten möchten wir in diesem Post mit euch teilen. Und: Ein paar praktische Tipps gibts am Ende des Blogartikels auch noch.

Weiterlesen

On-time delivery demystified

Wann wird es fertig? Die meist gestellte Frage kennt ihr alle. Die zweitmeiste Frage hingegen lautet: Warum ist es verspätet fertig geworden?

Da es sich bei Software-Entwicklung um komplexe sozio-technische Systeme handelt, gibt es eine Vielzahl von Faktoren, die Aufwandsschätzung und die wünschenswerte termingerechte Lieferung beeinflussen. Mal ganz davon abgesehen, dass wir uns natürlich auch um Outcomes & Business Impact bemühen müssen. Der kommt aber nicht ohne den entsprechenden Release.

Da ich nun schon lange in der digitalen Produktentwicklung arbeite, habe ich mich gefragt, ob nicht schon längst innerhalb der Forschung ein Framework entwickelt wurde, das die Herausforderungen systematisiert betrachtet und diese visualisiert.

Was soll ich sagen? Ich bin fündig geworden! Und zwar in einem Researchpaper von September 2022 … da ist die Druckerschwärze quasi erst getrocknet.

Weiterlesen

EKS & kubecost – Kubernetes-Kosten im Griff

Ein vollständig verwalteter Kubernetes-Service auf AWS ist eine feine Sache: binnen weniger Minuten können wir auf EKS-Cluster zugreifen und von den Möglichkeiten der Plattform profitieren.

Doch wie sieht es mit den Kosten aus? AWS berechnet Gebühren für Compute, Storage und Data Transfer. Hinzu kommt noch eine feste monatliche Gebühr in Höhe von 73 US-Dollar pro EKS-Cluster …

Weiterlesen

Taking Ownership of your Workflow

As a developer, you are constantly learning and improving. There are a lot of different benchmarks you are supposed to fulfill. When you are applying for a job, you are supposed to check all the boxes. Do you know Java? Do you have experience working in an agile environment? Design patterns? TDD? In consulting, you get to do this again with every new customer and project. But what then?

In our daily business, things get a bit fuzzier. It boils down to perceived competence and speed. Does this developer know what they are talking about? Do they get work done on time? The first boils down to the checkboxes again. The latter, though … How do you become faster? Without compromising on quality, that is.

Weiterlesen

CI/CD-Pipelines mit GitHub Actions

GitHub Actions ermöglicht die Realisierung einer vollständigen Continuous Integration / Continuous Delivery Pipeline direkt in unserem GitHub Repository. In diesem Workshop erstellen wir eine komplette Build- und Release-Pipeline für ein bestehendes Node.js-Projekt und lernen dabei die Funktionsweise von CI/CD sowie die Kernkonzepte von GitHub Actions in der Praxis kennen.

Weiterlesen

Knowledge Management for Software Engineers

… or: How I learned to stop worrying and love the Zettelkasten.

Everyone has been there. An error message pops up, and recognition begins to dawn. I have seen this error message before, you think. But where?

You google it. The Stackoverflow links for this topic are all purple. You have been down this rabbit hole before. You remember. It was something weird … involving a specific version of … something. You recall solving this error message to get another error message to solve to get yet another. You remember solving the problem eventually. You also remember it took you more than a day, but you have no clue where to find the solution.

Weiterlesen

Ungeplante, aber validierte Investments in Qualität

In meiner liebsten deutschen Chat-community zu agilen Themen, dem Slack von Mein Scrum Ist Kaputt, hatten wir vor Kurzem wieder eine spannende Diskussion zum Thema „Schätzen“. Und neben den Klassikern wie NoEstimates, ItemCount und Flow kamen wir auch auf die Outlier – die Stories und Bugs, die jeder Schätzung und zum Teil sogar dem Sprintziel im Wege stehen, weil sie im Sprint plötzlich zu wachsen beginnen.

Es eine schöne Idee aus DevOps („Seeking SRE“ in diesem Fall), auf die mich ein Ex-Kollege gestossen hat:

Incidents are best regarded as unplanned investments in system performance.


Weiterlesen