¿Dónde podrían estar actualmente los sistemas de control de versiones distribuidas en el ciclo exagerado de Gartner? [cerrado]

Editar : Dada la reciente votación negativa (+ 8 / -6 en este punto) me quedó claro que el ciclo de vida de Gartner es una métrica sesgada desde la perspectiva de un programador. Esto es algo que forma parte de un documento que voy a presentar a la gerencia , y los tipos de gestión son parte de la audiencia de Gartner.

Dando exposición y entusiasmo a DVCS (que "podría" considerarse exagerado, o al menos atacado como tal ), piense en la siguiente pregunta al leer esta: "¿cómo podría usar el ciclo de exageración de Gartner para convencer a la gerencia de que los DVCS están listos (o listo para nosotros) y que no es solo una exageración "

Solo preguntar si DVCSs es bombo no sería constructivo, el ciclo de bombo de Gartner es un instrumento más objetivo que solo preguntar eso (incluso si este instrumento se considera sesgado). Si conoce algún otro instrumento, por favor, menciónelo.

Edición n. ° 2 : estoy de acuerdo en que el ciclo de vida de Gartner no es para todas las tecnologías, pero considero que puede haber generado suficiente expectación para que algunos lo consideren una exageración, por lo que tal vez merezca ser evaluado / meditado como tal al usar este instrumento en para probarlo / refutarlo en cualquier grado. Soy un defensor de DVCS, por cierto.

Edición n. ° 3 : Gracias por sus respuestas. Bounty acude a Caleb por responder mi pregunta con detalles y consejos prácticos. La respuesta aceptada va a philosodad por proporcionar otro instrumento útil y responder más allá de mi pregunta.

Estoy investigando para un documento técnico que estoy escribiendo a favor de la adopción de DVCS en la empresa y me topé con el concepto de prueba social . Quiero demostrar que la prueba social de la adopción de DVCS no es necesariamente culto a la carga y, al hacer más investigaciones, ahora me topé con el ciclo exagerado de Gartner que describe la madurez tecnológica en 5 fases.

Mi pregunta es: ¿qué podría ser un indicador de la ubicación actual de los sistemas de control de versiones distribuidas (me refiero a git, mercurial, bazar, etc. en general) en una fase particular del ciclo de bombo? ... en otro (menos complicado) Es decir, ¿diría que las expectativas actuales de los DVCS son a) comenzar, b) inflar, c) disminuir (desilusión), d) aumentar (iluminación) oe) estabilizarse (madurar) y (más importante) ¿por qué ?

Sé que es una pregunta difícil y hay subjetividad involucrada, pero concederé la respuesta (y la cookie tradicional) al argumento / evidencia más claro para una fase en particular.

El ciclo de exageración mide la cantidad de noticias / rumores que genera una cosa en particular, no el uso real de la cosa o su valor de productividad real. Entonces ... diría que desde esa perspectiva, DVCS está alcanzando un pico en su ciclo de noticias. En realidad, suficientes personas lo usan y alientan a otras personas a que lo usen, ya que está recibiendo mucha atención en el mundo de la tecnología. Una vez que la adopción esté más extendida, espero que las noticias / rumores se desvanezcan un poco cuando aparezca algo nuevo y brillante, y luego aumenten nuevamente a medida que las personas comiencen a comprender los sistemas más completamente.

Una forma de ver el ciclo de exageración es observar la cantidad de nuevos adoptantes. El número de nuevos adoptantes de una tecnología tiende a seguir la misma forma de curva exacta que el ciclo de bombo. Tiene sentido que el rumor sobre una nueva tecnología dada vaya a crecer rápidamente a medida que la tecnología gane un gran número de nuevos adoptantes. Los primeros en adoptar difundieron la innovación, y los que adoptaron en el medio generaron el rumor.

El zumbido durante la rápida adopción de una innovación está necesariamente mal informado. Si hay muchas personas que saben de algo pero no lo saben, tendrán expectativas diferentes y posiblemente mayores que los usuarios experimentados. De ahí viene el bombo publicitario.

El zumbido después de que la tasa de adopción haya alcanzado su punto máximo va a caer ... en parte porque antes, las expectativas poco realistas no han valido la pena (DVCS lo hará más productivo, tal vez, pero no solucionará todos sus problemas) y en parte porque algo más está pasando por un período de adopción rápida y está ocupando toda la mente compartida. El bombo es inconstante.

