Reprise du message précédent :
up

quelqu'un a expérimenté ces techniques récemment ?

Perso, je ne suis pas fan du tout. Je trouve que la ou les méthodes (scrum, lean, ...) vantent un gain de productivité, alors que dans la réalité c'est le plus souvent du gros BullShit et une perte de temps dramatique.  C'est le contrôle par la division du travail et l'infantilisation des ingénieurs. Bref ce sont des méthodes de contremaitres "rebrandées".

Au final, de par mes précedentes expériences j'ai pu voir que le gain apporté est nul ou quasi-nul. Par contre, cela tue dans l'oeuf la motivation des équipes et le gain en compétences des gens, avec toute la bureaucratie qui va avec (morning meetings interminables et sans aucun interêt, process débiles avec jeu de cartes, sprints qui peuvent être déprimants sur la longueur, etc).

Qu'en pensez vous ? Ces méthodes ont tendances à se démocratiser par effet de mode ces derniers temps, mais bon ... est-ce bien UTILE à un quelconque niveau, autre que celui de tirer vers le bas la R&D, de faire confiance davantage aux process qu'aux hommes, et de remplir les poches des formateurs ?

Si je reformule un peu ta question c'est "Est ce bien utile d'implémenter une méthodologie n'importe comment en faisant n'importe quoi et en ne respectant pas la philosophie initaile du bousin" , je me trompe ?

in_your_phion > votre remarque tend dans une direction que j'ai déjà constaté. Les crises de réunionite aiguë, les certification pipo et branlo, etc. sont autant de choses qui découlent du mal être actuel de l'ensemble de notre économie.
=> On ne veut tellement plus courir le moindre risque qu'on n'ose plus rien faire. Et le peut qu'on fait, le client va tout faire pour prouver que tu l'as mal fait.

Résultat, effectivement, y'a quelques têtes "pensantes" (qui chient dans leur froc en fait) qui mettent ceinture/bretelle/air bag et veulent que leurs équipes passent plus de temps à faire des rapports d'activité, des tâches asphyxiantes et autres pertes de temps qu'à travailler efficacement, et surtout pas réfléchir (au cas où ils pensent à une solution différente qui pourrait remettre en cause l'ensemble de l'équilibre de l'univers établi).

=> Change de boîte. Tu bosses dans une entreprise qui est (rayer la ou les mentions inutiles) :
- bouffée par ses actionnaires
- bouffée par ses dettes
- bouffée par ses chefs bureaucrates et financiers qui n'ont aucune idée du métier de l'entreprise

Voilà. Après, est-ce que l'herbe sera vraiment plus verte dans le pré d'à côté, c'est une promesse que je ne peux te faire. Par temps de crise, tout le monde a tendance à évoluer dans cette direction malheureusement.

Cependant, cela n'a rien à voir avec les méthodes elles-mêmes, qui, lorsqu'elles sont utilisées dans de bonnes conditions, s'avèrent être un atout de taille pour appréhender plus facilement des projets de grande taille.

Cependant, ces méthodes sont avant tout de l'encre sur du papier : à moins d'être franchement débile, personne ne s'amuse à fabriquer le toi avant les murs. Ben le développement c'est pareil : Les murs avant le toit. Le toit avant l'électricité. Etc.
Ce que je veux dire par là, c'est qu'elles donnent un cadre à une démarche implicite.

Bien résumé C'est en gros la réflexion que je me suis faite en lisant le post de in_your_phion.
 
J'ai pu constaté que certains pensaient faire de la méthode agile parce qu'ils le prétendaient et avaient mis en place 2-3 trucs qu'ils avaient lu ou entendu sur une méthode agile; et en plus, ça fait "tendance" qu'on fait de l'agile, bon pour le marketing auprès des clients (qui bien souvent, n'ont pas compris ce que c'était et les impacts sur leurs propres méthodes de travail ).  
 
