Onde os sistemas de controle de versão distribuídos podem estar atualmente no ciclo de hype do Gartner? [fechadas]

Edit : Dada a recente redução de votos (+ 8 / -6 neste momento), ficou claro para mim que o ciclo de vida do Gartner é uma métrica tendenciosa da perspectiva de um programador. Isso é parte de um artigo que vou apresentar à gerência , e os tipos de gerência fazem parte do público da Gartner.

Dando exposição e entusiasmo ao DVCS (que "poderia" ser considerado um hype, ou pelo menos atacado como tal ), pense na seguinte pergunta ao ler este: "como eu poderia usar o ciclo de hype do Gartner para convencer o gerenciamento de que os DVCSs estão prontos (ou pronto o suficiente) para nós, e que não é apenas hype "

Perguntar se DVCSs é hype não seria construtivo, o ciclo de hype do Gartner é um instrumento mais objetivo do que apenas perguntar isso (mesmo que este instrumento seja considerado tendencioso). Se você conhece outro instrumento, mencione-o.

Edit # 2 : Concordo que o Ciclo de Vida do Gartner não é para todas as tecnologias, mas considero que ele pode ter gerado bastante agitação para ser considerado hype por algumas pessoas; portanto, talvez mereça ser pelo menos avaliado / ponderado como tal, usando este instrumento no para provar / refutar em qualquer grau. Eu sou um defensor do DVCS, BTW.

Edit # 3 : Obrigado por suas respostas. Bounty vai a Caleb por responder à minha pergunta com detalhes e conselhos práticos. A resposta aceita é enviada ao philosodad por fornecer outro instrumento útil e responder além da minha pergunta.

Estou pesquisando um artigo técnico que estou escrevendo a favor da adoção do DVCS na empresa e me deparei com o conceito de prova social . Quero provar que a prova social da adoção do DVCS não é necessariamente um culto à carga e, ao realizar pesquisas adicionais, deparei-me agora com o ciclo de hype do Gartner, que descreve a maturidade da tecnologia em 5 fases.

Minha pergunta é: o que poderia ser um indicador da localização atual dos sistemas de controle de versão distribuídos (refiro-me a git, mercurial, bazar etc. em geral) em uma fase específica do ciclo de hype? ... em outra (menos complicada) Em outras palavras, você diria que atualmente as expectativas dos DVCSs são a) partida, b) infladas, c) decrescentes (desilusão), d) crescentes (iluminação) ou e) estabilizadas (maduras) e (mais importante) por quê ?

Sei que é uma pergunta difícil e há subjetividade envolvida, mas concederei a resposta (e o cookie tradicional) ao argumento / evidência mais clara para uma fase específica.

O ciclo de hype mede a quantidade de notícias / buzz que uma determinada coisa gera, não o uso real da coisa ou seu valor real de produtividade. Então ... eu diria que, dessa perspectiva, o DVCS está atingindo um pico no seu ciclo de notícias. Na verdade, muitas pessoas o estão usando e incentivando outras pessoas a usá-lo, pois ele está recebendo muita atenção no mundo da tecnologia. Uma vez que a adoção seja mais difundida, espero que as notícias / buzz desapareçam um pouco quando algo novo e brilhante aparecer, e depois subam novamente quando as pessoas começarem a entender os sistemas mais completamente.

Uma maneira de analisar o ciclo de hype é analisar o número de novos adotantes. O número de novos adotantes de uma tecnologia tende a seguir a mesma forma exata de curva que o ciclo de hype. Faz sentido que o zumbido em torno de uma determinada nova tecnologia cresça rapidamente à medida que a tecnologia ganha um grande número de novos adotantes. Os primeiros adotantes espalharam a inovação, e os adotantes médios geraram o burburinho.

A agitação durante a rápida adoção de uma inovação é necessariamente mal informada. Se muitas pessoas sabem de algo, mas não sabem, elas terão expectativas diferentes e possivelmente maiores do que usuários experientes. Então é daí que vem o hype.

O burburinho após o pico da taxa de adoção diminuirá ... em parte porque antes, expectativas irreais não valeram a pena (o DVCS tornará você mais produtivo, talvez, mas não resolverá todos os seus problemas) e em parte porque outra coisa está passando por um período de adoção rápida e está ocupando toda a atenção. Hype é inconstante.

