div trav logiciel

Division du travail exemple du logiciel

exemple de division du travail dans le développement d'un logiciel

on dit qu'il y a une division verticale et une division horizontale avec des tâches verticales et des tâches horizontales puis des personnes affectées aux tâches verticales et des personnes affectées à des tâches horizontales

supposons que le logiciel a des morceaux 1 2 5 6 B et I

la division du travail de façon verticale serait d'affecter

1 2 à une personne

5 6 à une personne

B à une personne

I à une personne

on appellera B l'entrée

I la sortie

1 2 la synthèse

et 5 6 les détails

on aura 4 personnes chacune s'occupant de sa spécialité qui est spécifique avec ses problèmes ses difficultés ses détails à connaître et sa compétence particulière à régler le développement et l'évolution de cette partie verticale

la parttie B est une BD qui a les particularités de la Base de données

la partie 1 2 5 6 dont des états avec des calculs des consolidations

la partie I c'est la sortie avec les mises en forme pour l'impression

plus on divise et spécialise plus les gens deviennent compétents dans leur domaine que ce soit pour développer , expérimenter, dépanner, faire évoluer

d'autre part au delà de la division verticale on peut faire la division horizontale

la conception sera faite par une petit équipe restreinte composée du chef de projet et de un ou deux analystes chevronnés avec validation de la part des supérieurs informatiques et des clients bancaires (car il s'agit d'un logiciel de comptabilité bancaire)

le paramétrage une fois bien conçu, validé et testé fiabilisé en tant que méthode sera confié à un spécialiste du paramétrage qui travaillera en communication avec les responsables verticaux. il prendra en entrée les demandes et maquettes des utilisateurs et rendra en sortie les paramètres qu'il diffusera aux différentes parties verticales (entrée base de donnée, transcodage calculs traitement consolidation, sortie mise en forme impression) 

les tests recette livraisons seront regroupés dans une autre équipe horizontale qui réceptionne teste vérifie valide consolide intègre et livre selon une autre logique et un autre mode de travail que les développeurs verticaux qui eux aussi doivent tester en sortie de leur partie. la logique de cette partie serait de faire des modèles parallèles sous excel pour valider les logiciels sous db2 et cobol et aussi de monter des chaînes de recette pour prouver la complétude des livraisons décourvrir les erreurs au niveau de l'intégration , déceler les imperfections de coordination et relations entre différentes modules , d'assurer la cohérence exactitude et conformité de la chaîne toute entière avant la livraison, de faire la gestion des composants à livrer et le suivi du cycle de vie des composants de la création jusqu'à l'archivage.

si on limite les tâches horizontales à environ trois tâches conception, paramétrage, recette intégration livraison gestion des composants   et du cycle de vie on obtient ceci

une personne pour l'entrée
une personne pour la sortie
deux personnes pour le traitement
donc 4 personnes pour les tâches verticales
une équipe pour la conception dont le chef de projet
une personne pour le paramétrage
un équipe pour le recette dont le chef de projet
donc environ 2  personnes de plus pour les tâches horizontales (paramétrage , recette intégration)
et un chef de projet qui participe à la conception et paramétrage au début, à la recette et livraison à la fin et à la coordination communication au milieu

ce qui fait 4 verticaux 2 horizontaux et 1 coordinateur

quelle est l'utilité de cette organisation cette division du travail

s'il n'y avait pas le chef de projet qui conçoit tout avec son équipe de conception au départ qui communique aux intervenants au fur et à mesure de leur arrivée qui contrôle la qualité à la fin qui joue le rôle de débuggeur universel dépanneur de toutes les parties avec les responsables de chaque partie alors le logiciel ne tiendrait pas debout en qualité fiabilité évolutivité le chef de projet c'est l'âme du logiciel c'est le concepteur celui qui a fait naître qui fait évoluer qui optimise qui est garant de la qualité la continuité la robustesse et fiabilité la méthode et solidité la rareté des panne et le dépannage rapide en cas d'erreurs qui viennent de l'amont

donc le chef est indispensable

s'il n'y avait pas l'expert spécialiste en paramétrage alors le paramétrage par les différentes parties sera en constant conflit entre les parties et pas harmonieux si on optimise pour l'un on détériore pour l'autre. la tâche de paramétrage est mieux faite s'il y a un qui sait bien la faire et ne fait que cela

s'il n'y avait pas une équipe qui s'occupe de la recette il n'y aurait pas une réflexion profonde dessus, de l'innovation, invention, optimisation ,des outils pour faire la recette plus vite, plus puissante, plus exacte, plus performante, des chaînes plus complètes à lancer, des vérifications plus précises, des résultats plus justes, un environnement plus autonome, moins conditionné par les environnements de développement, plus proche de l'environnement d'exploitation

s'il n'y avait pas une spécialisation d'un personne dans la base de données évolution remplissage lecture écriture constitution gestion présentation maintenance administration alors c'est un problème de perte de temps et d'investissement de mettre au courant à chaque fois une nouvelle personne ou de confier à une personne qui se concentre ailleurs la tâche supplémentaire de gérer alimenter la base de donnée. une personne spécifique pour la base de donnée donnerait une compétence plus pure plus efficace du temps de réaction plus rapide des réponses plus justes des programmations moins dangereuses en contradictions et erreur. bref il vaut mieux quelqu'un qui connaît que quelqu'un qui ne connaît pas et pour que quelqu'un connaisse bien il faut qu'il vive dedans tous les jours comme cela il fait bien le travail qu'on attend de lui c'est à dire dès que l'utilisateur client demande une modification qui a un impact sur la base de donnée le spécialiste de la base de donnée sait immédiatement déterminer quels sont les impacts quel en est le nombre où sont situés le lieux d'impacts et quelles sont les modifications nécessaires à faire pour répondre à la demande du client

