Comment créer un «culte de la qualité» [clôturé]

DeMarco et Lister (Peopleware) vous suggèrent de créer un "culte de la qualité" au sein de votre équipe de programmation. Frustrant, ils ne suggèrent pas comment vous y prendre!

Quelqu'un a-t-il des idées sur la façon d'accomplir cela?

D'après mon expérience, les équipes de développement (mais en général, n'importe quelle équipe) sont composées de 3 types de personnes:

• ceux avec un lecteur intégré pour la qualité,
• ceux qui ne sont là que pour l'argent (bière / filles / quoi que ce soit) et ne s'en soucient pas, mais vous essayez de les motiver,
• les "médiocres" (faute d'un meilleur mot).

Le dernier groupe est le plus important et ils ont tendance à suivre le parti au pouvoir. S'il y a suffisamment de personnes de qualité dans l'équipe, elles peuvent tirer la majorité avec elles-mêmes, créant une forte spirale ascendante dans l'esprit d'équipe et la motivation. Cependant, s'il y a trop de slackers, ils peuvent facilement créer l'effet inverse, une spirale de mort.

Ainsi, la tâche principale du gestionnaire est de choisir et de garder les bonnes personnes et de se débarrasser des mauvaises dès que possible . Pas les «médiocres» cependant - ils peuvent être incités à commencer à s'améliorer, à soutenir les bonnes idées des autres, et certains d'entre eux pourraient même devenir des instigateurs positifs de leur propre chef.

[Update2] réfléchissant à la réponse d'Alb : OMI, il n'est pas nécessaire que les développeurs de qualité soient clairement en majorité au sein de l'équipe (bien que cela ne fasse pas de mal :-). Il existe un «seuil d'établissement des tendances» , au-dessus duquel les opinions et le comportement d'un sous-groupe peuvent rapidement devenir le «courant dominant» au sein d'une communauté , de sorte que d'autres personnes en prennent note et commencent à suivre. Vous pouvez voir cela dans le travail dans la société en général tout le temps (par exemple, les habitudes (non) de fumer, la santé et les régimes, les modes, les aliments biologiques). Mon estimation très approximative est qu'elle peut se situer entre 25 et 30%, mais cela dépend de nombreux facteurs. C'est là que les mauvaises personnes peuvent faire beaucoup de mal. Même quelques mauvaises personnes au sein de votre équipe peuvent augmenter ce seuil de manière significative. [/ Update2]

Bien sûr, il n'est pas toujours possible d'embaucher suffisamment de meilleurs gars. Ainsi, lorsque la première faction n'est pas assez forte pour conduire les choses par elle-même, la direction doit les aider. Quelques réflexions à ce sujet:

• Je pense que Scrum a une bonne idée pour cela avec des démos de produits. Démontrer la fonctionnalité que vous avez implémentée devant un public composé non seulement de vos coéquipiers, mais peut-être de développeurs d'autres équipes, de la direction, même des utilisateurs de l'application, peut être une énorme source de fierté et également un facteur important pour aider l'équipe à se marier.

• Une autre chose est que la direction écoute attentivement l'équipe de développement concernant la qualité. DeMarco et Lister mentionnent même qu'il existe des entreprises / départements où les équipes de développement ont un droit de veto sur ce qui peut aller à la production. S'ils estiment que l'application n'est pas encore prête pour les heures de grande écoute, ils peuvent reporter la sortie indépendamment de ce que la direction souhaiterait. Maintenant, c'est difficile pour la direction, mais je peux imaginer que cela renforce l'esprit d'équipe et communique fortement le message que la qualité est vraiment importante ici, pas seulement au niveau des mots.

• Cela nous amène au point suivant: pour créer un "culte de la qualité", la direction doit bien comprendre ce que les développeurs les plus expérimentés savent déjà: cette qualité n'est pas une réflexion après coup - elle doit être intégrée au produit dès le départ. Les gens devraient donc être encouragés à (et récompensés!) À penser à la maintenabilité à long terme, à rechercher les bonnes solutions, plutôt que les solutions rapides .

Mise à jour

@Machado dans son commentaire a donné une nouvelle tournure à la question (pour moi au moins):

Que puis-je faire en tant que membre de l'équipe et non en tant que manager pour améliorer la qualité du code de mon équipe?

Quelques réflexions:

• Continuez à apprendre et à diffuser les connaissances à tous ceux qui écoutent. Apprenez et utilisez les meilleures pratiques dans vos domaines d'expertise.
• Soyez fier de votre travail .
• Ces deux vous permettront presque naturellement de devenir un modèle positif pour les autres - en particulier les nouveaux arrivants et les juniors -; soyez conscient de cela et tirez parti de votre rôle au profit de toute l'équipe. La meilleure façon d'influencer les autres est par l'exemple positif.
• Regardez non seulement le code, mais l'ensemble du processus de développement de logiciels; continuez à poser des questions et à fournir des commentaires pour optimiser le processus de développement .

Et enfin et surtout: trouvez un endroit où vous pouvez être un "top guy" . Si vous êtes dans le groupe "médiocre" en ce moment, efforcez-vous de vous développer - j'espère que les idées ci-dessus vous y aideront. Mais s'il vous arrive d'être dans les "couches inférieures" de votre équipe actuelle, je vous recommande d'analyser les raisons. Qu'est-ce qui vous démotive? Mauvaises conditions de travail? Coéquipiers? La gestion? Type de travail? Et qu'est-ce qui vous excite et vous intéresse? Vous devrez peut-être en parler à vos collègues et / ou à votre patron. Ou vous devrez peut-être chercher un meilleur emploi - ou même une nouvelle profession - où vous pourrez commencer à briller. Cela ne vaut vraiment pas la peine de consacrer une partie importante de sa vie à une activité insatisfaisante ou déprimante.

Il se peut également que vous soyez obligé de continuer votre travail actuel sous-optimal en raison de facteurs externes (manque de meilleures opportunités d'emploi, besoin de payer les factures, etc.) - cela se produit de temps en temps. Même dans ce cas, essayez d'en tirer le meilleur parti. Produire un travail de qualité (autant que les circonstances le permettent) est une récompense en soi, qui aide à maintenir l'estime de soi et à rester sain et ouvert à long terme. Ainsi, lorsqu'une opportunité pour quelque chose de mieux apparaît, vous êtes mieux préparé à la saisir.

Excellente réponse de Péter Török pour souligner que vous ne pourrez gérer cela qu'avec une majorité de bonnes personnes. Une fois que vous avez de bonnes personnes, vous devez viser davantage l'approche carotte plutôt que le bâton. Autonomisez les développeurs, laissez-les s'approprier les projets / tâches et encouragez la concurrence en termes de qualité, demandez peut-être aux gens de faire de courtes présentations sur la façon dont ils ont amélioré la qualité des projets. Les bons développeurs seront motivés pour impressionner leurs pairs.

En plus des commentaires de Peter (qui sont vraiment le problème principal), vous devez vous assurer que la qualité n'est pas une fonctionnalité ajoutée ultérieurement.

Plus précisement:

• Supprimez toute trace de la pensée «Nous le nettoyerons plus tard». Au lieu de cela, faites l'effort au début pour le faire correctement.
• Exiger que les modifications soient examinées et traitées par une sorte de processus d'assurance qualité impliquant une personne autre que le développeur.
• Forcer la réflexion sur la qualité dans les premières phases des projets. Gardez les choses comme «la facilité avec laquelle cela peut être maintenu par les autres» au cours du développement.
• Suivez et signalez les bogues qui se produisent. S'il existe des tendances, cherchez des moyens de lutter contre la cause première des bogues.
• Présentez la pensée du logiciel comme un métier qui peut être amélioré et dont les créateurs peuvent être fiers.

Je dirais que la meilleure façon est d'encourager la qualité par rapport à la sortie. C'est l'un des prémisses du mouvement Lean Software (basé sur le Lean Manufacturing). J'ai écrit un long article sur ce blog Lean . Je vous dis comment créer un culte de la qualité. Investissez dans vos employés et laissez-les investir dans votre entreprise (pas d'investissement monétaire, mais plutôt un investissement personnel).

Dan Pink a fait un excellent exposé à TED sur ce qui nous motive. Bien qu'il ne s'y réfère pas spécifiquement. La hiérarchie des besoins de Maslow explique parfaitement le phénomène observé. Tant que l'employeur répond aux deux premiers besoins (c.-à-d. Payer suffisamment d'argent pour que l'argent ne soit pas un problème), il ne reste que l'appartenance, l'estime de soi et l'actualisation de soi.

• Fournir une communauté solide d'appartenance.
• Offrez un environnement dans lequel l'employé se sent libre de faire des erreurs afin qu'il puisse se forger une estime lorsqu'il accomplit ses réalisations.
• Donnez à vos développeurs les rênes afin qu'ils puissent prendre les décisions importantes pour l'auto-actualisation

La qualité n'est pas quelque chose qui peut être dicté ... elle est plutôt activée. Faites confiance à vos employés pour faire ce qui est le mieux et sortir du chemin. Finalement, vous devrez leur dire qu'ils doivent partir. Plutôt que de leur demander de consacrer plus d'heures