Konkretes Vorgehensmodell zur Software-Entwicklung

[gene]

In den letzten Wochen habe ich Einiges gelesen über "Requirements engineering" (zu deutsch: Anforderungserhebung).
Wir wollen ja unsere Web-Anwendung programmieren, dafür müssen wir aber natürlich auch wissen, was unsere Anwendung alles leisten soll. Und das müssen wir auch aufschreiben (wie genau, dazu komme ich weiter unten).

Währendd meiner Recherchen bin ich nach und nach davon weggekommen, zunächst sämtliche Anforderungen aufzuschreiben und dann mit der Programmierung zu beginnen. Ich bin dabei dann auf den Ansatz des "agilen Entwickelns" gestoßen, der nämlich (u.a.) genau in diesem Bereich vom klassischen Entwicklung-Prozess abweicht. Daraufhin habe ich mir auch direkt das Buch "Agile Softwareentwicklung: Werte, Konzepte und Methoden" zugelegt (Amazon-Link) (und bereits durchgelesen). Die darin verwendeten Prinzipien scheinen super für ein Projekt wie das unsere zu passen, besser als das klassische "Wasserfallmodell". Ein interessanter Text über einen Vergleich "Wasserfall-Modell/agile Entwicklung" findet man hier.

Hier ein paar Sätze über agile Softwareentwicklung:

Im Kern geht es bei agiler Softwareentwicklung um möglichst häufige Rückkopplungsprozesse und zyklisches (iteratives) Vorgehen auf allen Ebenen: bei der Programmierung, im Team und beim Management.

Anders als in der klassischen Vorgehensweise wird das neue System nicht im Voraus in allen Einzelheiten genau geplant und dann in einem einzigen langen Durchgang entwickelt, denn schließlich können sich die Anforderungen während der Projektlaufzeit noch ändern, und oft sind sie zu Projektbeginn noch gar nicht vollständig bekannt.
Stattdessen wechseln sich beim agilen Vorgehen kurze Planungs- und Entwicklungsphasen ab. Nachdem eine Vision für das neue System entwickelt wurde, also die Ziele festgelegt und gewichtet wurden, die mit der Software erreicht werden sollen, wird ein Plan für eine erste Version ausgearbeitet, und die Entwicklung beginnt. Danach werden notwendige Anpassungen vorgenommen.

Für uns würde das konkret heißen:
Wir konzentrieren und bei der Programmierung immer auf "Zwischen-Ziele", die wiederum jeweils funktionierenden Web-Anwendungen sind. Diese "Versionen" unserer Anwendung haben dann nach und nach mehr Features. Für die jeweils nächste Version entscheiden wir uns vor dem Start des Entwicklungs-Zeitraums (wird auch "Sprint" genannt), welche Features in diesem Sprint programmiert werden sollen (priorisierte Liste mit Unterstützung von Jira). Das wollen wir zum Einen in vielen kleinen Versions-Schritten bis zu der ersten "öffentlichen", produktiven Version unserer Web-Anwendung machen. Zum Anderen kann man dieses Verfahren aber auch dann weiter verfolgen, wenn man bereits produktiv ist: Durch kleine Versions-Sprünge wird das Risiko minimiert, dass auf Einmal Vieles nicht mehr funktioniert, und wir bekommen schnell Feedback von unseren Anwendern. Die Frage, welche Anforderungen unsere erste produktive Version erfüllen muss, ist eine sehr interessante Frage, die wir in einem einzelnen Thread gesondert behandeln sollten.

Was soll unsere Software leisten?
Das werden wir anhand von sog. "User Stories" (Wikipedia) aufschreiben. User Stories sind eine "leichtgewichtige" Möglichkeit, Anforderungen der Benutzer aufzuschrieben. Typischerweise macht das jemand, der die "Fachlichkeit" sehr gut kennt, der also bei uns genau weiß, was unsere Web-Anwendung leisten soll. Eine Liste interessanter Artikel über User Stories findet man hier.

