Где могут быть распределенные системы контроля версий в настоящее время в цикле обмана Gartner? [закрыто]

Редактировать : Учитывая недавнее снижение голосов (+ 8 / -6 на данный момент), мне стало ясно, что жизненный цикл Gartner является предвзятой метрикой с точки зрения программиста. Это то, что является частью статьи, которую я собираюсь представить руководству , а типы управления являются частью аудитории Gartner.

Давая DVCS разоблачение и энтузиазм (которые «могли бы» рассматриваться как ажиотаж или, по крайней мере, подвергались нападкам как таковые ), подумайте над следующим вопросом, читая этот: «Как я могу использовать цикл ажиотажа Gartner, чтобы убедить руководство в том, что DVCS готовы (или достаточно готов) для нас, и это не просто ажиотаж

Просто спрашивать, не является ли DVCS рекламой, не будет конструктивным, цикл рекламы Gartner является более объективным инструментом, чем просто спрашивать об этом (даже если этот инструмент считается необъективным). Если вы знаете какой-либо другой инструмент, пожалуйста, обязательно укажите его.

Редактирование # 2 : Я согласен, что жизненный цикл Gartner не для каждой технологии, но я считаю, что он, возможно, вызвал достаточно шума, чтобы некоторые считали его обманом, поэтому, возможно, он заслуживает, по крайней мере, оценки / обдумывания как такового с использованием этого инструмента в чтобы доказать / опровергнуть это в какой-то степени. Я сторонник DVCS, кстати.

Редактировать № 3 : Спасибо за ваши ответы. Баунти идет к Калебу за подробные ответы на мой вопрос и практические советы. Принятый ответ поступает в Philodadad за предоставление еще одного полезного инструмента и ответы за пределы моего вопроса.

Я занимаюсь исследованием белой книги, которую я пишу в пользу принятия DVCS в компании, и я наткнулся на концепцию социального доказательства . Я хочу доказать, что социальное доказательство принятия DVCS не обязательно является культом груза, и проводя дальнейшие исследования, я наткнулся на цикл обмана Gartner, который описывает зрелость технологии в 5 фазах.

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

Я знаю, что это сложный вопрос, и в этом есть субъективность, но я предоставлю ответ (и традиционное печенье) ясному аргументу / доказательству для конкретной фазы.

Цикл обмана измеряет количество новостей / шума, которое генерирует конкретная вещь, а не фактическое использование этой вещи или ее фактическое значение производительности. Итак ... Я бы сказал, что с этой точки зрения DVCS достигает пика в своем новостном цикле. Достаточно людей фактически используют это и поощряют других людей использовать это, что это получает много шума в техническом мире. Как только усыновление получит более широкое распространение, я ожидаю, что новости / гудение немного исчезнут, когда появится что-то новое и блестящее, а затем снова поднимутся, когда люди начнут понимать системы более полно.

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

Шум во время быстрого принятия нововведения обязательно плохо информирован. Если есть много людей, которые знают что-то, но не знают об этом, у них будут другие и, возможно, большие ожидания, чем у опытных пользователей. Так вот откуда пошла шумиха.

Шум после того, как уровень усыновления достиг пика, уменьшится ... отчасти потому, что ранее нереалистичные ожидания не оправдались (возможно, DVCS сделает вас более продуктивным, но не решит все ваши проблемы), а отчасти потому, что что-то еще проходит через период быстрого усыновления и занимает весь разум. Обман переменчивый.

Но в какой-то момент вы начинаете получать довольно постоянный процент новых пользователей, инновации стали нормой, и новые пользователи хотят знать, как использовать эту вещь, которую они уже решили использовать. Тогда шумиха вокруг инноваций связана с тем, что люди на самом деле делают с ним сейчас, когда они его используют, а не с тем, что они могли бы сделать с ним, если бы использовали его.

Поэтому, если вы взяли кривую шумихи и поместили ее рядом с S-кривой коэффициентов усыновления (см. «Распространение инноваций» Эверетта Роджерса), вы ожидаете, что ажиотаж достигнет пика там, где S-кривая самая крутая, хотя и меняется по мере изменения S-кривой. направление, и расти снова, как инновация достигает полного насыщения рынка.

DVCS находится в периоде быстрого внедрения, поэтому мы, вероятно, где-то на пике цикла обмана.

Я не утверждаю, что являюсь экспертом в области шумихи, но я приведу несколько замечаний:

1. Цикл обмана кажется скорее продуктом ожиданий и освещения в СМИ, чем характеристикой самой технологии. В моем словаре говорится, что реклама - это «экстравагантная или интенсивная реклама или продвижение по службе». Он определяет публичность как «уведомление или внимание, уделяемое кому-либо или чему-либо средствами массовой информации». Медиа - это собирательный термин для различных каналов массовой коммуникации.

2. Если вы согласитесь с предыдущим пунктом, из этого следует, что цикл рекламы применяется только тогда, когда носители охватывают данную технологию.

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

4. Распределенные системы контроля версий не столько новая идея, сколько утонченная старая. Называть их «развивающейся технологией» такого рода, как предполагается, должно предсказать цикл обмана.

Прежде чем вы начнете строить случай, когда DVCS вписывается в график цикла рекламы, вам нужно создать случай, когда распределенный контроль версий вообще подвергается циклу рекламы. Распространяется ли контроль версий как «технология» в СМИ? Существуют ли сейчас или когда-либо завышенные ожидания в отношении распределенного контроля версий? Возможно ли, что пользователи DVCS разочаруются, когда продукты DVCS не оправдают ожиданий?

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

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

Вместо того, чтобы полагаться на цикл обмана для вашего аргумента, я бы предложил сосредоточиться на скорости принятия распределенного контроля версий и причинах этого. Существует множество примеров того, что люди переходят на DVCS, потому что он работает; с другой стороны, я не слышал, чтобы кто-то снова переключался на нераспределенную систему, потому что был разочарован. Чтобы получить точные данные, вы можете попробовать поговорить с хостинговой компанией, такой как Beanstalk . Также обратите внимание на взаимодействие между централизованными системами и распределенными системами. Я слышал, что "git" играет очень хорошо с SVN. Централизованные системы продолжают хорошо работать в корпоративной сфере, поэтому особое внимание уделяется принципу «хорошо играет»

Обновление в ответ на редактирование OP:

как я мог использовать цикл обмана Gartner, чтобы убедить руководство в том, что DVCS готовы (или достаточно готовы) [?]

Я думаю, что есть несколько подходов, которые могут помочь здесь, и все полагаются на достоверные данные:

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

Пытаясь сделать это более специфичным для контроля версий, я попробовал git-репозиторий :

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

Этот последний график, кажется, является лучшим доказательством того, что люди принимают и используют git.

Поиск Гугл.

Попробуйте просто найти такие термины, как распределенный контроль версий, и запишите даты, скажем, в 25 лучших статьях, которые вы найдете. График результатов. У большинства хитов, которые я нашел, были даты в диапазоне 2007-2009. Если цикл обмана применим, и если вы можете показать, что большая часть освещения в СМИ происходила 3-5 лет назад, это кажется довольно хорошим доказательством того, что мы вышли за пределы пика завышенных ожиданий.

Соберите примеры проектов, которые используют DVCS.

В мире с открытым исходным кодом есть множество примеров, включая такие крупные, как Linux. (Линус Торвальдс создал git для управления разработкой Linux.) Более полезными для вас будут примеры корпораций, использующих DVCS. (Если есть что-то, что менеджеры ненавидят больше, чем внедрять технологию слишком рано, это отстает от времени.) Hype - это просто гудение о технологии или продукте. Если вы сможете найти доказательства корпоративного принятия 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 deltas), так и переименования файлов ...

Если вы заинтересованы, найдите более подробную информацию здесь:

• "Старик и Си" Эвана Адамса
• «Руководство пользователя Sun WorkShop TeamWare» на сайте Oracle / Sun - pdf ^{июль 2001 г.} , html

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

Мой ответ:

Я думаю, что ответ лежит где-то между «интернет-телевидением» и «облачными вычислениями» на растущем плече «пика завышенных ожиданий» (хотя я думаю, что оба из них продвинулись довольно быстро в последние пару лет).

Природа цикла обмана:

Насколько я понимаю, прохождение через цикл обмана характеризуется возрастающим осознанием плюсов и минусов конкретной технологии, а не какой-либо объективной мерой «зрелости» (что бы это ни значило).

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

