## 5. Comment travailler ensemble : Le développement informatique est un domaine très abstrait, qui déroute nombre de décideurs par ses spécificités. De ce fait, nombre de contractualisations classiques mais inadaptées prédestinent à l'échec les projets informatiques qu'elles encadrent. Nous tenons à partir sur de bonnes bases au plus tôt, pour faire de notre collaboration un succès. Si vous avez besoin de vous en convaincre, le Standish Group réalise depuis 1994 des rapports globaux sur les projets informatiques qui aboutissent ou non et leur facteurs de succès. ### 5.1. Facteur d'échec et succès des projets informatique <!-- cf annexe Facteur d'échec et succès des projets informatique --> Voici une infographie récapitulative tirée du dernier rapport public du Standish Group :<br/> le [CHAOS Report 2015](https://standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf).  **Légende et traduction :** - **Waterfall :** Modèle de conduite de projet en [cascade](https://fr.wikipedia.org/wiki/Mod%C3%A8le_en_cascade), similaire au cycle en V. Adapté aux projets industriels où tout concevoir en amont coûte moins cher que d'essayer et d'ajuster en cours de route. Inadapté à la conception de logiciel informatique, mais hélas répandu pour celle-çi par habitude. - **Agile :** Modèle de conduite de projet en synergie centré sur l'adaptation aux changements. La méthode SCRUM est la plus connue des métodes agiles, pour autant, c'est aussi la moins stygmergique d'entre elles. Sa popularité vient du fait qu'elle se rapproche d'avantage des modèles industriels déjà connus, ce qui rassure les décideurs, au prix d'une agilité moindre. Nous reprenons certains outils issue de SCRUM, mais sans s'y enfermer pour pousser notre agilité bien au dela. - **Successful :** Projets en production, ayant satisfait client et prestataire, tout en respectant globalement le cadre initialement négocié. - **Chalenged :** Projets ayant été mis en production, mais en ayant largement débordé du cadre inital (budget ou délais plus que doublés, satisfaction mitigée sur le produit livré). - **Failed :** Projet non livré ; livré mais jamais utilisé à cause de défaillances ou autres dysfonctionnements techniques (bugs), de l'ergonomie ou autre facteur de qualité délétaire ; livré mais jamais utilisé car trop inadapté aux besoins du client. - **All size projects :** Projets, toutes tailles confondu. - **Large size projects :** Projets de grande envergure. - **Medium size projects :** Projets de taille moyenne. - **Small size projects :** Petits projets. Pour approfondir, un article francophone sur le sujet : https://www.infoq.com/fr/articles/contract-model-failure/ <!-- Fin de la partie déplaçable en annexe --> ### 5.2. Notre approche Pour maximiser les chances que notre collaboration soit un succès, évitons les pièges habituels : Plutôt que de chercher à répondre à tout les besoins avec un gros projet in-maintenable et une contractualisation rigide basée sur des livrables prédéterminés (3 % de réussite, 42 % d’échec total), nous réduisons la complexité avec une réponse aux besoins sous la forme d’un écosystème de projets spécialisé, compatible entre eux, et développé de manière agile avec une contractualisation qui permet de s’adapter au fur et à mesure pour rester au plus près de l’évolution de vos priorités (58 % de réussite, 4 % d’échec). <!-- La création de logiciel est similaire à un travail de recherche, c'est un processus continu d’essai et d’erreur. Cette création n'est pas une production prévisible. Promettre ce qu’on va trouver à l’issue d’une recherche ne marche pas, et multiplier les publications pour faire du ranking mène à des publications vides de sens. Il en va de même pour le développement logiciel. Ce sur quoi il est possible de s’engager, c’est sur la méthode de collaboration (agilité dans les process, démarche qualité, gouvernance) et les ressources allouées (temps d’ingénieurie logicielle). --> De même, estimer le temps nécessaire à concevoir et réaliser ce qui n’existe pas encore est une activité à laquelle sont traditionnellement consacrés entre 10 et 30 % du temps et budget d’un projet, pour un taux de fidélité dans les estimations proche de zero, ainsi qu'un stress généré à des endroits préjudiciables à la qualité voir à la viabilité du projet. Il existe des moyens nettement plus fonctionnels de gérer les risques d’un projet logiciel innovant, comme l’approche no-estimate et la matrice de compromis, afin de s’assurer le résultat le plus satisfaisant possible pour chaque stackeholder et ainsi permettre une collaboration féconde, quelques soient les imprévus rencontrés. ### 5.3. Comment prioriser pour une collaboration fructueuse Voici la [matrice de compromis](http://brunosbille.com/2015/04/19/la-matrice-des-compromis-en-cas-de-problemes-quajusterons-nous/) qui nous semble la plus adaptée pour une collaboration fructueuse entre nous.  Concrètement, le cadre que nous vous proposons pour travailler ensemble est le suivant : - **Maximiser la qualité**, c’est ce qui vous évitera les déceptions à court, moyen et long terme, qui vous apportera satisfaction, et renforcera notre réputation. Par exemple, il s’agit de développer en TDD (Test Driven Development, pratique qui consiste à développer les tests avant d'écrire le code applicatif.) les aspects métier des logiciels, de pratiquer du pair-programming et des revues de code quand c’est humainement possible, de mettre en lien direct les personnes qui rencontrent un problème et celles qui le résolvent… - **Maîtriser le budget** alloué aux projets : vous choisissez le prix, nous y adaptons les ressources humaines dédiées à répondre à vos enjeux tout au long de l’année. - **Minimiser les délais** entre une requête prioritaire et la publication de la mise à jour du logiciel correspondant pour y répondre. Pour cela, priorisation des requêtes, intégration et déploiement continue nous permettent de réduire, dans les cas les plus simple à résoudre, à moins d’une heure le délais entre votre souhait et la mise à disposition de sa concrétisation. Dans les cas plus complexe, vous pourrez suivre et tester les évolutions au quotidien et nous faire partager vos enthousiasmes et difficultés afin de nous permettre d’ajuster au plus tôt la fonctionnalité en cours pour qu’elle corresponde parfaitement à vos enjeux. Elle pourra ainsi se déployer en production sitôt après vous avoir satisfait. - **Fluidifier le périmètre fonctionnel** : Plutôt que d’imaginer précisément ce que vous voulez avant d’avoir pu le tester, découvrez la fluidité de pouvoir essayer, changer d’avis, prioriser, reprioriser tout au long du projet, et avoir une équipe qui s’adapte à vous au fur et à mesure que s’affine ce qui compte vraiment pour vous. Ainsi au rythme de vos ajustements et des ressources humaines à votre service, ce qui est prioritaire pour vous sera priorisé chez nous, et ce qui s’avère secondaire pour vous passera après, ou jamais si vous avez toujours d’autres priorités.