Important: The GCConnex decommission will not affect GCCollab or GCWiki. Thank you and happy collaborating!

CSPS Digital Academy Innovation Services - Services d'innovation de l'Académie du numérique de L'ÉFPC/Cycle de développement des produits

From wiki
Jump to navigation Jump to search
Acceuil Notre équipe Notre cycle de
développement des produits 		Comment nous travaillons Contactez-nous



L’équipe des Services d’innovation (SI) de l'Académie du numérique de l’École de la fonction publique du Canada (EFPC) travaille constamment sur de nouveaux produits afin d’appuyer le mandat de l’EFPC, de l’Académie du numérique (AN) et du gouvernement du Canada (GC). L’équipe des SI s’occupe du développement de nouvelles applications, c’est-à-dire qu’elle développe, teste et publie continuellement des améliorations et des corrections de bogue tout le long du cycle de développement d’une version. Le développement, les tests et le lancement d’une nouvelle application Web comportent quatre étapes : Validation de principe, Alpha, Bêta et lancement officiel.

Pendant l’étape de la validation de principe, l’équipe des SI tente de démontrer la faisabilité d’un concept ou d’un produit pour confirmer qu’il peut être utilisé. L’équipe teste un logiciel ouvert pour s’assurer qu’il répond aux exigences initiales ou un produit minimal viable (PMV) récemment développé. Si le concept ou le produit franchit l’étape de la validation de principe, il passe ensuite à l’étape Alpha au cours de laquelle la majeure partie du travail de développement et de conception du nouveau produit est effectuée. Une fois que les premières fonctionnalités essentielles sont développées et testées à l’étape Alpha, le nouvel outil passe à l’étape Bêta. Au cours de cette étape, l’application est terminée à au moins 90 % et on la met à la disposition des utilisateurs en tant que produit minimal commercialisable (PMC). Au cours de cette même étape, on apporte les dernières corrections de bogue et améliorations requises avant de lancer officiellement l’application.


Produit minimal viable (PMV) et produit minimal commercialisable (PMC)

Qu’est-ce qu’un produit minimal viable?

Dans le développement de produits agile, le produit minimal viable (PMV) est la version embryonnaire d’un nouveau produit qui comprend un minimum de fonctionnalités (habituellement 1 ou 2). Il permet à une équipe d’obtenir sans trop d’efforts une première rétroaction d’un petit groupe d’utilisateurs.

Puisque le but premier du PMV est de faciliter l’apprentissage validé, il peut prendre la forme de prototypes papier ou à cliquer qui génèrent des données qualitatives (plutôt que des données quantitatives), dans la mesure où il permet de tester l’idée et d’acquérir les connaissances pertinentes.

Qu’est-ce qu’un produit minimal commercialisable?

Le produit minimal commercialisable (PMC) est la version d’un produit dotée d’un petit ensemble de fonctionnalités qui répond aux besoins des utilisateurs initiaux (innovateurs et adopteurs précoces). Cette version peut être mise sur le marché.

Le but premier du PMC est de réduire le délai de lancement puisqu’il peut être lancé plus rapidement qu’un produit équipé de plusieurs fonctionnalités. Le PMC permet de se concentrer sur l’essentiel, sans se soucier de toutes les fonctionnalités inutiles.

En résumé : Le PMV vous permet de tester vos idées. Le PMC vous permet de lancer votre produit plus rapidement.

Validation de principe

La validation de principe est une façon pour l’équipe des SI de démontrer la faisabilité d’un concept ou d’un produit pour confirmer qu’il peut être utilisé. Une validation de principe est facultative et habituellement courte. L’équipe teste un logiciel ouvert existant pour s’assurer qu’il répond aux exigences initiales ou un produit minimal viable (PMV) récemment développé. Ce test doit être réalisé avant que l’équipe ne développe le produit plus en profondeur. Il s’agit d’une étape expérimentale à court terme qui permet de déterminer comment le service à grande échelle fonctionnera en pratique et de mieux explorer un ensemble de technologies ainsi que la manière dont elles pourraient fonctionner dans une culture d’entreprise bien précise.

Avant d’entreprendre une validation de principe, il faut établir la portée du projet, notamment les exigences de l’utilisateur, opérationnelles et techniques. Les exigences de l’utilisateur sont définies par la recherche, les tests et l’analyse de la base d’utilisateurs. À partir de la portée du projet, l’équipe des SI effectuera des recherches pour déterminer s’il existe une application ouverte qui satisfait à ces exigences. Dans la négative, l’équipe développera un produit minimal viable (PMV). Le PMV ne comprendra pas toutes les fonctionnalités prévues pour l’application, mais seulement le minimum des fonctionnalités requises pour obtenir une première rétroaction des utilisateurs. Si la validation de principe est concluante, on développera d’autres fonctionnalités et améliorations qui rehausseront la valeur de l’outil.

