Me encanta cocinar. Es un hecho. Y desde que abandoné la casa de mis padres para retomar la aventura de construir Oslo con unos cuantos amigos, hace algo más de 6 meses, y vivo independizado en Vancouver, este hecho se ha convertido además en clara necesidad vital. Sin embargo, en este post, no voy a hablaros sobre Oslo como últimamente acostumbro a hacer, no voy a hablar de ningún gran proyecto software concreto; o, tal vez, hable un poco sobre todos ellos.
Retomando mis aficiones culinarias, hay algo en el proceso de preparación de una buena Paella Alicantina que se asemeja mucho a la ingeniería de procesos en grandes proyectos software. Desde el momento en el que captamos los requerimientos de nuestro proyecto (hora a la que queremos comer, cantidad de raciones a preparar, etc.), hasta que realizamos las estimaciones del proyecto (cantidades de cada uno de los ingredientes, tiempo de cocción, etc.) el razonamiento no difiere demasiado del que llevamos a cabo para construir software. Existen además una gran cantidad de técnicas que el tiempo y la experiencia previa nos aportan, de forma que podamos medir con una mayor precisión los riesgos de cada fase del proceso. De este modo, seremos capaces de determinar aquellas tareas críticas a las que deberemos dedicarnos de manera exclusiva, así como aquellas que podamos pararelizar y por tanto ser capaces de realizar de forma simultánea (tales como pelar una cabeza de ajos mientras freímos ñora picada, e incluso calentar agua para cocer el arroz mientras el resto de ingredientes ya están en la paella…). Eventualmente, también seremos capaces de cocinar al mismo tiempo que buscamos en los armarios de la cocina algunos de los ingredientes para añadir al proceso, e incluso nos sentiremos cómodos y consideraremos esta capacidad como algo natural, proporcionado por la experiencia. Por último, cuando cocinemos varios platos al mismo tiempo, deberemos hacerlo al ritmo adecuado para que todos ellos estén preparados en el momento preciso: la hora de comer. Este proceso, ya de por sí algo complejo, tiende a incrementar su nivel de dificultad cuando cada una de estas tareas o platos son elaborados por personas diferentes, incluso por equipos de personas diferentes.
De igual forma sucede en el mundo del desarrollo software. Existen diferentes formas de organizar y coordinar a esas personas, a esos equipos, con el fin de convertir el lanzamiento de un gran producto en un auténtico homenaje a la cooperación, sincronización y coordinación transversal. Analizando globalmente la estructura de los equipos de producto en Microsoft, encontraremos dos modelos principales de organización, a través de los cuales un proyecto evoluciona desde su fase de incubación hasta alcanzar su madurez.
Pensemos en un gran proyecto como Office, compuesto actualmente por más de una veintena de proyectos (yo ya he perdido la cuenta). Si recordamos los orígenes de este producto, veremos que “en la noche de los tiempos”, no existía Office… Existía Word, y Excel, y Access, y más adelante PowerPoint y OneNote, y… (paremos aquí de contar, ya que quiero acabar algún día este post). Office es uno de los grandes proyectos de Microsoft, junto con Windows, Visual Studio y unos cuantos más, que han experimentado una transición entre estos dos modelos, visiones, filosofías, enfoques para gestionar un gran proyecto software.
El primero de estos modelos es el conocido como Product Unit Management (PUM). Este modelo es probablemente el más habitual entre todos los equipos en Microsoft, y se basa en la definición de una unidad de producto (conjunto de arquitectos, desarrolladores, testers, program managers y otros roles implicados) como órgano independiente y hegemónico en la planificación de todas las fases del proyecto, desde su incubación hasta su lanzamiento. Generalmente, estas unidades de producto no dependen de otras, a menos que exista una tecnología concreta empleada por esta PUM que se encuentre próxima a su fecha de lanzamiento. Este independencia convierte al modelo PUM en el modelo óptimo en términos de agilidad, de “time-to-ship” (tiempo hasta el lanzamiento) y capacidad de respuesta ante la competencia. Sin embargo, es deficiente en términos de colaboración entre proyectos, estandarización de infraestructuras tales como automatización de builds, o ejecución de pruebas automatizadas. Esto genera un aumento de los costes para estas tareas, que si bien se llevan siempre acabo, en estos casos resultan más laboriosas para el grupo de producto al tener que duplicar esfuerzos de otros grupos. A menudo, encontramos este modelo organizativo en pequeños equipos, como el equipo de Surface, de Zune, de Live Mesh… También en proyectos más grandes como es el caso de Oslo (donde disponemos de distintas organizaciones PUM, para el lenguaje M, para Quadrant, etc.), e incluso en proyectos monstruosos (en volumen, se entiende) como es el caso de Windows u Office. En este último tipo de proyectos, generalmente el modelo de independencia a nivel de PUM se adopta para nuevas características del producto que se encuentran todavía en fase de incubación…
A medida que un producto madura, los equipos habitualmente crecen de tamaño y la centralización de algunas tareas e infraestructuras para mejorar la eficiencia y reducir costes sucede de forma natural. Este modelo recibe muchos nombres, pero tal vez el nombre más apropiado sea el de “modelo de equipos coordinados/compartidos” (en Inglés lo conocemos como “Shared Team”). Con este enfoque, muchas tareas y características del producto se asignan a un equipo compartido central y el resto de equipos que participan en el proyecto deben sincronizarse con este equipo central, o por el contrario no serán capaces de finalizar el proyecto y lanzar un producto con todas las características previstas.
Office es un gran ejemplo de adopción de este modelo, tal cual comentábamos unas cuantas líneas más arriba. Desde el día en que alguien tuvo la gran idea de que todas las aplicaciones de productividad deberían empaquetarse juntas y vender el producto como una suite ofimática, la jerarquía dentro del equipo de Office ha evolucionado hacia este segundo modelo. De hecho, este equipo compartido recibe el nombre de Office Shared Services Team (OSS).
Dentro de la división de Office, existen diferentes grupos de producto (como Word, Excel, Sharepoint, etc.) cuya labor es centrarse en el desarrollo de cada una de estas aplicaciones y ofrecer un producto de gran calidad, capaz de satisfacer a los clientes. Y frente a este tipo de grupos, encontramos otros grupos transversales encargados de una serie de características del producto comunes a todas las aplicaciones de la suite (Interfaz de Usuario, Infraestructura de Builds, Documentación, Internacionalización, etc.). Combinando los esfuerzos de ambos tipos de grupos, se consigue por una parte innovar en cada aplicación y mejorarla de una a otra versión, a la vez que mantener una coherencia a nivel de producto en toda la suite, y también alinear fechas de lanzamiento del producto. De igual modo, la creación de estos grupos transversales nos proporciona una mejor visión a la hora de implementar estrategias de diseño, desarrollo y pruebas en el conjunto de la suite de Office.
Existen muchas variaciones y modelos intermedios entre ambos enfoques de organización. Siendo sinceros, probablemente no seamos capaces de encontrar dos grupos en Microsoft con una estructura idéntica entre sí. Sin embargo, las filosofías y buenas prácticas de estos dos modelos son la base ideológica sobre la que todos los equipos se apoyan.
A menudo, desde fuera de Microsoft, esto puede parecer una batalla, un cierto grado de rivalidad entre equipos. Pensemos en equipos de desarrollo como el equipo de C# y el equipo de Visual Basic, la forma en que alternativamente van añadiendo características nuevas a su lenguaje respectivo y la consiguiente “respuesta” del otro grupo. Afortunadamente, la colaboración entre estos dos grupos (y entre otros muchos!) es cada vez mayor a nivel global dentro de Microsoft, y en lugar de ser transatlánticos independientes luchando por llegar primeros a la otra costa, son auténticas flotas navales avanzando de forma coordinada con un mismo rumbo…
Una estructura muy similar a la explicada para Office sería la existente en la división de Windows. Espero y deseo que a estas alturas todos conozcais y sigais de manera habitual el blog Engineering Windows 7, en el que nuestros amigos de Windows 7 encabezados por Steven Sinofsky (Senior VP de Windows, de hecho), nos cuentan muchas de las decisiones de diseño (y también de ingeniería de procesos), que se toman a lo largo del desarrollo de un proyecto de semejantes dimensiones.
Valga el párrafo previo para darme la oportunidad de mencionar el reciente lanzamiento de Internet Explorer 8 (Release Candidate). Si acudís a la web de descargas, observaréis que la versión para Windows 7 no está disponible para descarga, debido a que deben llevarse a cabo una serie de pruebas adicionales sobre ciertas características exclusivas de Windows 7 (tales como interfaz de usuario táctil, etc. podéis leerlo en la propia web de descarga)… como podréis adivinar, este tipo de característica pertenece a uno de esos “grupos transversales” de los que os hablaba arriba… y antes de que nadie se escandalice por el hecho de no disponer aún de una versión RC de IE8 en Windows 7, podréis leer entre líneas en este post la explicación razonada y metodológica de este hecho… Es “inminente” la aparición de una versión RC de Windows 7 que incluya IE8, así como otras características excepcionales en las que están trabajando.
Comensales, ocupen sus asientos, y dispónganse a degustar esta suculenta paella llamada Windows 7. 🙂
