Discussion :

[OSryx]

Bonjour,

Il m'est demandé de réaliser une application informatisant un processus administratif.

Donc pour faire les choses dans les règles, je dois d'abord rédiger un cahier des charges pour exprimer les besoins du client.

Ensuite, Concevoir l'application puis après procéder à l'étape de programmation ou réalisation de l'application.

Ce qui veut dire, j'aurai un premier livrable qui est le Cahier des charges qui sera lu par le client. Quelques livrables ou diagrammes UML pour concevoir les fonctions de l'application, que je communiquerai à personne, je les garderai pour les utiliser à l'étape de programmation.


S'il vous plait, est ce que j'ai bien compris le cycle de vie de réalisation d'une application. Est ce que vous pourrez me corriger ? et détailler d'avantage ?

[Francis Walter]

Je ne sais pas si j'ai bien compris ce que t'as expliqué mais il y a plusieurs cycle pour le développement d'une application. Le tout dépend du cycle (modèle) que tu choisis.

[OSryx]

est ce que vous pouvez me citer les noms des cycles (modèles) les plus célèbres ?

[Saverok]

Le modèle le plus simple pour débuter et quand on est seul, c'est le cycle en V : http://fr.wikipedia.org/wiki/Cycle_en_V

C'est une méthode rigoureuse et assez rigide qui évide de se disperser
Elle convient donc très bien aux débutants

Le tableau avec les documents à fournir par phase du lien wikipédia ci-dessus te donne la liste de tous tes livrables
Tu y retrouves ceux que tu as cités plus quelques autres en plus

Note :
Chose assez importante si tu souhaites être rigoureux : écrire ton plan de test au moment de la conception. Autrement dit, avant de développer.

[OSryx]

Merci pour votre réponse, je pense que le modèle que j'ai décrit dans ma première publication est le Cycle V.

Par contre, je vous serai reconnaissant si vous me citez la différence du cycle V des méthodes agiles !!?

[Francis Walter]

Merci pour votre réponse, je pense que le modèle que j'ai décrit dans ma première publication est le Cycle V.

Par contre, je vous serai reconnaissant si vous me citez la différence du cycle V des méthodes agiles !!?

Le cycle en V est fondé sur :

• Analyse (on analyse les informations disponibles et les besoins, ensuite on réalise les spécifications fonctionnelles qu'on fait valider avec les utilisateurs. On ne passe pas cette étape tant que les spécifications ne sont pas validées par les utilisateurs / client)
• Conception / Réalisation (Si les spécifications sont validées bah on passe à la mise en place de la BDD s'il y en a et aux codages)
• Tests (Unitaire, Intégration, Acceptation, etc.) : on s'assure que tout fonctionne bien comme voulu

Les méthodes agiles sont basées sur trois autres cycles : incrémental, itérative et adaptative et fondé sur 12 principes.
Les principes des méthodes agiles

1. La plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à forte valeur ajoutée.
2. Le changement est accepté, même tardivement dans le développement, car les processus agiles exploitent le changement comme avantage concurrentiel pour le client.
3. La livraison s’applique à une application fonctionnelle, toutes les deux semaines à deux mois, avec une préférence pour la période la plus courte.
4. Le métier et les développeurs doivent collaborer régulièrement et de préférence quotidiennement au projet.
5. Le projet doit impliquer des personnes motivées. Donnez-leur l'environnement et le soutien dont elles ont besoin et faites leur confiance quant au respect des objectifs.
6. La méthode la plus efficace de transmettre l'information est une conversation en face à face.
7. L’unité de mesure de la progression du projet est un logiciel fonctionnel (ce qui exclut de comptabiliser les fonctions non formellement achevées).
8. Les processus agiles promeuvent un rythme de développement soutenable (afin d’éviter la non qualité découlant de la fatigue).
9. Les processus agiles recommandent une attention continue à l'excellence technique et à la qualité de la conception.
10. La simplicité et l'art de minimiser les tâches parasites, sont appliqués comme principes essentiels.
11. Les équipes s'auto-organisent afin de faire émerger les meilleures architectures, spécifications et conceptions.
12. À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son processus de travail en conséquence.

Après, il faut voir quelles méthodes agiles choisir (XP, RAD ou Scrum) en fonction de la taille, de la complexité et des contraintes du projet

[foetus]

Merci pour votre réponse, je pense que le modèle que j'ai décrit dans ma première publication est le Cycle V.

Par contre, je vous serai reconnaissant si vous me citez la différence du cycle V des méthodes agiles !!?

En gros avec une méthode agile, il n'y a pas de cahier de charges (C.D.C.) de rédiger.
Mais il n'y aura plus ou moins des documents: par exemple, avec Scrum, il y a les To-do Lists.

L'idée des méthodes agiles c'est que 1) c'est long de recueillir les spécifications et rédiger le C.D.C. 2) le client ne sait pas ce qu'il veut
Donc il faut coder le plus rapidement possible pour toujours avoir une démo fonctionnelle, et pour se faire, en découpant le processus en petites étapes (méthode incrémentale et/ ou itérative)
De plus, il faut intégrer le client (ou un représentant) dans l'équipe de développement pour savoir quoi faire et avoir son feedback
Et enfin, pour que cela fonctionne, il faut avoir des moyens "de valider et d'assurer" son code: avec des tests unitaires, avec du pair programming, avec des outils de gestion de versions ou d'intégration continue...

Le cycle en V, c'est une méthode spécifique "traditionnelle" (<- avec un C.D.C.) -> "chaque étape d'une branche a son pendant dans l'autre branche, c'est à dire qu'une étape de conception correspond à une étape de test qui lui est spécifique. A tel point, d'ailleurs, qu'une étape de test peut être élaborée dès que la phase de conception correspondante est terminée, indépendamment du reste du projet"

[souviron34]

En gros avec une méthode agile, il n'y a pas de cahier de charges (C.D.C.) de rédiger.

Ah bon ??????

Si il y en a un....

Ce sont les documents d'Analyse et de Conception Préliminaire qui sont soit zappés, soit ultra-simplifés..

L'idée des méthodes agiles c'est que 1) c'est long de recueillir les spécifications et rédiger le C.D.C. 2) le client ne sait pas ce qu'il veut

