Ist die agile Herangehensweise eine zu bequeme Ausrede für Cowboys?


73

Ich glaube, dass ein agiler Ansatz am besten für Projekte geeignet ist, bei denen die Anforderungen verschwommen sind und viel Interaktion erforderlich ist, um die Ideen des Endbenutzers mitzugestalten.

Jedoch ... In meiner beruflichen Arbeit lande ich immer wieder in Unternehmen, in denen ein "agiler" Ansatz als Ausrede dafür verwendet wird, warum keine Anstrengungen unternommen wurden, um im Voraus zu planen. wenn die Anforderungen gut verstanden sind.

Ich kann nicht anders, als zu denken, dass ich hier mit einer netten Spezifikation auf hohem Niveau sitzen müsste, wenn es keinen agilen Ansatz gäbe, und nicht jeden zweiten Tag denselben Bildschirm und dieselbe Funktionalität erneut aufrufen müsste, wenn etwas anderes auftaucht oder so und so hatte ich nicht daran gedacht.

Reichen die Vorteile agiler Methoden wirklich aus, um die Entschuldigung für ihre Lahmheit gegenüber den technischen Führungskräften von Cowboys zu überwiegen?

Update: Ironischerweise bin ich jetzt ein zertifizierter Scrum Master. In einem der Vorträge des Scrum-Kurses wurde festgestellt, dass der beste Entwicklungsprozess ein Prozess war, bei dem ein einzelner Experte oder Guru die Entwurfsentscheidungen traf, der jedoch offensichtliche Schwächen aufweist. Scrum verlagert die Verantwortung für die Produktion von Qualitätssoftware auf das "Team", was bedeutet, dass ein unterdurchschnittliches Team mit Spaghetti davonkommen kann, was sich meiner Meinung nach nicht von anderen agilen und nicht-agilen Entwicklungsprozessen unterscheidet.


6
Downvotes eh ... Ich finde, dass einige agile Konvertiten ein bisschen defensiv werden, besonders wenn sie Agile und Cowboy im selben Satz sehen. Und ich packe nicht einmal agil ein, es sind die Cowboys, die mich irritieren.
Sipwiz

2
Dies könnte etwas damit zu tun haben, dass viele der ursprünglichen Unterzeichner des Agile-Manifests den Begriff "agil", wie er in den meisten Unternehmen verwendet wird, ablehnen. Stattdessen reden sie jetzt über Dinge wie "Software-Handwerkskunst".
Darcy Casselman

1
Lassen Sie mich zunächst sagen, dass ich KEIN Fan von Agilität bin. Zweitens sage ich, dass "Capital A Agile" meiner Erfahrung nach alle (einschließlich Cowboys) verlangsamt. Ich habe noch nie in einer Situation gearbeitet , wo ich das Gefühl , dass agile wurde ermöglicht , das so genannten „Cowboy - Coder“.
TM.

1
Ich glaube nicht, dass es richtig ist, das, was Sie beschreiben, "Cowboy-Codierung" zu nennen. Dies ist kein individuelles Problem - es ist ein Gruppenproblem. Dies ist ein schlechtes Produkt- und Teammanagement.
Matt b

3
Ich finde es fast sinnlos, von vornherein zu denken. Wenn Sie vernünftige Programmierpraktiken anwenden, kann es sehr effektiv sein, auf eine Lösung hinzuarbeiten, die den ersten Instinkten folgt. Meine Erfahrung zeigt, dass diejenigen, die im Vorfeld umfangreiche Pläne haben, nicht mehr auf die Realität reagieren können, wenn sie mit der Programmierung beginnen.
Dash-Tom-Bang

Antworten:


87

Ich bin froh, dass es einen Namen hat

Ich glaube, wenn Sie die Agile-Entwicklung als Ausrede für die Programmierung im Cowboy-Stil verwenden, verfolgen Sie die Agile-Entwicklung nicht wirklich. Cowboys werden immer Cowboys sein, egal welchen Prozess Sie ihnen geben.


17
Dilbert (immer) rockt ..
TheVillageIdiot

20

