Le chiffre est la pour estimer le chiffrage. Si le delta est supérieur à 25% c'est qu'il y as un probléme. Ils servent à ce dire si usuellement sa semble plausible de tenir les délai ces délai étant optimiste. Les chiffres servent aussi a pré-estimer le chiffrage sans rentré dans les détails. Il ne sert à rien de se dire on enléve une partie pour gagner du temps car si cette partie est la c'est pour gangner du temps. On test car sa permet de gagner du temps.

Les chiffre étant une estimation il suffit de multiplier par la complexité de l'us pour avoir la complexité estimé finale. Cette duré est optimiste

• US ici nous parlons d'une US simple de 1.

Comment connaitre la complexité en ammont du projet avec aucune exigence ?

• Une page demande
  • 3 jours pour le dev & 1 de (management, documentation, test) & 0.5 de design
• Un besoin demande (si elle semble):
  • Trés simple
  • Simple 2
  • Normal 3
  • Complexe 5
  • Trés complexe 13 semble extrémement simple sur le POC si sa semblé complexe il faut garder un temps qui pour le coup n'est même pas un risque. J'appelle sa un temps de dépendence et de gestion de cas. Et de mon expérience se delta arrive 100% du temps il est due au fait que la solution (attention je ne parle pas forcément d'une lib) va surement avoir des limitations que l'on ne voit pas dans le poc ou être plus complexe pour développer les trucs a coté, ou que le dev doit apprendre a jouer avec pour l'adapter, le fait que de cette complexité ce cache trés souvent des cas à gérer auquelle on ne peut pas penser avant le développement, .... Le Poc ne fait que prouvé que c'est possible il ne doit pas amené à diminuer le chiffrage c'est une erreur que l'on fait beaucoups trop.)

Le testeur teste et gére les tests. Il est impossible d'écrire tout les scénarios en avance du project. Il y auras forcément des retouches car c'est basé sur les spec (que les spec soit de vraix spec, des exigences fonctionnelles ou des US je vais parlé de spec pour simplifié) qui sont basé en trois catégorie (Les termes change celon la methodo de gestions de spec mais les grosse lignes ne change pas)

• White spec : ce sont les spec ecrite en dur (Quand l'utilisateur click sur le bouton la popup s'ouvre)
• Grey spec : ce sont des spec qui servent à gérer les oublies, les cas que l'on ne souhaite pas specifier et l'implémentation des nouvelles features. Elle permettes aussi de mieux comprendre les régles globale de l'application (Quand une opération de fond finie avec succé un toaster vert apparait contenant un message permettant clairement d'identifier la tache finie).
• Black spec : sont l'ensemble des choix technique/comportement de l'application qui ne sont pas spécifié par oublie ou par choix et qui ne peuvent être changer par habitude utilisateur. Ainsi un bug doit appartenir à une de ces trois catégorie.

Ecrire les tests (0.125 * US)

• Réfléchir au fonctionnel et essayer de trouver les manques
  • Corrigé les tests
  • Valider les test
  • Valider et ajouter les remontés du dev (Manque au exigence fonctionnelle) Management de test aux story&us&sprint (0.125 * (story&US&sprint)) Test release (1 * release) Test feature (0.125 * US)

Le PO est porteur du besoin client. Sont role est double il doit naturellement receuillir le besoin client mais se n'est pas sont role principal. Sont vraix role le plus important c'est de faire maturer le besoin client en :

• Posant des questions
• Simplifiant au maximum le processus. Il apporte les cas auquel le clients n'as pas pensé pour lui faire valider
• Shématisant les processus via wireframe pour de l'ui. Ou workflow pour des procéssus métier. Il est trés important dans tout les cas que le support soit le plus simple à monté possible peut immporte sa précision car il faut encourager le PO à les faire le plus possible hors sa prend du temps. De plus l'imprécision de ce workflow peut-être un avantage comme dans un brainstorming ou une personne peut ne pas comprendre la proposition de quelqu'un et finalement proposer une solution auquelle aucun des deux n'avait pensé. Il est aussi intéressant :
• De pré-évalluer la criticalité des taches.
• Il doit aussi s'engager le moins possible

Prise du besoin ecriture spec (0.125 * US) Ecriture exigence fonctionnel (0.125 * US)

• Reprise de chaque spec
• Analyse des cas particulier & Navette client
• Retouche remonté testeur Management des taches (0.125) Explication des tache (0.125)