Wie gesagt wollen wir unsere User Stories im Jira festhalten. Typischerweise entstehen dann daraus eine oder mehrere Aufgaben (Jira: Tasks), die erledigt werden müssen, bevor die User Story umgesetzt ist. Ich habe in unserem Jira-Projekt "Oregami Webanwendung" bereits einige solche User-Stories erstellt, hier kann man sie sehen.

Ich werde das in den nächsten Tagen/Wochen noch genauer erarbeiten und das auch nochmal in einem ausführlichen Blog-Posting darstellen. Damit wird unser Vorgehen um Einiges konkreter und besser greifbar für alle. Insbesondere die Frage "welche Dinge muss unsere Anwendung können, wenn sie zum ersten mal produktiv geht?" finde ich sehr interessant und daran kann sich ja eigentlich auch jeder beteiligen.

Ich habe die für mich/uns zentralen Aussagen des oben genannten Buchs bei uns im Wiki aufgeschrieben. Unbedingt durchlesen!

Was denkt ihr über dieses Thema?

[MZ per X]

Für uns würde das konkret heißen:
Wir konzentrieren und bei der Programmierung immer auf "Zwischen-Ziele", die wiederum jeweils funktionierenden Web-Anwendungen sind. Diese "Versionen" unserer Anwendung haben dann nach und nach mehr Features. Für die jeweils nächste Version entscheiden wir uns vor dem Start des Entwicklungs-Zeitraums (wird auch "Sprint" genannt), welche Features in diesem Sprint programmiert werden sollen (priorisierte Liste mit Unterstützung von Jira).

Also ich als Programmierlaie finde das Klasse! Meiner Meinung nach würde eine Entscheidung für das Wasserfallmodell wahrscheinlich unser Scheitern bedeuten, weil einfach der Entwicklungszeitraum zu lang wäre für ein Freizeitprojekt mit solcher Komplexität. Also sollten wir agil entwickeln!

[hydr0x]

Naja, um ehrlich zu sein finde ich alle Entwicklungsmodelle für Webseiten eher ungeeignet, da es sich bei Webseiten einfach anbietet Änderungen nach erfolgreichem Test direkt live zu setzen. Man muss ja kein Produkt auslieferen. Warum sollte ich da mit Versionen, Sprints oder was auch immer arbeiten. Ist ja kein Projekt von der Größe eines Google

[gene]

Naja, um ehrlich zu sein finde ich alle Entwicklungsmodelle für Webseiten eher ungeeignet, da es sich bei Webseiten einfach anbietet Änderungen nach erfolgreichem Test direkt live zu setzen. Man muss ja kein Produkt auslieferen.

Das sehe ich anders.

Unser Projekt soll eben nicht "eine einfache Webseite" sein, sondern eine testbare, wartbare, leistungsfähige Web-Anwendung. Dazu gehört etwas mehr als mal eben "eine Seite erweitern und online stellen". Aber jeder so, wie er möchte. Ich möchte auf jeden Fall "groß", d.h. konsequent mit vernünftigen Konzepten. Wenn man das nicht macht, läuft man schnell in eine Falle (nicht wartbar, schwer erweiterbar, nicht testbar).

Aber wie gesagt: jeder so, wie er möchte

[hydr0x]

Zu Testbarkeit (im Sinne von Korrektheit), Wartbarkeit und Leistungsfähigkeit bedarf es allerdings keines Entwicklungsmodells. Genauer gesagt hilft das Entwicklungsmodell in Sachen Wartbarkeit und Leistungsfähigkeit gar nicht. Ein Entwicklungsmodell dient dazu mit effizienter Ressourcennutzung möglichst anforderungstreu zu entwickeln. Ich habe schon die ausgefeiltesten Verfahren im Einsatz gesehen, hilft alles in Sachen Wartbarkeit und Leistungsfähigkeit nicht wenn der Code schlecht geschrieben ist. Da mögen dann bei jedem Milestone die Anforderungen erfüllt sein und die Tests einwandfrei durchlaufen, besser wird der Code dadurch nicht