Pero en algún momento, comienza a obtener una tasa bastante constante de nuevos adoptantes, la innovación se ha convertido en la norma, y ​​los nuevos adoptantes quieren saber cómo usar esta cosa que ya han decidido que necesitan usar. Entonces, el zumbido en torno a la innovación tiene que ver con lo que las personas realmente están haciendo con él ahora que lo están usando, en lugar de lo que podrían hacer con él si lo estuvieran usando.

Entonces, si tomó la curva de exageración y la colocó junto a la curva S de las tasas de adopción (vea "Difusión de innovaciones" de Everett Rogers), esperaría que la exageración alcanzara su punto máximo cuando la curva S es más pronunciada, a medida que la curva S cambia dirección, y subir de nuevo a medida que la innovación alcanza su plena saturación del mercado.

DVCS se encuentra en un período de rápida adopción, por lo que probablemente estamos en algún lugar alrededor del pico del ciclo de bombo.

No pretendo ser un experto en el tema de los ciclos de bombo, pero ofreceré algunas observaciones:

1. El ciclo exagerado parece ser más un producto de las expectativas y la cobertura de los medios que una característica de la tecnología misma. Mi diccionario dice que exagerar es "publicidad o promoción extravagante o intensiva". Define la publicidad como "el aviso o atención prestada a alguien o algo por los medios de comunicación". Medios es un término colectivo para los diversos canales de comunicación de masas.

2. Si acepta el punto anterior, se deduce que el ciclo de exageración se aplica solo cuando los medios cubren una tecnología determinada.

3. No está nada claro que el ciclo de exageración se aplique a todas las tecnologías. Las revistas científicas están llenas de informes de avances que los principales medios de comunicación nunca notan. Sin la cobertura de los medios, es menos probable que se inflen las expectativas y se puede evitar la depresión.

4. Los sistemas de control de versiones distribuidos no son tanto una idea nueva como un refinamiento de una vieja. Es difícil llamarlos una "tecnología emergente" del tipo que se supone que predice el ciclo de exageración.

Antes de comenzar a construir un caso para que los DVCS se ajusten a un gráfico de ciclo de bombo, debe construir un caso en el que el control de versión distribuido esté sujeto al ciclo de bombo. ¿El control de versiones distribuidas como "tecnología" obtiene cobertura de los medios? ¿Existen ahora, o ha habido alguna vez, expectativas infladas para el control de versión distribuido? ¿Es probable que los usuarios de DVCS se desilusionen cuando los productos DVCS no cumplan con las expectativas?

Me parece más probable que el control de versiones distribuidas sea solo una mejora en una categoría existente de productos, al igual que SVN fue una mejora en CVS. Si tuviera que trazar la tasa de adopción de SVN, no creo que obtenga una trama que se parezca al ciclo de exageración; en su lugar, obtendría una trama que aumentará constantemente hasta la meseta del dominio del mercado, seguido de una disminución lenta y prolongada a medida que los sistemas distribuidos como 'git' ganen popularidad.

Si realmente necesita una respuesta de ciclo exagerado, sugeriría que DVCS se uniera al juego al final de un período de desilusión / frustración con los sistemas de control de versiones no distribuidos y ha estado subiendo la cuesta de la iluminación a medida que aumenta la tasa de adopción.

En lugar de confiar en el ciclo de exageración para su argumento, sugeriría centrarse en la tasa de adopción del control de versión distribuido y las razones para ello. Hay mucha evidencia anecdótica de que las personas se están cambiando a DVCS porque funciona; por el contrario, no he oído hablar de conmutación a nadie volver a un sistema no distribuido, ya que se sintieron decepcionados. Para obtener algunos datos duros, puede intentar hablar con una empresa de alojamiento como Beanstalk . Además, preste atención a la interoperabilidad entre sistemas centralizados y sistemas distribuidos. Escuché que 'git' juega muy bien con SVN. Los sistemas centralizados continúan funcionando bastante bien en el ámbito corporativo, por lo que enfatizar "juega muy bien con"

Actualización en respuesta a la edición de OP:

¿Cómo podría usar el ciclo de bombo de Gartner para convencer a la gerencia de que los DVCS están listos (o lo suficientemente listos) [?]

