Gdzie rozproszone systemy kontroli wersji mogą być obecnie w cyklu szumów Gartnera? [Zamknięte]

Edycja : Biorąc pod uwagę ostatnie głosowanie w dół (w tym momencie + 8 / -6), stało się dla mnie jasne, że cykl życia Gartnera jest tendencyjnym wskaźnikiem z perspektywy programisty. To jest część artykułu, który zamierzam przedstawić kierownictwu , a typy zarządzania są częścią grupy odbiorców Gartnera.

Dając ekspozycję i entuzjazm DVCS (to „można” uznać za hype, a przynajmniej zaatakować jako takie ), przeczytaj następujące pytanie: „w jaki sposób mogę użyć cyklu hype Gartnera, aby przekonać kierownictwo, że DVCS są gotowe (lub gotowe) dla nas i nie jest to tylko szum

Samo pytanie, czy DVCS jest szumem, nie byłoby konstruktywne, cykl szumu Gartnera jest bardziej obiektywnym instrumentem niż samo pytanie (nawet jeśli ten instrument jest uważany za stronniczy). Jeśli znasz jakikolwiek inny instrument, proszę o wszelkie informacje go wspomnieć.

Edycja # 2 : Zgadzam się, że Cykl życia Gartnera nie dotyczy każdej technologii, ale uważam, że mógł wygenerować wystarczająco dużo szumu, aby niektórzy uznali go za hype, więc może zasługuje na przynajmniej ocenę / rozważenie jako takiego za pomocą tego instrumentu w aby udowodnić / obalić to w jakimkolwiek stopniu. Jestem orędownikiem DVCS, BTW.

Edycja nr 3 : Dzięki za odpowiedzi. Bounty idzie do Caleba za szczegółowe odpowiedzi i praktyczne porady na moje pytanie. Zaakceptowana odpowiedź trafia do filozofodada za dostarczenie kolejnego przydatnego narzędzia i udzielenie odpowiedzi poza moim pytaniem.

Robię badania dla białej księgi, którą piszę na rzecz przyjęcia DVCS w firmie i natknąłem się na koncepcję dowodu społecznego . Chcę udowodnić, że społeczny dowód przyjęcia DVCS niekoniecznie jest kultem ładunków i prowadząc dalsze badania natknąłem się teraz na cykl szumu Gartnera, który opisuje dojrzałość technologii w 5 fazach.

Moje pytanie brzmi: co może być wskaźnikiem bieżącej lokalizacji rozproszonych systemów kontroli wersji (ogólnie mam na myśli git, mercurial, bazar itp.) Na konkretnym etapie cyklu szumu? ... w innym (mniej skomplikowanym) słowami, czy powiedziałbyś, że obecnie oczekiwania na DVCS są a) początkowe, b) zawyżone, c) malejące (rozczarowanie), d) zwiększające (oświecenie) lub e) stabilizujące (dojrzałe) i (co ważniejsze) dlaczego ?

Wiem, że to trudne pytanie i wiąże się z subiektywizmem, ale udzielę odpowiedzi (i tradycyjnego pliku cookie) na najostrzejszy argument / dowód na konkretny etap.

Cykl szumu mierzy ilość wiadomości / szumu, które generuje konkretna rzecz, a nie faktyczne użycie rzeczy lub jej rzeczywistą wartość produktywności. Więc ... Powiedziałbym, że z tej perspektywy DVCS osiąga szczyt w swoim cyklu wiadomości. Wystarczająco dużo ludzi z niego korzysta i zachęca innych do korzystania z niego, że robi się coraz głośniej w świecie technologii. Gdy adopcja stanie się bardziej powszechna, spodziewam się, że wiadomości / szum zaczną nieco zanikać, gdy pojawi się coś nowego i błyszczącego, a następnie ponownie wzrosną, gdy ludzie zaczną lepiej rozumieć systemy.

