Archives du mot-clé projet informatique

Enfin une bonne mesure de la qualité logicielle ! (ou presque)

Je m’intéresse beaucoup à la qualité logiciel. Oui, ça fait bien marrer tous les javaistes, mais dans l’univers du PHP c’est « relativement » récent.

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.

Publicités

Je serais le premier orateur de l’histoire de Sud Web !

C’est un peu la classe ! o/

J’y animerais une conférence de 20 minutes plutôt atypique, la seule orientée business : Acheter des prestations IT et web. Je tenterais d’apporter un éclairage synthétique sur un sujet auquel je réfléchis depuis un petit moment (comme dirais @nhoizey !).

Je remercie d’ailleurs les organisateurs pour la confiance qu’ils m’accordent.

A ce propos il ne reste que quelques jours pour vous inscrire à ce qui promet être un bel évènement plein de gens biens ! (et y aura moi aussi ~ ).

Réfléchir c’est mal …

Je dis parfois avec espièglerie que réfléchir c’est mal … laissez moi vous expliquer.

Comme la plupart de mes idées, je l’ai piochée ailleurs. Ici en l’occurrence page 13 de ce monument de BD qu’est l’ouvrage « Les nouveaux centurions – donjon crépuscule tome 105″ , dessin : KERASCOËT, scénario : SFAR et TRONDHEIM (et oui, on a les références qu’on peut). Voici donc que Marvin Rouge tente d’expliquer aux moines dragon comment voler avec les sortes de canons qu’ils ont fixé a leur poignets et intégrés dans leur nouvelles armures. (cliquez sur les images pour les voir en grand)

Ca a l’air idiot mais justement REFLECHISSONS un peu à ce que Marvin vient de dire.

  1. il a toujours volé instinctivement ou poussé par la nécessité,
  2. il n’a pas planifié, anticipé cette pratique, il l’a juste mis en oeuvre naturellement,
  3. il explique qu’il ne faut surtout pas intellectualiser cette démarche : réfléchir c’est mal.

La suite est assez édifiante et on constate ici toute la profondeur de Marvin.

Il nous explique :

  1. qu’on peut se lancer sans savoir exactement ce qui va se passer (on va décoller après on voit !),
  2. qu’il ne sert à rien de psychoter sur un éventuel échec, en cas de problème on corrige,
  3. que de toute façon si on se plante c’est pas grave, on en a vu d’autres et on est bien protégé de toute façon (là Marvin exagère un peu non ?).

En fait Marvin fait la critique du OVERTHINKING. Un peu comme Barney dans HIMYM (se moquant gentiment de Ted).

Lily: Don’t Ted-out about it.
Ted: Did you just use my name as a verb?
Barney: Oh, yeah, we do that behind your back. « Ted-out »: to overthink. See also « Ted-up ». « Ted-up »: to overthink with disastrous consequences. For example, « Billy Tedded-up when he- »
Ted: All right, I get it!

(toute mes excuses pour cette digression)

A titre professionnel, j’applique la doctrine de Marvin assez régulièrement, alors que mon éducation me pousse à faire l’inverse : avant de rédiger une rédaction on fait un plan, il faut lire le manuel avant d’assembler sa boite de légo, tourne sept fois la langue dans ta bouche avant de parler … C’est du bon sens.

Pourtant, face à des problématiques très complexes il est tout simplement impossible de planifier l’ensemble. Il est quasi certain que le résultat sera faux. (j’ai personnellement pratiqué la planification de projet à haute dose en SSII et j’étais plutot considéré comme bon dans cet exercice ; d’expérience, je peux affirmer qu’au delà de 100 jours homme la prévision est fausse, ce sont les capacités du chef de projet à cadrer le client qui assureront la tenue budgétaire du projet). Une stratégie plus efficace in-fine est de se mettre en position de démarrer le plus vite possible dans les conditions les moins mauvaises. Ainsi, quand des consultants fonctionnels me demandent jusqu’où faut-il aller dans les spécifications, je réponds : « le minimum pour que les développeurs puissent démarrer ».

