Reprise du message précédent :

Nous aussi, je te rassure. D

Je t'envoie ça

This

 
1 seul pour l'instant, le reste étant délégué à l'extérieur (compta, juridique, etc.)

Et c'est mon associée au passage

 
Je suis d'accord. Chez nous, on a mis SCRUM en place depuis 2 ans seulement, et on a énormément évolué et on continue à toujours évoluer. On a même créé une colonne spécifique pour des tasks spéciales non assignables à un dev en particulier et non mesurable en terme de temps. On met dedans certaines tasks où personne ne sait comment faire et où on a aucune idée du temps que cela va prendre et on s'occupe de ces tasks tous ensemble un après midi par semaine dédié à la recherche et au travail tous ensemble. On discute stratégie à employer etc... Et on tente de résoudre le problème ensemble.  
On a fait cela parce qu'on a constaté qu'assigner ce genre de task et donner un estimate time dessus pouvait paralyser le dev qui s'en occupe ainsi qu'une partie des tasks "classiques". Et ce n'est qu'un exemple.

 
Les mecs mettent en place des trucs sans savoir à quoi ils servent, se posent la question de sa savoir si c'est utile et ratent complètement le fondamentaux.
Et tu te retrouves avec des "scrum master" qui assignent des tâches

 
completement HS, mais elles sortent d'ou tes captures ? c'est pas directement d'un oscillo, si ?

Un analyseur logique software je crois.
SALEAE un truc comme ça ?

bingo, salae logic.
 
J'ai acheté un petit analyseur logique à $12 ça marche pas super, mais c'est tout ce que je peux me permettre pour l'instant.
 
Quand j'aurai un peu de thunes et de stabilité je vais acheter un Rigol MSO 5000

Le #noestimate m'attriste toujours un peu, parce que c'est vraiment la vision égoiste du dev qui dit : me faites pas chier, ça ralentit MON travail.
 