Creo que hay algunos enfoques que podrían ayudar aquí, y todos se basan en datos duros:

Tendencias de Google. Obviamente, Google recopila un montón de datos sobre lo que hay en la red y lo que las personas buscan. Hace unos días, busqué (pero no pude encontrar) evidencia del control de versión distribuido wrt cycle wrt. http://trends.google.com/ dice que no hay suficientes datos para los términos dvcs o control de versión distribuido cuando limito la región a los EE. UU. (y los resultados de dvcs para el mundo no parecen muy relevantes o útiles). Buscar términos más específicos fue algo mejor, pero complicado por el hecho de que los nombres de productos como git y mercurial tienen otros significados (¿quién sabe?). El resultado para git muestra una tendencia que podría deberse en parte al sistema de control de versiones:

Intentando hacerlo más específico para el control de versiones, probé el repositorio de git :

Una más ... pensando que si la gente está adoptando git debería haber una tendencia creciente en la búsqueda de ayuda con los comandos de git, probé git pull (azul), git commit (rojo) y git rebase (oro):

Ese último gráfico parece proporcionar la mejor evidencia de que las personas están adoptando y usando git.

Búsqueda de Google.

Intente simplemente buscar términos como control de versión distribuido y anote las fechas en, digamos, los 25 artículos principales que encuentre. Trazar los resultados. La mayoría de los mejores éxitos que encontré tenían fechas en el rango 2007-2009. Si se aplica el ciclo de exageración, y si puede demostrar que la mayor parte de la cobertura de los medios ocurrió hace 3-5 años, parece una evidencia bastante buena de que hemos superado el pico de expectativas infladas.

Recopile ejemplos de proyectos que usan DVCS.

Hay muchos ejemplos en el mundo de código abierto, incluidos algunos grandes como Linux. (Linus Torvalds creó git para ayudar a administrar el desarrollo de Linux.) Más útiles para usted serán ejemplos de corporaciones que usan un DVCS. (Si hay algo que los gerentes odian más que adoptar una tecnología demasiado pronto, está quedando atrás). La exageración es solo eso: rumores sobre una tecnología o producto. Si puede encontrar evidencia de la adopción corporativa de DVCS, eso ayudará a contrarrestar el argumento de "es solo una gran exageración", tal vez mejor que cualquier otra cosa.

Últimos consejos:

• Se específico. Su empresa no va a adoptar una tecnología completa: adoptará un producto específico. Algunos productos siempre serán menos maduros que otros. Elija dos o tres productos DVCS conocidos y muestre cómo encajarían cada uno en su proceso de desarrollo. A los gerentes les gustan más las ideas concretas que las vagas promesas, por lo que analizar la tecnología en términos específicos los hará sentir más cómodos.

• No es todo o nada. Cualquier proyecto real que utilice un DVCS seguirá teniendo un depósito central, por lo que los temores sobre la pérdida del control de las joyas de la corona se pueden mitigar fácilmente.

• No es necesario renunciar a su sistema actual. Algunas herramientas, como git, pueden funcionar bien con los sistemas de control de versiones existentes, como svn. Por lo tanto, puede agregar fácilmente DVCS a su proceso de desarrollo sin renunciar a nada.

• Empieza pequeño. A menos que esté en una empresa pequeña que solo tiene un proyecto, debería ser fácil incorporar DVCS en el proceso de solo uno o dos de sus proyectos. No tienes que saltar de cabeza primero, solo sumerge un dedo del pie.

En resumen, identifique los puntos de resistencia y enfóquelos tan claramente como pueda.

argumento / evidencia de una fase particular

Cualquiera que sea la fase, debe ser una que coincida con el hecho de que la tecnología está en uso profesional durante "más de 10 años" , ya que VCS TeamWare distribuido ha estado allí por más tiempo: la Guía del usuario en pdf que se menciona a continuación está fechada en julio de 2001 .

Según Wikipedia, la implementación más grande de TeamWare fue dentro del propio Sun , donde (salvo algunas excepciones) en un momento fue el único VCS utilizado, lo que hace que miles de desarrolladores utilicen la herramienta. TeamWare se ha utilizado para administrar los árboles de origen más grandes de Sun, incluidos los del sistema operativo Solaris y el sistema Java .

