2009-02-01 10 views
6

Mi jefe tiene problemas cuando se trata de tecnología y rara vez aprueba proyectos que no impactan directamente los ingresos. Él (erróneamente) ignora el lado del costo de la ecuación muchas veces, especialmente para proyectos de tecnología donde es difícil aproximar los costos. ¿Alguien aquí tiene documentos, artículos, etc., para un argumento racional basado en el costo-beneficio para establecer un entorno de desarrollo adecuado (subversión, desarrollo, puesta en escena y servidores de producción)?¿Cómo puedo justificar (costo-beneficio) tomarse el tiempo para configurar un entorno de desarrollo adecuado (Subversion)?

Gracias!

+0

Creo que el hecho de que tengas SVN en este momento hace que esta pregunta sea menos obvia. Los gerentes pueden evitar formalizar algo por miedo a que un proceso mal concebido prevalezca sobre la reactividad. Hay muchas opciones, y encontrar la combinación correcta puede requerir una serie de cambios más pequeños. – Mark

+0

También estoy adivinando por su redacción que él no es de una formación de desarrollo, por lo que se está manejando con eficacia. Obviamente, deberá dejar muy en claro cuáles son sus objetivos y brindarle tranquilidad continua sobre las mejoras, en lugar de simplemente obtener un permiso. – Mark

+0

Estaba a punto de hacer una pregunta sobre el costo beneficio, pero creo que estas respuestas lo cubren. Sería bueno si alguien editara (Subversion) de su título para generalizarlo un poco más. – Makach

Respuesta

6

Martin Fowler tenía un artículo sobre el benefits of Continuous Integration. Llevará algún tiempo configurar una compilación automatizada. En el último proyecto, introduje a CI en que se necesitaba un desarrollador por día para que las cosas funcionasen, luego alrededor de una semana para tener todo ajustado. Hay tantos beneficios que es difícil enumerarlas todas, pero aquí son los que nos han ayudado:

  • favorece la integración frecuentes - ayuda a todos se mantienen en la misma página
  • pruebas automatizadas - cada vez que alguien cheques en se asegura de que los problemas se tratan temprano
  • despliegue automático - un clic y en cuestión de minutos la última versión de nuestro software es en todos los servidores

Para mí, el cambio más importante fue la última. Se convirtió en un proceso de una hora que era propenso a errores (¿Recuerdas actualizar el número de la versión remota? Oh, mierda ...) en un proceso de 5 minutos que podríamos revertir si algo salía mal.

Cuando estaba aprendiendo a configurar CI, this article by Carol Lotz me fue infinitamente útil. Recorre paso a paso la configuración de un proyecto complicado.

6

Wow, ¿qué estás utilizando para el control de fuente en este momento? ¿Nada en absoluto? Si no es así, entonces debería simplemente hacerlo, y configurar un servidor de Subversion. Lo bueno es que no tienes que pedir aprobación porque no es necesario cambiar dinero.

Si ni siquiera puedes hacer eso sin preguntar, entonces te sugiero que encuentres un jefe más ilustrado.

+0

Estamos utilizando un repositorio SVN básico, pero todos los desarrolladores mantienen una copia de desarrollo local en sus máquinas y luego la insertamos en una rama en el repositorio SVN y luego a la producción. Siento que realmente necesitamos formalizar el proceso y tener un proceso de publicación de varios pasos. –

+0

, por lo tanto, no se trata de cómo justificar el uso de SVN, sino cómo obtener un proceso de desarrollo completo, crear y lanzar un sistema. Deberías haber dicho tanto, es una pregunta completamente diferente. – gbjbaanb

4

Yo diría que el costo de no usar ningún tipo de sistema de control de fuente se reflejaría en el costo potencial de perder un montón de código o tener que realizar la conciliación manual de múltiples versiones simultáneas del mismo código, lo que equivale a un costo directo y mensurable en horas hombre.

0

Tengo que estar de acuerdo con Greg. Como Subversion, CC.net, TortoiseSVN, AnkhSVN son todos gratis, debería poder configurar un buen sistema de IC para el cambio.

0

No conozco ningún buen artículo como usted pidió, pero puede decirle que mucha gente aquí en SO (hablo por mí) piensa que su jefe lo entendió del todo mal y es miope. Apoyo la respuesta de Greg de todo corazón.

2

Es mejor pedir disculpas y pedir permiso.

Simplemente configure el servidor de control de fuente, sin preguntar primero. Si algo malo sucede como resultado, solo discúlpate y sigue adelante. Cuando la configuración del control de fuente resulta útil, simplemente diga "oh sí, configuro un sistema de control de fuente" y todos quedarán gratamente sorprendidos.

1

Además de comentario de Scott de sólo hacerlo (parafraseado), si usted comienza con un sistema distribuido, como git o bazaar en lugar de Subversion, puede empezar con tener que ejecutar de forma local sin ni siquiera que afectan a otros, y luego difundirlo entre los otros desarrolladores en el tiempo.

0

¿Podría hacer un análisis de riesgo? Esta es una disciplina de gestión de proyectos aceptada y esencialmente implica enumerar los riesgos, intentar cuantificarlos en términos de probabilidad e impacto e identificar posibles medidas de mitigación. Ese enfoque debería funcionar al menos para el control de la fuente, a menos que su jefe deliberadamente ignore los riesgos, lo que sería muy ... valiente de su parte. :-)

Si ocurre un desastre en el código fuente, su jefe se verá bastante estúpido (e imprudente) y se verá clarividente. La sugerencia de Peter también es buena: configúrela para usted y luego, cuando alguien pierda algún código fuente, o algunos cambios, diga casualmente "Oh, lo hice recientemente pero acabo de recuperar la versión anterior del control de fuente y solo perdí unos 20 minutos de trabajo. ¿Quieres que te prepare con un inicio de sesión? ")

Cuestiones relacionadas