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 18:12] 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 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 47: | Zeile 47: | ||
| * Zusammenarbeit mit dem Kunden vor Vertragsverhandlungen | * Zusammenarbeit mit dem Kunden vor Vertragsverhandlungen | ||
| * Reaktion auf Veränderungen vor Planverfolgung | * Reaktion auf Veränderungen vor Planverfolgung | ||
| + | |||
| + | ===== Pro und Contra ===== | ||
| + | **nach \cite[S. 159ff.]{Bleek2008}** | ||
| + | * Contra aufgrund des Kunden | ||
| + | * kein SMARTes Projektziel | ||
| + | * Prozess ist fest vorgegeben (z.B. bei Behörden) | ||
| + | * Nice-to-have-Projekt -> es gibt keinen Kunden, der Anforderungen definiert | ||
| + | * lange Entscheidungswege beim Kunden -> mangelhafte Rückkopplung | ||
| + | * langwierige Change-Request-Verfahren -> langer Stillstand im Projekt | ||
| + | * kein Anwenderkontakt möglich -> keine Rückkopplung möglich | ||
| + | * Kundenrolle nicht oder zeitlich zu knapp besetzt -> lange Entscheidungswege, keine klare Vision des Kunden vorhanden | ||
| + | * Erstellung von lebenskritischer Software -> wichtige Vorgaben zu Tests, Dokumentation etc. | ||
| + | * Angst und organisierte Unverantwortlichkeit -> niemand übernimmt Verantwortung | ||
| + | * Kunde steht nicht hinter dem Vorgehen -> Kunde nimmt seine Rolle nicht ernst oder fürchtet Mehrarbeit | ||
| + | * keine Arbeit vor Ort möglich -> mangelhafte Rückkopplung | ||
| + | * Festpreisprojekte -> Erkenntnisse können/dürfen nicht in den laufenden Prozess eingearbeitet werden | ||
| + | * Kunde ist eine Behörde -> meist treffen mehrere der obigen Punkte zu | ||
| + | * Contra aufgrund der Entwickler | ||
| + | * keine Erfahrung mit agilen Projekten und kein Coach vorhanden | ||
| + | * Lernunfähigkeit oder -unwillen -> agile Entwicklung bedeutet Lernen | ||
| + | * Kultur von Befehl und Gehorsam -> agile Entwicklung bedeutet Eigenverantwortung, Fehler machen dürfen etc. | ||
| + | * Entwickler scheuen Anwenderkontakt -> keine Rückkopplung möglich | ||
| + | * hohe Mitarbeiterfluktuation -> Team kann sich nicht einspielen | ||
| + | * keine Arbeit vor Ort gewünscht -> Rückkopplung wird behindert | ||
| + | * kein Management-Commitment auf agile Methoden -> Erlaubnis, Fehler machen zu dürfen ist sehr wichtig | ||
| + | * Contra aufgrund der Technologien | ||
| + | * lange Build-Zeiten | ||
| + | * Pro aufgrund des Kunden | ||
| + | * Start-ups -> müssen schnell Ergebnisse liefern | ||
| + | * innovative Projekte -> brauchen Lernerfolge, haben Commitment der Teilnehmer | ||
| + | * neue Anwendungsbereiche -> schnelle Lernerfolge | ||
| + | * schnelle Auslieferung notwendig (Time-to-Market) | ||
| + | * nutzenorientierte Perspektive des Kunden (anstatt kostenorientiert) | ||
| + | * Transparenz des Projektfortschritts -> Risikominimierung | ||
| + | * Pro aufgrund der Entwickler | ||
| + | * neugierige Entwickler -> wollen Kunden verstehen, wollen Neues ausprobieren, sind risikobereit, wollen sich einbringen | ||
| + | * Arbeit vor Ort ist sowieso gegeben | ||
| + | * konkrete (Team-)Probleme sind bekannt -> agile Entwicklung kann durch Rückkopplungen gezielt Probleme lösen | ||
| + | * Pro aufgrund von Technologien | ||
| + | * inkrementelle Compiler -> schnelle Rückkopplung beim Entwickler | ||
| + | * interpretierte Scriptsprachen | ||
| + | * Refactoring-Browser vorhanden -> leichte Änderbarkeit des Quelltextes | ||
| + | * 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.1230397975.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
