Préparez votre environnement de travail

Réfléchissez aux techno que vous allez utiliser (surtout si vous êtes porteur de projet). Installez/configurez tout le nécessaire pour ne pas avoir à le faire pendant le weekend.

Faites un tour de table pour connaitre le niveau et les compétences de chacun

Dès le vendredi soir, il est important de bien connaître les compétences de chacun pour faire de bons choix techno et dispatcher au mieux les tâches. Effectivement, cela serait une erreur, par exemple, de sauver les données sur du MongoDB alors que personne ne l’a déjà utilisé et qu’une bonne vieille base Postgres ou MySQL aurait très bien fait l’affaire.

Travaillez de manière agile

Dès le début, dessinez sur un paperboard un tableau à 4 colonnes (backlog, todo, current, done). Dès que quelqu’un a une idée, il écrit son idée sur un post-it (en la décomposant si elle est trop complexe ou trop floue) et le colle dans le backlog. A chaque fois que vous faites un point (toutes les 3-4 heures), choisissez les idées les plus prioritaires (en fonction de leur complexité et de leur valeur business) et mettez dans la colonne todo. Ensuite, dès qu’un développeur commence une tâche, il la déplace dans current. Enfin, vous l’aurez compris, lorsque la tâche est terminée, le post-it va dans done.

48h, c’est très court, prenez bien soin de toujours travailler sur les tâches les plus prioritaires. Veillez également à toujours avoir peu de tâches en cours en même temps.

Pensez toujours à féliciter quelqu’un qui termine une tâche, qui a une bonne idée… C’est principalement ce qui va permettre de maintenir la motivation durant le weekend !

Déployez régulièrement

Afin de ne pas être pris au dépourvu 5 min avant la fin, je vous conseille de déployer régulièrement l’application (toutes les 3-4h). Cela permet aux non-dev de tester l’appli, de remonter des bug, de nouvelles fonctionnalités…

Keep focus on dev

Essayez au maximum de vous concentrer sur le développement. Ne vous occupez pas à faire le design si vous n’avez pas de designer, achetez un design sur ThemeForest, cela fera très bien l’affaire. Ne vous occupez pas de l’admin sys si ce n’est pas nécessaire, déployez votre application en utilisant du PaaS. N’ayez également pas peur de créer de la dette techno (par exemple, en omettant de faire des tests si cela est pertinent), vous pourrez corriger le code la semaine suivante.

Il y a un service pour tout

N’hésitez pas à dépenser quelques euros dans un service qui peut vous faire gagner un temps précieux. Voici quelques services à connaître :

• Hoptoad : collecte les erreurs qui surviennent sur votre application (Rails, iOS, PHP, Java, .net…) et les agrège pour faciliter la consultation
• Pusher : Push temps réel sur une application web grâce à des WebSockets
• Redis To Go : hébergement Redis
• Sendgrid : envoi d’email
• Websolr : recherche full-text reposant sur Solr

Restez efficace et en forme

• Faites des pauses régulièrement
• N’hésitez pas à faire une sieste si la fatigue vous gagne
• Mettez en place du pair-programming au moins pour les tâches complexes

Si vous êtes un développeur Rails

Utilisez RailsWizard

RailsWizard permet de générer le code d’une application Rails avec certaines gems indispensables. Vous pouvez choisir les gems que vous voulez intégrer en fonction de vos habitudes et de vos besoins. Cela vous fera gagner quelques minutes.

Versionnez le code avec Git

C’est devenu un standard pour beaucoup de dev en Rails. Git est également indispensable si vous souhaitez déployer sur des services comme Heroku.

Déployez sur Heroku (si possible)

Heroku vous permet de vous décharger complètement de la partie administration système. Vous faites un push sur le Git de votre projet Heroku, et hop, l’application se déploie. Cerise sur le gâteau, la version de base est gratuite ;)

Vu que Heroku fourni un repository Git pour le déploiement, vous n’aurez même pas besoin de vous créer un git sur Github ou autre pour travailler en équipe. Travaillez par exemple dans une branche dev et pushez sur la branche master à chaque fois que vous voulez déployer.

Si Heroku est trop restrictif pour vous, regardez du côté de solutions comme Engine Yard, Dotcloud…

Il y a une gem pour tout

Evitez à tout prix de réinventer la roue. Si vous développez quelques choses d’assez classique, ayez le réflexe de regarder sur Rubygems s’il n’existe pas une gem qui fait ça très bien. Il y a près de 22 000 gems disponibles vous devriez trouver ce qu’il vous faut assez souvent.

Les conseils des lecteurs

Eclatez-vous et faites-vous plaisir (Frédéric Dupérier)

Pensez « lean » (Yann Klis)