Mas, em algum momento, você começa a obter uma taxa bastante constante de novos usuários, a inovação se tornou a norma e os novos usuários querem saber como usar essa coisa que eles já decidiram que precisam usar. Então, o burburinho da inovação é sobre o que as pessoas realmente estão fazendo com ela agora que estão usando, e não o que poderiam fazer se estivessem usando.

Portanto, se você pegar a curva de hype e colocá-la ao lado da curva S das taxas de adoção (consulte "Difusão de inovações" de Everett Rogers)), você esperaria que o hype atingisse o pico em que a curva S é mais íngreme, conforme a curva S muda direção e suba novamente à medida que a inovação atinge sua saturação total do mercado.

O DVCS está em um período de rápida adoção, portanto, provavelmente estamos em algum ponto do pico do ciclo de hype.

Não pretendo ser um especialista no assunto de ciclos de hype, mas vou fazer algumas observações:

1. O ciclo de hype parece ser mais um produto de expectativas e cobertura da mídia do que uma característica da própria tecnologia. Meu dicionário diz que o hype é "publicidade ou promoção extravagante ou intensa". Ele define publicidade como "o aviso ou a atenção dada a alguém ou alguma coisa pela mídia". Mídia é um termo coletivo para os vários canais de comunicação de massa.

2. Se você aceitar o ponto anterior, segue-se que o ciclo de hype se aplica somente quando a mídia cobre uma determinada tecnologia.

3. Não está claro que o ciclo de hype se aplique a todas as tecnologias. As revistas científicas são preenchidas com relatos de avanços que nunca são notados pela grande mídia. Sem a cobertura da mídia, é menos provável que as expectativas sejam infladas e a calha da desilusão pode ser evitada.

4. Os sistemas de controle de versão distribuído não são tanto uma idéia nova quanto um refinamento de uma antiga. É um exagero chamá-los de "tecnologia emergente" do tipo que o ciclo de hype deve prever.

Antes de começar a construir um caso em que o DVCS se encaixa em um gráfico de ciclo de hype, é necessário criar um caso em que o controle de versão distribuído esteja sujeito ao ciclo de hype. O controle de versão distribuído como uma "tecnologia" obtém cobertura da mídia? Existem agora, ou já houve, expectativas infladas para o controle de versão distribuído? É provável que os usuários do DVCS fiquem desiludidos quando os produtos DVCS não atendem às expectativas?

Parece-me mais provável que o controle de versão distribuído seja apenas uma melhoria em uma categoria de produtos existente, assim como o SVN foi uma melhoria no CVS. Se você planejasse a taxa de adoção do SVN, não acho que obteria um gráfico parecido com o ciclo de hype; em vez disso, você obteria uma trama que aumenta constantemente até o platô de domínio do mercado, seguida por um longo e lento declínio à medida que sistemas distribuídos como o 'git' ganham popularidade.

Se você realmente precisa de uma resposta do ciclo de hype, eu sugiro que o DVCS se junte ao jogo no final de um período de desilusão / frustração com sistemas de controle de versão não distribuídos e suba a ladeira da iluminação à medida que a taxa de adoção aumenta.

Em vez de confiar no ciclo de hype para seu argumento, sugiro focar na taxa de adoção do controle de versão distribuído e nos motivos. Há muitas evidências anedóticas de que as pessoas estão mudando para o DVCS porque funciona; por outro lado, nunca ouvi falar de alguém voltar para um sistema não distribuído porque ficou desapontado. Para obter alguns dados concretos, tente conversar com uma empresa de hospedagem como o Beanstalk . Além disso, preste atenção à interoperabilidade entre sistemas centralizados e sistemas distribuídos. Ouvi dizer que 'git' joga muito bem com o SVN. Os sistemas centralizados continuam funcionando muito bem no âmbito corporativo, enfatizando o "funciona bem com"

Atualização em resposta à edição do OP:

como eu poderia usar o ciclo de hype do Gartner para convencer o gerenciamento de que os DVCSs estão prontos (ou prontos o suficiente) [?]

Eu acho que existem algumas abordagens que podem ajudar aqui, e todas dependem de dados concretos:

Tendências do Google. O Google obviamente coleta uma tonelada de dados sobre o que está na rede e o que as pessoas pesquisam. Alguns dias atrás, procurei (mas não consegui encontrar) evidências do controle de versão distribuído do hype cycle wrt. http://trends.google.com/ diz que não há dados suficientes para os termos dvcs ou controle de versão distribuído quando limito a região aos EUA (e os resultados de dvcs para o mundo não parecem muito relevantes ou úteis). Procurar termos mais específicos era um pouco melhor, mas complicado pelo fato de nomes de produtos como git e mercurial terem outros significados (quem sabia?). O resultado para git mostra uma tendência que pode ser devida em parte ao sistema de controle de versão:

Tentando tornar isso mais específico ao controle de versão, tentei o repositório git :

Mais uma ... imaginando que, se as pessoas estão adotando o git, deve haver uma tendência crescente em procurar ajuda com os comandos git, tentei o git pull (azul), o git commit (vermelho) e o git rebase (gold):

Esse último gráfico parece fornecer a melhor evidência de que as pessoas estão adotando e usando o git.

Pesquisa do Google.

Tente simplesmente procurar termos como controle de versão distribuído e observe as datas nos, por exemplo, os 25 principais artigos encontrados. Plote os resultados. A maioria dos hits principais que encontrei tinha datas no período de 2007-2009. Se o ciclo de hype se aplicar, e se você puder mostrar que a maior parte da cobertura da mídia ocorreu há 3-5 anos, isso parece uma evidência muito boa de que fomos além do pico das expectativas infladas.

Colete exemplos de projetos que usam o DVCS.

Existem muitos exemplos no mundo do código aberto, incluindo alguns grandes como o Linux. (Linus Torvalds criou o git para ajudar a gerenciar o desenvolvimento do Linux.) Mais útil para você serão exemplos de empresas que usam um DVCS. (Se há algo que os gerentes odeiam mais do que adotar uma tecnologia muito cedo, isso está atrasando os tempos.) O hype é exatamente isso - fala sobre uma tecnologia ou produto. Se você puder encontrar evidências da adoção corporativa do DVCS, isso ajudará a combater o argumento "é muita publicidade", talvez melhor do que qualquer outra coisa.

Últimas dicas:

• Seja específico. Sua empresa não adotará uma tecnologia inteira - você adotará um produto específico. Alguns produtos sempre serão menos maduros que outros. Escolha dois ou três produtos DVCS conhecidos e mostre como cada um deles se encaixaria no seu processo de desenvolvimento. Os gerentes gostam mais de idéias concretas do que de vagas promessas; portanto, analisar a tecnologia em termos específicos fará com que se sintam mais confortáveis.

• Não é tudo ou nada. Qualquer projeto real usando um DVCS ainda terá um repositório central, portanto, o medo de perder o controle das joias da coroa pode ser facilmente atenuado.

• Não há necessidade de desistir do seu sistema atual. Algumas ferramentas, como o git, podem funcionar bem com os sistemas de controle de versão existentes, como o svn. Assim, você pode adicionar facilmente o DVCS ao seu processo de desenvolvimento sem abrir mão de nada.

• Comece pequeno. A menos que você esteja em uma pequena empresa que tenha apenas um projeto, deve ser fácil incorporar o DVCS ao processo para apenas um ou dois de seus projetos. Você não precisa pular de cabeça primeiro - apenas mergulhe o dedo do pé.

Em resumo, identifique os pontos de resistência e resolva-os da maneira mais clara possível.

argumento / evidência de uma fase específica

Qualquer que seja a fase, ela deve coincidir com o fato de que a tecnologia está em uso profissional por "mais de 10 anos" , uma vez que o VCS TeamWare distribuído está lá há mais do que isso: pdf O Guia do usuário abaixo, datado de julho de 2001 .

Segundo a Wikipedia, a maior implantação do TeamWare ocorreu dentro da própria Sun , onde (exceto algumas exceções) em um ponto, foi o único VCS usado - que faz com que milhares de desenvolvedores usem a ferramenta. O TeamWare foi usado para gerenciar as maiores árvores de origem da Sun, incluindo as do sistema operacional Solaris e do sistema Java .

