putain
https://monetendoir.fr/etendoir-jar [...] etail.html

Pour avoir essayé les deux (les jours/hommes et les points de complexité), y a pas de méthode magique. Sur les points de complexité, une fois que tu as de l'historique, tu peux en théorie transformer ça en "date de release", avec une idée de la vélocité de ton équipe.
Mais une fois qu'on a dit ça, on se plante déjà. Si on commence à confondre "estimation", avec "quand ce sera fini", c'est déjà un premier piège.
Toute estimation comporte une part d'incertitude, plus ou moins grande. Le problème étant que des features complexes sont souvent la sommes de plusieurs sous tâches, chacune avec son niveau d'incertitude... Et l'accumulation de ces incertitudes rend très très compliqué le fait d'avoir des dates fiables. Tu peux comme Harko le faire artificiellement rajouter N points à chaque fois, mais au final en faisant ça tu ne fais que compenser le biais d'optimisme des devs et si ça marche pour 80% des devs "standards", il est très probable que t'ais une partie des devs ou les 2 points ajoutés ne suffisent pas.
 
Rien que le terme "estimation" est foireux: "j'estime que cette pièce fait 20m2" => je fais une approximation à la louche d'un truc qui a une vraie réalité "physique". Et il est d'ailleurs assez facile de comparer la qualité de l'estimation/approximation avec ladite réalité.
Pour moi ce qu'on nous demande de faire avec les "estims" (que ce soit en poker planning ou autre), c'est plus une prédiction, comme en météo en fait (les modèles scientifiques en moins): on nous demande de prévoir le futur, comment ça va se passer. Et forcément c'est compliqué et pas une science exacte. Si ton management accepte pas ça...
 
Après je comprend bien que coté business on veuille avoir des dates de release, mais pour moi c'est justement le principe essentiel des méthodes agiles normalement: la flexibilité et revoir, toutes les semaines, tous les 15 jours le projet, et ajuster son scope, son budget et son délai pour prendre en compte ces incertitudes et ce qu'on apprend au fur et à mesure de l'avancée du projet. C'est SpaceX avec les SN1-9 et pas le SLS. Et surement pas Scrum et ses myriades de codification/rituels/process
 

Tu comprends min pivot vers la menuiserie ?

