Comment puis-je appliquer Six Sigma dans un environnement de développement logiciel?
Je suis un développeur Java, mais on m'a demandé d'apprendre à appliquer Six Sigma dans le but d'augmenter les bénéfices de notre organisation. J'ai lu que Six Sigma peut être appliqué dans tous les environnements, mais je ' m intéressé par les nuances de son application au développement de logiciels.
Quels concepts de Six Sigma peuvent être appliqués à un environnement de développement logiciel et comment puis-je les appliquer efficacement?
Ma compréhension est que Six Sigma se concentre sur:
- identifier et éliminer les causes profondes des défauts
- minimiser la variabilité dans l'application des processus de fabrication ou d'affaires
Il me semble que ces concepts pourraient être appliqués au développement de logiciels, mais cela peut-il être appliqué efficacement à un cycle de vie de développement logiciel (SDLC)?
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 initialement). 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 changements d'exigences, le nombre d'heures que chaque ingénieur passe en réunions et d'autres faits éventuellement pertinents.
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! Au départ, 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, car 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 terminé ... vous devez continuer à mesurer le taux de bogues et vérifier que le taux de bogues reste dans la plage acceptable, c'est-à-dire c'est statistiquement "en 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 logiciel 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.