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
Super article ! Je vais l’imprimer pour le coller sur la table ce week-end…
Je rajouterais un autre conseil super important (mais qui n’a pas grand chose à voir avec le dev) : éclatez-vous et faites-vous plaisir !
A demain ;)
Fred
Bon article.
Mais comme je le dis après participé à deux Startup Weekend, l’avancement du développement du projet ou de son prototype n’est pas pris en compte par le jury.
J’ai vu de nombreux projets sans aucun développement mais avec une super présentation être dans les premiers, et l’inverse, des projets avec un super prototype mais une présentation moyenne être totalement recalés.
Cela ne motive pas du tout les développeurs, à tel point que je me demande s’il ne vaut pas mieux mettre toutes les ressources sur l’unique présentation de fin de week end.
Dommage…
Il faudrait absolument une moyenne entre la présentation du projet et le prototype pour que le travail des développeurs de l’équipe soit apprécié à sa juste valeur.
@Nicolas comme ça a déjà été dit, le SW n’est pas un concours de programmation et je trouve ça plutôt sain (mais frustrant pour les devs, certes).
@Camille je rajouterai que ça 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 »
Je n’ai jamais dit que le SW est un concours de programmation et effectivement cela ne doit pas l’être.
Je constate simplement que l’on invite une grosse partie de développeurs, et qu’une très grosse partie de ces développeurs s’impliquent dans la réalisation de prototypes durant un StartupWeekend.
Pour peu de valeur comparé à la présentation. Autant qu’ils ne jouent le rôle que de simples consultants dans ce cas sans taper la moindre ligne…
Super article ! Je vais l’imprimer pour le coller sur la table ce week-end…
Je rajouterais un autre conseil super important (mais qui n’a pas grand chose à voir avec le dev) : éclatez-vous et faites-vous plaisir !
A demain ;)
Fred
Bon article.
Mais comme je le dis après participé à deux Startup Weekend, l’avancement du développement du projet ou de son prototype n’est pas pris en compte par le jury.
J’ai vu de nombreux projets sans aucun développement mais avec une super présentation être dans les premiers, et l’inverse, des projets avec un super prototype mais une présentation moyenne être totalement recalés.
Cela ne motive pas du tout les développeurs, à tel point que je me demande s’il ne vaut pas mieux mettre toutes les ressources sur l’unique présentation de fin de week end.
Dommage…
Il faudrait absolument une moyenne entre la présentation du projet et le prototype pour que le travail des développeurs de l’équipe soit apprécié à sa juste valeur.
@Nicolas comme ça a déjà été dit, le SW n’est pas un concours de programmation et je trouve ça plutôt sain (mais frustrant pour les devs, certes).
@Camille je rajouterai que ça 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 »
Je n’ai jamais dit que le SW est un concours de programmation et effectivement cela ne doit pas l’être.
Je constate simplement que l’on invite une grosse partie de développeurs, et qu’une très grosse partie de ces développeurs s’impliquent dans la réalisation de prototypes durant un StartupWeekend.
Pour peu de valeur comparé à la présentation. Autant qu’ils ne jouent le rôle que de simples consultants dans ce cas sans taper la moindre ligne…
N’ayant jamais été à un SW je vais peut-être faire tache en disant ce que je vais dire…
En tant que développeur je trouve l’ensemble de l’article très bon bien que très orienté RoR ou du moins Ruby. Mon autre critique est la recommandation d’éviter des solutions de type NoSQL comme MongoDB alors que dans certains cas cela peut éventuellement permettre un gain de temps (je pense aux idées qui impliquerait de la géoloc).
N’ayant jamais été à un SW je vais peut-être faire tache en disant ce que je vais dire…
En tant que développeur je trouve l’ensemble de l’article très bon bien que très orienté RoR ou du moins Ruby. Mon autre critique est la recommandation d’éviter des solutions de type NoSQL comme MongoDB alors que dans certains cas cela peut éventuellement permettre un gain de temps (je pense aux idées qui impliquerait de la géoloc).
Pour l’envoi d’email il y a mailjet qui est gratuit jusqu’à 6000 emails/mois et qui est très simple à mettre en oeuvre (SMTP). Sendgrid est gratuit jusqu’à 200/jour, c’est plus restrictif surtout si le site a un peu de succès lors de sa mise en ligne ;)
Pour l’envoi d’email il y a mailjet qui est gratuit jusqu’à 6000 emails/mois et qui est très simple à mettre en oeuvre (SMTP). Sendgrid est gratuit jusqu’à 200/jour, c’est plus restrictif surtout si le site a un peu de succès lors de sa mise en ligne ;)
[…] 6. As-tu des éléments supplémentaires à conseiller pour de futurs startup weekenders / auxquels tu feras particulièrement attention à ton prochain (Startup Weekend Toulouse le 13, 14 et 15 mai ? Bordeaux la semaine d’après ?) ? Un Startup Weekend est une expérience très enrichissante. Profitez du weekend pour faire du réseau, apprendre de nouvelles méthodes/pratiques, mieux comprendre certains marchés… Personnellement, les Startup Weekends m’ont apporté beaucoup de choses : j’ai rencontré de gens “comme moi” (c’est une phrase qui revient souvent parmi les gens qui ont vécu cette expérience) j’ai appris des méthodes pour faire un business model (les business model canvas par exemple) j’ai mieux compris le rôle des market/biz et comment travailler avec eux j’ai découvert le vrai monde des startups … Si vous êtes développeur, je vous invite à lire le billet sur mon blog contenant quelques conseils utiles pour un Startup Weekend. […]
[…] Startup Weekend : 10 conseils pour les développeurs web, par Camille Roux, développeur – startuper – participant – organisateur… ! […]
[…] Startup Weekend: 10 conseils pour les développeurs web Tweet Innovation, Perso Startup Week-end […]