Agile Mythen und Missverständnisse [geschlossen

Question

Was sind die Mythen oder Missverständnisse mit Agile?

Es gibt viele Missverständnisse in Bezug auf Agile, in die ein durchschnittlicher Neuankömmling möglicherweise fallen kann. Was sind die Missverständnisse in der agilen Welt und wie rechtfertigen Sie, dass es wirklich ein Missverständnis ist?

---

Update: Zusammenfassung agiler Mythen

• Agile erlaubt keine Dokumentation
• Agile Methoden skalieren nicht
• Agil bedeutet keinen Plan
• TDD deckt alle Anforderungen des Unit -Tests ab
• Paarprogrammierung führt immer zu einem besseren Code
• Agile ist eine Silber -Kugel -Lösung für Software -Engineering -Probleme (es gibt eine Silber -Kugel -Lösung)
• Agile braucht nicht vorne mit dem Design
• Wir machen Scrum, damit wir keine TDD -Programmierung durchführen müssen, usw.
• Man kann agil aus einem Buch lernen
• Agile arbeitet nur für triviale Projekte
• Agile verwendet immer "Benutzergeschichten"

Lesen Sie die folgenden Antworten, um weitere Informationen über die obigen Mythen und weitere Mythen zu erhalten.

Answer 1

1. "Wir machen Scrum - also müssen wir nicht (Paar | Refactor | tun | ...)" Tatsächlich haben die Scrum -Gründer - Ken und Jeff gesagt, dass alle hochproduktiven Scrum -Teams die gesamte Spektrum extremer Programmierpraktiken implementieren.

2. Die testgetriebene Entwicklung findet nicht alle Fehler / ist nicht einfach, um sich auf alles anzuwenden - also werden wir es nicht versuchen! - TDD zu lernen ist kein "alles oder nichts Geschäft" und Sie können besser beurteilen, was Sie testen und wie Sie es effizient machen können. Ich mache es jetzt seit zehn Jahren und finde immer noch bessere Möglichkeiten, es und neue Dinge zu berücksichtigen.

3. Ich kann alles lernen, was ich brauche, um agile Methoden aus einem Buch anzuwenden. - Sie müssen durch das Tun lernen, und das bedeutet oft, andere Menschen zu coachen und zu treffen, die helfen können. Viele Dinge gehen schief, wenn Leute nur versuchen, es aus einem Buch zu lernen.

4. Hysterisch (und ziemlich real) "Der Kandidat muss den Scrum -Master ausnehmen und unterstützen" (von einer Jobspezifikation, die mir letzte Woche gesendet wurde ...) - Der Scrum Master soll den Leuten nicht sagen, was sie tun sollen. Er/sie ist da, um zu erleichtern - dh, um dem Team zu helfen, die Dinge selbst zu klären. Es ist ein massiver Fehlermodus - einen Scrum -Master, der Menschen "befiehlt"!

5. Über "die agile Methodik" sprechen - Große Ahnungslosigkeitsindikator. Erstens, wenn man über "Agile" spricht, ist es eine bestimmte Sache, während es für viele verschiedene Dinge ein sehr vage Regenschirm begriff ist. Zweitens die Verwendung der "Agile -Methodik" - es gibt viele von ihnen und viele verschiedene Möglichkeiten, um viele von ihnen zu tun! Drittens kamen viele Menschen in der Agile-Community in die Gegenreaktion gegen die großen, schweren UML-beladenen Methoden der neunziger Jahre. Diese Leute neigen nicht dazu, das Wort "Methodik" zu verwenden ...

6. Sie brauchen besonders talentierte Menschen, um auf agile Weise Software zu entwickeln. Jeff Sutherland sagt, dass sie überlegte, das Modell "Chief Programmer Team" für die Verwaltung von Teams in Banken zu verwenden - aber feststellten, dass sie nicht genug "Chiefs" hatten. Scrum wurde entwickelt, um die beste Produktivität aus vielen mäßig fähigen Programmierern zu erzielen. Tatsächlich entfernen Sie ein überproportional produktives Teammitglied, das den anderen nicht helfen möchte, die mittelmäßigen Teammitglieder "entsperren" zu können und ihre kombinierte Produktivität dazu zu bringen, das superproduktive ehemalige Teammitglied mehr als zu kompensieren ... sagt trotzdem ...

Es gibt Nicht wenige andere XP-bezogene dass wir uns in einem Open -Space -Workshop ausgedacht haben, den ich kürzlich geführt habe: http://xpday-london.editme.com/wherehasxpgone

Answer 2

"Arbeitssoftware über umfassende Dokumentation" bedeutet, dass Sie keine funktionale Spezifikation benötigen ...

Falsch!!! Es bedeutet nur, dass Sie die Falten iterativ mit den Benutzern bügeln können - als Anbieter sprechen Sie immer noch gute Dokumentation, um die QA- und Abmeldungsphasen zu unterstützen ...

Answer 3

Mythos: Die Verwendung agiler Entwicklungspraktiken ist eine Silberkugellösung für Software -Engineering -Probleme.

Answer 4

Mythos: Test-First Development zwingt Ihr Projekt, angemessene Einheitenprüfungen durchzuführen.

Fakt: Viele Entwickler werden faul und die Einheitentests, die sie vor ihrem Code schreiben, sind oft schwach und unzureichend.

Mythos: Paarprogrammierung führt immer zu einem besseren Code.

Fakt: Programmierer sind in der Regel leicht antisozial und haben signifikant unterschiedliche Denkprozesse voneinander. Jemanden, der den Hals abatmet, während Sie Code codieren, ist sehr unangenehm, und das Ergebnis ist oft eine angespannte Arbeitsatmosphäre mit einer Verringerung der Codequalität und der Quantität.

Answer 5

Mythos: Agile bedeutet keine Dokumentation

Fakt: Agile Value Working Software mehr als umfassende Dokumentation, aber dies bedeutet nicht, dass überhaupt keine Dokumentation. Die Dokumentation sollte gerade rechtzeitig und gerade genug geschrieben werden. Und nein, Agile sagt nicht, dass man sollte sollte stets Verwenden von Benutzergeschichten. Verwenden Sie sie, wenn und nur, wenn sie angemessen sind!

Mythos: Agil bedeutet keinen Plan

Fakt: Agile unterstützt die Entwicklung ohne Planung nicht. Agile verwendet kontinuierliche Planung und Schätzung, um den ROI zu maximieren. Tatsächlich handelt es sich bei Agile um das Umfangsmanagement.

Mythos: Agil bedeutet keine Disziplin

Fakt: Agile Entwickler müssen für den Erfolg disziplinierter sein.

Mythos: Agile funktioniert nur für triviale Projekte

Fakt

• FDA-zugelassene, lebenskritische Software für Röntgen- und MRTs,
• Finanzzahlungsanträge,
• 24x7 mit 99,99999% Verfügungsanforderungen,
• Multi-Terrennyte-Datenbankanwendungen,
• etc

Mythos: Agile skaliert nicht

Fakt: Sutherland verwendete Scrum in Gruppen von 500+, Cohn verwendete Scrum in Gruppen von 100+

Answer 6

Mythos: "Kein großes Design im Voraus" bedeutet kein Design.

Answer 7

Mythos: Wasserfall scheitert immer.

Realität: Der größte Teil der Software, die Sie für Ihr agiles Projekt verwenden, wurde mit Wasserfall entwickelt. Sogar BDUF -Wasserfall, in vielen Fällen.

Answer 8

Es gibt keine wirklichen Mythen - aber alles, was zu einem Extrem genommen wird, wird falsch sein. Ein agiles Projekt, das in der Hoffnung, "zu entwerfen, wie es geht", auf Null entwirft, wird wahrscheinlich scheitern. Ein Wasserfallprojekt, das alles bis zum letzten Semikolon entwirft, wird wahrscheinlich aufgrund von Budget-, Zeit- oder Veränderungsanforderungen fehlschlagen.

Answer 9

Es wurde wiederholt gesagt, dass "Agile -Design -Methoden nicht skalieren", während die agile Entwicklung effektiv auf jede Größe skaliert wird, wenn sie richtig implementiert und durchdacht werden.

Answer 10

Mythos: Sie müssen jeden Sprint sorgfältig planen und planen.

Dies führt dazu, dass Sie viele, viele Vorabendungen durchführen, damit Sie jeden Sprint vollständig planen können.

Dies führt dazu, dass Sie die Beweglichkeit besiegen und einen Wasserfall namens "Agile" schaffen.

Answer 11

Der größte Mythos, den ich gesehen habe, ist, dass die Leute denken, dass es besser ist als andere Entwicklungsprozesse.

Es ist die übliche Silber-Kulissen-Schlangenöl, die wir seit Jahren in dieser Branche sehen.

https://stackoverflow.com/questions/301993/is-agile-development-dead/302060#302060

Answer 12

Mythos: Agile ist im Vergleich zu anderen Alternativen immer eine bessere Option.

Fakt: Je nach Projektgröße, Anforderungen (insbesondere Flexibilität solcher), externer Zeitplan und Kundeneinstellung ist es im Vergleich zur orthodoxen Methode möglicherweise nicht immer produktiver.

Answer 13

Mythos: Agile bedeutet XP und Scrum

Tatsache: Es gibt andere Praktiken wie Openup, AMDD usw.

Answer 14

Es ist leicht zu wissen, was Ihren Kunden aufladen soll. Dies ist immer die größten Probleme für uns, da wir den Umfang des Projekts nicht kennen, dass wir dem Kunden keinen festen Preis geben können und die meisten Kunden einen festen Preis fordern.

Answer 15

Toller Thread. Während ich in meinem zugehörigen Blog -Beitrag nichts Neues anbiete, veranschaue ich die beiden besten Gründe, warum Agile fehlschlägt, wenn es fehlschlägt. 1) Mangel an Vorausanforderungen (Annahme des Codierens mit unvollständigen Anforderungen an einen extrem RÜCKGELD).

