Michel Pigassou

Jeune ingénieur intéressé par l'évolution des technologies, les méthodes Agile, le web, les médias sociaux et l'entrepreneuriat.



Profil technique (principalement développement web et Ruby on Rails) et fonctionnel (gestion de projet, méthodes Agile, conseil architecture web et commerce électronique), avec un intérêt prononcé pour l'intégration des médiaux sociaux en entreprise.

CV complet : http://www.doyoubuzz.com/michel-pigassou

Profile

Michel Pigassou
Entrepreuneur, passioné du web et créateur d'applications en ligne
Information Technology and Services | France, FR

Summary

Jeune ingénieur intéressé par l'évolution des technologies, les méthodes Agile, le web, les médias sociaux et l'entrepreneuriat.

Profil technique (principalement développement web et Ruby on Rails) et fonctionnel (gestion de projet, méthodes Agile, conseil architecture web et commerce électronique), avec un intérêt prononcé pour l'intégration des médiaux sociaux en entreprise.
Specialties: Compétences managériales Création et gestion d'entreprise Intégration de sytèmes de traitement de l’information Projets, processus et activités Gestion de l'information sur les médias sociaux et collaboratifs Intégration des méthodes de développement Agile Compétences informatiques Conception, développement web et SaaS, création d'une API Référencement SEO/SEM, outils d’analyse et de veille Connexion avec des API distantes, synchronisation de données

Experience

  • Apr 2011 - Present
    Co-fondateur / FidzUp
  • May 2010 - Mar 2011
    Ingénieur logiciel / Nimble Apps SAS
    Participation au développement général de SalesClic, conception et développement de l'export des données de l'application vers Excel et Google Docs (stage 6 mois).

    Spécialisation dans l'interconnexion de SalesClic avec des services web (Google Contacts, Docs, réseaux sociaux) pour la recherche, l'export ou la synchronisation de données.
  • Dec 2009 - May 2010
    Développeur Ruby on Rails / Nimble Apps SAS
    Participation en alternance avec les études au développement de SalesClic, une application web d'analyse commerciale et de prévision des ventes.
  • Dec 2009 - Apr 2010
    MOA et MOE sur la création d'un réseau social culinaire (projet de fin d'étude) / EISTI
    Gestion d'un groupe de six personnes pour la création d'une entreprise virtuelle (étude de marché, business plan, administratif) éditant un réseau social spécialisé dans la cuisine (écriture collaborative de recettes, articles, médias).

Education

  • 2008 - 2010
    Université de Pau et des Pays de l'Adour
    Master Administration des Entreprises in Management, administration et gestion des entreprises
  • 2005 - 2010
    Ecole internationale des Sciences du Traitement de l'Information
    Ingénieur en informatique in Informatique, management
    Activities: Président de AIR-EISTI 2007-2008 et 2008-2009

Additional Information

Websites:
La fidélité mobile avec FidzUp, Personal Website
Honors:
Bourse de voyage Zellidja (www.zellidja.fr)
Interests:
Médias sociaux, Entrepreneuriat, Gestion de projet, Méthodes Agile, Développement web, Ruby on Rails, Culture asiatique, Web
CV LinkedIn

Posts

October 18, 03:47 AM
What Ruby’s ||= (Double Pipe / Or Equals) Really Does

What Ruby’s ||= (Double Pipe / Or Equals) Really Does
via rubyinside.com

Article intéressant à lire, en anglais.

Permalink | Leave a comment  »

October 16, 02:42 PM
Ruby 1.9.3-rc1 et le debugger

Si vous voulez tester la dernière RC de Ruby 1.9.3, il vous faudra surmonter quelques étapes avant de pouvoir l'utiliser complètement (avec le debugger, pour une appli Rails par exemple).

Pour l'instant les gems ruby-debug-base19 et linecache19 ne sont pas à jour sur Rubygems. Il faut aller les récupérer sur Rubyforge : http://rubyforge.org/projects/ruby-debug19/

