Dove potrebbero essere attualmente i sistemi di controllo della versione distribuita nel ciclo di hype di Gartner? [chiuso]

Modifica : dato il recente downvoting (+ 8 / -6 a questo punto) mi è stato chiarito che il ciclo di vita di Gartner è una metrica distorta dal punto di vista di un programmatore. Questo è qualcosa che fa parte di un documento che presenterò al management , e i tipi di management fanno parte del pubblico di Gartner.

Dando esposizione ed entusiasmo DVCS (che "potrebbe" essere considerato hype, o almeno attaccato come tale ), rifletti sulla seguente domanda quando leggo questo: "Come potrei usare il ciclo di hype di Gartner per convincere il management che i DVCS sono pronti (o pronto) per noi, e che non è solo hype "

Chiedere solo se il DVCS è hype non sarebbe costruttivo, il ciclo hype di Gartner è uno strumento più oggettivo che chiederlo (anche se questo strumento è considerato distorto). Se conosci altri strumenti, per favore, menzionalo.

Modifica n. 2 : sono d'accordo sul fatto che il ciclo di vita di Gartner non è per tutte le tecnologie, ma ritengo che potrebbe aver generato abbastanza brusio per essere considerato da alcuni da hype, quindi forse merita di essere almeno valutato / ponderato come tale utilizzando questo strumento in per dimostrarlo / confutarlo a qualunque livello. Sono un sostenitore di DVCS, BTW.

Modifica n. 3 : grazie per le risposte. Bounty va a Caleb per aver risposto alla mia domanda con dettagli e consigli pratici. La risposta accettata va a philosodad per aver fornito un altro strumento utile e aver risposto oltre la mia domanda.

Sto facendo ricerche per un white paper che sto scrivendo a favore dell'adozione del DVCS in azienda e mi sono imbattuto nel concetto di prova sociale . Voglio dimostrare che la prova sociale dell'adozione del DVCS non è necessariamente un culto del carico e, facendo ulteriori ricerche, sono incappato nel ciclo di hype di Gartner che descrive la maturità tecnologica in 5 fasi.

La mia domanda è: quale potrebbe essere un indicatore della posizione attuale dei sistemi di controllo della versione distribuita (intendo git, mercurial, bazar, ecc. In generale) in una fase particolare del ciclo di hype? ... in altri (meno contorti) parole, diresti che attualmente le aspettative dei DVCS sono a) iniziare, b) gonfiare, c) diminuire (disillusione), d) aumentare (illuminazione) o e) stabilizzare (maturo) e (soprattutto) perché ?

So che è una domanda difficile e c'è soggettività, ma concederò la risposta (e il cookie tradizionale) all'argomento / alle prove più chiare per una particolare fase.

Il ciclo di hype misura la quantità di notizie / buzz generati da una particolare cosa, non l'uso effettivo della cosa o il suo valore di produttività reale. Quindi ... direi che da quel punto di vista, DVCS sta raggiungendo un picco nel suo ciclo di notizie. Abbastanza persone lo stanno effettivamente usando e incoraggiando altre persone a usarlo perché sta ottenendo un sacco di buzz nel mondo della tecnologia. Una volta che l'adozione è più diffusa, mi aspetto che le notizie / i buzz svaniscano un po 'quando arriva qualcosa di nuovo e brillante, e poi si rialzano quando le persone iniziano a comprendere i sistemi in modo più completo.

Un modo per esaminare il ciclo di hype è quello di esaminare il numero di nuovi utenti. Il numero di nuovi utenti di una tecnologia tende a seguire la stessa forma curva esatta del ciclo di hype. Ha senso che il ronzio attorno a una data nuova tecnologia crescerà rapidamente man mano che la tecnologia acquisisce un gran numero di nuovi utenti. I primi utenti diffondono l'innovazione e quelli di mezzo generano il brusio.

Il brusio durante la rapida adozione di un'innovazione è necessariamente scarsamente informato. Se ci sono molte persone che sanno qualcosa ma non lo sanno, avranno aspettative diverse e forse maggiori rispetto agli utenti esperti. Ecco da dove viene l'hype.

Il ronzio dopo che il tasso di adozione ha raggiunto il picco cadrà ... in parte perché in precedenza, le aspettative non realistiche non hanno ripagato (il DVCS ti renderà più produttivo, forse, ma non risolverà tutti i tuoi problemi) e in parte perché qualcos'altro sta attraversando un periodo di adozione rapida e sta occupando tutta la condivisione della mente. Hype è volubile.

