PRATIQUES D'EQUIPE

Voici un article sur l'organisation d'une équipe de développement.
Quelles sont les pratiques d'équipe? Pourquoi sont-elles mis en place?
Vous lirez les réponses ici http://manu40k.free.fr/articlePratiquesDEquipe.pdf

AGILE PROJECT MANAGEMENT WITH SCRUM, Ken Schwaber

Ce livre a été publié deux ans après Agile Software Development with Scrum (Ken Schwaber et Mark Beedle). Par rapport au premier livre, celui-ci insiste moins sur la théorie de Scrum pour donner davantage de cas d'application de la démarche.

Parmi les points que j'ai particulièrement apprécié dans ce livre, je citerai l'affirmation selon laquelle Scrum ne permet pas d'assurer qu'un projet se déroule comme prévu - par contre la démarche assure que le déroulement du projet suit une voie qui maximise la réussite.
Aussi, un des derniers chapitres donne des pistes pour appliquer Scrum sur des projets qui dépassent le cadre idéal de 7+/-2 développeurs dans l'Equipe. L'auteur présente comment monter en charge et comment gérer un grand projet.

PEOPLEWARE, Tom DeMarco & Timothy Lister

Si j'étais responsable de mon entreprise, j'offrirais ce livre aux managers et aux équipes. Je leur conseillerais avec insistance de le lire.
Certes, je n'ai pas l'impression d'avoir beaucoup appris, mais sa lecture m'as fait du bien pour deux raisons:

• le livre est drôle, ce qui est rare pour un ouvrage concernant le développement logiciel, et
• le livre met des mots clairs sur des impressions issues de mon expérience.

Le passage sur les bureaux, l'aménagement des locaux et la police du mobilier m'a bien fait rire d'autant plus que notre projet est actuellement en cours de déménagement. En effet, il existe des gens qui décident de l'organisation des locaux et de leur occupation alors qu'il n'ont aucune idée de la manière dont les gens travaillent!

Voici une petite sélection de vérités bonnes à retenir:

• Les projets de développement échouent très rarement pour des raisons techniques;
• Les principaux problèmes affectant les projets de développement sont d'ordre sociologique et non technique;
• Les managers promus managers savent comment le travail est fait - pas comment il faut le gérer;
• Plus le projet est risqué et plus il faut prendre le temps de réfléchir à la manière dont on travaille;
• Les gens "pressurisés" ne travaillent pas mieux - juste plus vite;
• Viser un très haut niveau de qualité est un moyen pour gagner en productivité;
• Les managers ne doivent pas faire travailler leurs équipes. Ils doivent permettre à leurs équipes de travailler;
• N'importe quoi peut être mesuré d'une manière plus bénéfique que ne pas mesurer (Gilb's Law);
• Pour réussir un projet, il faut prendre des gens compétents et motivés et adopter un style de management délégatif;
• Plus un processus est déterministe et moins il est adaptatif;
• Un standard doit être consigné à postériori, c'est à dire après avoir fait ses preuves;
• Le management par les objectifs individuels est destructeur pour l'efficacité des équipes (cf Deming);

AGILE TOUR 2008 A VALENCE

L'Agile Tour est une conférence itinérante portant sur le développement Agile (Lean / Scrum / eXtreme-Programming).


Nous organisons une étape de l'Agile Tour fera à Valence le Jeudi 23 Octobre 2008 à l'ESISAR de 14h à 18h. Les conférences sont gratuites et seront suivies par un apéritif.

• L'inscription (gratuite) est obligatoire pour faciliter l'organisation de l'évènement. Il suffit de s'inscrire là: http://www.agiletour.com/inscription.html

• Si vous souhaitez proposer un sujet de conférence, vous pouvez le soumettre là: http://www.agiletour.com/devenir_orateur_agile.html

• Pour plus d'informations sur l'évènement, allez ici : http://www.agiletour.com

Venez nombreux!

LE PETIT SCRUM ILLUSTRE

Mon petit article SCRUM illustré parait dans le numéro 100 du mensuel [Pro]grammez.
Vous pouvez lire l'article d'origine ici.

AGILITE ET CMMi

Peut-on concilier Agilité et CMMi? Est-ce schizophrène? Voici un petit article sur le sujet.

LEAN SOFTWARE STRATEGIES, Peter Middleton et James Sutton

J'ai honte, mais je n'ai pas réussi à finir ce livre ... Cela m'arrive très rarement.
Ce n'est pas les 400 et quelques pages qui ont eu raison de moi, mais le style et la manière de traiter le sujet.

A mon goût, le style manque de fluidité et de simplicité. C'est peut-être un objectif ambitieux pour un livre sur le développement logiciel, mais certains auteurs y arrivent très bien - comme Martin Fowler, Kent Beck, Andy Hunt ou Mary Poppendieck.

Enfin, j'ai trouvé la démarche trop théorique et analytique. Il manquait le pragmatisme pourtant si cher aux américains.

Néanmoins, j'ai appris plusieurs choses très utiles:

• Le livre décrit très clairement les 5 piliers du Lean (value, value stream, flow, pull & perfection);
• Les caractéristiques des modèles industriels de l'artisanat, de la production de masse et du Lean sont décrites et comparées.
  
• La démarche d'amélioration continue du CMMi est comparée à celle du Lean. Cette partie m'a beaucoup intéressé car elle a mis des mots sur des choses que je ressentais (suite à un audit CMMi), mais que je n'arrivais pas à formaliser. J'écrirai un billet sur cette comparaison.
  

Bref, si vous souhaitez lire sur la transposition du Lean au développement logiciel, je vous conseille plutôt les 2 très bons livres de Tom et Mary Poppendieck:

• Lean Software Development, et
  

• Implementing Lean Software Development