Loading...Depuis plusieurs semaines nous travaillons au sein du département « Logiciels & Applications » de la DSI à la définition de ces processus liés au développement d’applications. La part du développement d’outils spécifiques par rapport à des outils à licences est de l’ordre de 95%. En effet, nous avons décidé que Pentalog était aussi une « solution logicielle » composée d’outils « maison » et d’outils OpenSource. Les processus de développement sont donc essentiels dans le fonctionnement de ce département.
Notre approche sur les processus n’a pas été de faire rentrer toute notre activité dans un processus, ce n’est pas assez précis pour les équipes qui ont à les mettre en œuvre et de par la diversité de ce qui est fait, il y aurait de disparité. Nous avons donc décidé de mettre en œuvre 4 processus qui correspondent à l’activité du département :
1/ Processus innovant
L’objectif de ce processus est de prendre en compte les projets où la part de recherche est importante et qu’à la suite de cela les résultats ne sont pas garantis, la piste technologique pouvant être une impasse, un échec. Il faut donc un processus l’acceptant. Même si le Labbs (http://www.pentalabbs.com) a pour vocation les approches R&D, ce département doit maîtriser le processus car il doit être capable également de proposer (ou répondre) à ces clients sur des cas de figure en dehors des pratiques standards. Bien sur, ce sont ces projets qui sont le plus candidats au CIR (crédit d’impôts recherche). C’est pour cette raison que le processus intègre les exigences documentaires de ce dispositif.
2/ Processus rapide
L’urbanisation de notre SI s’appuie sur un ensemble d’applications très ciblées sur un besoin métier et intégrées dans une architecture SOA/BPM. Ce processus est donc très important pour permettre de répondre aux réactivités requises par les clients. Ces petites applications dont la charge serait inférieure à 100j (suivi de projet compris) ont pour objectifs de déployer très rapidement des applications verticales, simples et robustes sur des technologies et méthodes éprouvées ; les ressources humaines devant également être préparées. Plusieurs processus rapides pourraient être enchaînées, mais la démarche ne sera pas de concevoir de gros projets de cette manière à un moment donné, il faut passer à un processus industriel pour disposer des garanties suffisantes.
3/ Processus industriel
Les projets stratégiques et conséquents dont le terme n’est pas court suivront ce processus. On prévoit ici un processus complet de développement avec toutes ces phases précises de contrôle. Pour ce type de processus, nous déploierons le processus utilisé par la production Pentalog qui évolue actuellement vers un alignement aux exigences du CMMi. Toute la suite de bonnes pratiques sera donc mise en œuvre pour assûrer ces projets ambitieux et sensibles : Capitalisation des connaissances, Amélioration continue, Revue de codes (automatique), intégration continue … Nous irons même sur ces projets jusqu’à l’intégration de tests automatiques.
4/ Processus d’intégration d’outils extérieurs
Même si notre approche principale est de disposer de nos propres outils réalisés dans nos « usines » de Brasov & Hanoï (localisation de l’effectif de ce département), nous n’évitons pas l’intégration d’outils externes. Nous avons déjà largement intégrés des outils métiers (Mantis, Testlink, …). Les déclinaisons de Mantis sont d’ailleurs nombreuses (gestion des actions d’amélioration continue, interrogation du service administratif & financier, …). Nous préparons donc ce processus sur la base de compatibilité d’outils externes à nos règles d’intégration dans le SI mais également de l’accompagnement des utilisateurs dans la prise en main de ces outils et surtout à la capitalisation des connaissances.
Bien sûr en parallèle de tout cela, il y a le processus de maintenance des applications une fois que l’application est passée en production. Mais cela fera l’objet d’un futur article.
Pour chacun de ces processus, nous avons défini des règles et conditions :
– Quelles sont les règles d’éligibilité d’un projet sur un processus ? Tous ne doivent pas être innovants ou industriels par facilité ou exigence particulière. L’ampleur (charge), la complexité, les risques encourus avec le projet, l’évolution à venir de l’application, … sont les principaux que nous avons retenus.
– Quelles sont les technologies acceptées par processus ? Même notre SI a pu être à une époque une vitrine de nos capacités technologiques, nous resserrons le spectre technologique pour assûrer une cohérence plus importante et une meilleure gestion des compétences de l’équipe. La limitation du spectre technologique doit nous permettre une plus grande réutilisation des composants. En effet, pour les composants liés au SSO, WebServices, Interfaces graphique, BPM, si nous nous aménageons une bibliothèque de composants, nous générerons des gains substantiels dans la réalisation de nos outils.
– Quelles sont les règles d’évaluation de la charge d’un projet ? Suivant le processus choisi, nous pourrons appliquer des unités d’œuvre différentes par processus mais systématiquement basées sur une méthode de dénombrement commune. En effet, comme sur ces différents processus, les tâches ne sont pas les mêmes, nous nous mettons en place des matrices différentes qui évaluent les tâches de chacun à partir du processus.
– Quelles sont les conditions de passage d’un processus à l’autre ? On peut commencer une application sur un processus rapide puis la passer sur un processus industriel car les nouveaux critères d’éligibilité ont changé avec le temps. On a donc donné quelques limites réfléchies comme indicateurs mais rien ne sera systématique.
– Quelles sont les exigences des clients ? Sur un processus de quelques semaines, les exigences en terme de reporting (contenu, fréquence, …) ne sont pas les mêmes qu’un projet de plusieurs mois ou années homme. Il en va de même sur l’implication du client sur le projet. Les demandes d’évolution s’organisent aussi différemment. Les exigences du client doivent donc être adaptées.
– Quelles sont les règles financières du projet ? Il faut en effet prendre en compte au plus tôt si un amortissement est possible et quelles parties du projet sont concernées. Suivant le sujet, il faut aussi se poser la question sur ce qui pourrait être intégré au dispositif CIR.
– Quelles sont les règles de gouvernance du projet ? La décision d’affectation d’un projet, bien que les critères d’éligibilité soient clairement définis, est dépendante d’un comité assurant la gouvernance des projets pour que les contraintes du client, du département et de la direction soient prises en compte.
– Quelles sont les exigences communes aux différents processus ? Nous allons donc gérer plusieurs « vitesses » au sein du département. Il faut toutefois maintenir une cohérence sur l’ensemble : le suivi de projet (temps prévus/passés/reste à faire), la traçabilité des exigences, la rédaction de cas de test, le cycle de livraison devraient faire partie de ce socle commun.
– Quel est l’impact sur les ressources humaines ? Nous n’avons pas encore définitivement décidé si des personnes étaient affectées à des processus (très bonne connaissance de celui-ci) ou s’ils pouvaient passer de l’un à l’autre. Je pencherai pour l’adaptation progressive pour nous assûrer une souplesse dans l’organisation. Dans tous les cas, nous avons prévu une formation des équipes pour que cette vision de l’organisation soit partagée.
– Quels sont les gains attendus ? En adaptant le processus aux besoins, on adapte également le processus à l’échéance des gains attendus. Les processus rapides doivent générer des gains très rapidement, sans quoi le projet n’est peut être pas essentiel.
– Quelles sont les règles d’intégration de nouveaux outils dans le SI ? Nous avons également défini les exigences d’intégration des outils dans le système d’information pour garantir une cohérence des pratiques dans les interfaces graphiques, les capacités de communication (WebService / BPM), les performances et le niveau de sécurité requis.
On ne peut pas tout concevoir dans un atelier, on ne peut pas tout concevoir dans une usine. Ce département s’organise donc en usine et atelier pour répondre au mieux aux besoins de nos clients (et collègues). Les prochains nouveaux outils suivront donc ces règles d’éligibilité. Je communiquerai dans quelques mois (autres épisodes de la saga) sur les gains mesurés de ces différentes approches pour l’équipe projet et nos interlocuteurs.
Tous ces choix sont en cours d’intégration par Iulia (la responsable de ce département) dans un PQS (Plan Qualité Services). Nous réfléchissons si de son côté le département Infrastructure de la DSI ne pourrait appliquer la même approche.
Fin du premier épisode. Captivé pour la suite ?