L'installation est simple (exemple avec RVM, sinon remplacez simplement selon votre cas) :

gem install ~/Téléchargements/linecache19-0.5.13.gem
gem install ~/Téléchargements/ruby-debug-base19-0.11.26.gem --with-ruby-include=\$rvm_path/src/\$rvm_ruby_string

Normalement vous devriez être bon.

Si vous voulez suivre les conversations sur les mises à jour de ces gems :

Pourquoi utiliser Ruby 1.9.3 ?

Pour faire court, même si c'est une Release Candidate, l'amélioration côté performances est significative (même pour une 1.9.2 patchée !). Il ne reste plus qu'à attendre que tout soit mis à jour côté Rubygems pour retrouver la même souplesse qu'avant.

Permalink | Leave a comment  »

May 16, 05:00 AM
Les fichiers encryptés de Dropbox peuvent être décryptés par leurs équipes

via zdnet.com

Selon ZDNet, Dropbox affirmait que ses équipes ne pouvaient pas décrypter les fichier déposés par les utilisateurs sur leur service de stockage en ligne.

Suite à quelques remarques sur leur manière de gérer le contenu dupliqué sur différents comptes (http://paranoia.dubfire.net/2011/04/how-dropbox-sacrifices-user-privacy-for.h... Dropbox a corrigé le tir sur son site à propos de la sécurité de ses fichiers en précisant comment leurs équipes peuvent les lire.

Ceux qui ont des choses à cacher apprécieront (http://www.zdnet.com/blog/government/if-you-have-something-to-hide-from-the-g...).

Permalink | Leave a comment  »

March 31, 05:30 AM
L'importance des retours réguliers dans l'Agile

InfoQ publie un billet qui me plait bien, The Importance of Agile Feedback Loops, dont le titre est difficile à traduire littéralement. Cet article aborde un point important des méthodes Agile et en voici une retranscription adaptée à ma sauce.

On parle ici d'itération sur un processus dont le résultat va influencer son propre fonctionnement dans le futur. C'est ce qui est appelé dans l'article feedback loop. Plus ce feedback est régulier et rapide, mieux c'est.

On trouve des processus qui ont des feedback loop dans les méthodes XP (Extreme programming) et Scrum :
- tests unitaires, pair programming et intégration continue (XP) ; 
- daily scrums (réunions quotidiennes), et sprints (Scrum*).

Dans ces exemples, le schéma de fonctionnement est le suivant : changer quelque chose => regarder le résultat => analyser les conséquences => changer de nouveau quelque chose.

L'article cite un billet, Quality in software, qui donne d'autres exemples de pratiques Agile qui permettent de mettre en place des feedbacks réguliers :
- les revues de code (analyse statique : on relit le code d'autres personnes afin de l'améliorer) ;
- automatisation des tests d'intégration et d'acceptance ;
- collaboration étroite entre tous les acteurs du projet (développeurs, opérationnels, managers, clients, etc.) - l'auteur du billet cite le bouquin Management 3.0 : "I think that people are the most important parts of an organization and that managers must do all they can to keep people active, creative and motivated." ;
- améliorer la fréquence des releases (notamment en ayant un déploiement automatique du produit sur les serveurs, eux-mêmes configurés automatiquement, etc.) ;
- et de manière plus technique et générale, le refactoring.

On notera la mention de Release It!, qui est le pendant de Ship It! dont j'avais déjà parlé ici.

Pour terminer, je prendrai la même conclusion que l'article original sur InfoQ : au délà des améliorations de la productivité et des processus, les feedbacks permettent aussi aux équipes de se sentir plus à l'aise.

If we have a continuous integration process that runs our regression tests on each new version of the code, we know within a few minutes or hours whether new or updated code has broken something. When we know right away, it's easy to fix. Problems don't worry us, because we know we can fix them in a timely manner and move on.

Short feedback loops give us confidence. Confidence leads to enjoyment.

(soure de la citation)

* Petit apparté : beaucoup de personne ont tendance à réduire Scrum aux sprints, ce qui est faux. Les itérations pour les releases de code sont juste une pratique Agile, formalisée par Scrum. Mais Scrum développe plein d'autres points, notamment au niveau de la collaboration entre personnes.

Permalink | Leave a comment  »

March 29, 05:30 AM
Votre musique en ligne avec Amazon Cloud Player

via techcrunch.com

Amazon coupe l'herbe sous le pied de Google et Apple !

L'offre gratuite permet de profiter d'un espace de 5 Go pour stocker sa musique (ou ses films de vacances), mais en achetant un album sur Amazon MP3, vous obtenez 20 Go gratuits pendant 1 an ! En plus, ce n'est pas cher : 20$ par an pour 20 Go, 50$ pour 50 Go, 100 pour 100 et 1000 pour 1000 (1 To).

Pour l'instant, ce n'est disponible que pour les américains, mais cela va vite arriver chez nous. Les possesseurs d'iPhone seront dessus aussi, puisqu'il n'y a pas (encore ?) d'application iOS ; eh oui, pour une fois Android est servi en premier !

On peut espérer que les offres types Dropbox ou Box.net, qui permettent aussi de stocker de la musique, revoient leur pricing à la baisse.

Permalink | Leave a comment  »

February 23, 06:30 PM
Une application Facebook pour être informé des changement de couples de vos amis dépasse 3 millions de membres

via techcrunch.com

L'application Breakup Notifier permet de recevoir des notifications dès qu'une personne que vous surveillez change son statut relationnel (en couple, célibataire, etc.).

Elle a dépassé hier les 3,6 millions de membres et bient d'être bloquée par Facebook qui effectue des vérifications sur son fonctionnement.

J'espère qu'un jour on saura le pourcentage d'hommes qui utilisent cette application ; quelque chose me dit qu'ils sont plus nombreux que les femmes.

Encore une preuve que tout ce qui touche au sexe et aux rencontres fait vendre !

Pour la télécharger : http://www.breakupnotifier.com

Permalink | Leave a comment  »

February 14, 05:00 AM
Organisez votre mariage avec Google Wedding


Google se propose d'organiser votre mariage ! Pour cela ils mettent à votre disposition plusieurs de leurs outils gratuits : Picasa, Sites, Docs et Picnik.

Picasa permet de mettre des photos en ligne, Picnik de les retoucher, Sites de créer un site Web en quelques minutes, et enfin Docs vous permet de créer des listes de choses à faire (to-do lists), d'organiser le budget, d'écrire les invitations ou encore le placement des invités, grâce aux modèles de documents.

Rendez-vous sur http://www.google.com/weddings pour en profiter, à condition de lire un minimum l'anglais.

Permalink | Leave a comment  »

February 11, 05:00 AM
Améliorer son référencement naturel SEO en 5 étapes

1. Utilisez des mots clés appropriés. Vous pouvez commencer par faire des brainstormings en équipe, et ensuite utiliser des outils pour affiner vos recherche et avoir une estimation des coûts, avec des outils tels que Google Adwords KeywordTool ou KeywordSpy.

2. Chaque page de votre site doit avoir un titre unique (balise HTML 'title'). Le titre doit refléter le contenu de la page, et pas simplement le nom de votre site.

3. Remplissez les balises de métadonnées (ou vérifiez que votre CMS les gère). Les balises HTML 'metadata' contiennent des informations sur votre page et votre site. Certaines sont utiles, d'autres non ; le débat fait rage dans la communauté SEO, entre les gourous et ceux qui ont fait des tests avec Google. En tous cas, ça ne coûte pas plus cher d'avoir une description bien rédigée et quelques mots clés ciblés. Personnellement, j'aime ajouter des métadonnées au format Dublin Core.

4. Les liens vers votre site sont importants. Vous devez faire en sorte que le plus de sites possible affichent un lien vers votre site (attention, certains liens peuvent n'avoir aucune valeur, c'est souvent le cas dans les commentaires de blog). L'article mentionne aussi l'importance de la multiplication des liens internes. Autant je suis convaincu qu'une bonne architecture de lien est utile, autant je suis sceptique au niveau de la quantité.

5. Analysez le classement de votre site. Des outils gratuits permettent d'avoir des informations sur votre référencement, comme Woorank.com ou Website Grader. Je conseillerais aussi Webmaster Tools de Google.

L'article complet : http://socialmediatoday.com/len-ostroff/268803/five-easy-ways-boost-seo

Permalink | Leave a comment  »

February 10, 05:00 AM
Pour calculer, il faut savoir parler

Sans pouvoir mettre de mot sur un concept aussi simple que les chiffres, les Hommes sont incapables de se représenter des quantités exactes supérieures au chiffre 3. Le calcul mental ne serait donc pas inné, mais facilité par l’utilisation d'un langage permettant de définir les nombres.

La suite sur Futura-Sciences : http://www.futura-sciences.com/fr/news/t/medecine/d/pour-calculer-il-faut-sav...

Permalink | Leave a comment  »

February 07, 06:29 AM
Fiche de lecture : "Rework", ou comment bien (re)organiser sa société

Rework est le second livre de la société 37signals. À la base simple agence web, c'est en développant des logiciels destinés à un usage interne mais tellement appréciés de leurs clients qu'ils ont fait du développement logiciel en ligne (on parle de SaaS pour Software as à Service) leur activité principale.

Aujourd'hui, la société est connue pour ses logiciels à succès, mais aussi pour être à l'origine de Ruby on Rails, et enfin pour sa manière de développer une entreprise innovante et très efficace.

Rework est découpé en plusieurs thèmes, chaque thème comprenant plusieurs chapitres assez courts. Fidèle aux habitudes de 37signals, leur livre transgresse les codes du genre et propose une synthèse claire en un peu plus de 250 pages, plutôt qu'un pavé illisible et interminable.

Quelques points abordés : la culture d'entreprise, le recrutement, la productivité ou encore la compétition avec d'autres entreprises.
Leur vision des choses est très tranchée, pour ne pas dire extrême. Par exemple les premiers chapitres conseillent d'ignorer le monde réel, de ne pas planifier, de garder la société de la taille la plus petite possible, ou encore de ne pas trop travailler.

Lorsqu'on rentre vraiment dans le livre, on comprend que ces conseils ont un sens. Je ne pense pas que le but de 37signals était de donner une unique recette pour créer la société idéale, mais plutôt quelques directives sur le modèle des choses qui ont fonctionnées chez eux.

De manière générale je trouve les conseils dispensés très pertinents, mais pas toujours faciles à appliquer. Par exemple au niveau du recrutement, tout le monde sait bien que les CV n'ont que peu de valeurs, de même que le diplôme, mais il est difficile de s'en abstraire totalement dans un pays comme le notre ou la formation vaut plus que l'expérience.

Pour conclure, la lecture du livre est intéressante car l'approche radicale utilisée permet de voir ce qui est efficace, à condition je pense de ne pas vouloir reproduire exactement la même chose au risque de se casser la pipe. Certaines parties pourraient être plus fournies mais le lecteur curieux pourra lire le blog de la société qui regorge de billets tout aussi intéressants.

Permalink | Leave a comment  »

January 24, 07:25 AM
Allez voir les Voca-People !

 Les extra-terrestres existent, ils s'appellent les Voca-People, et pour les voir il faut aller au théâtre Bobino à Paris.

À l'origine ils se sont fait connaître grâce à des vidéos sur Youtube, avant de tourner des pubs pour Tic-Tac en France. Leurs personnages apparaissent dans les vidéos comme dans leur spectacle tout de blanc vêtus. Enfin, leur particularité est de faire un show entièrement a capella et bourré d'humour.

Ayant eu la chance d'assister au spectacle, je recommande vraiment à tout le monde d'aller les voir, en couple ou avec toute la famille.

Permalink | Leave a comment  »

December 14, 08:00 AM
Google veut nous aider à apprendre l'informatique à nos parents

Avec son site Teach Parents Tech (teachparentstech.org, pour l'instant en anglais seulement), Google permet d'envoyer à ses parents ou sa famille des vidéos sur les bases de l'informatique (copier-coller, naviguer sur Internet, lire ses emails, etc.) et nous économise ainsi de longues conversations téléphoniques.

A quand la version française ?

Permalink | Leave a comment  »

December 14, 06:00 AM
LeWeb : quelques comptes rendus à lire

La semaine dernière se tenait l'événement incontournable du numérique organisé par le couple Le Meur.

Quelques comptes rendus :

#LeWeb10 En 5 Points! par Romain David

LeWeb’10 : ce que j’en ai retenu par Presse-Citron

Compte-rendu de LeWeb10 par Frédéric Cavazza

Géraldine et Loïc LeWeb : un seul mot Bravo... par Jean-Michel Billaut

Dans ces analyses, les commentaires que je trouve intéressant (hormis ceux envers l'organisation, apparemment plutôt réussie) concernent Twitter (annonce de départs, échecs subis en voulant faire des modifications trop importantes), Google (Android Gingerbread et la nouvelle version de Maps - qui va tout déchirer !) et le mobile avec Foursquare dont on va de nouveau entendre parler bientôt, Rovio et ses Angry Birds qui cartonnent en mode gratuit, le paiement mobile et les social games qui vont bientôt envahir notre quotidien.

Permalink | Leave a comment  »

December 07, 07:44 AM
Que se passe-t-il en 24h sur les médias sociaux ?
October 26, 08:17 AM
Facebook permet de voir quels moments de l'année sont les plus propices aux ruptures
October 21, 12:48 PM
Des cookies Gmail
October 15, 05:30 AM
Recette (Dukan) des crêpes salées, légères et fourrées

Cette recette en est inspirée d'une autre trouvée sur le net : http://emilieregimedukan.skyrock.com/2804913087-CREPES-SANS-TOLERES-PP-PL.html. Elle convient parfaitement pour le régime Dukan.

Pour 3 personnes (ou deux affamées), il vous faut :
- 3 oeufs
- 10 cuillères à soupe de lait écrémé en poudre
- 2 cuillères à soupe de fromage blanc 0%
- 3 tranches de jambon dégraisse et découenné
- 1 steak haché à faible teneur en matière grasse 
- 3 cuillères à soupe de pulpe de tomate 
- 1 oignon
- 1 échalote
- sel, poivre, épices

La recette est simple.

D'un côté, mélangez les oeufs avec le lait, et ajoutez un peu de sel. Pour que la pâte soit plus fluide vous pouvez y ajouter quelques cuillères de lait écrémé liquide, ou au pire un peu d'eau. 

De l'autre, commencez par couper l'oignon et l’échalote finement, puis faites les cuire à l'étouffée (quelques minutes à feu doux, couvert et avec un peu d'eau).

Mélangez ensuite dans un saladier le jambon, que vous aurez pris le soin d'émieter, et le steak cuit.

Rajoutez le fromage blanc, sel, poivre, épices, tomate puis remuez. Enfin, remettez le tout à cuire quelques minutes à feu doux avec l'oignon et l'échalote.

Vous pouvez maintenant faire cuire les crêpes, dans une autre poêle ou une crepière préalablement enduite de quelques gouttes d'huile. Suivant la puissance du feu il faut compter 2 à 3 minutes sur la première face et un peu moins une fois retournées.

En fin de cuisson, étalez une partie de la garniture au centre, pliez la crêpe et servez !

 

Permalink | Leave a comment  »

October 07, 10:52 AM
Lecture : Ship It! A Practical Guide to Successful Software Projects

Ship It! n'est pas un livre sur une méthodologie à suivre pour le développement logiciel, mais plutôt sur un ensemble de bonnes pratiques éprouvées par leurs auteurs, Jared Richardson et William Gwaltney Jr. au sein de SAS, éditeur bien connu dans le monde de l'informatique décisionnelle. L'approche des auteurs est pragmatique : les méthodes qui sont expliquées sont le fruit de longues années de pratique, d'observation et d'expérience pour "garder les bonnes choses et éliminer le reste" (extrait du quatrième de couverture).

Le livre est découpé en quatre thèmes principaux. Au sein de chaque partie certains éléments sont destinés aux chefs d'équipe ou aux managers, le reste ciblant les développeurs.
1) Outils et infrastructure : ce qu'il faut mettre en place pour travailler correctement et dans de bonnes conditions ;
2) Techniques pragmatiques de projet : méthodes d'organisation du travail en équipe ;
3) Tracer Bullet Development : une méthode de développement ;
4) Résolution de problèmes courants : présentation de plusieurs problèmes et comment les résoudre.