http://www.anujvarma.com/blogengine.net/post/2010/11/03/agile-versus-flat-footed-development.aspx

Answer 16

Sie haben völlig recht, dass es viele Mythen in Agile gibt, einige kommen von außen und andere von innen. Hier sind einige weitere, an die ich nachgedacht habe, um der Liste hinzuzufügen:

"Sie benötigen keine Projektmanager oder Business -Analysten mehr"

Obwohl wir BDUF nicht machen und die Teams selbst lenken, ist es immer noch ein Bedürfnis nach Menschen, deren Job das Koordinieren, was vor sich geht, koordiniert. Und wenn Sie ein sehr komplexes Geschäftsszenario haben, brauchen Sie möglicherweise jemanden, der Ihnen hilft, dies zu verstehen. IME, viele der Projekte, die PMs und Bas wirklich brauchten, brauchen sie immer noch (und diejenigen, die sie jetzt nicht brauchen, brauchten sie wahrscheinlich nie!). Aber natürlich sind die Rollen von PMS und BAS in der agilen Welt tendenziell unterschiedlich, und das kann die Menschen unruhig machen.

"Agile kann nicht für feste Preisprojekte verwendet werden"

Es kann, aber es ist etwas schwieriger. Zumal wir alle wissen, dass "fester Preis" wirklich "fester Preis, Umfang und Zeit" bedeutet ...