El artículo de Wikipedia se refiere a un mensaje de Usenix de Evan Adams, quien fue el jefe de arquitectura de TeamWare, que establece en particular:

En la primavera de 1991 decidimos implementar el proyecto TeamWare ...

TeamWare es un conjunto de herramientas de línea de comandos y GUI creadas a partir de varias bibliotecas comunes. Las bibliotecas son proporcionadas por el grupo TeamWare para uso de las aplicaciones TeamWare; No se proporcionan para un uso más general.

TeamWare es un producto de gestión de código que fomenta el desarrollo paralelo y está construido sobre SCCS. Un usuario realiza una copia (recuperación) de una jerarquía SCCS creando así una jerarquía personal. En esta jerarquía, el usuario realiza y prueba los cambios. Estos cambios se integran (devolución) en la jerarquía original. Si la jerarquía de integración contiene cambios que no están en la jerarquía del usuario, TeamWare detecta que ha habido cambios paralelos y rechaza la integración. Por lo tanto, los usuarios deben incorporar cambios en la jerarquía de integración en su propia jerarquía antes de la integración. TeamWare también incluye la utilidad filemerge, un programa gráfico de diferencias de tres vías que permite a los usuarios fusionar cambios paralelos. TeamWare rastrea los cambios en el archivo de origen (deltas de SCCS) y los cambios de nombre de archivos ...

Si está interesado, encuentre más detalles aquí:

• "El viejo y la C" de Evan Adams
• "Guía del usuario de Sun WorkShop TeamWare" en el sitio de Oracle / Sun - pdf ^{julio de 2001} , html

^{Según mi recuerdo, CVS / SVN centralizado en ese entonces tenía la ventaja de ser capaz de ejecutarse en Windows y Linux, mientras que TeamWare (SCCS) se ha bloqueado en el sistema de archivos Solaris (en Linux se ejecuta más o menos, si uno supiera cómo hackear errores espurios de "suma de comprobación cero").}

Mi respuesta:

Creo que la respuesta se encuentra en algún lugar entre "Internet TV" y "Cloud Computing" en el hombro ascendente del "Pico de las expectativas infladas" (aunque creo que ambos han avanzado un poco rápidamente en los últimos años).

Naturaleza del ciclo de bombo:

Según tengo entendido, la progresión a través del ciclo de bombo se caracteriza por una conciencia evolutiva sobre los pros y los contras de una tecnología en particular, más que por cualquier medida objetiva de "madurez" (lo que sea que eso signifique).

Antes de que hayamos acumulado un conjunto suficientemente diverso de experiencias para construir opiniones equilibradas (e independientes ), la dinámica de masas (naturalmente) prevalece, con opiniones altamente correlacionadas con poca diversidad, sutileza o profundidad de análisis.

Esto es tan cierto en el "Canal de la desilusión" como en el "Pico de las expectativas infladas"

Si la comunidad produjera una amplia y diversa gama de opiniones diferentes, con un análisis en profundidad sobre dónde y cuándo es apropiado implementar DVCS y dónde y cuándo no, entonces podemos inferir que estamos en la "Meseta de la Productividad" (O, al menos, un poco más arriba de la "Pendiente de la Iluminación").

Si, por otro lado, el discurso se centra en la superioridad (o no) de una tecnología sin tener en cuenta las caídas y pliegues del panorama competitivo en el que se encuentra, entonces podríamos inferir que estamos en el "Pico de Expectativas infladas "o el" valle de la desilusión ". Incluso podríamos estar en ambas fases al mismo tiempo, si la comunidad está dividida en campamentos por una guerra de llamas.

:-)

Evaluación de DVCS según estos criterios:

A partir del análisis relativamente superficial que he visto en el discurso hasta ahora, y la relativa ausencia de comentarios negativos, estimaría que actualmente estamos subiendo el "Pico de las expectativas infladas", con preguntas (como esta) que indican que hay Hay algunos que están preparando la pendiente hacia abajo en el otro lado.

Creo que un fuerte indicador de la madurez de la tecnología DVCS (desde el punto de vista corporativo) será cuando el debate pase de preguntar simplemente "¿Por qué DVCS?" a "¿Cómo podemos estructurar mejor nuestro flujo de trabajo y procesos en torno a DVCS para maximizar el beneficio para la organización?".

Por lo que he visto, todavía no estamos todos allí. (Aunque algunos de nuestros compatriotas más sofisticados están liderando el camino)

