Où les systèmes de contrôle de version distribués pourraient-ils être actuellement dans le cycle de battage médiatique de Gartner? [fermé]

Edit : Compte tenu de la récente baisse des votes (+ 8 / -6 à ce stade), il m'est apparu clairement que le cycle de vie de Gartner est une métrique biaisée du point de vue d'un programmeur. C'est quelque chose qui fait partie d'un document que je vais présenter à la direction , et les types de gestion font partie du public de Gartner.

Donner une exposition et un enthousiasme aux DVCS (qui "pourraient" être considérés comme du battage médiatique, ou du moins attaqués en tant que tels ), pensez à la question suivante lors de la lecture de celle-ci: "comment pourrais-je utiliser le cycle de battage médiatique de Gartner pour convaincre la direction que les DVCS sont prêts (ou assez prêt) pour nous, et qu'il ne s'agit pas seulement de battage médiatique "

Demander simplement si les DVCS est un battage publicitaire ne serait pas constructif, le cycle de battage médiatique de Gartner est un instrument plus objectif que de simplement le demander (même si cet instrument est considéré comme biaisé). Si vous connaissez un autre instrument, merci de le mentionner.

Edit # 2 : Je conviens que le cycle de vie de Gartner n'est pas pour toutes les technologies, mais je considère qu'il a peut-être généré suffisamment de buzz pour être considéré comme un battage médiatique par certains, donc il mérite peut-être au moins d'être évalué / réfléchi en tant que tel en utilisant cet instrument dans afin de prouver / réfuter à quelque degré que ce soit. Je suis un défenseur de DVCS, BTW.

Edit # 3 : Merci pour vos réponses. Bounty va à Caleb pour avoir répondu à ma question avec des détails et des conseils pratiques. La réponse acceptée va à philosodad pour avoir fourni un autre instrument utile et avoir répondu au-delà de ma question.

Je fais des recherches pour un livre blanc que j'écris en faveur de l'adoption du DVCS dans l'entreprise et je suis tombé sur le concept de la preuve sociale . Je veux prouver que la preuve sociale de l' adoption DVCS est pas nécessairement culte du cargo et de faire des recherches plus poussées maintenant je suis tombé sur Gartner cycle de battage médiatique qui décrit la maturité de la technologie en 5 phases.

Ma question est: quel pourrait être un indicateur de l'emplacement actuel des systèmes de contrôle de version distribués (je veux dire git, mercurial, bazaar, etc. en général) à une phase particulière du cycle de battage médiatique? ... dans d'autres (moins compliqués) En d'autres termes, diriez-vous que les attentes actuelles en matière de DVCS sont a) de commencer, b) gonflées, c) décroissantes (désillusion), d) croissantes (illumination) ou e) stabilisantes (matures) et (plus important) pourquoi ?

Je sais que c'est une question difficile et qu'il y a de la subjectivité, mais j'accorderai la réponse (et le cookie traditionnel) à l'argument / preuve le plus clair pour une phase particulière.

Le cycle de battage médiatique mesure la quantité de nouvelles / buzz qu'une chose particulière génère, pas l'utilisation réelle de la chose ou sa valeur de productivité réelle. Donc ... je dirais que de ce point de vue, DVCS atteint un pic dans son cycle d'actualités. Assez de gens l'utilisent et encouragent d'autres personnes à l'utiliser, cela fait beaucoup de bruit dans le monde de la technologie. Une fois l'adoption plus répandue, je m'attends à ce que les nouvelles / buzz s'atténuent un peu lorsque quelque chose de nouveau et de brillant arrive, puis remontent à mesure que les gens commencent à comprendre les systèmes plus complètement.

Une façon de regarder le cycle de battage médiatique est de regarder le nombre de nouveaux adoptants. Le nombre de nouveaux adoptants d'une technologie a tendance à suivre la même forme de courbe exacte que le cycle de battage médiatique. Il est logique que le buzz autour d'une nouvelle technologie donnée augmente rapidement à mesure que la technologie gagne un grand nombre de nouveaux adoptants. Les premiers adoptants diffusent l'innovation et les adoptants moyens génèrent le buzz.

Le buzz lors de l'adoption rapide d'une innovation est nécessairement mal informé. S'il y a beaucoup de gens qui connaissent quelque chose mais ne le savent pas, ils vont avoir des attentes différentes et peut-être plus grandes que les utilisateurs expérimentés. C'est de là que vient le battage médiatique.

