Wasserfall & Kanban?

[twisted]

Hey,

ich frage mich momentan welches Vorgehensmodell ich in meinem Projekt wirklich verwendet habe.

Der Ablauf der Dokumentation ist ja relativ Linear (zumindestens im Pflichtenheft der IHK) aufgebaut.

Analyse > Planung > Realisierung > Qualitätssicherung > Abschluss > Doku

Diese festgelegte Abfolge der Phasen ist ja nicht Agil sondern nach dem Wasserfallmodell (Wenn ich das richtig verstanden habe). Erst die eine Phase, dann die nächste.

In meinem Projekt habe ich mich an diese Phasen gehalten. Da wir mit Gitlab arbeiten war eine Anforderung das ganze Projekt und die Teilaufgaben in Gitlab in einem Kanban Board zu managen.

Ich habe also die Teilaufgaben in dem Board angelegt, Milestones und Deadlines hinzugefügt. Dann die Tasks nach Priorität geordnet und täglich den in Gitlab aktualisiert.

Dennoch verlief das ganze Projekt sehr linear. Das Kanban Board wurde so eigentlich nur zur besseren Übersicht gewählt und weil es eben Vorgabe war, Agil war an dem Vorgehen aber nichts wirklich.

Meine Frage nun, ist das überhaupt legit? Also Kanban mit einem Wasserfallmodell zu verbinden und eben nicht agil zu entwickeln?

LG

 

[Defneqon]

vor 17 Minuten schrieb twisted:

Dennoch verlief das ganze Projekt sehr linear. Das Kanban Board wurde so eigentlich nur zur besseren Übersicht gewählt und weil es eben Vorgabe war, Agil war an dem Vorgehen aber nichts wirklich.

Da hast du es doch.

Kanban ist im Übrigen eine Workflow-Optimierung und kein richtiger Entwicklungsprozess. So wie sich das anhört, wurde dann bei dir das Projekt sehr wahrscheinlich linear, sprich mit Wasserfall umgesetzt. Allerdings ist heutzutage (so jedenfalls mein Gefühl und in meinem Betrieb) oft eine Mischung aus agilen Komponenten und Wasserfall vertreten.

Um blöden Fragen im Fachgespräch aus dem Weg zu gehen, würde ich an deiner Stelle einfach Wasserfall sagen und gut ist.

 

EDIT: Ich habe auch eine wilde Mischung in meine Doku geschrieben: Analyse / Entwurf war mehr oder weniger iterativ, um immer eine realistische Aufwandschätzung abgeben zu können und weil zu dem Zeitpunkt eher noch nichts umgesetzt wurde. Ab Implementierung wird dann klassisch verfahren.

Bearbeitet 16. Mai 2019 von Defneqon

[Pixelfuchs]

Der "Wasserfall" kann durchaus iterativ sein. Das steht sogar so im Original-Paper. Das müsste das Original-Paper sein, auch wenn der Begriff "Wasserfall" darin gar nicht vorkommt: http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf

Das Wasserfallmodell läuft grundsätzlich linear ab. Eine Phase muss abgeschlossen sein und ein (Gesamt-)Ergebnis  haben, welches abgenommen wird, bevor es in die nächste Phase geht. Wenn sich dann in einer späteren Phase herausstellt, dass eine vorherige Phase unvollständig war, kann jedoch zurückgesprungen werden und das Ganze wird nochmal (neu) betrachtet. Dabei wird nicht nur die Änderung betrachtet, sonder noch einmal ein Blick auf das Ganze geworfen. Danach geht es dann, nach einer erneuten Abnahme, wieder mit der folgenden Phase weiter.

Die "agilen" Methoden sind hingegen inkrementell und iterativ. Das Ziel ist es möglichst früh einen Prototypen zu haben. Die Weiterentwicklung erfolgt anhand der gemachten Erfahrungen mit dem bisher entwickelten System. Das Produkt entwickelt sich Stück für Stück weiter, ohne das das große Ganze vorher in einem Dokument vorgeplant wurde. Die Dokumentation wird dabei auf das nötigste beschränkt. Siehe hierzu auch das agile Manifest.

[Rienne]