Agile ist nicht mehr für schlechte Entwicklungspraktiken verantwortlich als BDUF. Das Problem liegt in der Disziplin oder dem Mangel daran, die Praktiken anzuwenden. Der Zweck der BDUF-Praktiken besteht darin, die Richtung des Projekts zu identifizieren und die Risiken im Voraus zu bestimmen. Ziel agiler Praktiken ist es, den Entwicklungsstand flexibel genug zu halten, um schnell die Richtung zu ändern. Ein agiles Projekt könnte sehr detaillierte User Stories erstellen, sodass das Team die zukünftigen Richtungen kennt und nur 2 oder 3 pro Iteration für die vollständige Implementierung auswählt. Unabhängig von der verwendeten Methodik bleibt das Problem gleich: Das Management lässt Cowboys am Laufen.

[BDUF: Großes Design ganz vorne]


3
Es wird niemals möglich sein, die Cowboys zu vereiteln, egal wie man vorgeht. Zumindest mit Wasserfall müssten sie jedoch mindestens ein Anforderungsdokument, ein Spezifikationsdokument usw. erstellen. Mit Agilität können sie im Grunde genommen davonkommen, indem sie einfach direkt in den Code eintauchen.
Sipwiz

3
Dies ist wiederum ein Fehler bei der ordnungsgemäßen Verwaltung des Prozesses. Der Kunde sollte die Entwickler über den Geschäftswert in der User Story informieren, und die Tests sollten sicherstellen, dass sie in die Codebasis integriert sind. Protokollieren Sie die Bereiche, in denen Entwickler ihre Schritte nachvollziehen müssen. Sind sie mit den Geschäftsprozessen des Kunden nicht vertraut? Sind sie hinsichtlich der Implementierungsumgebung unsicher? Wenn das Projekt aufgrund von "Komponentenüberarbeitungen" zusätzliche Entwicklungskosten verursacht, sollte das Management dies korrigieren, um die Wahrscheinlichkeit zu verringern, dass das Budget oder der Zeitplan überschritten wird.
Huperniketes

4
Wenn Sie nur anfangen, an Code herumzuhauen, sind Sie nicht agil, selbst wenn Sie es so nennen. Was soll mich davon abhalten, einfach Code wegzuschlagen und ihn Wasserfall zu nennen, wenn ich 5 Minuten damit verbracht habe, über die Anforderungen am Anfang nachzudenken.
Craig

1
Huperniketes hat es richtig gemacht, das Problem liegt nicht in der Methodik; Das Problem ist, dass das Managementteam die Cowboys die Abteilung leiten lässt.
Jeff Siver

7
@sipwiz: Sogar im Wasserfall würden Cowboys direkt in den Code eintauchen. Schließlich würden sie dokumentieren, was sie als Designspezifikation geschrieben hatten.
TMN

13

Agilität kann wie alles andere verwendet werden, um ein schlechtes Verhalten zu decken oder um zu versuchen, ein Problem zu lösen, von dem das Team glaubt, dass es nicht dafür verantwortlich ist.

Die Magie bei einigen agilen Methoden wie Scrum ist jedoch, dass sie viel Transparenz bei Problemen innerhalb des Unternehmens bieten. Probleme im Team aufnehmen!

Sie erhalten dann die Möglichkeit, sie zu lösen, sobald sie entstehen.

Wenn das Problem bei den Cowboys liegt, wird dies nach der ersten Iteration sehr deutlich. Wenn das Problem anderswo auftritt, werden Sie es auch sehr bald bemerken.


12

Seltsamerweise scheint es bei den "agilen" Projekten, an denen ich beteiligt war, eher eine Ausrede für das Management zu sein, die Phase der Anforderungserfassung zu überspringen, als den Cowboy-Wunsch, einfach mit dem Codieren zu beginnen. Meine Projekte sind äußerst frustrierend , weil wir nicht haben mit allen Endnutzer zu interagieren. Stattdessen haben wir einen Direktor, der mit dem Vertrieb spricht, um herauszufinden, was die Kunden ihrer Meinung nach wollen, und dann ein Meeting einberuft und es den Managern beschreibt, die dann damit beginnen, den Entwicklern Aufgaben zuzuweisen. Bei einem "guten" Projekt haben wir möglicherweise eine PP-Präsentation, auf die wir uns beziehen können, aber normalerweise verbringen wir unsere täglichen Scrum-Meetings mit der Frage, wie ein Feature funktionieren soll, und der Manager schreibt die Fragen auf und fragt den Regisseur. Es ist eine enorme Zeitverschwendung - aber es ist "agil"!


