Welche Auswirkungen hat ITIL oder CMMI auf die Entwicklung?

Question

Ich lese viele Bücher darüber, welche Praktiken in der Softwareentwicklung gut funktionieren oder nicht. Und ich habe NIEMALS von Methoden wie ITIL oder CMMI in irgendeinem Webcast oder Buch oder Blogs im Entwicklungsbereich gehört.

Ich habe über diese Methoden in meiner Schule gehört, und für mich scheint es bürokratische Praktiken zu sein.

Jedoch jede Bücher über Entwicklung, die ich gelesen habe, sprechen über Zusammenarbeit oder Menschen über Dokumentation. (Ja, viele agile Bücher)

Meine Frage ist also: Haben Methoden wie ITIL oder CMMI einen Einfluss auf die Entwicklung oder den Alltag des Entwicklers? Und haben Sie großartige Bücher oder Blogs, die über einige gute Ideen in diesen Metodologien sprechen, die ich in einem Entwicklungsteam verwenden kann?

Answer 1

ITIL konzentriert sich mehr auf die Infrastruktur- und Support-Seite und nicht auf die Entwicklung. Daher ist die Diskussion von ITIL wahrscheinlich geeigneter für die "IT" -orientierte Version von StackOverflow, die sich angeblich in der Entwicklung befindet. Abgesehen davon nehme ich eine Ausnahme mit dem Hinweis, dass andere IT-Standorte sich auf IT, Infrastruktur, Support und Entwicklung konzentrieren. Wahrscheinlich ist ein guter Prozentsatz der StackOverflow-Anwender Entwickler in IT-Abteilungen.

Ich habe mit CMMI und dem Team Software Process (TSP) gearbeitet, beides Produkte von Watts Humphrey und dem Carnegie Mellon Software Engineering Institute. Wenn Sie sich einer kontinuierlichen Verbesserung verschrieben haben und der Meinung sind, dass die Messung im Mittelpunkt jeder kontinuierlichen Verbesserung steht, dann werden Sie in CMMI Wert finden.

Es ist sehr einfach, CMMI (und TSP) falsch oder in einer Weise zu machen, die Entwickler verfremdet und schließlich als Schaufensterdekoration oder etwas, das auf einem Haufen von Zertifizierungen gut aussieht, endet. Sieh dir die Entwickler in Indien an ... sie sind wie durch ein Wunder alle CMMI Level 5.Was sie nicht sagen, ist, dass es fast immer ein kleines Projekt oder Team in ihrer Organisation war, das hart daran gearbeitet hat, die Zertifizierung zu bekommen, aber die wiederholbaren Praktiken sind einfach nicht für 95% ihrer Organisation da. Der Schwerpunkt liegt auf Zeit-Tracking (Clock-Punching), Fehler-Tracking (Bug-Quoten), Code-Zeilen (viele Möglichkeiten zum "Spiel", wenn Sie so geneigt sind), und machen Ihren Prozess wiederholbar (so dass ein Entwickler fühlen wie ..) eine Kogge ohne Innovationsfreiheit), schalten viele Entwickler aus. < - Beachten Sie die abgestumpften Gegenargumente in Klammern.

Die Tatsache bleibt, dass 90% der Entwickler da draußen (von denen einige StackOverflow oder irgendwelche technischen Blogs/Websites lesen) aus der Hüfte schießen und sehr wenig Selbstbewusstsein darüber haben, wo ihre Möglichkeiten sich zu verbessern. Für sie sind die Prozessrigorität und die Möglichkeit, schrittweise Verbesserungen in der Qualität durch das Selbstbewusstsein, das Wiederholungen und Messungen ermöglichen, zu ermöglichen, wertvolle Bestandteile von CMMI. Wenn Sie das richtig machen, erhalten Sie die gleichen Vorteile von Agile-Methoden wie Scrum, bei denen wiederholbare Iterationen im Mittelpunkt stehen, die von jeder Iteration lernen und Ihr Ziel verbessern/eingrenzen. Es braucht viel Reife und Erfahrung, um ein Team zu führen, das entweder agile Methoden oder CMMI anwendet und den vollen Nutzen aus ihnen zieht.

Agile ist sexy und CMMI ist so weit weg von sexy wie Sie können, weshalb Sie nicht so viel davon hören.

Answer 2

Agile Adoption neigt dazu, von unten nach oben zu sein: Techies stolpern darüber und empfehlen es dem Management.

ITIL/CMMI neigt dazu, von oben nach unten zu gehen: Das Management stolpert darauf und drückt es auf Techies.

Das macht das eine nicht gut und das andere schlecht; meistens beeinflusst das die Sprache, die zur Beschreibung jedes Ansatzes verwendet wird. Und es gibt viele Ausnahmen - Leute mit Erfahrung in den Schützengräben, die CMMI gut anwenden, und Manager, die agil agieren.

Google für "agile CMMI" und Sie werden viele Treffer bekommen. Ich ziehe es vor, eines nicht zu empfehlen, weil es eine andauernde Debatte ist (d. H. Einige dieser Leute sind einfach falsch).

Aus meiner Sicht ist der Begriff Prozess sicherlich eine nützliche Idee, wenn Sie die tägliche Softwareentwicklung analysieren. Die Idee, dass es einige wiederkehrende Aktivitäten gibt und dass diese Aktivitäten oft in ähnlichen Sequenzen organisiert sind, ist ein guter Einstiegspunkt für das Stellen von Fragen, die zu Verbesserungen führen. Sie können auch einige Kilometer bekommen, indem Sie fragen, was wiederholbar ist und unter welchen Bedingungen Aktivitäten aufgerufen werden können verwaltet. Der Fehler und die Exzesse beginnen, wenn das magische Denken einsetzt: "Wenn wir den perfekten Prozess beschreiben (auf Papier) und ihn genau dokumentieren, werden die Menschen ihm folgen und wir werden perfekte Software bekommen." Es funktioniert nicht so.