Please enable JavaScript.
Coggle requires JavaScript to display documents.
No estimate, Prioriser les fonctionnalités sans faire d'estimation -…
No estimate
Aucune "méthode" préconisée
parfois tableau kanban mais pour des besoins ciblés
analyse réflexion de chacun
trop complexe pour être réduit à une méthode
inutile de montrer une méthode à un client mais des points réguliers
Client fait un backlog sans le savoir
avec les développeurs : au cas par cas, partir de l'existant
On fait avec les forces/faiblesse de l'équipes
Client/développeur placés au même niveau
Finalement aspects culturels pas méthodologiques
Rituels de feed back (rétro, livraisons, ...) OK mais pas contraints par le temps
mais aller chercher l'info du réel
Objections : comment vais-je gérer ?
Synchronisation avec une autre équipe
les deux plannings sont faux
réponse : équipes pluridisciplinaires
réponse 2 : on a rarement besoin de synchroniser. L'équipe prête la première peut être motrice par exemple
Organisation en mode projet
Projet ou l'équipe le plus important ?
si équipe KO : casse la productivité
Mode projet : Détruit cette richesse équipe
Projet = début -fin
--> pas le cas des "projets" informatiques
Utilisateurs ont besoin du projet "indéfiniment"
D'où l'importance de l'équipe
Changer un membre c'est changer l'équipe a fortiori plusieurs
Prises de décision basées sur estimations
Prise de décision sur des éléments faux (prévisions = voyance) donc inefficace
Irrationnel de les faire sur l'avenir mais pas sur le passé
Ex : prévisions de croissance de l'INSEE systématiquement fausses (pourtant on base nos politiques là dessus)
Dirigeants veulent prendre des "risques" mais basées sur les "certitudes" de la prédiction
Triangle : prix - qualité -délai
Qu'est ce qui doit être fait ?
question non posée --> problème
annonce prix-délai OK si périmètre fonctionnel variable
Fonctionnalités non figées
Le client n'est pas sûr de ce qu'il veut
Client OK si sensibilisé
Client KO : annonce forfait, si le besoin change plus de garantie sur le périmètre fonctionnel
Délai pour "éduquer" le client --> satisfaction --> ne reviendra plus sur le CdC initial
Grand classique de gestion de projet qui élude des questions essentielles
Attention :No estimate = repoussoir à prospects / peut être mal compris
Subterfuges : montrer que son besoin a évolué et c'est ce qui est important
Au final : satisfaction du client qui a l'impression que les "délais" sont respectés
No estimate n'annonce pas de délai mais le client a l'impression que les délais sont OK
Ne pas donner de date mais des points réguliers pour donner de la confiance
"Grosse maille" OK car périmètre fonctionnel variable
Appel d'offre publique
ruser sur les "UO" (unités d'œuvre)
Obligation de moyens pas de résultats
Devis : OK mais laisser une incertitude sur le périmètre fonctionnel
Estimation = défiance
Planning poker = hérésie
sprint : contresens sur agilité
mot choquant (intense, court)
alors qu'on cherche "l'indéfiniment soutenable" (boucles de rétro action, apprentissage régulier, démonstrations régulières sans prévenir à l'avance)
seul rythme OK = marche (ni marathon, ni ultra-trail surtout pas sprint)
granularité fonctionnelle non temporelle
Plus de stress : de succés en succès au lieu d'échecs liés aux estimations
Avant-vente
POC pour montrer qu'on est capable
génère la confiance
No estimate : Marche pas pour les gros projets ?
Facebook : au départ tout petit projet
On y va pas à pas (moins d'incertitudes)
Gros projets : par définition, échec annoncé car intenable (exemple Louvois)
No estimate = no conflit ?
eviter les contrat à long terme
Les conflits proviennent souvent des plannings mal ficelés
Désactive donc les conflits
Les conflits peuvent aussi provenir d'autres raisons que le planning mais ne remettent pas en cause le no estimate
Seul le no estimate permet l'efficacité (moins de temps perdu à estimer)
Zéro certification agile
certifs utiles pour valider compétences techniques
Intérêt pour l'agilité d'une certification ?
Compréhension plus importante
Y a t-il des certification de philosophie ? :smiley:
Qu'est ce que c'est ? Pourquoi ?
Estimations
charges
Délais
Problème : impossible
Constat du réel
Depuis 1970 on cherche vainement à estimer
Donc : cherchons alternative
Ne plus en faire : chercher autre chose
Suivi des estimations
Pour "constater le désastre"
Quel est le différentiel ? (marge d'erreur 200% possible !)
Vraie démarche scientifique
Qu'est ce que faire un planning ?
Prédiction de l'avenir : boule de cristal
Eléments imprévus exemple crise sanitaire
L'agilité compatible avec le no estimate ?
c'est le contraire (prédictif) qui n'est pas agile
beaucoup d'incohérences entre l'esprit agile et l'utilisation qui en est faite hors du no estimate
Prioriser les fonctionnalités sans faire d'estimation
On compare deux fonctionnalités comme on comparerait deux photos
Suppose un découpage fin
Décision du PO
Ne pas mettre de "points"