Nous sommes convaincus qu'un logiciel pensé pour être utile doit aussi être un produit fiable et bien construit, conçu pour absorber le changement continuellement, pour être livré à volonté en toute sérénité, pour durer sans douleur tant qu'il rencontre sa cible.
Le changement n'est pas un état, mais une dynamique. Libérez les potentiels humains et les savoir-faire pour laisser place à l'innovation. Adoptez l'état d'esprit et la culture qui s'accordent avec vos objectifs. Incarnez et soyez le changement que vous souhaitez voir naître. Recherchez l'excellence ingénierique pour soutenir le changement et bâtir du concret et sur la durée.
On oublie parfois qu'on livre comme on produit, et pas seulement ce qu'on produit. Tirez profit des outils en faisant émerger collectivement des méthodes de travail simples et efficaces, proportionnées à l'objectif visé. Structurez vos processus en fonction de vos méthodes, et non de vos outils qui doivent demeurer un moyen, une commodité. Toute livraison devrait être un acte anecdotique, un non-événement, dénué de toute charge émotionnelle.
Chaque candidature est une rencontre. Offrez la meilleure expérience à vos candidats, comme à vos recrues. Recrutez pour apprendre et muter, et non pour répéter et reproduire. Appliquez l'amélioration continue à votre démarche de recrutement de bout en bout. Et tendez à faire de tout un chacun un ambassadeur de votre organisation.
La variété des formes de test constitue un vaste arsenal, à la fois puissant et complexe à manipuler. Apprenez à le rationnaliser afin d'acquérir de nouvelles capacités : livrez sans surcoût, livrez n'importe quand, livrez en toute confiance. Mettez les tests à votre service plutôt que d'être au leur.
Étendez le terrain de jeu de vos tests de manière à engendrer une organisation apprenante et des processus générateurs de valeur. Optez pour des tests utiles et intelligemment organisés, entre machine et humain, en adéquation avec leurs forces respectives. Optimisez l'effort consenti à l'automatisation des tests pour en tirer le meilleur retour sur investissement dans votre contexte.
Accordez le même soin à votre code de test qu'à votre code de production, et traitez vos tests comme des composants de première classe. Les tests ont la faculté de documenter aussi bien le comportement d'un logiciel que sa dette, de quelque nature qu'elle soit. Structurez, scénarisez, spécifiez ou improvisez. Si le code ne ment pas, les tests disent la vérité - même leur absence. En prenant soin de vos tests, vous prenez soin de vos utilisateurs et clients : faites de vos tests des VIP et rejoignez le mouvement Clean Test®.
Alignez vos méthodes d'ingénierie logicielle et votre gouvernance, en adoptant de concert découvertes et apprentissages rapides avec Test-Driven Development (TDD) et Behavior-Driven Development (BDD).
Soyez fiers de vos accomplissements, en créant des conceptions qui reflètent vos talents. Pensez la qualité comme intrinsèque à vos produits, et construisez-la au quotidien dans le code pour qu'il porte l'identité et les valeurs de votre organisation. Faîtes de votre code source un élément à part entière de votre culture portée par des actes.
Faîtes l'économie de l'inutile et réduisez vos logiciels à l'essentiel, à la valeur que vous en attendez. Trouvez les armes pour vous préserver du chaos logiciel et usez-en à bon escient pour dompter l'entropie logicielle.
La conception logicielle ne se limite pas à prendre des décisions. C'est aussi savoir écouter l'impérieuse nécessité de changer la structure du code quand survient le besoin auquel répondre.
Tendre vers la meilleure décision de conception, c'est trouver les moyens d'attendre le plus longtemps possible avant qu'il ne soit trop tard.
En Informatique, toute chose temporaire devient définitive à l'instant même où elle existe. C'est encore plus vrai dans le code source.
Tout élément structurant de conception est associé à la fois à un gain et à un coût : le gain doit être supérieur au coût dans le temps. Sinon il faut y renoncer au plus tôt.
C'est dans le code source qu'émergent des conceptions d'excellence. Car elles naissent de la confrontation de préoccupations contraires. Ce sont les fruits d’accidents calculés.
Privilégier un couplage lâche et une cohésion forte, ce n'est pas vouloir les réunir à tout prix au même endroit. C'est faire le choix d'un couplage lâche entre deux composants à la cohésion faible, ou bien celui d'un couplage fort entre composants à la cohésion forte. Le reste n'est qu'une dette technique de plus.
Les défauts ne sont que la partie émergée d'un iceberg qui flotte avec la dette logicielle, qu'elle soit technique, organisationnelle, émotionnelle ou humaine. Et plus de dette signifie plus de défauts dans l'immédiat, et bien plus encore pour plus tard.
Une mauvaise conception ressemble à l'absence de conception : au lieu de faciliter les développements, elles les freinent, et les défauts adorent s'y nicher.
La programmation consiste à prendre en permanence de petites décisions qui auront de grands impacts. Une spécification formalise de grandes décisions qui ont de faibles impacts, sinon négatifs. En effet, la spécification, c’est le plan, alors que la programmation, c’est la planification. Une spécification a donc d’autant plus d’intérêt qu’elle se confond avec la programmation. D’où les développements pilotés par les tests.
En conception dirigée par les tests, on arrive à une conception comme on suit le chemin des tests. Si le chemin est hasardeux, la conception est une falaise. Si le chemin est astucieux, la conception est une plaine. En cela, un bon développeur est un paysagiste du code.
Qu'il s'agisse de conception ou d'anomalie, chacune a ses tests : on cueille la première, alors qu'on chasse la seconde.
Une bonne façon de ne pas se tromper de test est souvent de faire appel à deux personnes distinctes. Il en existe aussi une meilleure, sans exclusion mutuelle : concevoir le test avant le code.
Quand les tests de non-régression sont automatisés, on ne met pas les testeurs au chômage technique : on les laisse enfin exercer leur métier.
Quand les tests spécifient et documentent un logiciel, leur pendant n’est plus la spécification, mais la supervision, jusqu’à l’obsession de la mesure.
Les organisations sont des plans de culture à différents termes : on y récolte ce que l'on sème, même si les planteurs ne sont pas les cueilleurs, et leur avenir se dessine en fonction des récoltes à venir. Il faut pouvoir attendre pour récolter, et si rien n'a été planté pour une époque, tantôt proche tantôt lointaine, l'avenir en est compromis avec la même assurance.
Un centre de coût compte ses charges et réduit ses coûts. Un centre de profit bénéficie d’investissements et crée de la valeur. Il en va de même dans la façon de penser et de conduire la production de n'importe quel logiciel.
Les mêmes réflexes sont à l'œuvre qu'il faille communiquer au sein d'une organisation ou concevoir un logiciel. D'une part, les forces ou faiblesses existent en miroir. D'autre part, il faut changer de système de pensées pour espérer changer une faiblesse en une force.
Les organisations qui vivent leurs valeurs les transmettent par le geste, et non par le verbe. Les organisations qui communiquent le plus au sujet de leurs valeurs sont les mêmes qui en ont le moins. À trop parler d'une chose, on se persuade qu’elle existe, on en oublie qu'elle n'existe pas, et l'on fait de la propagande au lieu de communiquer.
N’importe quel être soucieux de son avenir prend soin de son patrimoine. Plus tôt une organisation prend conscience que sa richesse est humaine et que son patrimoine est logiciel, moins elle perdra de temps à dénigrer ses forces vives ou à incendier son code source.
La qualité des logiciels trouve son équilibre naturel entre l'expérience des utilisateurs et celle des développeurs : elles grandissent ou s'amenuisent ensemble. Et elles ne sont jamais déficitaires séparément.
Il est facile de renoncer à la valeur en se focalisant sur la quantité plutôt que la qualité, en livrant vite au lieu de livrer tôt, en livrant régulièrement beaucoup au lieu de livrer continuellement bien. Un logiciel de valeur n'est pas l'addition de ses fonctionnalités. Livrer tôt de la valeur, c'est livrer moins en réduisant le fonctionnel à l'essentiel, jamais la qualité au minimum. Beaucoup d'implémentations "agiles" sont des bévues bâtis sur cette incompréhension.
La première façon de renoncer à la valeur, et par extension aux développements agiles, c'est de ne pas extraire le minimum viable de chaque fonctionnalité. La deuxième, c'est de concevoir le code comme s'il devait l'être en une seule fois.
Si vous souhaitez emmener les gens dans un ailleurs, faites que ce soit une aventure enrichissante et vivez-la vous-même avec enthousiasme et conviction. Sinon abstenez-vous. Un changement sans enthousiasme ni conviction est un changement de direction sans le sens.
Easy Website Builder