Regístrate al Videoboletín informativo
Recibe en tu correo contenido de actualidad sobre el mundo de la gestión de proyectos: videos, entrevistas, artículos, noticias, eventos, ofertas de trabajo, cursos y mucho más.

¡Certifícate ya como PMP® o CAPM®!
Reserva una beca de hasta un 80% para unirte al programa en línea de habla hispana más efectivo de certificación PMP® o CAPM®: Los 1000 Certificados de LiderDeProyecto.com

Control de manejo de cambios, una experiencia

Más
03 Jul 2020 08:28 #134640 por moderador

moderador escribió:

JosePacheco escribió: Hola Definitivamente es importantisimo el control de las desviaciones potenciales en un proyecto, saber distingirlas (Cambio, trasferencia, Tendencia, desviación), Con una gestíón de cambios correctamente implementada desde los inicios del proyecto, tenemos una muy buena probabilidad de exito en el resultado del proyecto.

Soy ingeniero y me dedico a la construcción y he colaborado con compañias que no tienen un sistema bien establecido de control de proyectos, por lo mismo no dimensionan lo importante que es llevar los controles necesarios para medir y controlar el avance y productividad del proyecto, asi mismo no conocen las virtudes del control de la gestión de cambios, y al final del proyecto cuando ya estan ahorcados y deben hasta la camisa en el proyecto, es cuando quieren voltear e indagar en todos los alcances que no pudieron documentar y no pudieron facturar en su momento al cliente. Es terrible pero asi pasa en algunas compañias con algunos gerentes de proyecto.

Saludos

Pero además de los cambios debe haber un seguimiento metódico de los avances!!!
INFORMAR EL DESEMPEÑO
En este proceso se recopila el desempeño de la información, se analiza, y se envía a los Interesados. Es importante que el Director del Proyecto comprenda que:
- Los informes deben proporcionar los tipos de información y el nivel de detalle requerido por los Interesados.
- Los informes deben ser designados de acuerdo a las necesidades del proyecto.
- La mejor manera de tener un informe leído y seguido es utilizar el método de comunicación más apropiado al enviarlo. ¿Será posible que las personas se enfoquen en un email específico cuando reciben cientos al día? ¿Sería mejor enviar el reporte por la noche? Es importante asegurarse de considerar estos factores al momento de presentar la información.
- No debe pasar todo su tiempo informando. Es importante recordar que muchos informes explican el pasado. Encontrar información sobre el pasado significa que es muy tarde para evitar el problema. Es necesario continuar gestionando el proyecto, y no tan sólo informar sobre éste, para conseguir el éxito del proyecto. Mucha gente nueva en Dirección de Proyectos comete el error de dedicar demasiado tiempo al informe y poco tiempo a la dirección.
- Los informes deben incluir mediciones contra la Línea Base para la Medición del Desempeño establecido en el Plan para la Dirección del Proyecto. Es importante tener una Línea Base para la Medición del Desempeño (las Líneas Base del Alcance, Cronograma, y Costo combinadas) que pueda ser medida. Estas mediciones son indicadores de cuán exitoso es el Director del Proyecto.
- Los informes deben ser veraces y no esconder lo que está pasando realmente.
- Se debe informar el costo, cronograma, alcance, y rendimiento de calidad, no sólo el cronograma.
- Los informes ayudan a los miembros del equipo a saber dónde necesitan recomendar e implementar acciones correctivas.
- El proceso Informar el Desempeño incluye mirar hacia el futuro. El equipo y el Patrocinador pueden utilizar pronósticos para determinar qué acciones preventivas son necesarias.
- Es necesario obtener feedback de las personas que han recibido los informes como parte de este proceso.
- Existen diferentes tipos de informes de desempeño, no sólo uno que pueda surgir de alguna aplicación de software. Estos informes pueden ser:
Informe de Estado: Describe dónde se encuentra el proyecto hoy con respecto a la medición de la Línea Base del Desempeño.
Informe de Progreso: Describe lo realizado hasta la fecha de corte.
Informe de Tendencias: Examina los resultados a lo largo del tiempo para ver si el desempeño está mejorando o se está deteriorando.
Informe de Proyecciones: Predice el desempeño y el estado futuro del proyecto.
Informe de Variación: Compara los resultados reales con respecto a las líneas base.
Informe de Valor Ganado: Integra las mediciones de alcance, costo y cronograma para evaluar el desempeño del proyecto, utilizando los términos descritos en el capítulo de Gestión de los Costos (por ejemplo, PV, EV, AC, etc.).
Documentación de Lecciones Aprendidas: Los informes sobre el rendimiento se utilizan como Lecciones Aprendidas para futuros proyectos.



ALvaro

Debemos ponernos de acuerdo y definir cómo mediremos el trabajo
MÉTODOS MEDICIÓN DEL TRABAJO (AVANCES)
Extraído de
Gestión de Valor Ganado “EVM” para Control de Proyectos v.2
www.liderdeproyecto.com/evm/index.html

Existen diversos métodos o reglas de asignación del trabajo medido:
 Regla 0/100. Al concluir el trabajo se asignará la totalidad del valor.
 Fórmulas como 50/50, 40/60 o 25/75. El primer valor se asigna al autorizar el trabajo y el último al entregarlo. No hay que confundir el primer valor con un anticipo en la forma de pago.
 Logro por hitos alcanzados con pesos asignados. Al alcanzar un hito se asigna un porcentaje del valor o una cantidad fija pre-especificada. Una versión algo diferente es cuando los hitos son portales de paso de una a otra etapa del ciclo de vida.
 Por unidades terminadas y entregadas. Es similar a la regla 0/100, pero pensando más en partes, productos, sub-productos o entregables que en paquetes de trabajo. Puede ser aplicable también a funcionalidades alcanzadas en sistemas de software.
 Escala de valores discretos de progreso tal como 0/25/50/75/100%. Se trata de fórmulas usadas para actividades que llevan un tiempo significativo concluirlas y donde se otorgan porcentajes fijos según se completan trabajos parciales o se alcanzan ciertos atributos. Es típico de la industria de la construcción.
 Por % completado del trabajo, el cual es un método que asigna un porcentaje de avance acordado entre las partes. El valor es algo subjetivo que puede no reflejar la realidad.
 Medición del nivel de esfuerzo LOE (Level of Effort). Es una regla basada en asignar al trabajo el tiempo incurrido para llevarlo a cabo (horas, días, horas-hombre, etc.). Tiene la desventaja de que EV suele coincidir con PV. Es el típico sistema de medición de los proyectos de construcción de antaño. Se usa también en proyectos de Ingeniería y en otros ámbitos que requieren reporte de costos de personal contratados por tarifas.

 Asignación proporcional al esfuerzo. Es para trabajos o actividades, normalmente de gestión, que son proporcionales al trabajo directo. Por ejemplo puede incluir gestión de gerencia de proyectos, calidad, inspección, servicios de procura, marketing, seguridad, servicios, etc. Se suele asignar como un porcentaje fijo de otros trabajos medidos con reglas.
