Agile Softwareentwicklung - Nützliche Tricks für den Git-Alltag

In den Beiträgen Agile Softwareentwicklung - Software im Team entwickeln hatte ich mich mit den allgemeinen Begriffen (Contributor, Maintainer, Pull Request / Merge Request, Commit und Issue) beschäft und GitHub Flow kurz erklärt.

In der c't 17/2025 gibt es einen guten Beitrag zum Thema "Git-Stolperfallen im Alltag". Siehe https://www.heise.de/select/ct/2025/17/2519512434440349082.

Dabei werden folgende nützliche Tricks für den Git-Alltag gegeben:

• Wie kann ich verhindern, dass sensible Daten versehentlich in einem Commit landen?
• Stelle sicher, dass Dateien mit sensiblen Informationen (z.B. .env, config.json) in der .gitignore Datei aufgeführt sind.
  
• Wie finde ich heraus, welche Code-Zeile von welchem User kommt?
• git blame <dateiname>
• Für detaillierte Historie:
• git log -L :functionName:<dateiname>
• Für eine bestimmte Zeilenrange:
• git log -L 10,20:<dateiname>
  
• Wie behebe ich einen missratenen Commit vor dem Push? Ich vergesse häufig Dateien oder vertippe mich in der Commit-Nachricht. 
• git commit --amend
  
• In einem Projekt pflegen wir zahlreiche Branches und verlieren häufig den Überblick. Was können wir besser machen? 
• Ein konsistentes Namensschema hilft sofort beim Erkennen des Zwecks eines Branches
• feature/<ticket-id>-<beschreibung>
• bugfix/<ticket-id>-<beschreibung>
• hotfix/<beschreibung>
• release/<version>
  
• Ich habe ein Projekt gestartet, an dem nun weitere Leute mitwirken sollen. Wie sollten die Commits idealerweise aussehen, damit das Projekt wartbar bleibt?
•  Ein guter Commit sollte kurz, präzise und aussagekräftig sein. Ideal ist ein zweigeteilter Aufbau:
• Kurze Zusammenfassung (max. 50 Zeichen)
• Optional: ausführlichere Beschreibung (max. 72 Zeichen/Zeile)
• Ich habe zahlreiche unterschiedliche Änderungen an einer Datei vorgenommen, wie reiche ich diese in mehreren Commits ein? 
• Datei nicht direkt committen, sondern Änderungen stagen
• git add -p <dateiname>
  
• Ein Git-Repository soll auf einen anderen Server verschoben werden. Wie geht das am einfachsten? 
• Repository klonen und auf neuen Server pushen
• git clone --bare <url-zum-alten-repo>
• cd <repo-name>.git
• git remote add new-origin <url-zum-neuen-repo>
• git push --mirror new-origin

 

Agile - Argumentationswippe (Pro- und Kontra-Liste)

Gerade bei Retros im Team bzw einer größeren Gruppe werden Pro- und Kontra-Listen an einer Moderationswand gesammelt. Siehe auch zum Beispiel Siehe auch Agile - "Lifehack" Sammlung => Team-/Projekt Retrospektiven.