Pire, anticiper tous les futurs problèmes, s’assurer qu’on sait à l’avance comment tout va se passer dans les moindres détails peut même bloquer un démarrage, l’ampleur de la tâche à venir paralysant chaque tentative. Au final, tout cet effort de prévision (étude, synthèse, note de cadrage, réunions, …) n’aura été que du temps perdu.

Démarrez !

Vu ce que m’a appris Simon Sinek (quoi ! vous ne connaissez pas Simon Sinek), si nos actions ont un sens permettant d’atteindre un but clair, compris et accepté, il vaut mieux se fier à ses tripes et réfléchir le moins possible. Allez ! on y va.

Que faut il savoir pour être un bon développeur web ?

On utilise couramment l’expression développeur web pour désigner le développeur travaillant à l’élaboration d’un site web ou d’une application en client léger. Même si cette expression ne me satisfait pas énormément, je vais m’en contenter pour ce modeste article.

Voici, selon moi, ce qu’il faut savoir pour être un bon développeur web.

Lire la suite

Quelques trucs de base sur la gestion de projet en informatique

Je suis un vieux con. Je radote les mêmes trucs que d’autres radotaient avant moi avant de me les transmettre. Afin que toi aussi, cher lecteur, tu deviennes un vieux con comme moi, je me permets, en toute modestie, de te donner également ces très modestes conseils.

1/ De nouveaux besoins tu n’inventeras pas (dans un premier temps au moins)
L’informatique est la science de la gestion de l’information (bim !). En fait, on fait de l’informatique depuis bien avant l’ordinateur ou la machine a calculer. Si vous voulez que votre projet réussisse, commencer par informatiser les flux d’informations existants (genre le papier que untel dépose dans la bannette de untel pour le valider afin qu’il soit ensuite archivé etc…). Déjà ça ce sera pas mal. Ceci fait, vous pourrez optimiser tout ça.

2/ La lettre au père Noël tu n’écriras pas
C’est vrai qu’en phase de spécifications l’imagination à tendance à se débrider au détriment des fonctions clés : à relire sur ce blog. (omg ! ça date de 2006).

3/ Les plus petites itérations tu feras
Et ce n’est pas si facile à faire ! ¨Pourtant, les connaisseurs des méthodes agiles seront bien d’accord avec moi pour dire que plus on livre tôt et souvent, plus le cout de retour en arrière est faible, le projet tolérant aux erreurs de conception et les risques de répondre à coté de la plaque aux attentes des utilisateurs diminué. Enfin, on y pense peu, mais quand on programme un projet de plus de 4-5 ans (si si ça existe !), il faut s’attendre à gérer un turnover au sein même de ce projet (y compris à la direction).

Quand je vois le projet de DMP – Dossier Médical Personnel – tous ces indicateurs passent au rouge, ce qui selon moi est de mauvaise augure. A mon sens, une étape intelligente aurait été de commencer à informatiser ce bon vieux carnet de santé : facile + bénéfices immédiats. (c’est un avis personnel)

Acheter des prestations en informatique – #3 – Comment garantir la qualité du code de vos développements au forfait

De nombreux décideurs commandent des réalisations de développement informatique au forfait. Admettons que le besoin soit bien formulé, que les choix technologiques soient pertinents et que le respect du cahier des charges fasse l’objet d’un contrôle rigoureux ; l’objectif du forfait est de border l’enveloppe budgétaire qui va permettre de réaliser ce projet. Ce qui est souvent mal compris c’est qu’un projet dont le code est mal réalisé risque d’entraîner un surcoût important lors de la vie de ce projet.

Cet article fait partie de la série : Acheter des prestations informatiques.

Lire la suite

Acheter des prestations informatiques – #2 – le cahier des charges

Le cahier des charges est un incontournable de la gestion de projets. Un point de départ en somme. C’est aussi un des documents les plus critique, notamment dans le cadre de projets réalisés au forfait par des prestataires de services. Je vais tenter dans cet article de vous donner quelques recettes et de vous indiquer les écueils à éviter pour produire un bon cahier des charges.

Cet article fait partie de la série : Acheter des prestations informatiques.

Lire la suite