Les méthodes agiles, en général, c'est un peu tout ou rien. Soit tu la fais complètement soit ce que tu fais n'est pas de l'agile. C'est que c'est forcément pas bien, mais c'est pas une méthode agile.
 
Un des avantages des méthodes agiles, c'est d'éviter (ou en tout cas limité) l'effet "tunnel" qu'on a avec un cycle en V, en particulier sur un gros projet (ie > 1 an). Comme on dit, "petit écart au début, grand écart à l'arrivée". Quand un écart est détecté rapidement, c'est plus facile et moins coûteux de le corriger que lorsque c'est vu à la fin. Bien souvent, là, c'est trop tard ou compliqué  

+1

+1
 
J'ai personnellement vécu l'expérience d'une boite qui voulait à tout pris devenir agile. Mais l'application d'outils "parce qu'ils sont agiles", la formalisation à tout pris, des métriques, des décideurs têtus, et bien des choses ont rendus finalement la société bien plus rigide qu'elle ne l'était au départ.

bonjour,
D'après vous comment lutter contre les dérapages suivants:
- estimations de charges : "mettre le titre en rouge, 1 journée" "implémenter la centrale nucléaire, 1 journée". les deux coexistant sans rire. Quelle granularité choisir?
- standup meeting quotitien qui devient une pause café?

C'est vrai que pour l'estimation de charge, c'est pas évident. Pour ma part, je fonctionne beaucoup au retour d'expérience : on me file un truc à implémenter, j'essaye de trouver un truc que j'ai déjà développé qui s'en rapproche le plus (ou alors la combinaison de plusieurs trucs déjà développés) dont je connais la charge et je fais mon estimation par comparaison et approximation.
 
Mais le principal problème des dérapages vient souvent de spécs pas assez détaillées pour lever toute ambiguïté ou interprétation.
Ex : je veux un logiciel web de help-desk pour gérer mon tickets, ces tickets ayant un cycle de vie.
 
En réponse, on va avoir des chiffrages ayant un rapport allant de 1 à 10. Le soft répondant à ce besoin peut aller de la simple petit appli php écrite en 15j à un soft comme Astres qui en a nécessité une bonne centaine (juste pour le module de help-desk). Les 2 chiffrages sont corrects mais à l'arrivée, y'en a un qui fait beaucoup plus de choses et est beaucoup plus puissant et flexible. Mais est-ce dont le client avait réellement besoin ? Peut-être que oui, peut-être que non.
 
Conclusion : plus les spécs vont descendre dans le détail (le diable se coche toujours dedans ), plus on aura de chance d'avoir un chiffrage réaliste.
 
Après, ça dépend aussi des compétences des développeurs. Un bon ira généralement plus vite qu'un mauvais pour produire le résultat escompté. Faire un chiffrage réaliste implique donc également de bien connaître les membres de l'équipe de dév qui réalisera le soft. Si c'est pas le cas, ben estimation "à la louche"

 
Déjà, t'es sensé (pour Scrum en tout cas) estimer sur une échelle abstraite, Story Point par exemple.
Là dessus je tente une approche par l'outil. Sur un ticket, je saisi l'estimation initiale en SP. Quand un ticket est pris / terminé, la durée effective de travail est mise à jour.
 
On se sert de l'outil comme d'un REX facilement accessible. Les tickets sont taggés par catégorie, donc si j'ai un doute sur une estim (le cas que tu évoques), je prend l'outil comme référence dans nos discussion. Ça ne doit en aucun cas devenir une référence qui dicte les estimations, mais plus une base concrète pour étayer nos réflexions.
 
Là dessus les tag / catégories aident beaucoup, on s'aperçoit que les différences d'estimation sont très liées à certaines par exemple (UI et intégrations sont souvent sous estimées par exemple, du moins chez nous). On ne cherche donc les REX que des tickets appartenant à la catégorie sur laquelle on réalise l'estimation discutée.
 

