Де в даний час можуть знаходитись системи диспетчеризації розповсюджених версій у циклі розкрутки Gartner? [зачинено]

Редагувати : Враховуючи недавнє скорочення (+ 8 / -6 в цей момент), мені стало зрозуміло, що життєвий цикл Гартнера є упередженою метрикою з точки зору програміста. Це те, що є частиною статті, яку я буду представляти керівництву , а типи управління - частина аудиторії Gartner.

Даючи експозицію та ентузіазм щодо DVCS (що "може" вважатися ажіотажним, або принаймні нападати як такий ), подумайте над наступним питанням, читаючи це: "як я міг використати цикл ажіотажу Гартнера, щоб переконати керівництво, що DVCS готові (або готовий) для нас, і що це не просто ажіотаж "

Якщо просто запитати, чи є DVCS, це не є конструктивним, цикл ажіотажу Гартнера є більш об'єктивним інструментом, ніж просто просити це (навіть якщо цей інструмент вважається упередженим). Якщо ви знаєте будь-який інший інструмент, будь-ласка, згадайте про це.

Редагувати №2 : Я погоджуюся, що життєвий цикл Гартнера не для кожної технології, але я вважаю, що це може призвести до достатньої кількості шумів, щоб дехто вважався ажіотажним, тому, можливо, заслуговує на те, щоб принаймні оцінити / поміркувати за допомогою цього інструменту в щоб довести / спростувати це в будь-якій мірі. Я прихильник DVCS, BTW.

Правка №3 : Дякую за відповіді. Баунті йде до Калеба, щоб відповісти на моє запитання детально та практично порадити. Прийнята відповідь надходить до Philosodad за надання ще одного корисного інструменту та відповіді поза моїм запитанням.

Я займаюся дослідженням допису, який пишу на користь прийняття DVCS у компанії, і я натрапив на концепцію соціального доказування . Я хочу довести, що соціальний доказ прийняття DVCS - це не обов'язково культ вантажу, і, роблячи подальше дослідження, я зараз натрапив на цикл ажіотажу Гартнера, який описує зрілість технології в 5 етапів.

Моє запитання: що може бути показником поточного розташування розподілених систем управління версіями (я маю на увазі git, mercurial, базар тощо) на певній фазі циклу hype? ... в інших (менш закручених) Слова, ви б сказали, що в даний час очікування DVCS: а) починаються, б) завищуються, в) зменшуються (розчаровуються), г) збільшуються (просвітлення) або д) стабілізуються (зрілі) і (що важливіше) чому ?

Я знаю, що це важке питання, і тут є суб'єктивність, але я надаю відповідь (і традиційне печиво) на найясніший аргумент / докази для певної фази.

Цикл ажіотажу вимірює кількість новин / шумів, які створює конкретна річ, а не фактичне використання речі або фактичне значення продуктивності. Отже ... я б сказав, що з цієї точки зору DVCS досягає високого рівня у своєму новинному циклі. Досить людей фактично його використовують і заохочує інших людей використовувати його, що в світі технологій стає дуже багато. Як тільки прийняття набуде більшого поширення, я очікую, що новини / кайф трохи затухнуть, коли з’явиться щось нове і блискуче, а потім знову піднімуться, коли люди почнуть більш повно розуміти системи.

Один із способів переглянути цикл ажіотажу - переглянути кількість нових усиновлювачів. Кількість нових прихильників технології, як правило, відповідає тій же точній формі кривої, що і цикл ажіотажу. Має сенс, що гудіння навколо даної нової технології буде швидко зростати, коли технологія набирає велику кількість нових користувачів. Ранні усиновлювачі поширюють інновації, а середні усиновлювачі генерують зусилля.

Про шум під час швидкого впровадження інновації неодмінно недостатньо відомо. Якщо є багато людей, які щось знають, але не знають про це, вони очікують інших і, можливо, більших очікувань, ніж досвідчені користувачі. Отож, звідки походить ажіотаж.

Після того, як швидкість прийняття досягла максимуму, випаде ... почасти тому, що раніше нереалістичні сподівання не окупилися (можливо, DVCS зробить вас більш продуктивними, але це не виправить усі ваші проблеми) і частково тому, що щось інше переживає швидкий період прийняття і займає всю розуму. Хайп - непостійний.