"Wir machen nicht bduf, wir machen alles, während wir mitfahren"

Der einzige Weg zur Arbeit ist Jeduf (gerade genug Design vorne). Manchmal brauchst du mehr, manchmal kannst du mit weniger auskommen, aber du machst nicht mehr als du zu diesem Zeitpunkt brauchst.

Answer 17

Mythos: Agile ist gegen die Sicherheit anti-thetisch.

Tatsache: Dies gilt nur, wenn Sie versuchen, einen SDL (Sicherheitsentwicklungslebenszyklus) auf angeblich agile Teams zu zwingen. Tatsächlich habe ich agile-sdl-Varianten in zahlreichen Organisationen entworfen und implementiert, und ich kann sagen, dass das Erstellen der Agile die Erstellung hinein Die Sicherheit kann sich tatsächlich ein höheres und robusteres Sicherheitsniveau leisten. Es erfordert nur eine Änderung der Sicherheitsdaltung - von Kontrolle zu Sichtweite und Orientierungshilfe.

Answer 18

Wenn Sie mit Agile keinen echten Wert zeigen, wird dies scheitern. Und scheitern kläglich wie in bankrottem Unternehmen kläglich. Wenn Sie nach Agile gehen, nur weil es "agil" ist, sehen Sie in diesem Video so albern aus wie der CIO:

http://www.youtube.com/watch?v=nvks70pd0rs

John