Question : est-ce que certains parmi vous ont pu appliquer une méthode agile style Scrum dans le cadre d'un marché public (réponse à appel d'offre) ?
 
Parce qu'en lisant la description de la méthode SCRUM et la méthode d'estimation de la charge style story point, ça me paraît peut compatible avec le fonctionnement des marchés publiques Par ailleurs, le client (administration publique / grosse boîte) est rarement structuré pour appliquer une méthode agile (poids de la hiérarchie, par ex, système Qualité bien lourd...) et souvent pas franchement aussi dispo que les dévs le souhaiteraient.
 
Qu'en dites-vous ?

Pour travailler dans ce domaine (gros projet pour des marchés publics), au sein d'industries ayant essayer d'appliquer des méthodes agiles, je confirme : c'est extrêmement compliqué.
 
Mais pas impossible. A l'heure actuelle, le client du projet pour lequel je travail est un gros marché public, et pour le coup, bien que ce ne soit pas évident, on a réussi à mettre en oeuvre quelque chose d'assez agile du point de vue de ce client.
 
C'est pas aussi agile que ça le pourrait, et pas agile du tout d'un point de vue d'un puriste, mais c'est le plus agile des marchés publics que j'ai pu voir jusqu'ici
 
Ceci dit, dans mon cas, ce ne sont pas les clients les plus difficiles à rendre agile, mais les industriels qui ont dû développer ces projets. Ils ont voulu appliquer de telles méthodes sans les comprendre. Sans remise en question autre que les développeurs. Sans modification des méthodes de travail des autres postes autres que les développeurs. Bref, c'est du grand n'importe quoi, et c'est pas la faute des clients.

Mais du coup, pour le chiffrage (ie le prix) donné en réponse à l'appel d'offre, tu es obligé de donner une charge h/j et un prix, non ? Tu peux pas appliquer le story point j'imagine

Tiens c'est rigolo que tu demandes où c'est applicable ou pas.
J'ai eu une réunion récemment où quelqu'un est venu présenter les méthodes agiles.
Il y a eu une question qui était de savoir si ça pouvait s'appliquer partout.
 
Je me permets de donner la réponse qui a été faite, que j'ai trouvé très bonne
 
incertitude sur la maitrise de la partie métier
^
|
|(agile)     (fuyez)
|
|(cycle en V) (agile)
----------------->
                        incertitude sur la maitrise de la partie informatique
 
 
 
Pour un précédent projet j'ai mixé cycle en V et agile, en ajoutant des sprints dans le cycle en V

Si je comprends ton graphique, quand y'a peu d'incertitudes sur la partie métier ET la partie informatique, faut prendre le cycle en V. Si y'a une incertitude sur l'une ou l'autre des parties, faut prendre la méthode agile. par contre, si y'a de l'incertitude sur les 2 partie, faut pas faire le projet, c'est ça ?
 
Je suis un peu étonné que seul soit prix en compte l'aspect "risques". Le facteur délai/coût ne semble pas pris en compte. Or, le cycle en V induisant souvent un effet tunnel, ça engendre souvent une élongation du délai et donc, en général, du coût
 
J'imagine que l'adéquation entre ce qui était attendu par le client et ce qui a été livré est inclus dans les risques (ce que tu as appelé "incertitude" ) ?

Voilà
 
En fait, pour l'appel d'offre, le chiffrage est réalisé "à l'ancienne", ça ça ne change pas.
Après par contre, au cours du déroulement du projet, d'un point de vue du dev tu peux fonctionner en story point (ceci dit je n'ai encore pas vu un industriel réussir à se défaire d'une charge en j/h. Le premier truc qui a été mis en place ça a été une échelle de correspondance story point / jour-homme    )
 
Dans la théorie ceci dit, je suis encore persuadé qu'avec une bonne équipe, une entreprise qui veux vraiment essayer de bout en bout, en faisant en sorte que toute la chaîne joue le jeu, et se sente concerné, je suis sûr que c'est possible.
 
