Das Windows 7 Team

  • Article

Vielen Dank an alle, die Kommentare zu meinem Blog abgegeben und mir E-Mails geschickt haben. Ich freue mich über die angeregte Diskussion, die wir in Gang gesetzt haben. Seit ich mit diesem Blog begonnen habe, sind die Diskussionen in unseren Gängen spürbar lebhafter geworden. Daher scheint es angebracht, wenn ich als erstes das Windows Development Team vorstelle. Der heutige Beitrag bietet eine Übersicht über das Team, das in diesem Blog vertreten ist.

Bevor ich zur Sache komme, möchte ich kurz darauf eingehen, was Sie von diesem Blog erwarten können. Zunächst einmal ein paar Worte zu den Kommentaren und E-Mails, die ich erhalten habe: es waren eine Menge — den größten Teil des Wochenendes habe ich damit verbracht, diese Mails und Kommentare zu lesen. Es lassen sich bereits einige gemeinsame Themen erkennen. Im Großen und Ganzen war die Reaktion ausgesprochen freundlich, was ich sehr zu schätzen weiß. Am häufigsten kam der Wunsch zum Ausdruck, die Leistung von Windows zu diskutieren, und/oder wie man “Windows einfach schneller machen kann.” Dies ist ein komplexes Thema, und wir werden darauf in den nächsten Monaten recht oft zurückkommen. Daneben gibt es aber auch ganz spezifische Wünsche, die häufig mehrere Aspekte eines ganz bestimmten Problems darstellen. So sagen einige zum Beispiel “Nehmt doch <x> raus” oder “Hört auf, <x> zu machen,” während andere wieder sagen “Egal, was Ihr tut, <x> muss auf jeden Fall bleiben.” Was diesen Blog für mich persönlich so interessant macht ist, dass hier die Gelegenheit besteht, ein Problem in seiner ganzen Vielschichtigkeit zu beleuchten. Selbst so eindeutige Themen wie Leistung erweisen sich als äußerst komplex. So sagen einige, dass die beste Methode, die Bootgeschwindigkeit zu steigern, darin besteht, einen Prozess erst nach Einsetzen der Leerlaufzeit zu starten, während andere wiederum finden, dass diese Verzögerung ihre Arbeit verlangsamt. Wieder andere haben einen Start-Manager vorgeschlagen, wo jeder selbst bestimmen kann, was gestartet wird. All diese Ideen sind es Wert, diskutiert zu werden, und bezeugen gleichzeitig, wie komplex und nuanciert selbst der simpelste Verbesserungsvorschlag ist.

Zweitens möchte ich erwähnen, und das hat Jon und mich sehr überrascht, dass eine Reihe von Leuten die “Authenzität” der Beiträge in Zweifel gezogen haben. Manche haben sogar behauptet, dass die Beiträge von einem “Ghostwriter” stammen oder dass der Blog irgendein Trick ist. Ich gebe diese Beiträge direkt in Windows Live Writer ein und veröffentliche sie selbst, indem ich auf die Maustaste klicke. Dieser Blog ist tatsächlich echt — mit seinen Tippfehlern, inhaltlichen Fehlern und allem, was dazugehört. Es gibt keine Zwischenstufe oder ein Absegnen der Beiträge. Einige aus dem Team werden ihre eigenen Beiträge veröffentlichen, aber stets unter ihren eigenen Namen. Wir benutzen zwar einen gemeinsamen Benutzernamen für alle Beiträge, um die Sicherheit und das geistige Eigentum des Blogs zu gewährleisten, aber die einzelnen Beiträge werden von denen unterzeichnet, die sie veröffentlichen. (Die eingehenden Kommentare werde ich unter meinem MSDN-Namen steven_sinofsky beantworten.)

Drittens möchte kurz darauf eingehen, wie häufig neue Beitrage veröffentlicht werden und wann wir zu den “Features von Windows 7” kommen? Mit “regelmäßigen” Beiträgen ist gemeint, dass wir keinen Zeitplan oder Veröffentlichungskalender für die Beiträge haben, und wir möchten uns nicht zu einer künstlichen Regelmäßigkeit verpflichten, da dies dem Wesen eines Blogs widerspricht. Wir werden uns an einen ähnlichen Rhythmus halten, wie Sie ihn vom IEBlog bereits kennen. Ganz nebenbei hat mich noch niemand bezichtigt, nicht genug Beiträge zu meinem internen Blog zu liefern. :-)

