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.
Chaque fonctionnalité est portée par plusieurs sous-ensembles logiciels, et chaque sous ensemble logiciel porte plusieurs fonctionnalités. Ce qui peut donner une sorte de grosse matrice, avec beaucoup de lignes et de colonnes (selon la complexité du système).
De sorte que pour suivre l'avancement d'une fonctionnalité, il faut suivre l'avancement d'une multitude de sous ensembles logiciels, parfois réalisés par des personnes différentes. Et tant qu'il manque le moindre petit bout de "tuyau", alors la fonctionnalité n'est pas opérationnelle.
Et dans l'autre sens, un sous-ensemble logiciel ne sera terminé que quand il prendra en compte toutes les fonctionnalités qu'il porte.
Suivre l'avancement avec un tableur ou un diagramme de Gantt (MS Excel, MS Project, ou l'équivalent en logiciel libre) est fastidieux.
De surcroît, en logiciel, on utilise souvent des bouchons, pour tester un sous-ensemble tant que l'autre n'est pas prêt. Alors il faut aussi suivre tous ces bouchons, et ne pas oublier de tous les remplacer par du vrai code avant de livrer le système à l'utilisateur.
Pour fixer les idées, prenons l'exemple hypothétique et simplifié d'un système de téléguidage de tracteur.
Les fonctionnalités du système sont :
- programmer le parcours du tracteur
- programmer la tâche à réaliser (semis, tonte, …)
- piloter la trajectoire du tracteur par un matériel embarqué autonome
- piloter la réalisation des tâches par un matériel embarqué autonome
- suivre en direct le trajet et les indicateurs
- commander et faire le suivi à l'aide d'une tablette Android
Les sous-ensembles hardwares sont :
- un Raspberry Pi dans le tracteur pour recevoir les commandes et piloter le tracteur
- une tablette pour l'interface utilisateur
Dans un tel système il faut développer, configurer et maintenir les sous ensembles logiciels suivants :
- tablette : OS Android
- tablette : communication avec le Raspberry Pi
- tablette : interface de préparation du parcours
- tablette : interface de suivi du tracteur
- Raspberry Pi : kernel et distribution Linux
- Raspberry Pi : drivers (pour piloter le tracteur)
- Raspberry Pi : hot spot wifi
- Raspberry Pi : logiciel de calcul de parcours
Pour la fonctionnalité "piloter la trajectoire", on pourra dire qu'elle est terminée dès lors que les sous-ensembles logiciels suivants seront "câblés" :
- l'OS du Raspberry Pi, avec paramétrages ad hoc
- le driver GPS
- les drivers de contrôle du tracteur (direction, accélération, mesure de la vitesse)
- le stockage de la feuille de route (en RAM ou en mémoire persistente)
- le logiciel calculateur de la trajectoire
Bref, on arrive vite à beaucoup d'items, et à des tableaux ou des listes qui ne tiennent plus sur un écran. Avez-vous des méthodes ou des actuces pour suivre plus efficacement tout cela ?
# gitlab ?
Posté par olive12 . Évalué à 3.
Salut ,
je sais pas ce que ca vaut mais un blogueur du nom de Genma parlait du gestionnaire integré a gitlab (mode kanban..) qui apparemment est bien puissant pratique et efficace.
# on appelle ca de la gestion de projet
Posté par NeoX . Évalué à 2.
tu as des ressources, des hommes/femmes, des calendriers de disponibilités.
tu as des dependances entre tout ca,
et il y a des outils pour ca, ou des methodes,
KABAN, GANTT…
# Si c'est pour 2/3 personnes
Posté par MrBidon . Évalué à 8.
Si c'est juste pour donner une date à un chef ou autre quidam du genre, et que je n'encadre pas une armée de mexicains (2/3 personnes moi compris).
Je prend une heure avec Open Calc, je macro chiffre les taches selon les trois étapes : Spec/dev/test/doc. Je combine le tout avec la fonction SERIE.JOUR.OUVRE et ça donne des dates potentielles de sortie du bidule. Ca fait sérieux et de toute façon la date ne sera pas tenue car il y a 1000 autres trucs à faire qui seront arrivé d'ici là.
[^] # Re: Si c'est pour 2/3 personnes
Posté par goeb . Évalué à 2.
Justement, ces "1000 autres trucs à faire", comment peut-on les quantifier ? les prévoir ?
En réservant une enveloppe globale de x jours par mois ?
[^] # Re: Si c'est pour 2/3 personnes
Posté par BAud (site web personnel) . Évalué à 3. Dernière modification le 07 juin 2018 à 22:57.
bin ça fait partie des 10% ou 20% de portefeuille de jours proposés pour rajouter des fonctionnalités ou les préciser en cours de route (pour celles identifiées comme non stables initialement). Ça s'appelle aussi « avenant » mais là ça emmerde les 2 côtés et les dates ne sont sans doute pas tenues (e il y aura rejet de la faute, toussa toussa et personne n'en ressort gagnant généralement).
Il y a aussi d'autres méthodes, mais ça dépend d'éléments que tu n'a pas précisés :
L'organisation de l'équipe et les recours ne sont pas les mêmes, l'outillage peut être le même si déjà en place et instanciable.
[^] # Re: Si c'est pour 2/3 personnes
Posté par MrBidon . Évalué à 1.
Généralement oui je compte un certain pourcentage pour ces autres truc par exemple 10% de support, 10% de gestion de projet (si il y a des réunions).
# Se poser les bonnes questions
Posté par Michaël (site web personnel) . É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.
[^] # Re: Se poser les bonnes questions
Posté par goeb . Évalué à 1.
Oui.
Ah oui, c'est une bonne idée.
J'avais essayé Task Juggler il y a quelques années, et j'avais trouvé difficile de tenir à jour semaine après semaine :
- l'avancement plus ou moins rapide des tâches
- le changement d'affectation des tâches entre développeurs
- la segmentation de tâches en plus petites ou la fusion de plusieurs en une seule
- le changement de priorité des tâches
- le blocage d'une tâche par un évenement externe (attente d'une réponse)
- l'insertion de tâches inopinées
Et quand on a 300 tâches de 3 jours avec 5 développeurs, ça prend pas mal de temps à tenir à jour.
[^] # Re: Se poser les bonnes questions
Posté par BAud (site web personnel) . Évalué à 3. Dernière modification le 07 juin 2018 à 23:00.
ton objectif, c'est de fliquer les dév' ou d'arriver à livrer en temps et en heure ?
Pour 5 développeurs, ton problème est un peu trivial si tu bosses avec eux :-) après si tu veux faire de la justification pour de la justification, bah…
[^] # Re: Se poser les bonnes questions
Posté par goeb . Évalué à 1.
Le but est d'une part de savoir quand on aura terminé, et d'autre part de détecter si un développeur a des difficultés et a besoin d'aide.
[^] # Re: Se poser les bonnes questions
Posté par BAud (site web personnel) . Évalué à 3.
euh, tu ne passes jamais voir tes équipes ô_Ô ?
[^] # Re: Se poser les bonnes questions
Posté par goeb . Évalué à 2.
De nombreuses personnes ne disent pas spontanément qu'elles ont besoin d'aide :
Donc il faut en effet passer voir les équipes. Et demander où chacun en est, et savoir où il devrait en être. D'où un système de suivi.
[^] # Re: Se poser les bonnes questions
Posté par Michaël (site web personnel) . É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.
[^] # Re: Se poser les bonnes questions
Posté par BAud (site web personnel) . Évalué à 2.
tu mélanges àmha gestion à la semaine et dimensionnement effectif de l'équipe, pourrais-tu clarifier ton propos en séparant bien les deux ? (l'un est à la semaine/mois pour l'organisation de l'équipe/tenue des délais projets, l'autre au trimestre/semestre pour optimisation/respect des obligations contractuelles dans un cadre de centre de service)
[^] # Re: Se poser les bonnes questions
Posté par Michaël (site web personnel) . Évalué à 2.
Comment est-ce que tu en viens au dimensionnement de l'équipe? Pour la discussion jusqu'ici ce n'est pas une variable.
[^] # Re: Se poser les bonnes questions
Posté par BAud (site web personnel) . Évalué à 2.
bin quand tu dis :
l'étape classique d'après est le mythe du mois.homme ;-)
[^] # Re: Se poser les bonnes questions
Posté par Michaël (site web personnel) . Évalué à 2.
C'est complètement bidon comme estimation, mais ce que dit le bouquin de l'autre c'est qu'en fait on est à peu près sûr que ça va prendre vachement plus de temps. Du coup comme ma phrase finit par “on voit mal comment…” c'est pas une faut de raisonnement, non?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.