Wie organisiert ihr euren Software Entwicklungsprozess im Team?

[fanc48]

Im RAD-Studio steht hier unter Anforderungsverwaltung der Satz: "Mit den Tools für die Anforderungsverwaltung können Sie Anforderungen für Ihr Software-Projekt hinzufügen, entfernen und aktualisieren." Darüber hinaus finde ich aber keine Hinweise/Erläuterungen welche Tools Delphi & RAD-Studio da entweder selbst zur Verfügung stellen oder welche dort gemeint sind.

Was ich suche sind dabei eure Konstellationen die ihr in eurer Praxis der Softwareentwicklung mit Delphi in (mehreren kleinen) agilen Teams (scrum oder kanban) einsetzt, die alle gleichzeitig an verschiedenen Modulen/Projekten zusammenhängender Softwaresysteme/-produkte arbeiten. Dabei möchte ich folgende Rahmenbedingungen gewährleisten.

Es gibt eine Vision/Architektur und Roadmap was das Gesamtsystem und die einzelnen Module im groben Umfang leisten sollen und dies ist dokumentiert entwickelt/verändert sich in annehmbaren Rahmen auch über lange Zeiträume hinweg, betrifft tatsächlich aber auch bestehende Module bzw. es kommen regelmäßig komplett neue Anforderungen/externe Systeme mit denen ebenfalls interagiert werden soll und neue Technologien dazu. Von Zeit zu Zeit auch komplett neue agile Entwicklungsteams an neuen Standorten bzw. Teams verlassen auch das Gesamtprojekt.

