git - welchen Workflow nutzt ihr?

Noch ein Kommentar schrieb:

> Funktioniert in der Praxis nicht.

Bei uns funktioniert das.

> Und da der Maintainer eh nicht entscheiden kann,
> was in den Master aufgenommen wird,

Genau da ist der Fehler. Der Maintainer muss das Standing haben um sowas 
ablehnen zu können. Bei uns ist der Maintainer ein erfahrener 
Entwickler, der auch am Produkt mitentwickelt. Welche Features 
aufgenommen werden wird in Absprache mit ihm entschieden. Sein Chef 
steht dabei hinter ihm.

Und ja, ich kenne jemanden der das wirklich so ähnlich gemacht hat....
da gab's dann regelmäßig eine Kopie von seinem Working-dir mit dem Datum 
im Ordnernamen...

gitter schrieb:
> welchen Workflow nutzt ihr (z.B. mit git)

Bei uns in der Firma entspricht der offizielle Workflow weitestgehend 
dem gitflow:
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Wie sehr der dann auch tatsächlich gelebt wird, steht auf einem anderen 
Blatt und hängt auch vom jeweiligen Projekt ab. Er kann aber immer als 
Orientierung dienen.

Programmierer schrieb:
> Das ganze Team committet nach Belieben direkt auf master, vermurkst
> dabei gerne auch die Zeilenendungen (Windows vs. Unix), und bei
> Merge-Konflikten fragt man den git-Guru im Team.

So ungefähr sieht es öfter mal aus :)

Stefan ⛄ F. schrieb:
> Für mich ist Git kein Tool um Arbeitsabläufe zu koordinieren, sondern um
> die Änderungen von Team-Mitgliedern zusammen zu führen und zu
> protokollieren.

Das stimmt, aber die Durchführung und Zusammenführung der Änderungen 
muss auch wiederum koordiniert werden, sonst hat man das oben genannte 
Chaos. Alle commiten wild kreuz und quer ihr Zeug, der Code läuft 
ständig nicht oder compiliert gar nicht erst, keiner hat den Überblick 
und die Leute überschreiben sich gegenseitig ihre Änderungen, was 
nebenbei dann noch zu Merge-Konflikten führt. Und eine vernünftige 
Release kann man auch nicht machen.
Daher ist es besser, wenn man die einzelnen Features und Bugfixes in 
eigenen Branches bearbeitet und nach Abschluss dann einen Merge macht. 
Damit lässt sich nachher auch viel leichter nachvollziehen, wofür man 
eine bestimmte Änderung gemacht hat und umgekehrt, welche Änderungen man 
konkret für ein bestimmtes Thema durchgeführt hat.
Bei git ist branching und merging ein integraler Bestandteil eigentlich 
aller gängigen Workflows. Das muss man erst mal lernen, wenn man von 
anderen Versionierungstools kommt, wo das meistens nicht so intensiv 
gemacht wird.

> Wegen der Protokoll-Funktion nutze ich es auch zu hause für mich ganz
> alleine.

Solange man es alleine nutzt, braucht man meistens nicht viel workflow.

> Wo ich gerade arbeite werden Arbeitsabläufe mit Jira Ticket koordiniert.
> Das ist nicht gerade das allercoolste und komplexeste Produkt, aber für
> uns reicht es.

Hmm, Jira ist ein Issue-Tracker. Ich weiß nicht so ganz, was du in dem 
Zusammenhang mit "Arbeitsabläufe koordinieren" meinst.

Noch ein Kommentar schrieb:
> Dieser ganze Srum-Kult - jeder kann alles und jeder darf überall
> mitreden - funktioniert einfach nicht.

Naja, für das, wofür er gedacht war, funktioniert er.
Früher™ haben gute Programmierer gute Software geschrieben.
Markt ist leer, "echte" Programmierer findet man kaum noch.
SCRUM ist eine Methode, wie man mit einem Sack voll Affen eine 
halbfertige Bananen-Software hinbekommt.
Dafür funktioniert es gut.
Über die Architektur macht sich da keiner Gedanken, es wird halt "agil" 
hingepfuscht bis das CI-Tool nicht mehr meckert.
Und am Schluss wundert sich das Controlling, warum man für den 
Software-Betrieb monatlich viele $$$$$ an AWS überweisen muss, obwohl es 
vom reinen Durchsatz & Rechenleistungsanspruch auch ein (überspitzt) 
RasPi erschlagen hätte.

Εrnst B. schrieb:
> Noch ein Kommentar schrieb:
>> Dieser ganze Srum-Kult - jeder kann alles und jeder darf überall
>> mitreden - funktioniert einfach nicht.
>
> Naja, für das, wofür er gedacht war, funktioniert er.

Ja, das tut er.

> Früher™ haben gute Programmierer gute Software geschrieben.
> Markt ist leer, "echte" Programmierer findet man kaum noch.
> SCRUM ist eine Methode, wie man mit einem Sack voll Affen eine
> halbfertige Bananen-Software hinbekommt.

