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 Letzte Überarbeitung Beide Seiten der Revision | ||
|
se:agilesoftwareentwicklung [2010-05-14 19:55] stefan |
se:agilesoftwareentwicklung [2014-12-30 15:07] stefan Seite von programmierung:agilesoftwareentwicklung nach softwareentwicklung:agilesoftwareentwicklung verschoben |
||
|---|---|---|---|
| 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 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 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 | ||
| - | |||
| - | ==== Schwachpunkte von Scrum ==== | ||
| - | \cite{Cetinkaya2010} | ||
| - | * Rahmenwerk, aber kein Werkzeug | ||
| - | * Scrum verrät nichts über den Aufbau der Einträge der Backlogs | ||
| - | * die Sprint Plannings sind unausgereift | ||
| - | * Sprintdauer | ||
| - | * bei den Sprints (Iterationen) und deren Dauer ist die Methodik (bzw. die Umsetzung von Scrum) zumeist deutlich mangelhaft | ||
| - | * für ein Rahmenwerk, welches sehr stark auf die Mikro-Organisation fokussiert ist, sind 4 Wochen eine lange Zeit (kürzere Sprints werden kaum verwendet, wenn man aus dem klassischen PM kommt) | ||
| - | * Planung und Design | ||
| - | * Planung und Design in Scrum sind "unfassbar" | ||
| - | * in der Scrum-Methodik gibt es keine unterstützenden Merkmale zu adequater Businessanalyse und der anschließenden Anforderungsanalyse | ||
| - | * Sprint Planning ist in vielerlei Hinsicht inadequat | ||
| - | * Sprint Planning ist ein Alibi für Design und Planung | ||
| - | * Scrum Master | ||
| - | * in den meisten Unternehmen ist der Scrum Master Nachfolger des klassischen Projekt-Managers und nimmt aktiven Einfluss auf die Planung, verteilt Tasks und Aufgaben, zweifelt Entwicklungsaufgaben an, mahnt bei Refaktorisierungsaufgaben zur Beachtung des "Business Values" und erklärt sich selbst zum "Manager des Teams" | ||
| - | * ist oft V-Mann und Sklave des konservativen Managements und muss Executive Summaries und Projektpläne aufstellen | ||
| - | * kann aber auch ein Entwickler sein, der dann Tasks ändert, bei Estimations der Führende ist und den anderen "seinen Programmierstil" (unbewusst) vor die Nase setzt | ||
| - | * Skalierung | ||
| - | * Scrum in seiner ersten und "reinen" Form ist eher für ein einzelnes Team konzipiert, maximal ein paar Teams | ||
| - | * Sonstiges | ||
| - | * viele denken, sie praktizieren Scrum, dabei machen Sie kleine Wasserfall-Iterationen | ||
| - | * Scrum ist oftmals ein Ausreden-Paket für Entwickler | ||
| - | |||
| - | \cite{Martin2010} | ||
| - | * Scrum gibt den Entwicklern keine praktischen Hilfsmittel (z.B. TDD, Continuous Integration, Acceptance Testing, Pair Programming, Refactoring) | ||
| - | * 4 Wochen sind zu lang für einen Sprint | ||
| - | * der Scrum Master wird häufig zum Projektleiter | ||
| - | * der Scrum Master ist eine Rolle (die von mehreren Teammitgliedern abwechselnd eingenommen werden sollte), wird aber häufig mit einer einzelnen Person in Verbindung gebracht | ||
| - | * Scrum gibt keine Struktur für die Backlogs vor | ||
| - | * der Fokus auf selbstorganisierende Teams ist zu groß, Teams müssen auch geführt werden | ||
| - | * Scrum erwähnt nie automatisierte Tests, obwohl sie die Grundlage jedwedes agilen Vorgehens sind | ||
| - | * Scrum bietet keine Lösung zur Arbeit mit mehreren (verteilten) Teams | ||
| ===== Ist Agile Entwicklung ingenieursmäßig? ===== | ===== Ist Agile Entwicklung ingenieursmäßig? ===== | ||
se/agilesoftwareentwicklung.txt · Zuletzt geändert: 2014-12-30 15:08 von stefan
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