Jednym ze sposobów spojrzenia na cykl szumu jest przyjrzenie się liczbie nowych użytkowników. Liczba nowych użytkowników technologii ma ten sam dokładny kształt krzywej co cykl szumu. Sensowne jest, że szum wokół danej nowej technologii będzie szybko rósł, ponieważ technologia ta zyskuje dużą liczbę nowych użytkowników. Wcześni użytkownicy wprowadzają innowacje, a środkowi przyspieszają.

Brzęczenie podczas szybkiego wdrażania innowacji jest niepotrzebnie słabo poinformowane. Jeśli jest wiele osób, które coś wiedzą, ale nie wiedzą o tym, będą mieć inne i prawdopodobnie większe oczekiwania niż doświadczeni użytkownicy. Stąd pochodzi szum.

Brzęczenie po szczytowym tempie adopcji spadnie ... częściowo dlatego, że wcześniejsze nierealistyczne oczekiwania się nie opłaciły (DVCS może sprawi, że będziesz bardziej produktywny, ale nie rozwiąże wszystkich problemów), a częściowo dlatego, że coś innego przechodzi szybki okres adopcji i zajmuje cały umysł. Hype jest kapryśny.

Ale w pewnym momencie zaczynasz otrzymywać dość stały odsetek nowych użytkowników, innowacja stała się normą, a nowi użytkownicy chcą wiedzieć, jak korzystać z tej rzeczy, z której już zdecydowali, że muszą skorzystać. Następnie szum wokół innowacji dotyczy tego, co ludzie robią z nią teraz, gdy jej używają, a nie tego, co mogliby zrobić, gdyby z niej korzystali.

Tak więc, jeśli weźmiesz krzywą szumu i umieścisz ją obok krzywej S współczynników adopcji (patrz „Dyfuzja innowacji” Everetta Rogersa), spodziewaj się, że szum będzie szczytowy tam, gdzie krzywa S jest najbardziej stroma, minimalnie wraz ze zmianą krzywej S kierunek i znów rośnie, gdy innowacja osiąga pełne nasycenie rynku.

DVCS jest w fazie szybkiego przyjęcia, więc prawdopodobnie jesteśmy gdzieś w pobliżu szczytu cyklu szumu.

Nie twierdzę, że jestem ekspertem w temacie cykli szumu, ale przedstawię kilka uwag:

1. Cykl szumu wydaje się być raczej produktem oczekiwań i zainteresowania mediów niż cechą samej technologii. Mój słownik mówi, że hype to „ekstrawagancka lub intensywna reklama lub promocja”. Definiuje reklamę jako „zawiadomienie lub uwagę skierowaną do kogoś lub czegoś przez media”. Media to zbiorowe określenie różnych kanałów masowej komunikacji.

2. Jeśli zaakceptujesz poprzedni punkt, oznacza to, że cykl szumu ma zastosowanie tylko wtedy, gdy media obejmują daną technologię.

3. Nie jest wcale jasne, że cykl szumu dotyczy wszystkich technologii. Czasopisma naukowe są pełne doniesień o postępach, które nie są zauważane przez media głównego nurtu. Bez relacji w mediach, prawdopodobieństwo, że oczekiwania się zawyżą, jest mniejsze i można uniknąć minimalizacji rozczarowania.

4. Rozproszone systemy kontroli wersji to nie tyle nowy pomysł, co udoskonalenie starego. Nazywanie ich „rozwijającą się technologią”, jaką przewiduje cykl szumu, jest trudne.

Zanim zaczniesz budować przypadek, w którym DVCS pasuje do wykresu cyklu szumu, musisz zbudować przypadek, że rozproszona kontrola wersji w ogóle podlega cyklowi szumu. Czy rozproszona kontrola wersji jako „technologia” ma zasięg medialny? Czy są teraz lub kiedykolwiek były zawyżone oczekiwania co do rozproszonej kontroli wersji? Czy prawdopodobne jest, że użytkownicy DVCS rozczarują się, gdy produkty DVCS nie spełnią oczekiwań?

Wydaje mi się bardziej prawdopodobne, że rozproszona kontrola wersji jest tylko ulepszeniem istniejącej kategorii produktów, podobnie jak SVN było ulepszeniem CVS. Jeśli miałbyś sporządzić wykres współczynnika adopcji SVN, nie sądzę, że dostałbyś fabułę, która wygląda jak cykl szumu; zamiast tego dostaniesz fabułę, która stale rośnie aż do plateau dominacji rynkowej, a następnie długi powolny spadek, gdy systemy rozproszone, takie jak „git”, zyskują popularność.