Wir nennen es nichts, aber so laufen die Dinge hier im Grunde. Wir haben tatsächlich einige große Designdokumente, aber sie sind veraltet und niemand sieht sie an. Stattdessen wird jede neue Funktion oder Korrektur nur durch das bestimmt, was der Vizepräsident für aktuell hält oder was der Vertrieb den Kunden sagt, was schnell in Besprechungen herauskommt und was unter hohen Terminen abgeworfen wird.
CodexArcanum

+1: @TMN, @CodexArcanum: Ich hatte auch die gleiche Erfahrung. Es gab keinen User Champion. Der Vertrieb diktierte dem Produktmanagement neue Funktionen, die dann an die Entwicklung weitergegeben wurden.
Jim G.

7

Ich werde nicht sagen, dass ich ein Fan von Wasserfall bin, da ich mich auch mit immer frustrierendem Scope-Creep befasse, aber ich habe Agile immer als Zugeständnis an das Problem gesehen, nicht als einen wirksamen Weg, es zu bekämpfen. Ein gutes Design mit frühen iterativen Tests und vielen Papierprototypen scheint viel effektiver zu sein.


4
Das Problem ist, dass gutes Design für nichts anderes als für triviale Projekte so gut wie unmöglich ist. Probleme mit dem Design werden erst im Verlauf des Projekts offensichtlich. Benutzer wissen nicht, was sie wollen, egal wie erfahren sie sind.
Craig

@Craig. Ich stimme Ihnen zu, dass Spezifikationen nahezu unmöglich festzunageln sind, aber auch nicht-triviale Systeme sollten in der Lage sein, Prototypen auf Papier zu erstellen, und dies ist um einiges billiger als das eigentliche Schreiben des gesamten Systems, nur um herauszufinden, ob es erforderlich ist umgeschrieben werden. Wenn ein Papier-Prototyp (zumindest für die Grundfunktionalität) nicht möglich ist, ist es schwer vorstellbar, dass das jeweilige System gut funktioniert oder letztendlich sowieso sinnvoll zu implementieren ist. Wenn Sie und der Benutzer sich nicht hinsetzen und ein Testszenario auf Papier durchgehen können, bevor Sie mit der Arbeit beginnen, treten schwerwiegende Probleme auf.
Morgan Herlocker

2
@Craig Ich würde nicht zustimmen, dass ein gutes Design unmöglich ist. Es ist zwar nahezu unmöglich, jede einzelne Komplexität des Systems von vornherein zu kennen, aber dies bedeutet nicht, dass ein Entwurf gegen das, was bekannt ist, nicht erstellt werden kann. Ich meine, auch ein einziger Satz im Sinne von "Diese App wird als MVC-App unter Verwendung des Entity-Frameworks für die DAL geschrieben" wäre etwas. Abgesehen davon habe ich Ausschreibungen mit mehr als 180 Seiten mit Anforderungen gesehen, und Sie können mir nicht sagen, dass das nicht genug Detail ist, um ein ziemlich gutes Design zu erstellen.
Sipwiz

sipwiz, meiner erfahrung nach korreliert die anzahl der seiten nicht mit der nützlichkeit einer spezifikation. Was geschrieben steht, ist wichtiger, nicht wie viel. Es hängt völlig vom System ab, ob 180 Seiten gut sind oder nicht, wenn ich Windows baue, würde ich denken, dass es ein bisschen hell ist.
Craig

3
Auch ich denke, Sie müssen sich daran erinnern, dass Agilität keine Spezifikation bedeutet.
Craig

6

Ich sehe Verteidigungen von Agile Development, die besagen, dass es nicht für Fehler verantwortlich ist, die von Cowboys verursacht wurden. Erfolg mit Agile erfordert Fleiß und Intelligenz.

Dies scheint eine vernünftige Position zu sein, solange Sie die gleichen Zugeständnisse auf andere Methoden anwenden. Wenn Sie Agile nicht für von Cowboys verursachte Projektfehler verantwortlich machen können, können Sie auch nicht-agile Methoden nicht für von Cowboys verursachte Projektfehler verantwortlich machen.

Wir können dann streiten, ob es eine Korrelation (nicht eine Kausalität!) Zwischen Agile und Cowboys gibt. Ich glaube, es gibt nur vereinzelte Beweise. Wird es als ein guter Weg angesehen, mit Cowboy-Praktiken auszukommen, ohne vom Management entdeckt zu werden?