Але в якийсь момент ви починаєте отримувати досить постійну кількість нових усиновлювачів, нововведення стало нормою, і нові усиновлювачі хочуть знати, як користуватися цією річчю, яку вони вже вирішили використовувати. Тоді шум навколо інновації полягає в тому, що люди насправді роблять з цим зараз, коли вони його використовують, а не про те, що вони могли б зробити з ним, якби ним користувалися.

Тож якби ви взяли криву ажіотажу та поставили її поруч із S-кривою рівня прийняття (див. Еверетт Роджерс "Дифузія інновацій"), ви очікуєте, що ажіотаж досягне максимуму там, де S-крива найкрутіша, через зміну кривої S напрямок, і знову піднімаються, коли інновація досягає свого повного насичення ринком.

DVCS знаходиться в періоді швидкого прийняття, тому ми, мабуть, десь у пік циклу ажіотажу.

Я не претендую на те, що я є експертом з питань циклових показів, але запропоную кілька спостережень:

1. Цикл ажіотажу, здається, є скоріше продуктом очікувань та висвітлення у ЗМІ, ніж характеристикою самої технології. У моєму словнику сказано, що ажіотаж - це "екстравагантна або інтенсивна реклама або просування". Він визначає публічність як "повідомлення або увагу, яке комусь чи чомусь надають засоби масової інформації". ЗМІ - це збірний термін для різних каналів масової комунікації.

2. Якщо ви приймаєте попередній пункт, випливає, що цикл ажіотажу застосовується лише тоді, коли медіа висвітлює задану технологію.

3. Зовсім не зрозуміло, що цикл ажіотажу стосується всіх технологій. Наукові журнали наповнюються повідомленнями про досягнення, які ніколи не помічають у ЗМІ. Без висвітлення засобів масової інформації очікування рідше будуть завищені, а користь розчарування можна уникнути.

4. Розподілені системи управління версіями - це не стільки нова ідея, скільки вдосконалення старої. Це розтягнення, щоб назвати їх "новою технологією" такого роду, як передбачається цикл ажіотажу.

Перш ніж почати створювати випадок, коли DVCS вміщується на графіку циклу hype, вам потрібно побудувати випадок, коли розподілене управління версіями взагалі підлягає циклу hype. Чи отримує управління розподіленими версіями як "технологія" висвітлення медіа? Чи існують зараз чи були колись завищені очікування щодо контролю розподілених версій? Чи ймовірно, що користувачі DVCS розчаруються, коли продукти DVCS не виправдають очікувань?

Мені здається більш ймовірним, що контроль розподілених версій - це лише поліпшення існуючої категорії продуктів, подібно до того, як SVN був покращенням CVS. Якби ви склали графік прийняття SVN, я не думаю, що ви отримаєте сюжет, схожий на цикл ажіотажу; натомість ви отримаєте сюжет, який постійно збільшується до плато домінування на ринку з подальшим тривалим повільним зниженням, оскільки розповсюджені системи, такі як "git", набувають популярності.

Якщо вам справді потрібна відповідь на цикл ажіотажу, я б запропонував, щоб DVCS приєднався до гри в кінці періоду розчарування / розчарування з нерозподіленими системами управління версіями і піднімався на схил просвітлення в міру збільшення швидкості прийняття.

Замість того, щоб посилатися на цикл ажіотажу для вашого аргументу, я б запропонував зосередитись на частоті прийняття розподіленого контролю версій та причинах цього. Існує безліч анекдотичних доказів того, що люди переходять на DVCS, оскільки це працює; з іншого боку, я не чув , щоб хто - небудь перемикання задньої до нерозподіленого системі , тому що вони були розчаровані. Щоб отримати важкі дані, ви можете спробувати поговорити з хостинг-компанією, такою як Beanstalk . Також зверніть увагу на взаємодію між централізованими системами та розподіленими системами. Я чую, що "git" дуже добре грає зі SVN. Централізовані системи продовжують працювати досить добре в корпоративній царині, тому підкреслюючи "чудово грає з"

Оновлення у відповідь на редагування ОП:

як я міг використати цикл ажіотажу Gartner, щоб переконати управління, що DVCS готові (або готові) [?]

Я думаю, що тут є кілька підходів, які можуть допомогти, і всі покладаються на жорсткі дані:

Google Trends. Google, очевидно, збирає багато даних про те, що в мережі та що люди шукають. Кілька днів тому я шукав (але не міг знайти) доказів того, що цикл hype wrt розподіляв контроль над версіями. http://trends.google.com/ говорить, що недостатньо даних для термінів dvcs або керованого контролю версій, коли я обмежую регіон до США (а результати dvcs для світу не здаються дуже релевантними або корисними). Пошук більш конкретних термінів був дещо кращим, але ускладнений тим, що назви продуктів, як git та mercurial, мають інші значення (хто знав?). Результат для git показує тенденцію, яка частково може бути пов'язана із системою контролю версій:

Намагаючись зробити це більш конкретним для контролю версій, я спробував git сховище :

Ще одне ... розуміючи, що якщо люди приймають git, то повинно спостерігатися тенденція до пошуку допомоги з командами git, я спробував git pull (синій), git commit (червоний) та git rebase (золото):

Цей останній графік здається найкращим свідченням того, що люди приймають та використовують git.

Пошук Google.

Спробуйте просто пошукати такі терміни, як контроль розподіленої версії, і відзначте дати, скажімо, 25 найпопулярніших статей, які ви знайдете. Позначте результати. Більшість найпопулярніших хітів, які я знайшов, були в діапазоні 2007-2009 років. Якщо застосовується цикл ажіотажу, і якщо ви можете показати, що більша частина висвітлення в ЗМІ відбулася 3-5 років тому, це здається досить хорошим свідченням того, що ми вийшли за межі піку завищених очікувань.

Зберіть приклади проектів, які використовують DVCS.

У світі з відкритим кодом є багато прикладів, включаючи деякі великі, такі як Linux. (Лінус Торвальдс створив git, щоб допомогти керувати розробкою Linux.) Більш корисними для вас будуть приклади корпорацій, які використовують DVCS. (Якщо що-небудь менеджерів ненавидить більше, ніж використовувати технологію занадто рано, це відстає від часу.) Хайп - це саме те, що шумить про технологію чи продукт. Якщо ви зможете знайти докази корпоративного прийняття DVCS, це допоможе протистояти аргументу "це просто багато шуму", можливо, краще, ніж будь-що інше.

Останні поради:

• Бути специфічним. Ваша компанія не збирається впроваджувати цілу технологію - ви приймете конкретний продукт. Деякі продукти завжди будуть менш зрілими, ніж інші. Виберіть два-три відомі продукти DVCS та покажіть, як кожен би вписувався у ваш процес розробки. Менеджерам подобаються конкретні ідеї краще, ніж розпливчасті обіцянки, тому аналіз конкретних технологій змусить їх почувати себе комфортніше.

• Це не все-чи нічого. Будь-який реальний проект із використанням DVCS все ще має центральне сховище, тому побоювання з приводу втрати контролю над коронними коштовностями можна легко вгамувати.

• Не потрібно відмовлятися від вашої поточної системи. Деякі інструменти, такі як git, можуть добре грати з існуючими системами управління версіями, наприклад svn. Таким чином, ви можете легко додати DVCS до свого процесу розробки, нічого не відмовляючись.

• Почніть з малого. Якщо ви не є невеликою компанією, яка має лише один проект, вам потрібно буде легко включити DVCS в процес лише для одного або двох ваших проектів. Вам не доведеться стрибати головою спочатку - просто опустіть носок.

Коротше кажучи, визначте точки опору і зверніться до них максимально чітко.

аргумент / докази певної фази

Якою б фазою це не було, вона повинна відповідати тому, що технологія використовується в професійному режимі "більше 10 років" , оскільки розповсюджена команда VCS TeamWare існує вже більше ніж: посібник користувача pdf, згаданий нижче, датований липнем 2001 року .

Згідно з Вікіпедією, найбільше розгортання TeamWare було всередині самого Sun , де (за кількома винятками) в один момент це був єдиний використаний VCS - який змушує тисячі розробників використовувати цей інструмент. TeamWare використовувався для управління найбільшими джерелами дерева Sun, у тому числі для операційної системи Solaris та системи Java .

