Digitalisation : une définition

Régulièrement, dans notre discipline, fleurissent des mots un peu « hypes » qui nécessitent de se poser quelques instants pour en cerner le sens et comprendre dans quel sens agir.

L’an dernier, nous avons ainsi eu droit à Big Data, en 50 nuances (OCTO a d’ailleurs été complice de cela, tant nous sommes persuadés de la puissance du concept.:)).

En cette période de collections printemps-été 2013, il semblerait que « digitalisation » soit bien parti pour devenir le buzz-word de l’année, en tout cas dans les grandes DSI : Gartner nous parle de digital marketing, nos clients notamment bancaires veulent un SI digital, le Cigref propose des publications « en format numérique » pour « promouvoir la culture numérique » au sein de « l’entreprise numérique », et jusqu’au Syntec qui est devenu numérique. Ah oui, précisons tout de même que « numérique » semble la meilleure traduction française de « digital ».

Et pourtant, difficile de trouver une définition de « digitalisation » qui fasse autorité. Du coup, nous vous proposons la nôtre :
(Lire la suite…)

Les feature teams chez Spotify

Il y a quelques temps, dans le cadre de notre série d’articles sur les patterns des géants du web, nous avions publié un article sur les Feature Teams.
http://blog.octo.com/feature-team/

Cette semaine, quelqu’un chez OCTO a partagé un lien particulièrement intéressant qui décrit de façon très précise la mise en oeuvre concrète de ce type de pratique chez Spotify.
Ca se trouve ici http://fr.scribd.com/doc/113617905/Scaling-Agile-Spotify : c’est clair, concret, concis.
Je ne peux que vous recommander cette lecture si vous avez envie d’approfondir le sujet !

Les Patterns des Grands du Web – Feature Team

Description

Dans l’article « Pizza Team », nous avons vu que les géants du Web prêtaient beaucoup d’attention à la taille de leurs équipes. Mais ce n’est pas le seul point de vigilance qu’ils ont sur leurs équipes : ils veillent aussi fréquemment à avoir des équipes organisées par fonctionnalité, autrement dit des « feature teams ».

La petite équipe polyvalente est la clé pour aller vite, et la plupart des géants du Web tentent de résister le plus longtemps possible à la multiplication d’équipes pour réaliser un seul produit.

(Lire la suite…)

Les Patterns des Grands du Web – Build vs Buy

Description

Un écart marquant entre la stratégie des Grands du Web et celle des DSI dans lesquelles nous intervenons porte sur le sujet du Build vs Buy.

Ce dilemme est vieux comme le monde de l’informatique : vaut-il mieux investir dans la fabrication d’un logiciel taillé au mieux pour ses besoins ou bien s’appuyer sur un progiciel et des outils pré-packagés qui embarquent la capitalisation et la R&D d’un éditeur (ou d’une communauté) qui a le temps de creuser les sujets technologiques et métier ?

La plupart des grandes DSI françaises ont tranché et ont inscrit la progicialisation maximale dans leurs principes directeurs, partant souvent du principe que l’informatique n’est pas une activité cœur de métier pour elles et qu’il vaut mieux la laisser à des acteurs spécialisés.

Les acteurs du web tendent à faire exactement l’inverse, avec une certaine logique puisque précisément l’informatique est leur cœur de métier et par conséquent trop stratégique pour être laissée à des tiers.

(Lire la suite…)

Les Patterns des Grands du Web – 2-Pizza Team

 Description

Quelle est la bonne taille d’équipe pour fabriquer un produit logiciel remarquable ?

La sociologie des organisations s’est penchée sur le sujet de la taille des équipes depuis plusieurs années déjà. Si la réponse n’est pas uniforme et semble dépendre de différents critères comme la nature des tâches à effectuer, le niveau moyen et la diversité de l’équipe, un consensus émerge sur des tailles de 5 à 12 [1][5].
En deçà de 5, l’équipe devient fragile aux événements extérieurs et manque de créativité. Au-delà de 12, la communication perd en efficacité, la cohésion diminue, on voit apparaître des comportements de parasitisme et des luttes de pouvoir, et la performance de l’équipe décroît très rapidement avec le nombre de membres.
(Lire la suite…)

Les Patterns des Grands du Web – L’obsession de la mesure

Description

En informatique, nous connaissons tous des citations qui rappellent l’importance de la mesure : « Ce qui ne se mesure pas, ne se pilote pas », « sans mesure, tout n’est qu’opinion ».

Les grands du web ont poussé cette logique à l’extrême et ont, pour la plupart, développé une culture poussée de la mesure.

(Lire la suite…)

Le ROI du TDD ?

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 ? »

  • Il comprend les apports / la diminution des risques ….
  • Il comprend également que ça va lui coûter : il y a des développements, à créer, maintenir, refactorer.
  • Intuitivement, il a l’impression que ça colle : apports >> coût initial
  • Il voudrait des chiffres, des nombres, une formule magique, lui permettant de vendre cette démarche autour de lui

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

(Lire la suite…)