Wenn wir akzeptieren, dass Cowboys möglicherweise nicht gleichmäßig über verschiedene Methoden verteilt sind, und wir akzeptieren, dass Cowboys die erfolgreiche Verwendung eines Prozesses untergraben, haben wir es natürlich sehr schwierig gemacht, zu testen, ob ein Prozess erfolgreich ist. Die Behauptung, dass ein Prozess (innerhalb eines Kontexts) besser ist, wird nahezu unverfälschbar. Dies ist einer der Gründe, warum ich mich vor Scham über meinen Beruf schäme - das Fehlen einer wissenschaftlichen Grundlage für viele der Behauptungen.

(Übrigens hasse ich es, die Alternative (n) zu Agile als "Wasserfall" zu bezeichnen, weil Wasserfallprozesse ein Strohmann zu sein scheinen, den jeder angreift, aber nur sehr wenige Menschen jemals ohne Iteration verwendet haben.)


4
Entwicklungsfehler sind nicht das Ergebnis der Anwesenheit von Cowboys. Entwicklungsfehler sind das Ergebnis der Abwesenheit des Managements.
Huperniketes

@Huperniketes, das sind FANTASTISCHE Neuigkeiten. Programmierer sind niemals schuld! Welchen idealen Beruf haben wir gewählt!
Oddthinking

@Oddthinking, hör auf, dich auf binäres Denken zu beschränken. Programmierer können mit Sicherheit dafür verantwortlich gemacht werden, dass sie nicht das Niveau ihres Fachs erreicht haben, aber Programmierer sind niemals für Projektfehler verantwortlich. Das liegt in der Verantwortung der Projektmanager.
Huperniketes

@Huperniketes, könntest du vielleicht weiter klären, bitte? Sie sagten ursprünglich "Entwicklungsfehler", wechselten dann aber zu "Projektfehler". Ich bin damit einverstanden, dass Projektmanager möglicherweise "die Dose tragen" müssen, wenn einer ihrer Entwickler die Erwartungen nicht erfüllt, aber es ist schwer zu erkennen, dass die Nichterfüllung durch Cowboys niemals die Ursache für ein Scheitern eines Projekts sein kann.
Oddthinking

@Oddthinking, ich meinte keine Unterscheidung zwischen "Entwicklungsfehlern" und "Projektfehlern". Sie werden hier synonym verwendet. Sicher, ein Projekt war möglicherweise nicht erfolgreich, da der Programmieraufwand unterdurchschnittlich war, aber der Projektmanager hat die Aufgabe, diese Fälle zu identifizieren und sie bei Bedarf durch Änderungen im Team zu beheben. Es ist seine Aufgabe, den Erfolg des Projekts sicherzustellen. Er muss gefeuert werden, wenn er das nicht kann. Er muss also sicherstellen, dass Teammitglieder, auch Cowboy-Programmierer und Rockstar-Programmierer, ihren Verpflichtungen gegenüber dem Projekt nachkommen oder sie entlassen.
Huperniketes

5

Agile ist in Ordnung, solange es für Ihr Team funktioniert.

Viel zu viele verkaufen es, um ein schlechtes Team in ein gutes Team zu verwandeln, und es funktioniert einfach nicht so. Man kann keine schlechten Leute nehmen und einen Prozess anwenden, um sie plötzlich nützlich zu machen.

Ich mag viele der Ideen, die hinter agile stecken, aber das Scheitern, das ich immer wieder sehe, ist, dass die Manager eine Reihe von "agilen Prozessen" forcieren, die angesichts des gesamten Konzepts von agile, dass Teams selbst sein sollten -organisieren.

Was "Cowboys" angeht, finde ich, dass die Prozesse bei allen agilen Teams, in denen ich war, dazu dienen, sie mehr zu verlangsamen, als sie in den Wahnsinn zu treiben. Ich habe noch nie eine Situation erlebt, in der Agilität dazu beitrug, einen "Cowboy-Codierer" zu ermöglichen .

Für gute Teams scheint es gut zu funktionieren (andererseits scheinen die meisten Prozesse gut zu funktionieren, wenn Sie ein gutes Team haben, komisch, wie das funktioniert, nicht wahr?).

Für andere Teams hilft es meiner Erfahrung nach niemals den schlechten Leuten, es besser zu machen, aber es dient manchmal dazu, die produktiven Leute zu unterbinden.

