Quel est l'impact d'ITIL ou du CMMI sur le développement? [fermé]

Question

J'ai lu beaucoup de livres sur les pratiques qui fonctionnent ou non dans le développement de logiciels. Et je n’ai jamais entendu parler de méthodes telles que ITIL ou CMMI dans les diffusions Web, les livres ou les blogs dans le domaine du développement.

J'ai entendu parler de ces méthodologies dans mon école et il me semble que ce sont des pratiques bureaucratiques.

Cependant, tous les livres sur le développement que j'ai lus parlent de collaboration ou de personnes plutôt que de documentation. (Oui, beaucoup de livres agiles)

Ma question est donc la suivante: les méthodologies telles que ITIL ou CMMI ont-elles un impact ou une relation avec le développement ou la vie quotidienne du développeur? Et avez-vous d'excellents livres ou blogs qui parlent de bonnes idées dans ces métodologies que je peux utiliser dans une équipe de développement?

Answer 1

ITIL étant davantage axé sur l'infrastructure et le support, et non sur le développement, la discussion sur ITIL est probablement plus appropriée à & "IT &"; version ciblée de StackOverflow supposément en développement. En passant, je ne suis pas d'accord avec l'appel de cet autre site & "; IT &"; ciblé, car la TI englobe l’infrastructure, le support et le développement dans la plupart des entreprises ... probablement un bon pourcentage des utilisateurs de StackOverflow sont des développeurs travaillant dans les services informatiques.

J'ai travaillé avec CMMI et Team Software Process (TSP), deux produits de Watts Humphrey et du Carnegie Mellon Software Engineering Institute. Si vous vous engagez dans une démarche d'amélioration continue et que vous estimez que la mesure est au cœur de toute amélioration continue, vous constaterez l'intérêt du CMMI.

Il est très facile de faire CMMI (et TSP) de manière incorrecte ou de manière à aliéner les développeurs et à se transformer en une façade ou en quelque chose de bien sur une pile de certifications. Regardez les fournisseurs de développement en Inde ... ils sont miraculeusement tous au niveau 5 du CMMI. Ce qu’ils ne vous disent pas, c’est qu’il s’agissait presque toujours d’un petit projet ou d’une seule équipe de leur organisation qui a travaillé dur pour obtenir la certification, mais des pratiques répétables. ne sont tout simplement pas là pour 95% de leur organisation.

L'accent mis sur le suivi du temps (horodatage), du suivi des défauts (quotas de bogues), des lignes de code (beaucoup de façons de & "jouer &" si vous êtes si enclin) et de rendre votre processus Répétable (faire en sorte qu'un développeur se sente comme un rouage sans liberté d'innover) désactive de nombreux développeurs. < - notez les contre-arguments blasés entre parenthèses.

Il n'en reste pas moins que 90% des développeurs (dont très peu lisent StackOverflow ou des blogs techniques / sites Web) tirent de la hanche et manquent cruellement de conscience de leurs possibilités d'amélioration. Pour eux, la rigueur du processus et la possibilité d’améliorer progressivement la qualité grâce à la conscience de soi que facilitent la répétition et la mesure sont des éléments précieux du CMMI.

Bien fait, vous bénéficiez des mêmes avantages que dans les méthodes agiles telles que Scrum, qui met l’accent sur les itérations répétables, l’apprentissage de chaque itération et l’amélioration / la réduction de votre objectif. Il faut beaucoup de maturité et d’expérience pour diriger une équipe dans l’adoption de méthodes agiles ou de CMMI et en tirer toute la valeur.

Agile est sexy et le CMMI est à peu près aussi sexy que possible, raison pour laquelle vous n'en entendez pas autant parler.

Answer 2

L'adoption agile a tendance à être ascendante: les techniciens le tombent dessus et le recommandent à la direction.

ITIL / CMMI a tendance à être top-down: la direction l’abat et la repousse au niveau technicien.

Cela ne rend pas l’un bon et l’autre mauvais; principalement qui affecte le langage utilisé pour décrire chaque approche. Et il existe de nombreuses exceptions: les personnes expérimentées dans les tranchées qui savent utiliser le CMMI et les gestionnaires qui font preuve d'agilité.

Google pour " CMMI agile " et vous obtiendrez de nombreux hits. Je préfère ne pas en recommander un en particulier, car il s’agit d’un débat en cours (c’est-à-dire que certains de ces gens se trompent carrément).

À mon avis, la notion de processus est certainement une idée utile dans l'analyse du travail quotidien de développement de logiciels. L'idée qu'il existe des activités récurrentes, et que ces activités sont souvent organisées en séquences similaires, est un bon point de départ pour poser des questions qui conduisent à une amélioration. Vous pouvez également gagner du temps en demandant ce qui est reproductible et dans quelles conditions les activités peuvent être appelées gérées .

L'erreur et les excès commencent lorsque la pensée magique s'installe: & "; si nous décrivons simplement (sur papier) le processus parfait et le documentons avec précision, les gens le suivront et nous obtiendrons un logiciel parfait. " Ça ne marche pas comme ça.