Plus j'avance dans dans ma carrière moins je crois à l'utilité des chiffrages (et j'ai 10 ans de Scrum derrière moi avec 3 équipes dans des boîtes différentes, avec des métriques précises de temps passé vs chiffrage notamment).
Du coup je me demande si on va pas finir par faire du Kanban (en gardant certains rituels Scrum intéressants).  
Pour rappel Scrum c'est un framework.  

Je crois que c'est nraynaud (à vérifier) qui avait dit ici même que de toute façon le principal problème avec l'agile se situe en-dehors de l'équipe de dev, la date de sortie est toujours imposée par les commerciaux et après on fait comme on peut compte-tenu de cette date... donc oui on a avec du bol un peu de contrôle sur le 'scope' en ajoutant ou enlevant certaines features mais globalement la date du sortie et les trucs à mettre dans le produit sont quand-même vachement fixés en amont (on n'a pas dit que ça faisait un produit de qualité et qui sort en temps et en heure par contre on est bien d'accord )

Kanban c'est parfait quand tu fais des services et que l'orga est familière avec le LEAN. Par contre si tu es sur des softwares à état stable important (genre un soft livré au sein d'une grosse COGIP qui réfléchit pendant six mois avant d'upgrader tout ce qui n'est pas taggué CVE) c'est plus compliqué (parce qu'en général tu as déjà vendu la roadmap). La phase d'estimation te permet de savoir si tu es plus ou moins aligné avec l'objectif qui était fixé (et donc tu peux prévenir le client, déprioriser d'autres trucs... voir demander du staffing).

Plus j'avance dans dans ma carrière moins je crois à l'utilité des chiffrages  

skeye, c'est pour toi

Ouais mais genre, dans un espace dédié manipulé par un pro, pas en accès libre, rassures moi?
Parce que entre:
 
- La mouture pas adaptée
- Les bourrins du tamper
- Les manips pas faites correctement
- La maintenance
 
J'imagine même pas la catastrophe    
 
C'est pas vraiment l'usage, tu vas plus t'emmerder à trouver la bonne quantité pour moudre exactement ski faut. Le mieux c'est de trouver un blend qui marche pour vous deux. Par définition un ristretto sera plus aromatisé, tant que tu pars pas sur un robusta y'a forcément un common ground qui vous ira à tous les deux. Surtout si elle le noie dans du sucre.

Sérieux Jubi va demander à un L3 qui a claqué son budget WFH dans un Niche Zero de t'expliquer, t'es trop noob pour parler d'espresso sur ce topic.
Allez je suis gentil: https://www.youtube.com/watch?v=65Z4gOqwDLA
 
Tu me préviens quand tu mettras 5000 balle dans une La Marzocco pour chez toi, histoire que je guette les bonnes affaires sur Anibis deux mois plus tard.
 
Chez FB Londres tout le monde allait au café staffé alors qu'il y avait la queue et que c'était payant (bon £1 la boisson, pour un employé FB c'est une erreur d'arrondi).
Trop peur de toucher aux Rocket et de se salir les mains.
 
Sur un de nos sites on a une ECM Technika, quasiment tout le monde utilise la Jura à côté.  

La maintenance on a des gens payés pour ça qui le font tous les jours. Pour le reste, bah on est formés une heure pendant notre semaine d'on-boarding, ça suffit à éviter de trop les dégâts. Il y a des cheat sheets à côté de chaque machine.  
 
Après, si tu vas à Zürich il faut aller au 7ème étage, c'est là que les fous furieux du café s'occupent de leur cafetière en achetant leurs grains avec leurs réglage. Ils laissent pas les gueux qui passent la serpillière approcher leur machine à café, et il parait que c'est là qu'on peut faire le meilleur café. Ou alors tu vas au bar où il y a un barista...
 
Tain, vivement le retour au bureau.

Voilà ça c'est du semi-pro ou pro, tu vas faire 50 cafés identiques et tu finis ton panier en 2h. Pour un particulier / amateur tu fais pas ça.

T'as une boite pour chaque café, pour faire un caf' tu prends une balance de cuisine (ou de café si t'es vraiment à fond dedans) et un petit récipient (il y a des moulins avec lequel le bac réceptacle est fait pour, genre le niche), tu verses le café en fonction de la dose dont t'as envie / de la recette, tu transvases le café dans le moulin, tu lances le moulin, tu l'arrêtes quand il a fini de moudre. C'est tellement standard qu'il y a des moulins "auto-off" non pas sur minuterie mais quand ils passent trop de temps sans aucune résistance.
 
Si tu veux un café différent, tu mets un café différent dans le moulin.
 
Demo de l'auto-off et du niveau de perte / rétention du Wilfa Uniform: https://www.youtube.com/watch?v=3wkMkFfQ1N4

faudrait demander à ratibus de faire le proxy-PO entre toi et les profs

jours-hommes

Dans ce cas, dans le sprint review, ça serait pas mal de comparer les estimations avec la réalité et expliquer la différence. Parce que en ce qui me concerne, je trouve toujours que les points accordés sont insuffisants, et ce dès le poker. Et la réalité me donne raison.

Plus j'avance dans dans ma carrière moins je crois à l'utilité des chiffrages (et j'ai 10 ans de Scrum derrière moi avec 3 équipes dans des boîtes différentes, avec des métriques précises de temps passé vs chiffrage notamment).
Du coup je me demande si on va pas finir par faire du Kanban (en gardant certains rituels Scrum intéressants).
Pour rappel Scrum c'est un framework.

Comme accent anglais, je recommande le scouse, c'est au moins aussi déroutant que le scottish english...
https://www.youtube.com/watch?v=sWAUrHODRWM
A+,

Je crois que c'est nraynaud (à vérifier) qui avait dit ici même que de toute façon le principal problème avec l'agile se situe en-dehors de l'équipe de dev, la date de sortie est toujours imposée par les commerciaux et après on fait comme on peut compte-tenu de cette date... donc oui on a avec du bol un peu de contrôle sur le 'scope' en ajoutant ou enlevant certaines features mais globalement la date du sortie et les trucs à mettre dans le produit sont quand-même vachement fixés en amont (on n'a pas dit que ça faisait un produit de qualité et qui sort en temps et en heure par contre on est bien d'accord )

Oui mais attention à ne pas tomber dans l'excès inverse parce que pour 1 success story de #noestimate #noroadmap et que sais je tu as 15 échecs avec des ré écriture from scratch, des trimestres entier à faire du refactoring, du CV driven development etc

Pour avoir essayé les deux (les jours/hommes et les points de complexité), y a pas de méthode magique. Sur les points de complexité, une fois que tu as de l'historique, tu peux en théorie transformer ça en "date de release", avec une idée de la vélocité de ton équipe.
Mais une fois qu'on a dit ça, on se plante déjà. Si on commence à confondre "estimation", avec "quand ce sera fini", c'est déjà un premier piège.
Toute estimation comporte une part d'incertitude, plus ou moins grande. Le problème étant que des features complexes sont souvent la sommes de plusieurs sous tâches, chacune avec son niveau d'incertitude... Et l'accumulation de ces incertitudes rend très très compliqué le fait d'avoir des dates fiables. Tu peux comme Harko le faire artificiellement rajouter N points à chaque fois, mais au final en faisant ça tu ne fais que compenser le biais d'optimisme des devs et si ça marche pour 80% des devs "standards", il est très probable que t'ais une partie des devs ou les 2 points ajoutés ne suffisent pas.
 
Rien que le terme "estimation" est foireux: "j'estime que cette pièce fait 20m2" => je fais une approximation à la louche d'un truc qui a une vraie réalité "physique". Et il est d'ailleurs assez facile de comparer la qualité de l'estimation/approximation avec ladite réalité.
Pour moi ce qu'on nous demande de faire avec les "estims" (que ce soit en poker planning ou autre), c'est plus une prédiction, comme en météo en fait (les modèles scientifiques en moins): on nous demande de prévoir le futur, comment ça va se passer. Et forcément c'est compliqué et pas une science exacte. Si ton management accepte pas ça...
 
Après je comprend bien que coté business on veuille avoir des dates de release, mais pour moi c'est justement le principe essentiel des méthodes agiles normalement: la flexibilité et revoir, toutes les semaines, tous les 15 jours le projet, et ajuster son scope, son budget et son délai pour prendre en compte ces incertitudes et ce qu'on apprend au fur et à mesure de l'avancée du projet. C'est SpaceX avec les SN1-9 et pas le SLS. Et surement pas Scrum et ses myriades de codification/rituels/process
 

https://www.lemonde.fr/internationa [...] _3210.html
 
c'est moche...

MERCI, c'était exactement ma question.
 
après les gens demandent pourquoi il faut des PM/PgM pour s'interfacer avec les utilisateurs

Je trouve que tu as une approche assez compatible avec le bayésianisme quand tu parle de prédiction, de faire un pari finalement Finalement, il faudrait donner plusieurs estimations avec un degré de confiance.

Plus j'avance dans dans ma carrière moins je crois à l'utilité des chiffrages (et j'ai 10 ans de Scrum derrière moi avec 3 équipes dans des boîtes différentes, avec des métriques précises de temps passé vs chiffrage notamment).
Du coup je me demande si on va pas finir par faire du Kanban (en gardant certains rituels Scrum intéressants).  
Pour rappel Scrum c'est un framework.  

Je crois que c'est nraynaud (à vérifier) qui avait dit ici même que de toute façon le principal problème avec l'agile se situe en-dehors de l'équipe de dev, la date de sortie est toujours imposée par les commerciaux et après on fait comme on peut compte-tenu de cette date... donc oui on a avec du bol un peu de contrôle sur le 'scope' en ajoutant ou enlevant certaines features mais globalement la date du sortie et les trucs à mettre dans le produit sont quand-même vachement fixés en amont (on n'a pas dit que ça faisait un produit de qualité et qui sort en temps et en heure par contre on est bien d'accord )

Je trouve que tu as une approche assez compatible avec le bayésianisme quand tu parle de prédiction, de faire un pari finalement Finalement, il faudrait donner plusieurs estimations avec un degré de confiance.

 
il doit être un poil trop cher.

bah ça dépend ! tu le met devant une assistance de profs, et tu lui demandes de se mettre en mode Ray Patterson dans un épisode des Simpson

https://www.youtube.com/watch?v=-uS3a72MbVw

Sans doute. En tous cas quand tu vois la biblio à ce sujet sur le net, je pense que c'est assez facile d'en arriver à la conclusion que le système actuel basé sur un simple nombre fixe ne fonctionne pas (ou trop rarement). Et au final c'est assez logique, quand sur une météo tu vois une prédiction de la trajectoire d'un cyclone par exemple, souvent tu ne vas pas voir une simple ligne, mais une surface qui va en s'élargissant, pour prendre en compte l'incertitude sur l'évolution.
 
Du coup je pense que si on voulait significativement améliorer la qualité de la prévision, il faudrait sans doute un système équivalent:
- que les tâches unitaires soient estimées avec un intervalle de confiance (que ce soit via une fourchette, ou des 80% en 3j, 90% en 5j etc...)
- et ensuite une appli qui te permet de composer ça pour voir, ta feature compliquée qui comprend N tâches unitaires, chacunes incertaines, à quel point sa durée peut varier. Et éventuellement identifier rapidement les tâches les plus incertaines parmi cette features, pour peut être essayer le plus vite possible d'augmenter la confiance de leurs intervales (par exemple avec un PoC, ou l'investigation poussée d'un module existant etc...)
 
Après ça parait beau en théorie, mais la mise en pratique me parait plus compliquée

Sans doute. En tous cas quand tu vois la biblio à ce sujet sur le net, je pense que c'est assez facile d'en arriver à la conclusion que le système actuel basé sur un simple nombre fixe ne fonctionne pas (ou trop rarement). Et au final c'est assez logique, quand sur une météo tu vois une prédiction de la trajectoire d'un cyclone par exemple, souvent tu ne vas pas voir une simple ligne, mais une surface qui va en s'élargissant, pour prendre en compte l'incertitude sur l'évolution.
 
Du coup je pense que si on voulait significativement améliorer la qualité de la prévision, il faudrait sans doute un système équivalent:
- que les tâches unitaires soient estimées avec un intervalle de confiance (que ce soit via une fourchette, ou des 80% en 3j, 90% en 5j etc...)
- et ensuite une appli qui te permet de composer ça pour voir, ta feature compliquée qui comprend N tâches unitaires, chacunes incertaines, à quel point sa durée peut varier. Et éventuellement identifier rapidement les tâches les plus incertaines parmi cette features, pour peut être essayer le plus vite possible d'augmenter la confiance de leurs intervales (par exemple avec un PoC, ou l'investigation poussée d'un module existant etc...)
 
Après ça parait beau en théorie, mais la mise en pratique me parait plus compliquée

Tiens, question design d'API "REST"....
 
Vous avez une ressource Personne, avec des sous-ressources "CanauxDeContact"
 
un service de cette ressource répond POST, PUT, GET et DELETE (la modif est en mode replacement complet)
 
On veut ajouter PATCH pour modifier partiellement notre ressource.  
 
Comment faire pour lui indiquer de supprimer une sous-ressource ?  
 
(je sais, on a un service "personne/{id}/canal/{id}" avec DELETE, mais dans le contexte, on doit faire un seul appel.)

On veut ajouter PATCH pour modifier partiellement notre ressource.  
 
Comment faire pour lui indiquer de supprimer une sous-ressource ?

Pas sûr de bien comprendre ton pb si t'as "personne/{id}/canal/{id}" avec DELETE ?

Je balance le patch sur person/{id} charge a lui de péter la/les sous ressources

T'as plus qu'à faire un diff sur ta sous-resource avec ce que t'as en BDD et ce qui vient d'être envoyé en PATCH (en partant du principe que t'envoies une liste complète d'IRI pour ta sous-resource).

Il y a 2 choix possible:

• une update stateless où tu PATCH la resource avec une liste des canaux de contact qu'elle doit avoir, l'endpoint enlève ceux qui sont plus dedans et ajoute ceux qui sont dedans, l'avantage niveau client c'est que c'est simple, efficace, et clair
• une update stateful où le client va à la place fournir des directives d'ajout / suppression, c'est plus simple niveau serveur, c'est plus simple si le client veut juste ajouter des trucs, mais pour des maj complexes c'est plus compliqué car pas atomique et le client peut se retrouvé désychronisé facilement

Après tu peux offrir les deux via une variation de types ou bien des pseudo-champs sur la resource parent, genre soit CanauxDeContact est une liste auquel cas tu remplaces tout (update stateless), soit c'est un objet avec des clés style add et delete auquel cas c'est du stateful.

Github a les deux options avec les labels d'issue. Ils font pas ça via PATCH sur l'issue mais par PUT/POST/DELETE sur un sous-endpoint, mais le principe est le même:

• PUT issues/{id}/labels remplace atomiquement tous les labels par la liste de labels fournie
• POST issues/{id}/labels ajoute les labels fournis à l'issue
• DELETE issues/{id}/labels supprime tous les labels
• DELETE issues/{id}/labels/{name} supprime juste le label spécifié

Mon bot qui jouait avec les labels faisait initialement des POST/DELETE pour synchroniser l'état local & remote, mais au final ça avait trop tendance à desync donc maintenant ça fait juste un GET et un PUT.

faudrait demander à ratibus de faire le proxy-PO entre toi et les profs

 
il doit être un poil trop cher.

Par contre la question fondamentale est : est-ce que l'équipe de dev existe en dehors du chiffrage.
- si non (équipe produit stable par exemple) : les estimations servent à rien, tu posses sur les priorités avec un stack rank / roadmap light. Les gens estiment ce qu'ils pourront faire, et tu tournes comme ça
- si oui (service, département IT de COGIP où t'es toujours en ZBB / assault des autres équipes qui veulent tes gens) : alors t'es marron, parce que si la taille de l'équipe de dev dépend de la vente d'une roadmap, d'un scope, tu n'échapperas pas aux estimations. Et c'est légitime : celui qui paye "en veut pour son argent", et il peut y avoir un cout d'opportunité (si j'avais su que ça prendrait 3 ans, j'aurai payé le projet supply chain à la place)

Là on va peut être passer par un expédient : ajouter une "fausse sous-resource" qui contiendrait la liste de sous-resources à supprimer.
Mais c'est dégueu, ça n'a plus rien de REST....

Au passage, truc amusant : là on est sur des modifs dites RGPD => les DELETE sont "physiques". En mode "normal", on fait juste une historisation des données.
 
Imaginons qu'on veuille exposer le même service dans les 2 modes, est-ce qu'un header ou un truc comme ça peut être une solution valable pour passer l'info ? (pas techniquement, mais sur le principe)

Sauf que les chiffrages business n'ont pas le même niveau de granularité que les chiffrages "tech".
Quand le boss vient me demander une estimation sur une feature alors je donne une plage de chiffrage à la louche (avec mon expérience) et dans 99% des cas ça suffit.
Alors qu'en réunion de planification, on chiffre en heures chez nous

J'ai une petite question programmation (désolé du HS du coup )  
 
J'ai commencé une application mobile en utilisant Cordova.
Je veux faire une version gratuite à features limités et une payante avec tout de débloqué.
A l'intérieur de l'app cordova en elle-même (html/js/...) c'est assez simple, j'ai fait une bête variable on/off que je peux changer en 2 secondes.
 
Après côté compilation Android, publication, ... ça devient le bordel.
J'ai créé 2 noms de packages différents, j'ai tenté le rechercher/remplacer de "MonAppFree" en "MonAppPro" un peu partout dans les gradle.truc et packages.bidule mais ça part en cacahuète.
 
Avant de m'acharner, c'est quoi les best-practices pour ce genre de cas ?  
Je peux vraiment faire 2 applications séparées, mais j'ai peur que ça soit l'usine à gaz pour les mises à jour, correction de bugs, ...

Après côté compilation Android, publication, ... ça devient le bordel.
J'ai créé 2 noms de packages différents, j'ai tenté le rechercher/remplacer de "MonAppFree" en "MonAppPro" un peu partout dans les gradle.truc et packages.bidule mais ça part en cacahuète.
 
Avant de m'acharner, c'est quoi les best-practices pour ce genre de cas ?  
Je peux vraiment faire 2 applications séparées, mais j'ai peur que ça soit l'usine à gaz pour les mises à jour, correction de bugs, ...

une seule version avec un in-app purchase ?

 
C'est justement ce qu'on veut éviter.