Streng genommen kann man ein IHK Projekt gar nicht agil Umsetzen, da bereits vor Beginn des Projektes der Umfang fix vorgegeben ist und auch das Ziel definiert werden muss. So etwas agil zu machen und zu begründen ist mMn (und der Meinung unserer damaligen Berufsschullehrer/Prüfer), nicht ganz einfach.

Wie @Defneqon schon geschrieben hat, ist Kanban auch kein Modell oder eine Methode, sondern ein Werkzeug. Ich würde einfach das erweiterte (!) Wasserfallmodell (dieses erlaubt das zurückspringen in vorherige Phasen) zugrunde legen und eben ggf. darauf eingehen, dass du das Vorgehen für dich angepasst hast und dir Werkzeuge aus der agilen Entwicklung zur Hilfe genommen hast. Hauptsache du kannst begründen, warum du das gemacht hast und es für dich eine "gute Wahl" war.

 

[Whiz-zarD]

Wie @Defneqon schon sagt, Kanban ist keine agile Methode um Software zu entwickeln. Kanban macht eigentlich nur den Prozess transparent und zeigt die Schwächen eines Prozesses auf, wie z.B. wenn ständig das WIP-Limit (Work in Progress) überschritten wird. Das bedeutet dann, dass die Mitarbeiter zu viele Dinge gleichzeitig tun müssen.

"Agil" geistert seit einigen Jahren als Buzzword durch die IT-Welt aber man sollte sich fragen, was das Wort überhaupt bedeutet?
Agil heißt nämlich nicht, dass alles chaotisch verläuft und jeder tun und machen kann, was er will und einfach mal kurz in die Entwicklungsabteilung schreien kann und die Entwickler machen es schon. "Agil" heißt im Grunde "Kommunikation" und zwar auf allen Kanälen. Man entwickelt nämlich nicht Monate lang ein Pflichten- und Lastenheft, sperrt die Entwickler sechs Monate ein und raus kommt ein unfertiges Produkt, sondern man kommuniziert kontinuierlich mit dem Kunden und erörtert, was gut ist und was Verbesserungen bedarf. Das setzt auch voraus, dass der Kunde was sehen und anfassen kann. Sprich, es müssen in kurzen Abständen benutzbare Software-Releases bereitgestellt werden, die dann der Kunde begutachten kann. Auch darf der Kunde jeder Zeit neue Wünsche äußern. Die Software entwickelt sich also in kleinen Schritten und bei solchen Schritten ist es dann schwierig sowas wie Meilensteine zu setzen, weil man nicht weiß, wie sich der Prozess entwickelt. Kann ja sein, dass ein Feature mehrere Runden drehen muss, bis es dem Kunden passt. Das müssen jetzt nicht unbedingt Softwarefehler sein, sondern einfach z.B. dass der Kunde selber nicht mal so weiß, was er eigentlich möchte und es werden einfach mal mehrere Dinge ausprobiert. 

Das wichtigste an agiler Softwaremethoden also nicht, dass man tolle Prozesse wie z.B. Kanban oder etwas Scrum-ähnliches eingeführt hat, sondern das kontinuierliche Feedback und zwar seitens des Kundens und auch seitens des Teams. Man kann zwar toll Scrum einführen aber wenn die Phasen des Reviews und der Retrospektiven fehlen, dann ist es nicht agil, sondern einfach nur kurze Wasserfälle.

 

Bearbeitet 16. Mai 2019 von Whiz-zarD

[twisted]

Danke an alle

Ich hab nochmal 2 Fragen:

Denkt ihr so ist das ganze gut genug erklärt? Ich bin mir da noch relativ unsicher was Formulierungen angeht.

Gehört so ein Text zur Vorgehensweise in die Projektplanung oder in die Realisierung?

Das Projekt ist eine Erweiterung der firmeninternen Software XY.

Textauszug:

Den Mitarbeitern der XY GmbH steht ein eingerichtetes GitLab* zur Projektverwaltung und Projekt Versioniserung zu Verfügung. Da die firmeninterne Software XY in GitLab verwaltet wird und auch zukünftige zu realisierende Projekte in GitLab angelegt werden, ist das zu realisierende Projekte ebenfalls in Gitlab zu verwalten.

Das in GitLab vorhandene Kanban-Board bietet sich aufgrund der guten Übersicht optimal als Werkzeug zur Verwaltung der Teilaufgaben, Milestones und Zeiten an. Auch wenn keine agile Herangehensweise verfolgt wird.

