Ich habe Probleme, den Entwicklungsprozess meines Projekts zu beschreiben.
Ich mache mein Praktikum in einem Unternehmen als Information Systems Designer und Java EE-Entwickler, für den Abschluss. Ich muss in meinem Bericht über den Entwicklungsprozess und die Projektorganisation sprechen.
Ich habe meinen Chef nach dem Entwicklungsprozess gefragt, den sie im Unternehmen durchführen, und er hat mir bestätigt, dass es sich um Scrum handelt.
Mein Thema ist Intranet. Wir haben mit dem komplexesten Modul im Intranet begonnen. Die voraussichtliche Bearbeitungszeit beträgt 5 Monate. Nachdem wir dieses Modul beendet haben, beginnen wir mit einem anderen.
Während dieser 5 Monate erwarten wir also, die Anforderungen des Moduls zu spezifizieren, ein Informationssystem zu entwerfen, das die Anforderungen erfüllt, eine Softwarearchitektur zu entwerfen, zu entwickeln, zu integrieren, dann zu testen, dann zu validieren und dann zu einem anderen Modul zu wechseln. Diese Schritte geben mir das Gefühl, dass wir den hier beschriebenen V-Zyklus verwendet haben .
Wir haben jedoch Scrum-Praktiken durchgeführt, wie z. B. ein tägliches Follow-up zwischen dem Scrum-Team und dem Scrum Master (was hast du gestern gemacht? hast du irgendwelche Schwierigkeiten? was wirst du heute tun?...) während eines Meetings von 5 Minuten. Wir sind ein Team von 3 Personen, wir haben einen Scrum Master und 2 Product Owner.
Ich habe mit meinem Chef gesprochen und er sagte, er werde 5 Monate in Sprints von 2 oder 3 Wochen aufteilen (ein Sprint des Entwerfens, ein Sprint der Implementierung eines funktionierenden Prototyps ..., ..., ein Sprint des Testens ).
Was ich jedoch an meinem College gelernt habe, ist, dass uns jeder Sprint eine Version liefert, ein Produkt, das wir verwenden können, das wir aber verbessern müssen.
Entschuldigung für diesen langen Text, aber ich musste Sie in meinen Kontext stellen, um mir bei der Beschreibung des Entwicklungsprozesses dieses Projekts helfen zu können. Vielen Dank!
Könnten das Sprints sein?
Leider machen Sie kein Scrum. Sie wenden einfach bestimmte Praktiken an, folgen aber nicht der Denkweise. Sie sind nah dran, wenn Sie sagen, dass "... jeder Sprint uns eine Version gibt, ein Produkt, das wir verwenden können, aber das wir verbessern müssen" . Allerdings produzieren Sprints nicht zwangsläufig Versionen und in Scrum zielen wir in erster Linie auf Feedback ab.
Also machen wir Scrum, um schneller Feedback zu unserem Produkt zu erhalten. Natürlich können Sie die Scrum-Praktiken verwenden - wir verwenden auch einige davon -, aber Ihre Prozesse sind weit entfernt von einem Scrum-Prozess.
Wenn Sie Ihren Prozess beschreiben, vergessen Sie Scrum, beschreiben Sie den Prozess, und wenn Sie mit Ihrem Entwurf fertig sind, aktualisieren Sie Ihren Aufsatz mit den Scrum-Tools und wie sie Ihnen oder Ihrer Organisation helfen. Seien Sie realistisch und schreiben Sie nichts auf, was vielleicht gut aussieht, aber Sie tun es nicht wirklich.
Sie können KEINEN Design-, Programmier- oder Test-Sprint machen. Jeder Sprint muss alles tun, um eine funktionierende Funktionalität zu liefern.
Dieser Link führt nicht zu einem Bild des V-Modells. Es ist jedoch ein weit verbreiteter Irrtum.
Das V-Modell hat keinen Zeitpfeil. Es hat Abhängigkeitspfeile. Sie können dies nicht tun, bis Sie das getan haben. Scrum verstößt nicht gegen das V-Modell. Während V-Modell jedoch sagt, dass Sie nicht testen können, bis Sie den Code geschrieben haben. Agile besagt, dass Sie die Tests schreiben können und sollten, bevor Sie den Code schreiben. Agile sagt auch, dass Sie dies alles nicht tun müssen, bevor Sie das tun. (Mach nicht das ganze Design, dann die ganze Codierung, dann alle Tests)
Für Agilität (die Grundlagen):
Sie sehen, es gibt eine Reihenfolge, es ist die gleiche wie beim V-Modell, außer dass das ursprüngliche V-Modell nicht erkennt, dass wir Tests vor dem Produktionscode schreiben können. Es erkennt auch Codierung nicht als Design an. (Code ist der größte Teil des Designs)
Es gibt keine schöne Art, dies zu sagen, es ist ein Wasserfall. Das einzig Gute am Wasserfall ist, dass Sie als Auftragnehmer das Projekt sehr lange am Laufen halten können, ohne dass die Kunden/Manager merken, dass etwas nicht stimmt.
Todd A. Jacobs
Benutzer1847726
jmort253
Benutzer1847726