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

12

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.

wprowadź opis zdjęcia tutaj

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.

dukeofgaming
źródło
1
po ponad 10 latach musi być na „Płaskowyżu produktywności” według tej sztucznej skali
komara
@gnat: Zgadzam się w 100%! W 2000 roku, kiedy pracowałem w Sun, używałem SCCS / Teamware, co dobrze to zrobiło. Drapałem się w głowę, zastanawiając się, jak ktokolwiek może polubić CVS. Linus Torvalds myślał tak samo i utknął z BitKeeperem, dopóki nie stworzył Gita. To CVS / SVN miało niepotrzebny szum!
Macneil
@Macneil dobrze na moje wspomnienia, CVS / SVN były zdolne do działania 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ś wiedział, jak zhakować fałszywą „zerową sumę kontrolną” robaki). Nie chodzi mi o to, że jedno lub drugie jest lepsze, wystarczy dodać kilka faktów
komnata
7
Skala czasowa na wykresie nie wydaje się odnosić do czasu od pierwotnego wprowadzenia. Na przykład „Moc bezprzewodowa” jest wyświetlana po lewej stronie, mimo że Tesla zrobił to w latach 90. XIX wieku, a nawet jeśli ograniczymy ją do rzeczy zaawansowanych technologicznie / komputerowych, pasywne znaczniki RFID również używają jej od dłuższego czasu.
Jerry Coffin
@gnat: Czas nic tu nie znaczy. Dana technologia może pozostać na zawsze na określonym etapie, a nawet tam umrzeć.
CesarGon

Odpowiedzi:

5

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.

filozofodad
źródło
Zasadniczo więc mówisz, że DVCS mogą być na szczycie, ponieważ ludzie wciąż o tym głoszą ?, lub znów powstają, ponieważ lepiej się rozumie?
dukeofgaming
Powiedziałbym, że potencjalna pula osób adoptujących jest wciąż duża, więc jest wiele ciekawości i nowych, podekscytowanych użytkowników. Jeśli spojrzysz na krzywą S w Rogers „Diffusion of Innovations”, DVCS jest, jak sądzę, bardzo stromy - szybko się dostosowuje. Ta szybka adopcja generuje szum w wiadomościach / buzzie. W miarę nasycania adopcji szum zmniejsza się. Rzecz jest teraz stara. Następnie, gdy adopcja staje się normą, wiadomości i szum stają się bardziej tym, co ludzie robią, niż tym, co mogą zrobić.
Philodadad
1
filozofodad, czy mógłbyś rozwinąć tę kwestię jako część odpowiedzi?
dukeofgaming
@dukeofgaming Zmodyfikowałem moją odpowiedź, aby rozwinąć tę kwestię.
Philododad
15

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:

trend git

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

trend 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):

git trend pull / commit / rebase

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.

Caleb
źródło
1
Cykl szumu ma zastosowanie we wszystkich przypadkach z wyjątkiem kilku zdegenerowanych, nawet jeśli nie zostały zgłoszone przez media. Przypadki, w których nie ma miejsca, w których nigdy nie ma wstępnej adopcji (martwa technologia) i gdzie minimalne rozczarowanie osiąga zero (często z powodu zastąpienia technologii czymś całkowicie lepszym).
Donal Fellows
2
Kiedy „przegląd rozczarowania” miał miejsce w przeglądarce?
Gort the Robot
1
@StevenBurnap Czy przeglądarka przeszła w dowolnym momencie? (prawdziwe pytanie)
dukeofgaming
1
Z drugiej strony, czy cykl szumu dotyczy WSZYSTKIEGO? Czy istnieją jakieś faktyczne badania, które to potwierdzają? O ile mogę stwierdzić, cykl hype polega prawie na dopasowaniu wzorca wiadomości do czegoś po fakcie. Nie mówi ci nic o przyszłości, obecnym stanie innowacji, krzywej przyszłych zmian, a nawet jeśli powinieneś ją przyjąć, czy nie.
Philodadad
1
@WilliamPayne Przyznaję, że jest możliwe, że jakaś społeczność może nagle odkryć istniejącą technologię i że media w tej społeczności mogą generować szum / buzz zgodnie z wzorcem cyklu szumu. Zwracam jednak uwagę, że wykres w pytaniu PO jest oznaczony jako „Cykl szumów dla nowych technologii”. Ponadto nie wystarczy zakładać, że coś takiego może się zdarzyć - naprawdę musisz wskazać przykłady, w których to się wydarzyło. Jak zauważa filozofodad, pytanie, czy cykl szumu jest prawdziwy, czy tylko postrzegany, jest pytaniem otwartym.
Caleb
2

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 .

http://i.stack.imgur.com/J68MH.png

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:


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”).

komar
źródło
4
Istnieją technologie ponad 10 lat przed szczytem zawyżonych oczekiwań. Nie jestem pewien, czy czas sam może umiejscowić określoną technologię na pewnym etapie.
dukeofgaming
@dukeofgaming od ponad 10 lat jest obiektywnym faktem i właśnie to stwierdzam. Jakikolwiek subiektywny „etap” / „hype-miara” byłby nad nim wypchany, fakt musi tam być
komnata
1
Przepraszam, wciąż nie rozumiem o co ci chodzi. Jeśli rozumiem poprawność, mówisz, że ~ 10 lat jest obiektywnym faktem, ale na jaki etap?
dukeofgaming
1
@gnat: Myślę, że „Hype Cycle” jest dużym błędem. Cykl szumów nie dotyczy szumu, ale dojrzałości technologicznej. Hype jest tylko konsekwencją tego, że o technologii się mówi, ale nie jest wystarczająco dojrzała; cykl pokazuje to, ale także inne aspekty, takie jak adopcja. Podsumowując, biorę cykl szumów dla tego, co przedstawia dojrzałość wrt zamiast szumu, szum jest tylko drobnym problemem.
CesarGon
3
@gnat: Nie neguję zasług DVCS w tym zakresie. Ale model Hype Cycle ocenia dojrzałość plus oczekiwania razem; technologia może być dość dojrzała, ale jeśli oczekiwania co do niej są bardzo wysokie, wciąż może być rozczarowująca (stąd rozczarowanie). Moim zdaniem oczekiwania dotyczące DVCS były znacznie wyższe niż to, co dostarczył. Ponadto DVCS mógł być wykorzystywany w projektach Solaris i Java, ale to nie znaczy, że jego dojrzałość i oczekiwania są zrównoważone. Stąd wysoki szum.
CesarGon
1

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.

William Payne
źródło
Aby odpowiedzieć na twoje pytanie w innym komentarzu: aplikacja korporacyjna
dukeofgaming