Wie im einführenden Beitrag bereits erwähnt, sind wir der Ansicht, dass es sinnvoll ist, über die Technik von Windows 7 (das “Wie”) zu sprechen. Bevor wir jedoch auf das Produkt selbst eingehen (das “Warum” und “Was”), möchten wir die Ingenieure vorstellen, die hinter der Technik stehen.

Darf ich vorstellen: das Team

Man kann sich das Windows-Team als eine Gruppe oder Einheit vorstellen, bei der von Zeit zu Zeit eine bestimmte Person das Team repräsentiert — vielleicht hat sie bei einer Konferenz einen Vortrag gehalten, ein Buch oder einen Artikel geschrieben, das den Leuten bekannt ist, oder schreibt einen Blog. Bei Microsoft ist das Windows-Produkt in der Tat ein Produkt, an dem das gesamte Unternehmen beteiligt ist. Softwareentwickler aus vielen anderen Gruppen leisten ihren Beitrag dazu. Das eigentliche Windows Engineering Team wird gemeinsam von Jon und mir geleitet. Jon ist Manager des Core Operating Systems Teams — dazu gehören Kernel, Geräte-Infrastruktur, Netzwerke, sowie Entwicklungstools und Entwicklungssystem (sowohl für den Client als auch den Server). Ich selbst gehöre zum Windows Client Experience Team, das unter anderem Shell und Desktop, Grafikanwendungen und Medienunterstützung entwickelt. Ein weiterer bedeutender Teil des Windows-Produkts ist das Windows Media Center, eine Komponente von zentraler Bedeutung. Windows Media Center ist Teil der anderen Anwendungen für TV (IPTV, Extender, usw.).

Es ist keine geringe Aufgabe, eine Organisationsstruktur für solch ein großes Team aufzubauen. Der wichtigste Aspekt besteht jedoch in der Planung der Aufgaben des Teams. Diese Planung bildet einen integralen Bestandteil bei der Verwirklichung unseres Ziels, die allgemeine Konsistenz und Kohärenz mit Windows 7 zu verbessern. Anstatt also nur von einer großen Organisation oder zwei großen Teams zu sprechen, sollte man eher sagen, dass das Windows 7 Engineering Team aus ungefähr 25 verschiedenen Feature-Teams besteht.

Ein Feature-Team ist ein Team, das für einen bestimmten Teil von Windows 7 verantwortlich ist — sowohl Code, Features, Qualität, als auch die Entwicklung im Allgemeinen. Die Feature-Teams stehen im Zentrum der Arbeit und der übergreifenden Koordination. Dadurch sind die Teams auch von der Größe her einfacher zu leiten —Feature-Teams können in Besprechungsräumen zusammenkommen, gemeinsam ins Kino gehen und so weiter. Durchschnittlich besteht ein Feature-Team aus 40 Entwicklern, aber meist variiert die Größe der Teams. Bei einem Feature-Team gibt es zwei Aspekte zu beachten: woran das Team arbeitet und was ein Team zu einem Team macht.

Die Feature-Teams von Windows 7 entsprechen in vielerlei Hinsicht den Teilen von Windows, mit denen Sie bereits vertraut sind. Aufgrund der Plattformelemente von Windows haben wir viele Teams, die über mehrere Versionen hinweg relativ unverändert geblieben sind, während andere Teams völlig neu sind oder relative neue Gebiete vertreten, in denen sowohl neuer Code entwickelt als auch an dem Code gearbeitet wird, der die Grundlage des Teams darstellt. Einige Teams arbeiten hauptsächlich für den Server (z.B. die VM-Arbeit), andere wiederum leisten einen wichtigen Beitrag außerhalb von Windows 7 (z.B. Internet Explorer).