AU CONTRAIRE...

L'idée des méthodes agiles, c'est que c'est le CLIENT qui sait ce quil veut, et que les informaticiens ne savent pas toujours le traduire correctement, ou insister pour obetnier tous les détails...

Cela reivent donc à dire que les SP2CIFICATIONS (pas le cahier des charges) seront évolutives avec le temps...

Donc il faut coder le plus rapidement possible

Et après on se demande pourquoi ça échoue et pourquoi les méthodes agiles ont si mauvaise presse... !!!!!!!!!

Agile ne veut ps dire ne pas réfléchir, analyser, et préparer...

C'est juste qu'on n'attend pas d'avoi fini tout pour montrer au client...

Et enfin, pour que cela fonctionne, il faut avoir des moyens "de valider et d'assurer" son code: avec des tests unitaires,

Totalement faux.. Les TU viennent du cycle en V..


Bref, quand on sait pas de quoi on cause, on ferme sa boite et on évite de professer des âneries.. Merci pour ceux qui viennent chercher de l'information sur un forum de professionnels..

[Saverok]

L'idée des méthodes agiles c'est que 1) c'est long de recueillir les spécifications et rédiger le C.D.C. 2) le client ne sait pas ce qu'il veut

Bien sûr que le client sait ce qu'il veut sinon il ne ferai pas de projet CQFD
Par contre, soit il ne le sait pas en détail (et ces détails viennent au fur et à mesure), soit il ne sait pas l'exprimer précisément (ce qui revient au même que le point précédent), soit il n'est pas buté dans son idée initial et l'éprouve et l'adapte en fonction des retours utilisateurs lors des nombreuses démo (c'est le cas le plus courant car entre ce que l'on imagine sur papier et le résultat final, il peut y avoir des surprises et on se rend tjrs compte de chose à ajuster / adapter quand on voit le programme en fonctionnement car lors de la rédaction des CDC, on ne peut pas tout tjrs tout prévoir)

[foetus]

Si il y en a un....

Ce sont les documents d'Analyse et de Conception Préliminaire qui sont soit zappés, soit ultra-simplifés..

En XP il y a que dalle (juste pour que tu me contredises)
Et effectivement, en fonction des méthodes il doit y avoir des morceaux de C.D.C.

Mais l'idée des méthodes agiles est de simplifier au maximum le C.D.C.

Heureusement que je n'ai pas dit que les documents dans les méthodes agiles servent à rassurer les cravateux des 2 côtés

L'idée des méthodes agiles, c'est que c'est le CLIENT qui sait ce quil veut, et que les informaticiens ne savent pas toujours le traduire correctement, ou insister pour obetnier tous les détails...

Cela reivent donc à dire que les SP2CIFICATIONS (pas le cahier des charges) seront évolutives avec le temps...

Juste pour que tu rages, par définition le C.D.C. est figé dans le marbre (signé ...) Donc évolutif

Et c'est beau: les informaticiens y comprennent rien, ils ont dû mal à parler à des gens (toujours sur leur ordinateur), ils cassent le projet méchants.

