Zum Inhalt springen

Blogeintrag

Täglich Zeit und Nerven sparen - Automatisierung in der Softwareentwicklung

Projekt- & Produktmanagement  Programmierung & Code  Tools 

Wenn wir heute von "Automatisierung in der Softwareentwicklung" sprechen, dann denken die meisten von uns sicher an CI/CD, einige vielleicht an ANT oder MAKE. Auch Test-Automatisierung kommt uns in den Sinn.

Allerdings gibt es in der Softwareentwicklung viele nicht wertschöpfende Tätigkeiten, die sich gut automatisieren lassen.

Warum das Automatisieren von wiederkehrenden Schritten so wertvoll ist und wie das in der Praxis umsetzbar ist zeigt dieser Beitrag.

Hinweis: Die Inspiration zu diesem Newsletter-Beitrag stammt von The Composition.com

Exkurs: In Japan sagt man "Muda"

Japanischer Fischer

Wenn wir von "wertschöpfend" und "nicht wertschöpfend" sprechen, dann meinen wir "erzeugt unmittelbar Nutzen für den Kunden".

Überlegen Sie einmal selbst - für welche Tätigkeiten würden Sie als Kunde bezahlen?

  • Konzeption einer Architektur? - Ich tippe auf "ja". 
  • Warten auf den Build (oder den Drucker)? - hier tippe ich auf "nein".

Bei Toyota kam für nicht wertschöpfende Tätigkeiten der Begriff "Muda" auf, der soviel bedeutet wie "Verschwendung" – mir persönlich hilft allerdings das Akronym "D-O-W-N-T-I-M-E" weiter, man kann es sich sehr gut merken.

Ich übersetze die "8 Verschwendungsarten" einmal für Sie, und gebe jeweils Beispiele:

  • Fehlerzustände. Aufwände erzeugen um etwas falsch zu machen, damit man anschließend Aufwände erzeugt um die Fehlerzustände zu finden und zu korrigieren. Hier hilft professionelles Test Management weiter.
  • Überproduktion. Eine Story implementieren, die noch niemand benötigt oder testen kann? Dieses zu verhindern ist Aufgabe des Product Owners
  • Warten. Entwickler warten auf eine neue VM, das Operations-Team wartet auf eine Info zu IP und Port einer Komponente - hier helfen Tools wie Chef oder Puppet weiter.
  • Ungenutzte Fähigkeiten. Ihr Datenbank-Admin ist ein Dokumentationstalent, aber wir stellen stattdessen einen Technical Writer ein.
  • Transport  und  Lagerung. Diese beiden sind die Folge von Überproduktion. Alles beginnen, nichts fertigstellen hat nichts mit Effektivität zu tun - versuchen Sie es einmal mit Kanban-Boards mit WIP-Limits.
  • Bewegung. Hier geht es um Aufwände, die nichts mit der Erstellung des Produkts zu tun haben - später mehr dazu.
  • Über-Bearbeitung - gemeint sind "Bells and Whistles", die über die Umsetzung der Akzeptanzkriterien hinausgehen. Stimmt schon, wir alle wollen stolz auf unsere Arbeit sein - aber vertrauen wir dem Requirements Engineering, statt Features zu implementieren, die (noch) nicht angefordert wurden. Das Problem ist nämlich meist, dass diese "Über-Bearbeitung" niemandem berechnet werden kann.

Wir verfügen nun also über ein Hilfsmittel, um verschiedene Tätigkeiten auf ihren Mehrwert hin untersuchen zu können. Im nächsten Schritt wenden wir dieses Konzept nun auf die Softwareentwicklung an.

Nicht wertschöpfende Tätigkeiten beim Programmieren

Nicht wertschöpfend

Schauen wir uns die Verschwendungsart "Bewegung" einmal genauer an. In Industriebetrieben ist sofort klar, was hier gemeint ist: Ein Werkzeug holen. Material suchen.

Programmieren ist doch eine zutiefst kreative Tätigkeit! Was soll daran automatisiert werden - und dabei nicht wertschöpfend sein?