Mon avis et le résumé dans la suite du billet !
Mon avis

Certains pourraient considérer ce livre comme trop basique et inutile. Au contraire, je trouve qu'il synthétise bien la base du travail en matière de création de logiciel et qu'il serait trop facile de passer à côté de certains points "évidents", mais qui sont encore rarement appliqués (surtout dans les entreprises françaises). C'est bien la preuve qu'il faut commencer quelque part, et en ce sens Ship It! permet d'avoir d’excellents exemples des choses à faire ou ne pas faire.

La troisième partie est celle qui m'a le moins parlé, parce qu'à mon sens cette méthode est plus destinée à des développements de logiciels desktop (par opposition aux applications et services sur Internet). Elle peut cependant constituer une bonne base, à condition d'avoir une équipe assez grosse pour que l'ensemble du projet avance correctement dès le départ.

Mis à part ce point j'ai vraiment apprécié de voir regroupé dans un livre ces techniques, avec des applications pratiques plutôt que de la simple théorie comme on peut en trouver en gestion de projet. L'esprit se rapproche beaucoup de celui des méthodes Agile, leur but étant d'aboutir à un développement final de meilleure qualité et de travailler avec des personnes plus souples (agiles), plus réactives et plus interactives au sein de leurs équipes.

Intéressant et rapide à lire, je recommande donc ce livre à tous ceux qui souhaitent se lancer par eux-mêmes ainsi qu'à ceux qui sont déjà en poste pour apporter de bonnes idées dans leur entreprises.