Le buzz après le pic du taux d'adoption va tomber ... en partie parce que les attentes antérieures et irréalistes n'ont pas porté leurs fruits (le DVCS vous rendra peut-être plus productif, mais il ne réglera pas tous vos problèmes) et en partie parce que quelque chose d'autre traverse une période d'adoption rapide et prend toute la conscience. Le battage médiatique est inconstant.

Mais à un moment donné, vous commencez à obtenir un taux assez constant de nouveaux adoptants, l'innovation est devenue la norme et les nouveaux adoptants veulent savoir comment utiliser cette chose qu'ils ont déjà décidé d'utiliser. Ensuite, le buzz autour de l'innovation concerne tout ce que les gens font réellement avec elle maintenant qu'ils l'utilisent, plutôt que ce qu'ils pourraient en faire s'ils l'utilisaient.

Donc, si vous preniez la courbe de battage médiatique et la placez à côté de la courbe en S des taux d'adoption (voir Everett Rogers "Diffusion of Innovations"), vous vous attendriez à ce que le battage médiatique atteigne un sommet là où la courbe en S est la plus raide, en descendant lorsque la courbe en S change direction et remonter à mesure que l'innovation atteint sa pleine saturation du marché.

DVCS est dans une période d'adoption rapide, donc nous sommes probablement quelque part au sommet du cycle de battage médiatique.

Je ne prétends pas être un expert en matière de cycles de battage médiatique, mais je ferai quelques observations:

1. Le cycle de battage médiatique semble être davantage le produit des attentes et de la couverture médiatique qu'une caractéristique de la technologie elle-même. Mon dictionnaire dit que le battage médiatique est «une publicité ou une promotion extravagante ou intensive». Il définit la publicité comme "l'avis ou l'attention accordée à quelqu'un ou à quelque chose par les médias". Les médias sont un terme collectif pour les différents canaux de communication de masse.

2. Si vous acceptez le point précédent, il s'ensuit que le cycle de battage publicitaire s'applique uniquement lorsque le support couvre une technologie donnée.

3. Il n'est pas du tout clair que le cycle de battage publicitaire s'applique à toutes les technologies. Les revues scientifiques sont remplies de rapports d'avancées qui ne sont jamais remarquées par les médias grand public. Sans couverture médiatique, les attentes sont moins susceptibles d'être gonflées et le creux de la désillusion peut être évité.

4. Les systèmes de contrôle de version distribués ne sont pas tant une nouvelle idée qu'un raffinement d'une ancienne. Il est difficile de les appeler une «technologie émergente» du genre que le cycle de battage médiatique est censé prédire.

Avant de commencer à créer un cas pour lequel DVCS tient sur un graphique de cycle de battage médiatique, vous devez construire un cas où le contrôle de version distribué est soumis au cycle de battage médiatique du tout. Le contrôle de version distribué en tant que «technologie» bénéficie-t-il d'une couverture médiatique? Y a-t-il maintenant ou y a-t-il déjà eu des attentes exagérées pour le contrôle de version distribué? Est-il probable que les utilisateurs de DVCS deviennent déçus lorsque les produits DVCS ne répondent pas aux attentes?

Il me semble plus probable que le contrôle de version distribué n'est qu'une amélioration par rapport à une catégorie de produits existante, tout comme SVN était une amélioration par rapport à CVS. Si vous deviez représenter le taux d'adoption de SVN, je ne pense pas que vous obtiendrez un graphique qui ressemble au cycle de battage médiatique; au lieu de cela, vous obtiendrez un graphique qui augmente régulièrement jusqu'au plateau de domination du marché, suivi d'une longue et lente baisse à mesure que les systèmes distribués comme «git» gagnent en popularité.

Si vous avez vraiment besoin d'une réponse hype-cycle, je suggère que DVCS rejoigne le jeu au bas d'une période de désillusion / frustration avec les systèmes de contrôle de version non distribués et grimpe la pente de l'illumination à mesure que le taux d'adoption augmente.

Au lieu de compter sur le cycle de battage médiatique pour votre argument, je suggère de se concentrer sur le taux d'adoption du contrôle de version distribué et les raisons de celui-ci. Il existe de nombreuses preuves anecdotiques que les gens passent au DVCS parce que cela fonctionne; d'un autre côté, je n'ai entendu parler de personne revenant à un système non distribué car déçu. Pour obtenir des données fiables, vous pouvez essayer de parler à une société d'hébergement telle que Beanstalk . Faites également attention à l'interopérabilité entre les systèmes centralisés et les systèmes distribués. J'entends que «git» joue très bien avec SVN. Les systèmes centralisés continuent de fonctionner assez bien dans le domaine de l'entreprise, mettant ainsi l'accent sur le "joue bien avec"

