avr
14
Dan Leffingwell propose huit principes pour le développement et la maintenance d’une architecture d’entreprise dans une organisation lean et agile :
1. L’équipe qui programme doit aussi concevoir le système
2. Construisez l’architecture la plus simple qui puisse fonctionner
3. Lorsque vous doutez, programmez ou modélisez
4. Ceux qui construisent exécutent les tests
5. Plus le système est grand, plus longue est la piste d’envol
6. L’architecture système est un rôle collaboratif
7. Il n’y a pas de monopole sur l’innovation
8. Implémentez la fluidité architecturale
Source : « Agile Software Requirements », Dean Leffingwell, Addison-Wesley, 489 pages, IBSN 978-0-321-63584-6
déc
14
« Définie de manière simple et intuitive, la gestion de projet est un ensemble d’outils, de référentiels et de processus destiné à répondre aux six questions suivantes : Read more
août
30
Mike Cohn propose neuf questions pour une bonne équipe de projet Scrum
Filed Under Citations | Leave a Comment
Dans son livre « Succeeding with Agile », Mike Cohn présente neuf questions que vous devriez vous poser pour former l’équipe d’un projet existant ou futur. ces questions devraient être posées de manière itérative… jusqu’à obtenir une réponse positive pour chacune d’entre elles. Read more
fév
9
Je suis en train de lire le livre « Scaling Lean & Agile Development – Thinking and Organizational Tools for Large-Scale Scrum » de Craig Larman et Bas Vodde. C’est un livre très intéressant et riche qui m’a captivé dès les premières pages. Je ne peux résister à vous soumettre trois perles glanées au début de ce livre et qui devraient pouvoir stimuler les discussions de vos prochaines réunions de planification de projet.
« Après avoir travaillé pendant des années dans le domaine des projets de développement importants, distribués et offshore, nous avons résumé notre opinion et expérience en une seule phrase : n’en faites pas. »
« Nous conseillons régulièrement des groupes qui nous demandent: « Comment calculer le nombre de personnes nécessaires pour un projet de développement? » Notre suggestion est : « commencez par un petit groupe d’excellents développeurs et n’augmentez la quantité que lorsque cela commence à vraiment faire mal. » Cette situation arrive rarement.
La dernière citation est reprise du livre The Fifth Discipline : « Diviser un éléphant en deux ne produit pas deux petits éléphants. »
Sources :
« Scaling Lean & Agile Development – Thinking and Organizational Tools for Large-Scale Scrum », Craig Larman & Bas Vodde, Addison -Wesley
« The Fifth Discipline », Peter Senge, DoubleDay Business
oct
16
Question de méthode
Filed Under Citations | Leave a Comment
« Les gens sont terrorisés à l’idée d’échouer avec une méthode qu’ils ne connaissent pas mais sont rassurés par échouer avec une méthode qu’ils connaissent bien »
Ken Schwaber
Conversation citée sur le blog d’Alexandre Boutin
avr
30
Les trois règles du Test Driven Development
Filed Under Citations | Commentaires fermés
Au cours des ans, j’ai été amené à décrire le Test Driven Development en utilisant trois règles simples :
1. Vous ne devez écrire du code de production que pour faire réussir un test qui échoue.
2. Vous ne devez écrire que le test unitaire que nécessaire pour échouer; les problèmes de compilation sont aussi considérés des échecs.
3. Vous ne devez écrire que code de production nécessaire pour faire réussir un test unitaire qui échoue. Read more
jan
15
Développement agile du logiciel : il faut garder la tête froide
Filed Under Citations | Leave a Comment
J’ai été étonné par le niveau de dogmatisme, bigoterie, mépris ou simplement d’ignorance dont j’ai été le témoin dans le monde agile. Je ne blâme pas les agilistes les plus réputés, même si parfois par leurs écrits et leurs présentations, ils réduisent leurs messages à l’essentiel, au niveau du slogan, et qu’ils omettent le contexte – aussi bien au niveau de la source que de la mise en oeuvre.
Au moment où l’agilité augmente son taux d’adoption – ce que vous pouvez constater si vous assistez à de grandes conférences dédiées au développement informatique comme SD East et West ou OOPSLA (Object-Oriented Programming, Systems, Languages, and Applications) – de plus en plus de personnes disent (ou répètent) des messages incompris avec une forte conviction et peu d’expérience, raillant tous ceux qui osent questionner leurs déclarations, même s’il s’agit juste de demander une clarification sur l’étendue d’un projet ou de son contexte.
En écrivant ces mots, je devrais être exécuté comme traître à la cause agile, défenseur de l’église du cycle de vie en cascade, un dinosaure, un super-obtus, bien que j’apprécie l’agilité ou les pratiques agiles dans un contexte favorable et à travers le filtre de mes 33 ans d’expérience. Mais j’aimerais que mes amis et collègues gardent la tête froide, questionnent les hypothèses, n’assument pas trop l’existence d’un modèle mental partagé unique et remettent dans son contexte ce qu’ils entendent, lisent, disent ou écrivent.
Source : Philippe Kruchten, Voyage in the Agile Memeplex (en anglais)
Philippe Kruchten nous transmet une expérience précieuse. Il faut répéter qu’il n’a pas de solution miracle dans le développement informatique. De nombreuses approches échouent si leurs valeurs fondamentales ne sont pas comprises, mais qu’au contraire on se trouve en présence de personnes qui veulent ppliquer des recettes de cuisine sans intelligence ni bon sens. Chaque nouvelle approche compte un nombre de fondamentalistes qui tentent de la mettre en oeuvre à la manière de préceptes religieux stricts. Je crois fortement que le succès des projets de développement informatique dépend plus de l’adaptation pragmatique d’outils et de pratiques à une situation spécifique que le contraire