Ingénierie Logicielle on Shigaepouyen

Hadopi, c'est 16 gus dans un hémicycle

Tue, 07 Apr 2009 10:37:22 +0000

Parce que parfois une image vaut mieux qu’un long discours :

vote hadopi sur www.jaffiche.fr

Affiche HADOPI (c) Geoffrey Dorne

Vous pouvez continuer à réagir à notre article sur ce texte.

Travaillez votre AGILE IT!

Fri, 03 Apr 2009 08:30:33 +0000

Kesako ?

Agile englobe un ensemble de méthode de gestion de projet et de conception logicielle qui se veulent plus impliquantes et plus réactives vis-à-vis du client que les méthodes traditionnelles. Le but est d’obtenir un produit focalisé sur la satisfaction du client plutôt qu’un produit focalisé sur des engagements contractuels.

Les 4 valeurs fondamentales d’agile sont l’équipe (« Personnes et interaction plutôt que processus et outils »), l ‘application (« Logiciel fonctionnel plutôt que documentation complète »), la collaboration (« Collaboration avec le client plutôt que négociation de contrat ») et l’acceptation du changement (« Réagir au changement plutôt que suivre un plan »).

La méthode la plus répendu en France est SCRUM, souvent couplée avec XP (eXtrem Programming)

Huile sur toile (c) Olivier Morin

Méthodes agiles versus méthodes classiques

Je ne vous fais pas l’affront de vous présenter le cycle en V ou en Y (2TUP). Ces méthodes sont aujourd’hui bien connues par les chef de projets, des indicateurs de ROI et de performances sont intégrés, les projets maitrisés. De plus ces dernières années nous avons vu fleurir de “nouvelles méthodes” de gestion de projet bien adaptées à ces cycles (ITIL, CMMI, COBIT, …) et qui permettent de maîtriser aussi les projets dans la durée.

Le problème est que dans ce cycle, on implique le métier et la MOA en début et en fin uniquement. Du coup, plus le projet est long, plus l’effet de tunnelisation est important. De plus les équipes sont cloisonnées : Métier <-> MOA <-> MOE ( <-> prestataires ). Du coup, le métier désigne un responsable pour dialoguer avec la MOA, qui va mettre quelqu’un en face et va à son tour désigner un responsable pour dialoguer avec la MOE, … et ainsi de suite. Autant d’interfaces qui peuvent déformer l’information, faire goulet d’étranglement, … Et si on saute une étape, on crée des tentions et des frustrations.

Agile propose au contraire d’impliquer tous les acteurs ensembles et tout au long du projet. Dans Scrum, par exemple, on découpe le projet en sprint de 1 à 4 semaines. Lors de chaque sprint MOA et MOE décident ensemble de ce qui sera développer pendant le prochain sprint. Chaque jour du sprint, le chef de projet anime un “stand up meeting” avec ses équipes et chacun décide des tâches qu’il prend à sa charge. L’information est donc sensé remonter, dans le pire des cas chaque jour en interne MOE et à chaque sprint entre MOA et MOE. C’est aussi un process fortement impliquant pour les équipes de développement. Enfin, pour des projets avec “deadline” cela garantie que c’est bien les fonctionnalités les plus importantes qui seront développées.

Le problème est que cela demande une disponibilité beaucoup plus importante des MOA, il s’agit d’un pré-requis indispensable. Si la MOA attend un développement exhaustif du périmètre les risques de dérivent sont important. Enfin on peut se retrouve à casser et refaire souvent.

AGILITE = VITESSE + CAPITALISATION : il faut continuer à documenter ses projets sinon passé quelques runs ou un renouvellement partiel de l’équipe, le projets n’est plus viable.

Pourquoi attendre?

On se rend assez vite compte que les méthodes agiles ne sont pas des méthodes miracles. Finalement, si elles sont intéressante pour des projets innovants, elles le sont assez peu pour des projets très long ou des projets en exploitation.

De plus, les freins existent : les chef de projets ne peuvent plus appliquer leurs indicateurs traditionnels, du coup la comparaison entre un projet agile et un autre n’est pas aisée, pourtant les décideurs souhaitent toujours pouvoir mesurer leur ROI (pourquoi pas avec un indicateur gain/satisfaction utilisateur?)

