it-swarm.dev

Ist der agile Ansatz eine zu bequeme Ausrede für Cowboys?

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.

Allerdings ... In meiner beruflichen Arbeit lande ich immer wieder bei Unternehmen, bei denen ein "agiler" Ansatz verwendet wird als Entschuldigung dafür warum wurde kein Aufwand in ein Front-Design gesteckt; wenn die Anforderungen gut verstanden sind.

Ich kann nicht anders, als zu denken, wenn der agile Ansatz nicht vorhanden wäre, würde ich hier mit einer netten Spezifikation auf hoher Ebene sitzen und nicht jeden zweiten Tag denselben Bildschirm und dieselbe Funktionalität erneut besuchen müssen, 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 die Lahmheit der technischen Leads von Cowboys aufzuwiegen?

Update: Ironischerweise bin ich jetzt zertifizierter Scrum Master. In einem der im Scrum-Kurs vorgestellten Artikel 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 Erstellung von Qualitätssoftware auf das "Team", was bedeutet, dass ein Team, das nicht dem Standard entspricht, Spaghetti produzieren kann, was sich meiner Meinung nach nicht von anderen agilen und nicht agilen Entwicklungsprozessen unterscheidet.

73
sipwiz

(I'm Glad it has a name

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

87
Dean Harding

Agile ist nicht mehr für schlechte Entwicklungspraktiken verantwortlich als BDUF. Das Problem liegt in der Disziplin oder dem Fehlen derselben bei der Anwendung der Praktiken. Der Zweck der BDUF-Praktiken besteht darin, die Richtung des Projekts zu identifizieren und die Risiken im Voraus zu bestimmen. Der Zweck agiler Praktiken besteht darin, den Entwicklungsstand so flexibel zu halten, dass die Richtung schnell geändert werden kann. Ein agiles Projekt könnte sehr detaillierte User Stories erstellen, sodass das Team über zukünftige Richtungen informiert ist und dennoch nur 2 oder 3 pro Iteration für die vollständige Implementierung auswählt. Das Problem bleibt das gleiche, unabhängig von der verwendeten Methodik: Das Management lässt Cowboys am Laufen.

[BDUF: Großes Design vorne]

20
Huperniketes

Agile, wie irgendetwas, kann verwendet werden, um ein schlechtes Verhalten abzudecken oder um zu versuchen, ein Problem zu lösen, für das das Team glaubt, nicht verantwortlich zu sein.

Die Magie in einigen Agile Methoden wie Scrum ist jedoch, dass sie viel Sichtbarkeit bei Problemen innerhalb der Organisation bieten. Einschließlich Probleme im Team!

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

Wenn das Problem bei den Cowboys liegt, ist dies nach der ersten Iteration sehr gut sichtbar. Wenn das Problem anderswo liegt, werden Sie es auch sehr bald sehen.

13
user2567

Seltsamerweise scheint es aus den "agilen" Projekten, an denen ich beteiligt war, eher eine Ausrede des Managements zu sein, die Phase der Anforderungserfassung zu überspringen, als ein Cowboy-Wunsch, einfach mit dem Codieren zu beginnen. Meine Projekte waren äußerst frustrierend, weil wir keine Endbenutzer haben, mit denen wir interagieren können. Stattdessen haben wir einen Direktor, der mit dem Vertrieb spricht, um herauszufinden, was die Kunden ihrer Meinung nach wollen, 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 damit, zu fragen, wie eine Funktion funktionieren soll, und der Manager schreibt die Fragen auf und stellt die Direktor. Es ist eine enorme Zeitverschwendung - aber es ist "agil"!

12
TMN

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

7

Ich sehe Abwehrkräfte von Agile Development, die sagen, dass sie nicht für Fehler verantwortlich sind, die von Cowboys verursacht werden. Erfolg mit Agile erfordert Sorgfalt und Intelligenz.

Dies scheint eine vernünftige Position zu sein, solange Sie die gleiche Konzession auf andere Methoden anwenden. Wenn Sie Agile nicht für Projektfehler verantwortlich machen können, die durch Cowboys verursacht wurden, können Sie nicht-agile Methoden nicht für Projektfehler verantwortlich machen, die durch Cowboys verursacht wurden.

Wir können dann streiten, ob es eine Korrelation (keine Kausalität!) Zwischen Agile und Cowboys gibt. Ich glaube, dass es nur anekdotische Beweise gibt. 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 die 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 nicht fälschbar. Dies ist eines der Probleme, die mich vor Scham über meinen Beruf hängen lassen - das Fehlen einer wissenschaftlichen Grundlage für viele der Behauptungen.

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

6
Oddthinking

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

Viel zu viele verkaufen es, um aus einem schlechten Team ein gutes Team zu machen, und so funktioniert es einfach nicht. Sie können keine schlechten Leute nehmen und einen Prozess anwenden, um sie plötzlich nützlich zu machen.

Ich mag viele der Ideen, die hinter Agilität stehen, aber das Versagen, das ich immer wieder sehe, ist, dass die Manager eine strikte Reihe von "agilen Prozessen" vorantreiben, die angesichts des gesamten Konzepts von Agilität darauf abzielen, dass Teams selbst sein sollten -organisieren.

Was "Cowboys" betrifft, finde ich, dass die Prozesse bei allen agilen Teams, in denen ich war, dazu dienen, sie mehr zu verlangsamen, als sie wild werden zu lassen. Ich habe noch nie eine Situation erlebt, in der Agilität dazu diente, aktivieren einen "Cowboy-Codierer".

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

Für andere Teams hilft es meiner Erfahrung nach nie, dass die schlechten Leute es besser machen, aber es manchmal dient dazu, die produktiven Leute festzumachen.

Insgesamt denke ich, dass es wichtig ist, 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.)