Le job de chef de project et de visualisé le project dans sont intégralité via les chiffres qu'il peut avoir. Il pourras ainsi renforcer ce qui à besoin de l'être. Il est important de concidérer que la qualité de l'équipe n'influe pas sur le client si un project et bien manager. En effet l'expression la confience n'exclue pas le controle. Si on considére qu'un point est à risque pour le project on le sécurise quel que soit la situation ou notre activité. Par exemple un dev fait un push -f et suprime tout le code sur Github est la faute de l'équipe. Chaque membre doit garder contre les situations à risque (Le chef n'as pas mis en place une validation de ce point, les dev n'ont pas fait remonté le manque de protection de la branche, l'outillage manque de procédure en question ...). Ainsi quand un probléme +/- grave arrive le job du chef de project il doit avoir une methode pour valider cela sur ces futur project. Ainsi sont analyse peut-être ainsi :

• Si le nombre de retour client est trop grand
  • Ajout d'un testeur (externe au projet pour visualisé la problématique il ne faut pas qu'il connaisse le contexte)
    • Manque des spec (Le po n'as pas eu assez de temps)
    • Oublie de test (écrit) (Soit les spec ne sont pas assez claire. Soit il n'y as pas eu assez de temps sur la création des test)
    • Test oublié lors des regression(L'outillage n'est pas suffisant ou pas assez clair ou il manque une validation sur le management des tests)
    • Trop de bug retourné lors des tests donc livraison intermédiaire faite malgrés tout
      • Ajout d'un DEV (externe comme le dev)
        • Beaucoups de bug mineur orthographes/margin (Manque sur les validations des tickets au passage à valider)
        • Beaucoups de bug complexe de regressions (Qualité du code, Architecture, refactoring?, manque de comunication dev testeur pour l'ajout de test, manque d'analyse en ammont de impacts)
        • Beaucoups de bug de spec (Difficulté a comprendre les spec, Application avec beaucoups de cas particulier, Clair manque sur les validations des tickets au passage à valider)
        • Beaucoups de bug de performance/Ram (Manque d'analyse en ammont de potentiel besoin de performance) Il serait long et pas focément pertinant de finir ce tableau mais l'idée est la.

Le dev est le dernier niveau. En gros la représentation de sont job est simple. On peut voir le développement comme une succésion de découpage La spec client > groupe Tache > Tache > exigence fonctionnel > code. Il as un double role en plus de convertir les exigence en code il doit aussi aider les maillons supérieur à faire leur travail. Et ce second job est aussi important que le premier. En effet il est impossible de pensé à tout le project avant le project. Il y as deux dicton a gardé "tout bug est une décision fonctionnelle prise par le dev" et un autre dont je suis un plus d'accord "un des dev à au moins pensé une fois au bug avant qu'il soit remonté par le client". De mon expérience le second est plustôt vrais. Ainsi le dev dois trouver le moyen au cours de sont dévelloppement de se noté ces edge case quelque part pour les remonté au testeur. Pour sa il faut un organisation. Par exemple quand on pense à un groupe de cas à tester ce les marqué quelquepart en mode pense béte avant de commencer à codé. Prendre sont temps quand on code a chaque block d'instruction/methode de ce dire ou est-ce que sa peut planter. Et lors de la relecture durant le commit ou avant de demander la validation du PR. Prendre chaque changement et ecrire toutes les idées qui nous passe par la tête. A chaque question au po/testeur il se le note. Le but est de mergé toutes les infos récupéré et de les soumettre ensuite au testeur pour qu'il les ajoutes à ces exigences. Le dev n'est pas un litéraire. Il n'as pas à ecrire des exigences. Il retourne au testeur sous la forme qu'il souhaite (bien sur il faut que ce soit compréhensible). au testeur de mettre en forme. Pourquoi tout sa ? Parce que la limite du dev s'appelle la charge cognitive. Un Humain n'est pas capable de retenir beaucoups de chose en paralléle. Ainsi quand on pense à un bug on as souvent envie de le corrigé dessuite et de documenter aprés. Hors un bug en améne trés souvent un autre. On corrige alors le second et oublie le premier. Ou on pense à faire les deux mais on ne se rend pas compte d'un troisiéme car notre cervaux est occupé à pensé au premier. Il est plus important pour un humain que pour un ordinateur de vider sa memoire et d'être focus car le cervaux est fait pour ne traité qu'une chose à la fois hors en informatique il faut tout traité en une fois se qui fait que notre cervaux est poussé au limite. C'est ce principe qui fait que si vous quitté votre code une semaine ou deux et vous revenez dessus vous aller vous rendre compte de plein de truc ou vous allez vous dire "j'ai fais sa !!!!". Votre cervaux qui avant utilisé sa connaissance précise du contexte prennais de la memoire pour stocké le contexte et ignoré des parties. C'est normal c'est comme-sa qu'il s'implifie et accélére sont analyse. Mais sa veut aussi dire qu'il prend de la mémoire que vous le vouliez ou non et que vous pouvez lire 10 fois la même bétises sans vous en rendre compte (D'où le fait de faire valider sont code par un autres). Vous vous dites que si on fait pas de bug pas de probléme. Enfait pour mieux voir cela on va changer de point de vue. On va dire que tout les tache sont des bug. En effet si vous prennez un nouveau ticket et que jouer les exigences fonctionnel rien ne devrait passé. Désormais vous n'avez pas commencé a codé que vous avez des bugs. Si on prend le raisonement du paragraphe précedent maintenant vous commencer à vous attaquez au bug principal. En le corrigeant vous aurez forcément à penser à un second bug (sauf si votre tache n'as qu'une exigeance fonctionelle mais c'est rare sauf si c'est un bug à la base). Et boum vous êtes dans le cas ou vous devez pensez à deux bugs à la fois. Le Dev as une énorme responsabilté. Une application est un assemblage de millions de détails pour les plus simple. Il est plus simple d'expliquer dans le détails le fonctionnement d'un immeuble en une demi journé. Que d'expliqué comment marche une mini application dans le détails en deux semaines. Les applications actuelle parte sur le fait d'avoir des détails commune mais ceux-ci reste un choix qui ne correspondent pas forcément à notre application et qui peuvent donc être à changer. Ainsi un dev aujourd'hui ne code pas plus vite qu'il y as 20 ans (certaine etudes tende même à dire que c'est le contraire). Parcontre il as les détails définie par défault et un meilleur outillages pour l'intégration et le déploiment. Il est donc important de prendre en compte cette base car ces elle qui nous permet de gagner du temps par rapport à il y as 20 ans.

Prendre en compte le ticket Pensé et faire validé une solution Imaginé les bugs potentiel Code test (premier) Gerer le project (daily, gestion ticket, documentation) revue de code

Souvent quand tu commence dans le millieux pro il arrive que tous ceux qui t'entoure te dise "A ce que tu as apris à l'ecole sa ne marche pas en pro car tout les projets on leurs spécificité". Juste garde en tête une chose :

• L'informatique à plus de 60 ans. La POO as plus de 50 ans. L'informatique à pris le monde dans les années 90. Et la plus part des conventions qui font le management projet n'ont pas bougé depuit 20 ans et viennent de toutes ces années d'expériences.
• Les conventions n'ont pas été faites par un mec de sont coté. Mais par le principe de l'intellegence collective. Avec du try and die.
• Elles ont un seul et unique but être le plus flexible possible. Afin de faire un sorte que quand ton application évolue d'une maniére qui n'était pas prévue à la base cela continue à fonctionner.

Alors quand un mec vient te dire que pour ton projet les conventions/pattern/"connaissance scholaire générale" de base ne marche. Dite vous qu'il y as juste 99.9 pourcent de chance que le projet ce passe mal. Et je vous souhaite bonne chance. De mon experience c'est que j'ai souvent entendue cette phrase dans des projets ou justement le fais que X ne soit pas en place est le plus gros probléme. Mon exemple le plus commun est les test et les specs. On va souvent vous dire qu'il ne faut pas en faire car sa prend du temps et que du temps c'est de l'argent. Mais en fait (en particulier les test) ces deux outils existe pour gagner du temps. Alors les suprimer (ou les baclé) pour gagner du temps et plus que contre productif. C'est deux éléments vous pouvez êtres sur que dans facilement 80% pourcents des cas les avoirs de maniére ne serait-ce que eratique vous feras perdre beaucoups de temps.

Je vous conceille de ne jamais oublié ce que l'on vous as apris et de vous demander pourquoi sa ne s'applique pas à votre projet. Vous pouvez être trés agréaglement surpris sur comment les régles s'agence entres elle pour résoudre les problémes complexe et rester simple.

Il existe une phrase qui souvent est mal comprise par les dev mais qui est aussi importantes que complexe à expliqué. Cette phrase c'est "un dev ne travaille jamais seul". En gros sa veut dire qu'un dev travaille avec :

• Les prédécésseur si il y as.
• Son propre passé et on futur : Souvent quand on relis son code on as l'impression de ne pas ce reconnaitre. En effet chaque dev à ces petits truc qui sont une sorte d'emprunte. Donc documenter, aeré bref travailler proprement c'est aussi ce respecter.
• C'est succésseur : On retient la phrase "Develloppeur comme si un psychopathe qui sais où tu habite reprendras ton code"
• Son client (passé, présent et futur) : Comprendre le fonctionnel accepté de communiqué. Donner sont avis et des conceille. Peut-importe le type de projet le dev est celui qui voit la tache de la maniére la plus unitaire. Sont avis peut donc être trés intéressant. Il ne faut pas avoir peur de le retourné.
• Son Testeur : Comme pour son client

Résultat on attend au dev de communiqué réguliérement. Il faut donc être dans un environnement propice à la communication. Il faut l'encourager au maximum la simplifié, la persisté et l'indexé

Cette explication est trés complexe c'est un sujet un peut plus ressenti personel que je n'ai pas su expliquer

Deux effet agisse chez les dev. Dunning-Kruger et ce que j'appelle le [Phony noise](https://www.hanselman.com/blog/ImAPhonyAreYou.aspx). Cep qui est interressent en informatique ces que ces deux effects peuvent être combiné ce qui je trouve est assez incroyable. Cette impression de savoir ce que tu dois faire mieux que les autres, de gérer d'avoir confiance tout en te rendant compte que tu ne sais rien et que tu est un null. Je pense que seul le monde de l'informatique peut assemblé ces deux impressions au même moment. Pourquoi ? Parceque même l'action la plus simple en informatique demandé un doctora juste pour maitriser toute les subtilités. Si vous ne comprennez pas cette phrase je vais vous donnez des verités qui sont folle: - On ne peut pas définir la taille d'un dossier et on ne peut pas connaitre la taille d'un fichier. La taille donné par l'OS est une taille estimé. - La sauvegarde d'un fichier est un processus ultra complexe qui à couté des milliard à développer pendant des annés. Et pourtant il est encore loins d'être parfait et je ne parle même pas de segmentation/pagination de fichier. - Personne ne sais comment une OS marche dans le detail même pas les développeur eux même. Il y as trop d'interaction. - Faire un ctrl+Z est hyper complexe et long - Si on affiché simplement les caractéres à l'ecrand directement sans les otpimisations même le plus puissant des super calculateurs ne ferais pas tourner word.

Chacun de ces sujets semble on ne peut plus simple et pourtant ils sont on ne peut plus complexe. Chacun pourrais être des sujets des doctorats à eux tous seul tellement ils sont complexes. Et pour tant on as essayé de les simplifié pour obtenir quelque chose de simple. Et c'est sa qui fait cet effet de sur confiance. En effet quand vous prennez un project il n'ai pas rare en temps que développeur que vous metiez le client dans une situation où ses methodes de travail ne marche pas. En effet on fonctionne en utilisant une methode de travaille qui pour lui semble marchais tout le temps car dans la logique sa devrait être le cas mais en fait non. Pour donner un exemple et evite de vendre des info de mes client je vais prendre un sujet d'actu les masques.

En theorie un masque protége contre le virus c'est pour sa qu'ils ont été créer et si on réfléchit rapidement à leur fonctionnement c'est logique. Sauf que des etudes au Japon (où il est fortement utilisé) on montrés l'effet inverse. Pourquoi ? En fait c'est trés simple le masque commercial n'empéche qu'une partie des microbe de rentré. par contre il les empéchent tous de sortir. Hors le corps humain est en lutte constente avec eux. Ce qui améne le masque à devenir une soupe de bactérie et virus. Ce qui diminue drastiquement les défenses imunitaires... Pour éviter cela dans le millieux medical il change le masque trés réguliérement il est rare qu'ils en garde un plus d'une heure sauf oublie ou pénurie. De plus le masque ce remplit des particules qui ont été bloqué. Ainsi il faut aussi savoir le retirer sinon il n'auras qu'un effet néfaste.
Cela met en valeur que ce phénoméne de "c'est logique régit" comment on travaille. Sauf que quand on fait un logiciel c'est phénoméne qui sont border line remonte. Ainsi quand ton client te donne ton cahier des charges il va des fois ce rendre compte que sa méthode de travail l'impacte lui même. Le fait de devoir analyse tout ce cas commun et moins commun toute la journé et au final de conceiller le client va donner cet impression de confiance. L'idée de surconfiance viens du fait que tout les domaines sont complexe et qu'en temps que dev tu rentre tellement dans le détails du fonctionnement que tu apprend plein de choses. Mais le domaine est tellement complexe que tu va pouvoir mélanger la confiance avec l'inconfiance.

L'idée générale est que l'on as des domaines si titanesque que dire que l'on maitrise serais fou. On est tous des imposteurs qui savent plein de chose mais qui au final ne savent rien. C'est pour sa qu'il est important d'avoir des gens spécialisé. Car rien n'est simple et ce n'est pas parceque sa marche que sa marche.