Benutzer-Werkzeuge
se:agilesoftwareentwicklung
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung | Nächste Überarbeitung Beide Seiten der Revision | ||
|
se:agilesoftwareentwicklung [2010-05-14 19:55] stefan |
se:agilesoftwareentwicklung [2010-05-14 20:09] stefan |
||
|---|---|---|---|
| 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