5
TM.

Agil, wenn es richtig gemacht wird, sollte den Effekt haben, technische "Cowboy" -Leads und "Helden" -Programmierer einzuschränken. Wenn Sie diesen Effekt nicht beobachten, kann dies ein Zeichen dafür sein, 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 sie nicht instanziieren können. Wenn Ihre konkrete Implementierung XP ist, müssen Sie eine Reihe technischer Praktiken mit viel Disziplin befolgen, was wenig Raum für Cowboy-Programmierung lässt. Eine andere Möglichkeit ist, dass die Teamarbeit eines gut selbstorganisierten Scrum Teams dies in Schach hält.

3
azheglov

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

3
Matt H

Ich arbeite derzeit in einem Geschäft, in dem dies der Fall ist, außer dass es mehr mit der Organisationskultur als mit bestimmten einzelnen Cowboys zu tun hat.

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 in der Praxis einfach keine existierende Methodik. Verschiedene Teams arbeiten unterschiedlich, aber da in der gesamten Organisationskultur keine andere Methodik als ein sehr lockerer "Agile in name only" -Prozess vorhanden ist, ist er insgesamt relativ cowboyisch und chaotisch - insbesondere bei der Integration (und davon gibt es viel) ).

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, würde ich im Interview einige ziemlich schwierige Fragen stellen, um sicherzustellen, dass tatsächlich mehr als nur eine Fehlbezeichnung von Agile befolgt wird.

3
Bobby Tables

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 zu sagen versuchten (dass Kunden unterschreiben, aber jeder seine eigene Version der Bedeutung hat). Wenn es sich nicht um eine agile Entwicklung handelt, handelt es sich um ein Wasserfallprojekt, das über das Budget hinausgeht, aber die Anwendung wird sich ändern, sobald Sie es bereitstellen. Ihre erste Version ist lediglich ein Prototyp, mit dem Benutzer die Anforderungen besprechen können. Ich nenne es eher agil als über das Budget hinaus.

2

Ich denke, es ist wahr, in einigen Umgebungen wird Agile als Entschuldigung für keine Disziplin verwendet. Das eigentliche Problem ist, dass wir aus den Augen verloren haben, warum wir irgendeine Methodik haben. Ich persönlich bin der Meinung, dass die Methodik ein Architekturproblem 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 ein paar Dinge: 1) Ohne Metriken können wir die Wirksamkeit 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 gegen Wissenstransfer).

