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.
Odpowiedzi:
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.
źródło
Nie twierdzę, że jestem ekspertem w temacie cykli szumu, ale przedstawię kilka uwag:
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.
Jeśli zaakceptujesz poprzedni punkt, oznacza to, że cykl szumu ma zastosowanie tylko wtedy, gdy media obejmują daną technologię.
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.
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:
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.
źródło
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:
Jeśli jesteś zainteresowany, znajdź więcej szczegółów tutaj:
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”).
źródło
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:
Słabości:
Możliwości:
Zagrożenia
SWOT dla scentralizowanego VCS
Silne strony:
Słabości:
Możliwości:
Zagrożenia
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.
źródło