O artigo da Wikipedia refere-se a uma mensagem da Usenix de Evan Adams, que era o líder de arquitetura do TeamWare, que afirma em particular:

Na primavera de 1991 , decidimos implementar o projeto TeamWare ...

O TeamWare é um conjunto de ferramentas de linha de comando e GUI criadas a partir de várias bibliotecas comuns. As bibliotecas são fornecidas pelo grupo TeamWare para uso pelos aplicativos TeamWare; eles não são fornecidos para uso mais geral.

O TeamWare é um produto de gerenciamento de código que incentiva o desenvolvimento paralelo e é construído sobre o SCCS. Um usuário faz uma cópia (transição) de uma hierarquia do SCCS, criando assim uma hierarquia pessoal. Nesta hierarquia, o usuário faz e testa alterações. Essas alterações são então integradas (recuo) na hierarquia original. Se a hierarquia de integração contiver alterações que não estão na hierarquia do usuário, o TeamWare detectará que houve alterações paralelas e recusará a integração. Portanto, os usuários devem incorporar alterações na hierarquia de integração em sua própria hierarquia antes de integrar. O TeamWare também inclui o utilitário filemerge, um programa gráfico de diferenças de três vias que permite aos usuários mesclar alterações paralelas. O TeamWare rastreia as alterações no arquivo de origem (deltas do SCCS) e renomeia de arquivo ...

Se você estiver interessado, encontre mais detalhes aqui:

• "O Velho e o C", de Evan Adams
• "Guia do usuário do Sun WorkShop TeamWare" no site Oracle / Sun - pdf ^{julho de 2001} , html

^{De acordo com minha lembrança, o CVS / SVN centralizado naquela época tinha a vantagem de ser capaz de executar no Windows e Linux, enquanto o TeamWare (SCCS) estava bloqueado no sistema de arquivos Solaris (no Linux, ele é executado mais ou menos, se alguém soubesse invadir erros espúrios de "soma de verificação zero").}

Minha resposta:

Eu acho que a resposta está em algum lugar entre "Internet TV" e "Cloud Computing", no ombro crescente do "Pico das Expectativas Infladas" (embora eu ache que ambos tenham evoluído um pouco rapidamente nos últimos dois anos).

Natureza do ciclo de campanha publicitária:

Pelo que entendi, a progressão no ciclo do hype é caracterizada por uma consciência em evolução sobre os prós e contras de uma determinada tecnologia, e não por qualquer medida objetiva de "maturidade" (o que isso significa).

Antes de acumularmos um conjunto suficientemente diversificado de experiências para criar opiniões equilibradas (e independentes ), a dinâmica da multidão (naturalmente) domina, com opiniões altamente correlacionadas com pouca diversidade, sutileza ou profundidade de análise.

Isso é verdade tanto no "vale da desilusão" quanto no "pico das expectativas infladas"

Se a comunidade produzir uma ampla e diversificada gama de opiniões diferentes, com uma análise aprofundada sobre onde e quando é apropriado implantar o DVCS e onde e quando não é, podemos inferir que estamos no "Platô da Produtividade" (Ou pelo menos de alguma maneira subindo a "Encosta da Iluminação").

Se, por outro lado, o discurso estiver focado na superioridade (ou não) de uma tecnologia, sem levar em conta as quedas e as dobras da paisagem competitiva em que está, então poderemos inferir que estamos no "Pico da Expectativas infladas "ou" Calha da desilusão ". Poderíamos até estar nas duas fases ao mesmo tempo, se a comunidade for dividida em campos por uma guerra de chamas.

:-)

Avaliação do DVCS de acordo com estes critérios:

A partir da análise relativamente superficial que vi no discurso até agora e a relativa ausência de comentários negativos, eu estimaria que atualmente estamos subindo o "Pico das Expectativas Infladas", com perguntas (como esta) indicando que existe alguns estão preparando a encosta do outro lado.

Eu acho que um forte indicador da maturidade da tecnologia DVCS (do ponto de vista corporativo) será quando o debate deixar de perguntar simplesmente "Por que DVCS?" para "Como podemos estruturar melhor nosso fluxo de trabalho e processos em torno do DVCS para maximizar os benefícios para a organização?".

