Jump to content
Melde dich an, um diesem Inhalt zu folgen  

Wasserfall & Kanban?

Empfohlene Beiträge

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

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
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 von Defneqon

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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.

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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 von Whiz-zarD

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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 von twisted

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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? :D

Ich hab das ganze mal versucht grafisch darzustellen.

wasserfall2.thumb.JPG.887d62184b99e3124ef218a03d18c5ac.JPG

 

bearbeitet von twisted
grafik ausgetauscht

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

@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 :)

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
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? :D

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. 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Nimm an der Diskussion teil

Du kannst jetzt hier posten und Dich später registrieren. Wenn Du bereits über eine Konto verfügst, melde Dich jetzt an, um mit Deinem Konto zu posten.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

Melde dich an, um diesem Inhalt zu folgen  

Fachinformatiker.de, 2019 SE Internet Services

fidelogo_small.png

if_icon-6-mail-envelope-closed_314900.pnSchicken Sie uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App


Get it on Google Play

Kontakt

Hier werben?
Oder senden Sie eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...

Wichtige Information

Fachinformatiker.de verwendet Cookies. Mehr dazu in unserer Datenschutzerklärung