|
|
| (No se muestran 11 ediciones intermedias del mismo usuario) |
| Línea 1: |
Línea 1: |
| | Para hacer uso del repositorio de forma fácil, será necesario que descargues a tu maquina local la estructura completa del mismo. De esta forma podrás acceder a toda la documentación existente de los proyectos Telstock, y podrás gestionar la edición y actualización del mismo. | | Para hacer uso del repositorio de forma fácil, será necesario que descargues a tu maquina local la estructura completa del mismo. De esta forma podrás acceder a toda la documentación existente de los proyectos Telstock, y podrás gestionar la edición y actualización del mismo. |
| | | | |
| − | Para descargar el repositorio necesitas lo siguiente: | + | Para descargar el repositorio necesitas lo siguiente:<br> |
| − | # Descarga el cliente SVN Tortoise [https://tortoisesvn.net/downloads.html aquí]
| |
| − | # Accede al [http://192.168.9.60:8080/scm/#repositoryPanel;5cQeSfAgN9 SCM Manager] que es la interfaz empleada para administrar los repositorios existentes.
| |
| | | | |
| − | {{notice | '''NOTA:''' Para acceder al SCM necesitarás el usuario y clave de repositorio. Si aún no la tienes, comunicate con el '''Coordinador de TI''' o '''PM''' para gestionarla.}}
| + | '''1.''' Descarga el cliente SVN Tortoise [https://tortoisesvn.net/downloads.html aquí]<br> |
| | | | |
| − | [[Archivo:Login SCM.png|marco|centro|Logueate al SCM para administrar tus repositorios]] | + | '''2.''' Accede al [http://192.168.9.60:8080/scm/#repositoryPanel;5cQeSfAgN9 SCM Manager] que es la interfaz empleada para administrar los repositorios existentes. |
| − |
| |
| − | # Una vez dentro del SCM, busca en el listado de repositorios el '''Telstock-Documentation''' y posicionate sobre el
| |
| | | | |
| | + | {{notice | '''NOTA:''' Para acceder al SCM necesitarás el usuario y clave de repositorio. Si aún no la tienes, comunicate con el '''Coordinador de TI''' o '''PM''' para gestionarla.}} |
| | | | |
| − | Llamamos '''Control de Cambio''' siglas '''CC''', al proceso mediante el cuál se gestionan, monitorean y controlan las modificaciones en las funcionalidades de un producto.
| + | [[Archivo:SCM Mini.png|centro|Logueate al SCM para administrar tus repositorios]] |
| − | | |
| − | '''Todo aquello que implique una variación en el flujo, y que requiera invertir tiempo de desarrollo, debe ser considerado un control de cambio.'''
| |
| − | | |
| − | Se pueden presentar bajo las siguientes circunstancias:
| |
| − | | |
| − | * '''Mejoras''' son todos aquellas modificaciones que generan impacto en los módulos o funcionalidades existentes, y que van enfocados en la optimización o renovación de estos, debido a cambios de lógica de negocio, cambio de alcance por parte del cliente, adaptaciones etc. '''''Usualmente se hacen a solicitud del cliente''''', sin embargo esto no es obligatorio. Existirán casos en los que el equipo de desarrollo, o cualquier otro participante del proyecto, genere la solicitud.
| |
| − | | |
| − | * '''Corrección de errores''' son todos aquellos cambios que se deban realizar a fin de eliminar un bug o error en alguna funcionalidad del aplicativo.
| |
| − | | |
| − | Los Controles de Cambio irán relacionados a las funcionalidades de aplicativos que están en '''ambiente productivo'''. En el caso de proyectos en desarrollo, sólo se manejarán para aquellos que se estén gestionando bajo metodologías lineales, esto quiere decir que no aplica para aquellos proyectos llevados por Sprint´s, Ciclos o Metodologías Evolutivas.
| |
| | | | |
| − | Las solicitudes de cambio pueden ser registrados por cualquier persona '''( STAKEHOLDERS )''' que tenga algún interés en el proyecto, siempre y cuándo tenga las bases que sustenten el cambio y la justificación del mismo.
| + | '''3.''' Una vez dentro del SCM, busca en el listado el repositorio '''Telstock-Documentation''' y posiciónate sobre el. En la sección de detalle del repositorio, '''copia la url del ítem Checkout'''.<br> |
| − | | |
| − | #
| |
| − | == Software estándar a utilizar ==
| |
| − | El levantamiento de un '''CC''' se realiza a través del aplicativo [https://mantisbt.tmanager.com.mx/mantisbt/login_page.php/ Mantis].
| |
| − |
| |
| − | == Flujo de proceso ==
| |
| − | En esta sección se describirá el flujo de proceso para un '''CC''': | |
| | | | |
| − | === 1. Alta de la solicitud (Ticket): ===
| |
| − | Este flujo marca el inicio de un Control de Cambio, ya que representa su registro formal.
| |
| − | Para dar de alta una solicitud, es necesario que se tengan todos los datos que se deberán considerar para poder atenderlo.
| |
| | | | |
| − | *Para los casos de '''CC por Mejoras''', será necesario detallar las reglas de negocio, flujos, vistas y cualquier información adicional que complemente el requerimiento. Esta información podrá ir contenida de forma precisa en una '''Historia de Usuario''', la cuál deberá adjuntarse al ticket de Mantis.
| + | [[Archivo:SCM Mini 01.png|centro|Ubica el repositorio y copia la url de Checkout]] |
| | | | |
| − | *Para los casos de '''CC por Corrección de Errores''', será necesario especificar los detalles del error, pasos para reproducir y adjuntar las evidencias, a fin de facilitar la replica del escenario.
| + | '''4.''' Crea la carpeta '''Telstock-Documentation''' en la ubicación de tu preferencia, haz click derecho sobre ella y selecciona la opción '''SVN Checkout'''.<br> |
| | | | |
| − | Para obtener más detalles sobre el flujo de registro de una solicitud de '''CC''', por favor verificar el apartado de *[[Campos estándar de CC]].
| |
| | | | |
| | + | [[Archivo:SvnCheckout.png|centro|Haz Checkout del repositorio en tu carpeta local]] |
| | | | |
| − | === 2. Revisión de la solicitud (Ticket): ===
| + | '''5.''' Pega la Url copiada del SCM y acepta. El sistema te pedirá introducir usuario y contraseña de repositorio (emplea las mismas con las que accediste al SCM). Una vez hecho esto, el SVN Tortoise iniciará el proceso de descarga del repositorio a tu máquina.<br> |
| | | | |
| − | Una vez dada de alta la solicitud:
| |
| | | | |
| − | El '''Gestor de proyectos''' realiza una revisión de toda la información contenida en el Ticket.
| + | [[Archivo:SvnCheckout01.png|centro|Copia la URL y descargar el repositorio]] |
| − |
| |
| − | Si considera que la información proporcionada es insuficiente:
| |
| | | | |
| − | a. Cambiará el estado del Ticket a '''SE NECESITAN MAS DATOS''' en el Mantis.
| |
| − | b. Añadirá una nota etiquetando al '''STAKEHOLDER''' que registró el Ticket, para indicarle el detalle de la información que hace falta.
| |
| − |
| |
| − | En caso contrario a lo descrito anteriormente:
| |
| − |
| |
| − | a. Cambiará el estado del Ticket a '''ACEPTADO''' o asignará el Ticket a un '''Desarrollador''' en el Mantis.
| |
| − | {{warning|'''IMPORTANTE:''' La atención a las solicitudes dependerá de su prioridad, y de la disponibilidad de desarrolladores.}}
| |
| − |
| |
| | | | |
| − | {{notice | '''NOTA:''' Si el estado del Ticket es '''ACEPTADO''', solo quiere decir que el '''Gestor de proyectos''' ya lo recibió y valido la información contenida en el. '''No quiere decir que el Ticket ya esta siendo atendido'''. Es posible que el '''Gestor de proyectos''' pueda contactar al '''STAKEHOLDER''' para solicitar información adicional a la que se tiene en el Ticket}}
| |
| − |
| |
| − |
| |
| − | === 3. Asignación de la solicitud (Ticket): ===
| |
| − | La asignación de una solicitud de '''CC''' puede ser realizada por:
| |
| − |
| |
| − | '''Desarrollador:'''
| |
| − | Se define '''( Auto asignación )'''. Lo que se busca con esto es fomentar la iniciativa del '''Desarrollador''', su capacidad de '''Autogestión''' y de '''Autorganizacion'''. Es importante que el '''Desarrollador''' antes de asignarse una solicitud (Ticket) considere los siguientes aspectos:
| |
| | | | |
| − | a. No tener actividades mapeadas en un '''Sprint''' o '''Cronograma''' activo de mayor relevancia o prioridad.
| |
| − | b. Que se tenga conocimiento del aplicativo bajo el cual fue registrada la solicitud, en caso de que sean solicitudes de '''CC''' de prioridad '''Alta'''. Esto para evitar que exista desviación de tiempo por desconocimiento de la plataforma/tecnología/reglas de negocio.
| |
| − |
| |
| − | Si son solicitudes de '''CC''' de prioridad '''Normal''' o '''Baja''', el '''Desarrollador''' puede asignarse la solicitud (Ticket) aunque no tenga conocimiento del proyecto, para este caso sera necesario que valide con el '''Gestor''' o '''Coordinador''' de '''proyectos''' si puede tomar esta actividad.
| |
| − |
| |
| − | '''Gestor de proyectos/Coordinador de proyectos''':
| |
| − | a. Esta asignación se hace directamente por cualquiera de los roles antes mencionados y se realiza de acuerdo a la prioridad que tenga el Ticket.
| |
| − |
| |
| − | === 4. Análisis de la solicitud (Ticket): ===
| |
| − | Una vez que la solicitud fue '''Auto Asignada''' o recibió '''Asignación directa por el Gestor o el Coordinador de proyectos''',
| |
| − | el '''Desarrollador''' procederá a realizar lo que se describe a continuación:
| |
| − |
| |
| − | a. Documentar el campo '''Descripción técnica''' en el Mantis, realizando un previo análisis de los artefactos que van a sufrir cambios.
| |
| − | Es necesario que liste los artefactos como pueden ser:
| |
| − | '''* Clases'''
| |
| − | '''* Métodos'''
| |
| − | '''* Base de datos:'''
| |
| − | '''* Procedimientos'''
| |
| − | '''* Tablas'''
| |
| − | '''* Vistas'''
| |
| − | '''* Funciones'''
| |
| − | Que van a ser modificados a nivel de código fuente.
| |
| − |
| |
| − | b. Recurrir al '''Gestor''' o '''Coordinador''' de proyectos, cuando implique cambios a otras áreas de desarrollo (Web Service, Back Office, etc). A fin de que ellos puedan asignar un desarrollador adicional, para que apoye en el área que corresponda.
| |
| | | | |
| − | {{notice | '''NOTA:''' Este último punto aplica para aquellos casos en que el responsable desconozca las otras áreas de desarrollo. Los '''desarrolladores FULL STACK''', podrán hacer el análisis integral de la solución}} | + | {{notice | '''NOTA:''' Para mayor información sobre el uso del SVN Tortoise, ve a la pagina oficial del producto}} |
| − | | |
| − | c. Documentar en el campo '''Tiempo estimado''' los tiempos que se van a utilizar para la solución del '''CC''', tomando en cuenta:
| |
| − | * '''Tiempo de Desarrollo de áreas involucradas.'''
| |
| − | * '''Pruebas Unitarias.'''
| |
| − | * '''Pruebas de Integración.''' (Para los casos en que aplique)
| |
| − | d. El área de '''QA''' debe documentar en el campo '''Tiempo estimado QA''', los tiempos de pruebas a realizar de acuerdo a la información que se tenga en la solicitud de '''CC'''. Si este campo no esta documentado, el '''Gestor de proyectos''' solicitará al área de QA que documente sus tiempos estimados de pruebas de QA.
| |
| − |
| |
| − | {{notice | Las pruebas unitarias deben contemplar el tiempo de diseño y ejecución en el '''TestLink'''.}}
| |
| − | {{notice | Es importante mencionar que si existen otras solicitudes de controles de cambio que tengan que ver con la solicitud de cambio actual, se relacionen mediante el apartado '''Relaciones''' de Mantis. Este punto deberá ser considerado por el '''SOLICITANTE''', el equipo de '''QA''', y '''PM'''.}}
| |
| − |
| |
| − | === 5. Aprobación de la solicitud (Ticket): ===
| |
| − | Una solicitud de control de cambio es '''APROBADA''' cuando aparece en el campo '''Aprobado''' la palabra '''SI'''
| |
| − |
| |
| − | Una vez que se tiene la información en los campos '''Descripción técnica''' y '''Tiempo estimado''', el '''Gestor de proyectos''' solicita la aprobación del control de cambio a la '''Directiva''' para su resolución.
| |
| − |
| |
| − | La '''Directiva''' revisa la solicitud del control de cambio en el Mantis para aprobarlo o no.
| |
| − |
| |
| − | [[Archivo: APROBACION.JPG | Campo: Aprobación de una solicitud en Mantis]]
| |
| − |
| |
| − | === 6. Resolución de la solicitud (Ticket): ===
| |
| − | Una vez que la solicitud del control de cambio ha sido '''APROBADA''', el '''Desarrollador''' procederá a realizar lo que se describe a continuación:
| |
| − | a. Llevar a cabo la implementación de la solución del '''CC''', de acuerdo a la información registrada en el campo '''Descripción'''.
| |
| − | b. Una vez que haya realizado el desarrollo, realizará el proceso de las '''Pruebas Unitarias''' y '''Pruebas de Integración'''
| |
| − | a través del [https://mantisbt.tmanager.com.mx/testlink/login.php/ TestLink].
| |
| − | c. Generará el reporte de '''Pruebas Unitarias''' en formato de archivo '''PDF''' y lo incluirá en el repositorio de
| |
| − | [http://192.168.9.60:8080/scm/svn/Telstock-Documentation/ Telstock] en la ubicación que corresponda al proyecto.
| |
| − | d. Una vez que el proceso de las '''Pruebas Unitarias''' y '''Pruebas de Integración''' sea correcto, el '''Desarrollador''' procederá al despliegue de los cambios a los artefactos al ambiente de QA.
| |
| − | e. Una vez que el ambiente de QA este totalmente listo, el '''Desarrollador''' cambiara el estatus de la solicitud de '''CC''' a '''RESUELTA''' en el Mantis:
| |
| − | [[Archivo: ESTADO_RESUELTO_A.JPG | Campo: Estado de la solicitud a RESUELTA de una solicitud en Mantis]]
| |
| − | f. El '''Desarrollador''' añadirá una nota al Ticket, indicando al '''QA Manager''' la siguiente información:
| |
| − |
| |
| − | Atención a '''QA Manager'''
| |
| − |
| |
| − | " Por favor apoyarnos con las pruebas del presente control de cambio.
| |
| − | Las '''Pruebas Unitarias''' se encuentran en el repositorio en la ruta (Ruta repositorio)
| |
| − | Y en el TestLink en la ruta (Ruta TestLink).
| |
| − | La información para las pruebas es la siguiente:
| |
| − | * Url del aplicativo:
| |
| − | * Usuarios de prueba:
| |
| − | * Contraseñas:
| |
| − | * Versión del APK (Si aplica) que se esta liberando:"
| |
| − |
| |
| − | === 7. Validación de solicitud (Pruebas QA): ===
| |
| − | Una vez que el estatus de la solicitud de control de cambio sea '''RESUELTO''', '''QA''' procederá a realizar lo que se describe a continuación:
| |
| − | a. Validar que tiene la información completa de las '''Pruebas Unitarias''', y que pueda acceder al ambiente con toda la información suministrada por el desarrollador.
| |
| − | b. Ejecutar los escenarios de prueba considerando el tiempo estimado que se colocó en la solicitud.
| |
| − | c. Si al ejecutar los escenarios de prueba existen incidencias relacionadas al control de cambio entonces:
| |
| − | 1. '''QA''' registrará en Mantis las incidencias encontradas, haciendo una solicitud de alta, similar a lo descrito en el apartado '''''Alta de la solicitud (Ticket))'''''.
| |
| − | 2. '''QA''' relacionará el Ticket de la incidencia a la solicitud de '''CC''' inicial.
| |
| − | 3. El '''Desarrollador''' corrige las incidencias de acuerdo a lo considerado en el apartado: '''''Resolución de la solicitud (Ticket)''''' descrito anteriormente.
| |
| − | 4. '''QA''' valida la corrección de las incidencias y cierra aquellas que estén resueltas y reasigna las que aun no estén.
| |
| − | b. Si al final de la ejecución de los escenarios de prueba no existe ninguna incidencia, '''QA''' coloca como nota en la solicitud (Ticket) el Vo.Bo en el siguiente formato:
| |
| − |
| |
| − | '''Se validó el presente control de cambio con todos los escenarios exitosos, se da el Vo.Bo de QA'''
| |
| − | Y deberá agregar la siguiente información:
| |
| − | * Ruta de repositorio en donde está la matriz de pruebas.
| |
| − | * Ruta de repositorio en donde está el reporte de pruebas.
| |
| − | c. El '''Gestor de Proyectos''' procede a cerrar la solicitud (Ticket).
| |
| − | {{warning | '''QA''' debe establecer los limites de sus pruebas, dentro del tiempo inicial que se estimó.}}
| |
| − | {{warning | La gestión de las incidencias de QA por parte del '''Desarrollador''', debe ser similar a un Ticket de control de cambio normal, la única diferencia es que no se va a solicitar aprobación para aplicar la solución, ya que se entiende que es derivada de la solicitud inicial. Estos incidencias, unicamente pueden ser asignados por el '''QA Manager'''.}}
| |