Enfin pour les sociétés de services doivent mettre en face de ces projets un nouveau modèle commerciale : il serait suicidaire de vendre un projet agile comme un forfait classique et leur apport est moindre si elles se contentent de fournir des ressources agiles en régie.

Cependant, crise aidant, les sociétés qui ont du cash ont tout intérêt à investir dans l’innovation maintenant pour être leader en période de reprise. Je prends le paris qu’elles seront de plus en plus demandeuses de ce type de méthodes. Dans le même temps, on devrait voir un regain d’intérêt pour le MDA qui permet de contourner le problème du “faire et refaire”.

patate

Everland (c) Martin Vidberg

La souplesse du chef de projet

Le chef de projet doit maintenant connaître différent mode de projet pour offrir le meilleur service possible à son client… Et si la vraie agilité c’était l’adaptabilité, plutôt que l’évangélisation théorique?

Do you know Joel?

Thu, 29 Jan 2009 07:34:14 +0000

Quelques mots pour vous présenter un des auteurs les plus populaires du web… J’ai découvert Joel Spolsky durant mon année d’échange à Toronto grâce au cours “d’ingénierie logicielle”. C’était, en fait, censé être notre livre de cours.

Pour la plupart des cours, c’est généralement assez chaud de lire les livres, car c’est en anglais et en plus c’est rébarbatif (c’est pareil en français avec les bouquins académiques !). Mais pas avec Joel.

Pourtant, au départ, c’est pas super engageant comme couverture :

Je ne sais pas vous, mais moi ça me donne pas envie de l’ouvrir.

Franchement, ça fait penser à un vieux grimoire avec pleins de pages écrites en tout petit.

Mais quand j’ai (enfin) trouvé le courage d’ouvrir et de commencer le livre, je l’ai dévoré ! (Surtout que c’est pas écrit en tout petit mais en taille normale :) donc en fait ça se lit très bien)

Joel, c’est un type qui a passé 10 ans de sa vie chez Microsoft, mais qui a aussi passé pas mal de temps dans d’autres boites, et aujourd’hui il a monté la sienne. Dans toutes ses expériences, il a vu des trucs bien, et d’autres beaucoup moins bien. Et là, dans ce livre, il vous offre un condensé des “Do’s et Don’t’s” pour livrer des belles applications informatiques à temps.

Grâce à ses astuces, vous saurez évaluer la solidité et la fiabilité d’une boite d’édition de logiciel (le fameux “Joel’s test”). Et pour tous les geeks qui aiment le travail bien fait, mais aussi qui veulent réaliser des produits qui puissent se vendre (à l’opposé des geeks qui réalisent des trucs dont personne ne veut, d’ailleurs personne ne leur a demandé, mais ça leur fait plaisir), alors Joel est pour vous !

Si vous n’avez pas envie d’investir dans un livre, commencez par son blog : je vous conseille par exemple cet article récent, où il donne des conseils pour adapter son CV lorsqu’on postule à une petite boite d’édition.

Comme bien souvent avec ce genre de bouquin, il ne vous apprend pas forcément quelque chose de nouveau, mais il met le doigt sur le truc qui cloche, et il offre des solutions pour éviter ces obstacles. Et il vous dit : “allez-y ! n’ayez pas peur !”

Pour moi Joel est la preuve qu’on peut être bon développeur (en écrivant du code propre et documenté) tout en étant compétitif (c’est à dire livrer à temps le logiciel dont a beson le client). Je ne suis pas sûr que toutes les boites encouragent ça. Sur le papier, bien sûr ! Mais en réalité, combien donnent vraiment les moyens à leurs développeurs de livrer des bons produits ?

A l’heure où le développement informatique devient grand public, ou n’importe qui peut prendre un éditeur de texte et développer son site en php, je pense que c’est important que les professionnels de l’informatique arrivent à marquer leur différence. Ca n’était jamais arrivé avant : les professions sont parfois protégées (médecin, avocat, etc.) soit il faut investir dans du matériel, mais pour l’informatique : pas de barrière ! n’importe qui peut s’improviser informaticien.

Joel nous montre qu’un professionnel de l’informatique est bien plus qu’un bidouilleur de code, et j’aime bien ça !

à plus

roland