Стаття у Вікіпедії посилається на повідомлення Usenix від Евана Адамса, який був архітектурним керівником для TeamWare, де зокрема зазначено:

Навесні 1991 року ми вирішили реалізувати проект TeamWare ...

TeamWare - це набір командних рядків та інструментів графічного інтерфейсу, побудованих з декількох загальних бібліотек. Бібліотеки надаються групою TeamWare для використання програмами TeamWare; вони не передбачені для більш загального використання.

TeamWare - продукт управління кодом, який заохочує паралельний розвиток та будується на основі SCCS. Користувач робить копію (перенесення) ієрархії SCCS, створюючи таким чином особисту ієрархію. У цій ієрархії користувач вносить і тестує зміни. Ці зміни потім інтегруються (повернення) у вихідну ієрархію. Якщо ієрархія інтеграції містить зміни, які не є в ієрархії користувача, то TeamWare виявляє, що відбулися паралельні зміни, і відмовляється від інтеграції. Тому користувачі повинні включити зміни в ієрархії інтеграції до власної ієрархії перед інтеграцією. TeamWare також включає утиліту filemerge, графічну програму з тристоронніми відмінностями, що дозволяє користувачам об'єднувати паралельні зміни. TeamWare відстежує як зміни вихідного файлу (дельти SCCS), так і перейменування файлів ...

Якщо вас цікавить, знайдіть більше деталей тут:

• "Старий і С" Еван Адамс
• "Посібник користувача SunWordShop TeamWare" на сайті Oracle / Sun - pdf ^{липня 2001} , html

^{За моїм спогадом, централізований CVS / SVN тоді мав перевагу в можливості працювати на Windows та Linux, тоді як TeamWare (SCCS) був заблокований у файловій системі Solaris (в Linux він працює більш-менш, якщо хтось знав, як зламати хибні помилки "нульової контрольної суми").}

Моя відповідь:

Я думаю, що відповідь лежить десь між "Інтернет-телебаченням" та "Хмарними обчисленнями" на зростаючому плечі "Піку завищених очікувань" (Хоча я думаю, що обидва вони рухалися дещо стрімко за останні пару років).

Характер циклу ажіотажу:

Як я розумію, прогресування через цикл ажіотажу характеризується розвивається усвідомленням плюсів і мінусів певної технології, а не будь-якою об'єктивною мірою "зрілості" (що б це не означало).

Перш ніж ми накопичили достатньо різноманітний досвід для побудови збалансованих (і незалежних ) думок, динаміка натовпу (природно) змінюється, із сильно співвіднесеними думками з невеликою різноманітністю, тонкістю або глибиною аналізу.

Це так само вірно в "корито розчарування", як і в "піку завищених очікувань"

Якщо громада мала б створити широкий і різноманітний спектр різних думок, з глибоким аналізом того, де і коли доцільно розгортати DVCS, а де і коли цього немає, то ми можемо зробити висновок, що ми перебуваємо на "Плато продуктивності" (Або хоча б якимось чином вгору "Схил Просвітництва").

Якщо, з іншого боку, дискурс орієнтований на перевагу технології (або іншим чином) без врахування занурень і складок конкурентного ландшафту, на якому вона стоїть, то ми можемо зробити висновок, що ми або на "вершині" Завищені очікування "або" корито розчарування ". Ми навіть могли бути одночасно на обох етапах, якщо громада поділяється на табори полум'яною війною.

:-)

Оцінка DVCS за цими критеріями:

З порівняно неглибокого аналізу, який я бачив у дискурсі досі, та відносної відсутності негативних коментарів, я б оцінив, що ми зараз піднімаємося на "вершину завищених очікувань", із запитаннями (такими як цей), що свідчать про те, що там - це ті, хто готує схил вниз з іншого боку.

Я думаю, що сильним показником зрілості технології DVCS (з корпоративної точки зору) стане те, коли дебати змістяться із запитання просто "Чому DVCS?" "Як ми можемо найкраще структурувати наш робочий процес і процеси навколо DVCS, щоб максимізувати користь для організації?".