Comme l'a dit Saverok après toi, c'est aussi le client qui peut être déçu par un choix, une idée, un truc.
Donc changer quelque chose

Et après on se demande pourquoi ça échoue et pourquoi les méthodes agiles ont si mauvaise presse... !!!!!!!!!

J'ai dit "rapidemment" (comprendre pas au bout de X mois, mais quelques semaines ou quelques jours), je n'ai pas dit "dans la précipitation"
De toute manière, dans la majorité des méthodes agiles le processus est découpé en petites étapes (itératif/ incrémental).
Et à chaque étape, une démo doit être plus ou moins fonctionnelle.

C'est juste qu'on n'attend pas d'avoi fini tout pour montrer au client...

On est d'accord
Le client (ou un représentant) doit être dans le projet pour donner son feedback à chaque itération.

Totalement faux.. Les TU viennent du cycle en V...

En XP tu dois faire les TU avant. Que cela vient du cycle en V on s'en fiche.
Dans les méthodes agiles, les tests sont, il me semble, une pierre angulaire

Bref, quand on sait pas de quoi on cause, on ferme sa boite et on évite de professer des âneries.. Merci pour ceux qui viennent chercher de l'information sur un forum de professionnels...

Je m'excuse

Bien sûr que le client sait ce qu'il veut sinon il ne ferai pas de projet CQFD
Par contre, soit il ne le sait pas en détail (et ces détails viennent au fur et à mesure), soit il ne sait pas l'exprimer précisément (ce qui revient au même que le point précédent), soit il n'est pas buté dans son idée initial et l'éprouve et l'adapte en fonction des retours utilisateurs lors des nombreuses démo (c'est le cas le plus courant car entre ce que l'on imagine sur papier et le résultat final, il peut y avoir des surprises et on se rend tjrs compte de chose à ajuster / adapter quand on voit le programme en fonctionnement car lors de la rédaction des CDC, on ne peut pas tout tjrs tout prévoir)

Un peu confus mais effectivement tu apportes 1-2 nuances que j'aurai dû apporter

[souviron34]

Alors si tu connais XP parle de XP.. (je ne peux pas te contredire ou savoir si ce que tu dis est vrai, je ne connais pas, ni ne pratique)

Pas des "méthodes agiles"..


Relis le Manifeste stp...


Comme je l'ai déjà dit N fois, les "méthodologies agiles" sont un dérivatif "figé" (et visiblement mal assimilé) de la philosophie Agile, telle que décrite dans le Manifeste...

Pour la nième fois, il FAUT connaitre les étapes normales d'un cycle en V, et les suivre... Simplement pas dans le même détail que dans le cycle en V.. Ni (en ce qui concerne les tests) dans le même ordre...

Mais les CdC existent, de même que les specs et les analyses..

Simplement, on (équipe informatique, et donc discours vers le client) ne s'attend pas à avoir tout figé dans le marbre, que ce soit au niveau du CdC, des spec, de l'architecture, et finalement du détail..

Alors qu'à 'inverse, dans le cycle en V traditionnel, une fois le CDC établi - une fois pour toutes - , on analyse - une fois pour toutes - on crée une architecture - une fois pour toutes - et on établit des specs - une fois pour toutes - et même du pseudo-code - une fois pour toutes...

L'échec de ce genre d'approche n'est flagrant que pour les gros projets (plusieurs années avec plusieurs dizaines, voire centaines, de programmeurs). Dans ces cas, outre les changements technologiques intervenus pendant la durée, la traduction des besoins utilisateurs en specs et/ou l'architecture peut ne pas correspondre à ce qui est demandé réellement, et dans ce cas-là le processus est assez déchirant (autant humainement que financièrement, et en temps). **

C'est cette constatation qui a fait que, des auteurs du Manifeste à des gens comme moi ou d'autres, nous avons prôné une approche beaucoup plus souple, que ce soit dans la "gestion" du projet que dans la gestion humaine et des équipes..

Mais pour ce faire il faut possèder totalement ce qu'est réellement le cycle de vie en V, et simplement se reposer sur l'expertise de toutes les personnes de l'équipe..

Cela ne veut en rien dire "ignorer" les étapes essentielles, et faire du "n'importe quoi", même partiel....


Le PO poste une demande d'explication sur la différence entre les approches, le moins qu'on puisse faire sur un forum de pros est de lui donner une vraie information...


** : les projets sur lesquels j'ai appliqué ça étaient par exemple une 60 aine de programmeurs pendant plus de 14 ans, avec un budget de plus de 80 millions... La révision est assez déchirante : outre l'argent gaspillé (quand même 80 millions), c'était leur "bébé", depuis plus de 14 ans... et 2 millions de lignes de code... Leur faire accepter de tout revoir, et de jeter à la poubelle toute l'architecture, et toute l'approche, est pour le moins... délicat...