Ein Screenshot des Kanban-Boards befindet sich im Anhang unter x.y.

Zitat

* GitLab ist eine Webanwendung zur Versionsverwaltung für Softwareprojekte auf Basis von Git. Sie bietet diverse Management und Bug-Tracking-Funktionalitäten sowie mit GitLab CI ein System zur kontinuierlichen Integration. GitLab ist in den Programmiersprachen Ruby und Go entwickelt. Quelle: https://de.wikipedia.org/wiki/GitLab

LG

Bearbeitet 17. Mai 2019 von twisted

[twisted]

Hab mir nochmal Gedanken zur Agilität gemacht.

@Rienne Ich denke ich verstehe was du meinst. z.B. ist das Projekt zwar linear und man arbeitet die Phasen nacheinander ab, aber in der Implementierung springt man ja immer wieder mal zur Analyse oder Planung wenn man merkt es treten Probleme auf oder man muss etwas doch anders umsetzen. Also kann man schon sagen dass in der Realisierungsphase agil gehandelt wurde oder?

@Whiz-zarD Verstehe, ich habe mich auch immer wieder mit dem Auftraggsgeber unterhalten und wir haben z.B. erkannt dass wir ein bereits realisiertes Element so nicht gebrauchen konnten und ich musste innerhalb der Realisierung wieder neu Analysieren und das Problem neu Lösen. Also Agilität gegeben richtig?

Ich hab das ganze mal versucht grafisch darzustellen.

 

Bearbeitet 17. Mai 2019 von twisted
grafik ausgetauscht

[Whovian]

@twisted Bin auch grade am schreiben meiner Dokumentation habe mich dafür entschieden dass erweiterte Wasserfallmodell zu verwenden, da es im Vergleich zum normalen Wasserfallmodell beim erweiterten eben möglich ist auch zwischen den einzelnen Phasen hin und her zu springen (z.B. während der Implementierung zu Testen und dann weitermachen mit der Implementierung).

Denke das müsste dann bei dir eigentlich auch passen

[pr0gg3r]

vor 2 Stunden schrieb twisted:

 @Whiz-zarD Verstehe, ich habe mich auch immer wieder mit dem Auftraggsgeber unterhalten und wir haben z.B. erkannt dass wir ein bereits realisiertes Element so nicht gebrauchen konnten und ich musste innerhalb der Realisierung wieder neu Analysieren und das Problem neu Lösen. Also Agilität gegeben richtig?

Genau hier ist ja der Vorteil von agilen Methoden. Beim klassischen Wasserfallmodell stehen oben die Anforderungen und irgendwo unten die Porjektabnahme nach den Anforderungen. Bei kleinen Projekten auch kein Problem. Bei großen Projekten über mehrere Jahre hinweg ändern sich aber höchstwahrscheinlich die Anforderungen. Das heißt, was der Kunde bekommt ist zwar das was er ursprünglich wollte, aber nicht mehr das was er nun braucht. Und genau hier greifen solche Zyklen ein. Zurück zu deiner Frage: Ja, "Agilität" ist sicher in einem gewissen Maße gegeben, wobei man aus der Grafik nicht sieht nach welchen Methoden (XP, Scrum, ...).

vor 21 Stunden schrieb twisted:

Dennoch verlief das ganze Projekt sehr linear. Das Kanban Board wurde so eigentlich nur zur besseren Übersicht gewählt und weil es eben Vorgabe war, Agil war an dem Vorgehen aber nichts wirklich.

Meine Frage nun, ist das überhaupt legit? Also Kanban mit einem Wasserfallmodell zu verbinden und eben nicht agil zu entwickeln?

Es ist durchaus üblich, dass intern irgendwie agil entwickelt wird und nach außen zum Kunden klassisch. Das hat einmal den Grund, dass viele Auftraggeber gar nicht wissen, was agile Methoden überhaupt sind und wenn, dann ist für sie das höchste maß einen "Product Owner" zu benennen und zu denken, dadurch machen sie Scrum und sind wahnsinnig agil. Das ist auch OK so. "100% agil" findet man sowieso nirgends. Das hindert aber niemanden, intern trotzdem agil in Sprints zu entwickeln, Rollen zu definieren usw.