Mise à jour en réponse à la modification d'OP:

comment pourrais-je utiliser le cycle de battage médiatique de Gartner pour convaincre la direction que les DVCS sont prêts (ou assez prêts) [?]

Je pense qu'il existe quelques approches qui pourraient aider ici, et toutes s'appuient sur des données solides:

Tendances Google. Google recueille évidemment une tonne de données sur ce qui est sur le net et ce que les gens recherchent. Il y a quelques jours, j'ai cherché (mais je n'ai pas pu trouver) de preuves du contrôle de la version distribuée par le cycle de battage médiatique. http://trends.google.com/ dit qu'il n'y a pas suffisamment de données pour les termes dvcs ou contrôle de version distribué lorsque je limite la région aux États-Unis (et les résultats dvcs pour le monde ne semblent pas très pertinents ou utiles). La recherche de termes plus spécifiques était un peu mieux, mais compliquée par le fait que les noms de produits comme git et mercurial ont d'autres significations (qui savait?). Le résultat pour git montre une tendance qui pourrait être due en partie au système de contrôle de version:

En essayant de rendre cela plus spécifique au contrôle de version, j'ai essayé le dépôt git :

Un autre ... en supposant que si les gens adoptent git, il devrait y avoir une tendance croissante à rechercher de l'aide avec les commandes git, j'ai essayé git pull (bleu), git commit (rouge) et git rebase (or):

Ce dernier graphique semble fournir la meilleure preuve que les gens adoptent et utilisent git.

Recherche Google.

Essayez simplement de rechercher des termes comme contrôle de version distribué et notez les dates, disons, les 25 meilleurs articles que vous trouvez. Tracez les résultats. La plupart des grands succès que j'ai trouvés avaient des dates dans la gamme 2007-2009. Si le cycle de battage publicitaire s'applique, et si vous pouvez montrer que la majeure partie de la couverture médiatique s'est produite il y a 3-5 ans, cela semble être une assez bonne preuve que nous avons dépassé le pic des attentes gonflées.

Collectez des exemples de projets qui utilisent DVCS.

Il existe de nombreux exemples dans le monde open source, y compris certains grands comme Linux. (Linus Torvalds a créé git pour aider à gérer le développement Linux.) Les exemples d'entreprises qui utilisent un DVCS vous seront plus utiles. (S'il y a quelque chose que les gestionnaires détestent plus que d'adopter une technologie trop tôt, c'est qu'il est en retard.) Le battage médiatique n'est que cela - le buzz sur une technologie ou un produit. Si vous pouvez trouver des preuves de l'adoption de DVCS par les entreprises, cela aidera peut-être mieux que tout le reste à argumenter «c'est juste beaucoup de battage médiatique».

Derniers conseils:

• Être spécifique. Votre entreprise n'adoptera pas une technologie entière - vous adopterez un produit spécifique. Certains produits seront toujours moins matures que d'autres. Choisissez deux ou trois produits DVCS bien connus et montrez comment chacun s'intègre dans votre processus de développement. Les gestionnaires préfèrent les idées concrètes aux promesses vagues, donc l'analyse de la technologie en termes spécifiques les rendra plus à l'aise.

• Ce n'est pas du tout ou rien. Tout projet réel utilisant un DVCS aura toujours un référentiel central, donc les craintes de perdre le contrôle des joyaux de la couronne peuvent être facilement dissipées.

• Pas besoin de renoncer à votre système actuel. Certains outils, comme git, peuvent bien fonctionner avec les systèmes de contrôle de version existants, comme svn. Ainsi, vous pouvez facilement ajouter DVCS à votre processus de développement sans rien abandonner.

• Commencer petit. À moins que vous soyez dans une petite entreprise qui n'a qu'un seul projet, il devrait être facile d'incorporer DVCS dans le processus pour un ou deux de vos projets seulement. Vous n'avez pas à sauter la tête la première - plongez simplement un orteil.

En bref, identifiez les points de résistance et abordez-les aussi clairement que possible.

argument / preuve d'une phase particulière

Quelle que soit la phase, il doit s'agir d'une phase qui corresponde au fait que la technologie est utilisée de manière professionnelle depuis "plus de 10 ans" , puisque VCS TeamWare distribué existe depuis plus que cela: le guide de l'utilisateur pdf mentionné ci-dessous est daté de juillet 2001 .

