J’ai introduit les tests automatiques chez PMSIpilot quand j’y était directeur technique. J’ai fait de même chez m6web, en y ajoutant des outils d’analyse statique comme phpcd, ou phpmd.

Une question se pose facilement à la fin de chaque projet : le logiciel produit est il de qualité ? On peut déjà se poser la question s’il marche comme attendu. Toutefois, pour envisager la maintenance et l’évolution du produit il nous faut un peu plus. Je dégaine alors la couverture des tests, le mess detector etc…

Franchement, tout ça c’est bien – et puis, pour reprendre Frédéric Hardy : « un peu de tests, ça vaut mieux que pas du tout » – mais j’ai toujours de la peine à me fier à ces données : on peut couvrir tout le code sans couvrir tous les cas d’utilisation, on peut respecter à fond les standards en produisant tout de même du code illisible etc …

Je reprend alors la revue de code en y mesurant le taux de What The Fuck / minute. C’est très efficace (sèrieusement).

WTF / minute

Ok vous savez tout ça déjà.

Ouai ben accrochez-vous, j’ai trouvé une mesure encore plus efficace !

Le niveau de satisfaction des développeurs !

Le projet derrière vous, demandez aux développeurs ce qu’ils en pensent. Pensent-ils avoir fait du bon travail ? Ont-ils pris du plaisir ? Y a t’il des points particulièrement innovants qu’ils aimeraient exposer à leurs pairs ? Voudraient-ils continuer à travailler sur le projet ?

Essayez, ça marche à tous les coups. Les projets ayant le plus satisfait les développeurs seront ceux de meilleur qualité ! Retournons le concept, si vous voulez que la qualité soit au rendez-vous, faites en sorte que vos développeurs soient heureux.

J’écrivais précédemment qu’on loupait beaucoup de choses quand on ne s’intéressait pas aux retours de son équipe technique pendant la réalisation d’un  projet. J’ai oublié un truc.

J’ai complètement oublié qu’il est aussi dommage de se priver de cette intelligence lors de l’expression de besoin, de la préparation du projet. En effet, un Responsable Produit veut, en général, le meilleur pour son projet. Cela se traduit (à moins de rencontrer des concepteurs de très haut niveau) par l’expression d’une débauche de fonctionnalités. J’en parlais en 2006 déjà en bloguant autour de ce que j’appelais « la lettre au Père Noël« . Le concepteur, un peu experimenté, sera capable de classer ces demandes par ordre de priorité.

Toutefois, sans le développeur, il sera incapable de pondérer ces demandes par leur complexité. Ainsi, par exemple, vos équipes vont s’embarquer dans la création de back office pour des actions utilisateurs bi-annuelles ; un fichier de configuration aurait fait l’affaire. Vous risquez de ne pas traiter en priorité des demandes nice to have mais si peu coûteuses à réaliser qu’elles auraient pu vous démarquer avantageusement de la concurrence. Etc.

J’ai lu cette citation : « Chez Toyota, on a estimé que ces milliers de paires de bras étaient aussi surmontées d’un cerveau. ». Appliquons ça aussi à la conception de nos projets informatiques.

J’ai loupé quoi ? « Un push roash mais le terran a défendu. Là il part méca et le zerg pose B3″ mon fils, 6 ans, devant #ironsquid ^^

— Olivier Mansour (@omansour) Décembre 9, 2012

Les méthodologies agiles sont bien connues et commencent à être massivement adoptées. Toutefois ce n’est pas la poudre verte et beaucoup d’organisations continuent tranquillement à travailler « en V ». Que risque t-on à ne pas être agile ? Ou encore, quel est le principal avantage des méthodes agiles ?

Les méthodes agiles souffrent de beaucoup de préjugés quand on ne les a jamais pratiquées : « c’est le bazar », « on ne sait pas ou on va », « plus besoin de faire des specs, de la doc etc. ». Bref.

On oublie souvent que passer à l’agile demande une organisation bien rodée et un effort important. Cela nécessite également que la confiance règne entre les différents acteurs des projets. (product owner et dev notamment).

Par ailleurs, on passe souvent à coté de ce que j’estime être l’avantage premier de ces méthodes. On cite souvent : « on va livrer plus souvent, éviter l’effet tunnel », « on peut démarrer plus tot », « on peut changer d’avis », … C’est vrai, mais la killer feature n’est pas là !

Le product owner (le chef de produit ?) doit être au centre de l’équipe de développement. On imagine donc des responsables échangeant tous les jours avec les devs et les intégrateurs, participant au meeting etc. Ok super, comme ça aucun risque de non qualité. C’est ça ta killer feature ? Et non ! (même si c’est cool). Pour moi le truc génial c’est le responsable qui va pouvoir s’inspirer des ces échanges avec les techniciens pour améliorer son produit !

Et oui ! Ami PO, ces personnes ne sont pas juste de simples exécutants. Le développement informatique nécessite un (gros) cerveau, une capacité d’analyse et de recul importante. Votre équipe va passer 100% de son temps de travail derrière votre projet, croyez-moi ils le comprendront bien ! Ils vont discuter de détails que vous n’imaginez pas  ! Laissez-les s’exprimer, demandez leur leur avis pendant la planification par exemple. Attendez vous à de bonnes surprises .

Honnêtement, je suis persuadé que les grosses entreprises qui réussissent dans des projets techniques (google, facebook, apple …) ne laissent pas uniquement le marketing ou les chefs de projet sortant d’école de commerce aux commandes. Etre agile vous donne cette opportunité de travailler auprès de votre équipe technique, ne passez pas à coté !

Je pense connaitre un peu GIT, mais cette conf a été l’occasion de vraiment découvrir des principes de base qui m’avaient échappés. J’ai aussi découvert pas mal de commandes que je ne connaissais pas et des concepts qui m’étaient carrément passés au dessus de la tête . Donc un moment très intéressant, et bien animé par un orateur passionné.

J’ai pris quelques photos.

[edit] les slides sont disponibles via gitfr.net.

Retrouvez quelques photos de l’évènement : https://plus.google.com/photos/109730603589732450901/albums/5805597131704935201

Si vous voulez participer à la vie de l’AFUP Lyon, retrouvez l’antenne sur twitter et sur le site officiel : http://lyon.afup.org.

Voici différentes propositions :

N’hésitez pas à répondre au sondage ! Et suivez l’AFUP Lyon sur twitter.

Pour débugguer un site sur IPad il faut :

• activer l’inspecteur web dans les réglage de Safari

• relier votre IPad à votre ordinateur via USB
• dans les préférences de Safari, activer l’option affichant le menu de développement

• Vous devriez voir, sous le menu Développement, votre iDevice connecté

• Un clic dessus vous affiche l’inspecteur de Safari

et voilà !