Betrachten wir einmal zwei Beispiele:

  • Ich beginne mit der Arbeit an einer neuen Story. Ich muss also
    • Die Story im Jira auf "In Progress setzen"
    • Einen Branch im Git anlegen
    • Entwickeln
    • Einen Pull Request anlegen
    • Die Story im Jira wieder aktualisieren
    Nachdem wir oben gesehen haben, wie sich Tätigkeiten in "wertschöpfend" oder "nicht wertschöpfend" klassifizieren lassen - für welche der genannten Tätigkeiten würden Sie als Kunde gern zahlen? (Tipp: nur eine Antwort ist richtig). Für alle anderen empfehlen wir die Integration von Jira mit Ihrem Repository, um diese Tätigkeiten schnell und einfach zu automatisieren. Selbst ein automatischer Upload in ein Artifactory ist möglich!
  • Nächstes Beispiel:
    Als Teil eines Epics müssen neue API-Endpunkte angelegt werden. Ich muss hierfür:
    • Die Funktionen als Rumpf anlegen, evtl das Model anpassen
    • Die Routen eintragen
    • Die Controller schreiben
    Auch hier wieder: Kreativ war das eigentlich nur beim ersten Mal. Mit Hilfer der Doku haben wir herausgefunden wie man REST-API-Endpunkte anlegt. Beim zweiten Mal war dies schon weniger aufregend und beim 10. Mal? Routine. 

Routine an sich ist ja nichts schlechtes werden Sie sagen - "es geht routiniert von der Hand" ist ein Zeichen für ein tiefgehendes Verständnis, da ist jemand von dem man einiges lernen kann.

Handlungsbedarf besteht nur dann, wenn "Routineaufgabe" einen signifikanten Teil unseres Tagespensums ausmachen - und am Ende bleibt kaum noch Zeit, um etwas Neues zu entwickeln.

Dieser Trend kann durch Automatisierung durchbrochen werden - Tools wie Scriptrunner helfen hier weiter.

Schöne neue Welt

Notizzettel

Automatisieren schön und gut, aber Skripten ist ja nichts Neues. Intuitiver als Shell-Skripting sind da etwa die Smart Commits von Bitbucket, bei denen bestimmte Kommandos in der Commit Message dann Aktionen auslösen.

Wie wäre es aber, wenn wir einfach in ein Chat-Fenster schreiben könnten "Hey Bot, leg mir bitte einen API-Endpunkt an!"? 

Moderne Chat- und Collaboration Tools wie Slack oder Hipchat bieten zusätzlich zu den Basisfunktionen die Möglichkeit, bei bestimmten Kommandos Webhooks aufzurufen. Umgekehrt können Ereignisse auch direkt in den Chat eingeblendet werden.

Beides zusammen ergibt eine "Konversation", und genau dies ist die Idee hinter Atomist.

Fazit

Wir haben gesehen, dass nicht alle Tätigkeiten im Softwareentwicklungsprozess Wertschöpfung sind. Vielleicht machen uns einige davon Spaß oder wir sind stolz zu wissen wie es geht - aber der Lerneffekt und Wissensaustausch ist dabei eher gering.

Wenn wir also einen Schritt wie das Branchen oder das Anlegen von API-Endpoints hinreichend gut verstanden haben, dann wird es Zeit diese Schritte zu automatisieren. Ich möchte an dieser Stelle Seneca zitieren: "Docendo discimus." Das Automatisieren hat nämlich den großen Vorteil, dass das Skript dem Wissensaustausch dient und eine optimale Prozessdokumentation darstellt (Stichworte CMMI und Audits).

Die Schritte werden reproduzierbar, der Prozess stabil und unser Kopf ist frei für die wirklich wichtigen Dinge - das Entwickeln großartiger Produkte.

Wenn wir Ihre Neugier geweckt haben, kontaktieren Sie uns!

Kontakt für Anfragen

Johannes Bergsmann

johannes.bergsmann@software-quality-lab.com

 +43 5 0657-420
 +43 676 840072 420

Fachlicher Kontakt

Martin Brüggemann

martin.brueggemann@software-quality-lab.com

 +43 5 0657-137