J'avais essayé Task Juggler il y a quelques années, et j'avais trouvé difficile de tenir à jour semaine après semaine [...]
Oui c'est difficile, mais c'est un peu dans la nature des choses puisque le problème est complexe. Ce qui est important c'est de considérer le logiciel comme un outil et pas comme un oracle et donc de critiquer l'usage qu'on en fait.
Ce que tu observes c'est que c'est beaucoup de travail de tenir à jour une information détaillée et que ce n'est pas évident de trouver un équilibre entre le niveau de détail recherché et les bénéfices qu'il apporte. Il faut donc avoir bien en tête les questions auxquelles on veut répondre et critiquer la modélisation qu'on en fait.
Dans l'exemple que tu décris, en se disant qu'on peut dégager 3,5 jours de travail par semaine sur les tâches en elles-mêmes par développeur, on voit mal comment l'équipe pourrait sortir le truc en moins de 15 mois (calendrier) sans contre-temps majeur (ce qui me semble parfaitement illusoire, ça n'a aucune chance d'arriver!). Si d'un côté c'est important d'arriver au niveau de tâches d'un effort de quelques jours – pour avoir une estimation fiable par les développeurs – ce n'est en revanche pas forcément judicieux d'avoir ce niveau de détail dans taskjuggler. Si tu commences vendredi 1 juin, est-ce que ça te sert à quelque chose de travailler 1/2 journée à la mise à jour des tâches dans taskjuggler pour savoir le vendredi 8 juin que tu as 1/2 journée d'avance ou de retard sur le planning? Sans l'exclure tout à fait (je ne connais pas ton cas!) j'en doute fortement.
L'idéal serait plutôt de passer en mode "agile" en découpant le projet en une grosse dizaine d'itérations qui ont une plus-value pour toi ou ton client, ou bien si c'est pas trop possible en trouvant une grosse dizaine de rendez-vous d'étape qui sont autant d'occasions de réévaluer la date de livraison plausible.
Une fois qu'on a ces rendez-vous le but est de modéliser les situations bloquantes: on n'a pas besoin de Task Juggler pour dire qu'Alice qui programme en Java va faire les tickets Java et Bob le programmeur Python va faire les tickets Python. Par contre si on se rend compte qu'en sixième semaine le designer aurait besoin de finaliser les plaquettes commerciales pour l'exposition machin, le projet final pour le client (parce qu'on lui a promis une date comme ça au pif au début du projet) et les graphiques pour la livraison du troisième module – et que du coup il vaudrait mieux s'organiser autrement, parcequ'au moindre pépin c'est la cata, ça c'est utile. Concrètement ça peut suffire de faire dans Task Juggler de faire des gros paquets (genre le premier mois Alice faits les tickets T1, T2, T3 et T4 comme une tâche dans TJ) en les cassant juste assez pour exprimer les conditions les plus importantes. Comme tu as des phases qui utilisent du matériel, cela peut-être assez compliqué mais il faut aussi critiquer sa modélisation. Dans l'exemple que tu donnes avec les tracteurs, les tablettes et les raspberry-pi, tu peux partir du principe qu'il vaut mieux se dire qu'on pire on achètera plus de pis et de tablettes au lieu de faire une modélisation hyper détaillée de leur disponibilité. Le tracteur lui est peut–être plus important, surtout s'il est customisé parcequ'il n'y a pas d'expédient rapide (type location ou achat) qui permette de sauver les meubles.
[^] # Re: Se poser les bonnes questions
Posté par Michaël (site web personnel) . En réponse au message méthode de suivi de développement logiciel. Évalué à 3.
Oui c'est difficile, mais c'est un peu dans la nature des choses puisque le problème est complexe. Ce qui est important c'est de considérer le logiciel comme un outil et pas comme un oracle et donc de critiquer l'usage qu'on en fait.
Ce que tu observes c'est que c'est beaucoup de travail de tenir à jour une information détaillée et que ce n'est pas évident de trouver un équilibre entre le niveau de détail recherché et les bénéfices qu'il apporte. Il faut donc avoir bien en tête les questions auxquelles on veut répondre et critiquer la modélisation qu'on en fait.
Dans l'exemple que tu décris, en se disant qu'on peut dégager 3,5 jours de travail par semaine sur les tâches en elles-mêmes par développeur, on voit mal comment l'équipe pourrait sortir le truc en moins de 15 mois (calendrier) sans contre-temps majeur (ce qui me semble parfaitement illusoire, ça n'a aucune chance d'arriver!). Si d'un côté c'est important d'arriver au niveau de tâches d'un effort de quelques jours – pour avoir une estimation fiable par les développeurs – ce n'est en revanche pas forcément judicieux d'avoir ce niveau de détail dans taskjuggler. Si tu commences vendredi 1 juin, est-ce que ça te sert à quelque chose de travailler 1/2 journée à la mise à jour des tâches dans taskjuggler pour savoir le vendredi 8 juin que tu as 1/2 journée d'avance ou de retard sur le planning? Sans l'exclure tout à fait (je ne connais pas ton cas!) j'en doute fortement.
L'idéal serait plutôt de passer en mode "agile" en découpant le projet en une grosse dizaine d'itérations qui ont une plus-value pour toi ou ton client, ou bien si c'est pas trop possible en trouvant une grosse dizaine de rendez-vous d'étape qui sont autant d'occasions de réévaluer la date de livraison plausible.
Une fois qu'on a ces rendez-vous le but est de modéliser les situations bloquantes: on n'a pas besoin de Task Juggler pour dire qu'Alice qui programme en Java va faire les tickets Java et Bob le programmeur Python va faire les tickets Python. Par contre si on se rend compte qu'en sixième semaine le designer aurait besoin de finaliser les plaquettes commerciales pour l'exposition machin, le projet final pour le client (parce qu'on lui a promis une date comme ça au pif au début du projet) et les graphiques pour la livraison du troisième module – et que du coup il vaudrait mieux s'organiser autrement, parcequ'au moindre pépin c'est la cata, ça c'est utile. Concrètement ça peut suffire de faire dans Task Juggler de faire des gros paquets (genre le premier mois Alice faits les tickets T1, T2, T3 et T4 comme une tâche dans TJ) en les cassant juste assez pour exprimer les conditions les plus importantes. Comme tu as des phases qui utilisent du matériel, cela peut-être assez compliqué mais il faut aussi critiquer sa modélisation. Dans l'exemple que tu donnes avec les tracteurs, les tablettes et les raspberry-pi, tu peux partir du principe qu'il vaut mieux se dire qu'on pire on achètera plus de pis et de tablettes au lieu de faire une modélisation hyper détaillée de leur disponibilité. Le tracteur lui est peut–être plus important, surtout s'il est customisé parcequ'il n'y a pas d'expédient rapide (type location ou achat) qui permette de sauver les meubles.