Bonjour.

Je vous propose de nous retrouver pour une soirée des Praticiens XP le 3 Décembre (à partir de 18h30) dans les locaux d'OCTO Technology (au 5 eme étage).

Les objectifs de cette soirée sont de partager nos connaissances et nos expériences avec d'autres praticiens.

Le format utilisé pour cette soirée sera le format Open Space.

pour résumer : tout le monde peut proposer des sujets (il y aura 6 espaces donc 12 sessions) tout le monde participe aux discutions. et si une session ne vous intéresse plus momentanément ou définitivement, vous êtes invité à "voter avec vos pieds" et à aller rejoindre une autre session !

plus d'informations ici : http://www.openspaceworld.org/french/

Voici le programme de la soirée :

• 18h30 Accueil, présentation, choix des sujets.
• 19h15 1ère session
• 20h00 pause
• 20h10 2ème session
• 21h00 buffet

Les inscriptions se font sur le Wiki d'Xp France : http://xp-france.net/cgi-bin/wiki.pl?PraticiensDeParis/Mercredi03Decembre2008

« Encore une sale journée qui s’annonce » pensa Bertrand, de bon matin en sirotant son café. Bertrand est directeur de projet, il gère une équipe de développement d’un grand site internet stable et rentable. Mais ses développeurs croulent sous les demandes d’évolutions et de corrections d’anomalies provenant de différentes équipes : tentation du Web 2.0 du marketing, corrections de bugs pour la relation client, Urls à reformater pour le référencement Google, sans oublier ses satanés bugs qui proviennent en masse et de façon aléatoire. C’était trop ! Tout était urgent, développé à l’arraché, et mis en production aux forceps. « Comment améliorer ce bazar ? » se demanda Bertrand, tout en prenant un sachet de sucre.

Lire la suite

La tenue d'un backlog de user stories est un art dans lequel beaucoup d'équipes agiles excellent. Pourtant, dans beaucoup de ces équipes, la priorisation se basant sur ce backlog est perfectible, toujours dans une démarche d'amélioration continue à la poursuite de plus de valeur pour moins de délai/coût/effort.

Lire la suite

L'intégration continue (connue aussi sous le nom de "build continu") est l'une des pratiques agiles les plus populaires. C'est surement parce qu'il s'agit de l'une des plus simples à mettre en œuvre : on télécharge l'un des nombreux outils disponibles (Hudson, CruiseControl, Continuum, Bamboo....), on le fait pointer vers le référentiel de sources du projet (subversion, cvs ...), et c'est parti : tel un métronome il préviendra l'équipe toutes les 10 minutes si le code présent dans le référentiel de sources du projet ne compile pas ou ne passe pas les tests automatisés.

Mais suffit-il d'avoir un tel outil installé pour pouvoir prétendre faire de l'intégration continue ?
Je pense que non.

Lire la suite

Au secours ! Je n'arrive plus à suivre. Google veut une licence mobile, Microsoft devient opérateur de services, France Telecom et Belgacom soufflent les droits de diffusion du Foot aux chaînes de TV payantes, Apple fait du téléphone... Tous veulent proposer de nouveaux services pour attirer le client, générer de l’audience. Mais pour cela il faut des plates-formes performantes, innovantes, modernes, bourrées de logiciel…

Et moi, que puis-je faire avec mes plates-formes ? Comment faire évoluer une accumulation de 20 ou 30 ans de systèmes, technologies, protocoles ? Comment satisfaire les nouveaux besoins et anticiper la prochaine vague ?  Et en même temps je suis sensé comprendre l'IMS, le Web 2.0, les Mashups, eTOM, SIP, OSA Parlay, REST, SOAP, les SDP, les ESB, Google Talk, Android... Cela me donne mal à la tête rien que d'y penser. Pourtant, fondamentalement, mes préoccupations sont les mêmes qu'il y a quelques années, mais elles sont exacerbées : Time-To-Market, Qualité de service, Total Cost of Ownership.

Lire la suite

Dans un papier pas tout récent puisqu'il date de 2003, they don't care about quality, Kathy Iberle expose un sentiment communément (en tout cas déjà par moi) ressenti: "Ils se foutent de la qualité!", "Ils" étant bien entendu les autres...
Kathy illustre ce jugement à l'emporte-pièce en comparant une définition de la qualité dans un cadre médico-légal et une autre définition de la qualité chez un fabriquant de cartouche d'encre...Deux univers, deux définitions qui lui permettent de proposer quelques clés permettant de sortir de ce concours de mauvaise foi.
Alors qu'en est-il?

