Le défaut des gros projets est leur temps de réalisation. Le temps entre la prise de connaissance des besoins des utilisateurs et la livraison finale est très long. Vos utilisateurs peuvent changer leurs méthodes de travail et dans les cas les plus extrêmes, vous pouvez changer d’utilisateur final. Les risques que la solution finale ne convienne plus sont assez importants.
Un moyen pour pallier à ce problème est de diviser le projet en microlivraisons. Une microlivraison signifie qu’on livre une solution fonctionnelle régulièrement tout au long du projet. L’utilisateur peut rapidement commencer à intégrer l’outil dans son quotidien. Il aura donc une meilleure compréhension de ce que doit être le produit final.
L’autre aspect positif de livrer fréquemment aux utilisateurs finaux est la gestion du changement. L’être humain n’est pas capable de digérer trop de changements à la fois. Même avec les meilleurs analystes, les utilisateurs finaux ont trop de misère à visualiser le livrable final. Ils ont besoin d’avoir de quoi entre les mains régulièrement pour se sentir impliqués dans le projet.
Faisons une analogie avec la restauration. Aimeriez-vous un souper sept services où le serveur vous servirait tous les plats à la fin du repas et surtout au bout de 3 heures d’attente? Il aurait des assiettes froides et séchées, et la trop grande quantité de ces dernières sur la table envahirait votre espace. Les restaurants amènent un plat à la fois et ne laissent pas les clients attendre trop longtemps avec rien sur la table. Prenons des notes et appliquons ça aux TI !
C’est ce que par che nous on apelle un projet faite en ittérations. L’avantage de cette méthode est que sa permet de faire profiter dès maintenant du produit soit à tout les utilisateurs ou bien un groupe de testeurs, qui permet de voir si ce qui a été bâti en premier lieux est adéquoit aux besoins, et ainsi d’avoir le feedback des utilisateurs autre que ceux qui ont « passé la commande » (je fais allusion ici aux boîtes où il y a « la personne qui connais pomal tout et qui est bon en informatique itoo » qui est ta personne contact. Cette façon de faire également permet de mettre à l’épreuve l’analyse des besoins/solutions. C’est moins chiant corriger un détail en début de projet quand pas trop de choses ont été faite, mais quand tout le projet est fini, c’est une autre paire de manche. Et sans oublier que les clients aiment toujours voir, le lendemain si possible, un début d’interface.
Cependant, je crois qu’il ne faut pas oublier les inconvénients de cette solution. Cette dernière nous oblige à faire du support en cours de projet, et souvent pour des « codes 18″ qui ne comprennent pas que telle fonction n’a pas été complétée, mais que pour lui sa le lui prendrerai dès maintenant.
Également, sa apporte un surplus de travail comparé à la méthode en cascades (analyse, codage complet de l’appli, livraison, marci-bonsoire). En effet, cette nouvelle application, site web, etc, oblige de faire du travail supplémentaire pour installer la solution. Et si cette dernière utilise les mêmes structures de données actuelle que l’ancienne solution (c’est rare mais bon), il faut être aussi prudent, car ça pourrais causer des pépins, qui encore là, peuvent relever d’un code 18. L’utilisateur A enregistre son travail avec l’ancien logiciel, et l’utilisateur B utilise le nouveau. Si les deux n’utilise pas les mêmes « bases » de données, on risque d’avoir des problèmes sur la véridicité des données, ce qui pourrais causer d’importantes conséquences pour l’entreprise. Par exemple, un système d’inventaire, où les deux versions ne se parlent pas, on pourrais avoir des problèmes advenant qu’on utilise deux applications différentes.
Personnellement, j’ai toujours préféré par itération. Sa nous permet de se valider au fur et à mesure de l’avancement du projet, et de corriger les problèmes au fur et à mesure comparé à une seule livraison où même nous, on a l’impression que lors de «ze méga livraison», sa passe ou sa casse.
Et finalement, il ne faut pas perdre de tête que peu importe la solution et le moyen de la préparer, il faut toujours prendre le temps de réfléchir à ses impacts, implications et conséquences.