de la même façon l'utilité d'un spécialiste de la partie 1 2 ou 5 6 c'est exactement pour répondre aux même besoins c'est à dire dès réception de la demande d'évolution ou d'une sonnette d'alarme de panne l'expert responsable doit être capable instantanément d'analyser et de trouver la solution d'identifier où sont les endroits à toucher et comment les toucher comment faire les modification quels en sont les conséquences en coûts en temps et il doit surtout être sûr que s'il touche là cela va résoudre le problème cela va répondre à la demande c'est le plus sûr moyen le meilleur le moins cher et il doit être sûr aussi que cela ne va pas faire des casse par ailleurs qu'enlever une poutre ne va pas faire tomber le plafond qu'envoyer une produit chimique dans la nappe phréatique ne vas pas faire de la pollution quelques kilomètres plus loin à la sortie d'une autre source 

voilà en résumé l'argument pourquoi on fait la division du travail en tâches verticales c'est pour que chacun maîtrise mieux sa tâche assez complexe dans sa partie déjà assez grande pour que trop de compétences et de connaissances ne soient pas exigées d'une même personne et aussi de capacité de compréhension de mémoire de maîtrise du sujet.

quand aux tâches horizontales la division du travail permet de les aborder de façon plus concentrée plus sérieuse de mobiliser plus de créativité d'invention innovation optimisation pour plus d'efficacité plus de rentabilité plus de fiabilité plus de qualité moins de gaspillage de temps et d'argent pour améliorer les méthodes et les performances

par exemple dans la conception dégager une équipe spécialisée pour concevoir des logiciels plus solides plus performants plus cohérent plus évolutif plus souple plus réactif dans un brain-trust plutôt que laisser au hasard des responsables des parties verticales qui feront des contradictions entre eux. et dans la recette avoir un équipe (même si elle est puisée dans le temps des autres membres de l'équipe) permet de coordonner la recette la rendre plus complète lui permettre de bloquer cent pour cent des erreurs laissés par les tests individuels il faut que le test global ne laisse plus rien passer comme erreurs qu'il détecte tout qu'il ne génère pas les erreurs et incohérences lui même qui suive bien tous les composant qu'il n'en oublie pas et qu'il détecte vite et complètement les oublis des autres etc...

donc une équipe qui travaille et qui réfléchit sur les vérifications les test l'intégration qui monte les chaînes complètes qui innove dans les outils de tests de lancement rapide de relance répété de débugging dépannage c'est utile et c'est un investissement pour l'avenir pour la réduction des coûts du projet et pour l'augmentation de la qualité du logiciel et cette équipe n'est pas obligatoirement puisée à l'extérieur on peut former des équipes horizontales en puisant en partie sur les membres des équipes verticales sur une partie de leur temps mais c'est la concentration de réflexion qui fait la différence entre l'existence et l'utilité de l'équipe horizontale et la non existence de cette équipe et la négligence de ses tâches.

 si l'équipe horizontale n'existait pas alors chaque responsable vertical se concentrerait sur sa responsabilité verticale et il n'y aurait pas un bloc de travail horizontal de style industriel très performant donc il y aura des erreurs de programmation de la part des modules verticaux qui passeront en exploitation, des erreurs de livraisons, des manques, des oublis et aussi des imperfections de paramétrages, des contradictions de stratégie et le plus grave de tout des erreurs de conception gravissimes et erreurs d'analyse. D'où l'utilité de bien concevoir avant le développement avec une vue globale par une équipe dédiée pour cela et bien vérifier et  tester après avec également une équipe spéciale pour cela pour attraper tous les bugs traquer toutes les erreurs avant la mise en exploitation

conclusion

la division verticale du travail est nécessaire à cause de la limite de la tête d'une personne. s'il faut un grand travail il faut plusieurs personnes ayant chacune une partie à comprendre et à bien faire marcher car une seule personne ne peut pas tout faire ne peut pas tout comprendre tout maîtriser tout se rappeler être expert en tout. plus le projet est grand plus grand est le besoin de division du travail spécialisation chacun dans sa spécialité

la division horizontale du travail est nécessaire pour optimiser élever la qualité l'efficacité les performances réduire le coûts élever la productivité rendre moins chers les évolutions plus fiables les produits finis

on dit horizontale parce que les parce que le paramétrage est pour toutes les parties verticales, la conception est pour toutes les parties verticales et les vérifications tests intégration mise en exploitation gestion du cycle de vie des composant sont des tâches qui servent toutes les parties verticales , comme l'entrée Base de données, la sortie impressions, les calculs transcodages traitements consolidations les parties 12  5 6.

quand on trouve des tâches répétitives bien identifiées on a intérêt à optimiser automatiser fabriquer des outils logiciels pour les faire plus vite et mieux