Pelo que vi, ainda não estamos todos lá. (Embora alguns de nossos compatriotas mais sofisticados estejam liderando o caminho)

O papel do Ciclo Hype na tomada de decisão:

O modelo "Ciclo do Hype" é um modelo de viés comportamental e nos ajuda a entender nosso próprio estado mental. Se pudermos determinar que uma tecnologia é exagerada por outras pessoas, isso pode afetar nossa própria postura mental e (com o risco de pensar duas vezes), podemos precisar compensar adequadamente e nos forçar a agir racionalmente na escolha de nossos critérios de seleção.

Critério de seleção:

Escusado será dizer que as opções de critérios de seleção são extremamente dependentes do contexto.

Pessoalmente, eu faria (como uma espécie de exercício de brainstorming) uma análise SWOT curta (15 minutos) de cada opção que você está considerando, juntamente com (seriamente) uma análise PEST da situação para garantir que você traga informações mais amplas (não tecnológicas) fatores em sua análise.

SWOT para VCS distribuídos

Forças:

• Flexibilidade - mais liberdade para escolher diferentes fluxos de trabalho.
• Melhor desempenho em conexões de rede de baixa largura de banda / alta latência - melhor para equipes distribuídas e trabalhadores externos.
• Funcionalidade de mesclagem mais sofisticada, permitindo ramificar com mais frequência. (Não tenho certeza se isso é uma coisa boa).
• O código-fonte é "copiado" em cada máquina de desenvolvedores. (muito falso, este, pois pode interferir no planejamento adequado da recuperação de desastres)

Fraquezas:

• Flexibilidade - Como temos mais liberdade para escolher diferentes fluxos de trabalho, precisamos fazer um trabalho adicional para definir qual fluxo de trabalho estamos usando e para aplicá-lo.
• Complexidade e dificuldade conceitual (especialmente para membros da equipe que não são desenvolvedores de software).

Oportunidades:

• Talvez a flexibilidade possa ser utilizada para projetar um fluxo de trabalho mais adequado às necessidades da empresa?

Ameaças:

• Talvez passemos tanto tempo reestruturando nosso fluxo de trabalho que perderemos o foco em nosso produto principal?
• Pode ser difícil fazer com que algumas pessoas usem ferramentas simples, especialmente se elas não acreditam que são necessárias ou não estão motivadas.

SWOT para VCS centralizados

Forças:

• Fornece um canal de comunicação implícita dentro da banda para organização e processo de negócios.
• Restringe possíveis fluxos de trabalho a um subconjunto (em muitos casos, razoável).
• Facilita a configuração do IC e de outras ferramentas de automação de desenvolvimento.
• (Específico para SVN) Suporta repositórios enormes.
• (Específico para SVN) Muito estável, usado por muitas organizações grandes e conservadoras.
• Politicamente mais aceitável em uma organização de comando e controle de cima para baixo?

Fraquezas:

• Inflexível.
• Baixo desempenho em conexões de baixa largura de banda / alta latência, dificultando o uso para equipes distribuídas e trabalhadores externos (especialmente se o repositório ficar grande)

Oportunidades:

• Talvez possamos usar a natureza monolítica do repositório para ajudar os desenvolvedores a navegar no produto e reutilizar mais o código um do outro?

Ameaças:

• Se o projeto se tornar subitamente importante e precisarmos trazer desenvolvedores adicionais trabalhando em outros sites, eles podem trabalhar efetivamente com um repositório SVN hospedado (para eles) fora do local?
• Se o conjunto de desenvolvedores crescer tanto que a coordenação deles se tornar difícil, o repositório centralizado único se tornará um gargalo? (Podemos contornar isso de outra maneira?)

Conclusão:

O VCS a ser utilizado depende das circunstâncias individuais. Para muitas das situações em que trabalhei, um DVCS com um fluxo de trabalho centralizado teria se saído bem, mas eu teria que justificar o tempo e o esforço para criar um mecanismo para dar suporte e reforçar o fluxo de trabalho, o que teria sido (ainda é difícil.

Por fim, acho que a discussão deve se concentrar na pergunta: qual fluxo de trabalho melhor se adequa aos nossos negócios? A melhor ferramenta a ser usada deve seguir naturalmente da resposta a essa pergunta.