Mais bon, c'est un changement énorme, c'est super difficile.
 
http://blog.mageekbox.net/?post/20 [...] prit-agile : je trouve que ça correspond tout à fait à ce que j'ai pu voir jusqu'ici.
 
De mon expérience, pour des projets à appel d'offre avec une organisation réfractaire au changement, je pense que le cycle en V est plus sûr.
Avec une organisation motivée, et prête, réellement, à devenir agile d'un bout à l'autre de la chaîne, alors pourquoi pas, mais alors il ne faut pas faire les choses à moitié sinon c'est droit dans le mur : ça devient du waterfall itératif, et le leit-motiv "amélioration continue" passe malheureusement trop vite à la trappe.

 
C'est à peu près comme ça que j'avais compris sa réponse.
Mon avis c'est que s'il y a incertitude sur les deux points, faut commencer par une embauche ou s'abstenir.
 

Excellent article, merci
Malheureusement, ça résume bien ce que j'avais comme impression quand j'ai lu l'article concernant SCRUM sur Wikipedia. Je me suis dit : "jamais la hiérarchie acceptera ce genre de méthode beaucoup trop bouleversante en terme de méthodologie de travail, mais surtout en terme de changement de méthode de management. L'entreprise, contrairement à ce que les responsables affirment tous, n'incite pas à travailler en coopération, mais au contraire à travailler de manière individuelle, ce qui est fort dommage. J'en ai encore eu une illustration y'a 2-3 jours lors d'une réunion de notre nouvelle équipe de responsables qui nous présentait leur réorganisation (bien la 3ème en 3 ans ). Tout ce qui a été présenté était dans une vision haut vers bas
Y'en a bien un qui a posé une question au sujet de la vision du bas vers le haut. Le chef a répondu avec une vision haut vers bas : il ne comprenait pas le sens de la question. On a dû s'y reprendre à 3 fois pour qu'il finisse par comprendre, mais al réponse était toujours aussi nébuleuse et inappropriée...

Hello
Flag dans le topic -   ayant besoin de conseils :
 
 
 
Point 1 :
Avez vous un retour d experience sur la methode agile specialement sur la partie specifications. Type de Specs etc..
 
J ai un de mes CDP qui ne fonctionne qu en methode V donc besoin d'aller dans la Specs detaillée pour lancer le codage...
 
Je tente de lui expliquer qu"en agile en tant que PO il doit partager la vision et la fonction attendu avec l equipe de dev  et que justement la creation du produit se fait au fil de l eau .
Pour ma part j'ai l habitude de faire une specs fonctionnel avec  
Process de l'application - Scenaries  - and Mockup  
Je laisse ensuite au Team Leader Dev \ Architecte de traduite ça en back end  
 
Procedez vous differement ?
 
Second  point : Toujours sur la partie doc - comment gerez vous la documentation  apres les sprints  
Design backend,  source code etc..
Aujourd'hui j ai jira mais le bordel pour retrouver un contenu  
 
Utilisez vous les QA pour rediger une doc technique en plus de la doc de training ?
 
Merci

Déjà, un CDP qui devient PO, faut voir s'il est compatible avec ce poste.

Si tu parles de PO, c'est que tu dois être en Scrum.
Un PO, ce n'est pas quelqu'un qui ne fait que des specs. Ce rôle apporte le "Quoi" et le "Pourquoi" à l'équipe. Il consiste à
- Recueillir le besoin
- Maîtriser parfaitement ce besoin et ce qu'il induit niveau métier
- Découper ce besoin via l'écriture des User Stories
- ÊTRE DISPONIBLE POUR l'EQUIPE ! Afin de répondre à l'ensemble des questions qu'ils se poseront durant le développement le plus rapidement possible
- Savoir prioriser en définissant un ordre stricte des fonctionnalités apportant le plus de valeur à développer en fonction du besoin