З того, що я бачив, ми ще не всі там. (Хоча деякі наші більш складні співвітчизники лідирують на шляху)

Роль циклу Hype у прийнятті рішень:

Модель "Цикла Хайпе" - модель упередженості поведінки, і вона допомагає нам зрозуміти власний психічний стан. Якщо ми можемо визначити, що технологія перешкоджає іншим, то це може вплинути на нашу власну психічну позицію, і нам (нам, загрожуючи подвійне думка), нам, можливо, доведеться компенсувати та змусити себе раціонально поводитись у виборі критеріїв відбору.

Критерії відбору:

Потрібно сказати, що вибір критеріїв вибору залежить від контексту.

Особисто я б зробив (як своєрідну вправу для мозкового штурму) короткий (15-хвилинний) SWOT-аналіз кожного варіанту, який ви розглядаєте, разом із (серйозно) PEST-аналізом ситуації, щоб переконатися, що ви розширите ширший (нетехнологічний) фактори вашого аналізу.

SWOT для розподілених VCS

Сильні сторони:

• Гнучкість - більша свобода вибору різних робочих процесів.
• Більш висока продуктивність при низькій пропускній спроможності / високозатримкових мережевих з'єднаннях - краще для розподілених команд та працівників, які не працюють на місці.
• Більш досконалий функціонал злиття, що дозволяє вам частіше вести гілки. (Я не впевнений, що це гарна річ).
• Вихідний код "резервного копіювання" на кожній машині розробників. (досить хитра, ця, оскільки може заважати правильному плануванню відновлення після аварій)

Слабкі сторони:

• Гнучкість - Оскільки у нас є більше свободи вибору різних робочих процесів, нам потрібно провести додаткову роботу, щоб визначити, який робочий процес ми використовуємо, та для його виконання.
• Складність та концептуальні труднощі (особливо для членів команди не розробників програмного забезпечення).

Можливості:

• Можливо, гнучкість може бути використана для проектування робочого процесу, який краще відповідає потребам бізнесу?

Загрози:

• Можливо, ми витратимо стільки часу на переробку свого робочого процесу, що втратимо увагу на нашому основному продукті?
• Деяким людям може бути важко використовувати навіть прості інструменти, особливо якщо вони не вірять, що вони потрібні або інакше не мотивовані.

SWOT для централізованого VCS

Сильні сторони:

• Забезпечує вхідний непрямий канал зв'язку для організації та процесу бізнесу.
• Обмежує можливі робочі процеси до (у багатьох випадках розумного) підмножини.
• Полегшує налаштування CI та інших інструментів автоматизації розвитку.
• (Специфічний для SVN) Підтримує величезні сховища.
• (Специфічний для SVN) Дуже стабільний, використовується багатьма великими консервативними організаціями.
• Політично прийнятніше в організації командування та контролю зверху вниз?

Слабкі сторони:

• Негнучка.
• Низька продуктивність при низькій пропускній здатності / з високою затримкою з'єднань, що ускладнює використання для розподілених команд та працівників поза межами сайту (особливо якщо сховище стає великим)

Можливості:

• Можливо, ми можемо використовувати монолітний характер сховища, щоб допомогти розробникам орієнтуватися по продукту і більше використовувати код один одного?

Загрози:

• Якщо проект раптом стає гіперважливим і нам потрібно залучити додаткових розробників, які працюють на інших сайтах, чи можуть вони ефективно працювати з SVN-сховищем, розміщеним (для них) поза сайтом?
• Якщо набір розробників зросте настільки великим, що координувати їх стане важко, чи стане єдине централізоване сховище вузьким місцем? (Чи можемо ми обійти це будь-яким іншим способом?)

Висновок:

Який VCS використовувати, залежить від конкретних обставин. Для багатьох ситуацій, в яких я працював, DVCS з централізованим робочим процесом зробив би чудово, але мені довелося б обґрунтувати час і зусилля, щоб створити механізм підтримки та застосування робочого процесу, який був би (все ще є) важко.

Зрештою, я думаю, що дискусія повинна зосереджуватися на питанні: який робочий процес найкраще відповідає нашому бізнесу? Найкращий інструмент, який слід використовувати, повинен природним чином випливати з відповіді на це питання.