Cómo decidir cuándo un trabajo ha sido concluido para asignarle el último valor de la regla de asignación, vendrá dado por los procedimientos de verificación de alcance y aceptación de los entregables, o simplemente mediante un acuerdo logrado con el cliente.
En proyectos de infraestructura podemos medir simplemente unidades absolutas, longitudes, áreas, volúmenes, peso o cualquier otra unidad y convertirlas a porcentaje de avance del total, según lo acordado previamente.
Donde se hace más difícil es en tecnologías de información, en proyectos de elaboración de fármacos, en proyectos de investigación y desarrollo de nuevas tecnologías o de nuevos productos, donde las unidades a ser medidas, no suelen ser tan tangibles.
En el caso de software podemos medir progreso de requisitos utilizando una matriz de seguimiento, o de funcionalidades de sistemas o módulos, asegurando con un buen sistema de pruebas el no tener que rehacer demasiado trabajo, una vez certifiquemos la entrega de los paquetes.


ALvaro

Por favor, Identificarse o Crear cuenta para unirse a la conversación.

Más
03 Jul 2020 08:26 #134639 por moderador

JosePacheco escribió: Hola Definitivamente es importantisimo el control de las desviaciones potenciales en un proyecto, saber distingirlas (Cambio, trasferencia, Tendencia, desviación), Con una gestíón de cambios correctamente implementada desde los inicios del proyecto, tenemos una muy buena probabilidad de exito en el resultado del proyecto.

Soy ingeniero y me dedico a la construcción y he colaborado con compañias que no tienen un sistema bien establecido de control de proyectos, por lo mismo no dimensionan lo importante que es llevar los controles necesarios para medir y controlar el avance y productividad del proyecto, asi mismo no conocen las virtudes del control de la gestión de cambios, y al final del proyecto cuando ya estan ahorcados y deben hasta la camisa en el proyecto, es cuando quieren voltear e indagar en todos los alcances que no pudieron documentar y no pudieron facturar en su momento al cliente. Es terrible pero asi pasa en algunas compañias con algunos gerentes de proyecto.

Saludos

Pero además de los cambios debe haber un seguimiento metódico de los avances!!!
INFORMAR EL DESEMPEÑO
En este proceso se recopila el desempeño de la información, se analiza, y se envía a los Interesados. Es importante que el Director del Proyecto comprenda que:
- Los informes deben proporcionar los tipos de información y el nivel de detalle requerido por los Interesados.
- Los informes deben ser designados de acuerdo a las necesidades del proyecto.
- La mejor manera de tener un informe leído y seguido es utilizar el método de comunicación más apropiado al enviarlo. ¿Será posible que las personas se enfoquen en un email específico cuando reciben cientos al día? ¿Sería mejor enviar el reporte por la noche? Es importante asegurarse de considerar estos factores al momento de presentar la información.
- No debe pasar todo su tiempo informando. Es importante recordar que muchos informes explican el pasado. Encontrar información sobre el pasado significa que es muy tarde para evitar el problema. Es necesario continuar gestionando el proyecto, y no tan sólo informar sobre éste, para conseguir el éxito del proyecto. Mucha gente nueva en Dirección de Proyectos comete el error de dedicar demasiado tiempo al informe y poco tiempo a la dirección.
- Los informes deben incluir mediciones contra la Línea Base para la Medición del Desempeño establecido en el Plan para la Dirección del Proyecto. Es importante tener una Línea Base para la Medición del Desempeño (las Líneas Base del Alcance, Cronograma, y Costo combinadas) que pueda ser medida. Estas mediciones son indicadores de cuán exitoso es el Director del Proyecto.
- Los informes deben ser veraces y no esconder lo que está pasando realmente.
- Se debe informar el costo, cronograma, alcance, y rendimiento de calidad, no sólo el cronograma.
- Los informes ayudan a los miembros del equipo a saber dónde necesitan recomendar e implementar acciones correctivas.
- El proceso Informar el Desempeño incluye mirar hacia el futuro. El equipo y el Patrocinador pueden utilizar pronósticos para determinar qué acciones preventivas son necesarias.
- Es necesario obtener feedback de las personas que han recibido los informes como parte de este proceso.
- Existen diferentes tipos de informes de desempeño, no sólo uno que pueda surgir de alguna aplicación de software. Estos informes pueden ser:
Informe de Estado: Describe dónde se encuentra el proyecto hoy con respecto a la medición de la Línea Base del Desempeño.
Informe de Progreso: Describe lo realizado hasta la fecha de corte.
Informe de Tendencias: Examina los resultados a lo largo del tiempo para ver si el desempeño está mejorando o se está deteriorando.
Informe de Proyecciones: Predice el desempeño y el estado futuro del proyecto.
Informe de Variación: Compara los resultados reales con respecto a las líneas base.
Informe de Valor Ganado: Integra las mediciones de alcance, costo y cronograma para evaluar el desempeño del proyecto, utilizando los términos descritos en el capítulo de Gestión de los Costos (por ejemplo, PV, EV, AC, etc.).
Documentación de Lecciones Aprendidas: Los informes sobre el rendimiento se utilizan como Lecciones Aprendidas para futuros proyectos.



ALvaro

Por favor, Identificarse o Crear cuenta para unirse a la conversación.

Más
03 Jul 2020 08:24 #134638 por moderador

moderador escribió:

JosePacheco escribió: Hola Definitivamente es importantisimo el control de las desviaciones potenciales en un proyecto, saber distingirlas (Cambio, trasferencia, Tendencia, desviación), Con una gestíón de cambios correctamente implementada desde los inicios del proyecto, tenemos una muy buena probabilidad de exito en el resultado del proyecto.

Soy ingeniero y me dedico a la construcción y he colaborado con compañias que no tienen un sistema bien establecido de control de proyectos, por lo mismo no dimensionan lo importante que es llevar los controles necesarios para medir y controlar el avance y productividad del proyecto, asi mismo no conocen las virtudes del control de la gestión de cambios, y al final del proyecto cuando ya estan ahorcados y deben hasta la camisa en el proyecto, es cuando quieren voltear e indagar en todos los alcances que no pudieron documentar y no pudieron facturar en su momento al cliente. Es terrible pero asi pasa en algunas compañias con algunos gerentes de proyecto.

Saludos

Estimado José: muchas gracias por compartir tu experiencia!!
No gestionar en forma ordenada los cambios conduce inexorablemente a problemas!!!
Eso es el resumen de mi experiencia en proyectos!!!
Sigamos por más!!!
Alvaro

Si no se aplica un control de cambios robusto no podremos resolver el tema
Por eso debemos implantarlo y monitorearlo

Esquema detallado del Proceso para la realización de cambios

1. Prevenir la causa raíz de los cambios:
El director del proyecto no debe enfocarse sólo en la gestión de los cambios, sino en eliminar la necesidad de cambios en forma proactiva. Es necesario muchas veces adelantarse a esa posibilidad acordando con precisión requisitos, restricciones, evitando indefiniciones. No siempre los cambios son malos pero muchas veces requerirán esfuerzo extra y no siempre pago !!!!

