Besser weise als agil sein

Ich denke, dass die Menschen zu sehr auf die Einhaltung agiler Methoden fixiert sind. Agile Prinzipien und Best Practices sind wertvoll für die Anwendung wichtiger Lektionen, die in der Softwareentwicklung gelernt wurden. Der Nachteil des Befolgens von Methoden ist jedoch, dass man Erfahrung und Weisheit braucht, um zu wissen, welche ihrer Praktiken in einer bestimmten Situation am besten funktionieren. Best Practices und sogar Prinzipien, die blindlings befolgt werden, können mehr schaden als nützen, selbst wenn sie agil sind.

Um dies zu veranschaulichen, betrachten Sie die folgenden beiden Agile-Prinzipien:

Geschäftsleute und Entwickler müssen während des gesamten Projekts täglich zusammenarbeiten.

Das mag manchmal wünschenswert sein, aber es ist nicht üblich. Geschäftsleute brauchen ihre Zeit, um Geschäfte zu machen. Die Einbindung von Geschäftsleuten ist wichtig für die Softwareentwicklung, aber der Zeitaufwand, der von Geschäftsleuten verlangt wird, kann von Projekt zu Projekt sehr unterschiedlich sein. Eine zu rigorose Befolgung dieses agilen Prinzips kann dem Unternehmen mehr schaden, als durch die Steigerung der Qualität und Geschwindigkeit der Softwareentwicklung gerechtfertigt ist.

Die besten Architekturen, Anforderungen und Entwürfe entstehen in selbstorganisierten Teams.

Wenn Sie ein kleines Team von motivierten und qualifizierten Mitarbeitern haben, die sich mit dem Geschäft und den verwendeten Technologien auskennen, ist das sicherlich richtig. Ich habe jedoch gesehen, wie dieses Prinzip bei mehreren Projekten versagt hat. Diese Projekte wurden in der Regel zu schnell mit zu willkürlich ausgewählten Mitarbeitern aufgestockt. Eine RNP-Ausarbeitungsphase hätte mehr geholfen, als darauf zu hoffen, dass sich spontan etwas Gutes ergibt.

Wenn die agilen Prinzipien nicht allgemein auf alle Projekte anwendbar sind, so gilt dies umso mehr für die Regeln, die von bestimmten agilen Methoden vorgegeben werden. Ich werde einige XP-Beispiele anführen. Wenn 100 JSPs entwickelt werden müssen, die sich technisch ähneln, ist es nicht die beste Wahl, für den gesamten Produktionscode, der entwickelt wird, Pair Programming einzusetzen. Wenn die Hälfte Ihres Projekts auf bestehendem Produktionscode basieren kann, lohnt es sich vielleicht nicht, wann immer und wo immer möglich ein Refactoring vorzunehmen, weil das Design besser hätte sein können. Es ist vielleicht auch keine gute Idee, Unit-Tests für alle Klassen zu schreiben.

Verstehen Sie mich nicht falsch. Ich glaube, dass die agile Bewegung viele Ideen hervorgebracht hat, die Softwareentwicklungsprojekten sehr helfen können. Aber für jedes Team und jedes Projekt sind die agilen Ideen, die funktionieren, und die Ebene, auf der diese Ideen für eine optimale Lösung angewendet werden sollten, unterschiedlich.