Résumé

Outils et infrastructure

Cette partie se concentre sur le côté logiciel de la gestion de projet : utilité des logiciels de contrôle de version, mécanismes des systèmes de compilation (build), gestion des bugs et évolutions et enfin, les tests.

L'illustration de début de chapitre est très parlante, et je me permets d'en donner une traduction grossière ici : prenons deux constructeurs de maison. Le premier, Mike, commence par acheter des nouveaux outils et prend du temps pour apprendre à les utiliser. Le second, Joe, utilise les outils qu'il possède déjà et se met au travail. Bien sûr, la maison de Joe avance plus vite. Mais une fois l'apprentissage de Mike terminé, il rattrape très vite son retard et finit par dépasser Joe ! De plus, la prochaine maison de Mike sera construite encore plus vite.

Le but est bien évidemment de montrer qu'avec les bons outils on progresse au final plus vite, même si on a l'impression de passer trop de temps à apprendre comment les utiliser alors qu'on pourrait commencer à coder. La clé est de voir sur le long terme et pas seulement pour les quelques mois (années ?) que vont durer le premier projet.

Les concepts développés dans cette partie sont certes basiques mais encore une fois il n'est pas mauvais de les rappeler.

- Principe du bac à sable : développer dans un environnement isolé. Le but est de ne pas impacter le travail de ses collègues avec son propre code (et ses bugs...), et encore moins l'environnement de production.

