Comment gérer efficacement une équipe de développeurs en offshore

[((/dotclear/public/traductions/.colocate_t.jpg|Offshore colocation|L|Offshore colocation))|/dotclear/public/traductions/colocate.png]J’ai traduit un billet intéressant de Derek Huether : ++[« How To Effectively Manage An Offshore Team Of Developers »|http://thecriticalpath.info/index.php/2009/11/19/how-to-effectively-manage-an-offshore-team-of-developers/|en]++.%%% %%% > Il y a probablement deux raisons principales pour utiliser une équipe offshore :%%% > (1) Vos clients sont également offshore, ou%%% > (2) vous espérez faire des gains sur les coûts de développement.%%% > %%% > Je vais supposer que votre raison est la numéro (2). Bien que ce billet soit trop court pour un sujet aussi complexe, il devrait vous donner quelques éléments de réflexion. Effectivement, vous pouvez certainement gagner beaucoup sur les frais de développement. Mais vous pouvez aussi perdre pas mal d’argent dans des activités de rework s’il y a des problèmes de communication.%%% > %%% > __Comment pouvez-vous franchir la barrière des langues ?__%%% > (1) Vous avez besoin d’un meneur (~go-to-guy) qui parle la même langue que vos développeurs, mais qui travaillera au même endroit que vous. C’est obligatoire. Vos chances de succès augmenteront en vous assurant qu’il n’y a pas rupture dans les communications.%%% > %%% > __Comment vérifiez-vous la qualité du code ?__%%% > (1) Utilisez l’intégration continue%%% > (2) Utilisez des scripts de test pour comprendre les exigences%%% > (3) Faites des itérations courtes%%% > (4) Packagez régulièrement%%% > (5) Séparez les équipes par fonctionnalité (et non par activité)%%% > %%% > __Comment communiquez-vous ?__%%% > (1) Si vous pouvez vous permettre d’envoyer quelqu’un (ambassadeur) pour travailler avec l’autre équipe au début du projet, faites-le.%%% > (2) Il est essentiel que votre meneur ait une réunion quotidienne avec l’équipe. Choisissez une méthode qui permette à chacun de voir l’autre (Webcam / Skype).%%% > (3) Assurez-vous que tout le monde ait recours à Skype (VoIP) et / ou un client Chat pour les communications en face-à-face.%%% > (4) Conservez une connexion Skype ouverte entre les bureaux.%%% > (5) Utilisez des wikis ou autres solutions collaboratives pour partager les informations du projet.%%% > (6) Évitez les emails, sauf s’il s’agit de communication officielle. L’information va se perdre en chemin et il faudra plus de temps pour tout clarifier.%%% > %%% > __Rappelez-vous d’utiliser ces méthodes de communication en parallèle, et non une à la fois.__%%%

TDD ne concerne pas que le test !!!

((/dotclear/public/programmation.gif|Programmation|L|Programmation, aoû 2009))J’ai traduit un billet intéressant de Alberto Gutierrez : ++[« TDD is not about testing!!! »|http://www.makinggoodsoftware.com/2009/11/21/tdd-is-not-about-testing/|en]++.%%% %%% > Beaucoup de gens confondent « les méthodologies de tests au plus tôt » avec le TDD. Il est très fréquent d’entendre des commentaires du genre « TDD c’est juste l’écriture de vos tests en premier », ce qui est complètement faux. Ce type d’affirmation ne décrit pas du tout le TDD mais parle en fait du développement des tests en premier.%%% > %%% > La principale raison de cette confusion entre TDD et le développement des tests en premier vient de son propre nom : « Test-Driven Development ». Si quelqu’un, qui ne sait pas ce qu’est TDD, doit deviner ce qu’est TDD à partir de son nom, il devinera probablement que c’est juste une méthodologie de tests au plus tôt. Mais ce n’est pas le cas !%%% > %%% > TDD, inventé par Kent Beck (qui a aussi inventé l’eXtreme Programming et Junit), va au-delà. Au cœur de TDD, il y a un processus à suivre, ce qui le rend déjà différent d’une simple approche de test en premier.%%% > %%% > ((/dotclear/public/traductions/Test-driven_development.PNG|TDD||TDD))%%% > Source : ++[Wikipédia|http://en.wikipedia.org/wiki/Test-driven_development|en]++%%% > %%% > Ce processus est également connu sous le forme rouge (faire échouer votre test), vert (faire réussir votre test) et remaniement. On pourrait considérer cela comme une petite différence avec une approche test en premier, mais combiné avec certaines pratiques d’ingénierie agile et autres philosophies de développement, TDD devient très différent de toute approche test en premier et met en réalité l’accent sur la conception.%%% > %%% > TDD est une pratique de conception et est plus lié à la conception qu’aux tests. TDD –est inutile– –  »texte revu par l’auteur suite aux commentaires sur son post d’origine » – perd beaucoup de son potentiel s’il n’est pas combiné avec d’autres pratiques d’ingénierie agile, comme la programmation en binôme, ou des philosophies agiles comme YAGNI et ++[KISS|/dotclear/index.php?post/2009/11/03/Les-7-caracteristiques-d-un-code-simple-KISS|fr]++. En TDD, avoir un grand nombre de tests est un effet secondaire sympa, et non uniquement son objectif.%%% > %%% > Pour savoir si vous faites correctement du TDD, regardez votre code, du code TDD doit paraître simple et lean, TDD génère généralement plus de code pour tester que de code pour produire, et vous devriez sentir que cela vous aide à concevoir votre code.%%% > %%% > Donc, la prochaine fois que vous dites que vous faites du TDD, assurez-vous que vous ne voulez pas plutôt dire que vous faites du développement de tests en premier.%%%

Ocapi

Je travaille actuellement sur un projet nommé O.C.A.P.I. Je vous passe la signification de l’acronyme et pourquoi cette bestiole plutôt qu’une autre. J’en profite simplement pour vous présenter le T-shirt que j’ai conçu sur le site ++[Zazzle|http://www.zazzle.co.uk/|en]++ (par qui j’étais déjà passé pour faire mon mug ++[« How Scrum Are You?|/dotclear/index.php?post/2009/09/09/Mug-How-Scrum-Are-You|fr »]++) :%%% %%% Devant :%%% [((/dotclear/public/./.ocapi_front_m.jpg|T-shirt Ocapi front||T-shirt Ocapi front))|/dotclear/public/ocapi_front.png]%%% La superbe image d’Okapi revient à Lokomotivo sur son site ++[all texture|http://alltexture.blogspot.com/2009/04/obviously-i-wasnt-quite-done.html|en]++ . Special thanks to håkan qui m’a autorisé à utiliser son travail ! %%% %%% Derrière :%%% [((/dotclear/public/./.ocapi_back_m.jpg|T-shirt Ocapi back||T-shirt Ocapi back))|/dotclear/public/ocapi_back.png] %%% Je peux vous dire que ça a fait sensation chez le client…%%%

Vos tests unitaires sont-ils FIRE ?

((/dotclear/public/logos/logo_bigvisible.png|BigVisible – See Everything|L|BigVisible – See Everything))Très bon billet de ++[Adam Sroka|http://www.linkedin.com/in/adamatxagiledotcom|en]++ : ++[« Are your unit tests on FIRE? »|http://www.bigvisible.com/asroka/are-your-unit-tests-on-fire/|en]++%%% %%% > De bons tests unitaires sont :%%% > %%% > __F__ast / __R__apides : ils passent en moins de quelques millisecondes sur la plupart des machines.%%% > %%% > __I__solated / __I__solés : ils suppriment toutes les dépendances en utilisant des bouchons qui vérifient la façon dont les dépendances sont appelées et retournent des résultats bidons.%%% > %%% > __R__epeatable / __R__épétables : ils n’ont pas de dépendance avec un état externe et peuvent être exécutés encore et encore avec les mêmes résultats (à moins que le code change).%%% > %%% > __E__xamples / __E__xemples : ils démontrent la façon dont le code est destiné à être utilisé et autorise donc la Programmation Par Intention (si vous les écrivez d’abord).%%% > %%% > Note: avec tout le respect dû à l’auteur de ++[FIRST|http://www.makinggoodsoftware.com/2009/08/25/how-to-write-a-good-test-case5-tips-to-write-better-test-cases/|en]++, mais je préfère ma version.%%% L’acronyme anglais F.I.R.E s’est transformé en… R.I.R.E 🙂

Scrum par Claude Aubry – la couverture !

Claude Aubry a récemment publié sur son blog une présentation des ++[Publications sur les bénéfices du développement agile|http://www.aubryconseil.com/post/Les-b%C3%A9n%C3%A9fices-du-d%C3%A9veloppement-agile|fr]++ basée sur :%%% * la traduction de la présentation ++[Reported-Benefits-of-Agile|http://www.succeedingwithagile.com/resources/reported-benefits-of-agile|en]++ de Mike Cohn suite à la sortie de son dernier livre ++[Succeeding with Agile: Software Development Using Scrum|http://www.amazon.fr/exec/obidos/ASIN/0321579364/mountaingoats-20|en]++, * l’++[Enquête Nationale Méthodes Agiles|http://www.frenchsug.org/pages/viewpage.action?pageId=591296|fr]++ menée par le Scrum User Group France. %%% A la page 3 de cette présentation on trouve… la couverture (définitive ?) du livre ++[« Scrum – Le guide pratique de la méthode agile la plus populaire »|http://www.aubryconseil.com/post/Scrum%2C-le-livre-%3A-le-plan|fr]++ écrit par Claude Aubry et qui devrait bientôt sortir… mais quand ?%%% %%% J’effectue une rapide recherche sur le site de l’éditeur ++[Dunod|http://www.dunod.com/pages/onglet/aparaitre.asp?th=2|fr]++ qui n’affiche pour l’instant aucun résultat dans la catégorie Informatique des livres « A paraître ». Finalement j’ai plus de chance avec le site de la ++[Fnac|http://livre.fnac.com/a2773559/Claude-Aubry-Scrum-le-guide-pratique-de-la-methode-agile-la-plus-populaire?Mn=-1&Ra=-1&To=0&Nu=8&Fr=3|fr]++ qui annonce __Février 2010__. Mince, je ne l’aurai pas pour Noël !%%% %%% Je vous restitue ici la fameuse couverture :%%% [((/dotclear/public/test/.claude-aubry-livre-scrum_s.jpg|Claude Aubry : couverture du livre Scrum à paraître||Claude Aubry : couverture du livre Scrum à paraître))|/dotclear/public/test/claude-aubry-livre-scrum.png]%%% ainsi que les 2 propositions que j’avais faites à Claude (ben ouai si je peux aider…) :%%% [((/dotclear/public/test/.maquette-livre-scrum_s.jpg|1ère proposition de maquette pour le livre Scrum de Claude Aubry||1ère proposition de maquette pour le livre Scrum de Claude Aubry))|/dotclear/public/test/maquette-livre-scrum.JPG] [((/dotclear/public/test/.maquette2-livre-scrum_s.jpg|2ème proposition de maquette pour le livre Scrum de Claude Aubry||2ème proposition de maquette pour le livre Scrum de Claude Aubry))|/dotclear/public/test/maquette2-livre-scrum.JPG]%%% %%% Finalement, le parallèle avec le terrain de rugby est évident ! la solution la plus simple est toujours la meilleure, comme dirait l’++[autre|http://fr.wikipedia.org/wiki/Rasoir_d%27Ockham|fr]++ 🙂 %%% %%% Cité par Claude sur son blog : ++[« Les couvertures auxquelles vous avez échappé »|http://www.aubryconseil.com/post/Les-couvertures-auxquelles-vous-avez-%C3%A9chapp%C3%A9|fr]++%%%

Kaizen : The Wet Blanket List

[((/dotclear/public/./.Kaizen_graphic_t.jpg|Kanji Kaizen|L|Kanji Kaizen))|/dotclear/public/Kaizen_graphic.gif]La vie au sein d’une organisation n’est pas si facile que ça. Lorsque vous proposez une idée d’amélioration, votre chef peut vous poser une question idiote du genre : « si ça fonctionne, pourquoi devrions-nous changer quelque chose » ou bien « cette procédure me va très bien, pourquoi devrions-nous en changer ? ». Dans votre for intérieur, vous savez que si vous changez effectivement quelque chose, votre chef vous le reprochera. Votre chef ne veut tout simplement pas vous laisser essayer, avec ou sans raison valable. Vous êtes bloqué, « le chef a toujours raison » comme dit le proverbe. Il y a tant de chefs qui sont comme ça. Le livre ++[« KAIZEN, the Key to Japan’s Competitive Success »|http://www.amazon.fr/Kaizen-Key-Japans-Competitive-Success/dp/007554332X|fr]++, édité en 1986, du japonais __Masaaki Imai__ (connu comme le « Lean Guru ») parle d’une liste baptisée __ »The Wet Blanket List »__ (~La Liste des Rabat-Joies). Les chefs devraient encourager leurs subalternes, mais dans la vie réelle, les rabat-joies « anesthésient » les suggestions d’amélioration : ///html

The Wet Blanket List La Liste des Rabat-Joies
I am too busy to study it Je n’ai pas le temps
It’s a good idea, but the timing is premature C’est une bonne idée, mais elle va faire peur à tout le monde
It is not in the budget Ce n’est pas prévu au budget
Theory is different from practice C’est de la théorie, le résultat sera décevant
Isn’t there something else for you to do ? Et si vous faisiez votre travail, au lieu de vous occuper de ça ?
I think it doesn’t match corporate policy Je pense que ça va à l’encontre de la politique du groupe
It isn’t our business; let someone else think about it Ce n’est pas notre affaire, laissons quelqu’un d’autre s’en occuper
Are you dissatisfied with your work ? Votre travail ne vous plaît plus ?
It’s not improvement, it’s common sense Ce n’est pas de l’amélioration, c’est du simple bon sens
I know the result, even if we don’t do it Je vois d’ici le résultat, ce n’est même pas la peine d’essayer
I will not be held accountable for it Ce n’est pas moi qui porterai le chapeau pour ça
Can’t you think of a better idea ? Vous ne pourriez pas proposer une meilleure idée ?

/// Toute ressemblance avec des chefs ou des situations existantes ou ayant existé ne saurait être que fortuite… 🙂 %%% %%% Pourtant, c’est ce qui se passe réellement dans la vie d’une organisation. Les chefs découragent les subalternes et les subalternes deviennent sceptiques. Ils arrêtent de faire des propositions, des suggestions et des améliorations et l’organisation stagne peu à peu. Parfois, les chefs sont conscients de cet immobilisme et achètent « une nouvelle machine », changent le dispositif ou même louent les services d’un groupe de consultants pour opérer un changement majeur. Ils le font parce que c’est dans leur fonction d’opérer des changements majeurs. Ils changent tout et bouleversent l’organisation. Cependant, eux ne changent pas et continuent à critiquer leurs subalternes, en leur jetant des expressions rabat-joies. C’est le point le plus important : le changement et l’amélioration doivent partir du top management. Le top management doit modifier son propre comportement lorsqu’il traite avec ses subalternes.%%% %%% ++L’engagement du top management est donc la priorité numéro un. Sans un tel changement, vous ne pouvez pas démarrer la démarche KAIZEN dans une organisation.++%%% %%% Sources :%%% * ++[Revision Guru|http://www.revisionguru.co.uk/business/kaizen.htm|en]++ * ++[Hubert Bazin|http://pagespro-orange.fr/hubert.bazin/kaizen.html|fr]++ %%% Et pour finir, je vous invite à lire ce billet de Bertrand Duperrin (consultant chez ++[BlueKiwi Software|http://www.bluekiwi-software.com/|en]++ : ++[« Je suis un goulot mais je me soigne »|http://www.duperrin.com/2009/05/09/je-suis-un-goulot-mais-je-me-soigne/#more-2188|fr]++.%%%

Lean Kit Kanban

((/dotclear/public/logos/logo_LeanKitkanban.png|Lean Kit Kanban|L|Lean Kit Kanban))Hier, j’ai installé un ++[plugin Twitter pour Dotclear 2|http://plugins.dotaddict.org/dc2/details/twitter|fr]++. J’ai positionné le widget dans la colonne de droite de mon blog et je l’ai testé avec le compte twitter de ++[Henrik Kniberg|http://twitter.com/henrikkniberg|en]++ (un de mes héros agiles). Ça marche plutôt bien.%%% %%% Au cours de la journée, j’ai suivi d’un œil distrait l’évolution des tweets de Henrik… et tout d’un coup j’en vois passer un qui s’intitule ++[« Lean Kit Kanban looks very promising at first glance (digital Kanban board). »|http://twitter.com/henrikkniberg/status/5850892906|en]++. J’enregistre le lien cité ++[Lean Kit Kanban|http://www.leankitkanban.com|en]++ et je le met sous le coude pour tranquillement zoomer dessus en fin de soirée.%%% %%% Il s’agit d’une version Beta de la LeanKit Kanban « Team Edition », développée et mise à disposition par la société ++[Bandit Software, LLC|http://www.linkedin.com/companies/bandit-software-llc|en]++. Elle permet aux impatients de tester gratuitement (voir le modèle de ++[Pricing|http://www.leankitkanban.com/Account/Registrations/Pricing|en]++) l’élaboration d’un Board Kanban pour 5 utilisateurs. C’est déjà très bien !%%% %%% Le site propose de créer son espace sur l’adresse suivante :%%% ((/dotclear/public/screenshots/screenshot_SiteAdressLeanKitKanban.png|Site Adress LeanKit Kanban||Site Adress LeanKit Kanban))%%% %%% Ni une ni deux, je crée l’adresse ++[http://faimetti.leankittools.com|http://faimetti.leankittools.com|en]++ et je reçois une notification par mail pour activer mon compte.%%% [((/dotclear/public/screenshots/.screenshot_WelcomeLeanKitKanban_m.jpg|Welcome LeanKit Kanban||Welcome LeanKit Kanban))|/dotclear/public/screenshots/screenshot_WelcomeLeanKitKanban.png]%%% %%% Je décide spontanément de ++__faire un test__++ sur la base du Backlog du ++[Scrum User Group de Bordeaux|http://groups.google.fr/group/sug-bordeaux/web/liens-utiles?hl=fr|fr]++ dont le correspondant local du French Scrum User Group est ++[Philippe Launay|http://www.meetup.com/frenchsug/members/9069731/|fr]++ :%%% ((/dotclear/public/screenshots/screenshot_KanbanBoards.png|Board LeanKit Kanban||Board LeanKit Kanban))%%% %%% L’interface est intuitive. Cinq minutes après, j’obtiens le board suivant :%%% ((/dotclear/public/screenshots/screenshot_LeanKitKanban.png|Board LeanKit Kanban||Board LeanKit Kanban))%%% %%% C’est pas génial ? En plus ça gère automatiquement le ++[gravatar|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2009/08/21/Plugin-Gravatar|fr]++ de l’utilisateur, la classe… Du coup, vous voyez que j’ai créé et habilité un autre utilisateur. Par ailleurs, des icônes permettent de visualiser la priorité ‘High’ et ‘Critical’ d’une card Kanban :%%% ((/dotclear/public/screenshots/screenshot_CardLeanKitKanban.png|Card LeanKit Kanban||Card LeanKit Kanban))%%% %%% En prime, il est possible de sortir quelques graphiques selon différents axes (Lane, Type, User, Priority).%%% [((/dotclear/public/screenshots/.screenshot_CardDistributionByLane_m.jpg|Card Distribution LeanKit Kanban||Card Distribution LeanKit Kanban))|/dotclear/public/screenshots/screenshot_CardDistributionByLane.png]%%% %%% J’ai également vu la possibilité d’import et d’export de fichiers.%%% %%% Sur la droite de votre écran, un lien feedback permet de proposer des ++[idées d’évolution|http://leankittools.uservoice.com/pages/17754-general|en]++ pour alimenter la roadmap du produit.%%% %%% Une doc. en ligne est disponible sur le ++[LeanKit Kanban Wiki|http://wiki.leankitkanban.com/|en]++.%%% %%% A suivre… Merci Henrik !%%%

C’est le temps passé dans le goulet d’étranglement qui compte

[((/dotclear/public/traductions/.kanban_t.jpg|Kanban|L|Kanban))|/dotclear/public/traductions/kanban.gif]Goulet ou Goulot d’étranglement ? Je vois les deux termes utilisés. Qu’en est-il exactement ?%%% %%% Un goulet d’étranglement est, généralement dans un processus physique, un point étroit qui provoque un engorgement. L’expression fait référence à « goulet », terme de marine qui désigne un passage étroit à l’entrée d’une rade. Elle est souvent transformée en « goulot d’étranglement » par référence au goulot resserré d’une bouteille.%%% %%%  »Lu sur ++[Techno-Science.net|http://www.techno-science.net/?onglet=glossaire&definition=9977|fr]++ »%%% %%% A propos de goulot d’étranglement, j’ai justement traduit ce billet de David Peterson sur KanbanBlog : ++[« Time at the bottleneck is what counts »|http://www.kanbanblog.com/article/time-at-bottleneck.html|en]++.%%% > A votre avis, lequel de ces choix fonctionnels devrions-nous faire ?%%% ///html

Fonctionnalité Valeur
estimée
Temps de
production estimé
A 100 000 € 40 hrs
B 80 000 € 40 hrs
C 60 000 € 40 hrs

/// > La fonctionnalité A ? C’est une évidence, non ?%%% > %%% > Pas nécessairement. La ++[Théorie des Contraintes|http://en.wikipedia.org/wiki/Theory_of_Constraints|en]++ nous dit que le débit global de notre pipeline de production est limité par le débit du goulot d’étranglement. Cela signifie que si nous voulons produire autant de valeur que possible grâce à notre pipeline de production, alors il faut produire autant de valeur que possible à travers le goulot d’étranglement. Donc ce qui est important n’est pas le temps total, mais le temps que chacune des fonctionnalités prend  »dans le goulot d’étranglement ».%%% ///html

Fonctionnalité Valeur
estimée
Dans le
goulot
A la sortie
du goulot
Temps de
production total
A 100 000 € 20 hrs 20 hrs 40 hrs
B 80 000 € 10 hrs 30 hrs 40 hrs
C 60 000 € 10 hrs 30 hrs 40 hrs

/// > Dans ce cas, pour les mêmes 20 heures passées dans le goulet d’étranglement, nous pouvons produire à la fois B et C pour un total de 140 000 €, comparativement à A avec 100 000 €.%%% > %%% > Si vous n’êtes pas convaincu, imaginez le scénario suivant : vous disposez de 100 analystes, 100 développeurs et 1 testeur. Tout le travail doit être testé par le testeur. Le testeur est le goulot d’étranglement et tout le monde passe le plus clair de son temps à se tourner les pouces assis autour du testeur. Il est évident que nous voulons faire tout notre possible pour transférer une partie de la charge de travail du testeur vers d’autres personnes. C’est effectivement le rôle que jouent les fonctionnalités B et C par rapport à A, puisqu’elles exigent moins de temps de la part du testeur.

Rencontres Mondiales du Logiciel Libre en 2010

((/dotclear/public/logos/rmll.jpg|RMLL|L|RMLL))10 ans après la première édition, les ++[Rencontres Mondiales du Logiciel Libre|http://2010.rmll.info/|fr]++ se dérouleront à nouveau __dans l’agglomération bordelaise du 6 au 11 juillet 2010__. Les RMLL sont l’occasion pour tous les publics de se rencontrer autour des logiciels libres. Pendant 5 jours, des conférences et des ateliers sont ouverts à tous.%%% %%% L’objectif des RMLL est d’offrir un lieu de rencontre unique, localisé dans l’espace et dans le temps, au plus grand nombre de participants possible, qui permette la mise en commun des informations et la fédération des énergies autour de projets de logiciels libres de grande envergure. Elles sont ouvertes à toute personne désirant contribuer à l’essor du logiciel libre : chefs de projets, développeurs, traducteurs, utilisateurs avertis, etc. Cette manifestation n’est pas un salon commercial : son entrée en est libre et gratuite.%%% %%% Hier soir, j’ai participé à la ++[réunion mensuelle d’organisation|http://abul.org/Reunion-RMLL-de-novembre.html|fr]++ qui se tenait à 20h30 dans les locaux de l’ENSEIRB à Talence/Pessac. Cela m’a permis de rencontrer __l’équipe d’organisation qui accueille avec joie toutes les bonnes volontés pour mener ce projet à bien__. Le noyau dur est composée des membres fondateurs de l’Association Bordelaise des Utilisateurs de Logiciels Libres (++[ABUL|http://abul.org/Qu-est-ce-que-l-ABUL.html|fr]++).%%%