Uno de los puntos fuertes de Visual Studio Team System es que cuando creamos nuestros proyectos nos permite seleccionar la metodología con la que se gestionará el mismo. La metodología que elijamos marcará como distribuiremos y planificaremos todas las tareas necesarias para llevar a cabo el proyecto. Ya que existen una gran cantidad de metodologías y para hacer el producto lo mas versátil posible, se dotó a VSTS con un mecanismo para poder crear nuevas plantillas que definieran los procesos de cualquier metodología. Al producto la acompañan dos plantillas de proceso diferentes, la de MSF for Agile y MSF for CMMI, pero existen muchas otras plantillas, algunas creadas por Microsoft, como eScrum u otras de terceros como puede ser la famosa Scrum For Team System de Cochango. Algunas de estas plantillas han sido creadas como proyectos de código abierto, otras son simplemente gratuitas y también las hay de pago.
A pesar de la gran cantidad de plantillas que existen, la gran mayoría de ellas bajo mi punto de vista (y que conste que no soy un experto en metodologías ni mucho menos) están mas enfocadas al ciclo de creación de un nuevo software que al mantenimiento del mismo. Si bien Scrum por ejemplo puede ser utilizado para la gestión de Bugs, ya que solo dice como hay que organizarse no que estamos organizando, la realidad es que el departamento de desarrollo de nuevas aplicaciones y el de mantenimiento de las mismas se gestionan de formas muy diferentes normalmente. Por ejemplo, en muchas ocasiones los que nos dedicamos a la consultoría llegamos a un cliente hacemos un desarrollo a medida y es el cliente final el que se encarga de su mantenimiento.
Una vez que esta aplicación esta lista y pasa a un estado de mantenimiento, la mayoría de tareas que se hacen, basándome en mi experiencia, es bug fixing. Suele existir un grupo de personas que se encargan de trasladar los bugs encontrados por los usuarios al equipo de mantenimiento y estos en base a su criticidad, impacto o tipo asignan prioridades para la resolución de los mismos. En este punto el proceso se convierte en algo parecido a una cola donde se van apilando bugs y se van desapilando en base a su prioridad, ya no existen áreas e iteraciones, o sprints, no existe una fecha final, ni unos requisitos específicos, solo que corrijan los bugs de la versión que hay en producción y que los usuarios puedan utilizar el producto. Quizá esta visión este mas enfocada a esa gran cantidad de herramientas que poseen las compañías para la gestión interna de sus procesos y menos a un software que se venda como producto a un usuario final, pero este escenario que planteo es muy común y creo que todos lo hemos visto o vivido.
Llegados a este punto la pregunta es, ¿necesitamos nuevas plantillas de proceso?
A mí se me ha planteado este escenario recientemente y tras evaluar como gestionarlo con Scrum o con cualquier otra metodología, mi decisión ha sido crear una nueva plantilla de proceso. Para llegar a esta decisión me plantee una serie de preguntas y analice como de factibles eran con cada una de las opciones, plantilla nueva o una existente.
Por ejemplo, ¿cuando finaliza el desarrollo? ¿tenemos un objetivo claro?. Ante estas dos preguntas las respuestas son que no tenemos una fecha de fin ni un objetivo claro que alcanzar, solo que se corrijan los bugs que se encuentren. Si usasemos una plantilla existente de una metodología no podríamos crear sprints o áreas e iteraciones, porque no hay un objetivo tangible que alcanzar ni en una fecha concreta. En este aspecto, mi opinión es que al no haber un objetivo claro ni puntos en el tiempo que vayan marcando hitos, una metodología que se base en estas cosas no es adecuada, por lo tanto usar una plantilla ya existente es bastante complicado.
Pero si obviasemos el aspecto que he comentado anteriormente y optasemos por una plantilla existente, nos surgirían otros temas como por ejemplo si nos sirven o no los tipos de WorkItems de la plantilla. Ahora necesitamos información de otro tipo, como los datos aportados por el usuario, si sabe como replicar el bug, comentarios entre los que recogen los bugs que encuentran los usuarios y los desarrolladores, en definitiva, un montón de datos adicionales que requerirían de la personalización o creación de un nuevo tipo de Work Item.
O también los tipos de reportes que necesitaría. En este aspecto ya no tienen mucho que ver los reportes que pueda aportarme una plantilla de Scrum como en Burndown chart o el Project Velocity de MSF Agile. Ahora quizás necesite ver cual es la tipología de los bugs, o el volumen de bugs solucionados por fechas, o porque no, el número de bugs que soluciona cada desarrollador, cuantos bugs se han rechazado, un punto de vista quizás mas enfocado al pasado-presente, que al presente-futuro que aportan las metodologías donde se tiene un objetivo que alcanzar.
A raíz de esto es muy probable que ponga posts relacionados con la creación y edición de plantillas de proceso, pero si me gustaría que antes de crear una plantilla de proceso os hagais estas y más preguntas para determinar si realmente necesitáis una plantilla de proceso. Yo a día de hoy aun no estoy seguro de si la decisión es correcta o no y eso lo iré viendo con el tiempo, por eso me gustaría lanzaros varias preguntas, ¿que opináis vosotros de todo este asunto? ¿os parece correcto usar Visual Studio Team System para este tipo de gestión? ¿creéis que es necesaria la creación de mas plantillas de proceso?
