Benutzer-Werkzeuge
se:agilesoftwareentwicklung
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
|
se:agilesoftwareentwicklung [2008-12-27 21:33] stefan |
se:agilesoftwareentwicklung [2014-12-30 15:08] (aktuell) stefan Seite von softwareentwicklung:agilesoftwareentwicklung nach se:agilesoftwareentwicklung verschoben |
||
|---|---|---|---|
| Zeile 2: | Zeile 2: | ||
| ===== Kernpunkte agiler Entwicklungsmethoden ===== | ===== Kernpunkte agiler Entwicklungsmethoden ===== | ||
| - | **nach {[quellen:Bleek2008]}** | + | **nach \cite{Bleek2008}** |
| * **priorisierte Anforderungen** sind die Grundlage der Entwicklung | * **priorisierte Anforderungen** sind die Grundlage der Entwicklung | ||
| * Fokus auf nutzenbringende Features (und nicht auf Standardfunktionen wie z.B. Stammdatenverwaltung) | * Fokus auf nutzenbringende Features (und nicht auf Standardfunktionen wie z.B. Stammdatenverwaltung) | ||
| Zeile 10: | Zeile 10: | ||
| * zusätzliche Anforderungen können leicht und schnell integriert werden | * zusätzliche Anforderungen können leicht und schnell integriert werden | ||
| * das Team soll **ständig dazulernen** | * das Team soll **ständig dazulernen** | ||
| - | * **[[Retrospektiven]]** sind äußerst wichtig für die Entwicklung des Teams und des Prozesses | + | * **[[se:Retrospektiven]]** sind äußerst wichtig für die Entwicklung des Teams und des Prozesses |
| * kontinuierliche Verbesserung des Schätzverfahrens für Tasks -> z.B. Planning Poker | * kontinuierliche Verbesserung des Schätzverfahrens für Tasks -> z.B. Planning Poker | ||
| * Collective Code Ownership -> jeglicher Code darf von jedem Entwickler geändert werden | * Collective Code Ownership -> jeglicher Code darf von jedem Entwickler geändert werden | ||
| * lauffähige Software abliefern | * lauffähige Software abliefern | ||
| - | * die verfügbare Arbeitszeit muss realistisch [[iterationsplanung|verplant]] werden | + | * die verfügbare Arbeitszeit muss realistisch [[se:iterationsplanung|verplant]] werden |
| * überschaubare Länge der Tasks/Aufgaben der Entwickler (max. 1 Woche) | * überschaubare Länge der Tasks/Aufgaben der Entwickler (max. 1 Woche) | ||
| * z.B. 70% produktive Zeit wegen Urlaub, unvorhergesehenen Aufgaben etc. | * z.B. 70% produktive Zeit wegen Urlaub, unvorhergesehenen Aufgaben etc. | ||
| * Zeit für Bugfixing, Retrospektiven etc. muss eingeplant werden | * Zeit für Bugfixing, Retrospektiven etc. muss eingeplant werden | ||
| - | * [[Timeboxing]] -> Termine stehen fest, Funktionen werden ggfs. reduziert | + | * [[se:Timeboxing]] -> Termine stehen fest, Funktionen werden ggfs. reduziert |
| * einfache Regeln -> keine Zeitverschwendung durch lange Lernzeiten für Prozessmodell | * einfache Regeln -> keine Zeitverschwendung durch lange Lernzeiten für Prozessmodell | ||
| * viel Freiheit für die Entwickler -> dennoch sollten die wenigen Regeln strikt eingehalten werden | * viel Freiheit für die Entwickler -> dennoch sollten die wenigen Regeln strikt eingehalten werden | ||
| Zeile 24: | Zeile 24: | ||
| ===== Agile Werte ===== | ===== Agile Werte ===== | ||
| - | **nach {[quellen:Bleek2008|S. 10ff.]}** | + | **nach \cite[S. 10ff.]{Bleek2008}** |
| * Kommunikation | * Kommunikation | ||
| * direkt: von Person zu Person und möglichst kurzfristig bei Bedarf | * direkt: von Person zu Person und möglichst kurzfristig bei Bedarf | ||
| Zeile 33: | Zeile 33: | ||
| * methodisch: keine überbordenden Prozesse, sondern einfach umzusetzendes Vorgehen | * methodisch: keine überbordenden Prozesse, sondern einfach umzusetzendes Vorgehen | ||
| * Rückkopplung | * Rückkopplung | ||
| - | * insbesondere: [[Retrospektiven]] | + | * insbesondere: [[se:Retrospektiven]] |
| * Mut | * Mut | ||
| * neue Wege ausprobieren | * neue Wege ausprobieren | ||
| Zeile 49: | Zeile 49: | ||
| ===== Pro und Contra ===== | ===== Pro und Contra ===== | ||
| - | **nach {[quellen:Bleek2008|S. 159ff.]}** | + | **nach \cite[S. 159ff.]{Bleek2008}** |
| * Contra aufgrund des Kunden | * Contra aufgrund des Kunden | ||
| * kein SMARTes Projektziel | * kein SMARTes Projektziel | ||
| Zeile 90: | Zeile 90: | ||
| * Refactoring-Browser vorhanden -> leichte Änderbarkeit des Quelltextes | * Refactoring-Browser vorhanden -> leichte Änderbarkeit des Quelltextes | ||
| * Test-Frameworks vorhanden oder bekannt | * Test-Frameworks vorhanden oder bekannt | ||
| + | |||
| + | ===== Ist Agile Entwicklung ingenieursmäßig? ===== | ||
| + | **nach \cite{Coldewey2008}** | ||
| + | * Agiles Arbeiten ist ingenieursmäßiges Arbeiten | ||
| + | * es muss wissenschaftlich-theoretisch fundiert sein | ||
| + | * Quellen sind die Psychologie von Gruppen und Organisationen, die Theorie komplexer Systeme und die Managementtheorie | ||
| + | * bis auf Systemtheorie eher "weiche" Wissenschaften, aber trotzdem als theoretische Grundlage verwendbar | ||
| + | * es muss empirisch sein | ||
| + | * reale Projekte werden selten für Studien geöffnet (Angst, durch Veröffetnlichung von Interna das Geschäft zu schädigen) | ||
| + | * Zweifel, ob Empirie in der Informatik überhaupt sinnvoll ist (kurzlebige Theorien, häufige und schnelle Änderungen der Methoden und Werkzeuge) | ||
| + | * Methoden für empirische Studien in der Informatik fehlen allgemein | ||
| + | * es muss systematisch erlernbar und anwendbar sein | ||
| + | * für viele Praktiken und Methoden der agilen Entwicklung gibt es gute Literatur (z.B. Retrospektiven, contiuous integration etc.) | ||
| + | * agile Praktiken werden seit Jahren an amerikanischen Hochschulen gelehrt | ||
| + | * Agiles Arbeiten hat die gleichen Wurzeln wie traditionelle Prozesse | ||
| + | * bereits auf der Software-Engineering-Konferenz in Garmisch 1968 sagte Andy Kinslow, dass er Design als Prozess versteht aus Entwurf in Form von Flussdiagrammen, Programmieren nach diesen Diagrammen und zurückgehen, wenn man feststellt, dass das Diagramm falsch ist -> iterative Entwicklung | ||
| + | * auf derselben Konferenz wurde das Vorgehen, erst alles detailliert zu spezifizieren und dann erst zu implementieren als "das tödlichste in der Softwareentwicklung" bezeichnet (Douglas Ross) | ||
| + | * viele Unterzeichner des agilen Manifests waren vorher in der Pattern-Bewegung aktiv | ||
| + | * viele Methoden der traditionellen Verfahren werden auch bei agiler Entwicklung benutzt: Testautomatisierung, Versionskontrolle, Kapselung, Schichtentrennung etc. | ||
| + | * Agiles Arbeiten verfolgt die Linie der betriebswirtschaftlichen Ausrichtung | ||
| + | * die Erfahrung zeigt, dass es wesentlich wirtschaftlicher sein kann, die Anforderungen möglichst lange änderbar zu halten, als von Anfang an, alles haarklein zu spezifizieren | ||
| + | * die detaillierte Spezifikation kostet viel und kann zum Scheitern von Projekten führen | ||
| + | * Entwickler und Kunde verhandeln bei agiler Entwicklung gemeinsam, sodass bessere Ergebnisse (-> Fachbereich und Entwickler arbeiten zusammen) dabei herauskommen | ||
se/agilesoftwareentwicklung.1230409986.txt.gz · Zuletzt geändert: 2014-04-05 11:42 (Externe Bearbeitung)
Seiten-Werkzeuge
Falls nicht anders bezeichnet, ist der Inhalt dieses Wikis unter der folgenden Lizenz veröffentlicht: CC Attribution-Noncommercial-Share Alike 4.0 International