Selon Wikipedia, le plus grand déploiement de TeamWare était à l'intérieur de Sun lui-même, où (à quelques exceptions près) à un moment donné, c'était le seul VCS utilisé - ce qui fait que des milliers de développeurs utilisent l'outil. TeamWare a été utilisé pour gérer les plus grandes arborescences sources de Sun, y compris celles du système d'exploitation Solaris et du système Java .

L'article de Wikipédia fait référence à un message Usenix d'Evan Adams, qui était le responsable architectural de TeamWare, qui déclare notamment:

Au printemps 1991, nous avons décidé de mettre en œuvre le projet TeamWare ...

TeamWare est un ensemble d'outils de ligne de commande et d'interface graphique créés à partir de plusieurs bibliothèques communes. Les bibliothèques sont fournies par le groupe TeamWare pour être utilisées par les applications TeamWare; ils ne sont pas prévus pour un usage plus général.

TeamWare est un produit de gestion de code qui encourage le développement parallèle et est construit au-dessus de SCCS. Un utilisateur fait une copie (transfert) d'une hiérarchie SCCS créant ainsi une hiérarchie personnelle. Dans cette hiérarchie, l'utilisateur effectue et teste les modifications. Ces modifications sont ensuite intégrées (putback) dans la hiérarchie d'origine. Si la hiérarchie d'intégration contient des modifications qui ne se trouvent pas dans la hiérarchie de l'utilisateur, TeamWare détecte qu'il y a eu des modifications parallèles et refuse l'intégration. Par conséquent, les utilisateurs doivent incorporer les modifications de la hiérarchie d'intégration dans leur propre hiérarchie avant l'intégration. TeamWare comprend également l'utilitaire filemerge, un programme graphique de différences à trois permettant aux utilisateurs de fusionner des modifications parallèles. TeamWare suit à la fois les modifications du fichier source (deltas SCCS) et les renommages de fichiers ...

Si vous êtes intéressé, trouvez plus de détails ici:

• "Le vieil homme et le C" d'Evan Adams
• "Guide de l'utilisateur de Sun WorkShop TeamWare" sur le site Oracle / Sun - pdf ^{juillet 2001} , html

^{Si je me souviens bien, CVS / SVN centralisé avait à l'époque l'avantage de pouvoir fonctionner sur Windows et Linux, tandis que TeamWare (SCCS) était verrouillé dans le système de fichiers Solaris (sous Linux, il fonctionnait plus ou moins, si l'on savait comment pirater). bogues parasites "zéro somme de contrôle").}

Ma réponse:

Je pense que la réponse se situe quelque part entre "Internet TV" et "Cloud Computing" sur l'épaule montante du "Peak of Inflated Attentes" (même si je pense que ces deux éléments ont évolué assez rapidement au cours des deux dernières années).

Nature du cycle de battage médiatique:

Si je comprends bien, la progression dans le cycle de battage médiatique se caractérise par une prise de conscience croissante des avantages et des inconvénients d'une technologie particulière, plutôt que par une mesure objective de la «maturité» (quoi que cela signifie).

Avant d'avoir accumulé un ensemble d'expériences suffisamment diversifié pour construire des opinions équilibrées (et indépendantes ), la dynamique des foules (naturellement) règne, avec des opinions hautement corrélées avec peu de diversité, de subtilité ou de profondeur d'analyse.

Cela est aussi vrai dans le «creux de la désillusion» que dans le «pic des attentes gonflées»

Si la communauté devait produire un large éventail d'opinions différentes, avec une analyse approfondie sur où et quand il est approprié de déployer le DVCS et où et quand il ne l'est pas, alors nous pouvons déduire que nous sommes dans le "Plateau de la productivité" (Ou du moins dans une certaine mesure sur la "pente des Lumières").

Si, d'autre part, le discours est axé sur la supériorité (ou autrement) d'une technologie sans tenir compte des creux et des replis du paysage concurrentiel sur lequel elle se situe, alors nous pourrions en déduire que nous sommes soit sur le «pic de Attentes gonflées "ou" Auge de la désillusion ". Nous pourrions même être dans les deux phases en même temps, si la communauté est divisée en camps par une guerre des flammes.

:-)

Évaluation du DVCS selon ces critères:

D'après l'analyse relativement superficielle que j'ai vue dans le discours jusqu'à présent et l'absence relative de commentaire négatif, j'estimerais que nous gravissons actuellement le "pic des attentes gonflées", avec des questions (comme celle-ci) indiquant qu'il y a sont ceux qui préparent la pente de l'autre côté.

Je pense qu'un indicateur fort de la maturité de la technologie DVCS (du point de vue de l'entreprise) sera lorsque le débat passera de demander simplement "Pourquoi DVCS?" à "Comment pouvons-nous structurer au mieux notre flux de travail et nos processus autour du DVCS pour maximiser les avantages pour l'organisation?".