El papel del ciclo Hype en la toma de decisiones:

El modelo "Hype Cycle" es un modelo de sesgo conductual y nos ayuda a comprender nuestro propio estado mental. Si podemos determinar que una tecnología es promovida por otros, entonces eso puede afectar nuestra propia posición mental y (a riesgo de pensar dos veces) es posible que necesitemos compensar en consecuencia y obligarnos a comportarnos racionalmente al elegir nuestros criterios de selección.

Criteria de selección:

No hace falta decir que las opciones de criterios de selección dependen extremadamente del contexto.

Personalmente, haría (como una especie de ejercicio de lluvia de ideas) un breve análisis FODA (15 minutos) de cada opción que esté considerando, junto con (seriamente) un análisis PEST de la situación para garantizar que brinde una visión más amplia (no tecnológica) factores en tu análisis.

FODA para VCS distribuido

Fortalezas:

• Flexibilidad: más libertad para elegir diferentes flujos de trabajo.
• Mejor rendimiento en conexiones de red de bajo ancho de banda / alta latencia: mejor para equipos distribuidos y trabajadores externos.
• Funcionalidad de fusión más sofisticada, que le permite bifurcar con más frecuencia. (No estoy seguro de que esto sea algo bueno).
• El código fuente está "respaldado" en cada máquina de desarrolladores. (bastante falso, ya que podría interferir con la planificación adecuada de recuperación ante desastres)

Debilidades:

• Flexibilidad: debido a que tenemos más libertad para elegir diferentes flujos de trabajo, necesitamos realizar un trabajo adicional para definir qué flujo de trabajo estamos utilizando y aplicarlo.
• Complejidad y dificultad conceptual (especialmente para miembros del equipo que no son desarrolladores de software).

Oportunidades:

• ¿Quizás se puede utilizar la flexibilidad para diseñar un flujo de trabajo que se adapte mejor a las necesidades del negocio?

Amenazas:

• ¿Quizás pasaremos tanto tiempo rediseñando nuestro flujo de trabajo que perderemos el foco en nuestro producto principal?
• Puede ser difícil lograr que algunas personas utilicen incluso herramientas simples, especialmente si no creen que sean necesarias o no estén motivadas.

FODA para VCS centralizado

Fortalezas:

• Proporciona un canal de comunicación implícito en banda para la organización y el proceso empresarial.
• Restringe los flujos de trabajo posibles a un subconjunto (en muchos casos razonable).
• Facilita la configuración de CI y otras herramientas de automatización de desarrollo.
• (SVN específico) Admite grandes repositorios.
• (Específico de SVN) Muy estable, utilizado por muchas organizaciones grandes y conservadoras.
• ¿Políticamente más aceptable en una organización de mando y control de arriba hacia abajo?

Debilidades:

• Inflexible.
• Bajo rendimiento sobre conexiones de bajo ancho de banda / alta latencia, lo que dificulta su uso para equipos distribuidos y trabajadores fuera del sitio (especialmente si el repositorio se hace grande)

Oportunidades:

• ¿Quizás podamos usar la naturaleza monolítica del repositorio para ayudar a los desarrolladores a navegar por el producto y reutilizar más el código del otro?

Amenazas:

• Si el proyecto de repente se vuelve muy importante y necesitamos traer desarrolladores adicionales que trabajen en otros sitios, ¿pueden trabajar efectivamente con un repositorio SVN alojado (para ellos) fuera del sitio?
• Si el conjunto de desarrolladores crece tanto que coordinarlos se vuelve difícil, ¿el repositorio centralizado único se convertirá en un cuello de botella? (¿Podemos evitar esto de otra manera?)

Conclusión:

Qué VCS usar depende de las circunstancias individuales. Para muchas de las situaciones en las que he trabajado, un DVCS con un flujo de trabajo centralizado hubiera funcionado bien, pero habría tenido que justificar el tiempo y el esfuerzo para desarrollar un mecanismo para apoyar y hacer cumplir el flujo de trabajo, lo que hubiera sido (aún es difícil.

En última instancia, creo que la discusión debería centrarse en la pregunta: ¿Qué flujo de trabajo se adapta mejor a nuestro negocio? La mejor herramienta para usar debe seguir naturalmente la respuesta a esa pregunta.