Développements et spécifications

Dans la vie il y a des jours ou on veut rire, mais on ne peut pas; alors il nous faut trouver un moyen de le dire, de s'exprimer. Je vais le faire là. Dans le développement de logiciel on a en général plusieurs grandes étapes distinctes :

• Rédaction des spécifications (générales courtes puis détaillées, et techniques courtes puis détaillées)
  
• Le développement en lui même
  
• La recette (les test et l'évolution des spécifications initiales)
• Les corrections (la suite du développement)
• Un autre recette (en cas de validation on va à l'étape suivante, sinon on reviens à la précédente avec de nouvelles évolutions)
• La mise en production (là en général c'est champagne)

Donc une fois que l'on a ces bases, il devient évident qu'aucun logiciel ne devrait sortir comme cela se passe de nos jours à savoir :

• Rédaction et développement en même temps
• Recettes et corrections simultanées
• Mises en production de versions intermédiaires (n.x.y_z...)

Ce problème viens d'un défaut de compréhension de la méthode dite "Agile". En effet, si cette méthode prône une certaine réactivité, une certaine communication entre les équipes de développement et le client d'un projet, elle ne prône en aucun cas la précipitation ni l'accumulation de spécification de correction et encore moins la génération de régressions en chaîne.

En fait quand on parle à un client de méthode agile, le client entends "rapide", et confonds vitesse et précipitation. L'erreur est humaine mais en ayant un projet dont les spécification fonctionnelles courtes et détaillées sont abouties au moment d'en passer la commande, je pense qu'il y aurait moins de problèmes par la suite. Corriger et faire évoluer des spécifications est plus facile à faire sur des briques stables que sur des versions encore en développement. Par ailleurs corriger du code instable pour en faire un code instable pour une recette est parfaitement contre productif également.

Enfin bon tout cela pour dire que bien que l'informatique en soit encore à l'enfance, on a beaucoup à faire avant l'age adulte; nous n'avons pas encore fait son adolescence et que ce jour là, ça ne va pas être la fête.

Transports en IDF

Je hais le RER A, je suis obligé de le prendre tout les jours mais je le hais!
ce matin je pars bien je chope tout juste mon train de environ 08h05, et j'ai pus arrivé à la défense à 08h50 la où le trajet doit prendre 24 minutes, (j'aurais si je compte bien du arrivé à 30...) bref j'ai 20 minutes de retard soit 2 trains de ma correspondance (1 tout les 1/4 d'heure)... tout ça pour un frein de secours!

Faisons un petit calcul en tant que mercenaire informatique je suis facturé 400 €uros / jour c'est en gros la moyenne sur le marché, pour 08h00 de travail quotidien, deux trains ça fait 1/2 heures (au passage remarquez que la SNCF permet l'égalité : 20min = 30min) soit 400/16 ~ 25 €uros imaginons que les répercutions durent suffisamment longtemps pour impacter 10 000 personnes (en fait je crois que ça en impacte beaucoup plus, mais bon c'est de la théorie) ça fait une perte sèche pour l'économie française de directement 250 000 €uros... sans compter tout ceux qui bloquent des gens quand ils sont absents... Et sans compter tout ceux qui gueule en sont énervés par la suite ce qui compte encore (tout comme ce billet-exutoire d'ailleurs).

Bref, je propose de supprimer les frein de secours -et de le remplacer par un signal au chauffeur-, et que les blessés, malaises et autre soient gérés sur le quai de la gare suivante, par une équipe d'infirmier présente dans chacune d'entre elles (en plus ça fait de l'emploi).