- Gestion des ressources : pouvoir partager son code de manière instantanée avec le reste de l'équipe et l'historique de chaque fichier. C'est ce but que permettent d'attendre les logiciels de contrôle de version (CSV, SVN, Git, etc.) plutôt que la bonne vieille méthode du disque réseau (ou pire, de la clé USB). Pourquoi ? En vrac et de manière non exhaustive, pour pouvoir à tout moment revenir sur une ancienne version (si il y a un bug très important sur la production, il suffit de quelques secondes pour revenir à la dernière version stable connue !), gérer les conflits entre l'édition d'un même fichier par plusieurs personnes ou encore voir l'historiques des modification d'un fichier par date et auteur, etc.

- Compilation par script : plutôt que d'utiliser son éditeur de code pour compiler (qui de toutes façons ne sera pas partagé par tout le monde, et encore moins par le serveur de prod), prendre le temps de faire des scripts propres pour compiler chaque jour une version du code et lancer des tests dessus de manière automatique.

- Gérer les bugs, évolutions, etc. : on peut certes utiliser Excel (ce qui reste mieux que des Post-It) pour savoir quelles sont les tâches sur lesquelles l'équipe doit travailler, les bugs importants ou encore les demandes d'évolution, mais le mieux est de donner l'accès à tout l'équipe à une même interface qui permettra de consulter ces informations (ainsi que de les modifier et en ajouter). Ces logiciels permettent de suivre l'évolution du projet, de gérer les listes des tâches, les priorités ou encore de permettre à des non-développeurs (par exemple le support) de voir toutes ces informations.