Faktisch ist ja das "feature by feature" entwickeln und deployen nichts anderes als ein agile process mit extrem kurzen Zyklen, jeweils auf ein Feature eingeschränkt. Das schließt ja vernünftiges Testen und einen Ziel/Umsetzung-Vergleich nicht aus. Klar, ab x Entwicklern gibt es evtl. parallel mehrere Feature-Entwicklungen, so lange diese aber in klar getrennten Code-Abschnitten stattfinden macht das keinen Unterschied. Die Notwendigkeit für komplexe Modelle entsteht ja eigentlich erst durch eine hohe Anzahl Entwickler sowie eine starke Verzahnung der Programmkomponenten.

[gene]

Klar, die Wahl eines Entwicklungsmodells sorgt nicht direkt für Wartbarkeit etc.

Wir müssen ja auch keine "2-Wochen-Sprints" machen, das ist in Firmen mit mehreren Vollzeit-Entwicklern sinnvoll.
Aber die hier aufgeschriebenen Ansätze finde ich trotzdem sinnvoll, vor Allen, da ich bisher noch im "Wasserfall-Modell" unterwegs war. Und das ist halt etwas komplett anderes.

Testbarkeit kann man natürlich mit jedem Vorgehensmodell hinbekommen. Wichtig für uns (und alle Interessierten an unserem Projekt) ist, dass wir wirklich schrittweise entwickeln, Software-Zwischenstände oft "releasen", transparent dokumentieren, was dazu gekommen ist, um nach und nach "erfühlen" zu können, welcher Teil unserer umsetzungen gut funktionieren wird und welcher vielleicht nicht. Das finde ich sehr passend.

[StevenStorm]

Was ich mich eher frage: bei einer Fertigstellung die erst in Monaten geplant ist... macht ein Arbeiten nach Scrum wirklich Sinn?
Und gerade für den Anfang weiß man ja schon bereits was alles getan werden muss (+ Sachen die während der Entwicklung dazu kommen, weil nicht planbar). Es ist aus meiner Sicht also Wasserfall ganz egal ob man es in Sprints einplant oder nicht.

Als Entwickler bin ich an sich auch kein zu großer Freund von extrem knappen UserStories ala "A User can switch the language of the web interface", aber das kann man ja noch aufblähen als Entwickler.

[gene]

Was ich mich eher frage: bei einer Fertigstellung die erst in Monaten geplant ist... macht ein Arbeiten nach Scrum wirklich Sinn?
Und gerade für den Anfang weiß man ja schon bereits was alles getan werden muss (+ Sachen die während der Entwicklung dazu kommen, weil nicht planbar). Es ist aus meiner Sicht also Wasserfall ganz egal ob man es in Sprints einplant oder nicht.

Wir müssen es nicht "Scrum" nennen. Aber "Wasserfall-Modell" wollen wir eigentlich nicht machen, denn zum Einen wollen wir nicht jetzt *alles* aufschreiben, was das System irfendwann mal können muss. Zum Anderen wollen wir nicht erst in einem oder zwei Jahren eine Software-Version erstellen.

Hast du diesen Text gelesen? Ich finde, dass die von mir herausgeschrieben agilen Ansätze sehr gut für uns passen.
Aber wie wir das "benennen" ist mir eigentlich egal. Und echtes "Scrum" wie in einem Vollzeit-Firmen-Projekt machen wir nicht, stimmt.

[StevenStorm]

Naja ich weiß nicht - bei so kleineren Sachen kann Wasserfall(-ähnlich) denke ich schon Sinn machen.
Immerhin weiß man dann wo man steht und wieweit das Project ist.

Von agile an sich brauchst du mich nicht zu überzeugen...