Introduction
Cet article contient un court résumé des idées principales de chaque paragraphe du livre Creating A Software Engineering Culture de l'auteur Karl E. Wiegers ainsi que des notes personnels, des références et des tableaux qui m'ont semblés utiles.
Creating A Software Engineering Culture
Chapter 2 Standing On Principle
Parfois, on peut vous demander de ne pas faire de l'ingénierie de qualité ou même vous intimer à délaisser les bonnes pratiques qui pourraient donner une qualité supérieure à votre logiciel.
Toutefois, un bon conseil est de: "ne jamais laisser votre patron ou votre client vous dire de faire un mauvais travail" (travail baclé).
Intégrité et Intelligence: Avec le client
Il ne faut pas faire du zèle et obéir aveuglément à toutes les demandes du client. C'est le travail de l'analyse système de trouver des solutions intelligentes qui répondent aux besoins réels du client avec créativité, efficacité et bon-sens.
Il faut regarder pour une solution (simple et peu coûteuse) qui répond aux besoins premiers du client et non pas à la demande du client.
Les développeurs dans une culture saine d'ingénierie logiciel sont prêts à prendre des détours calculés pour arriver à combler les besoins du client le mieux possible. Ainsi, même si le client demande tout de suite (ou hier) des changements importants, il peut être mieux d'offrir un produit temporaire ou évolutif que de livrer un produit trop complexe ou trop différent des versions antérieures.
Le client peut avoir une vision tunnel, c'est-à-dire qu'il veut une solution qui répond seulement à ces besoins précis. Toutefois, avec un peu de recul, un analyste peut constater que le problème du client peut être généralisé et qu'une solution plus globale permet de satisfaire les besoins de plus de personnes et profite à la compagnie.
Préféré la réutilisabilité intelligente à la pression du client ou du gestionnaire.
Connaître l'étendu de l'expertise du client dans le domaine du logiciel. Le client ne doit pas obliger le développeur à prendre des décisions de conception pauvres.
Une relation de confiance entre les développeurs et les clients implique un respect des compétences de chacun et un contact constant pour indiquer les changements majeurs et leurs impacts, les délais et les coûts. Chaque parti doit être informé clairement et demeurer en tout temps honnête.
Integrité et Intelligence: avec les gestionnaires
Répondre au gestionnaire ce qu'il veut entendre (un estimé de la durée d'un projet par exemple) n'est pas profesionnel. Pour s'entendre avec le gestionnaire sur la durée d'un projet on peut:
- Expliquer la méthode d'estimation utilisée. Se baser sur des anciennes mesures ou sur des anciens cas.
- S'il y a trop peu de renseignement pour permettre de donner une estimé convenable, demander au gestionnaire d'explorer quelques avenues du projet
- Fournir trois estimés: meilleur cas, cas propable, pire cas.
Ne pas fournir un plan est aussi irresponsable que de ne pas finir à temps. (être en accord avec les dates de livraison).
Les 5 dimensions d'un projet logiciel
- Qualité
- Coût
- Planification (calendrier)
- Personnel (ressource humaine)
- Fonctionnalité
Chaques rôles ne sont pas indépendants et peuvent joués trois rôles: fil conducteur, contrainte, degré de liberté. Ils sont liés les uns aux autres.
Le fil conducteur est l'objectif principal (objectif clé) du projet.
Une contrainte est un facteur qui limite le projet et qui ne peut pas être contrôlé par le chef d'équipe.
Une dimension qui n'est pas un fil conducteur ou une contrainte est un "degré de liberé" (degree of freedom)
Il est important de définir avec le client dès le début du processus les rôles de chacunes des dimensions pour partir du bon pied.
Chapter 3: Recognizing Achievements Great and Small
Chapter 11: The Quality Culture
Il ne faut pas utiliser le terme "bugs" car il fait penser que ces "bugs" apparaissent ou émergent miraculeusement tout seul du logiciel. Ce n'est pas le cas, les "fautes", les erreurs et les échecs proviennent des développeurs du logiciel. Comme on dit, nul (humain) n'est parfait.
Il est biens de faire la différence entre "fautes" et "échecs". Un échec est un mauvais fonctionnement du système (un logiciel de correction orthographique oublie des mots). Une faute est un problème dans le code, dans les spécifications, dans la documentation, etc (une boucle infinie, une spécification imprécise, une documentation expirée, non à jour).
L'usager tient très peu en compte le nombre d'erreur dans le code. Il regarde surtout le nombre d'échec du logiciel (mauvaise fonction, fonction absente, usabilité faible, difficile à apprendre, documentation fastidieuse, ...)
Dans la culture de l'ingénierie logiciel, les développeurs veulent trouver les erreurs par eux-mêmes ou par leurs pairs.
Un ingénieur sérieux devrait prendre note:
- du lieu d'origine de la faute;
- de la raison pour laquelle la faute n'a pas été trouvée plus tôt;
- de ce qu'il peut faire pour éviter de faire une erreur semblable;
- comment il pourrait trouver ce type d'erreur plus efficacement;
- des endroits à regarder pour trouver le même type d'erreurs dans le logiciel.
La qualité logiciel dépend:
- de l'attitude individuel des ingénieurs logiciels et des gestionnaires;
- du processus pour prévenir les erreur durant le développement;
- des moyens utilisés pour détecter et corriger les erreurs et les fautes.
PART VI What to Do on Monday
On ne peut pas changer une culture du jour au lendemain. L'amélioration se fait dans tous les domaines : relation humaine, image de soi, technique de gestion, assurance qualité, standardisation, protocole. Il faut commencer par le plus important ou celui où on peut voir une amélioration rapidement.
Chapter 19 Action Planning for Software Managers
N'essayer jamais de manger un éléphant en une bouchée... et n'essayer jamais d'accomplir toutes vos idées d'amélioration en même temps.
Identifier les critères de changements:
- Quels sont les bénéfices attendues?
- Comment puis-je les mettre "réellement" en pratique%
- Combien d'efforts sont requis pour les accomplir?
- Qui peut m'encourager à poursuivre mon but?
- Qu'est ce qui peut arriver de pire si je ne réussis pas?
Le chef d'équipe joue un rôle déterminant pour améliorer la façon dont travail l'équipe. Il faut combattre l'inertie ( par le feu ? )
Priorités: Examiner la gestion, Prioriser la Qualité, Reviser, Planifier, Mesurer, Éduquer, Récompenser, S'Informer, Bien paraître, Évaluer l'environnement.