Et c'est beau: les informaticiens y comprennent rien, ils ont dû mal à parler à des gens (toujours sur leur ordinateur), ils cassent le projet méchants.

C'est (malheureusement) la réalité des projets à l'origine de l'émergence du Manifeste... et de ce que une longue expérience te prouve tous les jours...

En XP tu dois faire les TU avant. Que cela vient du cycle en V on s'en fiche.
Dans les méthodes agiles, les tests sont, il me semble, une pierre angulaire

Voir ce qu'a dit Francis : les TU sont la pierre angulaire du cycle en V...

Dans une comparaison des méthodes tellle que le demandait le PO, il est absurde de signaler que les TU sont la pierre angulaire des méthodes agiles..

[Invité]

Le sujet n’est plus d’actualité mais certaines pratiques le sont toujours…

Il faut intégrer le client (ou un représentant) dans l'équipe de développement pour savoir quoi faire et avoir son feedback.

Ça, c’est une pratique hypocrite apparue dans les années 80. L’objectif réel d’intégrer un « feedback » dans l’équipe de développement, c’est de cautionner le logiciel produit afin de l’imposer plus facilement à ses petits camarades.

On a le droit de penser autrement, de réfléchir par soi-même et décider non pas d’intégrer un « administratif » du processus dans l’équipe de développement mais de s’intégrer soi-même dans l’équipe de gestion, ce que j’ai toujours fait. C’est d’autant plus facile que la problématique est en grande difficulté et que l’on est le seul développeur. Le développeur devient alors l’homme providentiel et les administratifs sont tout acquis. Il suffit de vivre la problématique avec les gestionnaires, de regarder, d’écouter… de savoir parler à l’oreille des gestionnaires. Tout est là, devant nous. Il n’est même pas nécessaire de poser des questions. La plupart du temps, les gestionnaires sont des femmes, elles ont mille choses à assumer dans leur journée de mère de famille. Pour assumer leur travail au quotidien, elles savent s’organiser, optimiser leurs tâches. Il y a beaucoup de non-dits dans leur activité et bien souvent, elles ne savent pas qu’elles savent. C’est en étant au plus près des gestionnaires que l’on décèle leur mode de fonctionnement. Il ne reste au développeur qu’à traduire, à structurer leur démarche avec ses outils, sa compétence, son vocabulaire.

Dans cette approche du développement, le responsable de l’entité administrative n’apporte pas grand-chose car il vit une autre réalité. Il connaît les règles de gestion de son entité mais il ignore comment ses gestionnaires les mettent en œuvre. Ce n’est pas un reproche, ce n’est tout simplement pas son rôle. Et la meilleure preuve, c’est qu’il ne s’intéresse pas du tout au logiciel en cours d’élaboration et qu’il serait donc bien incapable de remplacer un(e) de ses gestionnaires si cela s’avérait nécessaire.

Au quotidien, les gestionnaires travaillent sous la contrainte de leurs horaires à respecter, du rendement à produire et de la pression hiérarchique. C’est le soir, à la fin de leur journée que l’on apprend le plus. Libéré(e)s de leur entrave journalière, les gestionnaires se livrent facilement, émettent leurs idées, leurs souhaits. Ce moment privilégié dure très peu de temps, le temps de s’habiller, 5-10 minutes, un quart d’heure, car il faut aller chercher les enfants, faire quelques courses, acheter le pain.

C’est là qu’il ne faut pas les décevoir. Quitte à y passer la nuit, réaliser un état qu’ils ou elles trouveront le lendemain matin sur le coin de leur bureau permet de gagner leur confiance.

Par ailleurs, l’utilisateur (responsable de l’entité hiérarchique) s'attarde souvent après le départ de ses gestionnaires pour régler sereinement ce qu’il n’a pas eu le temps de faire dans la journée. C’est là aussi un moment privilégié pour communiquer.

Si le développeur reste dans son entité informatique et quitte lui-même son poste à l’heure officielle c’est sûr qu’il passe à côté d’informations essentielles.

Anecdote : Le responsable d’une entité que j’informatisais (en live) m’a avoué s’être inquiété que je ne lui pose aucune question et que je m’intéresse davantage à ses gestionnaires qu’à lui-même. Finalement, comme tout se passait bien, il a décidé de laissé faire.

Un des problèmes récurrents, c’est que le chef de projet ne s’adresse qu’au responsable de l’entité administrative (hiérarchie oblige), lequel très souvent ne voit ses gestionnaires qu’en termes d’horaires à respecter et de gestion de leurs congés.

