March 2011 - Messages

Minimum Viable Product
28 March 11 09:16 AM | Nico | avec no comments

En développement logiciel, le Minimum Viable Product (MVP) est la stratégie qui consiste à construire un produit qui a le minimum de fonctionnalités pour être déployé et exploité par les utilisateurs cibles.

Cette démarche, initiée par les gourous du Lean Startup, est généralement conseillée et appliquée à des startups qui ont vocation à développer des produits innovants. L’idée est simple:

  • Aller vite dans la mise en oeuvre pour avoir un produit opérationnel rapidement, avant de ne plus avoir de ressources.
  • Aller à l’essentiel, en privilégiant d’abord les fonctionnalités qui ont le plus de valeur, et ne pas se disperser dans des fonctionnalités inutiles.
  • Recueillir un feedback de la part des premiers utilisateurs pour savoir si on est sur la bonne voie et compléter ensuite le produit de façon incrémentale.
  • Converger vers le produit qui recueillera les feedbacks positifs, vers le produit pour lesquels un utilisateur est prêt à payer.

Dans les projets, on avait l’habitude de faire une maquette ou un prototype pour valider ce à quoi devait ressembler une application; mais on jetait systématiquement la maquette à la poubelle, parce qu’elle n’était souvent pas faite dans les règles de l’art.

Avec le MVP, on est bien dans une considération de produit testable, mais pas jetable. Le premier jet est un produit qui rend une partie du service. Le feedback de l’utilisateur potentiel a beaucoup de valeur à ce stade, car il valide ou non l’idée du produit.

Cette démarche est bien adaptée à une logique de Startup, qui a besoin d’aller vite, avant de plus avoir de ressources, et de ne pas faire de dépenses inutiles. Comme souvent les Startup visent les early adopter, qui sont, en règle général, plus indulgent sur la complétude des produits, ce n’est pas grave de proposer un produit incomplet. Ce qui est important, c’est de montrer les fonctionnalités de base, et d’avoir un retour avant d’aller plus loin. Notre imagination nous pousse souvent à penser à beaucoup de fonctionnalités, alors que la mise en oeuvre révèle que cette imagination ne correspond pas toujours à quelque chose de valable. Le feedback utilisateur est là pour guider l’évolution du produit, pas à pas, vers quelque chose qui a une vraie valeur pour l’utilisateur.

Ce n’est pas tout à fait la même chose qu’une Beta, et ce sera souvent bien plus minimal que ce que vous pouvez imaginer pour votre produit. La version Beta est déjà le résultat d’un processus abouti, qui est en phase de consolidation. Le MVP se construit au fur et à mesure, avec les early adopters; on va d’abord rechercher l’expérience utilisateur pour construire le produit.

Cette idée peut aussi s’appliquer dans le contexte d’un projet d’entreprise plus mature. Après tout, certaines sociétés ont la volonté de continuer à fonctionner avec un esprit de Startup, et l’idée de faire converger un produit au fur et à mesure des besoins, est aussi au coeur de l’agilité. Un product owner doit penser à un MVP dans son cycle de développement. Ne pas gaspiller des ressources pour développer des fonctionnalités inutiles  - le fameux YAGNI - est au coeur du Lean et une préoccupation des agilistes.

Cette démarche nécessite de pouvoir mettre en oeuvre rapidement une idée, d’avoir un résultat visible tout de suite, pour construire petit à petit à partir du résultat. Elle est possible si vous pouvez mettre en production tôt, et si vous savez travailler en cycles courts pour mettre en production souvent.

Et c’est exactement comme cela que nous travaillons, et que nous pratiquons l’agilité; on fait pousser les applications par l’usage. Et c’est possible, parce que l’on écrit très peu de code; tout simplement parce plus vous êtes léger, plus vous êtes facile à bouger.

KB Crawl et Aspectize: histoire d’un projet agile
18 March 11 03:50 AM | Nico | avec no comments
KBCrawlSAS

Il y a quelques mois, nous avons rencontré la société KBCrawl, éditeur d’une solution de veille.