S'il était CDP, une des grosses difficultés sera de lâcher le "Comment" qui est propre à l'équipe de Dev. Il n'a pas à dire ce qu'ils doivent faire, ni à les fliquer en leur attribuant des tâches comme il avait l'habitude auparavant. C'est bien l'équipe de dev qui doit être en responsable de cette partie.

Tu noteras que je n'ai pas parler d'écriture des specs. Car c'est un des 4 principes premiers du manifest agile :
- Des logiciels opérationnels plus qu’une documentation exhaustive
Ca ne veut pas dire qu'ils ne faut pas faire de documentation, contrairement aux raccourcis qu'on entend à droite à gauche. Ca pose seulement la question : "la doc ok, mais à quoi sert-elle ? Pourquoi on en a t'on besoin ?" Et c'est une fois que tu auras posé cette question avec ton PO que tu décideras ce qu'il y a réellement à faire. A titre personnel, quand je développe, je n'ai que rarement besoin de specs, je préfère aller discuter directement avec le PO pour garantir qu'on est la même vision plutôt que de faire ma propre interprétation d'une documentation écrite. La doc est donc quelque chose à réfléchir dans ton contexte projet, tout en ayant à l'esprit la valeur précédente du manifest, et surtout un de ses principes sous-jacent - La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle, afin de garder une démarche Agile et non Cycle en V.

Ce qui serait intéressant de faire c'est d'en parler avec ton CDP, de l'impliquer dans le processus de transition Agile. Qu'est ce que lui attend de son poste ? Comment est-ce qu'il comprend le rôle de PO ? Est-ce que les choses dont je viens de te décrire sont des choses qui lui plairait ? Et en fonction de ces réponses, de définir si oui ou non, il est apte à prendre ce rôle. Ce n'est pas anodin, le rôle de PO est essentiel et stratégique pour le bon devenir de ton équipe.

Autre chose que je lis dans ton paragraphe : "Team Leader Dev \ Architecte de traduite ça en back end"
Est-ce que tu penses que donner la création de l'ensemble de l'architecture à une seule personne soit ce qu'on entend par :
- Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées.
?

Pour la documentation fonctionnelle et d'architecture, j'en ai déjà parlé précédemment. Par contre pour la partie documentation des sources : rien ne vaut la documentation dans le code lui même. Et que ce code soit lui même la documentation. Je pars du principe que si mon code nécessite un commentaire, c'est certainement que ma fonction est mal nommée et/ou qu'elle réalise trop de choses et donc doit être découper en d'autres fonctions plus petites et plus compréhensibles (et pas que mais je vais pas te réécrire le livre "Clean Code" de Robert C. Martin )

Une autre piste pour tes specs seraient l'ATDD ou le BDD. Mais là je laisserais Bubul en parler une fois qu'il aura compris à quoi ça sert réellement et non juste à faire des tests avant du dev

Petite remarque sur la doc. Perso, si je devais ne garder qu'un document (pour l'équipe réalisant le soft), ce serait les spécs détaillées. En effet, dans le cas d'un logiciel métier (je pense, par ex, aux softs qu'on trouve dans le contrôle aérien, genre la visu principale des contrôleurs, la chaîne radio/téléphone, le système de traitement radar ou des plans de vol...), les exigences sont souvent très pointues et complexes. Il me semble donc approprié d'avoir un document qui trace toutes ces exigences, ces besoins, avec, dans certains cas, des diagrammes, chronogrammes pour montrer les enchaînes d'actions. Ce document doit également contenir le MCD et le dictionnaire des données si y'a une BD. Bref, ce doit être un doc de référence, une bible. Et en cas de litige contractuel avec le client, on sera bien content d'avoir ce doc à opposer pour déterminer qui a tord ou raison sur le mode de fonctionnement de telle ou telle fonction. Car si t'as pas de doc, t'es en slip et les modifs seront à tes frais et non ceux du client
 
