Laws for Software Development Teams


Facebooktwitterredditpinterestlinkedinmail

Sorry, this entry is only available in Français.

Un certain nombre de lois s’appliquent au développement logiciel. Il est important d’en avoir conscience pour éviter de tomber dans les pièges connus.

Allan Kelly a publié un article très intéressant en listant et expliquant un certain nombre de lois connues ou non qui s’appliquent aux équipes de développement logiciel.

Voici la liste des lois mentionnées. Retrouvez leur explication dans l’article d’Allan Kelly sur methodsandtools.com.

Je termine l’article par ma propre contribution.

Brooks’ Law

“Adding manpower to a late software project makes it later.” (Brooks 1975)

Conway’s Law

“Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations” (Conway 1968)

Dunbar’s number: Natural breakpoints

“Extrapolating from the relationship for monkeys and apes gives a group size of about 150 – the limit on the number of social relationships that humans can have, a figured now graced with the title Dunbar’s Number.” (Dunbar 2010)

Parkinson’s Law and Hofstadter’s Law

“Work expands so as to fill the time available for its completion” (Parkinson’s Law, Wikipedia)

“It always takes longer than you expect, even when you take into account Hofstadter’s Law.” (Hofstadter 1980)

Gall’s Law

“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.” (Gall 1986) via Wikipedia

Allan ajoute ensuite ses propres lois :

Kelly’s First Law of software: Software scope will always increase in proportion to resources

Kelly’s Second Law of software: Inside every large development effort there is a small one struggling to get out

Ce qui me donne envie de rajouter ma propre contribution :

On ne prend conscience de la qualité que lorsqu’on la perd.

Ce n’est que lorsqu’on arrive dans un nouvel environnement que l’on prend conscience de la qualité qui était présente dans l’environnement précédent.

Ainsi chacun est invité à partager les bonnes pratiques rencontrées ailleurs afin d’en faire bénéficier la communauté locale.

Facebooktwitterredditpinterestlinkedinmail

About elan

Après plusieurs années en développement embarqué et expertise en Télévision Numérique, j'ai migré vers les méthodes et outils. Ce qui m'anime : rendre les projets efficace ! L'Agilité y répond parfaitement.

Leave a comment

Your email address will not be published. Required fields are marked *