Merci à tous pour vos commentaires et courriels. C’est avec beaucoup de plaisir que je vois ce dialogue s’établir, et le lancement de ce blog a aussi insufflé une énergie nouvelle dans l’équipe. Il me parait maintenant naturel de procéder aux présentations, et de décrire même sommairement la composition de l’équipe représentée par ce blog.

Avant de commencer, je voudrais dire quelques mots sur ce que l’on est en droit d’attendre de ce blog, et en premier lieu sur les nombreux commentaires et courriels que j’ai reçus – de fait, j’ai passé la plus grande partie de mon weekend à lire vos réponses. Certains thèmes sont récurrents. En général le blog a été reçu de façon très chaleureuse, et nous en sommes ravis. La requête de loin la plus fréquente concerne la performance de Windows, souvent simplement pour nous demander de « rendre Windows plus rapide ». C’est un sujet complexe, et nous avons l’intention d’y consacrer du temps sur ce blog dans les mois qui viennent. Il y a aussi de nombreuses requêtes spécifiques représentant souvent toutes les opinions possibles sur un même problème – certains nous suggèrent de nous « débarrasser de la fonctionnalité <X> », ou de ne « pas faire <X> », alors que d’autres nous confirment que « quoiqu’il arrive, il est très important de garder (ou faire) <X> ». Personnellement, je pense que l’intérêt de ce blog est en grande partie de pouvoir discuter des différents aspects d’un problème donné. Même une notion aussi cartésienne que la performance d’un système présente de nombreuses subtilités. Par exemple, certains suggèrent que la meilleure solution pour améliorer la performance de démarrage serait de ne rien charger au lancement de l’ordinateur, tandis que d’autres pensent que retarder le chargement ne ferait que les ralentir plus tard ; d’autres enfin suggèrent que la meilleure approche serait de fournir un gestionnaire de démarrage laissant à chacun son libre choix. Chacune de ces méthodes a ses avantages propres, et mérite d’être débattue, mais démontre aussi les subtilités et complexités d’un sujet apparemment simple.

En second lieu, et à notre grande surprise, un certain nombre d’entre vous ont mis en question l’authenticité de ce blog. Certains ont même suggéré que les articles étaient écrits par des prête-noms, ou que ce blog n’est qu’un stratagème. Soyez rassurés : j’écris ce blog dans « Windows Live Writer », et je le publie directement. Ce blog est authentique – y compris les fautes de frappe, les fautes d’orthographe, et toutes les autres. Il n’y ni intermédiaire ni filtrage. Des membres de l’équipe y contribueront aussi, et ils signeront leurs articles en nom propre (je signerai mes commentaires avec mon identité msdn, steven_sinofsky).

Troisièmement, quelle sera la fréquence de parution, et quand allons-nous aborder des thèmes portant sur « les fonctionnalités de Windows 7 » ? Quand nous avons dit que nous allions publier « régulièrement », nous n’avions pas réellement de plan ou de calendrier particulier en tête ; nous astreindre artificiellement à une fréquence donnée serait contradictoire à la nature même d’un blog. En gros, nous avons l’intention de suivre un modèle similaire à celui que vous connaissez sur IEBlog. Je vous dévoilerai qu’à Microsoft, personne ne m’a encore accusé de ne pas participer suffisamment à mon blog interne. J

Comme nous l’avions dit dans notre premier article, nous avons l’intention de parler de la création de Windows 7 (le « comment »), et la première étape est de vous présenter les ingénieurs qui réalisent le projet. Nous nous pencherons par la suite sur le « pourquoi » et le « quoi » du produit lui-même.

Commençons donc par rencontrer l’équipe…

Il est facile de se représenter l’équipe Windows comme un groupe ou une entité, ayant à l’occasion une personne donnée agissant en tant que porte-parole – soit au cours d’une présentation lors d’une conférence, ou à l’occasion de la publication d’un livre ou d’un article, ou de la parution d’un blog. En fait, Windows est le produit de tout Microsoft, le fruit d’une multitude d’apports provenant d’individus et d’équipes de développement divers répartis dans toute l’entreprise. Cependant, l’équipe de conception de Windows à proprement parler est cogérée par Jon et moi. Jon dirige le système d’exploitation qui comprend entre autres le noyau, toute l’infrastructure des pilotes, le système réseau et les outils de développement (pour le client ainsi que le serveur). Quant à moi, je travaille sur l’équipe « Windows Client Experience » qui développe entre autres le « shell Windows », le bureau de travail, les composants graphiques, et tout l’audiovisuel. Windows Media Center, un autre composant important du produit Windows, est développé par l’équipe responsable des produits TV Microsoft (IPTV, extendeurs, etc.).

