Des estimations correctes ? Mais c'est du foutage de gueule à l'état brut, ce que tu dis.
Chaque semaine la release prenait du retard, chaque semaine le nombre de bugs RC décroissait quatre fois moins vite que ce qui était attendu. Et à chaque point fait par les release managers, la réaction était : « on est en retard, eh bien il suffit de travailler plus, et on releasera à temps ».
Dans « release manager » il y a quand même « manager », et aucun des deux RM n'en avait la carrure. Steve Langasek est un excellent technicien, qui a une connaissance parfaite du projet, et abat un boulot absolument énorme ; il n'y a vraiment rien à redire quant à sa contribution technique. Andreas Barth est clairement un cran en-dessous, mais bon, il n'a quand même pas chômé, soyons gentils. En revanche ils ont été soit nuls soit malhonnêtes en gérant le projet :
ø début novembre, ils annoncent un retard du freeze mais pas de la date de release alors qu'il reste 310 bugs ;
ø début décembre, le jour qui aurait dû être celui de la release, il reste 160 bugs, toujours pas de freeze, et on a droit à un nothing too dramatic [...] in good progress ;
ø fin décembre, ils décident de freezer ; il reste 116 bugs alors que la limite avait été fixée à 80, ce qui signifie que le passage des paquets d'unstable à testing sera bien plus ardu, et que le nombre de bugs baissera plus lentement.
Et durant tout ce temps, aucune précision ou amélioration sur le nouveau calendrier ou les outils de gestion (lors de son premier rapport dunc-bank, Andreas Barth disait qu'il avait du mal à estimer les tendances de l'évolution du nombre de bugs parce qu'il aurait fallu pouvoir suivre séparément le nombre de bugs ouverts et le nombre de bugs fermés ; un mois -- de salaire -- plus tard, un tel graphe n'était toujours pas apparu). Alors elle est où, l'estimation correcte ? Dans mon cul, à mon avis.
[^] # Re: C'est qui Etch
Posté par Sam Hocevar . En réponse au journal Etch sous la barre des 100. Évalué à 8.
Chaque semaine la release prenait du retard, chaque semaine le nombre de bugs RC décroissait quatre fois moins vite que ce qui était attendu. Et à chaque point fait par les release managers, la réaction était : « on est en retard, eh bien il suffit de travailler plus, et on releasera à temps ».
Dans « release manager » il y a quand même « manager », et aucun des deux RM n'en avait la carrure. Steve Langasek est un excellent technicien, qui a une connaissance parfaite du projet, et abat un boulot absolument énorme ; il n'y a vraiment rien à redire quant à sa contribution technique. Andreas Barth est clairement un cran en-dessous, mais bon, il n'a quand même pas chômé, soyons gentils. En revanche ils ont été soit nuls soit malhonnêtes en gérant le projet :
ø début novembre, ils annoncent un retard du freeze mais pas de la date de release alors qu'il reste 310 bugs ;
ø début décembre, le jour qui aurait dû être celui de la release, il reste 160 bugs, toujours pas de freeze, et on a droit à un nothing too dramatic [...] in good progress ;
ø fin décembre, ils décident de freezer ; il reste 116 bugs alors que la limite avait été fixée à 80, ce qui signifie que le passage des paquets d'unstable à testing sera bien plus ardu, et que le nombre de bugs baissera plus lentement.
Et durant tout ce temps, aucune précision ou amélioration sur le nouveau calendrier ou les outils de gestion (lors de son premier rapport dunc-bank, Andreas Barth disait qu'il avait du mal à estimer les tendances de l'évolution du nombre de bugs parce qu'il aurait fallu pouvoir suivre séparément le nombre de bugs ouverts et le nombre de bugs fermés ; un mois -- de salaire -- plus tard, un tel graphe n'était toujours pas apparu). Alors elle est où, l'estimation correcte ? Dans mon cul, à mon avis.