Jeśli naprawdę potrzebujesz odpowiedzi w cyklu szumu, sugeruję, aby DVCS dołączyło do gry na samym dole okresu rozczarowania / frustracji nierozproszonymi systemami kontroli wersji i wspina się na oświecenie wraz ze wzrostem współczynnika adopcji.

Zamiast polegać na cyklu szumu w swoim argumencie, sugeruję skupienie się na szybkości adopcji rozproszonej kontroli wersji i jej przyczynach. Istnieje wiele niepotwierdzonych dowodów na to, że ludzie przechodzą na DVCS, ponieważ to działa; z drugiej strony, nie słyszałem o nikim, kto przestawiłby się na system nie-rozproszony, ponieważ byli rozczarowani. Aby uzyskać twarde dane, możesz spróbować porozmawiać z firmą hostingową, taką jak Beanstalk . Zwróć także uwagę na interoperacyjność systemów scentralizowanych i systemów rozproszonych. Słyszałem, że „git” bardzo dobrze gra z SVN. Scentralizowane systemy nadal działają całkiem dobrze w sferze korporacyjnej, dlatego podkreślenie „bawi się z”

Aktualizacja w odpowiedzi na edycję OP:

jak mogę użyć cyklu szumu Gartnera, aby przekonać kierownictwo, że DVCS są gotowe (lub wystarczająco gotowe) [?]

Myślę, że istnieje kilka podejść, które mogą tu pomóc, a wszystkie opierają się na twardych danych:

Google Trends. Google oczywiście gromadzi mnóstwo danych o tym, co jest w sieci i czego szukają ludzie. Kilka dni temu szukałem (ale nie mogłem znaleźć) dowodów na to, że cykl hype w rozproszonej kontroli wersji. http://trends.google.com/ mówi, że nie ma wystarczającej ilości danych dla warunków dvcs lub kontroli wersji rozproszonej, kiedy ograniczę region do USA (a wyniki dvcs dla świata nie wydają się zbyt trafne ani pomocne). Wyszukiwanie bardziej szczegółowych terminów było nieco lepsze, ale skomplikowane przez fakt, że nazwy produktów, takie jak git i mercurial, mają inne znaczenie (kto wiedział?). Wynik dla git pokazuje trend, który może częściowo wynikać z systemu kontroli wersji:

Próbując uczynić to bardziej specyficznym dla kontroli wersji, próbowałem repozytorium git :

Jeszcze jeden ... zakładając, że jeśli ludzie przyjmują git, powinien być rosnący trend w poszukiwaniu pomocy w poleceniach git, próbowałem git pull (niebieski), git commit (czerwony) i git rebase (złoty):

Ten ostatni wykres wydaje się być najlepszym dowodem na to, że ludzie przyjmują i używają git.

Wyszukiwarka Google.

Spróbuj po prostu wyszukać terminy, takie jak rozproszona kontrola wersji, i zanotuj daty w, powiedzmy, 25 najlepszych artykułach, które znajdziesz. Wykreśl wyniki. Większość hitów, które znalazłem, miała daty z lat 2007-2009. Jeśli cykl hype ma zastosowanie i jeśli możesz pokazać, że większość relacji w mediach miała miejsce 3-5 lat temu, wydaje się to całkiem dobrym dowodem na to, że przekroczyliśmy szczyt zawyżonych oczekiwań.

Zbierz przykłady projektów korzystających z DVCS.

Istnieje wiele przykładów w świecie open source, w tym niektóre duże, takie jak Linux. (Linus Torvalds stworzył git, aby pomóc w zarządzaniu rozwojem Linuksa.) Bardziej przydatne dla ciebie będą przykłady korporacji korzystających z DVCS. (Jeśli jest coś, co menedżerowie nienawidzą bardziej niż zbyt wczesnego wdrażania technologii, to opóźnia się). Hype jest właśnie taki - szum o technologii lub produkcie. Jeśli znajdziesz dowody na przyjęcie DVCS przez korporację, pomoże to przeciwstawić się argumentowi „to tylko dużo szumu”, być może lepiej niż cokolwiek innego.

Ostatnie wskazówki:

• Być specyficznym. Twoja firma nie zamierza zastosować całej technologii - zastosujesz konkretny produkt. Niektóre produkty zawsze będą mniej dojrzałe niż inne. Wybierz dwa lub trzy dobrze znane produkty DVCS i pokaż, jak każdy z nich pasuje do Twojego procesu rozwoju. Menedżerowie lubią konkretne pomysły lepiej niż niejasne obietnice, więc analiza technologii w konkretnych kategoriach sprawi, że poczują się bardziej komfortowo.

• To nie wszystko albo nic. Każdy prawdziwy projekt wykorzystujący DVCS nadal będzie miał centralne repozytorium, więc obawy o utratę kontroli nad klejnotami koronnymi można łatwo uspokoić.

• Nie musisz rezygnować z obecnego systemu. Niektóre narzędzia, takie jak git, mogą dobrze współpracować z istniejącymi systemami kontroli wersji, takimi jak svn. Dzięki temu możesz łatwo dodawać DVCS do swojego procesu programowania, nie rezygnując z niczego.

• Zacznij od małego. O ile nie pracujesz w małej firmie, która ma tylko jeden projekt, włączenie DVCS do procesu dla jednego lub dwóch projektów powinno być łatwe. Nie musisz najpierw wskakiwać do głowy - wystarczy zanurzyć palec u nogi.

Krótko mówiąc, określ punkty oporu i rozwiąż je tak wyraźnie, jak to możliwe.

argument / dowód konkretnej fazy

Niezależnie od tego, jaka to może być faza, musi to być faza zgodna z faktem, że technologia jest w profesjonalnym użyciu przez „ponad 10 lat” , ponieważ rozproszone oprogramowanie VCS TeamWare istnieje od dłuższego czasu: pdf Przewodnik użytkownika, o którym mowa poniżej, jest datowany na lipiec 2001 r. .

Według Wikipedii największe wdrożenie TeamWare miało miejsce w samym Sun , gdzie (poza kilkoma wyjątkami) w pewnym momencie był to jedyny używany VCS - co sprawia, że ​​tysiące programistów korzysta z tego narzędzia. TeamWare został wykorzystany do zarządzania największymi drzewami źródłowymi Sun, w tym drzewami systemu operacyjnego Solaris i systemu Java .

Artykuł w Wikipedii odnosi się do wiadomości Usenix od Evana Adamsa, który był pionierem architektonicznym w TeamWare, który stwierdza w szczególności:

Wiosną 1991 roku postanowiliśmy wdrożyć projekt TeamWare ...

TeamWare to zestaw narzędzi wiersza polecenia i GUI zbudowany z kilku popularnych bibliotek. Biblioteki są dostarczane przez grupę TeamWare do użytku przez aplikacje TeamWare; nie są przewidziane do bardziej ogólnego użytku.

TeamWare to produkt do zarządzania kodami, który zachęca do równoległego programowania i jest oparty na SCCS. Użytkownik tworzy kopię (przywracanie) hierarchii SCCS, tworząc w ten sposób osobistą hierarchię. W tej hierarchii użytkownik wprowadza i testuje zmiany. Zmiany te są następnie włączane (odkładanie) do pierwotnej hierarchii. Jeśli hierarchia integracji zawiera zmiany, których nie ma w hierarchii użytkownika, TeamWare wykrywa, że ​​nastąpiły równoległe zmiany i odmawia integracji. Dlatego użytkownicy muszą wprowadzić zmiany w hierarchii integracji do swojej własnej hierarchii przed integracją. TeamWare zawiera także narzędzie filemerge, graficzny program różnicowy, umożliwiający użytkownikom łączenie równoległych zmian. TeamWare śledzi zarówno zmiany plików źródłowych (delty SCCS), jak i zmiany nazw plików ...

