Gestion des sorties de produits : le retour d’expérience de SoftFluent – 4/12

Conception Produit

Au sein d’un module spécifique, la conception produit est le processus qui détaille les fonctionnalités et le comportement que le produit devra avoir pour les différents.

Nous suivons une approche très simple. Nous écrivons des spécifications courtes qui décrivent les scénarios clients que nous voulons supporter. Nous n’allons pas loin dans les détails de l’interface utilisateur dans la mesure où nous avons un produit orienté développeur, mais nous le faisons lorque cela s’avère pertinent pour aligner toute l’équipe sur les décisions clé. Nous l’avons fait pour notre assistant de démarrage par exemple.

En fait, au sujet des spécifications, nous sommes de fervents croyants dans le fait que presque tout le monde devrait être en capable de les lire sans utilisation d’un formalisme crypté ni de diplôme en modélisation UML. Notre philosophie sur ce sujet est d’ailleurs résumée dans un article précédemment publié sur notre blog en anglais : Formalizing specifications.

Nous créons des scénarios de test et, en raison de notre offre, cela signifie souvent de mini-applications utilisées comme échantillons pour illustrer la fonctionnalité. A certains stades, nous avons l’habitude de discuter les scénarios dans la mesure où nous avons 1.000 idées différentes de fonctionnalités possibles que, malheureusement, nous ne pouvons pas toutes mettre en œuvre.

Pour les bogues qui sont détectées par l’équipe du support (ou par des clients qui contactent le support) ils sont reproduits dans un 1^er temps, pour être complètement qualifies et envoyés à la R&D avec les conditions exactes pour reproduire la bogue. Nous planifions ensuite la correction et intégrons ce cas dans nos scénarios de test.

En fin de compte, l’implémentation de fonctionnalités et les demandes de correction finissent comme "élément de travail" dans l’outil Team Foundation Server de Microsoft et sont distribués au sein de l’équipe de R&D.