Extreme Startup @ Agile Nantes

Grâce � � j'ai eu l'opp ortunité avec Cédric Pineau d'animer un atelier Extreme Startup à de Nantes. Voici quelque snotes sur cette session, sans bien entendu rien dévoiler du contenu de l'extreme startup ! Nous étions une petite dizaine audépart avec des bases de code très diversifiées : 2 équipes en Java, une équipe en PHP, une équipe en node.js.

Ressenti des équipes

La plupart des participants n'ont pas ressenti vraiment le besoin de refactorer le code. Quand on a la tête dans le guidon, lecopier-coller fonctionne très bien ! En plus, il permet d'être sûr que l'on n'a pas cassé de fonctionnalité quand on rajoute ducode et en redéploie. Seule une équipe a réellement écrit des tests unitaires, aucune n'écrivant de tests fonctionnels.

Ceux qui n'étaient pas programmeurs ont eu du mal à savoir sur quoi agir. Certains se sont organisés pour faire de la veille ensuivant l'évolution de leur score et de leur projet sur un écran à part, ce qui permet aussi de se partager le travail. Analyserce qui arrive en temps réel demande du temps cependant, et permet aussi aux non-développeurs de vraiment se sentir utile. Uneéquipe a fait de la R&D en partageant le travail entre 2 développeurs : un qui produit du code opérationnel, un autre quidéveloppe des fonctionnalités futures.

La question de l'exploitation des logs a été levée, certains demandant à ce que la simulation propose plus de métriques et demoyens de savoir ce qui se passe. Mais on peut se demander si ce n'est pas aux développeurs d'être capable de fournir cesinformations, ce qui pose la question intéressante de l'opérabilité des solutions : dans quelle mesure le produit est capable defournir des données au-delà de la fonctionnalité qu'il remplit ?

L'environnem ent de dé veloppement a posé problème à une équipe développant en PHP: le mode serveur REST n'est pas habituel danscet environnement et de ce fait, l'équipe a eu du mal a avoir un serveur basique fonctionnel. D'autant plus que le serveur de baseproposé sur est basé sur une utilisation en ligne de commande et l'ouverture de sockets, chose qui n'est pas du toutusuelle dans l'univers PHP.

La simulation montre bien l'important de maîtriser son environnement et les fondamentaux de sa plate-forme.

Comprendre le score

Quelle est la signification du score de chaqué équipe ? S'agit-il d'un revenu généré, du cash disponible, de parts de marché? Ou bien encore d'une mesure abstraite de confiance ou d'image du groupe concerné sur un certain marché ? Cette question durapport au score se pose lorsque de nouveaux entrants pénètrent le marché : leur score est de 0 ce qui du coup peut lesavantager par rapport aux scores d'autres participants ayant déjà un historique négatif à rattraper. Cela fait partie de lasimulation car la capacité d'une startup à pivoter (ou persévérer) est un élément important d'une stratégie produit.

Toujours du point de vue de la simulation, la situation est potentiellement différente selon qu'une startup fonctionne sur desfonds propres ou des fonds externes. Dans le premier cas il sera difficile de remettre les compteurs à 0 : une fois que l'on aconsommé l'ensemble de son patrimoine, il n'est plus possible de réinvestir ! Inversement dans le second cas, un échec peutconduire à l'assèchement des financements, le ou les porteurs de projets devenant persona non grata auprès de financeurspotentiels.

Améliorations possibles

Une composante importante de la tactique dans le développement d'un produit web est absente de la simulation : le test A/B. Lesseules mesures dont disposent les équipes sont les points marqués ou perdus, le cumul des points et la position relative parrapport aux autres équipes. S'il apparaît possible d'anticiper sur les évolutions futures du marché avec un minimumd'observation, il ne semble pas possible de réllement tester la réaction du marché par rapport à telle ou telle solution.