Insgesamt denke ich, ist es wichtig, ein gutes Team aufzubauen, ihnen zu sagen, was Sie brauchen, und dann aus dem Weg zu gehen. Ich denke nicht, dass das Anwenden einer Reihe von Schlagworten das Problem eines schlechten Teams lösen kann.

(Wenn Sie das oben nicht herausgefunden haben, bin ich überhaupt kein Fan von "Capitol-A Agile". Andererseits denke ich auch nicht, dass es Cowboys ermutigt.)


3

Agilität sollte, wenn sie richtig gemacht wird, dazu führen, dass technische Leads von "Cowboys" und "Helden" -Programmierern eingebunden werden. Wenn Sie diesen Effekt nicht beobachten, ist dies möglicherweise ein Zeichen dafür, dass in Ihrer agilen Implementierung etwas Wichtiges fehlt.

Ich möchte hinzufügen, dass "Agile" wirklich eine Schnittstelle ist (ich verwende hier eine objektorientierte Metapher) und Sie können sie nicht instanziieren. Wenn Ihre konkrete Implementierung XP ist , müssen Sie eine Reihe von technischen Praktiken mit viel Disziplin befolgen, was wenig Raum für die Cowboy-Programmierung lässt. Eine andere Möglichkeit ist, dass die Teamarbeit eines gut organisierten Scrum- Teams dies in Schach hält.


3

Cowboy-Codierer neigen auch dazu, Code zu schreiben, der nicht sehr testbar ist, und sie neigen dazu, keine Tests zu schreiben. Ich denke, dass jeder, der TDD macht, dazu beitragen kann, die Haltung eines Cowboys zu wahren und Entwickler dazu zu bringen, ein wenig mehr über Architektur nachzudenken. Natürlich ist keine Methode perfekt.


1
Vergessen Sie nicht die paranoiden "if (var! = Null)" - Checks, die über den gesamten Code verteilt sind ...
Jörgen Sigvardsson,

3

Ich arbeite zurzeit in einem Geschäft, in dem dies der Fall ist, außer dass es mehr um die Organisationskultur geht als um bestimmte einzelne Cowboys.

Die Organisation hat immer einen relativ lockeren, "informellen agilen" Ansatz verfolgt. Ich würde nicht sagen, dass es wirklich agil ist, es ist eher "agil im Namen", aber einfach nicht existierende Methodik in der Praxis. Verschiedene Teams arbeiten unterschiedlich, aber da die gesamte Organisationskultur keine andere Methodik als einen sehr losen "Agile in name only" -Prozess aufweist, ist dies insgesamt relativ cowboyhaft und chaotisch, insbesondere bei der Integration (und davon gibt es eine Menge) ).

Die Moral der Geschichte lautet: Ja, das passiert. Wenn ich im Moment auf Jobsuche wäre, wäre ich sehr vorsichtig damit. Wenn ein Geschäft behauptet, agil zu sein, stelle ich im Interview einige ziemlich schwierige Fragen, um sicherzustellen, dass mehr als nur eine falsche Benennung von Agile tatsächlich befolgt wird.


1
Das klingt auch sehr nach meiner Situation. Und es kommt auf den Punkt dieser ganzen Frage, dass wenn "Agile" nicht in der Nähe von Organisationen wäre, sie sich wahrscheinlich an den Wasserfall halten würden und was auch immer ihre Mängel sind, es ist weitaus besser, keinen Prozess zu haben.
Sipwiz

2

Ich habe festgestellt, dass Benutzer uns nur dann Feedback geben können, wenn sie eine Anwendung haben, auf der sie Daten eingeben können. Nur dann verstehen sie wirklich, was wir in den Anforderungsdokumenten sagen wollten (die Kunden unterschreiben, aber jeder hat seine eigene Version der Bedeutung). Wenn es sich nicht um eine agile Entwicklung handelt, wird es sich um ein Wasserfallprojekt handeln, das über das Budget hinausgeht, aber die Anwendung wird sich ändern, sobald Sie sie bereitstellen. Ihre erste Version ist nur ein Prototyp, mit dem Benutzer die Anforderungen diskutieren können. Ich nenne es eher agil als über das Budget.