- Automatisation des tests : le problème des tests, c'est que d'une part on pense peu souvent à en faire (même si aucune personne au monde ne peut prouver qu'ils ne sont pas utiles...), mais que même si on en a ils ne sont jamais lancés. Il est donc important d'avoir des tests (par exemple des tests unitaires sur la logique métier du code, mais de manière plus générale de multiplier leur nature : fonctionnels, de performance, charge, intégration, etc.), de les maintenir et enfin d'automatiser leur exécution pour éviter de reproduire des problèmes déjà corrigés et s'assurer de la bonne santé de l'intégralité du projet. L'automatisation permet d'éviter le stress des tests lancés une fois de temps en temps et du temps perdu à quelques heures du rendu final...

Techniques pragmatiques de projet

L'accent est mis ici sur l'organisation du travail en équipe (autant l'individu au sein de l'équipe que l'équipe en elle-même), en montrant l'intérêt de courtes réunions quotidiennes et de revues de code pour améliorer la communication intra-équipe par exemple.

- Utiliser une liste de tâche : intégrée dans les logiciels de suivi des bugs/évolutions, les listes permettent à tout moment de savoir qui doit faire quoi en priorité, qui travaille sur quoi actuellement, le temps passé sur une tâche, etc. Chaque membre de l'équipe peut ainsi connaître et organiser son travail, et en informer ses collègues. Les fonctionnalités à intégrer sont, une fois entrées, attribuées puis terminées : un autre intérêt est donc de savoir quand est-ce qu'on a fini réellement le travail (c'est-à-dire lorsqu'il n'y a plus de fonctionnalités à implémenter ou de bugs à corriger). Bien sûr, il est important de respecter certaines règles pour concevoir de manière efficace une liste (sur la durée des tâches, leur découpage, leur nommage, etc.) ; règles qui sont expliquées dans cette partie.

- Avoir un tech lead (chef de projet technique, en quelques sortes) : cette personne encadre l'équipe et permet de recadrer les exigences de la direction. Plus simplement, c'est le tampon entre les personnes non techniques et l'équipe technique, dont il doit assurer la qualité du travail (en particulier en étant responsable de la fameuse liste des tâches).

- Communication dans l'équipe : utiliser des réunions quotidiennes (courtes, quelques minutes !) pour s'assurer que tout le monde travaille dans la même direction, ne rencontre pas de difficultés particulières et présente en quelques mots sont avancement. Le but n'est pas de faire un état des lieux détaillé mais plutôt de se concentrer sur l'insertion du travail d'une personne dans la globalité du projet. Le plus compliqué dans ces réunions consiste à ne pas sortir de leur cadre.

- Relectures fréquentes du code : faire relire son code par une autre personne permet de détecter des erreurs en ayant une autre perspective (souvent nécessaire parce qu'on a le "nez dans le guidon") et d'obtenir une meilleure qualité (performance des algorithmes, cohérence du code, pertinence des commentaires, etc.). Après plusieurs relectures, les personnes améliorent directement leur code parce qu'elles savent que quelqu'un d'autre va le relire et au final le projet ne s'en porte que mieux. Les relectures doivent être nombreuses et se concentrer sur des petites portions de code ; sinon on arrive à faire une seule relecture en fin de tâche ou de projet, qui s’avérera coûteuse en temps et en énergie.

Tracer Bullet Development

Les auteurs présentent dans cette partie leur propre méthode de développement, peaufinée au fil du temps. Ils jugent qu'il s'agit d'un bon départ pour des gros projets en permettant de les découper en plusieurs pièces, sur lesquelles l'équipe peut mieux répartir son travail. Ils insistent bien sur le fait qu'il n'existe pas UNE méthode universelle : il faut expérimenter et ajuster pour obtenir une méthode en adéquation avec chaque projet.

Le principe du TBD est de séparer le cœur du logiciel en plusieurs parties - ou couches - distinctes, qui peuvent agir de manière autonome. Ainsi, il est facile d'affecter des personnes à ces éléments car les équipes peuvent avancer indépendamment du travail des autres. Il est néanmoins nécessaire de définir à l'avance l'interface de communication entre les différentes couches (c'est la manière dont elles vont communiquer, pour permettre par exemple leur fonctionnement sur des machines distinctes). 

Résolution de problèmes courants

Enfin, le dernier chapitre du livre est un recueil de problèmes pour éviter de reproduire certaines erreurs.

Quelques exemples :

- Tester du code qui n'est pas testable : utiliser du test driven refactoring (refonte dirigé par les tests) en écrivant un test, en modifiant ensuite la partie de l'application sur laquelle porte le test, en revenant ensuite sur le test, etc.

- "Mais ça fonctionne chez moi" : pourquoi et comment éviter de dire que cela fonctionne chez soi. Si on soumet le problème c'est bien que quelque part, il y a quelque chose qui ne fonctionne pas.

- Les clients ne sont pas satisfaits : travailler avec les clients tout au long du projet pour recueillir leurs avis en continu. Éventuellement en maintenant une version de démonstration (même incomplète ou buggée), ou en leur donnant accès à la liste des fonctionnalités ou la possibilité de soumettre des bugs.

- Il n'y a pas de cohésion dans le travail d'équipe : instaurer des réunions quotidiennes (si ce n'est pas déjà fait), renforcer les interactions entre les membres avec les relectures de code, etc.

- Le projet n'est jamais terminé, ie. les fonctionnalités sont constamment revues, modifiées et au final rien n'est terminé... : mettre en place une liste claire des fonctionnalités, définir des priorités et définir ce qui doit être terminé pour tel ou tel livrable.

Permalink | Leave a comment  »

October 04, 06:10 AM
Une étape de la fabrication des nuggets de poulet - pas envie d'en savoir plus

via journaldugeek.com

Info ou intox ? Dans le doute, j'éviterai à l'avenir !

Permalink | Leave a comment  »

September 20, 04:54 AM
Si Facebook fabriquait des voitures
Blog
abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz