Comment faites-vous pour suivre l'avancement du développement logiciel sur l'ensemble d'un système ?
Le but du suivi est de plannifier un minimum et de prévoir les ressources (humaines et matérielles) dans le temps.
Je pense que les problèmes commencent ici. Planifier et prévoir est d'une part impossible et d'autre part n'est pas une fin en soi. Le problème théorique de base de la gestion de projet*s* (eh oui, souvent ils sont plusieurs :D) est plutôt "Étant données mes ressources et mes projets, quels sont les dates de livraisons raisonnables pour chacun de mes projets? (Et comment atteindre ces dates?)" C'est précisément le problème que résout le logiciel Task Juggler (un logiciel libre).
Selon les projets ou les organisations la place que va prendre cet outil et la réponse aux questions qu'il apporte vont être très différents. Par exemple pour une entreprise les projets peuvent perdre de la valeur (pénalités) s'ils sont en retard, voire ne plus avoir de valeur du tout. On veut aussi en général savoir le plus tôt possible si un rendez-vous semble difficile à tenir, évaluer des scénarios alternatifs ou envisager d'autres réactions. On se demande aussi quelle est la plus proche date de commencement possible pour un nouveau projet et quelle serait donc la date de fin. D'autres entreprises ou organisations vont avoir des besoins assez différents et à charge de chacun de développer et ajuster sa méthodologie et son fonctionnement pour tirer parti au mieux de l'information que peut livrer Task Juggler et avoir l'information la plus fiable possible.
Je peux décrire rapidement ce qu'on fait chez nous. On écrit des offres pour nos clients, qui sont valides 2 semaines (en gl.). La plupart de nos projets font moins de 6 mois. On utilise Task Juggler pour répondre aux questions suivantes: A/à partit de quand peut-on travailler sur une nouvelle offre, quand serait la date de livraison possible et l'estimation grossière initiale va dans l'offre; B/lorsque l'offre est acceptée on part sur une modélisation plus fine pour détecter le plus tôt possible si un rendez-vous est risqué puis on suit l'avancement du projet pour détecter le plus tôt possible si un rendez-vous est risqué; et C/maîtriser notre "overbooking" (comme les clients laissent tomber des offres on overbook un peu pour toujours avoir du travail).
Notre façon de modéliser les tâches dans Task Juggler est de tout découper en tâches qui font entre 1 et 4 jours si possible. Une partie importante est de modéliser les relations de blocage. On ajoute un buffer dont on calcule la taille en fonction de l'expérience de l'équipe vis à vis du projet (déjà fait mille fois on fait du 30%; on va rarement au delà de 100%). Pour les projets longs on ajoute aussi 1 ou 2 semaines (pour les impondérables de type maladie ou bref congé) . Comme on n'a pas de contraintes matérielles on n'a pas besoin de modéliser l'utilisation d'équipements etc. En plus des congés on modélise aussi notre force de travail hebdomadaire en allouant 8 jours par mois aux bugs, 2 jours par mois au "hacking" perso, 3 jours par mois aux réunions, et une efficacité (en général 0.7 pour un développeur à plein temps, en général moins pour ceux qui on plusieurs casquettes). Pour nos besoins, le système tourne assez bien, c'est à dire qu'on tient à peu près nos rendez-vous.
Je pense que tu as du largement sous-exprimer ton problème parcequ'en relisant ton message j'ai l'impression que ce qui t'intéresse est essentiellement de savoir quand tu as fini. (Tu ne parles pas de temps, et pour les ressources, tu les évoques sans poser de question concrète.) Du coup je serais tenté de te répondre que n'importe quel système de tickets devrait répondre à tes besoins. Si tu cherches un logiciel libre plutôt simple et efficace, je peux te suggérer Trac dont le look fait toujours très années 2000, mais ça reste un des mes outils préférés. Voir la Roadmap.
# 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.
Je pense que les problèmes commencent ici. Planifier et prévoir est d'une part impossible et d'autre part n'est pas une fin en soi. Le problème théorique de base de la gestion de projet*s* (eh oui, souvent ils sont plusieurs :D) est plutôt "Étant données mes ressources et mes projets, quels sont les dates de livraisons raisonnables pour chacun de mes projets? (Et comment atteindre ces dates?)" C'est précisément le problème que résout le logiciel Task Juggler (un logiciel libre).
Selon les projets ou les organisations la place que va prendre cet outil et la réponse aux questions qu'il apporte vont être très différents. Par exemple pour une entreprise les projets peuvent perdre de la valeur (pénalités) s'ils sont en retard, voire ne plus avoir de valeur du tout. On veut aussi en général savoir le plus tôt possible si un rendez-vous semble difficile à tenir, évaluer des scénarios alternatifs ou envisager d'autres réactions. On se demande aussi quelle est la plus proche date de commencement possible pour un nouveau projet et quelle serait donc la date de fin. D'autres entreprises ou organisations vont avoir des besoins assez différents et à charge de chacun de développer et ajuster sa méthodologie et son fonctionnement pour tirer parti au mieux de l'information que peut livrer Task Juggler et avoir l'information la plus fiable possible.
Je peux décrire rapidement ce qu'on fait chez nous. On écrit des offres pour nos clients, qui sont valides 2 semaines (en gl.). La plupart de nos projets font moins de 6 mois. On utilise Task Juggler pour répondre aux questions suivantes: A/à partit de quand peut-on travailler sur une nouvelle offre, quand serait la date de livraison possible et l'estimation grossière initiale va dans l'offre; B/lorsque l'offre est acceptée on part sur une modélisation plus fine pour détecter le plus tôt possible si un rendez-vous est risqué puis on suit l'avancement du projet pour détecter le plus tôt possible si un rendez-vous est risqué; et C/maîtriser notre "overbooking" (comme les clients laissent tomber des offres on overbook un peu pour toujours avoir du travail).
Notre façon de modéliser les tâches dans Task Juggler est de tout découper en tâches qui font entre 1 et 4 jours si possible. Une partie importante est de modéliser les relations de blocage. On ajoute un buffer dont on calcule la taille en fonction de l'expérience de l'équipe vis à vis du projet (déjà fait mille fois on fait du 30%; on va rarement au delà de 100%). Pour les projets longs on ajoute aussi 1 ou 2 semaines (pour les impondérables de type maladie ou bref congé) . Comme on n'a pas de contraintes matérielles on n'a pas besoin de modéliser l'utilisation d'équipements etc. En plus des congés on modélise aussi notre force de travail hebdomadaire en allouant 8 jours par mois aux bugs, 2 jours par mois au "hacking" perso, 3 jours par mois aux réunions, et une efficacité (en général 0.7 pour un développeur à plein temps, en général moins pour ceux qui on plusieurs casquettes). Pour nos besoins, le système tourne assez bien, c'est à dire qu'on tient à peu près nos rendez-vous.
Je pense que tu as du largement sous-exprimer ton problème parcequ'en relisant ton message j'ai l'impression que ce qui t'intéresse est essentiellement de savoir quand tu as fini. (Tu ne parles pas de temps, et pour les ressources, tu les évoques sans poser de question concrète.) Du coup je serais tenté de te répondre que n'importe quel système de tickets devrait répondre à tes besoins. Si tu cherches un logiciel libre plutôt simple et efficace, je peux te suggérer Trac dont le look fait toujours très années 2000, mais ça reste un des mes outils préférés. Voir la Roadmap.