Après, bien sûr, pour le client y'aura le manuel utilisateur. Ok pour que le code soit auto-suffisant pour la documentation. Pour le dossier de test et résultats, le développement piloté par les tes me paraît aussi auto-suffisant.

ça c'est bien joli mais ça dépend des loustics que tu as dans ton équipe, il y en a qui sont incapables de s'auto-organiser. C'est certainement qu'ils ne sont pas faits pour l'Agile, mais on a pas toujours le choix de l'équipe
Donc il faut adapter la méthode à ton équipe. Et c'est vrai pour plein d'autres trucs. La méthode agile c'est pas une recette de cuisine que tu appliques et qui va cartonner du premier coup, la méthodo elle-même doit être agile, il faut l'adapter à l'équipe, au client, pour que le projet avance et que tout le monde y trouve son compte.

Merci pour le bouquin, je regarderais
et sinon je fais du code critique, avec tout un environnement sécu et des preuves de sécurité à apporter (tout un tas de test à passer en unitaire, en hôte, cible).
Ce soft doit être certifié, et pour être certifié ont a besoin des différents éléments du cycle en V.
donc l'extreme programming là dessus, ça fait cheveu sur le soupe,  
en fait c'est hors sujet et ça apporte énormément de bruit car ça maintiens deux méthodes de développement en // et en concurrence.