Wir arbeiten mindestens nach kanban, überwiegend aber nach scrum in 14 Tage Sprints. Dabei sollen die Anforderungen der Kunden in gepflegten Backlogs landen und entsprechend des scrum Frameworks abgearbeitet werden. Bugs getrennt davon erfasst und ebenfalls entsprechend der Prio`s gelöst werden und insgesamt dabei ein Dokumentation und regelmäßig Releases erzeugt werden die der Roadmap folgen und das gesamte Softwaresystem systematisch voran treiben, dass es aus Sicht des Kunden für ihn immer wertvoller wird (bleibt) und er damit seine eigenen Ziele immer besser erfüllen kann.

Wie habt ihr euch aufgestellt/organisiert das ihr den "roten Faden" in eurer Softwareentwicklung halten könnt, den Gesamtzusammenhang transparent und nachvollziehbar dokumentiert und den gesamten Entwicklungsprozess so gestaltet das ihr diesen selbst stetig weiter optimieren könnt? Wie haltet ihr möglichst Tool / Lnk. / kontextbasiert den Zusammenhang zwischen Vision - Architektur - Roadmap - use cases / Task / Anforderung aus dem (Sprint)Backlog - zum Quellcode - zur Doku im Quellcode / in der Programm-/Release Dokumentation und das ganze auch zurück.

Ich möchte gerne auf einen Sprint-Backlog Eintrag, einen Punkt in der Roadmap, eine Feature-Beschreibung in der Dokumentation oder einen Bug gehen und auch noch Jahre später nachvollziehen können wo die relevanten Stellen im Quell-Code, in der Doku und in der Roadmap dazu sind ohne das ich mir das alles mühsam von Hand zusammenfummeln muß und dabei immer die Sorge habe irgendein Detail übersehen oder nicht erkannt zu haben. Wie geht ihr da aktuell in eurer Praxis vor? Wie sieht nach eurer Meinung dazu eine ideale Gesamtkonstellation aus wenn ihr die Möglichkeit hättet mit diesem Anspruch auf einer grünen Wiese zu starten? Vielen Dank für eure Antworten. Ich bin sehr gespannt wie ihr das seht und würde da sehr gerne von euch lernen.

[himitsu]

Wir nutzen ein selbstgehostetes Redmine (mit ein paar Erweiterungen und eigenen kleinen Anpassungen).
Teilweise nutzen wir auch im GitHup dann noch die Möglichkeit dort Pull-Requests in Projekten zu verwalten (synchronisiert mit Redmine), dafür was dann in welchen Versionen landet / zurückgemerged wird.

Beim Commit Push von SQL, ins Github, wird ein eignes CI gestartet, welches das durchtestet und erst wenn erfolgreich, wird der Merge freigeschaltet.
Für Delphi hab ich FinalBuilder inzwischen so weit, dass man dort auch etwas ins CI bekommen könnte, inkl. dem automatischen Build und Upload des Setups,
sowie anschließendem/vorhergehendem Test (innen fehlt noch, aber da ist alles noch SOOO verschachtelt, dass kaum möglich ... aber erstmal haben wir daher mit TestComplete angefangen und lassen die wichtidten Module der GUI durcharbeiten)

Embarcadero selbt nutzt inzwischen Jira
https://www.atlassian.com/jira-software

[fanc48]

Hallo himitsu,

vielen Dank für deine Antwort, dass sind schon entscheidende Hinweise, Danke dafür. Ich bin gespannt was ihr noch so an Konfigurationen benutzt, Gruß Frank.

[Uwe Raabe]

Ich bin zwar hier nur ein 1-Mann-Team, aber auch dafür muss man sich ja entsprechend organisieren um am Markt bestehen zu können. Durch meine Arbeit mit verschiedenen Teams konnte ich reichlich Erfahrungen sammeln und diese auch weitergeben. All diese Erfahrungen versuche ich in meiner eigenen Umgebung anzuwenden, was in einem stetigen Entwicklungsprozess immer noch nicht endgültig ist - wenn es das je sein wird. Aktuell sieht das hier so aus:

Nach langen Jahren mit FogBugz (Issuetracker) und Kiln (VCS), deren Bedienung und Integration mich anfangs wegen ihrer Leichtigkeit überzeugt hatten, stelle ich seit ein paar Monaten meine Projekte auf Azure DevOps um. Die Integration zwischen DevOps Boards und den Git Repositories ist sogar noch besser als die Vorgängerkombination und bringt auch agile Methoden (Scrum, Kanban) schon gleich in den Grundlagen mit, so dass es nicht wie bei anderen System irgendwie aufgesetzt wirkt. Das System bietet reichlich Möglichkeiten zur Anpassung und Erweiterung, die man sich nur zu benutzen trauen muss, um den individuellen Arbeitsfluss so passgenau wie nur möglich abzubilden. Die zwar komplexen, aber sehr leistungsfähigen REST-Apis erlauben nicht nur eine weitgehend automatische Übernahme aus dem Alt-System, sondern machen auch eher spezielle Aufgaben abseits vom Mainstream möglich.

Für das Build kommt ContinuaCI zum Einsatz, das in Kombination mit FinalBuilder kaum Wünsche offen lässt. Passend eingerichtete Events und Konnektoren sorgen für die Tags im VCS und die Verlinkung zu den Issues. So kennt jeder Bug nicht nur die Commits für seinen Fix, sondern auch das zugehörige Release. Ein neues Release ist somit auf einen Klick erstellt, verteilt und an der passenden Stelle mit den entsprechenden Release-Notes bereitgestellt. In der Realität sind am Ende eher die Sicherheitsbedenken der IT die einschränkende Kraft, wo es die technischen Möglichkeiten noch erlauben würden.

[fanc48]

Vielen Dank Uwe, das alles spricht für eine sehr fundierte Basis. Einiges was du ansprichst kenne ich noch nicht einmal, hier werde ich mich etwas schlau machen, Danke, Gruß Frank.

[Bernhard Geyer]

Wir haben 3 Wichtige Komponenten

1. Jira: Bug/Issue-Tracking und auch für die Aufnahme von Kunden-Kommunikation (Bugs/Anfragen/...I
   BigPicture in Jira um die Epen in eine Art Zeitplan (Gantt) zu bringen
2. Confluence für Dokumentation, welche über die sinnvoll in einem Ticket unterzubringenden Infos bzw. Info die Länger sinnvoll nötig sind
3. Git (Hier BitBucket) als Quellcodevewaltung. Mit starker Kopplung ans Jira

Die Kombination ist nicht ganz billig, aber wüsste nicht wie man heutzutage in Teams/Firmen ohne diese Tools (ob nun von Atlassian oder von anderen Hersteller) auskommen könnte.

[Uwe Raabe]

Zitat von Bernhard Geyer:

Die Kombination ist nicht ganz billig, aber wüsste nicht wie man heutzutage in Teams/Firmen ohne diese Tools (ob nun von Atlassian oder von anderen Hersteller) auskommen könnte.

Sehe ich auch so. Eine professionelle Softwareentwicklung passt eben nicht zu einer Kostenlos-Mentalität.

[himitsu]

Jupp, wir haben es auch erst mit kostenlos/günstiger versucht.

Ach ja, hier auch Scrum (so in etwa) im Redmine
und Freischalten von PullRequests teilweise mit automatischen Checks (aktuell nur SQL) und zusätzlich noch durch einen Review ... erst wenn Check erfolgreich und Review erledigt, lässt sich im Github mergen (direkter Commit/Merge/Push in Master nicht erlaubt) ... alles via Trigger im Github geregelt.

Github (früher SVN) mit Redmine verbunden, so dass der die Tickets ihre Commits kennen (autmoatisiert Redmine-Link im Commit gefunden, bzw. manuell der Redmine-Link im PullRequest und der Pull-Request als Feld im Redmine ... könnte man bestimmt auch noch automatisiert untereinander verlinken)

[jsheyer]

Wir nutzen für unsere Team folgende Tools:

• Redmine mit dem Agile Plugin für unser Kanban Board und Issues
• Redmine Wiki zur Dokumentation
• Diverse Plugins für Redmine die das Arbeiten verbessern.
• Gitea für unsere Source Code Verwaltung über die auch die Pull-Request laufen
• Jenkins als CI/CD der auch automatisiert die Unit Test ausführt und das Ergebnis auch in Gitea widerrum meldet
• Ranorex für automatisierte Oberflächen Tests
• Datenbank automatisierte Test um Trigger und Stored Procedure zu testen (Vergleichsweise wie ein Unit Test)
• Testlink zur Dokumentation und Nachweis von manuellen Testabläufen

Wir hatten vorher auch die Atlassian Tools im Einsatz, mit dem Zwang zur Cloud mussten wir davon Abschied nehmen und ich muss sagen ich habe es nicht bereut und wir vermissen nichts und redmine, gitea, etc sind erheblich performanter als die Attlassian Tools.

[freimatz]

Zitat von fanc48:

Im RAD-Studio steht hier unter Anforderungsverwaltung der Satz: "Mit den Tools für die Anforderungsverwaltung können Sie Anforderungen für Ihr Software-Projekt hinzufügen, entfernen und aktualisieren."

Davon lese ich heute auch zum ersten Mal.
Da wir aus RAD Studio eh auch noch andere verwenden für unser Produkt kommt eine Verwaltung darüber eh nicht in Frage.
Nomralerweise bekommt commit in der Beschreibung die Nummer der Aufgabe in der Planungssoftware mit reingeschrieben. Viel mehr haben wir da auch nicht. Immerhin kann man später Änderungen im Code "blamen" und kommt dann vielleicht drauf, warum oder wozu jemand was gemacht hat. (Ansonsten ist unser Entwicklungsprozess zu komplex als dass man das in einem Beitrag erörtern könnte.)