Validation de principe ouverte signifie que le produit ou l’application est accessible et peut être testé par n’importe quel utilisateur. Validation de principe fermée signifie que le produit ou l’application est seulement accessible à un petit groupe d’utilisateurs ou à l’équipe qui développe l’outil. L’équipe des SI utilise l’une ou l’autre de ces méthodes d’essai, selon ce qui convient le mieux au produit en cours de développement. Il est préférable, dans la mesure du possible, de procéder à une validation de principe ouverte, car elle inclut l’utilisateur dès les premières étapes du développement et permet une rétroaction des utilisateurs plus approfondie.

Si on considère que le PMV ou l’application ouverte mis à l’essai est concluant, l’application passera à la prochaine étape du développement. Si on considère qu’il est inapproprié (p. ex. qu’il ne répond pas aux exigences de l’utilisateur et opérationnelles), l’équipe des SI déterminera si elle doit changer d’orientation, abandonner ou trouver une nouvelle solution.

Le produit suivant est en phase the validation de principe ouverte :

  • Evalhalla

Alpha

Une fois qu’un produit (logiciel ouvert existant ou nouveau PMV) franchit l’étape de la validation de principe, l’application sera soumise au développement et aux tests de l’étape Alpha. Au cours de cette étape, les fonctionnalités et la conception de l’application sont développées en fonction de la rétroaction formulée par les utilisateurs lors des tests initiaux.

Si elle utilise une application ouverte, l’équipe des SI supprimera des fonctionnalités et en développera de nouvelles afin de répondre aux besoins des utilisateurs. Elle s’assurera également d’harmoniser l’aspect et la convivialité de l’interface utilisateur avec l’EFPC et l’AN. Le but premier est de rendre l’application stable, accessible et utilisable pour la base d’utilisateurs.

Les tests Alpha sont réalisés par des utilisateurs préalablement sélectionnés pour tester la convivialité et l’expérience client de l’outil en cours de développement et pour diagnostiquer les bogues majeurs venant compromettre la fonctionnalité de l’outil.[1] Lors de ces tests, l’équipe des SI se penche également sur l’accessibilité.

À l’étape Alpha, l’outil est fonctionnel, mais il ne comprend pas nécessairement toutes les améliorations qui seront incluses dans le produit minimal commercialisable (PMC) et lors du lancement officiel. L’étape Alpha prend fin lorsque la conception et toutes les fonctionnalités requises sont développées et testées, et que l’outil est prêt à être mis à la disposition de la base d’utilisateurs en tant que PMC, pendant l’étape Bêta, en vue de réaliser d’autres tests et d’obtenir une nouvelle rétroaction.[2]

Bêta

Au terme des tests réalisés à l’étape Alpha, l’application passe à l’étape Bêta du développement et des tests. Au cours de cette étape, l’application est terminée à au moins 90 % et on la met à la disposition des utilisateurs en tant que produit minimal commercialisable (PMC). Pendant les tests Bêta, les utilisateurs sont invités à fournir une rétroaction sur la conception, la fonctionnalité et la convivialité de l’outil. Les tests Bêta sont aussi réalisés pour diagnostiquer et corriger les bogues mineurs ainsi que les bogues qui auraient pu échapper aux tests Alpha.[3] L’équipe des SI se sert de tests Bêta ouverts pour mettre ses outils à l’essai. Cela signifie qu’un outil peut être utilisé et testé par chaque utilisateur qui souhaite participer aux tests dans un environnement réel.

Le développement Bêta fait appel à la rétroaction fournie par les utilisateurs réels en vue d’améliorer ou de modifier la conception de l’interface utilisateur pour lui permettre de lancer une application accessible et utilisable, tout en offrant la meilleure expérience client possible. Il peut exister plusieurs versions de l’application lancée à l’étape Bêta.[4]

Le produit suivant est en phase de développement bêta :

Lancement officiel

Lorsque la conception et toutes les fonctionnalités requises sont développées et implantées dans le cadre de la nouvelle application, celle-ci est prête à être officiellement lancée. Comme l’équipe des SI travaille dans un environnement agile, le lancement officiel ne marque pas la fin du développement de l’application. L,équipe effectue régulièrement des recherches auprès des utilisateurs pour déterminer la nécessité d’améliorations et comment on peut améliorer la convivialité de l’outil. Après le lancement officiel, l’équipe des SI continue de corriger les bogues, de développer et de lancer de nouvelles fonctionnalités et d’apporter des améliorations sur une base continue, et ce, pendant toute la durée de vie de l’application.

Références

  1. ↑ “What Is Alpha Testing? An Early Alarm for Defects.” Software Testing Help, 7 June 2018, www.softwaretestinghelp.com/alpha-testing/.
  2. ↑ Christensson, Per. "Alpha Software Definition." TechTerms. Sharpened Productions, 05 April 2013. <https://techterms.com/definition/alpha_software>.
  3. ↑ “What Is Beta Testing? A Complete Guide.” Software Testing Help, 7 June 2018, www.softwaretestinghelp.com/beta-testing/.
  4. ↑ “Beta Software.” Beta Software Definition, 5 Apr. 2013, techterms.com/definition/beta_software.
Retrieved from "https://wiki.gccollab.ca/index.php?title=CSPS_Digital_Academy_Innovation_Services_-_Services_d%27innovation_de_l%27Académie_du_numérique_de_L%27ÉFPC/Cycle_de_développement_des_produits&oldid=32228"