si tu fais du soft certifiable ou avec un niveau de SSIL élevé, tu es plus ou moins contraint dans un cycle en V, dans pas mal de domaine du dév, car les tests sont primordiaux (ceux qui te sont interdit de réaliser, pour des questions d'indépendance, de revue de code and co).

C'est clair que dans les grandes structures, difficile de mettre le cycle en V au rebut Perso, j'essaye de combiner l'agile avec le cycle en V : en gros, pour chaque incrément de version embarque un nombre de corrections et évolutions raisonnable de manière à pas livrer dans 3 plombes et pour chaque incrément, je fais un petit cycle en V (au moins les principales étapes), histoire que le client s'y retrouve.

 
 
Super - je prends le temps de lire en details ce weekend - merci de l aide en tout cas !!

Merci pour vos retours  c'est hyper interressant !
Pour l equipe auto organisé j ai la chance d avoir une equipe de dev brillante. je faisais un petit racourci en disant le TL c est plus un  consensus de l equipe.
 
Pour le PO c est exactement ce que tu as decris - la clef est le virage de pure CDP à PO et sa faculté à partager sa vision produit pour faire adherer l equipe.
Je le vois la semaine prochaine j en discuterai de vive voix avec lui  
 
 
pour la partie Doc - je fais tout de meme une Specs Fonctionnelles  qui est plus un process operationnels style SOPs  avec des idées mockups.
 
J ai demandé à mes QA de faire la doc utilisateurs et pour certains d entre eux plus technique - je demande un peu doc technique aussi
 
Merci vraiment de vos retours c  est hyper interressant

Un des auteurs d'agile qui pète un cable et t'explique que Agile est un raté sur toute la ligne à cause des cons qui lisent le bouquin plutôt que de penser
 
http://blog.toolshed.com/2015/05/t [...] agile.html

Rien ne vaut la methode GBS !

Gros Bon Sens

Très intéressant, et complètement d'accord
 
D'ailleurs, j'en profite pour me jeter des fleurs, c'est ce que j'écrivais la semaine dernière, mais en moins argumenté

 
Pour la petite histoire, j'ai été CP/Scrum Master pendant 2 ans (jusqu'à y'a un an) sur un projet Agile pour la poste, en formant ma successeure je me suis fait à moitié incendier parce que je faisais pas les choses dans les règles de l'art. Ouais je préférais adapter la méthode à ma sauce pour avoir une équipe qui tourne et un projet qui répond aux attentes du client. J'ai eu des nouvelles récemment, le client est pas satisfait de la nouvelle Scrum master, ils sont tout le temps à la bourre sur les itérations etc...  

Comme quoi, rien vaut le bon sens. Quelque part, Scrum me fait penser à ITIL : ce n'est qu'un recueil de bonnes pratiques que chacun est libre de mettre en application en fonction du contexte dans lequel il évolue (lui et son équipe). Si on fait aps tout pile/poil ce qui est dit dans la méthode, c'est pas bien grave. Ok, on fait pas du Scrum parce qu'on a pas mis en oeuvre tel truc ou de telle manière. Mais c'est pas bien grave si au final, le produit qui en sort satisfait tout le monde, que ça marche et qu'on a globalement respecté les délais et coûts. Et tant pis pour les puristes, qu'ils aillent se faire v... ailleurs.
 
Je me souviens, lors d'une formation CP interne à ma boîte, d'une CP/Scrum master qui m'avait rétorqué que j'avais pas fait du XP parce que j'étais seul et que pour XP, fallait être au moins 2. OK. N'empêche, j'avais développé une appli de gestion de conf (Icare, cf ma signature) en 50j en faisant donc une méthode proche de XP, + du développement piloté par les tests et en ayant respecte le design pattern MVC. Or, ça faisait 4 ans que le client attendait une appli de gestion de conf basée sur une GEDT customisé pour nos besoins spécifiques et ça a jamais abouti. Le client en a eu marre d'attendre si longtemps pour rien avoir au finale. J'ai fait une appli en PHP : tout a marché du premier coup, c'était fluide et bien adapté aux besoins. Le client était très content au final
 
Edit : moi aussi, du coup, j'étais très content du résultat, surtout vu le court délai, car c'était la première fois que je testais cette façon de développer et d'avoir automatisé tous les tests (TU, TI et tests fonctionnels). Bref, très bonne expérience.

Merci de vos retours
 
Comment gerez vous le Knowledge Management des applications?
 
 
En gros pour le moment mes PO font une specs fonctionels du produit et nos devs back -end front end design la solution et attaque dans Jira.
J ai ensuite mes QA qui font une espece de recette et test et mettents en prods.
 
 
Par contre j ai encore un peu de mal à avoir une vrai DOC  -  le fonctionnel j ai  -  mais le backend , orga de BDD - middle interface etc... c est un peu limite en termes de doc -
De votre experience qui s occupe de creer ça?
 
Une fois créé une bonne page confluence me suffit

Perso, j'utilise un wiki avec des articles, chaque article ayant une petite partie ontologie/taxonomie me permettant de faire des sortes de requêtes "SQL" pour sortir des listes d'articles dans des portails (des articles particuliers servant de points d'entrées).
Dans les articles, on a une fiche signalétique (qui reprend les infos de taxonomie) puis un § "présentation", un § "particularités techniques", un § "documents indispensables" et un § "contacts" (chef de projet et autres contributeurs).
 
dans ces articles, on trouve beaucoup de liens soit sur des fichiers stockés sur le réseau soit dans une GED ou un autre outil web
 
Pour l'organisation de la BD, je mets le MCD et le MLD dans la spéc.

Ya pas vraiment de bonnes réponses possibles. Ou plutôt on pourrait t'en sortir plein, basé sur de grandes expériences et sur nos projets en succès. Sauf que ton projet n'a pas forcément les mêmes besoins en documentations que celui de ton voisin.

De ce que je vois en général sur les projets, c'est qu'on cherche à écrire plein de docs pour que tout soit consultable. Mais au final, qu'est ce qui sert vraiment ? Pas grand chose.
J'aurais tendance à conseiller de garder tes docs tel que tu les faisais avant mais tu en supprimes une. Et tu regardes si les gens s'en plaignent de plus l'avoir,  et si ça arrive de commencer juste à essayer de les faire communiquer avec son voisin ou un sachant du projet. Et si ça suffit toujours pas, la tu auras de bonnes raisons de l'écrire cette doc. Et ainsi de suite pour chaque type de doc.

Les docs techniques, je constate le plus souvent que c'est pas à jour. Vaut mieux que la doc soit le code lui même plutôt qu'un truc à côté.
Le MCD, j'aime bien l'avoir sous les yeux.
Mais ça c'est mon  cas perso

Quand on travaille sur une BD, je vois pas comment on peut faire sans le MCD et le dictionnaire de données. A mon sens, ce sont 2 docs indispensables.
 
Après, faut pas tomber dans un piège classique : la doc, c'est rarement utile à ceux qui sont sur le projet depuis son début. Ca sert surtout à ceux qui arrivent bien plus tard en cours de projet voire carrément quand tous ceux qui étaient depuis le début sont partis. Là, la doc, t'es bien content de la trouver. C'est souvent pour ça que la doc est pas à jour : ceux qui sont sur le projet ont tout (ou presque) dans la tête.
 
Conclusion : moi, je fais la doc en me mettant dans la peau de qq'un qui arrive sur le projet et qui ne le connaît pas et je me pose la question de quoi j'aurais besoin ?
 
Quand j'ai créé le wiki, c'est ce que j'ai fait et à chaque nouvel arrivant, je lui dis de consulter le wiki et après 1 à 2 mois, je lui demande de le mettre à jour pour compléter les trucs qui n'étaient plus à jour ou qui manquaient. Ainsi, on converge vers une doc plutôt bien fichue

Tout ceux du début sont partis au fur et à mesure non ? Et ceux qui les ont remplacé sont montés en compétence logiquement ?

Alors pourquoi avoir peur des connaissances de ces derniers face à ceux qui sont partis ? Ou plutôt qu'est ce qui a été mis en place autre qu'une documentation non exhaustive (car pas complètement à jour) pour préserver la compétence malgré les mouvements des équipes ?

Je soulevais juste un cas de figure et faisait remarquer que la doc que l'on produit, c'est souvent pas pour les gens actuellement sur le projet mais pour ceux qui arriveront plus tard.
 
Concernant les compétences des nouveaux arrivants, le pb n'est pas le niveau de leurs connaissances techniques mais leur manque de connaissance du contexte métier (ex : spatial, aviation civile...). Y'a tout une terminologie et des connaissances métier à acquérir. Là encore, le wiki est bien pratique.
 
Edit : mais on sort un peu du sujet, je pense... On touche plus à la gestion de la connaissance explicite.

Tu ne sors pas du sujet si tu regardes le manifest agile
 
Le wiki peut être pratique bien sur Il faut juste voir ce qu'il faut réellement écrire dedans plutôt que de vouloir forcément tout détailler (le nombre de specs au format word que j'ai vu passer... je suis bien content de pouvoir aujourd'hui trouver un PO à côté de moi pour lui poser directement les bonnes questions plutôt que de passer des heures à comprendre ce que l'AMOA a bien voulu essayer d'écrire dans ces 15 pages de description )

Bon
J ai trouvé un bon compromis
 
- Specs fonctionnelles par le PO - WORD -  on partage la vision et les attendus  
> Business Needs
> Workflow
> Exception process
> Maquettes
 
- Jira -  on dev \ on test \ on comments
> Dev et Tickets
 
- Confluence  - on consolide
> Copy / Past du Word Specs avec update des maquettes par données de production
> Les devs update l'architecture mise en place et certains codes

Petite question : pourquoi 2 supports (word + confluence) pour un même contenu ?

trucs tout bete... certains de  mes users n ont pas accès à Confluence
Grosso modo mon confluence c est copier coller de Word
mais ça peut etre aussi Export de Confluence dand Word

Au premier coller de ton doc Word complet vers Confluence, ok ça va aller.
Mais ensuite, tu crois qu'il va se passer quoi lorsqu'il y aura des mises à jour ?

 
 
bon point
Donc Confluence  puis Export ^^