Les activités de base de Six Sigma sont capturées par l'acronyme DMAIC , qui signifie: Définir, Mesurer, Analyser, Améliorer, Contrôler . Vous les appliquez au processus que vous souhaitez améliorer: définissez le processus, mesurez-le, utilisez les mesures pour formuler des hypothèses sur les causes des problèmes, implémentez des améliorations et assurez-vous que le processus reste statistiquement "sous contrôle".
En ce qui concerne les logiciels, le processus est votre cycle de vie de développement logiciel (SDLC) ou une partie de celui-ci. Vous n'essaieriez probablement pas d'appliquer les principes Six Sigma à l'ensemble du SDLC (ou du moins, pas au départ). Au lieu de cela, vous recherchez des domaines où vous pensez avoir un problème (par exemple, notre taux de défauts est trop élevé; trop de régressions; notre calendrier glisse trop souvent; trop de malentendus entre les développeurs et le client; etc.). Disons pour l'instant que le problème est que trop de bugs sont produits (ou du moins signalés) chaque semaine. Vous définiriez donc le processus de développement logiciel / création de bogues. Ensuite, vous commenceriez à collecter des mesures telles que le nombre de lignes de code écrites chaque jour, la fréquence des modifications des exigences, le nombre d'heures que chaque ingénieur passe en réunion,
Ensuite, vous regardez les données et essayez de discerner les modèles. Peut-être que vous remarquez que l'équipe d'ingénierie A atteint chaque échéance qui leur est impartie et termine même souvent les tâches plus tôt! Initialement, l'équipe B ne semble pas tout à fait ainsi sur le ballon - ils manquent leurs délais d'un jour ou deux au moins la moitié du temps, et sont parfois en retard d'une semaine ou plus. La direction voit l'équipe B comme un problème et cherche à faire bouger les choses. Cependant, un examen plus approfondi des données montre que le taux de bogues de l'équipe B est beaucoup plus faible que celui de l'équipe A, et de plus, il est souvent demandé à l'équipe B de corriger les bogues attribuables à l'équipe A parce que la direction estime que l'équipe A est précieuse pour dépenser beaucoup. de temps sur la maintenance.
Donc que fais-tu? En utilisant les données que vous avez collectées et l'analyse que vous avez effectuée, vous proposez un changement: l'équipe A et l'équipe B corrigeront chacune leurs propres bugs. Avec la bénédiction de la direction (et contre l'opposition véhémente de l'équipe A), vous mettez en œuvre ce changement. Ensuite, vous continuez à collecter des mesures et vous continuez d'analyser les données pour voir si votre modification a fait une différence. Répétez ce cycle de mesure / analyse / mise en œuvre jusqu'à ce que le taux de bogues soit jugé acceptable. Mais vous n'avez pas encore fini. En fait, vous n'avez jamais fini ... vous devez continuer à mesurer le taux de bogues et vérifier que le taux de bogues reste dans la plage acceptable, c'est-à-dire qu'il est statistiquement "sous contrôle".
Notez qu'il n'y a rien ici qui soit spécifique au développement de logiciels autres que les détails du processus que vous améliorez, les types de mesures que vous collectez, etc. Les activités que vous utilisez pour améliorer un processus de développement de logiciels sont les mêmes que celles que vous '' d utiliser pour un processus de fabrication de widgets, même si le développement de logiciels est très différent de la fabrication de widgets. Tout cela signifie que vous devez appliquer un certain bon sens dans les types d'objectifs que vous définissez pour votre processus.