Lire la suite

Didier Girard et Bernard Notarianni organisent le 18 décembre 2007 les Rencontres Agiles 2007 à Paris La Defense.

Il s'agit d'une conférence cosponsorisée par OCTO, SFEIR et Xebia, dont le format est inspiré par les Rencontres GWT de juin dernier.

• Une salle de 200 places, inscription gratuite
• Une matinée complète, sans interruption
• Des sessions de 20 minutes pour aller rapidement à l’essentiel (no fluff, just stuff).
• Une sélection des meilleurs acteurs de l’Agile en France aujourd’hui.

Le programme se construit de manière incrémentale et comportera une dizaine de sessions couvrant des pratiques, des retours d’expérience et des démonstrations d’outils sur des projets en cours.
Si vous voulez en savoir le maximum sur l’agilité aujourd’hui en France en une matinée, inscrivez-vous dés maintenant sur le site de la conférence !

Tout projet de développement implique des choix d'architecture. Quels patterns de code ? Quels outils de build ? Un projet innovant  place ces question sur un axe temporel : les réponses adaptées ne sont pas les mêmes entre la 1ere itération et la 20ème itération. Une architecture "dynamique" permettra de maximiser la valeur apportée par une architecture applicative à un moment donné d’un projet.

Lire la suite

Perplexité chez les développeurs : les pratiques agiles (TDD, conception incrémentale, etc.) conduisent-elles, oui ou non, à "bien" programmer ? À trouver des solutions élégantes qui attireront le respect des pairs ?

Lire la suite

Il y a quelques temps déjà que nous croyons aux méthodologies de développement pilotées par les tests. J'en entends déjà pester "encore un truc de geek"...Le pilotage par les tests se résume à ces deux points clés:

• remplacer le cahier des charges, spécifications manuscrites riches, complexes et par expérience jamais complètes voire fausses du fait de l'ambiguïté du langage courant par des spécifications exécutables c'est à dire vérifiables concrètement et fournissant une réponse sans appel: "vert" ou "rouge".

• Piloter non pas sur un "reste à faire" - concept obscur car que met on dans le "reste à faire"? - mais sur du réalisé (ie. nombre de tests passants sur le nombre total de tests prévus) représentant de facto le pourcentage du logiciel réalisé et opérationnel.

Partant de ce principe, il est nécessaire d'avoir un outil permettant aux "fonctionnels" d'écrire simplement - c'est à dire dans leur vocabulaire - les spécifications exécutables et permettant aux "managers" de piloter les développements.

Lire la suite

Les besoins en terme de qualité de code amènent de plus en plus de projets à s'intéresser et à coder des Tests Unitaires. Et comme appréhender le logiciel en cours de production est complexe, des indicateurs dits "de couverture de tests" sont utilisés en complément.
Loin de moi l'idée de remettre en cause cet indicateur représentant le pourcentage de code métier exécuté par les tests. Il présente plusieurs intérêts:

• fournir une valeur quantitative représentant la part de logiciel testé
• fournir une visualisation (sous forme de rapport html maven ou autre) du code exécuté et surtout du code non exécuté. J'y vois là le double avantage :
• de mieux maitriser le risque. Le code non testé est connu.
• de permettre d'améliorer le test lui-même. En effet, du code peut ne pas être testé simplement parce qu'un cas un peu particulier a été omis et visualiser ces portions oubliées du code aide à affiner les tests. D'aucuns diront que si on fait du TDD ("Test Driven Development"), le code non testé est inutile et n'aurait donc pas du être écrit. Je peux les rejoindre dans cette approche extrême. Après, il y a la réalité des projets et du test aujourd'hui...

Reste que cet indicateur de "couverture de test" se contente de "voir" le code exécuté. That's all et ca n'est peut-être pas suffisant.

Lire la suite

Comme beaucoup d’autres, j’ai commencé à faire du pair programming sans le savoir, en dehors même d’un cadre de méthodes agiles. J’intervenais sur un projet de développement de librairie de calculs de risque financier et le langage était le C++. J’avais la chance d’avoir avec moi une collègue à la fois compétente et sachant réellement travailler en équipe. Je me souviens que nous avons mené à plusieurs reprises des séances en binôme devant le même écran pour résoudre les problèmes les plus difficiles.

Lire la suite