Nein.

> Dafür funktioniert es gut.

Nein, dafür funktioniert keine Methode.

> Über die Architektur macht sich da keiner Gedanken, es wird halt "agil"
> hingepfuscht bis das CI-Tool nicht mehr meckert.
> Und am Schluss wundert sich das Controlling, warum man für den
> Software-Betrieb monatlich viele $$$$$ an AWS überweisen muss, obwohl es
> vom reinen Durchsatz & Rechenleistungsanspruch auch ein (überspitzt)
> RasPi erschlagen hätte.

Tatsächlich war es in der alten Welt der "echten Programmierer" so daß 
sich am Anfang ein paar Rübennasen hingesetzt und Lasten- und 
Pflichtenhefte gebastelt haben. Das hat aus Gründen leider eher schlecht 
als recht funktioniert. Gründe waren und sind:

- Software wird zunehmend komplexer
- Entwicklerteams werden größer
- Anforderungen ändern sich
- Vorgaben ändern sich
- Vorhersagen sind Unfug
- ... und tausend andere Gründe.

Das Ergebnis war daß die meisten Softwareprojekte ihre Zeitpläne und 
Budgets nicht einhalten konnten.

Das fanden alle Beteiligten nicht so richtig gut und ein paar Cleverle 
haben daraufhin Methoden ersonnen wie man es besser machen kann. Ein 
zentraler Punkt dieser Ideen war unter anderem auch die altbekannte 
Weisheit daß Fehler umso schwerer und teurer werden sind je länger sie 
existieren.

Wie wäre es wenn man den Kunden früher in den Entwicklungsprozeß 
einbeziehen würde damit die Fehler und Schwächen in den Lasten- und 
Pflichtenheften früher auffallen und behoben werden können? Wie kann man 
die Entwickler dazu bringen besser miteinander zu kommunizieren?

Und genau um diese Themen geht es bei den Agilen Methoden. Mir stellen 
sich die Fußnägel auf wenn ich lese oder höre daß das 
Entwicklungsmodelle seien. Es sind Kommunikationsmodelle die dabei 
helfen sollen die zunehmende Komplexität in der Entwicklung besser 
beherrschen zu können und mehr Projekte innnerhalb der Zeit- und 
Budgetgrenzen umzusetzen.

Daß so etwas in einem Form wie diesem auf Ablehnung stößt wundert mich 
jedoch keineswegs. Große und komplexe Projekte sind auf Mikrocontrollern 
bereits aus Ressourcengründen eher die Ausnahme und schon einige 
C-Bibliotheken für diese Plattformen enthalten nicht einmal eine 
dynamische Speicherallokation.

Aus ähnlichen Gründen sind die Entwickler von Mikrocontrollersoftware 
auch die einzigen Communities auf der Welt in denen noch über Assembler 
versus C versus C++ versus Python gestritten wird. Nur die wenigsten 
Mikrocontrollerentwickler haben je an hochkomplexer Software mit 
mehreren hundertausend Zeilen Code (plus Bibliotheken) gearbeitet und 
kennen diese Art von Komplexität nicht. Sie kennen ohne Frage eine 
andere Art von Komplexität. Die ist aber nicht dasselbe!

Agile Softwareentwicklung kann eine feine Sache sein wenn man sie 
richtig macht. Wenn nicht sind es Schmerzen an einem Ort über die der 
Gentleman nicht redet.

Noch ein Kommentar schrieb:
> Ich selbst arbeite an einem 20 Jahre alten Programm. Die Firma hat
> mehrmals die Tools gewechselt. Der einzige Effekt: Wir können nicht mehr
> rekonstruieren, warum wir damals so unsinnige Entscheidungen getroffen
> hatten. Die alten Bugreports und Diskussionen sind verschwunden.
> Dieser ganze Srum-Kult - jeder kann alles und jeder darf überall
> mitreden - funktioniert einfach nicht.
> Ein Softwareprojekt braucht einen kompetenten charismatischen Leiter.
> Und Spezialisten, die Talent für Teilbereiche wie Architektur, User
> Iterface, Kodierung, Testfälle und so weiter haben.

Weder schafft dir Scrum an deine Tools wie Unterhosen zu wechseln, noch 
dass du keine Spezialisten haben darfst.

Sheeva P. schrieb:
> Wie wäre es wenn man den Kunden früher in den Entwicklungsprozeß
> einbeziehen würde damit die Fehler und Schwächen in den Lasten- und
> Pflichtenheften früher auffallen und behoben werden können? Wie kann man
> die Entwickler dazu bringen besser miteinander zu kommunizieren?
>
> Und genau um diese Themen geht es bei den Agilen Methoden.