Im Allgemeinen beinhaltet die Arbeit eines Feature-Teams eine Reihe von Windows-übergreifenden Architekturkomponenten und Szenarien. “Feature” ist ein kniffliges Wort, da einige darin ein bestimmtes Element der Benutzeroberfläche sehen, während es für andere eher eine bestimmte Komponente der Architektur (wie etwa TCP/IP) darstellt. Uns ging es darum, ein Gleichgewicht zwischen den verschiedenen Szenarien und der Architektur zu finden, bei dem sowohl sämtliche Szenarien als auch alle wichtigen Bestandteile der Architektur berücksichtigt werden. Was wir vermeiden möchten, ist die Trennung zwischen “Technik” und “Benutzeroberfläche”. Das bedeutet, dass alle Teams für sämtliche Aspekte ihrer Arbeit verantwortlich sind (z.B. ist das Team “Suchen und Organisieren” sowohl für die Entwicklung des Indexers als auch der Benutzeroberfläche der Suche verantwortlich). Zu den wichtigsten Feature-Teams von Windows 7 gehören:

  • Applets und Minianwendungen
  • Hilfe- und Unterstützungstechnologien
  • Benutzererfahrung der residententen Programme
  • Kunden- und Anwendungstelemetrie
  • Bereitstellung und Komponentenplattform
  • Desktopgrafik
  • Geräte und Medien
  • Geräte und Speicher
  • Dokumente und Drucken
  • Engineering-System und Tools
  • Dateisystem
  • Suchen und Organisieren
  • Grundlagen
  • Internet Explorer (bis einschließlich IE 8)
  • Internationales Team
  • Kernel & VM
  • Media Center
  • Netzwerk – Residente Programme
  • Netzwerke für Unternehmen
  • Drahtlosnetzwerke
  • Sicherheit
  • Plattform - Benutzeroberfläche
  • Plattform – Windows-Anwendungen

Ich denke, die meisten dieser Bezeichnungen sind, für den Zweck dieses Blogs, eingängig genug — in zukünftigen Beiträgen werden die Vertreter der einzelnen Teams jeweils erwähnen, zu welchem Team sie gehören. Die obige Übersicht soll Ihnen eine Vorstellung davon geben, in welche Gruppen die Windows-Systeme unterteilt sind, und wie wir die Arbeit an einem umfangreichen Projekt möglichst sinnvoll aufteilen. Natürlich koordinieren wir die Arbeit untereinander über das gesamte Projekt hinweg und entwickeln Team-übergreifende Features. Dies ist eine Arbeitsmethode, die sich für uns bewährt hat, da man häufig den Code in einzelnen Schichten entwickeln möchte, um eine bessere Effizienz und Leistung zu erzielen (sozusagen von unten nach oben), wogegen für den Endbenutzer der Code mehrere Schichten beeinflusst. IT-Professionals hingegen möchten unter Umständen den Desktop von oben nach unten verwalten. Ich gebe zu, dass dies vielleicht zu sehr von der Insiderperspektive her geschrieben ist, da Sie nicht wissen können, wo einige dieser interessanten Dinge “integriert” sind. So ist zum Beispiel die Tablet- und Freihand-Funktionalität Teil des Teams “ Plattform - Benutzeroberfläche”, zusammen mit Spracherkennung, Mehrfingereingabe und Eingabehilfen. Dies liegt in der durch die Architektur bedingten Notwendigkeit begründet, eine gemeinsame Infrastruktur für alle Eingabemechanismen zu schaffen, selbst wenn der Benutzer nicht immer sämtliche Ebenen in Anspruch nimmt. Auf diese Weise können die Entwickler beim Design der APIs für die Eingabeverarbeitung die Vorteile sämtlicher Arten von Benutzerinteraktionen in all den anderen APIs erkennen.

Ein weiterer Aspekt unserer Feature-Teams ist deren Zusammensetzung. Ein Feature-Team setzt sich immer aus den drei zentralen technischen Disziplinen zusammen: Software Development Engineers (SDEs oder “Devs“ – Software-Entwickler), Software Development Engineers im Test (SDET oder “Test“ - leider habe ich bis jetzt noch keine externe Stellenbeschreibung verfasst), sowie Programm Manager (PM). Die Zusammenarbeit dieser drei technischen Disziplinen ist kennzeichnend für Microsoft, eine Tatsache, auf die selbst einige Experten hinweisen. In meinem alten Blog habe ich die Disziplinen “Dev” und “PM” beschrieben. Die Beschreibung können Sie den Links entnehmen (ich muss noch einen ähnlichen Beitrag über SDETs schreiben!).

Kurz gesagt ist der Dev verantwortlich für die Architektur und den Code, der PM für die Reihe von Features und die Spezifikationen, und Test ist verantwortlich für die Validierung aus der Sicht des Benutzers. Sie alle sind verantwortlich für Qualität und Leistung, und zwar jeweils unter dem Gesichtspunkt ihrer eigenen Disziplin. An jedem Feature arbeiten Devs, Tester und PMs als gleichwertige Mitglieder eines Teams zusammen (sowohl im buchstäblichen als auch im übertragenen Sinn). Dies stellt ein zentrales Gleichgewicht von Expertise und Verantwortlichkeit dar, das gewährleistet, dass wir bei der Entwicklung von Windows 7 einen ausgewogenen Ansatz verfolgen. Von der Organisation her arbeiten die Devs in Dev-Teams, die SDETs in SDET-Teams und die PMs in PM-Teams. Das bedeutet, wir haben die Teams nach “Engineering-Funktionen” eingeteilt. Dies ermöglicht eine Optimierung in zweifacher Hinsicht — einerseits die Konzentration von Expertise sowohl im sachlichen Bereich als auch im Bereich der jeweiligen Disziplin, sowie andererseits die Gewähr, dass wir das Produkt nicht in isolierten Silos entwickeln, sondern stets dessen Gesamtheit im Blick haben.

Wir sehen diese drei Disziplinen als eine Einheit, da unsere Feature-Teams sich jeweils aus n Entwicklern, n Testern und 1/2n Programm Managern zusammensetzen. Dieses Verhältnis ist ziemlich konstant in unserer Gruppe. Beim Windows 7-Projekt besteht ein Feature-Team im Durchschnitt ungefähr aus 40 Entwicklern.

Daneben haben wir für das Produkt als Ganzes auch Mitglieder unseres Engineering-Teams, die übergreifend am gesamten Produkt arbeiten:

  • Content-Entwicklung – die technischen Redakteure, die die Onlinehilfe, den Inhalt der Website, SDK-Dokumente und Bereitstellungsdokumentationen verfassen.
  • Produktplanung – dieses Team ist verantwortlich für die Marktforschung, die die Grundlage für die Auswahl der Features bilden. Das Produktplanungsteam ist auch für die Koordination unserer Arbeit mit unseren Partnern innerhalb des Ökosystems in Bezug auf Partnerschaft bei Design und Entwicklung eines Releases zuständig.
  • Produktdesign – dieses Team entwickelt das übergreifende Interaktionsmodell, die Grafik und das Design für Windows 7.
  • Forschung und Benutzerfreundlichkeit – dieses Team erstellt Feld- und Laborstudien, die zeigen, wie bestehende Produkte und geplante Features beim Kunden ankommen.

Manche sagen, dass das Windows-Team einfach zu groß ist und dass die inzwischen erreichte Größe zu Problemen im Engineering-Bereich führt. Gleichzeitig jedoch weisen viele Kommentare daraufhin, dass es eine bedeutende Nachfrage nach einer umfangreichen Reihe von Features und Veränderungen an Windows gibt. Um Windows zu entwickeln, ist eine bestimmte Anzahl von Leuten erforderlich, denn es handelt sich hier um ein großes Projekt. In meinen Augen ist es unsere Aufgabe, dafür zu sorgen, dass das Windows-Team die richtige Größe hat — dies hört sich nach einem Klischee an, aber das Team darf weder zu groß noch zu klein sein und muss auf effiziente Weise geleitet werden, so dass der Umfang des Teams der Arbeit des Teams entspricht und das Projekt verwirklicht werden kann. Dies erinnert mich an eine Szene aus Amadeus, wo der Kaiser bemerkt, dass die Hochzeit des Figaro “zu viele Noten” enthält, wogegen Mozart einwendet “es gibt genau soviele Noten wie notwendig, Eure Majestät, weder zu wenig noch zu viel.” Auf den Vorschlag des Kaisers, doch einige Noten zu streichen, reagiert Mozart mit der einfachen Frage “an welche haben Eure Majestät dabei gedacht?” Die Leute im Team stellen für uns einen Weg dar, die geforderten Feature-Anforderungen umzusetzen und umfassende Szenarien zu entwickeln. Die Herausforderung liegt darin, das richtige Team beisammen zu haben und eine effiziente Organisationsstruktur zu schaffen, um unsere Aufgaben bestmöglich zu erfüllen — weder zu wenig noch zu viel.

Ich habe mir vorgenommen, nicht mehr als vier Seiten zu schreiben, und ich bin am Ende meines heutigen Beitrags angelangt. Die Kommentare sind hochinteressant und helfen uns dabei, zukünftige Beiträge zu gestalten. Ich hoffe, dass dieser Betrag zusätzliche Zusammenhänge aufzeigen wird.

--Steven

Veröffentlicht am Montag, 18. August 2008 24:00 in e7blog