Comment les normes et les améliorations de processus devraient-elles être introduites dans une organisation sans elles?

10

J'ai été chargé d'améliorer le processus de développement de logiciels grâce à la mise en œuvre d'améliorations de processus, dont nous utiliserons très probablement CMMI pour le développement, version 1.3 comme ligne directrice et adopter les meilleures pratiques en tout ou en partie. Quelle est la meilleure façon d'introduire des normes et des améliorations de processus afin que le degré de refoulement et de résistance des développeurs soit minimisé?

standards cmmi process-improvement rjzii
la source
Juste curieux, avez-vous déjà une idée de la raison pour laquelle plus de bugs passent alors souhaité?
Chris Pitman
2
@ S.Lott Pouvez-vous faire valoir que les bogues ne sont pas réduits (du côté des consommateurs) sans normes? Mon expérience d'un processus et de normes réduit considérablement ce que le consommateur voit sur les bogues ... pas qu'ils n'existent pas, ils ne sont tout simplement jamais vus par le client.
Rig
@RobZ: Je n'ai pas demandé ce que vous avez actuellement. J'essaie toujours de comprendre la question. «mettre en œuvre des améliorations de processus» semble être la description la plus précise de ce que vous demandez. Je dirais que «normes» est un terme déroutant, car il a une définition formelle et vous n'utilisez pas cette définition formelle.
S.Lott
@Robz: "Coding Standards" n'est pas "Formal Standards". Cela clarifiera la question. Encore. Les "normes formelles" sont les normes W3C, Posix, ISO, IEEE, ANSI. Rédigé et approuvé par une organisation reconnue de création de stands. Si vous parlez de normes de codage, veuillez mettre à jour la question pour supprimer le mot «formel» et utiliser le mot «codage». Avec ce changement, votre question est logique. Et c'est un doublon.
S.Lott
"En ce qui concerne les mots" normes "dans le titre conjointement avec les améliorations de processus, le mot normes ne s'applique pas seulement au code que quelqu'un écrit"? Quelle? Voici un indice. Veuillez ne pas utiliser le mot "standard" sans une sorte de qualificatif; c'est confu. Si vous voulez dire "normes de codage", veuillez utiliser cette expression. Si vous voulez dire un autre type de "standard", veuillez qualifier le mot "standard" avec une phrase qualificative pour clarifier ce dont vous parlez. "standard" est vague et déroutant.
S.Lott

Réponses:

2
  1. Lancer un projet d'amélioration des processus logiciels (SPI) . Définissez sa portée et ses objectifs. Il sera certainement utile que la normalisation ait ses propres objectifs et mesures applicables à votre organisation.
  2. Désigner une personne responsable de l'adoption des normes . Il peut également s'agir de plusieurs personnes ou même d'un service dans le cas d'une grande organisation. L'important est que tous les responsables de la normalisation soient:
    • assez professionnel pour voir l'image entière
    • suffisamment influent pour traiter avec les équipes et les aider à adopter / négocier des changements
  3. Développez des formations couvrant à la fois la norme que vous souhaitez adopter et ses spécificités appliquées à votre organisation. Et c'est vraiment important tant que toutes les personnes qui n'ont pas été formées sont potentiellement résistantes aux changements. Par exemple, lorsque je travaillais dans une grande entreprise, j'ai donné des instructions à tous les nouveaux arrivants sur les processus d'assurance qualité, CMMI, ISO et système de gestion de la qualité. Cette formation était obligatoire. Il a permis d'améliorer les connaissances sur les processus de gestion de la qualité et de sensibiliser les employés à l'importante question de la qualité des logiciels.
  4. Négociez les changements et adaptez les pratiques généralement acceptées à vos besoins spécifiques. Cela permettra d'éviter la bureaucratie et la mise en œuvre de processus lourds dont personne n'a vraiment besoin.
  5. Établissez un suivi de la façon dont les améliorations de processus mises en œuvre sont prises en charge et si elles sont suffisamment efficaces dans votre organisation.

Il vous sera également utile de trouver toutes les personnes au sein de votre organisation qui sont vraiment préoccupées par la qualité. Il s'agit très probablement de la ressource la plus importante pour vous aider à promouvoir des changements et à établir des pratiques matures.

altern
la source
6

Quelques réflexions de l'école des coups durs:

1) La plupart des initiatives d'amélioration des processus consacrent 80% de leur temps à la conception des processus et 20% à l'éducation et à la socialisation. Inversez ces pourcentages. Un standard médiocre qui est suivi bat un parfait qui ne l'est pas.

2) Identifiez les raisons claires pour lesquelles vous demandez aux gens de changer leur façon de travailler. Quel est le cas commercial? Idéalement, cela profite à chaque équipe individuellement. Parfois, ce n'est qu'une amélioration systémique. Dans tous les cas, rendez le boîtier visible.

3) Simplifiez, puis standardisez, et non l'inverse.

4) Vous ne pouvez pas entièrement déléguer cela à un PMO. Les gestionnaires directs doivent être achetés et le chef de l'unité commerciale devra rompre les liens lorsque des plaintes arrivent.

5) Trouvez des adopteurs précoces amicaux. Les gens se plaindront du temps que cela prendra. Vous avez besoin de quelqu'un vers qui vous pouvez pointer du doigt et dire: "ça ne leur a pris que 15 minutes"

6) Pour les métriques, insistez pour que le quantitatif soit le qualitatif. Sinon, vous avez des projets qui sont verts jusqu'à la veille de la mise en ligne, lorsque tout glisse d'un mois.

7) Mettez l'accent sur les techniques plutôt que sur les outils. Une bonne planification est plus importante que MS Project.

8) Mettre en place un niveau de processus par rapport aux besoins. Chaque restaurant a besoin d'un processus, mais Nobu et la French Laundry ont besoin d'un type différent de McDonalds. Même chose avec les éditeurs de logiciels.

Bonne chance!

MathAttack
la source
1
Excellente réponse - J'ajouterai également soyez très prudent avec le processus que vous introduisez - Assurez-vous de ne pas tomber dans le piège de faire ce qui est le mieux pour le processus, pas ce qui est le mieux pour le client - c'est-à-dire que le processus doit être axé sur le client. Faites également attention à ce que vous mesurez - par définition, ce qui est important est important et ce qui n'est pas mesuré est sans importance. Mesurez les mauvaises choses (SLOC / Day, Bugs / SLOC etc.) et vous n'obtiendrez aucune amélioration, mais les mesures vous diront que vous l'êtes.
mattnz
1
@mattnz - Je ne sais pas, error / SLOC peut être une métrique utile si vous l'appliquez correctement. Si quelqu'un dit qu'il a en moyenne 1 erreur / 10 SLOC, je serais probablement inquiet. L'astuce est que vous devez savoir où se trouvent les barres, ce qui peut être difficile.
rjzii
Bon point. Les gens optimisent leurs mesures. Si vous produisez d'abord des mesures financières, les gens optimiseront cela au détriment de la fonctionnalité ou du service client. C'est une question d'équilibre et de priorités.
MathAttack
1
Mesurez-moi par les erreurs / SLOC, SLOC / jour, et vous serez surpris de voir à quel point je peux rendre mon code source sans rien ajouter d'utile. Par exemple, le placement d'accolades, sur une nouvelle ligne, toujours - plus il y a de lignes, moins la statistique, meilleur je deviens, instantanément. Donnez-moi N'IMPORTE QUELLE mesure, et je vais vous montrer comment je peux faire cette mesure pour me faire mieux paraître.
mattnz
1
@mattnz - C'est à cela que sert la révision du code, si quelqu'un rend son code inutilement verbeux pour cacher le fait qu'il est criblé de bogues, alors il y a de fortes chances qu'ils ne devraient pas écrire du code pour commencer. Vous pouvez également examiner les défauts par point de fonction, ce qui est extrêmement difficile à simuler car vous voyez soit une exposition du nombre de fonctions avec le nombre en baisse (mauvais signe), soit le nombre commence à baisser à mesure que le code s'améliore (bon signe).
rjzii
2

Baser vos efforts sur le CMMI est probablement une bonne idée, même si vous ne subissez pas les évaluations et ne vous faites pas auditer et noter officiellement. Il existe de nombreuses publications sur le CMMI , le CMMI et d'autres techniques d'amélioration des processus telles que Lean et Six Sigma , et CMMI et le développement de logiciels agiles . Le SEI dispose d'une collection complète de ressources , certaines disponibles gratuitement, sur différents aspects du CMMI et des conseils pour différents types d'organisations.

