Agilisten sind sich nicht einig über Planung und Architektur. XP neigt dazu, keine (oder kleine) Architektur im Voraus zu befürworten (dh geplantes Design), aber Leute wie Martin Fowler sagen, dass sie es tun geplantes Design vielleicht 20% der Zeit . Kapitel 14 von XP Explained (Kent Beck) hat eine schöne Artikulation der XP-Design-Philosophie.
Michael Keeling hat eine gute Erklärung dafür, warum Agilisten (und andere) nicht einverstanden sind . Er sagt, auf zwei Dimensionen zu achten: Ihr Wissen über Lösungen und Ihr Wissen über Probleme. Wenn Sie viel über Lösungen in diesem Bereich wissen (z. B. Web-Systeme), werden Sie die Planung wahrscheinlich eher verschieben. Aber wenn noch nie jemand einen Mars Rover gebaut hat, macht man mehr Planung. Für mich erklärt dies, warum Ingenieure in verschiedenen Situationen unterschiedliche Dinge tun, doch was jeder tut, ist rational.
Kapitel 3 meines Buches über Software-Architektur widmet sich der Beantwortung der Frage "Wie viel Architektur sollten Sie tun? " Kurz gesagt lautet die Antwort: "Mach Architektur, bis Risiken von deinem Radar verschwinden". Wenn Sie sich keine Gedanken über Skalierbarkeit oder Sicherheit machen, sollten Sie diese nicht planen. Wenn Sie sich jedoch Sorgen über die Überprüfbarkeit (z. B. Einhaltung gesetzlicher Vorschriften) machen, sollten Sie daran arbeiten, bis Sie glauben, dass Sie damit umgehen können, oder mit evolutionärem Design umgehen können. Dieses Kapitel steht zum kostenlosen Download zur Verfügung.
Wenn Sie agil sind, sollten Sie es vermeiden, viel Frontdesign in eine Iteration Zero zu stecken. Anders gesagt, wenn Ihre Iteration Zero drei Monate Design hat, sind Sie nicht wirklich sehr agil.
Ihre Frage bezieht sich speziell auf Architekturmodelle - nur eines der Dinge, die Sie im geplanten Design tun würden. Modelle sind Mittel zum Zweck (das Ende ist ein laufendes System). Gut eingesetzt, können sie Ihnen helfen, Risiken zu reduzieren, aber niemand wird am Ende des Projekts glücklich sein, wenn Sie ein großartiges Modell und kein System haben.
Agile bedeutet überhaupt keinen Plan.
Sie erstellen den Sprint 0, der darin besteht, die Entwicklungsumgebung und die Architekturziele einzurichten.
Halten Sie es am Anfang einfach, es wird sich langfristig auszahlen.
Es kommt darauf an, dass Sie eine vage Vorstellung davon haben müssen, wohin Sie gehen, um dorthin zu gelangen. Sie können also mit einem Walking Skeleton und fülle die einzelnen Teile aus, während du gehst, aber du willst auch keine Entscheidungen treffen zu bald . Sie können also mit einem Architekturdiagramm beginnen, das bestimmte Entitäten enthält, aber Sie geben ihre konkrete Implementierung erst an, wenn Sie sie nacheinander ausgewertet haben.
Technisch gesehen sollte eine Architektur Iterationen durchlaufen, da eine Architektur besagt, dass wir skalieren oder so kommunizieren wir usw. Während der Entwicklung bauen Sie nur das auf, was Sie für diese Iteration benötigen. Wenn Sie nicht skalieren müssen, fügen Sie diesen Teil der Architektur nicht in Ihr Projekt ein. Als Teil von Agile ist es, Tests zu verwenden, wenn Sie diesen Code später noch einmal überarbeiten müssen, um ihn skalieren zu können. Obwohl er Nacharbeit enthält, sollten Sie diese Änderungen und die aktuellen Architekturempfehlungen für die Skalierung verwenden.
>Dasselbe könnte man auch aus Planungs- und anderen Projektaktivitäten sagen. Sie müssen bei all diesen Aktivitäten etwas unternehmen, um das Projekt in Gang zu bringen, aber Sie sollten nicht tief in Details gehen, die am besten zu jeder Iteration gehören .
Es ist sehr wichtig, zu Beginn sehr klar zu wissen, worum es bei dem Projekt geht auf einer sehr hohen Ebene . Wenn das nicht der Fall ist, ist das erste, was getan werden muss. Das Gleiche gilt für die Architektur , wir sprechen hier von sehr kurzer Zeit mit den richtigen Leuten, die den Unterschied machen können beginnen, eine völlig falsche Sache zu bauen .
Da Sie das oben genannte auf einem extrem hohen Level machen, werden Sie natürlich bei jeder fortschreitenden Iteration viele neue, etwas hochstufige Informationen erhalten. Beachten Sie auch, dass Sie gleich zu Beginn festgestellt haben könnten, dass es wichtig ist, überhaupt etwas zu tun, um zu wissen, ob das Projekt überhaupt funktionieren kann. Dies beeinflusst die Konzentration auf das Team und die Aktionen, die durchgeführt werden müssen, um sicherzustellen, dass es ein gesundes Projekt wird.
Tags und Links agile