Pour ceux qui ne savent pas ce qu’est un projet de veille, cela consiste à collecter des informations jugées stratégiques par l’entreprise sur les différents canaux d’informations Internet (blogs, réseaux sociaux, sites, flux de news, …). Le process de veille se déroule traditionnellement en 2 étapes: la collecte d’informations, et l’exploitation. Pour la collecte, on utilise un moteur, qui va surveiller les différentes sources d’informations choisies par les veilleurs de l’entreprise, et remonter les informations pertinentes. C’est là tout le savoir-faire de KBCrawl, éditeur spécialisé sur ce métier. L’exploitation, cela consiste à mettre à disposition cette information aux différents utilisateurs; toute l’information n’a pas la même valeur pour tout le monde. Il faut donc qualifier, classer, répertorier, indexer, organiser, modifier cette information, pour que chacun, en fonction de son profil, sa fonction, ses centres d’intérêt, trouve l’information pertinente. Pour cela, un portail Intranet, de type CMS, convient bien à ce genre d’usage. C’est ce que propose également KBCrawl dans son offre avec un portail basé sur une solution open source.

Sauf que, un des clients de KBCrawl, ne veut pas de la solution open source, et souhaite une solution sur-mesure. Que faire, quand les délais sont serrés, et qu’il y a un vrai projet de développement à réaliser ? C’est là où la complémentarité avec Aspectize s’est parfaitement trouvé. N’ayant pas le temps de former l’équipe de KBCrawl, nous décidons conjointement de réaliser le projet nous-mêmes.

L’expression de besoin est très sommaire, exprimée par 15 slides, tout ce qu’on adore. A partir de là, nous allons construire au fil de l’eau la solution, avec des cycles extrêmement courts, un feedback permanent du client, qui a parfaitement jouer le jeu, et une réactivité très forte de notre part. Et tout cela est possible, parce que nous écrivons très peu de code.

  • Ecrire peu de code permet d’être réactif.
  • Etre réactif permet de livrer en continu.
  • Livrer en continu permet d’avoir du feedback.
  • Avoir du feedback permet de mieux cibler les besoins des utilisateurs.

Au total, on a réalisé une application spécifique en un temps record, et surtout avec un minimum de code, et c’est vraiment cela qui permet d’être agile. Et au passage, on s’est intégré au moteur Exalead, le moteur d’indexation choisi pour la solution, ainsi qu’au système d’authentification du client.

En général, lorsque l’on montre l’application, et que l’on explique ce qu’on a fait, nos interlocuteurs sont assez impressionnés.

Alors, si vous aussi vous souhaitez en savoir plus, venez assister à la conférence que nous co-animons avec KBCrawl le Mardi 5 Avril à 9h30, au CNIT de La Defense.

C’est gratuit, vous pouvez vous inscrire ici.

De l’importance du langage en informatique
09 March 11 07:35 PM | Fredy | avec no comments

 

Une petite discussion à la soirée bière – très sympathique – d’Alt.net de mardi, nous a menés des propriétés automatiques du C# 3.0 à qu’est-ce que la science puis à l’analyse non standard… mais je m’égare.

Revenons au C# et à l’objet de la discussion : y a-t-il une caractéristique d’un langage qui a de l’importance ? C.-à-d. une caractéristique qui permettrait d’être meilleur informaticien, d’écrire un meilleur code, un code qui dénoue le problème métier plus efficacement, avec moins de bugs et plus de souplesse ?

Personnellement je pense que non ! Et, dans la limite des langages que j’ai pratiqués, mon argument est le suivant : de l’assembleur au JavaScript en passant par le Fortran et le C, sans oublier le C++, le C# ainsi que VB6, VB.net et VBS, bien que je trouve que l’un se démarque, et c’est le JavaScript, ils se ressemblent tous : des « si », des « tant que », des variables et des valeurs, des points virgules et des accolades, du « case sensitif » ou pas… bref ils se différencient sur des détails alors que le problème est ailleurs. Qu’en pensez-vous ?

Classé sous :