D'après ce que j'ai vu, nous n'y sommes pas encore tous. (Bien que certains de nos compatriotes les plus sophistiqués ouvrent la voie)

Le rôle du Hype Cycle dans la prise de décision:

Le modèle "Hype Cycle" est un modèle de biais comportemental, et il nous aide à comprendre notre propre état mental. Si nous pouvons déterminer qu'une technologie est mise en avant par d'autres, cela peut affecter notre propre position mentale et (au risque d'une double réflexion), nous pouvons avoir besoin de compenser en conséquence et de nous forcer à nous comporter rationnellement dans le choix de nos critères de sélection.

Les critères de sélection:

Il va sans dire que les choix des critères de sélection dépendent extrêmement du contexte.

Personnellement, je ferais (comme une sorte d'exercice de remue-méninges) une brève (15 minutes) analyse SWOT de chaque option que vous envisagez, avec (sérieusement) une analyse PEST de la situation pour vous assurer que vous apportez plus large (non technologique) facteurs dans votre analyse.

SWOT pour VCS distribué

Forces:

• Flexibilité - plus de liberté pour choisir différents workflows.
• Meilleures performances sur les connexions réseau à faible bande passante / à latence élevée - meilleures pour les équipes réparties et les travailleurs hors site.
• Fonctionnalité de fusion plus sophistiquée, vous permettant de vous connecter plus souvent. (Je ne suis pas sûr que ce soit une bonne chose).
• Le code source est "sauvegardé" sur chaque machine de développeur. (assez faux, celui-ci, car cela pourrait interférer avec la bonne planification de la reprise après sinistre)

Faiblesses:

• Flexibilité - Parce que nous avons plus de liberté pour choisir différents flux de travail, nous devons effectuer un travail supplémentaire pour définir le flux de travail que nous utilisons et pour l'appliquer.
• Complexité et difficulté conceptuelle (en particulier pour les membres de l'équipe non développeurs de logiciels).

Opportunités:

• Peut-être que la flexibilité peut être utilisée pour concevoir un flux de travail mieux adapté aux besoins de l'entreprise?

Des menaces:

• Peut-être que nous passerons tellement de temps à réorganiser notre flux de travail que nous perdrons notre concentration sur notre produit principal?
• Il peut être difficile d'amener certaines personnes à utiliser des outils même simples, surtout si elles ne croient pas qu'elles sont nécessaires ou ne sont pas motivées.

SWOT pour VCS centralisé

Forces:

• Fournit un canal de communication implicite intrabande pour l'organisation et les processus commerciaux.
• Limite les workflows possibles à un sous-ensemble (dans de nombreux cas raisonnable).
• Facilite la configuration de CI et d'autres outils d'automatisation du développement.
• (Spécifique SVN) Prend en charge d'énormes référentiels.
• (Spécifique SVN) Très stable, utilisé par de nombreuses grandes organisations conservatrices.
• Politiquement plus acceptable dans une organisation de commandement et de contrôle descendante?

Faiblesses:

• Inflexible.
• Mauvaises performances sur les connexions à faible bande passante / à latence élevée, ce qui rend son utilisation plus difficile pour les équipes distribuées et les travailleurs hors site (surtout si le référentiel devient volumineux)

Opportunités:

• Peut-être pouvons-nous utiliser la nature monolithique du référentiel pour aider les développeurs à naviguer dans le produit et à réutiliser le code les uns des autres?

Des menaces:

• Si le projet devient soudainement hyper important et que nous devons faire appel à des développeurs supplémentaires travaillant sur d'autres sites, peuvent-ils travailler efficacement avec un référentiel SVN hébergé (pour eux) hors site?
• Si l'ensemble des développeurs devient si grand que leur coordination devient difficile, le référentiel centralisé unique deviendra-t-il un goulot d'étranglement? (Pouvons-nous contourner cela d'une autre manière?)

Conclusion:

Le VCS à utiliser dépend des circonstances individuelles. Pour bon nombre des situations dans lesquelles j'ai travaillé, un DVCS avec un flux de travail centralisé aurait fait l'affaire, mais j'aurais dû justifier le temps et les efforts nécessaires pour créer un mécanisme pour soutenir et appliquer le flux de travail, ce qui aurait été (encore est difficile.

En fin de compte, je pense que la discussion devrait être centrée sur la question: quel flux de travail convient le mieux à notre entreprise? Le meilleur outil à utiliser devrait découler naturellement de la réponse à cette question.