À quoi devriez-vous prêter attention lors de la rédaction des contrats pour les projets de développement ?

En règle générale, le prestataire plaidera pour un contrat de service. Mais attendez : il me manque toute la sécurité juridique pour obtenir ce que je veux ! C’est peut-être vrai. Mais alors que le contrat d’entreprise vous garantit ce que vous voulez, le contrat de service vous permet d’obtenir ce dont vous avez besoin. Le contrat d’entreprise, une fois conclu, livre exactement ce qui a été spécifié. Cela nécessite un véritable chef-d’œuvre de spécification. C’est précisément ce que nous voulions éviter. Au lieu d’écrire un roman de spécifications pendant trois mois, créons plutôt le premier prototype. Nous en bénéficierons beaucoup plus :

Je sais si le prestataire est capable de mettre en œuvre ce que je prévois.

Un contrat d’entreprise à lui seul ne me garantit pas que le prestataire puisse livrer du tout ou avec la qualité souhaitée. C’est certainement tentant pour les personnes qui aiment passer leur temps devant les tribunaux, mais un projet réussi a une autre apparence.

Trois mois de développement équivalent à trois mois d’expérience.

Une expérience qui peut être investie dans l’optimisation du plan. Je ne peux pas concevoir mon logiciel de manière si précise qu’aucun changement ne se produise. Ce qu’on oublie souvent, c’est que le logiciel est utilisé par de nombreux utilisateurs dans différents rôles. Penser qu’on peut se mettre complètement à la place des collègues et leur fournir l’outil optimal est un cas typique de surestimation de soi.

Évitement des problèmes de communication.

La communication est l’un des processus les plus complexes de notre vie, compte tenu de la facilité à communiquer et de la probabilité de mal comprendre. Pourquoi donc risquer qu’un projet soit mis en danger par une mauvaise interprétation d’une spécification écrite ? Notre perception est manipulée par divers facteurs tels que le passé, l’éducation et la formation. Dans le dialogue, je peux immédiatement éliminer ces malentendus et ainsi économiser du temps et de l’argent.

Donc, si vous rencontrez un prestataire qui vous présente un contrat d’entreprise, vous devriez être plutôt sceptique. Il est très probable qu’il souffre exactement de la surestimation mentionnée et ne développe pas de manière agile, mais « agile ».
Le développement agile fonctionne avec une avance de confiance, les approches classiques fonctionnent plutôt avec des promesses douteuses.

À quelles réunions devriez-vous participer ?

Une fois le contrat de service classé, le travail commence. Pour les développeurs et pour vous. Car le développement logiciel agile signifie un échange intensif. Le prestataire travaillant avec SCRUM s’attendra à ce que vous participiez à la revue de sprint et à la planification de sprint. Selon la taille de l’équipe, cette réunion peut prendre jusqu’à une journée entière.
La revue de sprint et la planification de sprint s’adressent à vous, les clients, et sont votre opportunité d’intervenir dans le processus de développement. L’équipe de développement y sollicite votre opinion sur les résultats du dernier sprint (incrément de produit) et vous demande ce dont vous avez besoin ensuite.

La revue de sprint est la validation du travail accompli lors du dernier sprint. L’équipe vous présente ici les fonctionnalités mises en œuvre. Cela vous donne l’opportunité d’évaluer la fonctionnalité et la qualité. Les éventuels problèmes sont notés et peuvent être résolus lors du prochain sprint ou reportés. Afin de contrecarrer la surestimation de soi mentionnée précédemment, je vous conseille d’impliquer les personnes de votre entreprise qui travailleront le plus avec les fonctionnalités présentées par la suite. Cela en vaudra certainement la peine, car les connaissances de la personne confrontée quotidiennement au problème peuvent transformer un bon produit final en un excellent produit.

La planification de sprint sert à planifier le prochain sprint. Un bon propriétaire de produit aura déjà trié les récits utilisateurs par ordre de priorité avec vous. L’équipe de développement a préalablement estimé les efforts individuels avec le propriétaire de produit lors d’une réunion de grooming ou de raffinement. Il est important de savoir qui détermine la quantité de travail à accomplir lors du prochain sprint : l’équipe. Après tout, c’est l’équipe qui devra gérer la charge de travail à la fin. Grâce à une préparation appropriée, la planification de sprint dure généralement beaucoup moins longtemps que la revue de sprint.