Ce n’est pas la peine de bosser 24h/24. Il vaut mieux prendre le temps de construire un bon plan que de se jeter à corps perdu dans des choses qui ne sont pas forcément utile. Pensez « lean » -> « Eliminate waste »

 

Si vous avez d’autres conseils, partagez-les en commentaire, je les ajouterai dans l’article

 

Le weekend dernier, j’ai participé à la troisième édition du Startup Weekend Paris. Le weekend a été très dense, de ce fait j’ai à vous rapporter à propos de l’événement, du projet, de l’équipe, des technologies et méthodes utilisées…

Démarrage du weekend

Le Startup Weekend a commencé vendredi soir par un apéro pour faire connaissance. Ensuite, Franck, un des organisateurs, nous a fait faire quelques exercices d’impro sur le sujet de la création de startups pour détendre l’atmosphère. Enfin, nous nous sommes tous rendu dans un grand amphi pour passer aux choses sérieuses (pitch et élection des projets).

Nous étions 116 personnes. 46 projets ont été présentés (liste complète). J’ai moi-même présenté un projet, le #26. L’idée que j’ai présentée est un outil permettant de faciliter au maximum la rédaction des tweets lorsqu’on publie de la veille, sans pour autant l’automatiser (comme le propose TwitterFeed par exemple). Cet outil offre également une analyse du ROI (Return On Influence). On pourrait donc avoir des réponses à des questions comme : Quel est le meilleur moment dans la journée/la semaine pour publier un tweet? Quels thèmes intéressent le plus mes followers? …

Mon projet a finalement été sélectionné. Deux autres projets se sont d’ailleurs ralliés au mien car nos sujets étaient proches. Les participants se sont répartis sur les différents projets, nous nous sommes retrouvé 11 pour « monter une startup » en un weekend! L’équipe était composée de 7 développeurs, 4 marketeux et 1 designer.

Le vendredi soir s’est terminé par un brainstorming et un peu d’organisation. Nous avons finalement décidé de nous consacrer uniquement à la partie stats.

Choix technologiques

Coté techno, Ruby on Rails a été choisi de manière quasi-unanime. Pourquoi ? Car il n’y avait que des développeurs Rails ! Ce n’est pas du tout représentatif du marché du développement web en France, par contre cela représente très bien le marché des startups en France et plus particulièrement sur Paris. La vague Ruby on Rails est bien là et ça fait plaisir !

Nous avons donc développé en Rails 3 et Ruby 1.8.

Voici la liste des principaux services/techno que nous avons utilisés durant le weekend :

Côté plugins Rails, nous avons utilisé :

• mongoid
• devise
• devise-twitter
• mini_fb
• hoptoad_notifier
• will_paginate
• web-app-theme
• haml
• bitly
• …

Avec du recul, je pense que nos choix ont été plutôt bons. Heroku nous a permis de déployer l’application très rapidement et de ne perdre aucun temps avec l’administration système. Grâce à MongoDB (et Mongoid) nous avons pu nous permettre quelques facilités comme stocker les tweets dans leur totalité sans déformer leur structure. J’ai cependant toujours un doute sur la facilité à faire évoluer la structure des documents mongoDB sur du long terme. Nous avons pu mettre en place l’authentification en quelques secondes grâce à Devise. L’authentification par Twitter fut plus complexe car le plugin, devise-twitter, n’est pas encore stable.

Organisation

Ce weekend m’a permis de constater que Scrum est fréquemment utilisé dans le monde startup, la plupart des membres de notre équipe connaissait déjà cette méthode agile de gestion de projet. Nous avons donc décidé de la mettre en oeuvre pour le weekend pour l’équipe de dev.

Nous avons adapté la méthode à notre cas. Nous avons fait des sprints de 6h. Nous avons également choisi de commencer le samedi matin avec un sprint pas encore défini afin de ne pas perdre de temps.

Malheureusement, comme le produit a été conçu et modifié par le marketing tout au long du weekend, il n’a pas été possible d’appliquer Scrum comme nous l’aurions souhaité. Nous avons donc supprimé la notion de sprint. Nous avons gardé le concept de user stories, des Post-It sur un tableau, la notion de ‘terminé’ (samedi matin, nous nous sommes entendus sur le fait que pour ce weekend, une tâche terminée serait une tâche qui aurait été testée par un développeur)…

Enfin, ce qui m’a le plus surpris côté organisation c’est le fait qu’il n’y a pas eu de leader durant ce weekend et que personne n’a cherché à l’être. L’équipe s’est auto-organisée. Toutes les décisions ont été prises par l’ensemble de l’équipe et cela a très bien fonctionné.

Je craignais une guerre du pouvoir, j’ai assisté à une alliance pour la réussite ! Bravo l’équipe !

Le résultat : Qualifeed

Le weekend est passé très vite. Nous avons peu dormi. Et ce fût rapidement l’heure de rendre la copie.