Auch. Für mich ist das Stichwort "Änderungen". Das Problem bei 
klassischen Entwicklungsmethoden ist, dass Änderungen eher 
stiefmütterlich behandelt werden. Beim Wasserfall sind sie überhaupt 
nicht vorgesehen. Da wird am Anfang einmal alles komplett durchgeplant 
und dann nur noch abgearbeitet. Wenn sich nun irgendwann die 
Anforderungen ändern (was sie heute in dynamischen Projekten oft tun) 
oder man merkt, dass der Ansatz nicht passt, muss man noch mal ganz 
zurück und hat einen sehr hohen Aufwand, um die Änderungen einzubauen. 
Du schreibst es ja eigentlich schon selbst oben:

> - Anforderungen ändern sich
> - Vorgaben ändern sich
> - Vorhersagen sind Unfug

Bei agilen Modellen sind Änderungen dagegen ein integraler Bestandteil 
des Entwicklungsprozesses. Die Planung wird nicht einmal beim Start 
gemacht und ist dann in Stein gemeißelt, sondern wird zyklisch an die 
aktuelle Situation angepasst. Die Schleife, die man drehen muss, um 
Änderungen zu integrieren, ist viel kleiner und daher weniger aufwändig. 
Natürlich spielt die Kommunikation da auch eine wesentliche Rolle.

Jürgen schrieb:
> Was hier unauffällig unter den Tisch fallen gelasden wird ist die zu
> beherrschende, ebenfalls ansteigende Komplexität der Methoden und Tools
> selber. Bürokratie mit Bürokratie zu bekämpfen ist eine heikle
> Angelegenheit die schnell aus dem Ruder läuft = alles unter dem Strich
> noch komplizierter macht. Hier hinterfragt man besser zuerst die
> Komplexität des Produkts selber und die der Werkzeuge zu seiner
> Herstellung.

Vielen Dank daß Du meinen Beitrag gelesen hast. Aber das Problem bei der 
neuen Komplexität sind nicht zunehmend komplexer werdende Werkzeuge 
sondern zunehmend komplexer werdende Anwendungsfälle. Oder anders gesagt 
lösen wir heute ganz neue Probleme und die Werkzeuge und 
Entwicklungsprozesse passen sich dem an. Wenn Du magst empfehle ich Dir 
gerne den folgenden Beitrag:

https://www.youtube.com/watch?v=zIKZKkPtmNs

Rolf M. schrieb:
> Bei agilen Modellen sind Änderungen dagegen ein integraler Bestandteil
> des Entwicklungsprozesses. Die Planung wird nicht einmal beim Start
> gemacht und ist dann in Stein gemeißelt, sondern wird zyklisch an die
> aktuelle Situation angepasst. Die Schleife, die man drehen muss, um
> Änderungen zu integrieren, ist viel kleiner und daher weniger aufwändig.
> Natürlich spielt die Kommunikation da auch eine wesentliche Rolle.

Das ist der Punkt auf den ich hinaus wollte. Es passiert mir zunehmend 
oft daß ich einen Beitrag von Dir lese und insgeheim niederknien möchte. 
Einer mehr. :-]

Stefan ⛄ F. schrieb:
> Ich habe SCRUM in zwei Konzernen an den Rahmenbedingungen scheitern
> erlebt.

Was Du im Folgenden beschreibst ist nicht agil und schon gar nicht 
SCRUM.

> - Es wird ein Auftrag nach Wasserfall Modell erstellt
> - Es wird ein Angebot erstellt und angenommen

An dieser Stelle ist jedes agile Entwicklungsmodell aber schon tot.

> - Danach beginnt die Entwicklung in Iterationen ungefähr nach SCRUM,
> aber ohne Beteiligung des Auftraggebers (Ziel und Kosten stehen ja fest)
> - Zu einem festen Termin muss geliefert werden, weil genau dann und nur
> dann die Testsysteme + Personal bereit stehen.
> - Man findet Fehler, die zwangsläufig nach dem Liefertermin behoben
> werden.
> - Die Korrekturen können mangels Ressourcen nicht ordentlich getestet
> werden

Was Du da beschreibst ist in der agilen Entwicklung einfach nur Mist. 
Daß das so ist liegt weder an Deiner völlig korrekten Beschreibung 
dessen was heute leider immer noch stattfindet noch daran daß agile 
Kooperationsmodelle falsch wären.

Agile Entwicklung ist zuerst eine organisatorische Angelegenheit. 
Kommunikation halt. Das hat auch mit Vertrauen zu tun: mit dem Vertrauen 
Deiner Vorgesetzten und dem des Kunden. Dem Vertrauen seiner und Deiner 
Leute zueinander. Vertrauen entsteht aber nicht von allein...

Seitdem ich agile Methoden kenne und die Software in meinem Kopf 
aktualisiert habe arbeite ich wesentlich entspannter und entwickle 
bessere Software. Kunden sind jetzt Freunde und ich bin (meistens) 
zufriedener mit meinen Ergebnissen.

Sheeva P. schrieb:
> Es passiert mir zunehmend oft daß ich einen Beitrag von Dir lese und
> insgeheim niederknien möchte. Einer mehr. :-]

Oh, danke. Ich fühle mich geehrt.