Organiser et mettre en place une telle équipe est une entreprise difficile, dont la partie la plus importante reste de planifier et de répartir l’ensemble du travail. Cette planification fait partie intégrante de notre objectif d’améliorer la cohérence et l’intégration de Windows 7. Aussi au lieu d’une organisation monolithique, ou de deux équipes, nous considérons que l’équipe Windows 7 est constituée d’environ 25 « équipes de fonctionnalité » différentes.

Chaque équipe de fonctionnalité  est responsable d’une partie spécifique de Windows 7 – code, fonctionnement, qualité, et développement. L’équipe de fonctionnalité est l’unité de base dans la répartition et la coordination du travail à travers l’organisation. Ce niveau de granularité présente certains avantages pratiques – une équipe de fonctionnalité  peut tenir entière dans une salle de réunion, ou aller ensemble au cinéma. La taille moyenne d’une équipe est d’environ 40 développeurs, quoique ce chiffre varie. Une équipe de fonctionnalité  est définie à la fois par ce sur quoi elle travaille, et par les ingénieurs qui la constituent.

En général, les équipes de fonctionnalité  de Windows 7 portent les noms des divers composants de Windows avec lesquels vous êtes déjà familiers. Certaines équipes associées aux éléments de base de Windows sont restées pratiquement inchangées depuis plusieurs versions, alors que de nouvelles équipes ont été créées pour travailler sur de nouvelles fonctionnalités. Certaines équipes travaillent principalement sur la version serveur (par exemple la Machine Virtuelle), alors que d’autres (tel que Internet Explorer) créent des produits aussi disponibles en dehors de Windows 7.

En général, une équipe de fonctionnalité  est responsable à la fois de composants d’architecture et de divers scénarios de Windows. Le terme « fonctionnalité » lui-même est ambigu ; certains parlent de fonctionnalité  pour un élément de l’interface utilisateur, alors que d’autres utilisent le terme pour designer des composants d’architecture (tel que TCP/IP). Notre philosophie est d’établir un équilibre entre scenarios et architecture. Nous évitons aussi de séparer la partie infrastructure de la partie interface utilisateur afin de faire en sorte que les équipes soient responsables d’un scénario de bout-en-bout (par exemple, « Recherche et Organisation» construit à la fois le moteur d’indexation et l’interface utilisateur de recherche). Voici une liste partielle des équipes de fonctionnalité  de Windows 7 (par ordre alphabétique anglais) :

  • Applets and Gadgets : Petites Applications et Gadgets
  • Assistance and Support Technologies : Techniques de Support et d’Assistance aux Utilisateurs
  • Core User Experience : Expérience Utilisateur
  • Customer Engineering and Telemetry : Télémétrie
  • Deployment and Component Platform : Déploiement et Plateforme
  • Desktop Graphics : Graphiques
  • Devices and Media : Périphériques et Audiovisuel
  • Devices and Storage : Périphériques et Stockage
  • Documents and Printing : Documents et Impression
  • Engineering System and Tools : Outils de Développement
  • File System : Système de Fichiers
  • Find and Organize : Recherche et Organisation
  • Fundamentals : Systèmes Fondamentaux
  • Internet Explorer : Internet Explorer, y compris le déploiement hors Windows
  • International : Internationalisation
  • Kernel & VM : Noyau et Machine Virtuelle
  • Media Center
  • Networking – Core : Réseau – Base
  • Networking – Enterprise : Réseau – Entreprise
  • Networking – Wireless : Réseau – Sans Fil
  • Security : Sécurité
  • User Interface Platform : Plateforme d’Interface Utilisateur
  • Windows App Platform : Plateforme d’Applications Windows

Je pense que pour les besoins de cet article, la plupart de ces noms parleront d’eux-mêmes – dans nos publications futures les auteurs feront référence à cette liste pour indiquer l’équipe à laquelle ils appartiennent.

Ceci devrait vous donner une idée des multiples sous-systèmes de Windows, ainsi que de la façon dont nous avons divisé un projet complexe en équipes plus petites. Bien entendu tout au long de ce projet de nombreuses fonctionnalités sont développées par plusieurs équipes travaillant en collaboration. Cela requiert de la pratique. Par exemple, pour des raisons d’efficacité ou de performance, il est souvent naturel de développer une fonctionnalité par « couches » successives, en général de bas en haut (en commençant par la plateforme, et en finissant par l’interface utilisateur). Cependant, l’usager utilisera souvent plusieurs couches en parallèle, et les administrateurs de réseaux souhaitent en général gérer les ordinateurs de haut en bas.