En un petit weekend, nous avons réalisé Qualifeed. Aujourd’hui Qualifeed permet déjà pas mal de choses :

• Affichage des tweets les plus influents
• Pour chaque tweet, affichage du nombre de personnes ayant pu voir le tweet, du Qualifeed Score, du nombre de réponses, du nombre de retweets et du nombre de followers au moment de la publication
• Possibilité de tweeter votre meilleur Qualifeed Score
• Mini gestion du suivi de l’effet d’une campagne sur son site (avec un tracker en Javascript)
• Graphique montrant l’évolution du nombre de followers et du nombre de fans de votre page Facebook dans le temps
• Authentification par Twitter

Bien sur l’idée est de faire évoluer le produit. Nous aimerions que petit à petit Qualifeed se rapproche de la définition suivante :

Qualifeed propose une solution de mesure de l’audience, de l’engagement et de la transformation de vos campagnes social media marketing.

Plus précisément :

Qualifeed fournit une solution de Social Inluence Management et de Social Influence Optimization pour aider les marques, les community managers et les politiques à mesurer et à améliorer de manière continue le ROI (Return On Influence) de leurs campagnes de social media marketing sur Twitter mais également sur les autres outils sociaux. Le Social Influence Dashboard fournit une vision holistique de l’audience, de l’engagement et la transformation des activités.

Conclusion

J’ai beaucoup appris ce weekend !

Tout d’abord, j’ai pu voir que Ruby on Rails est la techno choisie par la plupart des startups web qui se lancent sur Paris. Ce weekend a été une très belle démonstration des possibilités offertes par Ruby on Rails. J’espère que les startups de Sophia vont vite s’y mettre.

Ensuite, j’ai pu rencontrer des gens formidables. C’est incroyable à quel point les gens présents étaient passionnés, compétents et motivés.

Enfin, j’ai été bluffé par la quantité et la qualité du travail que les équipes ont pu réaliser en un weekend. Cela prouve bien que si l’on s’entoure de gens passionnés, on peut déplacer des montagnes !

Bref, ce weekend a été une excellente expérience. J’espère pouvoir participer à nouveau à un tel événement très bientôt !

C’est avec grand plaisir que je vous propose un cinquième épisode de ma série d’articles, Flux RSS à suivre.

Le précédent épisode avait pour thème Ruby et sa communauté. Aujourd’hui l’épisode est entièrement consacré à un des projets qui a le plus contribué à la popularité de Ruby, au framework web qui sert de source d’inspiration depuis plusieurs années à beaucoup d’autres, au framework qui permet de répondre à de nombreux besoins avec toujours une grande élégance, j’ai nommé Ruby on Rails !

Voici les sites les plus intéressants que je lis dans ma veille quotidienne pour me tenir à jour sur ce framework :

(Lire la suite…)

Il y a un mois environ, j’ai eu le plaisir de présenter Ruby on Rails avec Maxime Menant dans le cadre des SophiaConf 2010. Comme nous avions beaucoup de choses à raconter, nous avons décidé de ne pas faire une conférence mais deux, d’une durée d’une heure chacune.

La première, que j’ai présentée, s’adresse principalement aux entrepreneurs, chefs de projet, directeurs techniques… Cette conférence explique pourquoi Ruby on Rails peut-être un très bon choix technologique, pourquoi ce choix peut faire gagner du temps et de l’argent… J’en parlais dans un précédent article : Pourquoi Ruby on Rails est génial? (d’un point de vu non technique)

Aujourd’hui, je souhaite partager avec vous la deuxième conférence, présentée par Maxime. Celle-ci s’adresse principalement aux développeurs. Elle présente Ruby et Ruby on Rails tout en mettant en avant les points forts de ce couple fusionnel.

Pourquoi Ruby et Ruby on Rails sont geniaux ?

• Les slides (pdf)
• La vidéo

Il y a un mois environ, j’ai eu le plaisir de présenter Ruby on Rails avec Maxime Menant dans le cadre des SophiaConf 2010. Comme nous avions beaucoup de choses à raconter, nous avons décidé de ne pas faire une conférence mais deux, d’une durée d’une heure.

La première, que j’ai présentée, s’adresse principalement aux entrepreneurs, chefs de projet, directeurs techniques… Cette conférence explique pourquoi Ruby on Rails peut-être un très bon choix technologique, pourquoi ce choix peut faire gagner du temps et de l’argent…

La deuxième, présentée par Maxime, avait pour but de démontrer la puissance de cette technologie aux développeurs.

Dans ce billet, je vais présenter la première conférence. Je parlerai de la deuxième dans un autre billet que je publierai prochainement.

Ruby on Rails d’un point de vue non technique

• Les slides (pdf)
• La video

(Lire la suite…)