Jeśli jesteś zainteresowany, znajdź więcej szczegółów tutaj:

• „The Old Man and the C” Evana Adamsa
• „Sun WorkShop TeamWare Podręcznik użytkownika” w witrynie Oracle / Sun - pdf ^{lipiec 2001} , HTML

^{Według moich wspomnień, scentralizowane CVS / SVN miało wówczas zaletę możliwości uruchamiania w systemach Windows i Linux, podczas gdy TeamWare (SCCS) został zablokowany w systemie plików Solaris (w systemie Linux działa mniej więcej, jeśli ktoś wie, jak się włamać) fałszywe błędy „zerowej sumy kontrolnej”).}

Moja odpowiedź:

Myślę, że odpowiedź leży gdzieś pomiędzy „telewizją internetową” a „chmurą obliczeniową” na rosnącym ramieniu „Szczytu napompowanych oczekiwań” (chociaż myślę, że oba te elementy postępowały dość szybko w ciągu ostatnich kilku lat).

Charakter cyklu szumu:

Jak rozumiem, postęp w cyklu szumu charakteryzuje się coraz większą świadomością zalet i wad konkretnej technologii, a nie jakąkolwiek obiektywną miarą „dojrzałości” (cokolwiek to oznacza).

Zanim zgromadziliśmy wystarczająco zróżnicowany zestaw doświadczeń, aby budować zrównoważone (i niezależne ) opinie, dynamika tłumu (naturalnie) rządzi, z wysoce skorelowanymi opiniami o małej różnorodności, subtelności lub głębokości analizy.

Dotyczy to zarówno „Koryta rozczarowania”, jak i „Szczytu napompowanych oczekiwań”

Jeśli społeczność miałaby przedstawić szeroki i różnorodny zakres różnych opinii, z dogłębną analizą tego, gdzie i kiedy należy wdrożyć DVCS, a gdzie i kiedy nie jest, możemy wywnioskować, że jesteśmy na „płaskowyżu produktywności” (Lub przynajmniej trochę w górę „Stoku Oświecenia”).

Z drugiej strony, jeśli dyskurs koncentruje się na wyższości (lub innej) technologii bez względu na spadki i fałdy konkurencyjnego krajobrazu, na którym się ona opiera, wówczas możemy wywnioskować, że jesteśmy na „szczycie” Napompowane oczekiwania ”lub„ Koryto rozczarowania ”. Moglibyśmy być jednocześnie w obu fazach, gdyby społeczność została podzielona na obozy przez wojnę z płomieniami.

:-)

Ocena DVCS według tych kryteriów:

Na podstawie stosunkowo płytkiej analizy, którą do tej pory widziałem w dyskursie, oraz względnego braku negatywnych komentarzy, szacuję, że wspinamy się obecnie na „Szczyt nadmuchanych oczekiwań”, z pytaniami (takimi jak ta) wskazującymi, że istnieje są tacy, którzy przygotowują stok po drugiej stronie.

Myślę, że silnym wskaźnikiem dojrzałości technologii DVCS (z korporacyjnego punktu widzenia) będzie moment, w którym debata zmieni się z pytania „Dlaczego DVCS?”. do „Jak najlepiej ustrukturyzować nasz przepływ pracy i procesy wokół DVCS, aby zmaksymalizować korzyści dla organizacji?”.

Z tego, co widziałem, jeszcze nas wszystkich nie ma. (Chociaż niektórzy z naszych bardziej wyrafinowanych rodaków przodują)

Rola cyklu szumów w podejmowaniu decyzji:

Model „Hype Cycle” to model błędu behawioralnego, który pomaga nam zrozumieć własny stan psychiczny. Jeśli uda nam się ustalić, że technologia jest rozpowszechniana przez innych, może to wpłynąć na naszą mentalną postawę i (na ryzyko podwójnego myślenia) możemy potrzebować odpowiednio zrekompensować i zmusić się do racjonalnego wyboru naszych kryteriów wyboru.

Kryteria wyboru:

Nie trzeba dodawać, że kryteria wyboru są bardzo zależne od kontekstu.

