Sur son blog, David Brocard commente un phénomène observé dans des équipes agiles (Scrum par exemple) : une pression et un rythme insoutenable pèsent sur l'équipe. À mon sens, ceci est la conséquence d'un héritage des approches classiques, et d'un oubli de certains principes qui font l'Agilité. Voyons cela plus en détail.

Lire la suite

La valeur. Voilà un terme qui s’utilise souvent à outrance. Dans le secteur informatique, on est en perpétuelle recherche de valeur. L’objectif permanent est de la maximiser.

J’ai mis un certain temps à comprendre ce que l’on entendait par le mot 'valeur'. Je commence aujourd’hui à en cerner les contours. Et plus cette compréhension progresse, plus mon intérêt redouble.

L’une des premières prises de conscience est que la valeur est un concept qui s’utilise dans n’importe quel domaine, avec, souvent, le même sens caché. Marié depuis peu, j’ai pu en faire l’enrichissante expérience, à travers l’organisation de mon mariage. Alors qu’il ne nous restait plus qu’une semaine de préparation, nous nous sommes rendu compte que nous n’allions pas pouvoir finir tout ce que nous avions projeté de faire.

Lire la suite

Dans un précédent billet Industrialiser n'est pas automatiser, nous présentions les standards comme moteur de l'industrialisation, et base de l'amélioration continue. Voyons maintenant comment une équipe peut mettre en pratique ces principes.

Comment élabore-elle ses standards ? Comment les met-elle en application ?

Reprenons l'exemple de l'éditeur de logiciel de e-commerce, et de son équipe de développement. Pour rappel, l’équipe livre, toutes les 2 semaines, des fonctionnalités en mettant en œuvre Scrum.

Lire la suite

La lutte contre les facteurs de coût est éternelle. En matière de développement, elle consiste d’abord à réduire les temps de développement. Pour ce faire, on peut améliorer l’efficacité et la productivité du travail, ou bien encore, comme les temps de développement sont chiffrés à la journée, augmenter le temps de travail d’une journée, au risque d’aboutir à des charges irréalistes.

Une voie trop rarement empruntée consiste simplement à agir à la source, en évitant de demander des fonctionnalités, ou d’intégrer des exigences, dont on n’aura pas besoin. Une idée simple, et pourtant…

Lire la suite

Sur TV4IT, Eric K'Dual évoque la démarche lean et son application à l'informatique.

Que promet la démarche lean ?
Quels sont ses grands pilliers ?
Comment le lean contribue à l'amélioration continue ?
Comment cette méthode s'applique-t-elle à l'informatique et notamment à la production ?
Quels sont ses liens avec les méthodes agiles ?

Eclairage avec Eric K'Dual, responsable de l'activité architecture de Neoxia.

Lire la suite

Comme beaucoup, je pensais, il y a quelques mois encore, que l'industrialisation se résumait à une question d'automatisation. Au cours d'un échange passionné, on me fit remarquer qu'une procédure manuelle parfaitement réalisée pouvait être aussi efficace qu'un automate, et bien souvent moins coûteuse. Suite à cette discussion, je décidais de revoir mon approche, et de l'approfondir.

Lire la suite

Dans le dernier billet, un bug grave avait été découvert sur une des solutions de e-commerce. À la sortie du débriefing, David et Mathieu échangent à la machine à café.

Lire la suite

Ward Cunningham, le père du wiki, résume ainsi la notion de dette technique :

• Négliger la conception, c'est comme emprunter de l'argent.
• Refactorer, c'est comme rembourser la dette principale.
• Développer moins rapidement à cause de la complexité, c'est comme payer des intérêts.

Laisser s'accumuler la dette technique pour répondre rapidement à un besoin fonctionnel est une pratique assez courante dans le développement logiciel.

Malheureusement, la dette qui s'accumule épuise les ressources projets, et démotive les équipes. Lorsque la dette s'est effectivement accumulée, le travail d'un architecte est alors d'investir pour rembourser la dette principale (à plus ou moins long terme), et pour éviter que le système ne s'écroule sous la dette, et sous les intérêts.

Lire la suite

Aujourd'hui, je m'entretiens avec Marc, ingénieur qualité sur un projet d'application web de gestion piloté par Scrum.

Ingénieur qualité et Scrum ? S'agit-il d'une chimère ?

Dans les méthodologies classiques, le terme 'ingénieur qualité' a un sens bien précis. Les habitués de ces méthodologies ne reconnaitrons d'ailleurs peut-être pas l'ingénieur qualité qu'ils connaissaient. Quant aux utilisateurs de Scrum, ils pourront éventuellement être quelque peu choqués par ce terme.

Qu'en est-il donc ? Pour le savoir, donnons la parole à Marc.

Lire la suite

Lors du précédent billet, nous avions mis en œuvre la réduction des stocks de spécifications, de développements, et de tests.

Construire du logiciel de façon itérative nécessite cependant une phase importante d'apprentissage. Je vous propose donc de suivre cet apprentissage au travers d'une petite histoire.

Lire la suite

Dans l’épisode précédent, nous avions livré une première fonctionnalité après 245 jours. Et nous nous étions mis au défi de livrer cette même fonctionnalité bien plus rapidement.

Adoptons maintenant une démarche Lean, et regardons de plus près l'organisation de notre production de fonctionnalités.

Que constatons-nous au niveau de notre chaîne de production de logiciel ?

Les stocks en attente dans notre projet sont causés par le plus fondamental des gaspillages : la surproduction !

Lire la suite

Voici l'histoire d'un projet comme les autres qui livre une fonctionnalité somme toute simple après 245 jours de délai.

Pour savoir comment on en est arrivé là, commençons par le commencement.

Lire la suite

Les tests unitaires sont devenus (ou redevenus) des éléments essentiels du cycle de vie de construction d'une application. Mais, comment mesurer précisément si les tests unitaires couvrent bien tous les cas possibles dans une application ?

Lire la suite

Les méthodes agiles sont-elles faites pour moi ? Cette question, les consultants Neoxia se la voient poser de manière croissante chez nos clients.

Lire la suite