Je reconnais qu'il peut s'agir ici d’un point de vue interne, puisqu’en général il vous est impossible de savoir dans quelles équipes « vivent » diverses fonctionnalités. Par exemple, les plateformes de Tablet PC et d’encrage, ainsi que la reconnaissance vocale, le « multi-touch » et les modèles d’accessibilité font partie de l’équipe de Plateforme d’Interface Utilisateur. Cela s'explique par la nécessité de partager l'infrastructure de tous les mécanismes « de saisie », même si un même usager n’en utilisera pas tous les niveaux. Cette conception commune d’API pour toutes les saisies de données permettra aux développeurs de bénéficier de tous les modes d'interaction utilisateur au travers d'un seul jeu d'API.

Une autre caractéristique de nos équipes de fonctionnalité est la façon dont elles sont composées. Une équipe de fonctionnalité comprend trois branches d’ingénierie: les ingénieurs de développement de logiciel (« software development engineer », « sde » ou « dev »), les ingénieurs de développement de logiciel de test (« software development engineer in test », « sdet », désolé, je n’ai pas encore écrit de profil de travail à usage externe) et les responsables de programmes (« program manager », « pm »). La combinaison de ces trois disciplines est une caractéristique unique de Microsoft qui a même attiré l'attention de certains chercheurs. Les liens ci-dessus vous référeront aux descriptions de « dev » et de « pm » décrites sur mon ancien blog. (je dois toujours créer un article similaire sur le « sdet » !).

De façon succincte, le « dev » est responsable de l'architecture et du code, le « pm » est responsable de la définition et de la spécification de la fonctionnalité, et le « testeur » est responsable de la validation et défenseur ultime de l'expérience du client. Tous sont responsables de la qualité et de la performance, chacun apportant une perspective différente. Pour chaque fonctionnalité, des ingénieurs de dev, test et pm collaborent en équipe, à la fois conceptuellement et littéralement. Cet équilibre des pouvoirs est un concept clé dans notre façon de travailler, et assure une approche équilibrée dans le développement de Windows 7. Notre organisation est structurée pour permettre à des dev de travailler pour des dev, des sdets pour des sdets, et des pm pour des pm. En d’autres termes, nous sommes organisés par « fonctions de développement ». Deux optimisations sont ainsi obtenues – nous mettons l’accent sur la compétence dans un domaine et une discipline donnés, et nous nous assurons également de concevoir le produit conjointement et non pas en silos.

Nous parlons de ces trois disciplines comme un tout, car nos équipes de fonctionnalité sont composées de n développeurs, n testeurs et 1/2 n responsables de programme. Ce ratio est assez constant à travers l’organisation. En moyenne, une équipe de fonctionnalité dans Windows 7 compte environ 40 développeurs.

Notre équipe de conception comprend aussi un certain nombre de personnes qui travaillent sur l’ensemble du produit :

  • Développement de contenu – les rédacteurs et les éditeurs qui créent l’aide en ligne, le site Web, les documents SDK et les documents de déploiement.
  • Planification du produit – responsable de l’étude des besoins des clients qui informe la sélection des fonctions du produit. La planification produit coordonne également notre travail avec nos partenaires dans l’écosystème Windows en matière de design et de développement.
  • Design – développe le modèle d’interaction, le langage graphique, et le langage conceptuel de Windows 7.
  • Recherche et ergonomie – crée des études en laboratoire et sur site qui montrent comment les utilisateurs répondent aux produits existants et aux fonctions proposées.

Certains d’entre vous ont émis des doutes ou des questions quant à l’effectif de l’équipe de Windows – trop importante, sa taille poserait maintenant problème. Je ferai simplement remarquer que l’ensemble de vos réponses sur ce blog indique une importante demande de nos usagers en faveur d’une gamme de fonctionnalités nouvelles, et de modifications à apporter à Windows. Windows est un énorme projet qui requiert énormément d’effectifs. Au risque de paraître trivial, mon opinion est que l’équipe Windows doit avoir la taille appropriée – ni trop grande, ni trop petite, mais doit surtout être gérée efficacement pour que sa charge de travail soit proportionnelle à sa taille, de façon à produire les résultats attendus. Dans une scène du film Amadeus, l’empereur fait remarquer que le Mariage de Figaro contient « bien trop de notes », ce à quoi Mozart répond : « Il y a juste le nombre de notes nécessaires, Majesté, ni une de plus, ni une de moins ». Lorsque l'empereur insiste et demande à Mozart d'ôter quelques notes, Mozart répond simplement : « A quelles notes pensez-vous en particulier ? ». Ce sont les personnes composant l'équipe qui définissent le produit et développent les scénarios de bout en bout, et notre défi est donc d’avoir l'équipe et la structure appropriées pour maximiser notre capacité à accomplir ces taches - ni trop, ni trop peu.

Je me suis promis qu'aucun de mes billets ne ferait plus de 4 pages, et je crois en être proche. Vos commentaires sont excellents, et nous aident à cibler nos prochains billets. J'espère que celui-ci aidera à préciser le bon contexte.

--Steven