Reprise du message précédent :
Ça doit faire 10 ans que je fais du scrum en jours/homme mais on applique un coefficient de "focalisation" aux jours de présence de l'équipe.  
En général on est à 60% de coefficient de focalisation (pour des équipes de dev qui font aussi de la maintenance et du support).

Ma facture est payée ?

 
D'où l'importance des ABAQUES qui permettent de faire une habile conversion SP -> j/h, laquelle peut ensuite être habilement utilisée pour faire pression sur l'équipe lors des chiffrages, ce qui est un moyen habile de leur mettre la pression sur leurs deadlines, mais en mode agile.

Principalement parce que les équipes ont des besoins différents (pas que des dev), et s’accommodent très bien de leur solution en cours.
Dans mon cas précis, parce que Jira - comme les autres - n'apporte pas de solution au problème posé : une dashboard ultra macro sur la prochaine étape des projets.
Au final je vais pas faire d'overengineering sur le truc. Vu le peu de réponses je pense qu'il n'y a pas d'outil tout fait pour ce besoin, pas si étonnant vu sa simplicité. On renseignera un tableau à la mano et basta.
Merci pour tes contributions

J'ai un redmi 4x et j'ai une maj de l'os béta sur lequel je suis de façon hebdomadaire

Et le classement en fonction du type de tâches ? Son importance ou son lien avec un projet ? des tags ?

Jours-Hommes. Testés les deux, je vois pas ce que les SP apportent dans la réalité, même si en théorie c'est séduisant :

- Je trouve pas spécialement facile d'identifier des bonnes tâches étalons- Je trouve compliqué en dehors de cas très bateaux/extrêmes de comparer du coup la complexité d'un dev aux tâches étalons
- L'argument du "oui mais le temps d'implem en JH dépend de l'expérience des devs et de leur familiarité avec le code" pour moi tient pas, vu que c'est la même chose avec les SP : quelqu'un qui n'a jamais bossé avec la techno X ou le module Y du projet aura tendance aussi à mal estimer la complexité.
- Au final les SP sont utiles qu'à l'intérieur de ta team, donc tu te retrouves pour communiquer derrière à rebasculer en JH
- Pour les rétros, je trouve bien plus facile et objectif de mesurer le temps réellement passé sur une tâche si t'es un minimum focus et fait pas 20 context swicth par jour (suffit d'un chronomètre ou de regarder ton agenda), que de donner a postériori la complexité réelle de ton dev en SP

