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…)
Nous avons chez OCTO, des mailings très actives sur lesquelles les consultants posent des questions et débattent de sujets techniques, méthodologiques, fonctionnels,…
Je suis souvent soufflé par la qualité de ces débats.
Histoire de rendre un peu visible cet iceberg, j’ai prévu de prendre certains threads intéressants pour les restituer sur notre blog. Voici donc, pour démarrer, une version abrégée d’une discussion sur le ROI des approches de développement piloté par les tests. Merci à Misters F, C, G et S pour leurs contributions involontaires et tronquées…
Pour la Nième fois, un client me demande : « et le Test Driven Développement (TDD), ça va me coûter combien au final ? »
Est-ce qu’on a des éléments pour répondre précisément à cette question redondante ?
J’ai trouvé cette étude, couvrant les aspects ROI du TDD :
http://www.ipd.uka.de/~exp/xp/edser03.pdf
Vous en pensez quoi ?
Mister F
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.
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.
Dans tout projet, les tests occupent une place très particulière. Ils assurent le lien entre le monde des utilisateurs et le monde du développement. Nous avons vu dans un précédent article que la démarche de développement pilotée par les tests n’est pas incompatible avec les tests de recettes traditionnels. Un projet bénéfice peut tirer bénéfice de l’utilisation conjointe des deux approches. Il faut alors intégrer deux types d’outils. Nous allons voir aujourd’hui comment inclure les résultats de tests GreenPepper dans Test Director afin de présenter une vision homogène de l’ensemble des tests à notre client.
Dans un précédent post, j’avais déjà évoqué l’insuffisance de l’indicateur « couverture de test » à lui seul pour garantir la détection de régressions. Pour résumer, un autre indicateur permettant de répondre aux questions « mes tests me protègent-ils contre d’éventuelles régressions? » ou formuler autrement « Quel est le niveau de confiance que j’ai dans mes tests? » doit être trouvé.
Deux idées existent. La méthode plus simple consiste à compter le nombre d’assertions réalisées: efficace et simple à mettre en oeuvre puisque cette solution repose sur un simple grep (comme si grep était simple…).
L’autre méthode repose sur le principe suivant:
Le code de test « valide » le code métier. le code métier peut valider le code de test…
Alors concrètement comment faire?! comment l’implémenter? Comme j’avais envie de coder, voilà « l’histoire » d’un POC visant à valider les principes précédemment énoncés.
Dans tout projet, les tests occupent une place très particulière. Leur vocation première est de s’assurer que le logiciel répond au besoin. Ils assurent ainsi le lien entre le monde des utilisateurs et le monde du développement. Les tests se retrouvent de manière très formelle – quasi juridique – dans le process de validation (le « PV de recette »). Ce rôle de point d’orgue du projet (sa conclusion) occulte très souvent la place réelle des tests, on oublie qu’ils ont participé très en amont à l’élaboration du livrable : derrière un PV de recette dûment signé, combien de bugs ont dû être préalablement corrigés, combien de chapitres a-t-il fallu revoir dans les spécifications ? Ces ajustements n’ont pas été produits ex nihilo, ils sont le résultat de la constatation d’une anomalie, d’un test en fait. S’ils ne sont pas formalisés, on les retrouve indirectement dans les écrits du projet : soit sous forme de complément de spécifications, soit aussi sous forme de correction de bug.
Lorsque le test n’est plus formalisé » sous le manteau » mais fait l’objet d’une démarche systématisée, on parle de démarche pilotée par les tests.
Trop souvent cette démarche est opposée à l’approche classique, et ce de façon manichéenne. Nous allons voir au contraire que les deux démarches sont complémentaires et que les outils correspondants peuvent être facilement intégrés.
(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…)
La décision est prise, demain matin vous devez développer un logiciel pour votre entreprise. Un budget est disponible et un premier choix s’impose à vous : la méthode de travail….
Chronique à paraître dans 01 Informatique
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.
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 !