Ich habe das auch gesehen (Kunden, die eine frühe Version sehen und sich zu sehr mit den Fehlern / Funktionen beschäftigen, von denen Sie wissen, dass sie noch nicht fertig sind), und Sie können manchmal Schwierigkeiten haben, nützliches Feedback zu erhalten. Ich denke, das ist eine Frage der Kundenerziehung.
Dean Harding

Prototyping ....
sipwiz

2

Ich denke, es ist wahr, in einigen Umgebungen wird Agile als Ausrede für keine Disziplin verwendet. Das eigentliche Problem ist, dass wir die Methodik aus den Augen verloren haben. Persönlich bin ich der Meinung, dass die Methodik ein architektonisches Problem in dem Sinne ist, dass die Architektur des Systems die nicht funktionalen Qualitätsattribute berücksichtigen soll. Die Methodik sollte einige dieser Attribute berücksichtigen (Wartbarkeit, Entwicklungsproduktivität, Wissenstransfer, et al.)

Das Betrachten der Methodik als Kontrolle für die Prozessattribute impliziert eine Reihe von Dingen: 1) Ohne Metriken können wir die Effektivität einer Methodik nicht mit einer anderen vergleichen. 2) Es muss eine aktive Entscheidung darüber getroffen werden, welche Attribute wichtig sind (Lieferzeit vs. Code) Qualität versus Wissenstransfer).

Ohne Metriken und ein konkretes Ziel zu haben, wählen wir einfach eine Methode als unsere "magische Feder", die es uns ermöglicht, Software zu liefern, wenn wir uns daran halten.

Jetzt sprechen die Neinsager von Agile, XP, Scrum usw. über die Fragilität dieser bestimmten Kategorie von Methoden. Das Argument lautet: Warum sollte eine Methodik angewendet werden, die von einer Person, der es an Disziplin mangelt, sabotiert werden kann, um alle Regeln einzuhalten? Die Frage ist richtig. Dies ist jedoch das Symptom und nicht die Ursache. Wenn ein genauer und aussagekräftiger Satz von Prozessmetriken definiert, getestet und zeitnahes Feedback gegeben wird, werden wir meiner Meinung nach feststellen, dass die jeweilige Methodik wenig mit Erfolg zu tun hat. (Anekdotisch gesehen habe ich erfolgreiche Projekte mit einer Vielzahl von Methoden gesehen, und doppelt so viele scheitern mit denselben Methoden.)

Also, was sind die Metriken? Sie variieren von Projekt zu Projekt, Team zu Team und von Zeit zu Zeit. Nützlich, wenn der Liefertermin wichtig ist. Eine, die ich persönlich verwendet habe, ist die Fähigkeit und Qualität zu schätzen. Die meisten Entwickler können Aufgaben, die eine Woche oder weniger dauern, genau einschätzen. Daher besteht ein Ansatz darin, das Projekt eine Entwicklerwoche lang in Aufgaben zu unterteilen und nachzuverfolgen, wer die Schätzung vorgenommen hat. Im Laufe des Projekts können sie ihre Schätzungen ändern. Wenn eine Aufgabe abgeschlossen ist und die Abweichung mehr als 10% (1/2 pro Tag) beträgt, wird dies wie ein Fehler behandelt. Ermitteln Sie, warum die Schätzung deaktiviert war (dh eine Datenbanktabelle wurde nicht berücksichtigt) Korrekturmaßnahme (dh beziehen Sie den DBA in die Schätzung ein), und fahren Sie dann fort. Mit diesen Informationen können wir Kennzahlen erstellen, z. B. Anzahl der geschätzten Fehler pro Woche, Anzahl der Fehler pro Entwickler,

Na und? Dann kommen die Methoden ins Spiel. Wenn Sie ein Vorhersagemodell haben, das die Prozessqualitäten nicht erfüllt, können Sie einen Aspekt der Methode hinzufügen oder entfernen und sehen, wie sich dies auf Ihr Modell auswirkt. Zugegeben, niemand möchte aus Angst vor dem Scheitern mit einem Entwicklungsprozess spielen, aber wir scheitern bereits mit einer konstant hohen und vorhersehbaren Rate. Indem Sie individuelle Änderungen vornehmen und das Ergebnis messen, stellen Sie möglicherweise fest, dass Agile die perfekte Methode für Ihr Team ist. Sie können jedoch auch RUP, Wasserfall oder eine Vielzahl von Best Practices als ideal erachten.