Это так же верно в «корыте разочарования», как и в «пике завышенных ожиданий»

Если бы сообщество подготовило широкий и разнообразный спектр различных мнений с углубленным анализом того, где и когда целесообразно развертывать DVCS, а где и когда нет, то мы можем сделать вывод, что мы находимся на «плато производительности» (Или, по крайней мере, каким-то образом вверх по «Склону Просвещения»).

Если, с другой стороны, дискурс сфокусирован на превосходстве (или иным образом) технологии без учета провалов и сгибов конкурентной среды, на которой она стоит, то мы можем сделать вывод, что мы находимся на «пике Завышенные ожидания »или« Корыто разочарования ». Мы могли бы даже быть в обеих фазах одновременно, если сообщество разделено на лагеря пламенной войной.

:-)

Оценка DVCS по этим критериям:

Из сравнительно поверхностного анализа, который я видел в беседе до сих пор, и относительного отсутствия негативных комментариев, я бы оценил, что в настоящее время мы поднимаемся на «Пик завышенных ожиданий», с вопросами (такими как этот), указывающими на то, что Есть те, кто готовит спуск с другой стороны.

Я думаю, что сильным показателем зрелости технологии DVCS (с корпоративной точки зрения) будет то, когда дискуссия переходит от простого вопроса "Почему DVCS?" на «Как мы можем наилучшим образом структурировать наш рабочий процесс и процессы вокруг DVCS, чтобы максимизировать выгоду для организации?».

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

Роль Hype Cycle в принятии решений:

Модель "Hype Cycle" - это модель поведенческого смещения, и она помогает нам понять наше собственное психическое состояние. Если мы сможем определить, что технология раздувается другими, то это может повлиять на наше собственное умственное состояние, и (с риском некоторого обдумывания) нам может потребоваться соответствующая компенсация и заставить себя вести себя рационально при выборе наших критериев выбора.

Критерий отбора:

Излишне говорить, что выбор критериев выбора в значительной степени зависит от контекста.

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

SWOT для распределенных VCS

Сильные стороны:

• Гибкость - больше свободы выбора различных рабочих процессов.
• Лучшая производительность по сравнению с сетевыми подключениями с низкой пропускной способностью / высокой задержкой - лучше для распределенных команд и удаленных работников
• Более сложная функциональность слияния, позволяющая вам чаще выполнять ветвления. (Я не уверен, что это хорошо).
• Исходный код «резервируется» на каждом компьютере разработчика. (довольно поддельный, этот, так как это может помешать правильному планированию аварийного восстановления)

Слабые стороны:

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

Возможности:

• Возможно, гибкость может быть использована для разработки рабочего процесса, который лучше подходит для потребностей бизнеса?

Угрозы:

• Возможно, мы потратим так много времени на перестройку нашего рабочего процесса, что потеряем фокус на нашем основном продукте?
• Может быть трудно заставить некоторых людей использовать даже простые инструменты, особенно если они не верят в то, что они необходимы, или иным образом не мотивированы.

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

Сильные стороны:

• Обеспечивает внутриполосный неявный канал связи для организации бизнеса и процессов.
• Ограничивает возможные рабочие процессы (во многих случаях разумным) подмножеством.
• Упрощает настройку CI и других инструментов автоматизации разработки.
• (SVN) Поддерживает огромные репозитории.
• (Специфично для SVN) Очень стабильный, используется многими крупными консервативными организациями.
• Политически более приемлемо в нисходящей командно-контрольной организации?

Слабые стороны:

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

Возможности:

• Возможно, мы можем использовать монолитную природу хранилища, чтобы помочь разработчикам ориентироваться в продукте и больше использовать код друг друга?

Угрозы:

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

Вывод:

Какой VCS использовать, зависит от индивидуальных обстоятельств. Для многих ситуаций, в которых я работал, DVCS с централизованным рабочим процессом работала бы хорошо, но мне пришлось бы оправдать время и усилия, чтобы создать механизм поддержки и обеспечения рабочего процесса, который был бы (все еще это трудно.

В конечном счете, я думаю, что обсуждение должно сосредоточиться вокруг вопроса: какой рабочий процесс лучше всего подходит нашему бизнесу? Лучший инструмент для использования должен естественно следовать из ответа на этот вопрос.