Freitag, 29. April 2016

Kommentierte Links (XII)

Grafik: Pixabay / Geralt - Lizenz
  • Michael Mahlberg: DevOps - Karl Marx to the rescue?

  • Und ich dachte schon, ich wäre der einzige, der über marxistische Ansätze in der IT schreibt. Wenn ich Michael Mahlberg mal wieder begegnen sollte bekommt er auf jeden Fall Kudos von mir. Darüber hinaus hat er natürlich recht - in der Software-Entwicklung müssen die Produktionsmittel (v.a. die Computer und deren Adminrechte) in der Hand der Arbeiter Programmierer sein. Beispiele wie die von ihm genannten habe ich auch schon erleben müssen: entfesselte Großkapitalisten Konzernabteilungen machten durch überbordende Bürokratie jedes Software-Update und jede Installation eines neues Tools zu einem wochenlangen Formular-Krieg. Das dauerte, machte alles teuer und vertrieb die dringend benötigten Fachkräfte aus der Firma. Aber ganz unabhängig davon - ich müsste mal darüber schreiben, ob Shared Code Ownership vielleicht ein bisschen kommunistisch ist. Nur so eine Idee.

  • Tim Kanning: Jetzt kommen die Lego-Banken

  • Dass agile Software-Entwicklung nicht nur das Projektmanagement sondern auch die Struktur der Software selbst umfasst wird viel zu oft vergessen. Tim Kannig arbeitet das am Beispiel einiger Fintechs sehr schön heraus. Dort wurde nicht nur erkannt, dass ein modularer Aufbau den Austausch und Umbau einzelner Bestandteile stark vereinfacht - dieses Baukasten-Prinzip ermöglicht es sogar, die Module verschiedener Startups so zu kombinieren, dass am Ende ein vollwertiges "virtuelles Finanzhaus" steht. Und diese Bündelung ermöglicht nicht nur Online-Banking sondern auch Auslandsüberweisungen und sogar das deutschlandweite Abheben von Bargeld an einem ebenso schrägen wie naheliegenden Ort: den Supermarktkassen. Ich kenne einige Bank-Manager die das gerade sehr nervös macht. Zurecht.

  • Jason Little: Successful Agile Transformation through Community Building (Edit: Link ist mittlerweile tot)

    Jason Little bringt es zunächst auf den Punkt wie große Organisatoren an der Einführung agiler Methoden scheitern: Irgendjemand in der bereits bestehenden hierarchischen Struktur bekommt die Verantwortung übertragen, versucht einen Rollout nach dem "bisher bewährten Vorgehen", scheitert, versucht es nochmal, scheitert nochmal, gibt auf und führt stattdessen Cargo Cult ein. Um das zu vermeiden empfiehlt Little eine neue Art der Einführung: statt zentralisierter Verantwortung wird eine agile Community gegründet, die den Änderungsprozess dezentral vorantreibt. Fördern kann man diese durch die Beschränkung von Regeln auf das absolute Minimum, das Zulassen von Experimenten, die Einführung informeller Meeting-Formate (z.B. Lean Coffees) und regelmässiger Retrospektiven, das Zurückschneiden der Planung zum Jahresbeginn und die Vernetzung mit anderen agilen Organisationen. Eine Erfolgsgarantie ist das zwar nicht, dafür steigt aber die Wahrscheinlichkeit, dass Agilität wirklich entsteht und nicht nur simuliert wird, drastisch an.

  • Charles Edge: From Dungeon Master to Scrum Master - 15 Software Development Lessons from Dungeons and Dragons

  • Die IT ist eben doch ein Tummelplatz für sympathische Nerds. Über diesen Allgemeinplatz hinaus geht dieser Artikel von Charles Edge aber auf einen wichtigen Punkt ein: da man als Scrum Master seinen Job ohne Social Skills nicht machen kann, und da diese Skills in Studium oder Ausbildung nicht vermittelt werden, muss man sie irgendwoher sonst bekommen. Rollenspiele wären zwar nicht die erste Option die mir in diesem Zusammenhang einfallen würde, aber wenn es funktioniert - warum nicht? Und wenn man seine Auflistung sieht muss man ihm schon irgendwie recht geben. Es gibt definitiv Einiges was man dort lernen kann.

  • Katrina the Tester: What problems do we have with our test automation?

  • Ähnliche Situationen wie die hier beschriebene habe ich bei verschiedenen Kunden erleben dürfen. Automatisierte Testsuites können schnell zu komplex und schwerfällig werden, benötigen dann mitunter Stunden für die Ausführung, sind nur mit Mühe aktuell zu halten und sind nur noch eingeschränkt für Absicherungen häufiger Merges in den Master Branch nutzbar. Die Agilität der Softwareentwicklung geht dann zurück. An einem konkreten Beispiel aus ihrer Arbeit beschreibt Katrina Clokie Probleme, Lösungsansätze und Lerneffekte. Ein eher technischer aber trotzdem wichtiger und interessanter Blickwinkel.

Related Articles