Que las empresas opten en algún momento por permitir que sus
desarrolladores dejen de aplicar rigurosamente la metodología es algo
que ocurre frecuentemente y por la necesidad de no entorpecer la
productividad de las versiones que se distribuyen a los usuarios, frente
a necesidades de cambios donde es casi imposible determinar su
ocurrencia dado los vaivenes de las necesidades de negocio.
El primer problema con el proceso de desarrollo de
aplicaciones es lograr que sea conocido (comprendido) por el equipo de
trabajo. Luego viene el problema siguiente: conseguir que sea aceptado
Por qué ese malestar con las metodologías? Cuáles son las
razones por las cuales las necesidades de cierta rigidez en los procesos
terminan endureciendo la productividad? Acaso existe un punto de
equilibrio entre formalismo y agilidad? De ser así, cómo se lo descubre?
Cómo se lo alcanza?
A principios de los ’90 Microsoft comenzó a recopilar a nivel
interno las mejores prácticas en términos de procesos de desarrollo de
software, no con la intención de establecer una metodología, sino con la
idea de tener una colección de prácticas individuales de lo que funciona, aplicables dentro de determinados contextos
Aquí no se buscó reinventar ninguna rueda sino que a esta colección iban a parar tanto prácticas made in Microsoft como prácticas populares de la industria, por ejemplo, la de formalizar como parte del proceso las pruebas unitarias
Así es como surge Microsoft Solution Framework (MSF o, pronunciado, em-es-ef),
no una metodología en sí, sino prácticas que, de acuerdo al contexto de
proyecto (tamaño del equipo, frecuencia de entregas, etc) serán más o
menos recomendables de aplicar. De manera tal que para cada proyecto se
podrán seleccionar aquellas prácticas que realmente agreguen valor al
proceso (de ahí el concepto de framework, por si algún despistado pensó que podría tratarse de un framework de software como lo es Spring, Struts o la Enterprise Library)
Cada práctica se compone de una secuencia de actividades. Estas se describen en ETVX, un modelo de documentación de procesos introducido en los ’80 que sirve para representar Criterio de Entrada, Tareas, Verificaciones y Validaciones y Criterio de Salida. Un ejemplo de práctica puede ser Crear Arquitectura de Solución, la que a su vez se descompone en actividades como Particionar el Sistema, Determinar Interfaces, Crear el Prototipo de Arquitectura y Crear la Infraestructura, entre otras
Las prácticas generan resultados tangibles en la forma de work products (productos de trabajo), análogos aunque no necesariamente los mismos que los artifacts (artefactos) de UP. En el ejemplo del párrafo anterior, Diagrama de Aplicación, Diagrama de Sistema, Modelo de Amenazas de Seguridad son posibles work products
Como contaba al comienzo, todo esto puede sonar interesante como
concepto, pero aplicarlo sin herramientas adecuadas, integradas a los
mismos mecanismos por los cuales se generan los productos de trabajo
obliga a los integrantes del equipo de desarrollo a usar distintas
herramientas para completar las diferentes etapas. Esto desde luego
genera un overhead que abre la puerta a la posibilidad de comenzar a incumplir con las formalidades del proceso
La próxima versión de Visual Studio Team System permite definir procesos MSF
y crear proyectos de equipo que se enmarquen dentro de los mismos. Por
defecto ya vienen dos procesos: uno ágil y el otro formal. Pero además
pueden conseguirse adaptaciones de terceros o incluso adaptaciones
hechas por uno mismo, ya que el nuevo Visual Studio tiene un manager de
procesos
Voy a profundizar en el proceso ágil. En otro post me voy a ocupar del proceso formal (que está pensado para certificación CMMI). El proceso MSF Ágil
es un típico proceso iterativo que incrementalmente va aproximando
entregables de mayor fidelidad. En eso no es distinto de UP claro que
este proceso ágil está pensado para equipos reducidos. Tampoco está
dirigido unicamente por casos de uso (que aquí se llaman escenarios y
cubren cierta info específica del actor o persona) sino también
por requerimientos de calidad de servicio (como performance o
seguridad). Otra diferencia con UP es que aquí tiene mayor relevancia el
análisis de riesgos
Los roles intervinientes dentro del proceso MSF Ágil son
mayormente 6: Analista de Negocio, Jefe de Proyecto, Arquitecto,
Desarrollador, Tester y Administrador de Releases. No necesariamente
esos roles deban ser mapeados a personas diferentes. Si bien ciertos
roles pueden ser realizados por una misma persona, hay otras
combinaciones en las que eso no es lo deseable
El proceso MSF Ágil se compone de un conjunto de 14 workstreams. Cada uno gira en torno a un rol responsable aunque sus actividades constituyentes pueden involucrar al resto de los miembros
Las actividades atómicas se asignan y trackean mediante el concepto de work items (ítem de trabajo). En el proceso MSF Ágil los ítems de trabajo que encontraremos en general son Escenario, Requerimiento de Calidad de Servicio, Riesgo, Tarea a Desarrollar o Bug. En otros procesos más elaborados podríamos encontrar estos y/u otros ítems de trabajo
El proceso completo MSF Ágil puede obtenerse aquí. No obstante estar aún en beta, las actualizaciones se irán descargando allí mismo
Es interesante conocer, para que MSF no termine yendo a
parar a la fuente de los buenos deseos como tantas otras iniciativas, el
estupendo soporte que trae la herramienta de desarrollo Visual Studio 2005,
que entre otras cosas nos permite extender tanto las guías de
proceso como también las plantillas de los mismos, alterar los ítems de
trabajo, las actividades y/o los flujos de trabajo
De ese modo, es sencillísimo lograr adaptar un proceso existente a
uno más acorde a nuestro contexto, y que la herramienta nos garantice su
adecuación (como debe ser) para evitarnos el tener que cumplir con un
procedimiento en forma voluntaria
En otro post pienso cubrir con mayor detalle el proceso MSF Formal
0 comentarios:
Publicar un comentario