Anecdote : Un soir, bien après le départ de ses gestionnaires, je surprends ce responsable en train de calculer des moyennes en regard de chaque ligne d’une liste. Assez pressé ce soir-là, il s’apprêtait à partir pour terminer chez lui. Je lui fais alors remarquer que ce qu’il est en train de calculer, un ordinateur le fait très bien. Me voyant m’investir énormément dans le développement de son application, il ne voulait pas me solliciter davantage. Une demi-heure plus tard, je lui sortais le même état avec ses moyennes.

Maintenant, chacun voit les choses à sa façon…

… C’était histoire de faire entendre une voix différente. Vous pouvez reprendre vos activités normales… Cahier à décharges, users stories, backlogs, tests unitaires, etc.

[Saverok]

@IFA2377

Si je comprends bien ton message, tu dis que c'est aux développeurs de se mettre au niveau / à la place des gestionnaires et pas l'inverse.
Sur ce sujet, je suis plutôt d'accord.
Le dev est au service du métier et de ce fait, c'est au dev de comprendre le métier et non l'inverse
Jusque là, on est d'accord

Ensuite, sur le meilleurs moment pour avoir l'attention des gestionnaire : la fin de journée
Là, j’émets plus de doute car comme tu le dis, si ce sont des femmes, elles ont plein d'obligations perso (une seconde journée à enchaîner après la journée de travail) et là, la plupart des femmes se ressemblent : elles sont en retard
Tu coup, elles sont pressées de partir et c'est à mon sens l'un des pires moments pour avoir leur attention...

A mon sens, et par expérience, les meilleurs moments sont les instants off : machine à café, resto le midi, sport (midi ou soir), pot, etc.
Là, on parle plus librement et les infos les plus utiles s'obtiennent plus facilement.

Pour finir, là où je ne suis pas du tout d'accord avec toi c'est sur les heures sup
En quoi un développeur devrait bosser en plus ? voir carrément la nuit ? alors qu'on est même pas en phase critique du planning ?
Faut pousser non plus
Etre au service du métier ne signifie pas être à la solde du métier
La nuance est de taille
Si tu acquières une demande en fin de soirée, son traitement peut attendre le lendemain matin et le gestionnaire l'aura en cours de journée voir le lendemain et il n'y aura pas mort d'homme
Ce qui compte pour gagner la confiance : c'est l'écoute et la prise en compte des demandes
Et prendre en compte une demande ne signifie pas la traiter dans l'urgence et la précipitation
Si on commence à taffer la nuit pour répondre à une demande effectuée à 18h00, on ne va pas s'en sortir
Comme tu le dis, les gestionnaire ont une vie après le bureau, les développeurs aussi

[Invité]

Les meilleurs moments sont les instants off : machine à café, resto le midi, sport (midi ou soir), pot, etc.

Dans ces moments-là, on n’est pas dans le sujet et chacun reste dans sa bulle confort. Les informaticiens vivent entre eux et les administratifs également. Dans un même bureau d’informaticiens, je me suis aperçu que chaque collègue ignorait ce que faisaient les autres. Bertrand PICCARD dirait qu’informaticiens et administratifs ne vivent pas à la même altitude.

Mon propos n’a rien de théorique, c’est 35 ans de vécu. La richesse est dans la diversité, je ne cherche pas à imposer quoi que ce soit, je raconte ma démarche et il appartient à chacun de s'en inspirer ou non pour se construire.

Je ne suis pas du tout d'accord avec toi sur les heures sup. En quoi un développeur devrait bosser en plus ? Voire carrément la nuit ? Alors que l'on n’est même pas en phase critique du planning ?

Je ne dis pas « Il faut » je dis « Je fais comme ça mais chacun voit les choses à sa façon… ». J’exprime seulement un autre point de vue, celui d’un développeur fonctionnaire qui n’a pas connu le RTT et qui a préféré vivre une vie plus palpitante qu’une vie de fonctionnaire.

C’était une partie du prix à payer pour préserver ma liberté, pour survivre... et aller au bout de ma démarche idéaliste. Cela fait bientôt 8 ans que je suis à la retraite et je suis toujours en train d'essayer de comprendre, d'expliquer comment j'ai fonctionné.

… phase critique du planning

De quel planning parles-tu ? Je n’ai jamais eu besoin de planning. Il y a des mots comme ça auxquels je suis allergique, planning, horaires, réunions, cahier des charges, users stories, tests unitaires…