2. Identificar el cambio:
Los cambios pueden provenir del director del proyecto, como resultado de una comparación con la línea de base para la medición del desempeño, o del patrocinador, del equipo, la gerencia, el cliente u otros interesados. El director del proyecto debería estar buscando activamente cambios de todas estas fuentes, porque descubrir un cambio de manera temprana disminuirá siempre el impacto del cambio.

3. Revisar el impacto del cambio en el área de conocimiento:
Si es un cambio en el alcance, ¿cómo afectará al resto del alcance del proyecto? Si es un cambio en el tiempo, ¿cómo afectará al resto del cronograma del proyecto?
Pensemos siempre desde el área de integración y las consecuencias escalonadas del cambio, no sólo el primer impacto directo si no en todos los correlacionados.

4. Crear una solicitud de cambio:
Los cambios pueden ser realizados al alcance del producto, a cualquier parte del plan para la dirección del proyecto, al contrato, al acta de constitución, al enunciado del trabajo, a las políticas y procedimientos, o incluso a la línea de base para la medición del desempeño. El proceso de realización de cambios debe seguir el plan de gestión de cambios.

5. Realizar el control integrado de cambios
¿Cómo afectará el cambio a todas las demás restricciones del proyecto? Debemos analizar y detallar el impacto del cambio.

a. Evaluar el cambio :¿El cambio afecta el acta de constitución del proyecto, es decir las definiciones de alto nivel? Si es así podría afectar al viabilidad/factibilidad del proyecto!!! Podríamos tener que cerrar el proyecto y eventualmente decidir si abrir otro!!! . ¿El cambio beneficia al proyecto? ¿Es necesario o imperativo? Si la respuesta a cualquiera de estas preguntas es no, el cambio no debería aprobarse. Tengan en cuenta también que todo cambio que ya tenía una reserva creada (un evento de riesgo identificado previamente) será tenido .en cuenta en el plan para la dirección del proyecto como parte de los esfuerzos de gestión de riesgos, y debería ser manejado como parte del proceso Dirigir y Gestionar el Trabajo del Proyecto, en lugar del proceso de control integrado de cambios.

b. Buscar opciones: Las opciones incluyen acciones para disminuir las amenazas aún más, aumentar las oportunidades, ajustar el cronograma a través de la compresión o la ejecución rápida, cambiar la forma en que es realizado el trabajo, ajustar la calidad, o recortar el alcance de manera que el efecto del cambio se vea minimizado. Tengan cuidado: no es acertado disminuir individualmente el impacto de cada cambio. Al hacerlo, el director del proyecto podría disminuir la probabilidad general de éxito dentro del proyecto. En algunas ocasiones, dos semanas de trabajo adicionales por alcance agregado al proyecto, implica una extensión de dos semanas al tiempo del proyecto, si el trabajo ocurre en la ruta crítica. Debemos tener una visión holística y evaluar globalmente el impacto del cambio.

c. El cambio es aprobado o rechazado: el director del proyecto puede aprobar muchos cambios. Pero los cambios que afecten al plan para la dirección del proyecto, líneas de base, acta de constitución, etc., posiblemente deban ser aprobados por el comité de control de cambios. Los cambios aprobados luego son implementados en el proceso Dirigir y Gestionar el Trabajo del Proyecto.

d. Actualizar el estado del cambio en el registro de cambios Esto colabora con que todos conozcan el estado del cambio. Si un cambio no es aprobado, las razones por las que fue rechazado también deben documentarse.

e. Actualizar el plan para la dirección del proyecto, los documentos del proyecto y las líneas de base según sea necesario Algunos cambios aprobados deben ser incorporados a las líneas de base del proyecto. Los cambios pueden afectar a otras partes del plan para la dirección del proyecto o los documentos del proyecto, o afectar el modo en que el director del proyecto dirigirá el proyecto, y la documentación del proyecto debe ser actualizada para reflejar los cambios. Esto significa que debe realizarse la replanificación para incorporar los impactos del cambio a la nueva versión de documentos y planificar antes de que el equipo comience a ejecutar el cambio. Por ejemplo, si se realiza un cambio al alcance, deben actualizarse la línea de base del alcance (la EDT, el diccionario de la EDT y el enunciado del alcance del proyecto), el plan para la dirección del proyecto y la matriz de trazabilidad de requisitos. Si ese cambio en el alcance afecta a otras áreas del proyecto, la documentación asociada (p. ej., la lista de actividades, el plan de recursos humanos y otra documentación de recursos, el cronograma, el presupuesto, el registro de riesgos, etc.) también debe actualizarse.

6. Gestionar las expectativas de los interesados comunicando el cambio a los interesados afectados por el mismo
Es necesario seguir las pautas de comunicación de cambios a los interesados de acuerdo al plan de comunicaciones. Esto puede ser pensado, en parte, como la gestión de la configuración (control de la versión para garantizar que todos estén trabajando en base a la misma documentación del proyecto.


7. Gestionar el proyecto de acuerdo con el plan para la dirección del proyecto y los documentos del proyecto modificados
Finalmente poner en marcha los cambios aprobados de acuerdo al nuevo estado del proyecto de acuerdo al Plan del Proyecto actualizado!!!

ALvaro

Por favor, Identificarse o Crear cuenta para unirse a la conversación.

Más
03 Jul 2020 08:16 #134637 por moderador

JosePacheco escribió: Hola Definitivamente es importantisimo el control de las desviaciones potenciales en un proyecto, saber distingirlas (Cambio, trasferencia, Tendencia, desviación), Con una gestíón de cambios correctamente implementada desde los inicios del proyecto, tenemos una muy buena probabilidad de exito en el resultado del proyecto.

Soy ingeniero y me dedico a la construcción y he colaborado con compañias que no tienen un sistema bien establecido de control de proyectos, por lo mismo no dimensionan lo importante que es llevar los controles necesarios para medir y controlar el avance y productividad del proyecto, asi mismo no conocen las virtudes del control de la gestión de cambios, y al final del proyecto cuando ya estan ahorcados y deben hasta la camisa en el proyecto, es cuando quieren voltear e indagar en todos los alcances que no pudieron documentar y no pudieron facturar en su momento al cliente. Es terrible pero asi pasa en algunas compañias con algunos gerentes de proyecto.

Saludos

Estimado José: muchas gracias por compartir tu experiencia!!
No gestionar en forma ordenada los cambios conduce inexorablemente a problemas!!!
Eso es el resumen de mi experiencia en proyectos!!!
Sigamos por más!!!
Alvaro

Por favor, Identificarse o Crear cuenta para unirse a la conversación.

Más
02 Jul 2020 13:03 #134626 por JosePacheco
Hola Definitivamente es importantisimo el control de las desviaciones potenciales en un proyecto, saber distingirlas (Cambio, trasferencia, Tendencia, desviación), Con una gestíón de cambios correctamente implementada desde los inicios del proyecto, tenemos una muy buena probabilidad de exito en el resultado del proyecto.

Soy ingeniero y me dedico a la construcción y he colaborado con compañias que no tienen un sistema bien establecido de control de proyectos, por lo mismo no dimensionan lo importante que es llevar los controles necesarios para medir y controlar el avance y productividad del proyecto, asi mismo no conocen las virtudes del control de la gestión de cambios, y al final del proyecto cuando ya estan ahorcados y deben hasta la camisa en el proyecto, es cuando quieren voltear e indagar en todos los alcances que no pudieron documentar y no pudieron facturar en su momento al cliente. Es terrible pero asi pasa en algunas compañias con algunos gerentes de proyecto.

Saludos

Por favor, Identificarse o Crear cuenta para unirse a la conversación.

Más
19 Jun 2020 20:44 #134285 por moderador

moderador escribió:

Tammara Peraza escribió: A veces desde la planificación y la gestión de los proyectos misma no es fácil llevar a buena aplicación el control de versiones y se requiere de un apoyo externo que fortalezca la disciplina de su aplicación.
Una experiencia que puedo compartir, es que en mi empresa nadie tomaba en cuenta el control de cambios, aunque se tenía un protocolo para clasificar las versiones y plena conciencia de su necesidad y desventaja en la no aplicación. La versión oficial de los documentos de los proyectos, era referenciada por las fechas de creación del archivo en cuestión, por ello los cabios en el alcance no siempre eran claros, la versión final del alcance lo conocía el gerente del proyecto en el sitio del proyecto de cara al cliente y su homólogo también en sitio y había que corretear a los Project managers en sitio para que entregaran la última versión y poder subirse al repositorio de documentos del proyecto desde oficinas centrales. Se pudo tomar acción y control en el cambio de versiones hasta que la empresa se tuvo que certificar en ISO de manera local y con plena instrucción del corporativo a implementar todo lo que fuera necesario para conseguir la certificación, allí el control de cambios, manejo de versiones y repositorio de documentos era tomado en cuenta por fuerza o la certificación de iba para atrás, además de la sanción que se llevaría el responsable de la actualización de las versiones finales oficiales. Sólo de esa manera se resolvió ese vicio de operación.

No siempre es el camino pero a veces la presión ayuda estimada Tammara!!
Unas línes debajo y muchas gracias por comaprtir la experiencia!! :-)
Sigamos por más!!!
ALvaro

