Que faut-il faire pour avoir de meilleurs logiciels ?

Vous voulez du logiciel mature plus vite ?

Ce n'est pas compliqué. Misez sur des techno mûres et des développeurs d'expérience.

Faites du neuf avec du vieux.

Le développement logiciel est surtout affaire d'expérience et de méthode au même titre que n'importe quelle activité d'ingénierie.

Cependant, la tendance n'est pas à faire confiance à l'expérience.

J'adore ce genre d'articles bourrés de lieux communs. Je vais ouvrir un blog aussi avec un article.

Comment faire un bon logiciel.

Glutinus, développeur Business Intelligence, nous explique comment faire un bon projet BI.

Alors c'est très simple. Il faut que le sponsor soit chaud bouillant donc on lui fait un POC exprimant le ROI dont il a besoin pour qu'il étale la thune pour faire une bonne équipe.
Les utilisateurs doivent être impliqués et comprendre parfaitement le process. Systématiquement refuser si la spécification de besoin ou le cahier des charges a une incohérence et ne pas lancer les devs.
La MOA et l'AMOA doivent rédiger des spécifications fonctionnelles compréhensibles à 100% par la MOE, et pas du tout vague.
Le chef de projet ne doit rien faire à l'arrache et être à jour dans son fichier excel. Son équipe doit également être composée d'un référent technique, d'un analyste-concepteur, d'un DBA Prod couplé études et des développeurs avec 15 ans d'expérience ainsi que quelques jeunes à la tête bien faites qui se formeront sur des développements.

On ne fait pas de développement sans spec technique validée par tout le monde. Une fois lancé les tests unitaires doivent être détaillés, le code commenté, les specs remises à jour lors des écueils techniques puis un test de performance avec une plate-forme iso DEV / Recette / production.

Les utilisateurs sont impliqués à 100% pour la recette et pas de mise en production le vendredi.

Si tout le projet se passe bien ne pas oublier d'inviter l'équipe MOE et les féliciter au pot de la galette du nouvel an, et pour les prestataires appeler les commerciaux des SSII pour leur dire de verser une prime de 2000€ à chacun d'entre eux.

Vouzenpensezquoi ?

+1000 Jai déjà mis ce lien il n'y a pas longtemps, mais il illustre tellement bien le débat... Peu importe la méthodologie, tant qu'elle est appliquée par des gnous qui ne comprennent pas ce qu'ils font(un peu moi quand je fais du système, hélas), on va dans le mur. Et, au contraire, n'importe quelle méthodologie peut être détournée par des gens qui savent ce qu'ils font pour obtenir un résultat brillant.

+1 aussi sur la culpabilité des grands comptes sur l'existence des SSII à la Française. J'en ai vu refuser un expert à 600€ sur 30 jours mais accepter 3 gnous à 350€ 60 jours chacun. Et, au final, les gnous n'ont pas fait ce que l'expert aurait fait - en 30 jours. Mais comme le TJM a baissé, les gens des achats ont eu leur prime.

- bannir les SSII qui poussent au low-cost et qui méprisent le métier de développeur, réduit à un simple ouvrier qu'on jette une fois le travail terminé

- sensibiliser le développeur sur l’intérêt des tests unitaires, étape souvent bâclée, surtout si on est dans une SSII lamentable

- un calendrier raisonnable et réaliste

- favoriser la licence open-source ( code source en libre accès ) pour une transparence absolue et un meilleur contrôle

Pour avoir de meilleur logiciel, que faut-il faire ?

C'est simple... être meilleur...

alors, certains vont partir dans la direction de l'amélioration des processus (agile, TDD, autres)...

d'autres vont pointer la formation des développeurs, la reconnaissance, etc...

d'autres vont miser sur le temps, l'écoute, le partage...

d'autres vont miser sur la reconnaissance de l'expérience qui permet, normalement (mais pas toujours), d'obtenir de meilleurs choses plus on a l'habitude d'en faire...

-------------

Après, on tape sur les SSII.. mais finalement, la SSII n'est que la réponse a un besoin exprimé par un client...

Les SSSI aimeraient bien vendre des développeurs expérimentés à 500€/jours à leurs clients... sauf que le client (principalement les gros industriels plus que les petites boites) a tendance à croire que développer, c'est simple, facile, rapide et donc, "hurle" dès qu'on lui mets des tarifs élevés.. (d'ailleurs, souvent les entreprises "compensent" le TJM bas par plus de jours de prestations !!!

Personnellement j'aurais mis "maintenable" en haut de la liste (comprenez documenté, sans trop de code spaguetti, etc.)

Un logiciel maintenable mais pas très robuste, ça se renforce, pas de soucis.
Un logiciel robuste mais impossible à maintenir, c'est la poubelle direct à la moindre évolution importante.

Enfin bon c'est un point de vue

Au delà de pratiques particulières, je pense qu'il faut former les intervenants à tenir compte de l'ensemble des domaines de la fabrique d'un logiciel. Qu'il s'agisse d'architecture, conception, analyse, développement, test, intégration, déploiement, maintenance, support, robustesse, etc.
Quand on envisage une tâche, il faut tenir compte de l'impact sur tous ces domaines.

Donc pour avoir de meilleurs logiciels, il faudrait former ce que certains appellent des artisans logiciels.

Enfin un autre point, l'amélioration continue (ou la remise en cause perpétuelle). Qu'il s'agisse de processus, de son propre travail ou de celui des voisins. Ayant cet objectif en tête, l'utilisation des techniques citées deviendra assurément une évidence, et permettra surement la création de nouvelles techniques.