Je ne travaille pas comme ça. Je t’explique… Je cherche une situation la plus critique possible, le genre de situation pour laquelle il n’y a plus d’espoir, à la limite de fermer la boutique, j’approche tranquillement la problématique sans m’imposer, je cherche à savoir si les administratifs sont mûrs et valent le coup. Si c’est le cas, mon approche est plus insistante et quand ça se passe bien on tope là ! Le temps d’installer un serveur, une imprimante, quelques postes de travail et trois jours plus tard, les gestionnaires saisissent. C’est tout… mais quand même pas si simple. Un informaticien qui s’installe dans un service administratif, ce n’est pas prévu. Humainement, ce n’est déjà pas évident, mais il faut trouver l’espace et aménager cet espace. Pour l’équipement, je trouve ce qu’il faut sur le trottoir, le jour des encombrants ; quant à l’espace, je me suis aperçu qu’en 35 ans de carrière, je n’ai jamais « habité » un bureau normal, avec une fenêtre normale, une porte normale donnant sur un couloir normal. J’ai réalisé ça en cherchant les principes communs à tous mes développements.

Pour vivre ces expériences, je n’ai pas hésité à changer de structure, à changer d’administration, à passer des concours, à vivre à 200 km de ma famille… ce qui m’a d’ailleurs valu une pétition de mes enfants.

J’explique tout ça dans une sorte d’étude que j’ai proposée quelque part dans une discussion mais ça n’a intéressé personne… Pas grave, je l’ai remise dans mon ordinateur !

Ma chanson leur a pas plu, n'en parlons plus...

[Saverok]

@IFA2377
De ce que je comprends, tu as été une sorte de fonctionnaire freelance
Ta situation a été très particulière et je ne suis pas sûr que tu as dû avoir beaucoup de collègues dans le même cas que toi
Tu as eu la chance d'être une exception au sein des administrations

Dans le privé, c'est très rare.
On est missionné pour quelque chose de précis.
On ne décide pas unilatéralement de ce que l'on veut faire.

Je suis CP Technique de plateformes web.
Avec mon équipe, nous sommes force de proposition mais on n'effectue jamais rien sans l'aval du client. Validation du client que l'on aura qu'après avoir présenté un chiffrage ainsi qu'un ROI.
On ne fait rien sans le facturer au client.
Ca limite pas mal les choses.

Ensuite, tu sembles avoir travaillé en solo.
En équipe, on est contraint de se coordonner tant au niveau d'un planning que de spécifications fonctionnelles et techniques, etc.
Chacun ne peux pas faire son truc dans son coin et serrer les fesses quand on va mettre les trucs en commun et constater qu'il en manque la moitié ou que pas une seule interface n'est commune ou qu'il y a eu des fonctionnalités développées plusieurs fois, etc.

Ton cas semble assez unique.
Ce que tu as mis en place ne semble pas pouvoir se faire pour la plupart des développeurs, y compris fonctionnaires.

[Invité]

Désolé de mon manque de réactivité...

Entre temps, j'ai créé un site internet et revisité un texte sur ma démarche, que j'avais un peu abandonné.

Tu as été une sorte de fonctionnaire freelance. Dans le privé, c'est très rare. ?

Un électron libre, tout-à-fait. J’ai rencontré un enseignant à l’IUT, lui-même un vrai freelance ; il donnait des cours à l’IUT pour pouvoir le mettre sur sa carte de visite. Nous nous sommes parfaitement compris. J’ai fait un IUT à 34 ans pour savoir ce qu’il s’y disait ; quand j’ai commencé, les DUT n’existaient pas. J’ai donc su ce que l’on y enseignait mais je n’ai pas changé pour autant ma façon de développer. J’ai expliqué à l’un des enseignants comment je fonctionnais. Habituellement très loquace, il n’a rien dit, pas un mot.

Tu as eu la chance d'être une exception au sein des administrations.

Cela n’a rien à voir avec la chance. C’est ma vie, c’est moi qui prends les risques, c’est moi qui m’investis, donc c’est moi qui décide comment je m’y prends. Ça fonctionne tant que tout le monde y trouve son compte. Au début, on n’y croit pas et on m’attend au coin du bois, et puis ça marche. Ça reste cependant fragile car l’histoire se termine toujours mal. L’utilisateur baisse la garde, n’investit plus, ne s’investit plus, et la situation se dégrade. On passe insensiblement de l’autre côté de la courbe de Gauss. Il m’appartient de comprendre le message et de reprendre mon bâton de pèlerin. Tant pis pour lui. C’est tout l’intérêt d’être fonctionnaire. On garde le même patron, l’état, et on peut bouger. Le seul risque, c’est une perte de confort parce que l’on repart à zéro mais cela m’indiffère, je ne m’installe jamais. Je n’ai jamais mis la photo de ma famille sur mon bureau. Par contre dans ma courte période « responsable informatique », j’avais un bocal avec deux poissons rouges. Ça détendait l’atmosphère dans mes rapports avec les administratifs rétifs à l’informatique. De retour au développement, j’ai conservé le bocal mais j’ai remplacé les poissons rouges par des friandises de toute sorte. Ce fut un attrape-gestionnaires fabuleux.

