Hallo, meine Frage richtet sich an Entwickler (kleinere Gruppe) - welchen Workflow nutzt ihr (z.B. mit git) - es gibt im Netz zahlreiche mit allen möglichen Vor- und Nachteilen. Was nutzt ihr und warum? Wo gibt es Probleme? Viele Grüße,
:
Verschoben durch Moderator
Beitrag #6904588 wurde von einem Moderator gelöscht.
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.
Wäre schön wenn die Kollegen git statt zip benutzen würden… (nicht mal die Autokorrektur kennt git).
Theoretisch bietet Git das genialste Feature überhaupt. Die einzelnen Teams committen ihren Murks in ihr eigenes Repository. Und die Maintainer pullen nur das Brauchbare in den Master. Funktioniert in der Praxis nicht. Wahrscheinlich, weil alle Firmen lieber wirr zusammen gestückelten Murks ausliefern, als zugesagte Termine verschieben. Und da der Maintainer eh nicht entscheiden kann, was in den Master aufgenommen wird, committen alle Chaoten direkt in den Master. Die verschiedenen Push-Workflows unterscheiden sich eigentlich gar nicht. Die Entwicklerteams schieben ihre größten Knalltüten in irgendwelche Meetings ab, in denen sie über Worksflows und sonstige irrelevante Themen diskutieren. Außerdem hoffe ich, das mit den irrsinnig komplexen Workflows geht bald wieder zu Ende. Und wir bekommen wieder Prozesse, bei denen jeder Programmierer durchblickt, weiß wo er bei Problemen hin langen muss.
Noch ein Kommentar schrieb: > Wahrscheinlich, weil alle Firmen lieber wirr zusammen gestückelten Murks > ausliefern, als zugesagte Termine verschieben. Es gibt auch Firmen die beide Verfahren kombinieren! Noch ein Kommentar schrieb: > Außerdem hoffe ich, das mit den irrsinnig komplexen Workflows geht bald > wieder zu Ende. Überhaupt keinen Prozess zu haben ist auch unschön. Da weiß man auch nicht wo man Probleme suchen soll.
Noch ein Kommentar schrieb: > Funktioniert in der Praxis nicht. Du hast wohl schlimme Erlebnisse hinter dir. Wo arbeitest du? Nicht dass ich mich aus versehen mal dort bewerbe.
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.
Angehängte Dateien:
-
git.png
48 KB
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...
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. Wegen der Protokoll-Funktion nutze ich es auch zu hause für mich ganz alleine. 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.
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.
:
Bearbeitet durch User
Rolf M. schrieb: > Hmm, Jira ist ein Issue-Tracker. Ich weiß nicht so ganz, was du in dem > Zusammenhang mit "Arbeitsabläufe koordinieren" meinst. In einem Issue-Tracker kann man Anforderungen, sich daraus ergebende Arbeitspakete, und natürlich Bugs verwalten. Diese kann man dann untereinander sowie mit Branches, Merge Requests und Commits verlinken, sodass immer nachvollziehbar ist, wo was warum(!) bearbeitet/repariert wurde. Wenn ein Fehler erneut auftritt, kann man über das Issue sofort alle relevanten Änderungen im Code finden und schauen, was da noch getan werden muss. Diese Funktionen bieten alle gängigen Issue Tracker, wie z.B. die in GitLab, GitHub oder Azure DevOps integrierten. Die Verwendung von Merge Requests mit daran gekoppelter CI und Acceptance Tests ermöglicht die Prüfung von Änderungen. So bekommt man eine natürlich wachsende Dokumentation des Codes, und jedes Teammitglied kann nebenbei auch verfolgen was im Projekt so geschieht. Wer drauf steht kann sich auch Burn-Down-Charts anzeigen lassen. Letzten Endes spart man sich so viel Arbeit und Unsicherheit. Das ist natürlich alles nicht mehr git-spezifisch und funktioniert auch mit anderen VCS. Viele Unternehmen scheuen aber die Umgewöhnung und verfolgen eben lieber ihre Lieblingsstrategie: Programmierer schrieb: > Das ganze Team committet nach Belieben direkt auf master Bei sicherheitskritischer Zertifikation ist es auch wichtig nachvollziehen zu können, was warum implementiert/verändert wurde - bei dieser "nach Belieben"-Strategie ist das natürlich nicht möglich, und es gibt dann früher oder später ein böses Erwachen. Ich habe gehört dass manche Projekte daher doppelt so lange brauchten wie geplant, weil bei der Zertifizierung auffiel dass nichts dokumentiert ist und alles nachgearbeitet werden musste.
Rolf M. schrieb: > Jira ist ein Issue-Tracker. Ich weiß nicht so ganz, was du in dem > Zusammenhang mit "Arbeitsabläufe koordinieren" meinst. Aufgaben verteilen und den Bearbeitungsstatus dokumentieren. Programmierer schrieb: > Diese Funktionen bieten alle gängigen Issue Tracker, wie > z.B. die in GitLab, GitHub oder Azure DevOps integrierten. Deswegen hatte ich gefragt, ob er eventuell GitLab anstatt Git meinte.
> People and interactions over processes and tools.
Die Sache ist total aus dem Ruder gelaufen.
Bis 2000 rum hatten uns die Tools immer mehr Arbeit abgenommen.
Inzwischen sind die Hilfsmittel so umfangreich - wir brauchen mehr Zeit
für Konfiguration, Einarbeitung und Fehlersuche als wir mit den neuen
Prozessen und Tools einsparen.
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.
Die Tools sind gut genug. Da kann man irgend eines der weit verbreiteten
benutzen. Macht keinen Unterschied.
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.
Sheeva P. schrieb: > Es sind Kommunikationsmodelle die dabei helfen sollen die zunehmende > Komplexität in der Entwicklung besser beherrschen zu können 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.
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: > Große und komplexe Projekte sind auf Mikrocontrollern bereits aus > Ressourcengründen eher die Ausnahme Es gibt jede Menge Controller mit vielen Megabytes an Speicher, mehreren Cores, Hunderten MHz an Taktfrequenz, und einer Leistung wie ein PC vor 20 Jahren. Und da laufen auch entsprechend komplexe Projekte drauf, mit vielen 100kLoC. Die ganzen Hobbyfrickler hier im Forum haben halt sowas nicht auf dem Schirm.
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.
Ich habe SCRUM in zwei Konzernen an den Rahmenbedingungen scheitern erlebt. - Es wird ein Auftrag nach Wasserfall Modell erstellt - Es wird ein Angebot erstellt und angenommen - 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 Will sagen: Wenn man agil entwickelt, dann gilt das auch für die Mitarbeit des Auftraggebers, sein Budget und die Verfügbarkeit von Test-Ressourcen. Sonst funktioniert es nicht. Die Vorstellung, dass SCRUM eine Arbeitsmethode alleine für das Programmier-Team sei, ist völlig falsch. Steckt aber leider so in den Köpfen einiger Entscheider. Vermutlich wurde SCRUM teilweise falsch vermarktet. Seit ungefähr 5 Jahren arbeite ich woanders, wo man agile Methoden vernünftig und erfolgreich anwendet.
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: > An dieser Stelle ist jedes agile Entwicklungsmodell aber schon tot. Erzähle das Managern. Leider ist es dafür zu spät, das Kind ist längst in den Brunnen gefallen. Wie sie es wieder heraus geholt haben, habe ich nicht mehr mit bekommen. Nur die Info, dass meine ehemalige Abteilung kurz nach meinem Weggang geschlossen wurde.
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.
Beitrag #6914469 wurde von einem Moderator gelöscht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.