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.
Respuestas:
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.
fuente
No pretendo ser un experto en el tema de los ciclos de bombo, pero ofreceré algunas observaciones:
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.
Si acepta el punto anterior, se deduce que el ciclo de exageración se aplica solo cuando los medios cubren una tecnología determinada.
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.
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:
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.
fuente
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:
Si está interesado, encuentre más detalles aquí:
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").
fuente
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:
Debilidades:
Oportunidades:
Amenazas:
FODA para VCS centralizado
Fortalezas:
Debilidades:
Oportunidades:
Amenazas:
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.
fuente