Mein Vorschlag ist also, sich keine Gedanken mehr über den Prozess zu machen, Überprüfungen durchzuführen, die für unsere Entwicklungsziele relevant sind, und mit verschiedenen Techniken zu experimentieren, um diesen Prozess zu verbessern.


Gute Argumente. Meine Frustrationen resultieren aus den Ergebnissen eines agilen Ansatzes, der viel flüssiger ist und es einem inkompetenten Techniker ermöglicht, mit allem, was er will, davonzukommen, und was meiner Erfahrung nach als überhaupt kein Prozess für die Codierung von Cowboys endet.
Sipwiz

1

Ich würde hier mit einer netten High-Level-Spezifikation sitzen und nicht jeden zweiten Tag den gleichen Bildschirm und die gleiche Funktionalität erneut aufrufen müssen, wenn etwas anderes auftaucht, und hätte deshalb nicht daran gedacht.

Das scheint mit der Erfahrung meines Kollegen in Bezug auf das "agile" Projekt übereinzustimmen, an dem er arbeitet (ich war selbst noch nie bei einem): Er wird gebeten, einen Teil des Codes nach einer Spezifikation zu schreiben, sobald er damit fertig ist und ist bereit, eine neue Anforderung zu bearbeiten, die es erforderlich macht, sie zu ändern und erneut zu testen. Er findet es frustrierend.

Ich schlage nicht auf Agile ein, ich vermute, das Team macht Agile nicht richtig - aber wie Sie sagen, kann der Begriff "Agile" manchmal von Cowboys verwendet werden, um Spitzenköpfe davon zu überzeugen, dass halbgebackenes Design eher positiv als negativ ist .


Agile ohne automatisierte Tests bittet um Kopfschmerzen
Steven A. Lowe

1

Es ist lustig, wie sich niemand als Cowboy-Programmierer sieht. Ich wette, viele der Poster sind oder waren eins;)


1
Ich würde vermuten, dass die meisten von uns als Cowboys angefangen haben.
David Thornley

Sie mögen Recht haben, und ich habe noch nicht lange programmiert, aber als ich in einem Geschäft ohne Methodik war, hatten wir Cowboys. Ich bin jetzt in einer agilen Beratungsfirma, und was Sie tun, ist groß und sichtbar, und es fällt mir schwer, mir einen Cowboy vorzustellen, der diese Umgebung genießt.
Eric Wilson

1

Cowboy-Programmierer sind gut, weil sie es mögen, Dinge schnell zu erledigen. Sie sind oft nicht so besorgt über Probleme mit dem Gesamtbild oder der Codequalität, weshalb "Cowboy-Codierer" oft ein Beiname ist. Ihre Methoden verringern die Risiken der Opportunitätskosten einer verspäteten Projektabwicklung.

Nicht-Cowboy-Programmierer arbeiten gerne sicher, diszipliniert und ordentlich. Sie bauen es gerne richtig und bauen es einmal. Sie sind dafür bekannt, für immer Informationen zu sammeln, Was-wäre-wenn, große Dokumente zu erstellen, die niemand liest, und Systeme spät oder sehr spät auszuliefern. Ihre Methoden versuchen, die Risiken schlechter Softwarequalität zu mindern.

Die Brillanz der agilen Methoden besteht darin, dass sie die Stärken beider Codierertypen nutzen, indem sie kurze, zeitlich begrenzte Arbeitsiterationen erzwingen, die die Codierer auffordern, schnell kleine, qualitativ hochwertige Arbeiten zu erstellen. Und mit jeder Iteration werden sowohl die Risiken der Opportunitätskosten einer verspäteten Lieferung als auch die Risiken von Software schlechter Qualität gemindert.


0

Der Grund, warum agiles Design / Spezifikationen nur sehr wenig in den Vordergrund rücken, liegt nicht nur darin, dass sich die Anforderungen ändern können. Der tiefere Grund ist, dass selbst bei stabilen Anforderungen die Spezifikationen in der Regel folgende sind:

  • falsch - die Anforderungen werden nicht erfasst.

  • inkonsistent - voller Widersprüche, weil sie genug Informationen enthalten, um es dem Autor / Leser unmöglich zu machen, sie zu fassen.

  • Abgelöst - Sie enthalten kein wertvolles Feedback von einem laufenden (obwohl degenerierten) System.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.