Sauf à ne traiter que des bugs, y'a toujours une estimation qui rentre en jeu. Ne serait-ce que l'estimation du bénéfice attendu :  
- tu es Plam, comment tu sais quelle est la feature la plus importante de ton backlog ? Tu dois estimer ce qu'elle va rapporter, et combien elle va couter. C'est meme réducteur, en plus de ce qu'elle rapporte il y a plein d'effets à considérer (facilité de maintenance, valeur marketing d'avoir un produit qui supporte X, etc...
- tu es Ratibus et tu gères un eCommerce de vente de bouquins, clairement y'a des estimations partout sur la valeur attendu. Je vais prendre un exemple simple : 2 features sont estimées par le product owner comme pouvant rapporter 100k€ par an. A est estimée à 100 jours, B à 200 jours. Manque de pot, t'as que 200 jours de dispo. Tu peux gagner à faire la feature A, et peut etre C et D, qui tiennent dans les 100j restants, mais qui cumulées rapporteront peut etre 120k€.
 
Vous allez me dire : si t'as une tache à 200 jours t'a pas assez découpé. OK. Mais du coup si tu as un site eCommerce par ex, comment tu décides si il vaut mieux supporter Paypal, ou si il vaut mieux implementer le direct debit ? Vraissemblablement aucune des deux ne tiendra dans un sprint...
 
Mon propos : a un moment y'a toujours quelqu'un qui doit pouvoir avoir une vue raisonnable du cout/avantage de faire quelque chose, et c'est dur de faire ça sans avoir un minimum d'estimation (du benefice comme du cout, d'ailleurs)
 
Après, je reconnais qu'il y a des PMs qui aiment se palucher sur des abaques de chiffrages, et au final ça sert à rien.

Bullshit tout du long.
 
Y'a certains cas où il faut viser une date, genre les jouets doivent être commandés à l'usine en septembre avant noël, ou alors certaines campagne marketing ont une date fixe.  
 
Mais en général décider de l'opportunité d'une feature se fait surement pas face à une estimation.  
 
Quand les devs sont appelés, ça fait bien longtemps que tout a été décidé. Pour continuer avec Plam, je vois pas comment il aurait décidé de consulter les devs qu'il avait pas encore avant de forker et engouffrer du fric dans XCP-ng. Les features demandées par les product manager sont souvent des trucs de product manager, ils ont vu à une conf que A/B testing, le cloud, SOA ou IoT c'était bien, il faut en mettre, sauf cas exceptionnel il est très difficile de réellement inscrire un revenu sur une feature. C'est comme les développeurs qui veulent du react ou du ember après une conf.
 
Y'a des cas où c'est critique, genre la planification énergétique ou l'aéronautique, et dans ce cas, il est hors que question que celui qui va réaliser chiffre lui-même.
 
Quant à savoir si la modification de ton écran va prendre une semaine ou 2, et si tu t'es arrêté en cours de route pour aider un collègue, ou t'as eu un pb super compliqué en cours de route, franchement, on s'en fout.

Même dans ces cas là, c'est rarement l'estimation qui prime, tu vas plus te retrouver avec du crunch jusqu'à ce que le truc soit sorti.
 
Et à côté de ça, les estimations sont régulièrement utilisées plus pour pouvoir impliquer/fauter le dev que pour quoi que ce soit d'utile: je pense que plus ou moins tous les devs ont eu une demande d'estimation et se sont vu répondre que c'était trop long, pas au sens "on va déprioriser le truc" mais au sens "engage toi sur une durée moins longue. Et t'as rarement un suivi et un environnement qui pousse ou aide à apprendre à estimer. De ce que j'ai compris c'est en théorie un truc fait en agile, mais je sais pas à quel point il est courant de revenir sur les estimations et comparer au résultat effectif.

Dans mon cas l'estimation qui compte est l'ordre de grandeur et la confiance dans la livraison

Est ce que c'est de l'ordre de l'heure, de la journée , de la semaine ?

Est ce que je suis confiant sur le fait de pouvoir le faire, ou est ce que je dois faire un poc avant ? Quelles sont les technos, quelles en sont leurs limites

Est ce que c'est une feature isolée ou une demande qu'on retrouve ? Est ce que c'est aligné avec la direction dans laquelle on veut aller ?

Pour rappel on est éditeur d'une seule solution (CMS + Android + iOS).

Jubi , ta tâche a 200j, en vrai elle va prendre entre 150 et 300, non ?
Donc comparer une tâche a 100j qui va prendre entre 75 et 150 a une a 200 est un exercice de proba, pas un de planification. Pas comme une usine qui sort 100 véhicule jour a qui on demande dans combien de tps elle aura produit 200v

Pour ça que je ne compare pas les tâches au sein d'un même ordre de grandeur

On a déjà évincé des features en fonction du chiffrage macro qu'on avait indiqué car pour le même temps macro on peut en faire d'autres plus petites pour lesquelles on pense que le ROI est plus intéressant.
 
Par contre pour les "gros" trucs je donne toujours un intervalle. Ça a été révolutionnaire ici

Relevant https://twitter.com/lynnandtonic/st [...] 9745434624

Y a une différence entre savoir si la feature "supporter Paypal" prend 100 ou 200 jour et savoir si la  sous-tâche 1.A.54.B.32 "se connecter à l'API xyz de Paypal" vaut 5, 8 ou 13 story point. Ça t'apporte aucune information utile, vu que t'as déjà décidé que tu devais supporter Paypal.

 
ça dépend bcp de la structure (probablement la taille joue un grand rôle) Dans notre cas, les next features sont décidées avec les devs (moi et le lead dev en dessous de moi), jamais sans nous.
 

 
j'ai pas l'impression que ça contredit bcp ce qui a été dit avant par Jubi, mais j'ai peut-être pas tout compris.
 

 
Ben je suis pas vraiment d'accord avec ça. Je reconnais que oui, tout peut changer tout le temps, mais on s'en fout pas. Derrière, ya par exemple le marketing qui annonce une nouvelle feature et qui espère que les délais sont respectés, ya l'attente des clients qui ont besoin de telle ou telle feature, ya les sales qui ont besoin de telle ou telle feature pour vendre le produit.
Le "quand ce sera prêt", c'est pas vraiment super satisfaisant. ça a certes des avantages (moins de pression sur le dev, travail donc peut-être plus soigné si les dev sont sérieux, temps nécessaire pris pour appréhender les problèmes etc...), mais ça tiens pas compte des réalités économiques comme la concurrence, le fait de devoir avoir la bonne feature au bon moment clé dans le marché etc...
 
Je pense que tout est affaire de compromis et que rien n'est simple.

la priorisation est importante :
cette tache dépend d'une autre
cette tache a un ETA dur (pour nous : une inauguration)

Le reste est essayer de remplir le planning sans noyer les gens, de garder du temps pour la R&D et le support impromptu , ou l'imprévu ( hey devine quoi, tu vas passer 4 jours a publier une fucking app au lieu de 30mn), de garder un avantage sur nos concurrents (ou plutôt sur ce qu'on sait et qu'on imagine que nos concurrents font), tout en essayant de sentir vers où va le marché (genre est ce qu'on va vers de la 3d, de l'animation 2D , ou plutôt de l'IoT et des capteurs ), est ce qu'on améliore nos apps internes qui amélioreront à terme notre productivité ou est ce qu'on fait du visible pour le client qui nous permettra de chopper de nouveaux marchés
et puis il faut saupoudrer le tout de trucs intéressant (<- rien que ça , c'est fun tellement ça varie d'une personne à l'autre)

Les ETA , c'est difficile à chiffrer, difficile à actualiser et  respecter,  et finalement beaucoup d'effort pour un tout petit maillon de la chaine. Au final, si c'est une vraie obligation on fera un bout de crunch, sinon, on décalera la cible ou la date

Les priorisations sont beaucoup plus stables et permettent de décider quoi faire facilement, avec une matrice du genre de celle d'eisenower

Désolé je peux pas participer à la discussion avec vous les gueux, j’ai des affaires avec des stars

Yop  

L'un d'entre vous saurait-il si on peut utiliser Stripe pour des paiements en plusieurs fois?   (ou à défaut, programmer plusieurs débits à dates espacées en un seul appel API?)
J'ai fouillé la doc sans succès. Y'a leur système de Subscription pour des abonnements, mais aucune option pour définir une clôture automatique à une date de fin donnée, ce qui aurait pu faire l'affaire.

La seule option que je verrais, serait de néanmoins faker une subscription et programmer via une crontask les clôtures de subscription, moyennant entretien d'une table en bdd qui répertorie tout, mais ça devient de suite bien plus relou à gérer
(Comment font les sites marchands?!)

Toute info serait précieuse  

1/ en effet il y a des cas avec des dates butoirs (an 2000, RGPD, Noel, etc...) mais souvent y'a pas de discussion sur l'opportunité de faire ou pas : il faut faire, donc on tombe dans le cas où tu fais du mieux possible dans le temps imparti. Par contre je pense que ça représente pas la majorité des taches que fait une equipe de dev
 
2/ pour le reste je suis pas d'accord : en tant que PM tu es toujours dans une situation où tu as plus d'idées que de bande passante pour les produire, donc tu dois prioriser pour 2 raisons :  
- tu dois prioriser ce que tu fais vs ce que tu fais pas
- tu dois ordonner les taches par ordre de benefice (un backlog est ordonné)
Je vois pas comment tu peux faire ça sans avoir une idée du cout et du benefice attendu.
 
Je te rejoins sur le fait que le gain est souvent difficile à chiffrer (ça explique d'ailleurs pourquoi dans plein de boites, la dette technique existe et se résorbe mal : refactorer un truc iso fonctionnel, c'est peu de benefice visible, et c'est difficile d'estimer le gain de productivité futur.
 

c'est un truc que j'ai appris en faisant cette connerie, c'est qu'au final l'estimation doit servir qu'en amont, pour assigner une enveloppe. Après tu fais confiance et tu pars du principe que les devs feront du mieux qu'ils peuvent dans le temps imparti. Micro gérer les taches est une perte de temps fantastique.
Mais ça existe pour plusieurs raisons :  
- le "business" veut souvent une vue précise de ce que fera / ne fera pas ce qui est développé
- le fait que de l'argent soit assigné à un projet dépend d'un brief en amont, où on a fait mirroiter des bénéfices : ça te crée déjà un scope a minima qui est souvent beaucoup trop gros (pas du tout un MVP)
- beaucoup de gens non technique perçoivent comme injuste le fait qu'il n'y a pas d'élément simple quantitatif pour mesurer leur job. Si t'es un sales tu fais un chiffre X ou tu ne le fais pas, si t'es au support tu réponds à X tickets ou tu ne le fais pas. Ça rapproche le dev de la recherche par exemple en terme de mesure, et plein de boites n'en ont pas l'habitude.
 

Je suis d'accord avec ça, mais la production de cet ordre de grandeur, j'appelle ça une estimation
 

Mon exemple était trop proche en effet, mais
1/ il te faut une estimation pour avoir l'ordre de grandeur
2/ effectivement, y'a un exercice de proba..c'est comme ça que je le gérais en tant que PM chez Nespresso. On estimait sur des intervales, avec vote de l'équipe et application de la formule Pessimiste + 4x Plus probable + Optimiste / 6
 

1/ CQFD : il te faut donc un macro chiffrage pour décider. Ce que je reproche au #noestimate c'est le dogmatisme contre ça
2/ les intervales c'est la vie. On s'était aussi battu pour mettre ça en place. Par contre au final tout le monde prenait la borne haute pour discuter
 

Un intervale c'est bien, mais faut faire un effort pour donner une information la plus honnete possible. Sinon tu estimes tout entre 0.5 jours et 300 jours, pis t'es peinard. Mais tu aides personne à décider.
 

Entièrement d'accord. Pour moi l'estimation sert à décider quelle feature tu fais.
Après "supporter paypal" ça va etre une epic avec une enveloppe de 200 jours, et dedans faut laisser l'équipe faire son job. Du coup tu auras peut etrele payment sur le site, mais pas la gestion des retours par exemple
 

+1000
 

l'ETA te met dans la situation où tu as un budget de temps alloué (tu l'as pas décidé, mais il correspond entre le moment où vous signez et le moment où vous devez livrer). Mais j'imagine que pendant la négo, avant de vous engager sur tout, vous réfléchissez au temps probable que ça prendra, pour savoir quand dire non. C'est une estimation.
 

Fais gaffe t'as Gargamel qui veut te manger
 

 
J'ai ici un dev qui fait pas mal de Stripe, si tu veux je peux lui fwd ta question

Et sinon vu que je suis cité, je dirai que la réalité est beaucoup plus « grise » que #noestimate vs #ETA_en_minute_de_la_sous_sous_feature_27b12_alinéa_2

J'ai vécu plusieurs scénarios :

• la pifomètre/instinct pur. Pour XCP-ng, dans la colonne débit : aucun dev dedans avant de forker capable d'estimer l'ampleur du taff. Dans la colonne crédit : c'est pas de la rocket science, on va bien y arriver.
• pour certaines features complexes, j'ai des livrables qui ont 3 ou 4 ans de retard, jusqu'au jour où je décide de passer à un kanban et des réunions tous les 15 jours pour que ça avance
• pour les « petites features » (ou bien découpables), ça livre de plus en plus vite avec l'XP de la team XO qui monte (et aussi le fait d'arrêter de trop agrandir la team avec des juniors chaque année)

Pour le 2ème point, c'est que c'est une tâche très dure à découper Et que entre temps j'ai lâché beaucoup de lest sur la gestion de projet XO (avant ça reposait sur ma volonté de pousser, ça marchait bien jusqu'au jour où j'ai du laisser ce rôle car plus le temps : patatra. Perte de qualité pendant les releases, ralentissement. Maintenant, il y a un vrai process mieux orga = c'est reparti quasi aussi bien qu'avant et ça pourra grossir sans moi

et pour le coup, niveau orga, vous avez mis quoi en place ? (eventuellement en MP)  

Pour XO :

* j'ai plus que des réunions tous les 15j, dans lesquelles on négocie la prio d'une feature intéressante « sortable » par mois (on release commercialement tous les mois)
* les releases techniques ont lieu toutes les 2 semaines (au lieu d'épouser les releases marketing mensuelles, moins de pression du jour J pour les devs)
* il y a un kanban papier avec suivi des délais estimés (colonne avec les mois, et délais en date, à mon niveau je rentre pas dans les J/H ni les SP), très utile pour constater les dérives (date barrée, puis remplacée). Quand la tâche est terminée, elle va dans un kanban historique, ce qui permet d'avoir des chiffres concrets pour critiquer a posteriori pour tel ou tel truc qui a sa race dérivé. Ça aide aussi le(s) responsable(s) XO à mieux estimer.
* meilleure définition des workflow au sein de l'équipe XO, par exemple avec remplacement des rôles de « release manager » à chaque release, ce qui force à faire une meilleure doc dès que c'est un nouveau qui s'occupe d'un processus

Avant c'était 100% moi qui gérait tout le projet, maintenant je fais plus que les réunions tous les 15j et c'est tout. Rarement, il m'arrive d'intercaler un truc au milieu quand c'est vital (dernier exemple en date : « brancher » le support de zstd dans XO en même temps que release dans XCP-ng, effet d'impact important en terme de com'.

Pour l'instant c'est pas aussi bien que quand j'étais derrière tout (en mode pilotage tous les jours) mais c'est beaucoup plus propre et le résultat s'affine de release en release, ce qui fait que ça va me « battre » à un moment. Sans oublier que j'y consacre plus que quelques heures vs au moins 2h par jour. C'était surtout ça l'objectif

si je résume:  tu fixes le cap et les points d'étapes majeurs , pour le reste, c'est léquipe xo qui priorise
J'aime beaucoup le côté low tech (nous on a un tableau véléda des livraisons à venir, bien plus utilisé que le trello que je tiens à jour)

encore des gens qui me contactent pour me donner de l'argent
 
Je crois que ma réputation est plus forte que mes résultats.

 
Ce serait chouette et avec plaisir, merci    
Je viens d'avoir un retour du support Stripe, c'est un peu ce que j'envisageais (partir sur un Billing classique), sauf qu'ils ont un système de webhook qui pourrait être trigger à chaque fois qu'ils encaissent un paiement, du coup y'aurait juste un compteur à maintenir, ça sera plus propre que mon hypothétique cron
 
Mais un retour de dev plus expérimenté que moi serait pas de refus, d'autant plus s'il manipule du php

 
"Fake it until you make it"

ouais, je suis dans une dur au niveau du "fake it" là
 
ça fait 2 mois que j'ai pas facturé un jour.

 
Pour l'instant on reste low tech le temps d'être 100% satisfait par le workflow. Quand ça sera le cas, on pourra imaginer le trellotiser peut être, à voir (le problème du low tech c'est que c'est local au siège de Vates, excluant pour l'instant les devs remote, même si c'est pas grave vu que on y met que les grosses prio.
 
On verra comment ça évolue
 
 

 
MP moi que je vous mette en relation (on est full JS par contre ici)

Y'en a qui utilisent autre chose qu'une souris ici ?
 
Dans les périodes où je bosse pas mal sur powerpoint, ça me tue le bras à force (le fait de garder le bras à un angle ouvert)
 
Options alternatives :  
- Magic Trackpad : c'est dur d'etre précis avec je trouve
- Trackball : jamais essayé, mais ça pourrait etre bien
- Cintiq (je plaisante pas, j'ai vu un gars ici avec ça. J'ai cru que c'était un graphiste, mais non, il faisait ses emails et des docs avec )  

Je n'utilise que le trackpad du mbp, je n'ai pas de problème de precision maintenant que je m'y suis habitué

MagicTrackpad ftw  

 
Idem.
 
Je ne sais pas si le MagicTrackpad est aussi précis, mais je suppose que oui. En tout cas c'est le trackpad que j'arrive utiliser constamment sans me dire "il me faut une souris".
 
Sinon j'ai vu que Logitech faisait une souris verticale. Pour en avoir essayé une une fois, c'est franchement agréable la sensation de "libération" au niveau poignet.

Main gauche au boulot, main droite chez moi, ça a changé ma vie perso.

j'ai oublié de dire : dans le cadre d'un setup avec un écran (où du coup mon pc portable est à coté de l'écran, ou dans le cas où j'utilise ma workstation)
 
en utilisation nomade j'utilise le trackpad du Pixelbook 2 ou de mon T480s qui sont corrects.
 

je doute que ça fonctionne avec mon pixelbook2 (les fonctions de base sans doute, mais pas les gestures avancées)
 

il fonctionne sous Linux ce trackpad ?
 
Pour la souris verticale : ça me tente aussi, mais mon problème actuel vient plus de l'angle de mon bras que de mon poignet : c'est l'épaule qui est en vrac. La souris verticale ne résoudra pas ce problème, pour le résoudre il faut que je garde le bras dans un axe normal, ie vers l'intérieur, donc avec un dispositif de pointage face à moi.
 

   
 
mais l'idée est pas mal, je note.

J'ai testé le magic trackpad, mais rien au monde, ne vaut ma Steelseries Sensei à 30€.
 
Meilleure ergonomie de l'univers

 
https://support.google.com/pixelboo [...] 8517?hl=en
 
Apparemment, ça marche dans le dev channel.
 
Et le support dans le kernel linux a été ajouté par Google themselves très récemment.
 
Edit: pour les gestures avancées, par sûr effectivement.

Jubi > ton siège est la bonne hauteur ?
 
Ce jeu est horriblement difficile : http://grgrdvrt.com/sketches/246_pong/