Ma a un certo punto, inizi a ottenere un tasso abbastanza costante di nuovi utenti, l'innovazione è diventata la norma e i nuovi utenti vogliono sapere come utilizzare questa cosa che hanno già deciso di utilizzare. Quindi il ronzio attorno all'innovazione riguarda tutto ciò che le persone effettivamente ne fanno ora che lo stanno usando, piuttosto che cosa potrebbero farci se lo usassero.

Quindi, se prendessi la curva hype e la mettessi accanto alla curva S dei tassi di adozione (vedi "Diffusione di innovazioni" di Everett Rogers), ti aspetteresti che l'hype raggiunga il picco in cui la curva S è più ripida, attraverso il cambiamento della curva S direzione e rialzarsi quando l'innovazione raggiunge la sua piena saturazione del mercato.

Il DVCS è in un periodo di rapida adozione, quindi probabilmente siamo da qualche parte intorno al picco del ciclo di hype.

Non pretendo di essere un esperto in materia di cicli di hype, ma offrirò alcune osservazioni:

1. Il ciclo di pubblicità sembra essere più un prodotto di aspettative e copertura mediatica che una caratteristica della tecnologia stessa. Il mio dizionario dice che l' hype è "pubblicità o promozione stravagante o intensiva". Definisce la pubblicità come "l'avviso o l'attenzione data a qualcuno o qualcosa dai media". Media è un termine collettivo per i vari canali di comunicazione di massa.

2. Se si accetta il punto precedente, ne consegue che il ciclo di hype si applica solo quando il supporto copre una determinata tecnologia.

3. Non è affatto chiaro che il ciclo di hype si applichi a tutte le tecnologie. Le riviste scientifiche sono piene di resoconti di progressi che non vengono mai notati dai media mainstream. Senza copertura mediatica, è meno probabile che le aspettative vengano gonfiate e si possa evitare la depressione della delusione.

4. I sistemi di controllo della versione distribuita non sono tanto una nuova idea quanto un perfezionamento di una vecchia. È un tratto definirli una "tecnologia emergente" del tipo che il ciclo dell'hype dovrebbe prevedere.

Prima di iniziare a creare un caso in cui DVCS si adatta a un grafico del ciclo di hype, è necessario creare un caso in cui il controllo della versione distribuita è soggetto al ciclo di hype. Il controllo della versione distribuita come "tecnologia" ottiene copertura mediatica? Ci sono ora, o ci sono mai state, aspettative gonfiate per il controllo della versione distribuita? È probabile che gli utenti DVCS rimarranno delusi quando i prodotti DVCS non soddisfano le aspettative?

Mi sembra più probabile che il controllo della versione distribuita sia solo un miglioramento su una categoria di prodotti esistente, così come SVN è stato un miglioramento su CVS. Se dovessi tracciare un grafico del tasso di adozione di SVN, non penso che otterrai una trama che assomigli al ciclo di hype; invece, si otterrebbe un complotto che aumenta costantemente fino al plateau del dominio del mercato, seguito da un lungo e lento declino man mano che i sistemi distribuiti come "git" guadagnano popolarità.

Se hai davvero bisogno di una risposta sul ciclo di campagna pubblicitaria, suggerirei che DVCS si è unito al gioco alla fine di un periodo di disillusione / frustrazione con i sistemi di controllo della versione non distribuiti e ha scalato la pendenza dell'illuminazione all'aumentare del tasso di adozione.

Invece di fare affidamento sul ciclo di hype per il tuo argomento, suggerirei di concentrarsi sul tasso di adozione del controllo della versione distribuita e sui motivi di ciò. Ci sono molte prove aneddotiche che le persone stanno passando al DVCS perché funziona; d'altra parte, non ho sentito nessuno tornare a un sistema non distribuito perché erano delusi. Per ottenere alcuni dati concreti, potresti provare a parlare con una società di hosting come Beanstalk . Inoltre, prestare attenzione all'interoperabilità tra sistemi centralizzati e sistemi distribuiti. Ho sentito che 'git' gioca molto bene con SVN. I sistemi centralizzati continuano a funzionare abbastanza bene nel regno aziendale, sottolineando quindi il "gioca bene con"

Aggiornamento in risposta alla modifica dell'OP:

come potrei usare il ciclo di hype di Gartner per convincere il management che i DVCS sono pronti (o abbastanza pronti) [?]

Penso che ci siano alcuni approcci che potrebbero aiutare qui e tutti si basano su dati concreti:

Google Trends. Google ovviamente raccoglie una tonnellata di dati su ciò che è in rete e ciò che la gente cerca. Qualche giorno fa, ho cercato (ma non sono riuscito a trovare) prove del ciclo di hype rispetto al controllo della versione distribuita. http://trends.google.com/ afferma che non ci sono abbastanza dati per i termini dvcs o controllo della versione distribuita quando limito la regione agli Stati Uniti (e i risultati dvcs per il mondo non sembrano molto pertinenti o utili). La ricerca di termini più specifici era in qualche modo migliore, ma complicata dal fatto che nomi di prodotti come git e mercurial hanno altri significati (chi lo sapeva?). Il risultato per git mostra una tendenza che potrebbe essere dovuta in parte al sistema di controllo della versione:

Cercando di renderlo più specifico per il controllo della versione, ho provato il repository git :

Ancora una volta ... immaginando che se le persone adottano git dovrebbe esserci una tendenza crescente nella ricerca di aiuto con i comandi git, ho provato git pull (blu), git commit (rosso) e git rebase (oro):

L'ultimo grafico sembra fornire la migliore prova che le persone stanno adottando e usando git.

Ricerca Google.

Prova semplicemente a cercare termini come il controllo della versione distribuita e annota le date, diciamo, sui 25 migliori articoli che trovi. Traccia i risultati. La maggior parte dei migliori successi che ho trovato ha avuto date nell'intervallo 2007-2009. Se si applica il ciclo di hype e se puoi mostrare che la maggior parte della copertura mediatica è avvenuta 3-5 anni fa, sembra una prova abbastanza buona che siamo andati oltre il picco delle aspettative gonfiate.

Raccogli esempi di progetti che utilizzano DVCS.

Ci sono molti esempi nel mondo open source, inclusi alcuni grandi come Linux. (Linus Torvalds ha creato git per aiutare a gestire lo sviluppo di Linux.) Più utili saranno esempi di aziende che usano un DVCS. (Se c'è qualcosa che i gestori odiano di più rispetto all'adozione di una tecnologia troppo presto, è dietro i tempi.) L'hype è proprio questo: brusio per una tecnologia o un prodotto. Se riesci a trovare prove dell'adozione aziendale del DVCS, questo aiuterà a contrastare l'argomento "è solo un bel po 'di pubblicità" forse meglio di ogni altra cosa.

Ultimi suggerimenti:

• Sii specifico. La tua azienda non adotterà un'intera tecnologia: adotterai un prodotto specifico. Alcuni prodotti saranno sempre meno maturi di altri. Scegli due o tre noti prodotti DVCS e mostra come ognuno si adatterebbe al tuo processo di sviluppo. Ai manager piacciono le idee concrete meglio delle vaghe promesse, quindi analizzare la tecnologia in termini specifici le farà sentire più a loro agio.

• Non è tutto o niente. Qualsiasi progetto reale che utilizza un DVCS avrà ancora un repository centrale, quindi i timori di perdere il controllo dei gioielli della corona possono essere facilmente attenuati.

• Non è necessario rinunciare al sistema attuale. Alcuni strumenti, come git, possono giocare bene con i sistemi di controllo versione esistenti, come svn. Quindi puoi facilmente aggiungere DVCS al tuo processo di sviluppo senza rinunciare a nulla.

• Inizia in piccolo. A meno che tu non sia in una piccola azienda che ha un solo progetto, dovrebbe essere facile incorporare DVCS nel processo per uno o due dei tuoi progetti. Non devi prima saltare in testa, basta immergere un dito del piede.

In breve, identifica i punti di resistenza e affrontali nel modo più chiaro possibile.

argomento / prova di una fase particolare

Qualunque fase possa essere, deve essere quella che corrisponde al fatto che la tecnologia è in uso professionale da "più di 10 anni" , dal momento che VCS distribuito TeamWare è stato lì per più di questo: pdf Guida dell'utente di seguito indicata è datata luglio 2001 .

Per Wikipedia, la più grande distribuzione di TeamWare è stata all'interno di Sun stessa, dove (salvo alcune eccezioni) a un certo punto è stato l'unico VCS utilizzato - che rende migliaia gli sviluppatori che utilizzano lo strumento. TeamWare è stato utilizzato per gestire i più grandi alberi di sorgenti di Sun, inclusi quelli per il sistema operativo Solaris e Java .

L'articolo di Wikipedia fa riferimento a un messaggio Usenix di Evan Adams, che era il capo architettonico di TeamWare, in cui si afferma in particolare:

Nella primavera del 1991 abbiamo deciso di attuare il progetto TeamWare ...

TeamWare è un set di strumenti da riga di comando e GUI creati da diverse librerie comuni. Le librerie sono fornite dal gruppo TeamWare per l'uso da parte delle applicazioni TeamWare; non sono previsti per un uso più generale.

TeamWare è un prodotto di gestione del codice che incoraggia lo sviluppo parallelo e si basa su SCCS. Un utente crea una copia (bringover) di una gerarchia SCCS creando così una gerarchia personale. In questa gerarchia l'utente apporta e verifica le modifiche. Queste modifiche vengono quindi integrate (rimbalzo) nella gerarchia originale. Se la gerarchia di integrazione contiene modifiche che non sono nella gerarchia dell'utente, TeamWare rileva che vi sono state modifiche parallele e rifiuta l'integrazione. Pertanto, gli utenti devono incorporare le modifiche nella gerarchia di integrazione nella propria gerarchia prima dell'integrazione. TeamWare include anche l'utilità filemerge, un programma grafico di differenze a tre vie che consente agli utenti di unire le modifiche parallele. TeamWare tiene traccia sia delle modifiche ai file di origine (delta SCCS) sia della ridenominazione dei file ...

Se sei interessato, trova maggiori dettagli qui:

• "Il vecchio e la C" di Evan Adams
• "Manuale dell'utente di Sun WorkShop TeamWare" sul sito Oracle / Sun - pdf ^{luglio 2001} , html

^{Secondo il mio ricordo, CVS / SVN centralizzato allora aveva il vantaggio di poter funzionare su Windows e Linux, mentre TeamWare (SCCS) è stato bloccato nel filesystem Solaris (su Linux funziona più o meno, se si sapesse come hackerare bug "zero checksum" spuri).}

La mia risposta:

Penso che la risposta si trovi da qualche parte tra "Internet TV" e "Cloud Computing" sulla spalla crescente del "picco delle aspettative gonfiate" (anche se penso che entrambi si siano spostati in qualche modo rapidamente negli ultimi due anni).

Natura del ciclo pubblicitario:

A quanto ho capito, la progressione attraverso il ciclo di campagna pubblicitaria è caratterizzata da una consapevolezza in evoluzione sui pro e contro di una particolare tecnologia, piuttosto che da qualsiasi misura oggettiva di "maturità" (qualunque cosa significhi).

Prima di aver accumulato un insieme sufficientemente diversificato di esperienze per costruire opinioni equilibrate (e indipendenti ), le dinamiche della folla (naturalmente) dominano, con opinioni altamente correlate con poca diversità, sottigliezza o profondità di analisi.

Questo è vero nel "trogolo della delusione" come lo è nel "picco delle aspettative gonfiate"

Se la comunità dovesse produrre una vasta e diversificata gamma di opinioni diverse, con un'analisi approfondita su dove e quando è appropriato distribuire DVCS e dove e quando non lo è, allora possiamo dedurre che siamo nel "Plateau of Productivity" (O almeno in qualche modo su per il "Pendio dell'Illuminismo").

Se, d'altra parte, il discorso è focalizzato sulla superiorità (o in altro modo) di una tecnologia senza tener conto degli avvallamenti e delle pieghe del panorama competitivo su cui si regge, allora potremmo dedurre che siamo sul "Picco di Aspettative gonfiate "o il" trogolo della delusione ". Potremmo anche essere in entrambe le fasi contemporaneamente, se la comunità fosse divisa in campi da una guerra di fiamma.

:-)

Valutazione del DVCS secondo questi criteri:

Dall'analisi relativamente superficiale che ho visto finora nel discorso e dalla relativa assenza di commenti negativi, stimerei che stiamo attualmente salendo il "Picco delle aspettative gonfiate", con domande (come questa) che indicano che lì sono alcuni che stanno preparando la pendenza dall'altra parte.

Penso che un forte indicatore della maturità della tecnologia DVCS (dal punto di vista aziendale) sarà quando il dibattito si sposta dal chiedere semplicemente "Perché DVCS?" a "Come possiamo strutturare al meglio il nostro flusso di lavoro e i nostri processi attorno al DVCS per massimizzare i benefici per l'organizzazione?".

Da quello che ho visto, non siamo ancora tutti lì. (Sebbene alcuni dei nostri connazionali più sofisticati stiano aprendo la strada)

Il ruolo del ciclo Hype nel processo decisionale:

Il modello "Hype Cycle" è un modello di distorsione comportamentale e ci aiuta a comprendere il nostro stato mentale. Se siamo in grado di determinare che una tecnologia è sostenuta da altri, ciò potrebbe influire sulla nostra posizione mentale e (a rischio di qualche ripensamento) potremmo dover compensare di conseguenza e forzarci a comportarci razionalmente nella scelta dei nostri criteri di selezione.

Criteri di selezione:

Inutile dire che le scelte dei criteri di selezione dipendono fortemente dal contesto.

Personalmente farei (come una sorta di esercizio di brainstorming) una breve analisi SWOT (15 minuti) di ogni opzione che stai prendendo in considerazione, insieme a (seriamente) un'analisi PEST della situazione per assicurarti di portare più ampio (non tecnologico) fattori nella tua analisi.

SWOT per VCS distribuito

Punti di forza:

• Flessibilità: maggiore libertà nella scelta di diversi flussi di lavoro.
• Migliori prestazioni su connessioni di rete a bassa larghezza di banda / alta latenza - migliori per team distribuiti e lavoratori fuori sede.
• Funzionalità di unione più sofisticate, che consentono di ramificarsi più spesso. (Non sono sicuro che questa sia una buona cosa).
• Il codice sorgente viene "sottoposto a backup" su ogni macchina degli sviluppatori. (piuttosto fasullo, questo, in quanto potrebbe interferire con un'adeguata pianificazione del ripristino di emergenza)

Punti di debolezza:

• Flessibilità: poiché abbiamo più libertà nella scelta di diversi flussi di lavoro, dobbiamo fare un lavoro aggiuntivo per definire quale flusso di lavoro stiamo usando e per applicarlo.
• Complessità e difficoltà concettuali (specialmente per i membri del team di sviluppatori non software).

Opportunità:

• Forse la flessibilità può essere utilizzata per progettare un flusso di lavoro più adatto alle esigenze aziendali?

Minacce:

• Forse passeremo così tanto tempo a riprogettare il nostro flusso di lavoro da perdere la concentrazione sul nostro prodotto principale?
• Può essere difficile convincere alcune persone a usare anche strumenti semplici, specialmente se non credono di essere necessari o altrimenti non sono motivati.

SWOT per VCS centralizzato

Punti di forza:

• Fornisce un canale di comunicazione implicito in banda per l'organizzazione e il processo aziendale.
• Limita i possibili flussi di lavoro a un sottoinsieme (in molti casi ragionevole).
• Semplifica la configurazione di CI e altri strumenti di automazione dello sviluppo.
• (Specifico per SVN) Supporta enormi repository.
• (Specifico per SVN) Molto stabile, utilizzato da molte grandi organizzazioni conservatrici.
• Politicamente più accettabile in un'organizzazione di comando e controllo dall'alto verso il basso?

Punti di debolezza:

• Inflessibile.
• Scarse prestazioni su connessioni a bassa larghezza di banda / alta latenza, rendendo più difficile l'utilizzo per team distribuiti e lavoratori fuori sede (soprattutto se il repository diventa grande)

Opportunità:

• Forse possiamo usare la natura monolitica del repository per aiutare gli sviluppatori a navigare nel prodotto e riutilizzare il codice dell'altro?

Minacce:

• Se il progetto diventa improvvisamente iper-importante e dobbiamo coinvolgere altri sviluppatori che lavorano su altri siti, possono effettivamente lavorare con un repository SVN ospitato (per loro) fuori sede?
• Se l'insieme di sviluppatori diventa così grande che diventa difficile coordinarli, il singolo repository centralizzato diventerà un collo di bottiglia? (Possiamo aggirare questo in qualsiasi altro modo?)

Conclusione:

Quale VCS usare dipende dalle circostanze individuali. Per molte delle situazioni in cui ho lavorato, un DVCS con un flusso di lavoro centralizzato avrebbe funzionato perfettamente, ma avrei dovuto giustificare il tempo e gli sforzi per costruire un meccanismo per supportare e applicare il flusso di lavoro, che sarebbe stato (ancora è difficile.

In definitiva, penso che la discussione dovrebbe essere incentrata sulla domanda: quale flusso di lavoro si adatta meglio alla nostra attività? Lo strumento migliore da usare dovrebbe seguire naturalmente dalla risposta a quella domanda.