Ohne sowohl Metriken als auch ein konkretes Ziel zu haben, wählen wir einfach eine Methodik als unsere "magische Feder", die es uns ermöglicht, Software zu liefern, wenn wir uns an die Grenzen 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 Methode verwendet werden, die von einer Person sabotiert werden kann, der die Disziplin fehlt, um alle Regeln zu befolgen? Die Frage ist gültig; Dies ist jedoch das Symptom und nicht die Ursache. Wenn ein genauer und aussagekräftiger Satz (das ist der schwierige Teil) von Prozessmetriken definiert, getestet und rechtzeitig Feedback gegeben wird, werden wir 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.)

Was sind die Metriken? Sie variieren von Projekt zu Projekt, von Team zu Team und von Zeit zu Zeit. Nützlich, wenn der Lieferplan wichtig ist, ist einer, den ich persönlich verwendet habe, die Fähigkeit und Qualität der Schätzung. Die meisten Entwickler können Aufgaben, die eine Woche oder weniger dauern, genau abschätzen. Ein Ansatz besteht also darin, das Projekt eine Entwicklerwoche lang in Aufgaben aufzuteilen und zu verfolgen, wer die Schätzung vorgenommen hat. Im Laufe des Projekts können sie ihre Schätzungen ändern. Wenn eine Aufgabe nach Abschluss um mehr als 10% (1/2 pro Tag) deaktiviert ist, behandeln wir dies genauso wie einen Fehler. Wir identifizieren, warum die Schätzung deaktiviert war (dh eine Datenbanktabelle wurde nicht berücksichtigt) Korrekturmaßnahmen (dh Einbeziehung des DBA in die Schätzung), und fahren Sie dann fort. Mit diesen Informationen können wir Metriken wie Anzahl der Schätzfehler pro Woche, Anzahl der Fehler pro Entwickler, Anzahl der Fehler pro KLOC, Anzahl der Fehler pro Entwickler-KLOC usw. erstellen. Das Posten dieser Zahlen im Team-Wiki führt zu ernsthaftem sozialem Druck und Aus Managementsicht können Sie nach einigen Wochen ein Vorhersagemodell für nachfolgende Entwicklungswochen erstellen.

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. Wenn 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 genauso gut RUP, Wasserfall oder nur eine Vielzahl von Best Practices als ideal erachten.

Mein Vorschlag ist also, dass wir uns keine Gedanken mehr über den sogenannten Prozess machen, Überprüfungen durchführen, die für unsere Entwicklungsprozessziele relevant sind, und mit verschiedenen Techniken experimentieren, um diesen Prozess zu verbessern.

2
TEC

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

Nicht-Cowboy-Programmierer erledigen ihre Arbeit gerne auf sichere, disziplinierte und geordnete Weise. Sie bauen es gerne richtig und einmal. Sie sind dafür bekannt, für immer Informationen zu sammeln, über Was-wäre-wenns nachzudenken, große Dokumente zu erstellen, die niemand liest, und Systeme zu spät oder sehr spät zu liefern. Ihre Methoden versuchen, die Risiken von Software schlechter Qualität zu mindern.

Die Brillanz agiler Methoden besteht darin, dass sie die Stärken beider Codierertypen nutzen, indem sie kurze zeitlich begrenzte Arbeitsiterationen erzwingen, bei denen Codierer aufgefordert werden, schnell kleine, qualitativ hochwertige Arbeiten zu erstellen. Und jede Iteration verringert sowohl die Opportunitätskostenrisiken einer verspäteten Lieferung als auch die Risiken einer Software von schlechter Qualität.

1
Jay Godse

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

1
user5206

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 so hatte ich nicht daran gedacht.

Das scheint mit der Erfahrung meines Kollegen mit dem "agilen" Projekt übereinzustimmen, an dem er beteiligt ist (ich war selbst noch nie bei einem): Er wird gebeten, ein Stück Code nach einer Spezifikation zu schreiben, gerade als er mit dem Testen fertig ist und ist bereit, eine neue Anforderung zu bearbeiten, die es erfordert, dass er sie ändert und erneut testet. Er findet es frustrierend.

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

1
Tony Andrews

Der Grund, warum Agile das Design/die Spezifikationen im Vorfeld kaum betont, 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 wie folgt lauten:

  • falsch - die Anforderungen können nicht erfasst werden.

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

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

0
Itay