Avec ma démarche, sur le plan financier, parfois je gagnais, parfois je perdais. L’important, c’était d’aller au bout de ma démarche ; comme je l’ai dit dans une discussion, l’important était de découvrir ce qu’il y avait de l’autre côté du miroir. Je n’y suis pas vraiment parvenu car le but ultime eut été de tout redévelopper de façon classique mais sans effet tunnel, en toute sérénité, avec les moyens du moment, par une équipe s’appuyant sur l’application existante faisant office de cahier des charges.

Mes applications ayant été remplacées par d’autres, développées classiquement, il eut été intéressant de comparer les fonctionnalités. Ce que je sais, c’est que désormais une demande d’aménagement, quand elle a une chance d’aboutir demande minimum deux ans quand je réglais le problème par téléphone dans l’instant. Ce que je sais aussi, c’est que les gestionnaires n’en peuvent plus de cliquer, ils cliquent, ils cliquent. Je sais également que les fonctionnalités non prises en compte ont été développées localement. Je sais surtout, que l’excellente ambiance que j’avais su créer a complètement disparu, les gestionnaires ne communiquent plus et s’enferment dans leur bureau.

Ce que j’ai pu faire dans une structure qui ne peut pas être plus rigide, plus administrative que l’administration (la maison des fous disaient Goscinny et Uderzo), qu’est-ce qui empêche le privé de le faire, de le décider, de l’organiser ? En m’intéressant à l’Agile, j’ai découvert lors de la Journée Agile 2011 de Bruxelles un intervenant qui proposait une conférence intitulée « L’adhocratie va-t-elle sauver le monde ? ». Le privé aurait-il enfin compris ?

[B]Description de sa session :[/B] L'élément le plus flexible contrôle le système - et si l'entreprise s'organisait pour injecter dans son ADN (valeurs, vision, attitudes, compétences, ...) les ingrédients nécessaires pour constamment être en phase avec un environnement économique, humain, technologique, social... en changement perpétuel... Comment l'entreprise pourrait être sûre d'avoir cette agilité pour concentrer ses forces sur les sujets du moment qui font du sens pour elle et son écosystème... qui lui permettront de traverser n'importe quelle crise et d'en tirer une force concurrentielle supplémentaire... Est-ce un pur fantasme ? Existe-t-il une configuration d'entreprise qui soit désignée pour fonctionner de manière ad hoc perpétuellement ? Qui a comme culture d'entreprise la gestion de l'exception ? Qui plus elle traverse des changements, plus elle se renforce ? L'adhocratie serait-elle la configuration ultime de l'entreprise agile ? Est-ce LA structure de la génération Y ?

Ce conférencier a participé à monter une des premières entreprises agiles appelée "adhocratie" en Belgique. Je suis bien sûr allé voir ce qu’il en était. En fait, la démarche de son entreprise était aussi structurée que peut l’être n’importe qu’elle méthode dite agile… Rien à voir avec l’adhocratie. Déception ! Je n’ai pas jugé bon de conserver l’information et je ne la retrouve pas sur internet.

Ce que je peux dire, c’est que j’ai résolu la quadrature du cercle et que j’ai vécu une aventure professionnelle captivante qui a duré 35 ans.

Tu sembles avoir travaillé en solo.

Oui, sauf une fois… mais ça n’a duré que 3 jours. Le quatrième jour, je n’ai pas revu mon collègue et je n’ai jamais su pourquoi il m’avait lâchement abandonné. Il ne devait pas être évident quand on n’a pas fait ma démarche, de démarrer un développement qui allait atteindre 1.650.000 lignes et se terminer 17 ans plus tard.

Je ne le savais pas encore mais neuf mois plus tard, les circonstances ont fait que j’allais être amené à développer en parallèle une deuxième application de 1.400.000 lignes, toujours en solo et sur une période de 15 ans.

Les gestionnaires me voyant travailler « la tête dans le guidon » me demandaient « pourquoi ne prenez-vous pas quelqu’un avec vous ? » Je leur ai répondu : « Picasso aussi travaillait comme un fou, aurions-nous pu lui proposer de prendre quelqu’un pour l’aider. » Ce qui n’est pas encore développé n’existant pas, les gestionnaires s’en passent quant-à ce qui va l’être, c’est en gestation dans ma tête, je ne l’ai pas encore inventé.

