An der Universität haben wir über agile Programmierung gesprochen, aber auch darüber, wie viele agile Methoden in der Geschäftswelt nicht verwendet werden, wie die Paarprogrammierung.
Ich würde gerne wissen, welche Methoden zur agilen Programmierung gehören (extreme Programmierung, Paarprogrammierung) und welche wirklich verwendet werden / benutzen Sie. Was ist mit iterativer und inkrementeller Entwicklung?
edit: für diejenigen, die diese Frage wegen "subjektiv und argumentativ" schließen wollten. Diese Frage kann beantwortet werden, denn agile Entwicklung ist ein definierter Ausdruck. Ссылка . Weiterhin sind viele User an dieser Frage interessiert, um sie zu schließen, wird nicht gut überlegt.
Agile Entwicklung ist keine Methode an sich, sondern ein Überbegriff, der mehrere agile Methoden beschreibt (die alle zur iterativen und inkrementellen Entwicklung - IID - Familie gehören).
alt text http://img62.imageshack.us/img62/6374/dd997578teamprojagileum.png
Bei der Unterzeichnung des Agilen Manifests 2001 wurden die folgenden Methoden vertreten: eXtreme Programming (XP), Scrum, DSDM , Adaptive Software Entwicklung (ASD), Kristall, Feature-Driven Development (FDD), Pragmatische Programmierung. Jeder von ihnen teilt die Kernwerte des Agilen Manifests, implementiert sie aber mit einem etwas anderen Ansatz.
Im Gegensatz dazu ist die Paarprogrammierung eine Ingenieurpraxis (sie ist eine der Praktiken von XP, die viele Praktiken als eine unteilbare Menge , aber Sie können sie außerhalb von XP verwenden). Und während ich Praktiken sehr schätze, bedenke nur, dass Praktiken kein Ende sind, sie sind nur ein Mittel, wie ich geschrieben habe zuvor . Bei Agile geht es nicht um Paarprogrammierung, Stand-up-Meetings usw. Bei Agile geht es darum, den Kundenwert zu maximieren und gleichzeitig die Verschwendung zu minimieren, um den optimalen ROI zu erzielen. Agile ist geschäftsorientiert, Praktiken sind nur ein Weg, um dieses Ziel in einem gegebenen Kontext zu erreichen.
Scrum und XP (zusammen benutzt) werden heutzutage am häufigsten verwendet.
Klingt so, als würdest du wirklich wissen wollen, was Menschen in der realen Welt tatsächlich benutzen. Es gibt viele Websites über was ist in und was ist keine Agile Praxis / Methodik.
Also, meine bisherigen Erfahrungen in meinen letzten (letzten 5 Jahren) Rollen:
Ich bin gerade auf die Ergebnisse der Agile Practices Survey: Juli 2009 gestoßen. Es ist eine ziemlich kleine Stichprobe (123), aber es bietet eine interessante Perspektive. Zum Beispiel waren die Top 10 der effektivsten agilen agilen Praktiken (wie von den Befragten berichtet):
Es gibt auch Diagramme für Top-10-agile Praktiken, die:
Wir machen die Praktiken nicht um der Praxis willen. Die agilen Praktiken ergeben sich aus den agilen Prinzipien , wie auf der erklärt Manifestwebsite . Das höchste agile Prinzip lautet: "Den Kunden durch frühzeitige und kontinuierliche Lieferung wertvoller Software zufriedenstellen". Früh , kontinuierlich und wertvoll sind die Schlüsselwörter. Wenn ein Team nicht versteht, wie die Prinzipien die Praktiken vorantreiben, riskieren sie, wie @Guildencrantz sagte, Frachtkult zu sein, nicht den Zaubererfolg zu haben, den sie erwarten, und erklären agil einen Fehlschlag und aufgeben es.
Ich habe kein gutes Zitat zur Hand, aber es wird allgemein als leichter erachtet, auf Greenfield-Projekten dann ist es ein Brownfield-Projekt zu agil zu machen. Ein Grund dafür ist, dass bestehender Code oft so geschrieben wird, dass es schwierig ist, automatisierte Tests hinzuzufügen. Michael Feathers hat ein ganzes Buch über das Hinzufügen von Tests zu altem Code geschrieben.
Die meisten erfahrenen Entwickler sind inzwischen Projektmanager oder IT-Leiter geworden. Damals, vor etwa 20 Jahren, gab es solche Methoden wie Agile Software Development noch nicht einmal, und sie waren in der Lage, Arbeitssysteme zu produzieren und zu liefern.
Diese gleichen Leute könnten das Wissen über eine solche vorgeschlagene Praxis aufgrund dieser neuen Methoden nicht haben, die aus einer Art Widerstand gegen die Herbeiführung dieser Vorgehensweise resultieren.Wir können für sie nicht grob sein, sie widerstehen nur Veränderungen, die sie nicht kennen oder gar nicht verstehen, wie zum Beispiel ein Kunde, der es gewohnt ist, in einer Richtung zu arbeiten, und dann kommen wir mit unseren neuen Methoden und dann Ändern Sie die Gewohnheiten dieses Kunden innerhalb eines Tages! Es ist ganz normal, dass diese Widerstände auftreten, sie sind menschliche Bahviours.
Außerdem bekommen sie für einige dieser erfahreneren Leute nicht einfach den Sinn, zum Beispiel paarweise zu arbeiten. So wie sie im Allgemeinen nicht an Scrum-Treffen glauben, bevorzugen sie den alten Schulweg, der seinen Erfolg in irgendeiner Weise erkannt hat, von einem Treffen, das 1 bis 2 Stunden pro Woche dauert.
Für Administratoren, die für die Budgets von Programmierressourcen verantwortlich sind, sieht man, wie bei der Paarprogrammierung, einen Programmierer, der nichts tut, während dieser Do-nothing-Programmierer an einem anderen Teil des Codes arbeiten kann, um die Produktivität zu multiplizieren. Du kannst ihnen auch nicht wirklich die Schuld geben, da das, was sie denken, machtvoll ist.
Einige Vorschläge aus der Agile Software-Entwicklung sind im Vergleich zu anderen leichter zu nutzen. Während die Paarprogrammierung vielleicht keinen wirklichen Erfolg in der Praxis oder sogar tägliche Scrum-Meetings kennt, ist ein Erfolg nach meiner Erfahrung das beginnende Codieren, sobald wir eine präzise Skizze der Software, ihrer Anforderungen und Funktionen erhalten, niemals die Prioritäten zu vergessen, die der Kunde selbst gegeben hat. Aktualisieren Sie dann die UML-Analyse während der Entwicklung für eine Iteration.
Software-Iterationen haben nach meiner Erfahrung einen wachsenden Erfolg.
Lass es Zeit, Agile Software Entwicklung, wie Test Driven Development, gut in meiner Region, sind immer noch neue Sachen. Sobald sie mehr Praktizierende bekommen, werden ihre geübten Praktiken damit wachsen, glaube ich.
Es hängt von Unternehmen zu Unternehmen ab. Ich arbeite für eine Firma, die alle TDD, alle Paarungen, alle CI, die ganze Zeit. Das Team hat keine Angst, Sie anzurufen, wenn Sie Code einreichen, aber Unit- / FitNesse-Tests nicht einreichen, und weniger als eine Minute, nachdem Sie den Code eingegeben haben, führt der CI-Server die gesamte Testsuite und Ihren Code aus bricht den Build oder Amy der Tests fehlschlagen, Lichter gehen aus und du bist markiert als derjenige, der den Build brach.
Es ist nicht die häufigste Situation, aber sind Unternehmen, die wirklich Agile praktizieren.
In der Geschäftswelt denke ich, dass Sie im Allgemeinen Teams sehen werden, die die Aspekte, die sie mögen, aus verschiedenen Programmiermethoden ziehen und sie zu ihren eigenen Praktiken kombinieren. Sie werden wahrscheinlich den Begriff anwenden, den sie wollen, auch wenn es nicht 100% genau ist.
In unserem Team setzen wir tägliche Stand-ups und Team-Programmierung ein (etwa die Hälfte der Zeit - abhängig von der Aufgabe). Wir behaupten jedoch nicht, agil zu sein.
Die agile Methodik ist eine Basis für agile Entwicklung.
Mit anderen Worten, eXtreme Programming , Scrum und so weiter sind agile Methoden, die auf agilen Prinzipien basieren. Wenn Sie diese ausführlich prüfen, beantworten Sie Ihre Fragen.
Wie für agile selbst, und was all diese Arten von agilen Entwicklung gemeinsam haben Wikipedia für einen schönen Überblick .
Thoughtworks gehört zu den Unternehmen, die Agile Development in Kraft haben. Lesen Sie mehr über die agile Entwicklung direkt von Martin Fowlers Website.
Viele Leute scheinen Konzepte wie Refactoring, Paarprogrammierung und das allgemeine Konzept von sich selbst organisierenden Teams falsch zu verstehen ... diese können für Leute schwierig sein, die vom Wasserfall ein gewisses Maß an Erfolg haben und sich auf diese Weise verfestigt haben Dinge tun. Es ist ein Problem, diese Leute dazu zu bringen, XP auszuprobieren.
Wie andere agile erwähnt hat, ist ein Oberbegriff und kann in einer Reihe von verschiedenen Arten implementiert werden; Wenn die besagt aktuelles Modewort Status der agile hat zu vielen Unternehmen führen versuchen, agil zu implementieren, die wirklich nur eine Reihe von Ladung Kult- implementieren esque Verfahren und erwarten Agile Flexibilität.
In meiner vorherigen Firma haben sich die Manager einen agilen Griff geholt, als ob sie die Antwort auf all ihre Probleme wären. Aber das einzige, was es getan hat, war eine Menge mehr Probleme zu schaffen.
Wir hatten sehr regelmäßige Treffen, die "Standups" (eine Art agiler Begriff) genannt wurden.
Ich denke, sie haben eine Menge agiler Techniken ausprobiert, aber es hat zu dieser Zeit nicht wirklich gut funktioniert.
Tags und Links agile methodology