Je recommanderais de regarder en profondeur l'approche continue de la mise en œuvre de CMMI, plutôt que l'approche par étapes. Cela me semble être un moyen beaucoup plus efficace de déterminer exactement où en est votre organisation et de s'améliorer dans les domaines qui ajoutent le plus de valeur commerciale. Cela vous permettra non seulement d'aligner vos efforts d'amélioration avec les objectifs commerciaux, mais également de réaliser rapidement des étapes de progrès et de démontrer les effets de l'amélioration, en augmentant l'adhésion à tous les niveaux.

Cependant, il faut garder à l'esprit que l'amélioration des processus est généralement plus efficace lorsqu'il s'agit d'un effort de base. Lorsque les changements de processus sont dictés par le haut - par des gens que les développeurs "dans les tranchées" peuvent considérer comme déconnectés de la façon dont les choses se font dans les tranchées - il y aura probablement un refoulement, même si l'idée est bonne. Soyez prêt pour cela.

Un certain type de groupe de processus d'ingénierie pourrait également être bénéfique. Réunir des représentants des différentes composantes organisationnelles et des équipes impactées par l'amélioration afin que la voix de chacun soit entendue. Cela comprendrait non seulement des représentants de chaque rôle, mais peut-être diverses équipes de développement de produits. Sans savoir comment votre organisation est structurée, je ne peux pas dire exactement qui vous voudrez regarder, mais inclure des personnes de tous les niveaux de l'organisation dans le groupe. De plus, mettez les discussions et les décisions prises par ce groupe à la disposition de l'organisation pour commentaires et soulèvement de tout problème.

Thomas Owens
la source
Je ne sais pas dans quelle mesure la promotion des efforts à la base va fonctionner, car très peu d'équipes de projet ont formalisé des processus, c'est pourquoi cela va être davantage un processus descendant. Cela dit, tout le monde est soucieux de rendre les choses aussi douces que possible pour éviter l'échec de l'effort en raison du manque de mise en œuvre réelle.
rjzii
@RobZ Par définition, vous ne pouvez pas pousser pour des efforts à la base - cela doit naturellement venir de bas en haut. À moins que les équipes de projet ne réalisent qu'il y a un vrai problème, la tendance est de ne pas changer et de s'opposer aux changements qui sont perçus comme mauvais d'une manière ou d'une autre (comme rendre le travail plus compliqué ou difficile, ce qui est souvent associé à l'amélioration des processus, bien qu'il ne soit pas ce n'est pas souvent le cas).
Thomas Owens
Exactement et c'est pourquoi la direction formalise les choses. Il y a eu des problèmes avec certains logiciels qui sont sortis et ils cherchent également à changer la culture de l'entreprise tout en s'assurant que les mauvais produits ne réapparaissent pas sur le terrain.
rjzii
@RobZ Et lorsque la direction intervient et dicte des actions, les développeurs résistent. Vous ne pouvez pas imposer un changement culturel et vous attendre à ce qu'il se produise simplement et tranquillement. C'est un processus long et douloureux.
Thomas Owens
Personne ne s'attend vraiment à ce que ce soit le cas et nous avons déjà rencontré de la résistance, à ce stade, nous recherchons des moyens de la minimiser.
rjzii
0

Pour chaque changement:

  • Appelez le 1 changement et comment il améliorera le développement.
  • Implémentez le changement.
  • Démontrer l'amélioration
  • Supprimer les modifications qui n'ont pas démontré d'amélioration

De toute évidence, l'analyse doit se produire au fil du temps, mais aucun changement ne doit être accepté tant qu'il n'est pas démontré qu'il est efficace. C'est aussi pourquoi je n'implémenterais pas plus de 2-3 changements par cycle, sinon vous ne pouvez souvent pas mesurer s'il y a eu une amélioration ou non.

Rien ne m'irrite plus que de suivre aveuglément les meilleures pratiques sans faire l'analyse pour montrer qu'il s'agit en fait d'une meilleure pratique pour votre environnement. Une meilleure pratique qui ne démontre pas d'amélioration est au mieux du gaspillage et au pire des dommages.

Toutes les étapes de votre processus et toutes les pratiques méthodologiques doivent être analysées et s'avérer bénéfiques. Si ce n'est pas le cas, il doit être supprimé. Cette analyse doit être effectuée sur une base continue, indépendamment de l'ajout ou de la suppression d'étapes ou de pratiques.

Dietbuddha
la source