La revue de sprint et la planification de sprint peuvent donc être considérées comme de petits contrats d’entreprise conclus chaque sprint entre l’équipe de développement et le client. Elles garantissent que les développeurs ne travaillent pas sans plan, mais suivent un plan extrêmement précis. Par conséquent, une participation active est importante. Un bon maître SCRUM vous le rappellera certainement.

La communication comme facteur important dans le processus de développement

Outre la revue de sprint et la planification de sprint, une communication continue d’égal à égal est essentielle. Cela signifie : réservez du temps pendant lequel vous êtes disponible pour l’équipe de développement. Si un propriétaire de produit doit attendre une semaine pour obtenir des réponses, il n’aura plus suffisamment de temps à la fin pour préparer le prochain sprint.
Surtout au début, vous serez probablement assaillis de questions. Il est donc d’autant plus important de constituer un cercle de personnes capables de répondre sans trop réfléchir. Ici aussi, le thème de la surestimation de soi entre en jeu. Les questions sont répondues par les personnes qui devront vivre avec la réponse par la suite. La plupart du temps, ce sont les personnes qui peuvent répondre le plus rapidement à la question.
Une communication fréquente est bonne, une communication d’égal à égal est meilleure. Vous n’irez pas loin avec un comportement dominant. Vous avez besoin des développeurs pour mettre en œuvre vos idées. Les développeurs ont besoin de vous pour élaborer les exigences. Il n’y a pas de place pour la hiérarchie ici. Vous ne dites pas aux développeurs ce qu’ils doivent faire, ils vous communiquent ce dont ils ont besoin. Néanmoins, le principe « le client est roi » reste valable. Les développeurs ne vont donc pas soudainement élaborer leur propre plan.

Pourquoi une mise en production précoce du logiciel est avantageuse

Supposons : le contrat de service est signé, vous participez à la revue de sprint et à la planification de sprint, et il y a une communication active. Ainsi, vous avez pris toutes les mesures qui aident l’équipe à prendre de l’élan. Il arrivera certainement qu’on vous demande l’un ou l’autre extra. Je classerai cela élégamment dans le point communication. Cependant, il y a encore une dernière chose sur laquelle je voudrais attirer votre attention. Mettez votre logiciel en production le plus tôt possible. Cela vous permet de vérifier deux choses.

L’équipe implémente d’abord les fonctionnalités les plus importantes.

L’objectif est de mettre en œuvre rapidement les cas d’utilisation centraux, sans se perdre dans les détails. Si, après des mois de développement, votre logiciel ne peut toujours pas représenter le cas d’utilisation le plus simple, alors quelque chose ne va pas.

Les fonctionnalités implémentées sont pratiques.

La revue de sprint et les tests contribuent déjà considérablement à l’amélioration de la qualité. Cependant, ce sont les fonctionnalités et non les scénarios qui sont testés. On ne vérifie pas la praticabilité dans des scénarios simulés, mais en direct. La recherche, performante sur peu de données, est beaucoup trop lente avec des données réelles. Cette animation, si agréable à regarder lors du test, agace et prend du temps. Tous ces points ne sont malheureusement pas aussi visibles dans un test simulé que dans l’utilisation quotidienne.

Nous ne construisons pas ici un nouveau robot martien, pour lequel un véritable test pratique serait effectivement assez difficile. Nous avons simplement souvent peur de présenter un logiciel inachevé. Les collègues sont certainement d’abord irrités de se voir présenter quelque chose d’incomplet. Et une fois de plus, la communication est la clé : « Nous sommes en train de faire développer un logiciel pour X, Y, Z et nous souhaitons que ce logiciel vous assiste de manière optimale à la fin. X fonctionne déjà, Y et Z pas encore. Comme vous êtes très compétent dans ce domaine, je vous prie d’accomplir le scénario X avec ce nouveau logiciel et de me donner un retour sur ce qui fonctionne bien et ce qui ne fonctionne pas ». Le collègue se sent impliqué dans le processus, valorisé en tant que fournisseur de feedback et a l’assurance que le logiciel est destiné à l’assister, non à le remplacer. Il est désormais largement responsable du succès du projet. Il n’y aura pas de « Mais cela ne fonctionne pas du tout » a posteriori.

Conclusion

Effectivement, vous, en tant que clients, avez déjà beaucoup à faire. Mais c’est précisément la différence avec les approches classiques. Au lieu de nous débattre avec des exigences abstraites et des contrats complexes, nous préférons utiliser votre temps pour créer une véritable valeur ajoutée.