Osobiście przeprowadziłbym (jako rodzaj burzy mózgów) krótką (15 minut) analizę SWOT każdej rozważanej opcji wraz z (poważnie) analizą PEST sytuacji, aby zapewnić szersze (nietechnologiczne) czynniki w twojej analizie.

SWOT dla rozproszonego VCS

Silne strony:

• Elastyczność - większa swoboda wyboru różnych przepływów pracy.
• Lepsza wydajność w połączeniach sieciowych o niskiej przepustowości / dużym opóźnieniu - lepsza dla rozproszonych zespołów i pracowników zewnętrznych.
• Bardziej wyrafinowana funkcjonalność scalania, pozwalająca na częstsze rozgałęzienia. (Nie jestem pewien, czy to dobra rzecz).
• Kopia zapasowa kodu źródłowego jest wykonywana na każdym komputerze programisty. (dość fałszywy, ponieważ może to zakłócać prawidłowe planowanie odzyskiwania po awarii)

Słabości:

• Elastyczność - ponieważ mamy większą swobodę wyboru różnych przepływów pracy, musimy wykonać dodatkową pracę, aby określić, którego przepływu pracy używamy, i go wymusić.
• Złożoność i trudności koncepcyjne (szczególnie dla członków zespołu nie będących programistami).

Możliwości:

• Być może elastyczność może zostać wykorzystana do zaprojektowania przepływu pracy, który lepiej odpowiada potrzebom biznesowym?

Zagrożenia

• Być może spędzimy tak długo na przeprojektowaniu naszego przepływu pracy, że stracimy koncentrację na naszym głównym produkcie?
• Niektóre osoby mogą mieć trudności z użyciem nawet prostych narzędzi, zwłaszcza jeśli nie wierzą, że są konieczne lub w inny sposób nie mają motywacji.

SWOT dla scentralizowanego VCS

Silne strony:

• Zapewnia ukryty wewnątrz pasma kanał komunikacji dla organizacji i procesów biznesowych.
• Ogranicza możliwe przepływy pracy do podzbioru (w wielu przypadkach uzasadnionego).
• Ułatwia konfigurację CI i innych narzędzi automatyzacji programowania.
• (Specyficzne dla SVN) Obsługuje ogromne repozytoria.
• (Specyficzne dla SVN) Bardzo stabilny, używany przez wiele dużych, konserwatywnych organizacji.
• Politycznie bardziej akceptowalny w odgórnej organizacji dowodzenia i kontroli?

Słabości:

• Nieelastyczny.
• Niska wydajność w przypadku połączeń o niskiej przepustowości / dużych opóźnieniach, co sprawia, że ​​jest trudniejszy w użyciu dla rozproszonych zespołów i pracowników zewnętrznych (szczególnie w przypadku dużego repozytorium)

Możliwości:

• Być może możemy użyć monolitycznej natury repozytorium, aby pomóc programistom w nawigacji po produkcie i ponownym wykorzystaniu kodu innych użytkowników?

Zagrożenia

• Jeśli projekt nagle stanie się niezwykle ważny i musimy pozyskać dodatkowych programistów pracujących na innych stronach, czy mogą skutecznie współpracować z repozytorium SVN hostowanym (dla nich) poza witryną?
• Jeśli zestaw programistów będzie tak duży, że ich koordynacja stanie się trudna, czy pojedyncze scentralizowane repozytorium stanie się wąskim gardłem? (Czy możemy to obejść w inny sposób?)

Wniosek:

Wybór VCS zależy od indywidualnych okoliczności. W wielu sytuacjach, w których pracowałem, system DVCS ze scentralizowanym przepływem pracy byłby w porządku, ale musiałbym uzasadnić czas i wysiłek w celu opracowania mechanizmu do obsługi i egzekwowania przepływu pracy, który byłby (nadal jest trudne.

Ostatecznie uważam, że dyskusja powinna koncentrować się na pytaniu: jaki przepływ pracy najlepiej odpowiada naszej firmie? Najlepsze narzędzie do użycia powinno naturalnie wynikać z odpowiedzi na to pytanie.