Eine digitale Alternative ist die Argumentationswippe (https://argumentationswippe.de). 

Die Retro-Teilnehmer sammeln ihre Argumente und können sie so auf die eine oder andere Seite der "Wippe" sortieren.

Agile - Wieso geht es ständig ums Feedback? Agiles Schiffe versenken!

In verschiedenen Beiträgen bin ich bereits auf das Thema "Warum eigentlich agil?" bzw. "Agile - "Lifehack" Sammlung Selbstmanagement und Kollaboration" eingegangen. Das Vorgehen ist natürlich in der Softwareentwicklung weit verbreitet, für Teams mit einem anderem beruflichen Kontext benötigt eine Umstellung jedoch viel Zeit.

Agiles Schiffe versenken als Antwort auf die Fragen:

• Wieso verändert sich ständig unser Ziel? 
• Wieso muss ich mich selbst organisieren? 
• Wieso reden wir ständig von Feedback?

 

Softwareentwickler Box UK hat eine Version "Schiffe versenken" entwickelt, bei der man im 1. Durchgang kein direktes Feeback zu möglichen Treffern erhählt. Im 2. Durchgang jedoch nach jedem Schuss eine Rückmeldung (ob Treffer oder nicht) bekommt.

In der anschließenden Statistik sieht man sofort, dass man mit direktem Feeback viel erfolgreicher ist!

Agile - Open Practice Library (Softwareentwicklung, Produktentwicklung und Teamkultur)

Die Innovation Labs des Softwareherstellers Red Hat betreiben die Website "Open Practice Library". Hierbei geht es um iterative Vorgehensmodelle zur schnellen Entwicklung digitaler Produkte. Das Team dokumentiert hier verschiedene Praktiken und Prinzipien, welche die Softwareentwicklungsprozesse vorantreiben.

Die Einträge sind anhand der Prinzipien Discovery, Options, Delivery und Foundation organisiert:

Quelle: Red Hat Open Innovation Labs - https://openpracticelibrary.com

Discovery-Praktiken beginnen mit dem aktuellen Ist-Zustand und sollen helfen, wichtige Fragen zu Ergebnissen zu stellen.

• Warum tust du das? Welche Probleme versuchen Sie zu lösen und für wen? Wie werden Sie die Ergebnisse messen?
• Siehe z.B. Why, How, What - The golden circle von Simon Sinek
  

Options-Praktiken untersuchen, wie man Erkenntnisse abwägen und möglicherweise die Richtung ändern kann.

• Welche Möglichkeiten hat das Team? Was benötigen Sie möglicherweise, um Ihre Zielergebnisse zu erreichen?
• Siehe z.B. How-Now-Wow Prioritization (Matrix)
  

Bereitstellungs-Praktiken konzentrieren sich darauf, die Optionen bereitzustellen, für die man sich entschieden hat, und Feedback von den Benutzern und Interessenvertretern einzuholen.

• Was war die gemessene Wirkung? Was hast du gelernt?
• Siehe z.B. Canary Release - Exposing a small number of real users to a new version

Grundlegende-Praktiken konzentrieren sich auf die Schaffung einer Teamkultur, Umgebungen für die Zusammenarbeit und technische Praktiken.

• Diese unterstützen schnelle und iterative Reisen durch die anderen Teile der Schleife.
• Ohne die Grundlage können Teams keine nachhaltige, kontinuierliche Bereitstellung erreichen.
• Siehe z.B. Daily Standup - A short time-boxed synchronization of the team activities that occurs in a cadence determined by the team

 

Agile Softwareentwicklung - Software im Team entwickeln (Glossar)

In dem Beitrag "Agile Softwareentwicklung - GitHub Flow notwendig?" habe ich den "GitHub Flow" kurz erklärt. Etwas näher möchte ich auf die allgemeinen Begriffe (Contributor, Maintainer, Pull Request / Merge Request, Commit und Issue) in der Softwareentwicklung im Team eingehen.

Contributor

Wenn jemand als Entwickler etwas zu einem Projekt beiträgt, der darf sich offiziell Contributor (Mitwirkender) nennen. Dies trifft auch dann zu, wenn man nur einen kleinen Tippfehler in der Dokumentation beseitigt, was für viele der Einstieg in ein Open Source-Projekte ist. Da die meisten Softwareprojekte in Regel bei GitHub oder GitLab verwaltet werden, kann man mit einem eigenen Account dort sofort mit der Unterstützung beginnen.

Maintainer

Nicht jeder, kann aber sofort Änderungen am Quellcode oder der Dokumentation vornehmen. Jedes Entwicklungsprojekt benötigt einen oder mehrere Maintainer (Betreuer). Sie haben die Berechtigung, eingereichte Änderungen zu akzeptieren und in den Quellcode aufzunehmen. Zudem kümmern Sie sich um geplanten Funktionen für neue Versionen und legen fest wohin sich das Projekt entwickelt soll.

Pull Request / Merge Request

Möchte man Änderungen an einer Software vornehmen, muss mann zunächst einen neuen "Fork" (Verzweigung) anlegen. Dies ist eine lokale Kopie der aktuellen Code Basis. Jetzt kann man all seine geplanten Änderungen vornehmen. Anschließend kann man einen Request mit seinen Änderungen an das Originalprojekt stellen. Bei GitHub und Bitbucket heißen diese Request "Pull Request" und GitLab nennt sie "Merge Request". Der Maintainer prüft nun die Änderungen und entscheidet, ob sie für eine Übernahme geeignet sind.

Commit

Hinweis: Die Befehle "git commit" und "svn commit" haben denselben Namen, sie unterscheiden sich aber voneinander! Siehe auch https://www.atlassian.com/de/git/tutorials/saving-changes/git-commit.

Hat man seine Änderungen fertiggestellt (z.B. die Programmierung eines neuen Moduls), erzeugt man einen Commit. Dadurch werden die Änderungen als Entwicklungsschritt in die Quellcode-Chronik mit aufgenommen und mit einer kurze Nachricht versehen. Hierdurch sehen auch die anderen Entwickler diese in ihrer Chronik.

Agile - (Online) Warm-up bzw. Kennenlernspiele

In dem Beitrag Agile - "Lifehack" Sammlung Selbstmanagement und Kollaboration bin ich auf das Thema "Daily-Stand-up Meetings" eingegangen. Gerade bei Online-Meetings spielen die Themen Vorbereitung, Moderation und Zeitmanagement eine sehr wichtige Rolle. Um das "Eis" bei Online-Meetings oder Konferenzen zu brechen, bieten sich vor dem eigentlichen Start Kennenlern-Spiele bzw. Warm-ups an.

Es gibt vermutlich zich hunderte Ideen für Workshop Spiele, anbei ein paar Beispiele für den Einstieg:

• Wichtig: Die Moderation sollte hierbei etwas vorschlagen, was zum Team passt und vor allem jeden zu Wort kommen lassen. Die Dauer sollte max. 5-8 Minuten betragen, um nicht den Fokus auf das eigentliche Meeting zu verlieren!

• Jeder malt für sich in einer Minute ein Tier, das die heutige Stimmung widerspiegelt. Anschließend zeigen alle die Ergebnisse und erklären sie gegenseitig kurz.
• Die Teilnehmer sollen in ihrem Arbeitszimmer (bei Homeoffice) einen Gegenstand einer bestimmten Farbe suchen und in die Kamera halten.
• Was müssten wir tun, damit das Meeting heute ein "Reinfall" wird?
• Was ist deine Superpower?
• Wenn Zeitreisen möglich wären, wohin würdest du reisen? Warum?

Viele weitere Ideen finden sich im Blog Wilde Workshop-Spiele.

Agile - Priorität und Qualität vom Shopify CEO (Tobias Lütke) lernen

In dem Artikel "Zeitmanagement - MoSCoW Priorisierung / Prinzip" habe ich beschrieben, wie man mit Hilfe des MoSCoW-Prinzip seine Aufgaben priorisieren kann. In dem Artikel "Shopify-Gründer Tobi Lütke: CEOs müssen die Hüter der Qualität sein" beschreibt Tobi Lütke welche Prioritäten man als guter CEO setzen soll.

Shopify bietet für kleine, mittelständische Händler und mittlerweile auch Konzerne ein einfach einzurichtendes Online-Shopsystem samt Hosting und Bezahldiensten.

Lütke empfiehlt die folgende Prioritätenliste, damit CEOs den Fokus auf die Qualität des Produktes setzen:

1. "Lasst uns das bestmögliche Produkt bauen."
2. "Wir müssen ab und zu Geld verdienen, damit wir Prio eins finanzieren können."
3. "Niemals Prio eins und zwei verwechseln."

"Ich finde es interessant, wie häufig Firmen das falsch herum machen. Das ist bis heute eigentlich mein Hauptjob bei Shopify: Herumrennen und jeden daran erinnern, dass es das Wichtigste ist, ein gutes Produkt zu machen. CEOs müssen die Hüter der Qualität sein."

Aus meiner Sicht kann man diese Prioritätenliste auch in der Softwareentwicklung anwenden, wenn es z.B. um "Softwaretest bei agiler Entwicklung durch Testautomatisierung" geht.

Cloud - Open-Source Software im Cloudumfeld

Nach der Vorstellung von "Cloud - Basics (Konzepte, Werkzeuge und Methoden)" gehe ich kurz auf die Open-Source Software im Cloudumfeld ein. Siehe auch CNCF Cloud Native Interactive Landscape.

Docker

• Freie Software der Firma Docker Inc. zur Containervirtualisierung.
  
  

Ansible und Terraform

• Mit Ansible werden die "Rezepte" erstellt, um Cloud Server bestellen und konfigurieren zu können und fungiert als Admin Kommandozeilenwerkzeug. Terraform eignet sich für die Bestellung der Cloud Server bei den Anbietern.
• 
  
  

Git, GitHub und GitLab

• Git ist eine Software zur Versionsverwaltung von Dateien, es lassen sich dabei verschiedene Entwicklungspfade zu verfolgen und so können mehrere Entwickler parallel entwickeln. Siehe auch Agile Softwareentwicklung - GitHub Flow notwendig?.
• GitHub ist einer der weltweit am bekanntesten Hoster für Git-Repositories inklusive Continuous Integration (CI) / Continuous Delivery (CD) Lösungen.
  
• GitLab ist eine Webanwendung zur Versionsverwaltung für Softwareprojekte auf Git-Basis, welche man selber hosten kann.
  
  

Kubernetes (k8s)

• Automatisiert den Betrieb von Container, sprich Kubernetes verwaltet somit die Cluster von Servern, die wiederum Container ausführen.
  
  

OpenStack

• Ist der "Baukasten" für Cloudserver und soll Unternehmen dabei unterstützen den Aufbau eigener Clouds zu erleichtern um die eigene digitale Souveränität zu gewährleisten.
  
  

S3 (Simple Storage Service)

• S3 wurde von Amazon entwickelt und kann man als Blockspeicherplatz-Angebot beschreiben. Dateien werden in Buckets (Ordner ohne Verschachtelung) abgelegt. Der Zugriff erfolgt über HTTP / HTTPS. Es ist sehr gut skalierbar und somit wird es gerade von Dropbox oder auch Netflix zum Ablegen von Dateien aller Art verwendet.
  
  

Cloud Native Computing Foundation (CNCF)

• Ein Projekt der Linux Foundation um Cloud Computing, Microservices und Containervirtualisierung zu fördern.
• Siehe auch https://github.com/cncf/landscape/blob/master/README.md#trail-map.

 

Cloud - Basics (Konzepte, Werkzeuge und Methoden)

Nach meinem Artikel "Cloud - Pizza as a Service: Was hat eigentlich "Pizza" mit Cloud Services zu tun?" gehe ich in diesem Beitrag auf die "Cloud Basics" ein. Hierbei handelt es sich um Werkzeuge und Methoden, welche vor einer möglichen Umsetzung / Einführung / Migration unbedingt bekannt sein sollten.

CI/CD (Continuous Integration/Continuous Delivery)

Release early, release often - Mit Hilfe der CI/CD-Pipelines, welche in einem agilen Softwareprojekt zwingend erforderlich sind, welche den Prozess des fortlaufenden Zusammenfügens von Komponenten hin zu einer Anwendung garantieren, müssen Änderungen am Quellcode bzw. neue Funktionen nicht mehr bis zum nächsten großen Release gesammelt werden. Siehe auch "Agile Softwareentwicklung - GitHub Flow notwendig?".

Änderungen am Quellcode, die in der Versionsverwaltung eingecheckt werden, können sofort automatisch von Skripten getestet (siehe auch Softwaretest bei agiler Entwicklung durch Testautomatisierung) und zu einem auslieferungsfähigen Paket verpackt werden.

Die Tools der Wahl sind hier zum Beispiel Jenkins (build, test, and deploy their software) oder GitHub Actions, GitLab (end-to-end software development platform with built-in version control, issue tracking, code review), Maven (build automation tool used primarily for Java projects) und Nexus (software repository manager).

Cloud-Native

Entwickler bezeichnen Software als Cloud-Native, welche die Vorteile der Cloud im eigenen Rechenzentrum (Flexibilität, Skalierbarkeit und Reproduzierbarkeit) bieten. Die Software ist daher in der Regel für den Betrieb in Containern (Raspberry Pi - Docker installieren) optimiert und kann somit auf eigenen oder auf gemieteten Servern laufen.

Container

Hier erfolgt eine Isolierung von Anwendungen mit Hilfe von Containervirtualisierung (siehe z.B. Raspberry Pi - Docker Compose installieren). Sie nutzen den Kernel des darunterliegenden Betriebssystems und blockieren somit keinen Arbeitsspeicher und haben nur eine sehr geringe Bootzeit. Alle Abhängigkeiten sind enthalten, dadurch lassen sich Container schnell starten, vervielfältigen, auf anderen Servern oder auch ganze Rechenzentren übertragen.

DevOps

Die Entwickler und der Betrieb / Service einer Software (Development und Operations) werden bei diesem Modell nicht hart getrennt, sondern arbeiten eng miteinander zusammen. Flexible Mietserver und Konzepte aus dem Cloudumfeld (zum Beispiel CI/CD) unterstützen dabei, die DevOps Methoden umzusetzen.

Hybrid 

In der Regel wird nicht die komplette Serverinfrastruktur eines vorhandenen Rechenzentrums durch Cloud-Infrastruktur ersetzt. Dies ist vor allem der Fall, wenn es um besonders sensible Daten geht. Die lokale Software sollte aber idealerweise "Cloud-Native" sein, damit Hybride Strategien gut funktionieren. Die restliche Software kann dann in der flexiblen Public Cloud betrieben werden.

laaS (Infrastructure as a Service)

Hierbei handelt es sich eigentlich um Marketing Kreation der Cloud Anbieter. Hierbei kann man Angebote oder Dienste zum Minutenpreis mieten, oft auch Platform as a Service (PaaS) genannt. 

Infrastructure as Code

Die Infrastruktur lässt sich immer wieder neu einrichten. Die jeweils gewünschte Konfiguration wird z.B. in Dateien mit YAML-Format beschrieben. Mit Hilfe von Terraform oder Ansible erfolgt dann die Umsetzung im Cloud-Umfeld.

Public Cloud & Private Cloud

Siehe hierzu auch "Hybrid" Beschreibung oben, Public Cloud sind Angebote für flexibel abgerechnete Server und weitere Dienstleistungen. Private Cloud sind eigene physische Server, welche zum Beispiel mit der Software Open Stack verwaltet werden.
Unternehmen, die idealerweise mit cloud-nativen Tools arbeiten, haben sie die Möglichkeit ihre Dienste jederzeit aus der "Private Cloud" in eine "Pubilc Cloud" zu migrieren.

 

Semantic Versioning

Es handelt sich um eine Standardisierung der Software-Versionierung. Sie besteht aus drei Zahlen (1.3.08) besteht: Die major version (1), minor version (3) und patch version (08). Siehe auch https://semver.org/lang/de/.

SaaS (Software as a Service)

Analog zu IaaS, Software wird zum Monatspreis an Kunden vermietet. Man muss sich nicht um die Administration, Updates oder Backups der Software kümmern. In der Regel laufen die Anwendungen auf Cloud-Infrastruktur wie zum Beispiel Amazon (aws).

Vendor Lock-in

Beschreibt die Befürchtung, dass man mit der Entscheidung für eine Software oder Service im Dienstleisteruniversum eingesperrt ist. Dies kann man mit der Verwendung von Open-Source-Software aus dem Cloud-Native-Umfeld umgehen. Als Beispiel ist hier Kubernetes als Plattform für seine Container und eigenen Betrieb von Open-Source-Software selbst genannt.

Agile - "Lifehack" Sammlung Selbstmanagement und Kollaboration

Die nachfolgenden Themen zur besseren Selbstorganisation und Kollaboration werden immer wieder von mir selber verwendet. Daher gibt es in diesem Artikel eine Sammlung meiner bisher veröffentlichen "Lifehacks". Bleibt agile!

Lifehacks - Büro, Effizienz, Zeitmanagement, Selbstmanagement, Tasks

• Warum eigentlich agil?
• Scrum: Manifest der agilen Softwareentwicklung
  
• Scrum: Werte & Prinzipien
• Scrum: Rahmen (Werte)
  
• Eisenhower Matrix: Priorisiere was dringend und wichtig ist
• Effizienz - "Arbeit geht den Weg des geringsten Widerstandes" 
• E-Mail - Posteingang mit der richtigen Strategie bearbeiten (Inbox Zero Methode)
  
• TaskBoard/Kanban Board: Übersicht über aktuelle Aufgaben
• Taskplaner Vorlage für Ihr Zeitmanagement
• Daily-Stand-up Meetings: Effiziente Status Meetings, tägliche Besprechungen im Stehen
• Agile - Zusammenarbeit und Regeln für (virtuelle) verteile Teams
• Timeboxing: (Wirklich) feste Zeitvorgaben
• Agile - Framework OKR (Objectives and Key Results)
  
• Stakeholder Management: RASCI (Responsibility Assignment Matrix) 
• Aus dieser Matrix geht hervor, welche Team-Mitglieder wofür im Projekt verantwortlich sind.
  
• MoSCoW Priorisierung / Prinzip: Auftragsklärung
• Good Enough: Nutzen Sie das Parkinsonsche Gesetz oder Pareto
• Gehen Sie effizient mit E-Mails um!
  
• Dot Voting: Schnell zu einer demokratischen Entscheidung kommen
• Cloud - Pizza as a Service
• Templates: Strukturierte Zusammenfassung von Aufgabenstellungen und Ergebnissen
• Flipchartvorlage - Agenda
  
• Team-/Projekt Retrospektiven: Feedback geben und einholen für Verbesserungen
• Scrum - Sprint / Team Retrospektive 
  
• Kommunikation - Feedback, 5 Finger Feedback
  
• Stacey-Matrix: Welches Team für welche Aufgabe
• SMARTe Ziele: spezifisch, messbar, attraktiv, realistisch und terminiert
  
• Schlüssel zur Produktivität? Konzentrieren Sie sich auf eine Aufgabe!
  
• Kontextverluste - (Zeit-)Verschwendung durch Projektwechsel bzw. Multitasking
  

Lifehacks - Kommunikation, Kollaboration

• Rituale (Being)
• Check-in (Wochenstart,Besprechungsbeginn)
• Check-out (Wochenende,Besprechungsende)
• Virtuelle Kaffeemaschine
• Monatliche Being Rituale
• Scrum - Sprint / Team Retrospektive
  
• Achtsamkeit und Empathie
• Kommunikation - Aktives Zuhören und GFK (Gewaltfreie Kommunikation) 
• Kommunikation mit Gesprächspartnern
  
• Erfolge feiern: Party mit dem Team!!!
• Being: Wie geht es uns, bei dem was wir tun?
• Why, How, What - The golden circle von Simon Sinek
• Fehler - Arten von Misserfolgen
• Fehler - "0-Fehler" Strategie
  

 

Agile - Framework OKR (Objectives and Key Results)

Im agilen Framework OKR (Objectives and Key Results) zur Strategieumsetzung dauern Zyklen ca. 3 Monate. Es hilft dabei Organisationen, sich an Wirkungszielen auszurichten und sich auf diese zu fokussieren.

Wichtig, für den o.g. Zeitraum müssen die Ziele auch beschreiben werden, damit das Unternehmen diese in den Fokus stellen kann. Zudem spielt die Frage WHY (Warum und wofür ist es wichtig?) eine zentrale und erinnert sehr stark an den golden circle von Simon Sinek .

Folgende Regeln sind zu beachten und erinnern dabei stark an die Werte & Prinzipien von Scrum :

• Maximal vier Objectives (entspricht den Zielen) mit maximal je vier Key Results (klare, zeitlich begrenzte und messbare Vorgaben, wie die Ziele erreicht werden können) pro Team.

Sehr hilfreich um OKR zu verstehen, ist das folgende Video "Why the secret to success is setting the right goals von John Doerr" einem ehemaligen Mitarbeiter von Andy Grove dem Mitbegründer der Firma Intel, welcher die Idee zu Objectives and Key Results hatte,

Zum Schluss noch eines meiner agilen Lieblingszitate:

"It does not make sense to hire smart people and then tell them what to do. We hire smart people to tell us what to do." (Steve Jobs)

Kontextverluste - (Zeit-)Verschwendung durch Projektwechsel bzw. Multitasking

In dem Buch Quality Software Management: Congruent Action schlägt Gerald Weinberg eine Faustregel zur Berechnung der (Zeit-)Verschwendung vor, die durch Projektwechsel verursacht werden.

So wirkt sich selbst das Hinzufügen eines einzelnen Projekts zur aktuellen Arbeitslast nach Weinbergs Berechnung äußerst schwächend! Man verliert mindestens 20% seiner Zeit!

Muss man zum Beispiel ein weiteres drittes Projekt betreuen, wird fast die Hälfte der Zeit für das Wechseln von Aufgaben (KONTEXTVERLUST) verschwendet.

 

 

Wenn man sich auf ein einzelnes Projekt konzentriert, kann man 100% seiner Zeit darauf verwenden. 

 

Sobald man jedoch mit dem Multitasking von Projekten beginnt, steigt der Effizienzverlust massiv!

 

Nach der Schätzung von Weinberg verliert man 

• 20% seiner Zeit, wenn man gleichzeitig an 2 Projekten arbeitet, 
• 40% an 3 Projekten und bis zu 
• 75% an 5 Projekten. 

Die ständige Ablenkung der Gedanken zwischen den verschiedenen Aufgaben oder Projekten ist extrem zeit- und energieintensiv.

Scrum - Sprint / Team Retrospektive

Die Sprint Retrospektive findet am Ende des Sprints statt. Hierbei überprüft das gesamte Scrum Team seine Arbeits- und Verhaltensweise während des Sprints, um im nächsten Sprint noch effektiver und effizienter arbeiten zu können.

Ablauf

• Es sollte eine angenehme Atmosphäre für das Team geschaffen werden,
• z.B. durch den Raum, der Umgebung und dem Zeitpunkt,
• jedes Teammitglied sollte Zeit für die Vorbereitung auf den Termin haben.
• Die Daten werden vom Scrum Master gesammelt (Erkenntnisse und Einsichten) und z.B. auf einem „Board“ festgehalten.
• Abschließend werden Aktionen und Verbesserungsmöglichkeiten daraus abgeleitet.

Beispiel

• Eine Pinnwand mit den Symbole: "Gewitter", "Regen", "Sonne".

Quelle: https://cdn.pixabay.com/photo/2013/07/12/12/53/weather-forecast-146472_1280.png

• Jeder im Team bekommt 3 Karten, für jede Kategorie eine und gibt Feedback zu den folgenden Fragen:
  
• Gewitter - Was hat mich im letzten Sprint wütend gemacht hat?
• Regen - Was hat mich im letzten Sprint traurig gemacht hat?
• Sonne - Was hat mich im letzten Sprint froh gemacht hat?
  

Eine nächste (Team) Retrospektive steht an und man hat keine Ideen für einen Ablauf? Dann kann ich die Seite https://retromat.org/de/ empfehlen. Hier kann man sich zufällig Ideen für eine Retro generieren lassen.

Kommunikation - Feedback, 5 Finger Feedback

In agilen Projekten sind "offene Information- und Feedback-Prozesse" sehr wichtig. Auch sollte man in seinen Projektteam immer ehrliche und aufrichtige Anerkennung geben. In diesem Beitrag möchte ich kurz auf Feedback Möglichkeiten eingehen.

Wie kann man Feedback geben und somit auch die "Scrum Werte" berücksichtigen?

1. Feedback Möglichkeit anbieten.
2. Positive Rückmeldung sollte zuerst gegeben werden.
3. Die Rückmeldung muss konkret sein und sollte eine Beschreibung bzw. Beispiel beinhalten.
• Wichtig, jeder ist für sich selbst verantwortlich und spricht nur für sich.
• Nicht: Wir alle sind total verärgert. => Sondern: Ich habe mich geärgert über xyz.
4. Formulierung einer konkreten Bitte bzw. eines Vorschlags, aber KEINER Forderung.
5. Der Dialog dabei ist sehr wichtig (den anderen sehen/erkennen, nicht Recht haben wollen).

 

Eine weitere gute Methode, ist die „Fünf-Finger-Methode“.

Quelle: Landesmedienzentrum Baden-Württemberg, https://www.lmz-bw.de/medien-und-bildung/medienwissen/medienbildung/definitionen-von-medienkompetenz-und-methoden/methoden/feedback-hand/

Why, How, What - The golden circle von Simon Sinek

Die Anforderungen werden bei Scrum nicht in Use Cases (Anwendungsfälle), sondern in User Stories erfasst. User Stories (Anwendererzählung) beschreiben GUIs, Funktionalitäten und Testszenarien.

Als „Anwender“ will ich „Eigenschaft/Feature“ Damit „Nutzen“.

Einen ähnlichen Ansatz verfolgt auch der "golden circle" von Simon Sinek.

In dem Buch Frag immer erst: warum: Wie Top-Firmen und Führungskräfte zum Erfolg inspirieren  beschreibt Sinek, dass die Menschen von einem Sinn für Ihre Absichten (dem "Warum") inspiriert sind. Daher sollte das WHY (Warum und wofür ist es wichtig?) bei der Anforderungsbeschreibung an erster Stelle stehen, bevor man mit dem "Wie" und "Was" in die Detaillierung geht.

Sinek nennt diese "Triade" den goldenen Kreis, beschrieben in einem Kreis-Diagramm mit

• "Why / Warum" im innersten Kreis, der die Motive oder Zwecke darstellt. Umgeben von einem Ring mit der Bezeichnung
• "How / Wie" hier werden die die Prozesse und Methoden dargestellt (Wie willst du dein Ziel erreichen?). Eingeschlossen mit der Bezeichnung
• "What / Was" welcher die Ergebnisse darstellt (Was machst du um dein Ziel zu erreichen?).

Quelle: Wikipedia (The golden circle diagram, redrawn from Start with Why - Mosborne01)

Warum eigentlich agil?

Das Scrum Manifest der agilen Softwareentwicklung definiert agile Methoden nach z.B. der Eigenschaft das sich Prozesse während der gesamten Projektzeit ständig weiterentwickeln und immer wieder neu bewertet müssen. Aber warum ist man überhaupt gezwungen agile Methoden zu verwenden?

Eine gute Antwort auf die Frage bietet mein Blog Eintrag vom April 2020  "Digitalisierung - The Six D's of Disruption". Mit Hilfe des Modells kann man verstehen, wie Technologien bzw. Digitalisierung uns beeinflussen.

In letzten Jahren kam es immer schneller zu einer "Demokratisierung" und Technologien sind immer schneller mehr und mehr Menschen zugänglich. Dies führt zu einem Verschwinden von alten Technologien bzw. kompletter Berufszweige. Die folgendene Grafik zeigt die Anzahl der Jahre, bis die aufgeführten Technologien eine Reichweite von 50 Millionen Nutzern erlangt hatten. So hatte Facebook bereits nach 3,5 Jahren 50 Millionen Nutzer. Das Telefon benötigt 75 Jahre für 100 Millionen Nutzer, das Fernsehen benötigte 13 Jahre und Candy Crush nur 1,3 Jahre bis es eine Nutzerschaft von 50 Millionen erreicht hatte.

Quelle: https://www.visualcapitalist.com/how-long-does-it-take-to-hit-50-million-users/

Definition Agilität

Schnelle Reaktions-(Adaptions-)fähigkeit in einer komplexen Welt. Siehe hierzu auch "Die Komplexität von Scrum bzw. eines Projektes kann durch die Stacey Matrix dargestellt werden".

Die Themen Unsicherheit und Komplexität könne auch gut durch das Akronym VUCA beschrieben werden, welches sich aus den vier Begriffen Volatilität (Unstet - schneller Wandel - Flüchtigkeit), Unsicherheit (Unberechenbarkeit - keine Strategien), Komplexität (Multioptionen -
Vernetzung - Schnelligkeit) und Ambiguität (Mehrdeutigkeit - Multifaktoriell - verwirrend) zusammensetzt.


AGILE => "Always run a changing system" anstatt "Never change a running system"!

Agile - Zusammenarbeit und Regeln für (virtuelle) verteile Teams

In der agilen Softwareentwicklung bietet z.B. Scrum bereits  Regeln, wie "Scrum: Werte & Prinzipien - Empowered, self-organized teams" und "Der Scrum Rahmen ist ein Zusammenspiel von der Organisation, dem Produkt und dem Team" vor. Gerade in Zeiten von Corona und Homeoffice empfiehlt es sicher daher für (virtuelle) verteile Teams Richtlinien zu definieren.

Folgende Grundsätze können als Basis für die Zusammenarbeit in virtuellen Teams verwendet werden:

• Für alle Mitglieder im Team sollten Kernerreichbarkeitszeiten definiert werden, wie zum Beispiel von 09:00 bis 11:00 Uhr und von 13:00 bis 15:00 Uhr. In dieser Zeit sollte dann auch jeder zu erreichen sein.
• Wichtig: Arbeiten die Teams ggf. in verschiedenen Zeitzonen, müssen diese Kernzeiten ggf. angepasst werden.
• Eine "Definition of Done (DoD)" sollte definiert werden, damit allen im Team klar ist, ab wann einen Aufgabe wirklich als "erledigt" gilt.
• Meetings bzw. Regeltermine sollte nur während der Kernarbeitszeiten stattfinden.
• In einem kurzen "Daily" Meeting analog dem "Daily Scrum" sollte der Fortschritt aller Mitglieder transparent kommuniziert werden.
• Vorgaben für den Krankheitsfall bzw. eine Vertretung innerhalb des Teams müssen vorab definiert werden.
  
  

Fazit: Die o.g. Vorgaben können nur als Idee dienen. Die Teams sollten gemeinsam die Regeln definieren und nach einer gewissen Zeit immer wieder auf den Prüfstand stellen. Gerade hierbei spielt eine offene und ehrliche Feedbackkultur eine wichtige Rolle.

Agile Softwareentwicklung - GitHub Flow notwendig?

Ist der GitHub Flow bei einem agilen Entwicklungsteam überhaupt noch notwendig?

 

GitHub Flow kurz erklärt

Wird eine neue Funktion in einem Softwareprojekt entwickelt, dann erstellt der Entwickler in der Regel einen "neuen Branch". Ist die Entwicklung der neuen Funktion abgeschlossen, wird ein "Pull Request" erstellt und zusammen mit dem Team besprochen. Mit Hilfe von automatischen Tests (siehe auch Unit-Tets - Was ist automatisches Testen?) wird sichergestellt, dass der neue bzw. angepasste Quellcode auch funktioniert. Anschließend kann der zuvor neu erstellte "Branch" in den "Master-Branch" übernommen werden.

Siehe hierzu auch "Following the GitHub flow":

Quelle: https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/github-flow#following-the-github-flow

Continuous Integration (CI) / Continuous Delivery (CD)

Mit Hilfe der CI/CD-Pipelines, welche in einem agilen Softwareprojekt zwingend erforderlich sind, welche den Prozess des fortlaufenden Zusammenfügens von Komponenten hin zu einer Anwendung garantieren, müssen Änderungen am Quellcode bzw. neue Funktionen nicht mehr bis zum nächsten großen Release gesammelt werden. Auch das "große" gemeinsame Testen und das "Live setzen" zu einem festgelegten Termin ist nicht mehr erforderlich. Siehe auch Softwaretest bei agiler Entwicklung durch Testautomatisierung .

Kleine Anpassungen sollten immer so schnell wie möglich getestet und abgenommen werden, damit diese sofort veröffentlicht werden können. Die sogenannten "Release Branches" sind damit hinfällig.

Wenn jede kleine neue Funktion oder Korrektur von Fehlern (Bugs) nach erfolgreicher Testautomatisierung und Abnahme durch den Fachbereich im Live System zur Verfügung steht, dann werden auch keine "Hotfixes" mehr benötigt (Hotfixes = Feature). Fehlerbehebungen müssen somit nicht in einer "veralteten Version" erfolgen (Forward Fixing und nicht Rolling Back).

Was bleibt zum Schluss übrig?

Die Entwickler arbeiten nur noch mit dem "Master-" und dem "Feature-Branch".

RAM Speicher - Steckplatz frei?

Ob man seinen PC noch um einen weiteren Riegel Arbeitsspeicher aufrüsten kann, erfährt man mit Hilfe des Task-Manager von Windows 10.

Der Start des Task-Manager erfolgt z.B. über die "Taskleiste" oder mit Hilfe der Tastenkombination "Strg+Umschalt+Esc". Anschließend "Mehr Details" und "Arbeitsspeicher" anklicken.

Firefox - command line option, start from a batch file

Will man nach dem Starten von Windows direkt mit seinen Lieblingswebseiten surfen, bietet sich beim Firefox Browser die folgenden Möglichkeiten per "command line" oder "batch file" an.

Aufruf per command line (cmd):

"C:\Program Files\Mozilla Firefox\firefox.exe" -new-window "http://www.ebay.de/" -new-window "https://www.mydealz.de/" -new-window "https://mail.google.com/mail/u/0/#inbox"


Aufruf per batch file (.bat):

@echo off
start "" "C:\Program Files\Mozilla Firefox\firefox.exe" -new-window "http://www.ebay.de/" -new-window "https://www.mydealz.de/" -new-window "https://mail.google.com/mail/u/0/#inbox"