Documenter la RS&DE dans un monde agile

Le programme de crédit d'impôt pour la recherche scientifique et le développement expérimental (RS&DE) est l'un des plus généreux au monde et de nombreuses entreprises de logiciels profitent de ce programme pour aider à financer leurs initiatives de recherche et développement.

Le programme RS&DE (prononcé shred) a été créé il y a plus de 25 ans lorsque le développement de logiciels était principalement effectué par de grandes entreprises et des intégrateurs de systèmes, la méthodologie de développement étant un processus en cascade hautement structuré avec un fort accent sur la documentation.

Aujourd'hui, de nombreux développeurs de logiciels adoptent des méthodologies de développement agiles, allégées ou itératives et maintiennent la documentation des processus axée sur les exigences minimales. Cependant, l'accent mis par le programme de RS&DE sur la documentation contemporaine a créé un conflit pour une entreprise qui tente d'optimiser sa demande de RS&DE, tout en développant un logiciel à l'aide d'une méthodologie Agile.

L'une des questions que l'on me pose fréquemment est de savoir comment les entreprises peuvent appliquer les exigences rigoureuses en matière de documentation RS&DE avec la rapidité et l'agilité requises par leur processus de développement hautement itératif. Comment les deux concepts peuvent-ils coexister avec succès et efficacité ?

Pour répondre à cette question, commençons par les exigences de la politique sur la documentation de la RS&DE de l'Agence du revenu du Canada (ARC). La politique stipule qu'il est nécessaire d'avoir une documentation contemporaine des activités de RS&DE comme preuve de travail qualifié. Contemporain fait référence à la documentation qui est créée au moment où l'activité de RS&DE est exécutée, identifie qui a fait le travail et ce qui a été fait. Idéalement, la documentation devrait illustrer les incertitudes technologiques et l'enquête systématique qui a été effectuée.

Essentiellement, le comment et le pourquoi du processus de développement sont bien plus importants à prendre en compte que le quoi. Malgré la possibilité de montrer les résultats finaux de la RS&DE, le non-respect des exigences en matière de documentation de la RS&DE entraînera généralement le refus d'une demande, si elle est examinée.

Au lieu de créer un processus de RS&DE supplémentaire et onéreux, je suggère d'ajouter ou de modifier vos processus de développement actuels pour tenir compte de la RS&DE. À cette fin, j'ai identifié des domaines faciles à mettre en œuvre et souvent négligés où vous pouvez documenter la RS&DE dans votre environnement agile existant.

1. Créez un champion de la RS&DE au sein de votre entreprise. Cette personne doit être quelqu'un qui gère des projets et connaît les normes et les processus de développement de logiciels dans votre entreprise.

Idéalement, il s'agit d'un chef de projet qui produit déjà des artefacts tels que des résumés de sprint. En tant que champion de la RS&DE, ils sont la principale ressource pour toutes les questions liées à la RS&DE et peuvent appliquer la mise en œuvre de ces idées par le biais d'artefacts de gestion de projet existants et nouveaux.

2. Ajoutez des commentaires sur la RS&DE lors de l'enregistrement du code source. Un exemple de la façon dont un processus de développement existant peut être modifié pour répondre aux besoins de la RS&DE est d'utiliser les enregistrements du référentiel de code source pour documenter la RS&DE. Vos développeurs peuvent déjà ajouter leurs notes d'enregistrement.

En rendant obligatoire l'utilisation d'étiquettes RS&DE avec des notes supplémentaires sur l'expérimentation effectuée menant à la sortie du code, vous avez maintenant un journal de tous vos résultats RS&DE. Ce référentiel peut ensuite être consulté lorsque vous avez besoin de documenter et de compiler votre réclamation.

3. Utilisation des rapports de sprint/scrum et des notes wiki : Ajout de trois champs pertinents pour la RS&DE dans vos résumés de sprint ou vos rapports Scrum – RS&DE : Oui/Non ; Obstacles technologiques ; Expérimentation effectuée - vous assurera de saisir les travaux de RS&DE effectués dans le contexte de vos rapports de RS&DE existants.

Vous pouvez également ajouter la balise RS&DE aux entrées du wiki qui peuvent être liées à des travaux de RS&DE. Cette étiquette peut être facilement recherchée lorsque vous devez développer votre demande de RS&DE pour des sprints ou des tâches connexes.

4. Commentaire du code source : Bien que le code source soit une forme acceptée de documentation de RS&DE, il ne montre que les résultats de la RS&DE, plutôt que le processus de RS&DE. Identifier les algorithmes spécifiques essayés et l'expérimentation entreprise sous forme de commentaires dans le code est un bon moyen de documenter le processus de RS&DE.

Le cas échéant, commenter le code qui a échoué ou les itérations d'algorithmes est un bon moyen d'étiqueter les travaux de RS&DE. L'ajout de raccourcis aux commentaires, tels que les initiales du programmeur et les dates, peut renforcer la fiabilité de ce type de documentation.

5. Le courrier électronique est un domaine souvent négligé de la documentation de la RS&DE. Vous pouvez créer un compte spécifique à la RS&DE tel que sred@monentreprise.com et mettre en copie le courriel lorsque des courriels spécifiques à la RS&DE sont envoyés. Les e-mails qui traitent des obstacles technologiques, des incertitudes et des expérimentations méritent d'être documentés.

Cette méthode est un bon moyen d'améliorer votre documentation de RS&DE avec un minimum de frais généraux. Ce compte de courriel peut maintenant être récupéré régulièrement ou à la fin de l'exercice financier lorsque vous devez compiler votre demande de RS&DE.

L'ARC s'attend également à ce que les environnements de développement de logiciels plus vastes et plus complexes disposent d'une documentation plus mature et officielle; vous devez vous attendre à ce que si vos réclamations sont importantes, votre niveau de documentation corresponde en conséquence. Les réclamations plus importantes devraient, en théorie, avoir une documentation plus complète. En mettant en œuvre ces étapes simples en conjonction avec leur processus existant, les entreprises de logiciels de toutes tailles peuvent adapter leur développement agile pour améliorer la documentation de RS&DE, ce qui se traduit par des demandes de RS&DE plus efficaces et plus opportunes.