Peut-on imaginer ma démarche à plusieurs ? Je me suis posé la question. Pour y répondre il eut fallu vivre l’expérience, je pense.

Cela dit, avant de développer des applications, j’ai commencé par une période programmation… sans jamais faire partie officiellement d’une équipe de développement.

Dès le départ, j’ai travaillé en électron libre. Curieusement, les chefs de projets ne me sollicitaient pas, sans doute parce qu’ils m’avaient connus auparavant opérateur-pupitreur. Quand ils rencontraient un problème apparemment insoluble, je leur disais : « si vous voulez, je veux bien le faire, votre programme » ou « si vous voulez je peux vous aider ». Acculés, ils n’avaient alors rien à perdre et je résolvais leurs problèmes. J’ai papillonné comme ça d’application en application pendant quelques années jusqu’au jour où un collègue avant de partir m’a suggéré, si je le pouvais, d’aider un service de gestion. Lui-même n’en avait pas eu le temps et selon lui, ils valaient vraiment le coup. J’ai commencé par un énorme programme qui est devenu sans que je m’en aperçoive, une application. Deux mois seulement après notre premier contact, les gestionnaires utilisaient l'application. A partir de là, créer une application sans étude préalable, sans cahier des charges, dans l’instant, ne m’a plus jamais posé de problème.

Ton cas semble assez unique.

Dans ce contexte (développements tout ce qu’il y a d’officiels) et à ce niveau, c’est possible. Sinon, les développements « non officiels » sont légion, on appelle ça de la perruque, je crois.

Ce que tu as mis en place ne semble pas pouvoir se faire pour la plupart des développeurs, y compris fonctionnaires.

Ils ne savaient pas que c’était impossible, alors ils l’ont fait - Mark Twain

Je ne propose pas d’être imité. Je dis seulement, voilà ce que j’ai fait et ça marche. Si ma démarche inspire quelqu’un, à lui de l’adapter, de se l’approprier.

Un jour, je vois arriver une collègue de ma première administration qui cherchait un point de chute car sa (notre) sous-direction informatique était sur le point de disparaître de l’organigramme. J’avais senti le vent et j’avais pris les devants en changeant d’administration. Je lui ai dit, tu fais comme moi, tu montes dans les étages, tu ouvres n’importe qu’elle porte, dans le bureau tu vas trouver des gestionnaires cernées par des armoires débordantes de dossiers. Tu mets un écran-clavier sur chaque bureau, une imprimante dans un coin et tu développes. Elle est repartie avec sa déprime et je ne l’ai jamais revue.

C’est avec elle que j’ai écrit mon premier programme. Je m’étais installé dans un bureau où il y avait de la place, personne ne s’occupait de moi. Et puis un jour, le chef de projet de l’équipe de développement dans laquelle je m’étais en quelque sorte immiscé, interpelle l’équipe pour dire que tout va mal, le programme principal, la mise-à-jour, n’est toujours pas opérationnel après trois tentatives d’écriture. Que fait-on ? On arrête tout et on dit aux gestionnaires qu’ils peuvent continuer manuellement ? J’avais 23 ans et deux stages de formation chez le constructeur, COBOL et LCP. Je me suis alors manifesté en disant : si vous voulez, je veux bien la faire votre mise-à-jour. Et ma collègue a surenchéri en disant : si tu fais la programmation, je te fais l’analyse. Deux mois après, le programme tournait. Quatorze ans plus tard, un collègue est venu me voir pour me dire : ça y est, je viens d’arrêter ton programme. Comme je l’ai dit précédemment, j’ai récidivé ce genre d’interventions au pied levé et en électron libre, sans jamais faire partie officiellement d’une équipe de développement.

Mai 68

Intronisé programmeur début 71, l’esprit 68 perdurait. C’est ainsi que les collègues analystes et programmeurs se réunissaient une à deux fois par semaine dans un couloir pour échanger sur leurs méthodes de travail. Novice livré à moi-même, je participais à ces réunions en auditeur libre, en quelque sorte. Les discussions animées condamnaient invariablement le cloisonnement des tâches, responsable selon eux de tous les problèmes. De fait, les chefs de projets donnaient leurs cahiers des charges aux analystes, qui donnaient leurs analyses aux programmeurs.

C’est dans ce contexte que j’ai décidé deux choses :

1. m’approprier les développements, c’est-à-dire être le seul responsable. Pas de dilution des responsabilités, s’il y a un problème, j’en suis le seul responsable.
   
2. me rapprocher le plus possible de l’utilisateur pour avoir l’information à sa source.

Ces deux décisions ont ainsi toujours balisé mon parcours professionnel.

C'est tout pour aujourd'hui !