Control de Versiones
"Versión" Versus "Revisión"
El termino versión es a veces utilizado como un sinónimo para "revisión", pero aquí no voy a utilizarla de esta forma, ya que se puede confundir fácilmente con "versión" en el sentido de una versión de un programa—así que, el número de lanzamiento o edición como en "Versión 1.0". Y aunque la frase "control de versiones" es un estándar, continuare utilizándolo como sinónimo para "control de revisiones" y para "control de cambios".
commit
Realizar un cambio en el proyecto. Formalmente, almacenar un cambio en la base de datos del control de versiones de forma que pueda ser incorporado en lanzamientos futuros del proyecto. "Commit" puede ser utilizado como un verbo o como un sustantivo. Como un sustantivo, es esencialmente un sinónimo de "cambio". Por ejemplo: "He commited una reparación para un fallo reportado en Mac OS X que hacía que el servidor se colgara. José ¿podrías por favor revisarlo y verificar que no estoy haciendo mal la asignación?"
Mensaje de registro
Un pequeño comentario añadido a cada commit que describe el tipo y el propósito del commit. Los mensajes de registro forman parte de los documentos más importantes de cualquier proyecto ya que son un puente entre el lenguaje altamente técnico de los cambios individuales en el código y el lenguaje más orientado al usuario de características, resolución de fallos y progreso del proyecto. Más adelante vamos a ver la forma de distribuir estos mensajes a la audiencia apropiada y también “Tradición en Capítulo 6, Comunicaciones discutimos como ENCOURAGE a los voluntarios para que escriban mensajes de registro útiles y concisos.
update
Solicitar los cambios (commits) que han realizado otros en la copia local del proyecto, esto actualiza esta copia a la última versión. Es una operación muy común ya que la mayoría de los desarrolladores actualizan su código varias veces al día y así saben que están ejecutando casi lo mismo que los otros desarrolladores, así que si se descubre un fallo es muy posible que éste aún no haya sido resuelto. Por ejemplo: "Hey, he notado que el código del índice está fallando en el último byte. ¿Es esto un nuevo fallo?" "Sí, pero fue resuelto la semana pasada—prueba actualizar para resolverlo."
repositorio
Una base de datos en la que los cambios son almacenados. Algunas versiones de sistemas de control de versiones son centralizadas, es decir, existe un único repositorio maestro, el cual almacena todos los cambios en el proyecto. Otros sistemas son descentralizados, cada desarrollador tiene su propio repositorio y los cambios pueden ser intercambiados entre repositorios arbitrariamente. El sistema de control de versiones mantiene un registro de las dependencias entre estos cambios y cuando llega el momento de realizar un lanzamiento, un conjunto particular de cambios es aprobado para ese lanzamiento. La cuestión de cual sistema es mejor es otra de las guerras santas del desarrollo de software. Intentad no caer en la trampa de discutir sobre esto en las listas de correo del proyecto.
checkout
El proceso de obtener una copia del proyecto desde el repositorio. Por lo general, un checkout produce un árbol de directorios llamado "copia funcional" desde el cual los cambios serán enviados de vuelta al repositorio original. En algunas versiones descentralizadas de sistemas de control, cada copia funcional es en sí mismo un repositorio y los cambios son empujados (o atraídos) a cualquier repositorio que esté dispuesto a aceptarlos.
copia funcional
El árbol de directorios privado de cada desarrollador que contiene el código fuente del proyecto y posiblemente las páginas web u otros documentos. Una copia funcional también contiene una pequeña cantidad de meta-data administrada por el sistema de control de versiones, informando a la copia funcional cual es repositorio central de procedencia, la revisión de los ficheros presentes, etc. Generalmente, cada desarrollador tiene su propia copia funciona en la cual realiza y prueba los cambios y desde la cual envía sus commits (cambios).
revisión, cambio, conjunto de cambios
Una revisión es usualmente una encarnación específica de un fichero o directorio en particular. Por ejemplo, si el proyecto se inicia en la revisión 6 del fichero F y alguien envía un cambio al fichero F, esto produce la revisión 7 de F. Algunos sistemas también utilizan revisión (revision), cambio (change) o conjunto de cambios (changeset) para referirse a un conjunto de cambios enviados juntos como una unidad conceptual.
Estos conceptos pueden tener distintos significados técnicos en cada sistema de control de versiones, pero en general, la idea es siempre la misma: dar un sistema para comunicar de manera precisa la historia de cambios en un fichero o conjunto de ficheros (inmediatamente antes y después de que se ha corregido un fallo). Por ejemplo: "Eso se ha resuelto en la revisión 10" o "Se ha corregido eso en la revisión 10 del fichero foo.c."
Cuando se habla sobre ficheros o una colección de ficheros sin especificar una revisión en particular, por lo general se asume que nos referimos a la revisión disponible más reciente.
diff
Una representación contextual de un cambio. Un diff muestra las líneas que han sido modificadas, como y además, algunas líneas contextuales rodeándolas a cada lado. Un desarrollador familiarizado con el código puede, con leer un diff de ese código, entender lo que hace el cambio e incluso detectar fallos.
etiqueta (tag)
Una etiqueta para una colección particular de ficheros en una revisión específica. Los tags son utilizados para preservar capturas interesantes del proyecto. Por ejemplo, un tag es hecho para cada lanzamiento público, de forma que cada persona pueda obtener, directamente desde el sistema de control de versiones, el conjunto exacto de ficheros/revisiones que componen el lanzamiento. Algunos tags comunes son como Release_1_0, Delivery_00456, etc.
rama (branch)
Es una copia del proyecto, bajo el control de versiones, pero aislado, de forma que los cambios realizados en esta rama no afecten al resto del proyecto y vice versa, excepto cuando los cambios sean deliberadamente "unidos" de un lado al otro. Las ramas también son conocidas como "líneas de desarrollo". Incluso cuando un proyecto no tiene ramas específicas se considera que el desarrollo se está produciendo en la rama principal, también conocida como "línea primaria" o "trunk".
Las ramas o branches, permiten aislar diferentes líneas de desarrollo de sí mismas. Por ejemplo, una rama puede ser utilizada para un desarrollo experimental que sería demasiado inestable para la rama principal. O al contrario, una rama puede ser utilizada como sitio para estabilizar una versión para lanzamiento. Durante el proceso de lanzamiento, el desarrollo regular se mantendría ininterrumpido en la rama principal. Mientras tanto, en la rama de lanzamiento, ningún cambio es aceptado excepto aquellos aprobados por el responsable del lanzamiento. De esta manera, realizar un lanzamiento no tiene porqué interferir con el trabajo de desarrollo que se está realizando. Para más información “Las ramas para evitar cuellos de botella” más adelante en el capítulo para una discusión más detallada sobre las ramas.
merge
Mover un cambio de una rama a otra, lo que incluye unir desde la rama principal a otra rama o vice versa. De hecho, estos son las uniones más comunes y es rara la ocasión en la que esto se hace entre dos ramas no principales. Para más información sobre los merge “Singularidad de la información”.
"Merge" tiene otro significado: es lo que hace el sistema de control de versiones cuando se encuentra con que dos personas han realizado cambios en un mismo fichero sin relación alguna. Ya que estos cambios no interfieren entre ellos, cuando alguna de estas personas actualiza su copia del fichero (el cual ya contiene los cambios) los cambios de la otra persona serán unidos automáticamente. Esto sucede muy a menudo, especialmente en proyectos con múltiples personas realizando cambios en el mismo código. Cuando dos cambios diferentes están relacionados, el resultado es un "conflicto".
conflicto
Sucede cuando dos o más personas intentan realizar diferentes cambios en la misma porción de código. Todos los sistemas de control de versiones detectan estos conflictos automáticamente y notifican a al menos uno de los humanos involucrados de que sus cambios entran en conflicto con los de alguien más. Es entonces tarea de estas personas resolver el conflicto y comunicar esa resolución al sistema de control de versiones.
bloqueo (lock)
Declaración de un intento exclusivo para cambiar un fichero o directorio en particular. Por ejemplo, "No puedo enviar cambios a las páginas web ahora mismo, ya que parece que Alfredo las tiene bloqueadas mientras arregla sus imágenes de fondo." No todos los sistemas de control de versiones ofrecen la posibilidad del bloqueo y aquellos que sí lo permiten, no es necesario que se utilice. Esto es porque el desarrollo paralelo y simultáneo es la norma y bloquear a la gente para que no puedan modificar los ficheros es contrario a la idea del sistema.
El modelo del sistema de control de versiones que requiere el bloqueo de ficheros suele ser llamado bloqueo-modificación-desbloqueo y el modelo que no requiere del bloqueo es llamado copia-modificación-unión. Una excelente explicación en profundidad y comparaciones puede ser encontrada en svnbook.red-bean.com/svnbook-1.0/ch02s02.html . En general, el modelo de copia-modificación-unión es el mejor para el desarrollo open source y todos los sistemas de control de versiones discutidos en este libro soportan este modelo.
Escoger un sistema de control de versiones
Hasta ahora, los dos sistemas de control de versiones más populares en el mundo del software libre son Concurrent Versions System (CVS), www.cvshome.org/ ) y Subversion (SVN, subversion.tigris.org/ ).
CVS lleva largo tiempo y los desarrolladores más experimentados ya están familiarizados con él. Hace más o menos lo necesario y ya que ha sido popular durante mucho tiempo es probable que no se termine discutiendo su utilización. A pesar de todo, CVS tiene algunas desventajas. No ofrece facilidad para hacer referencia a cambios en múltiples ficheros, no permite renombrar o copiar ficheros dentro del sistema de control (así que puede ser muy doloroso reorganizar el código después de iniciar el proyecto), el soporte para las uniones es algo pobre, no trabaja muy bien con ficheros muy grandes o con ficheros binarios y algunas operaciones son lentas cuando muchos ficheros están involucrados.
Ninguno de estos fallos de CVS es fatal y sigue siendo muy popular. Sin embargo, durante los últimos años Subversion ha venido ganando terreno, especialmente con nuevos proyectos. [15]. Si está iniciando un nuevo proyecto, recomiendo Subversion.
Por otra parte, dado que estoy involucrado en el proyecto Subversion, mi objetividad puede ser razonablemente cuestionable y durante los últimos años han ido surgiendo un número de nuevos sistemas de control de versiones open source. Podemos encontrar una lista de todos los sistemas que conozco en Apéndice A, Sistemas de Control de Versiones Libres según su popularidad. Como muestra esta lista, escoger un sistema de control de versiones puede convertirse en una interminable tarea de investigación. Posiblemente esta decisión ya haya sido tomada por el sitio donde hospedamos el proyecto, liberándonos de esta carga, pero si es necesario tomar una decisión, lo mejor es consultar con otros desarrolladores, indagar un poco para tener una idea de las distintas experiencias que haya tenido la gente y luego escoger uno y mantenerse con este. Cualquier sistema de control de versiones estable y listo para entornos de producción será suficiente, no hay que preocuparse demasiado sobre tomar una decisión equivocada. Si simplemente no se puede decidir, entonces la opción es Subversion. Es relativamente fácil de aprender y es probable que se mantenga como el estándar por unos años más.
Utilizando el sistema de control de versiones
Las recomendaciones realizadas en esta sección no están enfocadas hacia un sistema de control de versiones en particular y debería ser sencillo implementarlas en cualquiera. La documentación específica del sistema debe ofrecer los detalles necesarios.
Versiones de todo
No solo hay que mantener el código del proyecto bajo el control de versiones también las páginas web, documentación, FAQ, notas de diseño y cualquier cosa que pueda ser necesario editar. Todo esto hay que mantenerlo cerca del código, en el mismo árbol que el repositorio. Se deben mantener versiones de cualquier pieza de información que pueda cambiar y archivar la que no cambie. Por ejemplo, un correo electrónico, una vez enviado, no cambia, por lo tanto, mantener versiones de este no tiene sentido (a menos que se convierta en una parte importante de la documentación).
La razón de mantener versiones de todo en un mismo sitio, es para que la gente sólo tenga que aprender un sistema para realizar cambios. A menudo, un voluntario se iniciará modificando algunas páginas web o partes de la documentación, para luego pasar a realizar pequeñas contribuciones al código, por ejemplo. Cuando el proyecto utiliza el mismo sistema para todo tipo de cambios, las personas sólo tendrán que aprender THE ROPES una vez. Mantener las versiones juntas significa que nuevas características pueden ser añadidas junto a la actualización de la documentación, y que al crear ramas del código, se crearan ramas de la documentación, etc.
No hace falta mantener los ficheros generados bajo el sistema de control de versiones ya que no son datos editables generados por otros programas. Por ejemplo, algunos sistemas de compilado generan los ficheros configure basándose en una plantilla configure.in. Para realizar cambios al fichero configure bastaría con modificar configure.in y volver a generarlo. Entonces, sólo el fichero configure.in es un fichero editable. Sólo es necesario mantener versiones de las plantillas—si se hace con los ficheros generados, la gente se olvidará de volver a generarlos cuando realicen algún cambio en las plantillas y las resultantes inconsistencias crearan una mayor confusión. [16]
La regla de que todos los datos editables deben ser mantenidos bajo el control de versiones tiene una excepción desafortunada: el gestor de fallos. La base de datos de fallos almacena una gran cantidad de datos editables pero generalmente, por razones técnicas, no se puede mantener bajo el control de versiones principal. (Algunos gestores tienen características primitivas de control de versiones, pero independiente de repositorio principal del proyecto.)
Navegabilidad
El repositorio del proyecto debe ser accesible desde Internet. Esto no sólo significa la habilidad de visualizar la última revisión de los ficheros del proyecto, pero permitir volver atrás en el tiempo y ver en revisiones anteriores, mirar las diferencias entre revisiones, leer los mensajes de registro para cambios específicos, etc.
La navegabilidad es importante porque es un ligero portal a los datos del proyecto. Si el repositorio no es accesible desde un navegador web entonces alguien que desea inspeccionar un fichero en particular (por ejemplo, para mirar si una mejora ha sido incluida en el código) tendrá que instalar el mismo programa utilizado por el sistema de control de versiones, lo cual convierte una simple consulta de dos minutos en una tarea de medio hora o más.
También implica URLs CANONICAL para visualizar revisiones específicas de un fichero y para la última revisión en cualquier momento. Esto puede ser muy útil durante discusiones técnicas o para indicar alguna documentación a la gente. Por ejemplo, en lugar de decir "Para ayudas sobre cómo encontrar fallos en el servidor, mirad el fichero www/hacking.html en vuestra copia funcional" se puede decir "Para ayudas sobre cómo encontrar fallos en el servidor, mirad subversion.apache.org/docs/community-guide/ ," dando una URL que siempre lleva a la última revisión del fichero hacking.html. La URL es mejor porque no es nada ambigua y evita la cuestión de si existe una copia funcional actualizada.
Algunos sistemas de control de versiones incluyen un mecanismo que permite la navegación del repositorio, mientras que otros dependen de herramientas de terceros. Tres de estas herramientas son ViewCVS( viewcvs.sourceforge.net/ ), CVSWeb ( www.freebsd.org/projects/cvsweb.html ), and WebSVN( websvn.tigris.org/ ). La primera trabaja muy bien con CVS y con Subversion, la segunda sólo con CVS y la tercera sólo con Subversion.
Correos de cambios
Cada commit al repositorio debería generar un correo electrónico mostrando quien ha hecho el cambio, cuando, cuales ficheros y directorios han cambiado y como. Este correo debe ser dirigido a una lista de correos separada de las listas a las que envían los humanos. Los desarrolladores y todos aquellos interesados deben ser animados para suscribirse a las lista de commits ya que es la manera más efectiva de mantenerse al día con lo que sucede en el proyecto al nivel del código. Aparte de los obvios beneficios técnicos de la revisión por la comunidad (“Practicad revisiones visibles del código”), los correos con los cambios ayudan a crear un sentido de comunidad porque establecen un ambiente compartido en el que la gente puede reaccionar ante diferentes eventos (commits) que saben son visibles a otros también.
La configuración específica para habilitar estos correos varía dependiendo de la versión del sistema de control de versiones pero a menudo existe un script o paquete que facilita esto. Si se tiene algún problema para encontrar estos, intente buscar en la documentación el tema relacionado con los hooks, específicamente el post-commit hook, también llamado loginfo hook en CVS. Los Post-commit hooks son tareas automatizadas que se ejecutan como respuesta a los cambios enviados (commits). El hook es ejecutado por un cambio individual, se rellena con la información acerca del cambio y luego es liberada esa información para ser utilizada como se desee—por ejemplo, para enviar un correo electrónico.
Con los sistemas de correos con cambios ya listos para usar, quizás sea necesario modificar alguna de las siguientes conductas:
1. Algunos de estos sistemas no incluyen el diff en el correo que envían sino que enlazan con una URL para poder ver el cambio en la web utilizando el sistema de navegación del repositorio. Aunque está bien dar una URL para que se pueda revisar el cambio luego, también es muy importante que el correo del commit incluya los diff. Leer el correo electrónico ya es parte de la rutina de la gente, así que si el contenido es visible allí mismo en el correo, los desarrolladores podrán revisar el commit en el mismo sitio sin la necesidad de abandonar sus clientes de correo. Si tienen que seguir un enlace a una página de revisiones, muchos no lo pulsarán, ya que esto requiere de una nueva acción en lugar de una continuación de lo que ya estaban haciendo. Por si fuera poco, si el lector desea preguntar algo acerca del cambio, es mucho más fácil responder al mensaje incluyendo el texto original y simplemente realizar anotaciones en el diff, en lugar de tener que visitar una página web y tomarse la molestia de copiar y pegar partes del diff en el navegador web al cliente de correo.
(Por supuesto que si el diff es gigantesco, como cuando una gran parte de código nuevo ha sido añadido al repositorio, entonces tiene sentido omitir la parte del diff y ofrecer sólo la URL. Muchos de los sistemas permiten hacen esto automáticamente. Si el utilizado en el proyecto no es capaz de hacer esto, entonces sigue siendo mejor incluir los diffs completos. La conveniencia de la revisión y los comentarios es una piedra angular del desarrollo cooperativo, algo demasiado importante para olvidar.)
2. Los correos con los cambios deben tener su cabecera Reply-To direccionada hacia la lista regular de desarrollo, no a la lista de los cambios, de esta manera cuando alguien revise un cambio y escriba una respuesta, esta debe ser dirigida automáticamente a la lista de desarrolladores, donde los temas técnicos son discutidos normalmente. Existen varias razones para esto, primero, se quiere mantener todas las discusiones técnicas en la lista, porque es allí donde la gente espera que sucedan y porque así ésta es la única lista que será necesario archivar. Segundo, puede que existan partes interesadas no suscritas a la lista de cambios. Tercero, la lista de cambios es publicitada como una lista para los commits y no como una lista para los commits y las discusiones técnicas ocasionadas. Quienes se han suscrito sólo a la lista de cambios, no se han suscrito a nada más que commits, al enviarles correos con material sin relación utilizando ésta vía, es una violación del contrato implícito. Cuarto, algunas personas escriben programas que procesan los correos con los cambios (para publicarlos en una página web, por ejemplo). Estos programas están preparados para manejar correos con un formato consistente y son incapaces de trabajar con correos escritos por humanos.
Hay que señalar que ésta recomendación no contradice las recomendaciones anteriores en “El gran debate del Reply-To”. Siempre está bien que el remitente del mensaje configure la cabecera Reply-to. En este caso, el remitente es el sistema de control de versiones y su Reply-to lo configura de tal manera que indique que el lugar apropiado para responder es la lista de desarrollo y no la lista de cambios
CIA: Otro mecanismo de publicación de cambios
Los correos con los cambios no son la única forma de propagar las noticias de los cambios. Recientemente, otro mecanismo llamado CIA ( cia.navi.cx/ ) ha sido desarrollador. Este es un distribuidor y AGGREGATOR de estadísticas de cambios. El uso más popular de CIA es el de enviar notificaciones de los commits a un canal IRC de forma que las personas en el canal pueden ver los commits en tiempo real. Aunque es una utilidad menos técnica que los correos electrónicos, ya que los observadores puede que estén o no conectados cuando las alertas sobre nuevos cambios llegan al canal, esta técnica tiene una inmensa utilidad social. La gente tiene la sensación de pertenecer a algo vivo y activo, y siente que pueden ver el progreso que se está haciendo ante sus propios ojos.
El programa de notificaciones del CIA es invocado por el post-commit hook, da formato al commit en un mensaje XML y lo envía al servidor central (por lo general cia.navi.cx). Este servidor luego distribuye la información a los otros foros.
CIA también puede ser configurado para enviar feeds RSS. Más detalles en la documentación en cia.navi.cx/ .
Para ver un ejemplo de CIA en acción conéctese a irc.freenode.net, y al canal#commits.
Las ramas para evitar cuellos de botella
Los usuarios inexpertos del control de versiones pueden sentirse temerosos de crear ramas y uniones. Esto sea probablemente un efecto colateral de la popularidad de CVS: su interfaz de ramas y uniones puede ser poco intuitivo, así que muchas personas han aprendido a evitar estas operaciones por completo.
Si se encuentra entre estas personas, decídase ahora mismo a conquistar cualquier miedo que pueda tener y tómese el tiempo de aprender cómo funcionan las ramas y las uniones. No son operaciones muy complicadas una vez que se acostumbra a ellas y se vuelven muy importantes mientras el proyecto adquiere más desarrolladores.
Las ramas son muy importantes porque convierten un recurso escaso—espacio de trabajo en el código del proyecto—en uno abundante. Normalmente, todos los desarrolladores trabajan juntos en la misma caja de arena, construyendo el mismo castillo. Cuando alguien desea añadir un nuevo puente levadizo, pero no puede convencer a los demás de que sería una mejora, entonces las ramas hacen posible que vaya a una esquina aislada donde probar su puente. Si el esfuerzo tiene éxito, puede invitar a otros desarrolladores para que evalúen el resultado. Si todos están de acuerdo en que el resultado es bueno, pueden hacer que el sistema de control de versiones mueva ("merge") el puente levadizo de la rama del castillo a la rama principal del castillo.
Es fácil ver como esta habilidad ayuda al desarrollo colaborativo, ya que la gente necesita de cierta libertad para probar cosas nuevas sin sentir que están interfiriendo con el trabajo de otros. Igual de importante es cuando el código debe ser aislado del CHURN usual de desarrollo de manera que un fallo sea reparado o un lanzamiento sea estabilizado (más en “Stabilizing a Release” y en “Maintaining Multiple Release Lines”en Capítulo 7, Packaging, Releasing, and Daily Development) sin la preocupación de seguir un blanco en movimiento.
Hay que utilizar las ramas libremente y fomentar su uso entre otros. Pero también hay que asegurarse de que una rama en particular se mantenga activa exactamente durante el tiempo que sea necesaria. Incluso quienes no trabajan en la rama principal mantienen una visión periférica de lo que está sucediendo en ésta. Esta visión es deseable, por supuesto, y los correos con cambios deben salir de estas ramas como de cualquier otra. Pero las ramas no deben convertirse en un mecanismo que divida a la comunidad de desarrolladores. Con raras excepciones, el objetivo eventual de la mayoría de las ramas debe de ser su unión a la rama principal y desaparecer.
Singularidad de la información
Las uniones tienen un corolario importante: nunca se debe enviar el mismo cambio dos veces, es decir, un cambio dado sólo debe ser introducido al sistema de control de versiones solo una vez. La revisión (o conjunto de revisiones) en la que el cambio es introducido es su identificador único desde ese momento. Si debe ser aplicado a otras ramas aparte de la cual en la que ha sido hecho, entonces deberá ser unido desde su punto de entrada original a sus otros destinos —al contrario de enviar cambios textualmente idénticos, que tendrían el mismo efecto en el código, pero harían del mantenimiento eficaz y de la gestión de lanzamientos una tarea imposible.
Los efectos prácticos de este consejo difieren entre sistemas de control de versiones. En algunos sistemas, las uniones son eventos especiales, fundamentalmente distintos de los commits y acarrean sus meta-datos propios. En otros, el resultado de las uniones son enviadas de la misma manera que los cambios son enviados así que la mejor manera de distinguir una unión de un nuevo cambio es leyendo los mensajes de registro. El mensaje de registro de una unión no repite el mensaje de registro del cambio original, en cambio, sólo indica que es una unión y da la identificación de la revisión del cambio original, con como mucho una línea de sumario del sus efectos. Si alguien desea ver el mensaje de registro completo, deberá consultar la revisión original.
La razón por la cual es importante evitar la repetición de los mensajes de registro es que estos pueden ser editados después de que se hayan enviado. Si un mensaje de registro es repetido en el destino de cada unión, entonces incluso si alguien edita el mensaje original, deja todos los otros mensajes sin corregir—lo cual sólo puede causar confusión a largo plazo.
El mismo principio se aplica al retirar un cambio. Si esto llegara a suceder, entonces el mensaje de registro para la retirada solo debe indicar que una revisión en particular está siendo retirada, no debe describir el cambio en el código resultante, pues la semántica del cambio se puede intuir al leer el mensaje de registro original del cambio. Por supuesto, el mensaje de registro del retiro también debe indicar la razón por la cual ese cambio ha sido retirado, pero no debe duplicar nada del mensaje de registro del cambio original. Si es posible, hay que volver y editar el mensaje de registro original para señalar que ha sido retirado.
Todo lo anterior implica que se debe utilizar una sintaxis consistente al referirnos a las revisiones. Esto es de gran ayuda no sólo en los mensajes de registro, sino en los correos electrónicos, en el gestor de fallos y en todas partes. Si se está utilizando CVS, recomiendo "directorio/al/fichero/del/proyecto/rama:REV", donde REV es un número de revisión en CVS como "1.76". Si se está utilizando Subversion, la sintaxis estándar para la revisión 1729 es "r1729" (el directorio de los ficheros no es necesario porque Subversion utiliza números globales para las revisiones). En otros sistemas, existe por lo general una sintaxis estándar para expresar el nombre del conjunto de cambios. Cualquiera que sea la sintaxis apropiada para el sistema utilizado, hay que animar a la gente a que lo utilicen al referirse a algún cambio. El uso consistente en el nombre de los cambios permiten que el mantenimiento del proyecto sea mucho más sencillo (como ya veremos en Capítulo 6, Comunicaciones y en Capítulo 7, Packaging, Releasing, and Daily Development), y dado que mucho de este mantenimiento será realizado por voluntarios, debe ser lo más sencillo posible.
Más información en “Releases and Daily Development” Capítulo 7, Packaging, Releasing, and Daily Development.
Autorizaciones
Muchos de los sistemas de control de versiones ofrecen la posibilidad por la cual a ciertas personas se les permite o no, realizar cambios en áreas específicas del repositorio. Siguiendo el principio de que cuando a las personas se les entrega un martillo empiezan a buscar clavos para golpear, muchos proyectos utilizan esta característica con ABANDON, permitiendo cuidadosamente el acceso solo a las áreas donde tienen permiso de enviar cambio y asegurándose de que no lo puedan hacer en ningún otro sitio. (Más información en “Committers” Capítulo 8, Coordinando a los Voluntarios sobre como los proyectos deciden quienes pueden hacer cambios y donde.)
Probablemente hayan pequeños daños implementar un control así de estricto, pero una política un poco más relajada también está bien. Algunos proyectos utilizan un sistema basado en el honor: cuando a una persona se le permite la posibilidad de realizar cambios, aunque sea a una pequeña área del repositorio, lo que reciben es una contraseña que les permite realizar cambios en cualquier otro sitio del repositorio y sólo se les pide que mantengan sus cambios en su área. Hay que recordar que no existe ningún peligro aquí: de todas formas, en un proyecto activo, todos los cambios son revisados. Si alguien hace un cambio donde no debía, alguien más se dará cuenta y dirá algo. Es muy sencillo si un cambio debe ser rectificado—todo está bajo el control de versiones de todas formas, así que sólo hay que volver atrás.
Existen varias ventajas en tal aproximación tan relajada. Primero, mientras los desarrolladores se vayan expandiendo en las diferentes áreas (lo cual harán a menudo si siguen en el proyecto), no es necesario un trabajo administrativo extra de tener que dar y quitar privilegios. Una vez que la decisión es tomada, la persona puede empezar a enviar sus cambios a la nueva área sin problemas.
Segundo, la expansión se puede filtrar mejor, ya que generalmente, quienes realizan cambios en el área X y desean expandirse al área Y sólo tienen que empezar a enviar sus cambios contra Y y solicitar su revisión. Si alguien con acceso a cambios al área Y recibe alguno de estos parches y lo aprueba, puede pedir que el cambio sea enviado directamente (mencionando el nombre de quien ha revisado/aprobado el cambio en el mensaje de registro). De esta manera, el commit vendrá de quien ha hecho el cambio, lo cual es preferible desde un punto de vista administrativo y de credibilidad.
Por último, y quizás la razón más importante, al utilizar un sistema basado en el honor, se crea una atmósfera de confianza y respeto mutuo. Al darle a alguien permiso para enviar cambio a un subdominio se hace una declaración acerca de su preparación técnica—la cual dice: "Hemos visto que tienes la capacidad para realizar cambios en cierto dominio, así que a por ello". Pero imponer controles estrictos en las autorizaciones dice: "No sólo estamos juzgando tus limitadas capacidades, sino que también sospechamos de tus intenciones." Este no es el tipo de declaraciones que se desean hacer si pueden ser evitadas. Incluir a alguien dentro del grupo de desarrolladores del proyecto es una oportunidad de iniciarlos en un círculo de confianza mutua. Una buena manera de hacer esto es dar más poder del que se supone deben tener e informarles que es su responsabilidad mantenerse dentro de los límites impuestos.
El proyecto Subversion ha operado bajo este sistema por más de cuatro años, con 33 desarrolladores con privilegios completos y 43 con privilegios parciales. La única distinción que el sistema fuerza esta entre quienes envían cambios y quienes no, otras divisiones son mantenidas sólo por humanos. Incluso así, nunca hemos tenido ningún problema con que alguien realice un cambio deliberado fuera de su dominio. Una que otra vez han habido inocentes mal entendidos sobre la extensión de los privilegios de alguna persona, pero siempre es resuelto rápida y amigablemente.
Obviamente, en situaciones donde esto es poco práctico se debe depender en controles estrictos en las autorizaciones, pero dadas situaciones son raras. Incluso cuando hay millones de líneas de código y ciento o miles de desarrolladores, un commit hecho a cualquier módulo del código sigue siendo revisado por quienes trabajan en dicho módulo y son quienes pueden reconocer si quien lo ha intentado hacer puede hacerlo. Si una revisión regular no está sucediendo entonces el proyecto tiene problemas más importantes con los cuales lidiar que el sistema de autorizaciones.
Para concluir, no hace falta pasar mucho tiempo con las autorizaciones del sistema de control de versiones a menos que se tenga una razón en específico. Usualmente esto no trae beneficios tangibles y confiar en el control humano tiene sus ventajas.
Por supuesto que nada de esto significa que las restricciones mismas son poco importantes. Sería malo para un proyecto el animar a las personas a realizar cambios en áreas para las cuales no están cualificadas. Incluso en algunos proyectos, el acceso ilimitado tiene un status especial: implica derecho de voto en cuestiones que atañen al proyecto por completo. Este aspecto político del acceso es discutido en mayor profundidad en “¿Quién Vota?” en Capítulo 4, Infraestructura Social y Política.

________________________________________
[15] Más información en cia.vc/stats/vcs y para evidencia sobre su crecimiento enhttp://subversion.tigris.org/svn-dav-securityspace-survey.html .
[16] Alexey Mathotkin tiene una opinión diferente sobre el tema de controlar las versiones de los ficherosconfigure en un artículo llamado "configure.in and version control" enhttp://versioncontrolblog.com/2007/01/08/configurein-and-version-control/.



ALvaro

Por favor, Identificarse o Crear cuenta para unirse a la conversación.

Tiempo de carga de la página: 0.149 segundos