Par contre comme ratibus, c'est pas parce que tu estimes en JH que ça en fait une deadline automatique. On sait qu'on est pas focus à 100% sur une semaine, du coup on a aussi un coefficient (qui varie en fonction des profils des gens et de leurs casquettes d'ailleurs).

 
Sur iOS, les mises à jour, c'est 4 ans et sur les produits google, même si c'est officiellement 2 ou 3 ans suivant les produits, ça a toujours été mis à jour au moins 4 ans aussi.
De plus, recevoir les mises à jour, c'est bien... Les recevoir day 1 au lieu de +6 months voire +1 year, c'est mieux. Mon Samsung S6 qui a été supporté assez longtemps, fallait attendre des plombes. Et c'est déprimant de voir qu'il ne peut pas installer le dernier android alors que le HW pourrait sans problème le supporter.
 
Bref, je ne prend que du stock maintenant, quelque soit l'OS.
 
Et même pour microsoft pour les employés de ma boite, si je dois prendre quelque chose, c'est surface, surface book maintenant (excepté les XPS pour les devs qui le veulent, mais ils foutent du Linux dessus). Et rien d'autre non plus. Pas envie de jouer au ping pong avec les hotlines qui se renvoient la baballe avec Microsoft.

Ou plus, le 5S en est à 5 allant sur 6.

Oui, pour moi, les SP sont sensés lever la pression sur l'équipe en ajoutant une couche d'abstraction pour le N+1 ou le N+2 ou le product owner, qui serait obligé de raisonner en SP (complexité, scope) et non plus en J-H (durée de développement), mais ça ne marche pas vraiment parce qu'à la fin, il finit quand même par demander "c'est pour quand". Si c'est sensé lever la pression sur les devs individuellement, ça n'a pas non plus l'effet escompté parce qu'ils s'engagent sur le nombre de SP qu'ils doivent produire durant le sprint. Alors certes, la statistique finale est un nombre de SP au lieu de "tu es en retard de tant de jours", mais on peut tjrs dire "ah mais tu aurais du finir il y a 2 sprints" ce qui revient au même. Au final, malgré tout ce que j'ai lu, je ne suis pas totalement convaincu de l'utilité du concept.

mais ça tu n'as pas besoin, suffit de dire que ce n'est pas si compliqué et que dans le sprint d'il y a trois mois ils ont fait plus de SP comme quoi quand on veut on peut

Mais tu factures à l'heure ou à la tâche ?

face à la difficulté de trancher, j'ai décidé de ne plus facturer.

let mut buffer: GenericArray<u8, N> = unsafe { mem::zeroed() };
        {
            let slice: &mut [u8] = &mut buffer;
            slice[0] = reg.read_address();
            self.ncs.set_low();
            // 0.2ms de glande avant que le moindre boulot ne soit fait.
            self.spi.transfer(slice)?;
            self.ncs.set_high();
        }

 
   victoire!

heisenbug, je vais devoir dépanner avec une LED.

Envoie leur une photo de ta bite (si elle arrive à rentrer sur la photo)

je crois que je viens de me prendre un cours de gestion de mémoire un peu violent en rust  
 
Genre j'ai tenté d'apprendre le karaté en m'incrustant à un cours de ceintures noires et ça s'est passé de manière assez prévisible

nraynaud il m'impressionne toujours, je comprend pas la moitié de ses posts. A part qu'il joue avec Rust et fait des trucs avec des composants électroniques. Je suis le seul ?

 
Et il fait du Karaté aussi ? Avec une LED ?  

non, c'est la dernière phase avant l'évolution vers le jovalise

 
Moi c'est la totalité.

je pense que j'ai une variable qui survit pas toute sa lifetime, elle se fait optimizer avant la fin de la transaction DMA qui pointe dessus.

 
Merde... et c'est irréversible ? on va vraiment le perdre ?

https://gist.github.com/nraynaud/b1 [...] bc2380e552
quand j'appelle write() j'ai des données aléatoires sur le fil.

Je pense que la variable "words" se fait optimiser avant d'avoir été lue par le DMA.

edit: le pb n'apparait qu'en build optimisé, et pas en debug.

 
C'est trop tard  

Moi j'ai fini par admettre que tout ce que faisait nraynaud avait du sens, mais que j'étais trop mauvais pour attaquer des problèmes difficiles dans ce genre.

Perdu ou pas il faut surtout profiter avant le soulèvement de ses machines

Tant que masklinn le comprend on est bien  C'est pas encore le stade Jovalise

 
Fait du C bordel de merde

 
Non mais faut arrêter le délire hein.    
 
Jovalise, c'est le mec qui chie sur une toile et qui prétend que c'est de l'art, c'est pas le mec qui est passé d'abord par l'hyperréalisme avant de poser sa crotte sur la toile. faut pas tout confondre hein.  

Comme ça il aura un segfault au runtime

 
ah non pareil je dois comprendre 10%. Mais j'ai confiance qu'il sait ce qu'il fait.

Ça se trouve il fait n'importe quoi et on le croit.

tant que mes factures sont payées, qu'est-ce qu'on en a tous à foutre finalement ?

C'est important, le forum ne peut survivre si le taux de jovalise passe la barre des 5%.

En fait ce topic c'est un peu l'équivalent du canard jaune pour nray.
 
Il expose ici ses problèmes que personne ne comprend et une fois le problème posé il a la solution.

Le problème pourrait pas être dans transfer_is_complete? Passke je crois pas que "words" puisse être déalloué/trashé avant que write ne retourne à son appelant (que je sache), c'est pas comme si c'était un vec avec de l'unsafe bizarre que tu pourrais faire un use after free, en tout cas de ce que je vois. Par contre si tu lances le transfert, que la fonction se termine, que le buffer se fait réutiliser et qu'à ce moment le DMA se réveille ça peut expliquer.

Si tu veux être sûr et que tu peux faire des allocs, tu pourrais copier ton buffer dans un Vec et assertir que t'as le même contenu (c'est pas optimisé/dégagé) à la fin du wait_for_transfer

edit: ya pas de possibilité de trucs bizarres sur l'endianness je présume?

edit2: dans https://blog.japaric.io/safe-dma/ qui ressemble beaucoup à ce que tu fais, ya un machin qui dit

// set destination address
channels.5.cmar().write(|w| w.ma().bits(buf.as_ptr() as u32));
 
// set transfer size
channels.5.cndtr().write(|w| w.ndt().bits(buf.len()));
 
// ..
 
atomic::compiler_fence(Ordering::SeqCst); // <- NEW!
 
// start transfer
channels.5.ccr().modify(|w| w.cen().set_bit());

Dans ton code je vois les deux premiers appels, mais pas le "start transfer". Ya "self.ifcr().write(|w| w.$cgifX().set_bit());" mais il est après le "transfer_in_complete" pas avant, c'est "transfer_is_complete" qui fence, lance le transfer puis attends?

Si le compilo décide de dégager / remplacer son bordel, ça va probablement être pire en C pas mieux (sauf à utiliser la méthode du Gros Buffer Statique Volatile je présume)

 
Encore quelques années aux states, et il va bientôt venir nous défendre Trump sur le topic.    

Je crois que c'est une des IA de Jovalise. Il essaie de passer le test de Turing en convainquant son interlocuteur qu'il est trop con pour le comprendre.