Futurecat - Michael Karek

Hinweis des Herausgebers: Dies ist der erste Beitrag eines führenden Mitarbeiters unseres Entwicklungsteams. Erlauben Sie mir, Ihnen Michael Fortin vorzustellen. Michael ist einer der „Distinguished Engineers“ bei Microsoft und Leiter des Feature-Teams „Fundamentals“ in unserer Gruppe Core-Betriebssysteme. Er leitet die Arbeit an der Verbesserung der Leistung und Zuverlässigkeit innerhalb der gesamten Windows-Plattform.  –Steven  (PS: Versäumen Sie es nicht, sich die Website www.microsoft.com/ie anzusehen und die Beta 2- Version von Internet Explorer 8 auszuprobieren).

Für die Arbeit an Windows 7 haben wir ein Team zusammengestellt, das sich speziell auf die Leistung beim Systemstart konzentriert, aber eigentlich umfasst diese Arbeit nicht nur die Windows-Gruppe, sondern auch andere Bereiche bei Microsoft. Darüberhinaus arbeiten unsere zahlreichen Partner auf dem Gebiet der Hardware- und Software-Entwicklung eng mit uns zusammen, und man kann mit Recht sagen, dass auch diese Teil unseres umfassenderen Teams sind.

Der Systemstart kann sich auf drei verschiedene Aspekte beziehen: Neustart, Wiederaufnahme nach dem Standby, oder Wiederaufnahme nach dem Ruhezustand. Obwohl die Wiederaufnahme nach dem Standby meist als Ausgangspunkt genommen wird und bei der gängigen Hardware und den standardmäßig installierten Programmen in der Regel 2 bis 5 Sekunden dauert, beschäftigt sich dieser Beitrag hauptsächlich mit dem Neustart, da die meisten Kommentare sich mit diesem Vorgang befassen. Eines unserer wichtigsten Ziele, das wir uns für Windows 7 vorgenommen haben, ist eine signifikante Verbesserung der Dauer des Neustarts für möglichst viele unterschiedliche Systeme. Bei unseren Tests verstehen wir unter einem „sehr guten System“ ein System, das innerhalb von 15 Sekunden startet und verfügbar ist.

Eine reduzierte Startzeit bei einem PC ist nur dann zu erreichen, wenn eine Reihe von Prozessen effizient und so parallel wie möglich durchgeführt werden kann:

• Die Dateien müssen in den Speicher gelesen werden.
• Die Systemdienste müssen initialisiert werden.
• Geräte müssen identifiziert und gestartet werden.
• Die Anmeldeinformationen des Benutzers müssen überprüft werden.
• Der Desktop muss aufgebaut und angezeigt werden.
• Startup-Programme müssen gestartet werden.

Da die einzelnen Systeme und Konfigurationen unterschiedlich sind, kann die Dauer des Neustarts bedeutend variieren. Dies zeigt sich in zahlreichen Testergebnissen, wird aber auch in unabhängigen Analysen deutlich, wie sie unter anderem von Ed Bott durchgeführt wurden. Die von Ed anhand seiner Systeme erfassten Daten ergaben, dass nur bei 35% aller Neustarts die Benutzer innerhalb von weniger als 30 Sekunden Zugriff auf das System hatten. Obwohl die Zahl der verschiedenen Systeme in Eds Untersuchung nicht sehr groß ist, passen seine Daten in das Bild, das sich aus unseren eigenen Tests ergibt. So weisen unsere Daten zu Windows Vista SP1 (sh. unten) ebenfalls daraufhin, dass nur ungefähr 35% der Systeme innerhalb von maximal 30 Sekunden gestartet werden, während 75% aller Systeme bis zu 50 Sekunden für den Neustart benötigen. Die Daten zu Vista SP1 sind telemetrisch erfasste Daten aus dem täglichen Gebrauch. Die Quelle dieser Daten ist eine beachtlich große Anzahl von Systemen (es handelt sich hier um Millionen von Systemen), deren Benutzer sich einverstanden erklärten, Microsoft im Rahmen des Customer Experience Improvement Programs auf anonyme Weise die Daten ihrer Systeme zur Verfügung zu stellen.

[Boot Times (System Responsive) : Startzeiten (die erforderliche Zeit, bis das System zur Verfügung steht)]

Unserer Meinung nach kommt es viel zu häufig vor, dass die Betriebssysteme zu langsam starten. Diese Situation müssen wir ändern. Besonders die Leistung der Systeme, die länger als 60 Sekunden brauchen, muss entschieden verbessert werden—gleichgültig, ob es sich dabei um Probleme mit den Geräten, dem Netzwerk oder der Software handelt. Wie Sie aus der Abbildung ersehen können, haben einige Systeme besonders lange Startzeiten. Im Bereich der PCs fällt vor allem die variierende Leistung auf—Unterschiede, die sich sowohl aus einer Reihe verschiedener Möglichkeiten ergeben als auch aus der unterschiedlichen Qualität der verschiedenen Komponenten. Einige Prozesse der Systemwartung können ebenfalls zu den langen Startzeiten beitragen. Wenn ein Benutzer ein umfangreiches Software-Update installieren möchte, geschieht das eigentliche Update des Systems beim nächsten Starten des PCs. Dieses Update, dessen Durchführung mitunter mehrere Minuten benötigt, wird in unserer Metrik erfasst. Was auch immer die Ursache für die geringe Leistung beim Systemstart ist – ein großer Teil unserer Aufgabe, die wir als Teil des PC-Ökosystems erfüllen müssen, besteht in der Verbesserung der Startzeiten.

Sowohl bei den von Ed gesammelten Daten als auch unseren telemetrisch erfassten Daten bedeutet „Startzeit“ die Zeit, die ein System benötigt, bis es für den Benutzer zur Verfügung steht. Dazu gehören das Anmelden am System und der Aufbau des Desktops, so dass dieser benutzt werden kann. Zwar stellt dies keine perfekte Metrik für unsere Analyse dar, jedoch wird damit die große Mehrheit der Probleme festgehalten. Bei Systemen, die Windows 7 und Vista betreiben, werden die Werte automatisch festgehalten und in dem Systemereignislog gespeichert. Darauf geht Ed in seinem Artikel geht Ed ausführlich ein.

Es ist uns bewusst, dass es auch noch andere Vorgänge und Aspekte gibt, die für den Benutzer zum Systemstart gehören, wie zum Beispiel das Anhalten des Datenträgers oder die Verfügbarkeit der Anwendungen, des Startmenüs oder des Desktops. Auch die Zeit nach dem Booten (wenn die Anwendungen im Startup laufen und einige Dienste nach einer bestimmten Verzögerung ausgeführt werden), die Zeit, bis der Start von Windows initiiert wird, sowie die BIOS-Zeit können wichtige Aspekte darstellen. Bei unseren Bemühungen um Verbesserungen werden wir stets sämtliche Faktoren im Auge behalten, die für den Benutzer die Startleistung beeinflussen.

Bevor ich auf unsere Arbeit an Windows 7 zu sprechen komme, möchte ich darauf hinweisen, dass wir eng mit unseren Partnern zusammenarbeiten. Bei der Analyse von Dutzenden von Systemen haben wir reichlich Gelegenheit gehabt, Verbesserungen vorzunehmen. Als Beispiel dafür mögen die folgenden Daten dienen, die beim Betrieb eines Systems erfasst wurden. Als das System geliefert wurde, hatte die Standardkonfiguration eine Startzeit von ca. 45 Sekunden. Nach einer Neuinstallierung von Vista SP1 auf diesem System verringerte sich die Startzeit in der Regel auf ca. 23 Sekunden. Bei einer Neuinstallierung gibt es natürlich weniger Prozesse, Dienste und etwas unterschiedliche Treiber (meist handelte es sich dabei um andere Versionen). Trotzdem gelang es uns, die Standardkonfiguration weiter zu optimieren und eine generelle Startzeit von ca. 21 Sekunden zu erzielen, etwa 2 Sekunden schneller als nach der Neuinstallierung, da wir in der verbesserten Konfiguration einige Veränderungen an den Treibern/dem BIOS vorgenommen hatten.

In diesem Zusammenhang möchte ich noch betonen, dass beim gleichen System die Wiederaufnahme nach dem Standby ungefähr 2 Sekunden beträgt, so dass das System beinahe sofort zur Verfügung steht. Wir empfehlen daher den Benutzern, Standby als Alternative zum Booten zu erwägen.

In Bezug auf unsere Arbeit an Windows 7 sei zu erwähnen, dass wir uns auf die Systemdienste konzentrieren. Unser Ziel ist es, sowohl ihre Anzahl zu reduzieren als auch deren Anforderungen an CPU, Datenträger und Speicherbedarf zu verringern. Der Grundgedanke dabei ist ganz einfach: wenn ein Dienst nicht unbedingt erforderlich ist, sollte er auch nicht gestartet werden, und es sollte einen Trigger geben, der Ausnahmefälle regelt und den Dienst nur in diesen Situationen startet.

Natürlich haben alle diese Dienste ihren Zweck: sämtliche Anforderungen des Benutzer sollen erfüllt werden, auch wenn sie noch so selten sind. Nehmen wir an, dass eine neue Tastatur, Maus oder neue Tablet-Hardware hinzugefügt wurde, während das System ausgeschaltet war. Wenn die neue Hardware nicht erkannt wird und keine neuen Treiber für die Benutzung der Hardware beim Starten installiert werden, kann der Benutzer unter Umständen seine Anmeldeinformationen nicht eingeben, um sich am System anzumelden. Im Falle eines einzelnen Benutzers tritt eine solche Situation sehr selten oder überhaupt nicht ein. Nimmt man jedoch Hunderte von Millionen von Benutzern, so geschieht dies häufig genug, um dafür zu sorgen, dass die erforderliche Unterstützung vorhanden ist. Bei Windows 7 haben wir die erforderlichen automatisch gestarteten Dienste reduziert, indem wir umfassendere Auslösemechanismen einsetzen.

Wie bereits bemerkt, stellen Geräte- und Treiberinitialisierung ebenfalls wichtige Faktoren dar. Bei der Arbeit an Windows 7 haben wir uns intensiv um eine umfassendere Parallelschaltung der Treiberinitialisierung bemüht, wodurch die Wahrscheinlichkeit geringer wird, dass bestimmte Geräte oder Treiber die allgemeine Startgeschwindigkeit verlangsamen.

Was das Einlesen der Dateien vom Datenträger betrifft, wurden bei Windows 7 die Logik und Verfahrensweise des „Prefetching” verbessert. „Prefetching“ wurde bereits mit Windows XP eingeführt. Da die heutigen Datenträger andere Leistungsmerkmale aufweisen, wurde die Logik des zeitlichen Ablaufs etwas abgeändert, um eine vergleichbare Effizienz zu erhalten. So evaluieren wir das „Prefetch“-Feature im Hinblick auf die neuen Solid State Datenträger, wobei wir sogar die Frage stellen, ob das Feature überhaupt noch erforderlich ist. Letztlich werden die Daten zur Leistungsanalyse, die anhand bestimmter Systeme erfasst werden, entscheiden, inwieweit wir vom „Prefetcher“ Gebrauch machen werden.

Auch die Diagnostik wurde bei Windows 7 verbessert. Unser Ziel ist es, die speziellen Probleme der jeweiligen Systeme unmittelbar zu identifizieren und die Problemlösung zu unterstützen. Wir halten dies für eine angemessene Art und Weise, den Benutzer auf die Probleme hinzuweisen, die sich z.B. ergeben, wenn zu viele Startup-Anwendungen oder umfangreiche domänenspezifische Anmeldeskripts vorliegen. Wie viele Benutzer bereits wissen, führt eine große Anzahl von Startup-Anwendungen zu einer verringerten Startleistung. Nur wenige Benutzer sind jedoch mit den Implikationen problematischer Start- oder Anmeldeskripts vertraut. Bei Windows XP, Vista und Windows 7 kann sich der Benutzer standardmäßig am Desktop anmelden, ohne auf eine langwierige Netzwerkinitialisierung oder die Ausführung eines Skripts warten zu müssen. In Unternehmen ist es jedoch möglich, dass die IT-Abteilung diese Standardkonfiguration ändert und die Clientsysteme so konfiguriert, dass sie die Server innerhalb des Netzwerks kontaktieren. Leider konfigurieren die Domänen-Administratoren die Clients, auf denen die Skripts ausgeführt werden, häufig so, dass sie synchron geschaltet sind und blockiert werden. Dies führt dazu, dass im Falle von Timeouts oder Problemen mit der Serverauthenfizierung der Systemstart und die Anmeldung verzögert werden. Darüberhinaus benötigen solche Skripts mitunter Programme, die viel CPU-, Datenträger- und Speicherressourcen beanspruchen.

Neben unserer Arbeit an den eigentlichen Features und Diensten von Windows 7 stellen wir unsern Partnern auch Tools, Testverfahren und Daten zur Verfügung. Diese Tools sind auch für die Enthusiasten unter Ihnen erhältlich. Sie können unsere internen Tools zur Identifizierung und Behebung von Startproblemen als Teil des Windows Performance Toolkits hier kostenlos herunterladen. Obschon diese Tools für die meisten Benutzer nicht unbedingt geeignet sind, erweisen sie sich doch für einige als sehr nützlich.

Eines der Themen, über das wir bald sprechen möchten und das bereits oft erörtert und kommentiert wurde, ist der Einfluss der zusätzlichen Software, die nach der ersten Installation von Windows installiert wird, auf die Leistung des Systems. Schon allein aufgrund der umfangreichen Software für Windows kann nicht jedes Programm den hohen Qualitätsanforderungen aller Benutzer entsprechen, wobei jedoch die meisten Programme zufriedenstellend sind. Daher muss Microsoft weiterhin den Entwicklern Tools zur Verfügung stellen, mit deren Hilfe sie leistungsfähige Software programmieren können. Ebenso müssen wir den Endbenutzern Tools zur Verfügung stellen, mit denen sie feststellen können, welches Programm die Leistung ihres Systems beeinträchtigt. Auch bei Windows selbst muss die Art und Weise verbessert werden, wie zum einen Programme identifiziert werden können, die die Leistung negativ beeinflussen, und zum anderen der Endbenutzer darauf aufmerksam gemacht wird.

Ein weiterer Beitrag könnte sich mit den Konfigurationsveränderungen befassen, die die Benutzer an ihren Systemen vornehmen. Viele der empfohlenen Veränderungen sind keineswegs nützlich. So haben wir festgestellt, dass die meisten Empfehlungen bezüglich kleiner Änderungen der Registrierung Unsinn sind. Mein Lieblingsirrglaube ist jedoch der folgende: Wenn man mit Live Search nach “ Superfetch auf XP aktivieren” sucht, erhält man zahlreiche Treffer. Nun, ich kann ihnen versichern: es gibt keine Superfetch-Funktionalität bei Windows XP und keinen der auf diesen Sites angeführten Registrierungsschlüssel. Gleiches gilt für viele andere Empfehlungen zu CPU-Zeitplanung, Speicherverwaltung und andere Konfigurationsveränderungen, die die Systemleistung in keiner Weise verbessern.

Startup ist ein Aspekt des Themas „Leistung.“ Wie im vorherigen Beitrag erwähnt, möchten wir die Diskussion dieses Themas fortsetzen. Lassen Sie uns wissen, welche anderen Aspekte Sie gerne eingehender diskutieren möchten.

Michael Fortin

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
• 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

Zum Thema der Leistung von Windows habe ich viele Kommentare und E-Mails erhalten. Es ist ein umfassender Dialog—die Leute möchten (natürlich) eine Verbesserung der Leistung. Wie viele andere Themen, die wir diskutieren werden, beinhaltet dieses Thema, auch wenn es sich hier um eine noch so absolute und messbare Größe zu handeln scheint, eine ganze Reihe von Fragen. Bei dem Ziel, eine Leistung zu erreichen, die sämtlichen Anforderungen gerecht wird, gilt es, viele verschiedene Elemente und notwendige Kompromisse im Auge zu behalten. Wir sind uns bewusst, dass die Leute, selbst wenn wir alle Erwartungen erfüllen, stets mehr von ihrem Windows-PC verlangen (was auch verständlich ist). Aus diesem Grund werden wir uns dieser Aufgabe mit Windows 7 (und IE erneut stellen. Dies ist eine übergreifende Initiative, an der sämtliche Feature-Teams beteiligt sind, und stellt die zentrale Aufgabe eines unserer Feature-Teams (des Fundamentals-Teams) dar. In diesem Beitrag möchte ich den Rahmen für die Diskussion festlegen, damit wir in den folgenden Beiträgen näher auf dieses Thema eingehen können.  In diesem Zusammenhang mögen der Beitrag IE8 Performance sowie der Artikel über den Beta 2 Release von IE 8 von Interesse sein.

Der Begriff „Leistung“ umfasst mehrere Elemente. Er kann sich auf die Geschwindigkeit beziehen, mit der eine bestimmte Anforderung bearbeitet wird. Mit „Leistung“ kann auch gemeint sein, wie viel RAM normalerweise erforderlich ist, oder was für eine CPU die Benutzer benötigen. Es könnte auch die tatsächliche Zeit gemeint sein, die für das Starten eines Programms, den Neustart oder für Standby/Wiederaufnahme erforderlich ist. Man kann die Leistung auch auf die CPU-Aktivität oder Datenträger-Eingabe/Ausgabe-Aktivität (oder ausbleibende Datenträgeraktivität) beziehen. Es kann sogar die Lebensdauer der Batterie damit gemeint sein. Mitunter bedeutet Leistung auch so etwas Banales wie der standardmäßig benötigte Speicherbedarf nach der Installation. All dies sind Maßstäbe für die Messung der Leistung, und sie alle werden im Verlauf der Entwicklung systematisch festgehalten. Mit Hilfe einer ganzen Reihe von Szenarien (davon gibt es Tausende) messen wir die Leistung, und unsere Developer führen unterschiedliche Szenarien aus, je nachdem, ob ihre Analyse mehr in die Tiefe oder in die Breite gehen soll. Im Folgenden sind einige der metrischen Analysen aufgeführt, auf die die uns wir bei der Arbeit an Windows 7 konzentrieren:

• Speicherbedarf – Wie viel Speicherbedarf wird bei der Ausführung eines bestimmten Szenarios in Anspruch genommen? Wie Sie wissen, ist man im Bereich Informatik gezwungen, einen Kompromiss zwischen Zeitersparnis und Speicherkapazität zu finden, und auch für uns gilt da keine Ausnahme. Wir begegnen diesem Kompromiss recht häufig in Zusammenhang mit Zwischenspeichern, wo wir mehr Speicherkapazität in Anspruch nehmen, um die Leistung zu verbessern oder die Wiederholung eines Rechenvorgangs zu vermeiden.
• CPU-Auslastung – Es ist klar, dass die modernen Mikroprozessoren eine enorme Rechenleistung darstellen, und mit dem Erscheinen von Mehrfach-CPUs bietet sich mehr Gelegenheit für parallel geschaltete Vorgänge als je zuvor. Diese Ressourcen haben freilich ihren Preis. Daher messen wir die CPU-Auslastung mit Hilfe von Vergleichstests. Im Allgemeinen geht es darum, die CPU-Auslastung so gering wie möglich zu halten, da dies die Leistung bei der gleichzeitigen Benutzung eines Computers durch mehrere Benutzer verbessert und den Stromverbrauch reduziert.
• Datenträger-Eingabe/Ausgabe – Während sich die Leistung der Festplatten auf bedeutende Weise verbessert hat, müssen wir noch immer alles dafür tun, um die Lese- und Schreibvorgänge (und natürlich das Auslagern) in Windows zu reduzieren. Aufgrund der neuen Solid State Disks, die entschieden andere Eigenschaften besitzen, müssen wir diesem Bereich in Windows 7 besondere Aufmerksamkeit widmen.
• Starten, Herunterfahren, Standby/Wiederaufnahme – Diese Vorgänge sind bei unserer Arbeit an Windows 7 von zentraler Bedeutung. Wir wissen, dass diese Prozesse nie schnell genug sein können. Hierbei ist unsere Zusammenarbeit mit den PC-und Hardware-Herstellern sehr wichtig, da wir sicherstellen möchten, dass die Zeiten, die wir unseren Labors messen (oder die Leistung, die wir nach einer Neuinstallierung messen) genau so gut sind wie bei einem neu gekauften PC.
• Basissystem – Wir unternehmen einiges, um das Basissystem zu messen und optimal einzustellen. Dies bedeutet, dass wir die Ressourcenauslastung vor dem Laden zusätzlicher Software festhalten. Dieses System stellt sozusagen die “Grundlage” dar, die den Ausgangspunkt für alle Developer festlegt und die Systemanforderungen für eine angemessene Benutzererfahrung definiert. In diesen Zusammenhang wird häufig gefordert, etwas aus dem Basissystem herauszunehmen und es stattdessen „bei Bedarf“ zur Verfügung zu stellen. In die Untersuchung dieser Wünsche investieren wir einiges an Arbeit. Wir möchten jedoch eine Situation vermeiden, bei der die große Mehrheit von Benutzern gezwungen ist, ein Programm bei Bedarf zu laden, dadurch aber gleichzeitig eine verringerte Leistung bei gewohnten Vorgängen in Kauf nehmen muss.
• Speicherbedarf – Obwohl der Speicherbedarf des Betriebssystems nicht direkt mit dessen Laufzeitleistung zusammenhängt, sehen viele Benutzer darin einen Indikator für die von ihnen beobachtete Leistung. In Bezug auf diesen Maßstab haben wir uns ein paar ganz bestimmte Ziele gesetzt und werden später näher auf die Details eingehen. Ebenso haben wir vor, \Windows\WinSxS näher zu erläutern, da dies häufiger Gegenstand der Diskussionen auf TechNet und MSDN ist. In diesem Bereich sehen wir anstelle von Kompromissen in Bezug auf die Laufzeit eher Kompromisse in Bezug auf bestimmte Annehmlichkeiten, wenn es um Dinge wie Datenträger-Gerätetreiber, dem angebotenen Umfang der Hilfe, wahlweise zur Verfügung gestellte Windows-Komponenten sowie Diagnostik und Protokolldaten geht.

Wir verfügen über eine Reihe von Kriterien, die wir am Ende der Meilensteine unseres Projekts an das Produkt anlegen, bevor wir zur Betaversion übergehen, und wir bringen das Produkt nicht auf den Markt, wenn diese Kriterien nicht weitestgehend erfüllt sind. Manchmal stellen diese Kriterien detailierte Vergleichstests dar (Seitenfehler, Prozessorauslastung, Working Set, Framerates für Spiele), während andere hingegen eher auf bestimmten Szenarien basieren und die Zeit messen, die für die Durchführung einer bestimmten Aufgabe erforderlich ist. (gemessene Zeit, Anzahl der Mausklicks). Wir nehmen diese Messungen an einer Reihe von Hardware-Plattformen vor (32-bit oder 64-bit; 1, 2, 4 GB RAM; 5400 bis 7200 RPM oder Solid State Disks; unterschiedliche Prozessoren etc.). Aufgrund der bei bestimmten Ansätzen der Softwarearchitektur erforderlichen Kompromisse führen wir häufig Code ein, der auf den jeweiligen Hardware-Typ abgestimmt ist, auf dem Windows betrieben wird.

Auf der einen Seite sollte das Thema „Leistung“ relativ einfach darzustellen sein: man benutzt weniger, tut weniger, und hat auch weniger. Solange man von allem weniger hat, sollte die Leistung besser sein. Im Extremfall trifft dies sicherlich zu. Wie wir den Kommentaren entnehmen, ist jedoch das, was der eine Benutzer unbedingt haben möchte, genau das, was ein anderer nicht haben möchte. Dies ist häufig bei den Features der Fall, die einige als “optische Spielereien” bezeichnen — viele der Benutzer wünschen sich, dass die zentrale Benutzeroberfläche durch Animationen und Grafiken aufgelockert wird (“wie bei den Produkten der Konkurrenz”), während andere wiederum sagen, wir sollen „auf die Grafiken verzichten und zu Windows 2000 zurückkehren”. Windows ist enorm flexibel und bietet viele Möglichkeiten, die Benutzererfahrung auf die jeweiligen Bedürfnisse abzustimmen. In diesem Forum wurde oft der Wunsch zum Ausdruck gebracht, bestimmte Versionen von Windows zur Verfügung zu stellen, die auf unterschiedliche Benutzerschichten zugeschnitten sind. Auf der anderen Seite haben wir auch einiges über die Notwendigkeit gehört, die Anzahl der verschiedenen Versionen von Windows zu reduzieren. Unsere Möglichkeiten, all diesen Wünschen gerecht zu werden, sind jedoch begrenzt, wenn wir gleichzeitig eine zuverlässige Plattform zur Verfügung stellen möchten, auf die sich die Benutzer und Entwickler gleichermaßen verlassen können, und die robust und für eine breite Schicht von Benutzern leicht zu handhaben ist. Und doch wird es innerhalb eines bestimmten Kontexts (bei der Benutzung zu Hause oder innerhalb eines Unternehmens, das eine ganz bestimmte Reihe von Programmen ausführt) immer möglich sein, von den Tools zur Anpassung und Verwaltung Gebrauch zu machen, die Windows für die Abstimmung auf die jeweiligen Bedürfnisse bietet. Die Möglichkeit der Entscheidung und Kontrolle darüber, was auf dem PC geschieht, ist von größter Bedeutung für uns, und Sie werden sehen, wie wir uns bei der Arbeit an Windows 7 auf deren Realisierung konzentrieren.

Die bei weitem größte Herausforderung bei dem Ziel, eine hervorragende Benutzererfahrung in Bezug auf Leistung zu bieten, liegt darin begründet, dass die Benutzer mit ihren PCs immer mehr tun wollen und mit Recht verlangen, dass dies auf ihrem PC möglich ist, wenn sie nur die entsprechenden Programme hinzufügen. Es stimmt zwar, dass Windows an sich bereits zusätzliche Funktionalität ermöglicht, aber gleichzeitig geben wir uns große Mühe bei der Auswahl der Features, von denen wir uns den größten Nutzen für den Großteil der Benutzer versprechen. Dennoch besteht ein signifikanter Teil unserer Arbeit an Windows 7 darin, für den Benutzer verschiedene Optionen und Möglichkeiten der Kontrolle darüber zu schaffen, welche Art von Software mit Windows zur Verfügung gestellt wird, z.B. welche Standardhandler es für bestimmte Dateitypen und Protokolle gibt, und dadurch eine Plattform zu erstellen, die es für die Endbenutzer einfach macht, ihre Computererfahrung auf ihre persönlichen Bedürfnisse abzustimmen.

Zum Schluss möchte ich noch kurz auf das Thema „Realität und ideale Voraussetzungen“ eingehen. Bei der Entwicklung von Windows führen wir unsere Vergleichstests unter Laborvoraussetzungen durch, die es uns gestatten, die Leistung und die Auswirkungen des von uns hinzugefügten Codes zu messen. Ebenso arbeiten wir eng mit den PC-Herstellern zusammen und unterstützen sie bei den Vergleichstests, die sie an den von ihnen ausgelieferten Systemen durchführen. Was die tatsächliche Leistung unseres Systems betrifft, bietet das Microsoft Customer Experience Improvement Program (anonym, vertraulich, freiwillig) Daten über die unterschiedlichen Geräte. Auf diese Daten werden wir uns in den nächsten Monaten häufig beziehen, da sie Auskunft darüber geben, wie die Dinge wirklich liegen, und wir somit nicht auf einzelne Berichte oder weniger verlässliche Informationsquellen angewiesen sind.

In unserem nächsten Beitrag werden wir auf die Leistung beim Starten und Systemneustart eingehen – angesichts des vorhandenen Interesses werden wir auf das Thema Leistung sicherlich noch häufiger zurückkommen.

–Steven

Danke für das Feedback das wir von ihnen bekommen haben. Wir freuen uns natürlich darüber, dass ein Großteil davon positiv ist. Ich habe versucht die Emails so gut wie möglich zu beantworten. Zusammen mit Mitarbeitern aus den Arbeitsgruppen haben wir eine Diskussion in den Kommentaren zu dem Blog geführt. Jeder der Teilnehmer hat gute Arbeit geleistet Perspektiven über Gewünschtes und Anforderungen darzustellen. Ich finde es toll diese Emails zu bekommen und die Kommentare zu lesen. Es ist einfach fantastisch. Ich wollte nur sicherstellen dass sich jeder bewusst ist dass ich nicht jedes Email beantworten kann! Wir werden die Kommentare und Emails als Anregung nehmen welche Artikel wir schreiben sollen. Das Team freut sich über die positive Reaktion von allen die uns hier begleiten. Wir wissen dass wir energiegeladene Diskussionen vor uns haben und wir freuen uns darüber dass wir nun damit beginnen können.

Mit diesem Artikel hoffe ich den Dialog über die Art und Weise, wie wir innerhalb des „Win7 Teams“ denken, fortzusetzen – in einem gewissen Maße das Team auf diese Art zu erweitern und ihnen die Möglichkeit zu geben mehr an der Diskussion teilzunehmen wie wir ein Release planen. Diese Konversation über große und kleine Releases ähnelt sehr der Diskussion die ich mit meinem Chef führe wenn wir mit der Planung beginnen

Man könnte meinen dass – wenn wir mit der Planung des Releases beginnen – die erste Frage ist, ob der Windows 7 Client ein „großes Release“ sein sollte oder nicht. Die Anführungszeichen rühren daher dass man das nicht wirklich entscheidet und dass es dafür auch nicht wirklich eine einzige Antwort gibt. Die Größe des Releases ist gleichwohl abhängig von der Perspektive über die Leistungsmerkmale als es von den Leistungsmerkmalen selbst. Man könnte gar fragen ob es ein Kompliment ist als „großes Release“ bezeichnet zu werden. Als Ingenieure legen wir am Anfang des Produktplanungsprozesses fest welcher Prozentsatz der Entwickler an dem Release arbeiten werden und über welchen Zeithorizont sich die Entwicklung bewegen soll. Dies führt dazu, dass sich Kunden selbst eine Meinung darüber bilden ob es ein „großes“ Release ist oder nicht – aber natürlich haben wir uns auch eine Meinung darüber gebildet. Auf dem Server Blog sprachen wir über den Zeitplan und legten auch unsere Meinung offen über das Ausmaß der Releases von Windows 7 Client und Server.

Unser Ziel ist es ein großartiges Release von Windows 7!

Über alle Kunden hinweg existiert immer die Perspektive, dass sich ein „großes“ Release dadurch auszeichnet dass alle Leistungsmerkmale für eben diese Kunden von Nutzen sind. Ein kleines Release zeichnet sich dadurch aus dass es „nichts für mich“ hat. Dadurch sollte es ziemlich einfach sein ein großes Release zu planen – man muss nur sicherstellen dass man die exakt richtigen Leistungsmerkmale für jeden Kunden hat (und da Leistung so wichtig ist soll es auch keine Funktionen darüber hinaus haben, selbst wenn andere Leute sie gerne hätten)! Als Ingenieure wissen wir dass ein solcher Design-Prozess unmöglich ist – gerade weil es die Norm ist dass zwei unterschiedliche Kunden exakt das Gegenteil verlangen. Gerade als ich diese Zeilen schreibe erhielt ich zwei Emails nacheinander wo jemand schreibt dass „niemand diesen Touch Screen Nonsens braucht“ und jemand anderer meint dass „(Win7) mehr ausgefeilte und robuste Touch-Fähigkeiten benötigt“.

Wenn man nur unverlangtes und unstrukturiertes Feedback bekommt sieht man diese Gegensätze ganz besonders. Ich bin mir sicher dass die Leser dies auch an den Blog-Kommentaren bemerken.

Lassen sie mich das Spektrum an möglichen Release-Umfängen anhand einiger Kundentypen erläutern: Endbenutzer, Entwickler, Partner, IT-Experten und „Beeinflusser“.

Endbenutzer sind meist sehr pragmatisch bei ihrer Entscheidung über den Umfang eines Releases. Für den Endbenutzer ist es meist ein großer Schritt wenn sie den Wunsch verspüren den Computer für ein neues Release aufzurüsten oder sich einen neuen Rechner zuzulegen. Wir könnten dies ein „großes“ Release bezeichnen. Ziemlich einfach – ein „großes“ Release ist gut für jeden Beteiligten. Auf der anderen Seite kann man sich auch vorstellen, dass ein Release wirklich „cool“ ist und dass es Leute gerne kaufen möchten, die Anforderungen an Speicher oder neue Treiber jedoch hoch sind oder man neue Hardware benötigt um alle Möglichkeiten auszureizen. Unter diesem Aspekt kann ein großes Release ein wenig an Attraktivität verlieren, da es einiges an Aufwand erfordert. Natürlich wissen wir, was Endbenutzer fordern: dass alle ihre Wunsch-Features auf ihrer Wunsch-Hardware funktionieren – denn dann ist es ein tolles Produkt das man haben muss (ob es ein großes Release ist oder nicht).

Entwickler sehen ein Release unter einem anderem Blickwinkel. Natürlich ist es für Entwickler ein großes Release wenn neue Programmierschnittstellen (APIs) und Funktionen zur Verfügung stehen, die in ihrer Software Anwendung finden – wiederum ziemlich einfach. Es könnte auch der Fall sein, dass ein vorheriges Release viele neue APIs anbot und dass Entwickler sich gerade erst damit vertraut machen. Dann wollen Entwickler nur eine Vervollständigung dieser APIs und vielleicht Geschwindigkeitsverbesserungen. So könnte man meinen dass ein erstes Release ein „großes“ und ein nachfolgendes zweites Release ein „kleines“ ist. Wenn man aber die Geschichte von Softwareprodukten betrachtet, sieht man, dass diese „kleinen“ sich sehr oft zu großen Releases entwickeln – Windows 3.1, Office 4.2, selbst Windows XP SP2. In jedem dieser Fälle wandten sich die Entwickler diesen „kleinen“ Releases zu, aber aus dem Blickwinkel des Marktes waren dies „große“. Der Grund warum Entwickler diese neuen APIs nutzen wollen ist, dass sie ihre Produkte von anderen unterscheidbar machen wollen oder dass sie ihr Spezialwissen einsetzen wollen – und nicht weil sie diese APIs „einfach so“ verwenden wollen. In diesem Sinne kann ein Release für einen ISV ein großes sein wenn es dazu führt, dass genug Ressourcen zur Verfügung stehen um auf neue APIs zu setzen weil sie sich auf Dinge konzentrieren können die für sie wichtig sind.

Partner repräsentieren ein breites Spektrum an Leuten die PCs bauen, Hardware entwerfen und die Infrastruktur schaffen, die wir als das Ökosystem sehen an dem Windows teilnimmt. Partner sehen ein Release als „groß“, wenn es neue Möglichkeiten schafft und deshalb meist mit viel Veränderung verbunden ist und das Feld öffnet neue Hardware und Infrastruktur an Kunden auszuliefern. Auf der anderen Seite werden Inkompatibilitäten meist unter einem negativen Blickwinkel gesehen, da Partner bereits Geliefertes ändern müssen um es mit dem neuen Release kompatibel zu machen und sich nicht mit neuen Projekten auseinander setzen können. Wenn sich Partner – aus einer Vielzahl an Gründen – dafür entscheiden, diese Arbeit nicht zu tun, kann das Release aus einem Mangel an Unterstützung des Ökosystems als „kleines“ wahrgenommen werden. So kann eine große Veränderung wiederum unter dem Aspekt eines „kleinen“ und eines „großen“ Releases betrachtet werden.

IT-Experten werden oft als von Natur aus konservativ charakterisiert und nehmen deshalb zu Veränderungen oft eine negative Haltung ein. Da sich ihre Rolle auf betriebswirtschaftliche Aspekte konzentriert wird die Evaluierung von Softwareprodukten immer unter der Linse von Rentabilität betrachtet. Für einen IT-Experten ist ein „großes“ Release eines, das zu signifikanter wirtschaftlicher Wertschöpfung führt. Diese Wertschöpfung kann beispielhaft als eine signifikante Investition im Management der Software verstanden werden. Für Endbenutzer oder Entwickler jedoch könnten die gleichen Leistungsmerkmale uninteressant sein und in keiner Weise als „großes“ oder „kleines“ Release tituliert werden.

Beeinflusser sind jene Personen, deren Geschäft es ist Beratung, Analyse und unterschiedliche Blickwinkel zu unserer Software anzubieten. Diese Personen messen ein Release oft am Umfang der Veränderungen. Große Veränderungen bedeuten ein großes Release. Eine große Veränderung kann z.B. ein Architekturwechsel sein wie z.B. der Wechsel von Windows 9x auf Windows 2000 – obwohl beide Produkte gleich aussahen, gab es viel über Veränderungen unter der Oberfläche zu berichten. Für Analysten war es damit definitiv ein großes Release. Große Veränderungen können auch mit der Benutzeroberfläche verbunden sein, da diese einfach wahrzunehmen sind und damit für viel Diskussion sorgen. „Groß“ für jede dieser Veränderungen kann aber als wenig positiv gewertet werden, da Architekturänderungen potenziell Inkompatibilität bedeuten können. Neue Benutzeroberfläche bedeutet Lernbedarf und Abschied von Bekanntem.

Wir haben viele Kommentare bekommen und ich habe viele Emails erhalten die sich mit der Architekturänderung von Windows als Symbol eines großen Releases befassen. Wir haben auch viel Feedback darüber erhalten, dass ein Release dann groß“ ist wenn es Vergangenes nicht mehr unterstützt. Generalisierend kann man sagen, dass Leute oft annehmen, dass eine Veränderung der Architektur zu verbesserter Geschwindigkeit oder geringerem Speicherverbrauch führt. Solche Vergleiche sind immer schwierig, da sie den Status-Quo mit einer Version vergleichen, in der wir alle bekannten Probleme behoben haben, aber noch nicht wissen welche Probleme wir geschaffen haben oder welche Dinge nicht mehr funktionieren. So anstatt ein großes Release relativ an der Implementierung zu messen macht es glaube ich mehr Sinn, den Erfolg eines Releases relativ am Nutzen der wie auch immer gewählten Implementierung zu bewerten. Wir werden diesen Teil der Diskussion definitiv weiterführen – hier gibt es großen Bedarf an Dialog.

Es ist wichtig die richtige Balance zu finden. Wir können große Veränderungen für alle Kunden durchführen wenn wir die Betroffenen ausreichend vorbereiten. Wir können auch durch kleine Veränderungen große Wirkung erzielen, wenn es die richtigen Veränderungen zur richtigen Zeit sind, und diese werden über längere Zeit als großes Release wahrgenommen.

Wir haben über Timing und die Art und Weise wie wir ein Team strukturieren gesprochen, so werden sie ein Gefühl dafür haben über die „Inputs“ des Projektes. Wenn wir gut genug zugehört und unsere Anstrengungen korrekt fokussiert haben, dann wird jedes Kundensegment Dinge finden die das Release attraktiv machen. Und wenn wir gut über das Produkt kommunizieren, dann können sogar Dinge, die als „Problem“ wahrgenommen werden könnten, in einem breiteren Kontext des Ökosystems – wo jeder kollektiv davon profitiert wenn einige signifikant profitieren – erscheinen.

Aus unserer Perspektive haben wir unser vollständiges Engineering-Team und einen umfangreichen Zeitplan eingesetzt um das Windows 7 Client Betriebssystem in die Realität umzusetzen. Damit ist dies – nach jeder Definition – ein großes Projekt. Wir haben die Absicht dass Windows 7 ein großartiges Release wird.

Ich hoffe, dass ihnen dies geholfen hat zu sehen, dass Perspektive alles ist wenn es für den Kunden jeglichen Typs darauf ankommt zu entscheiden, wie groß ein Release nun wirklich ist.

—Steven

Willkommen beim ersten Beitrag zu einem neuen Microsoft-Blog— dem Blog „Die Technik von Windows 7“ („Engineering Windows 7“), oder abgekürzt „E7.“ Die Beiträge zu E7 stammen von den beiden Senior Engineering Managern für Windows 7, Jon DeVaan und Steven Sinofsky. Jon und Steven werden, gemeinsam mit anderen Mitgliedern des Engineering Teams, Beiträge und Kommentare veröffentlichen und sich aktiv am Blog beteiligen.

Beginnend mit diesem ersten Beitrag werden wir uns damit auseinandersetzen, was das „Windows 7”- Projekt bedeutet. Es ist uns bewusst, dass es tausende von Fragen über die Einzelheiten des Projekts gibt, und dass Sie wissen möchten, was von dem nächsten großen Release von Windows zu erwarten ist. Sie dürfen uns glauben, dass wir begeistert sind, über dieses neue Release schreiben zu können. Seit Windows Vista vor achtzehn Monaten auf den Markt gekommen ist, hat das Engineering Team sich in seiner Arbeit fast ausschließlich auf das neue Windows-Produkt konzentriert.

Dieser Blog richtet sich an die Enthusiasten, Blogger und all jene, die die Entwicklung von Windows mit Interesse verfolgen. Mit dem Blog möchten wir die Diskussion darüber eröffnen, wie wir an die Arbeit an Windows 7 herangehen. Windows weist sämtliche Herausforderungen auf, die mit einem großangelegten Softwareprojekt verbunden sind—die Auswahl der Features, deren Design, die Entwicklung sowie die hohen Qualitätsanforderungen, die wir an das Release stellen. Darüberhinaus stellt Windows eine weitere Herausforderung dar: das Produkt hat einen außergewöhnlich unterschiedlichen Benutzerkreis zufriedenzustellen. Dies bringt, sowohl für das Team als auch für jeden einzelnen Mitarbeiter, eine große Verantwortung mit sich.

Wir sind fest davon überzeugt, dass zum Erfolg von Windows 7 eine offene und aufrichtige Diskussion zwischen uns und unseren Lesern darüber gehört, wie wir diesen verschiedenen Interessen gerecht werden und ein so umfangreiches Produkt wie Windows auf den Markt bringen können. Dieser Blog soll dazu dienen, einen solchen Dialog zu ermöglichen.

Zur Planung eines Produkts wie Windows gehört die systematische Analyse der Bedürfnisse und Anforderungen sämtlicher Benutzersegmente. In Bezug auf die Planung des Releases arbeiten wir bereits seit Beginn des Projekts mit Vertretern unterschiedlicher Benutzergruppen und Partner zusammen (darunter PC-Hersteller, Hardware-Entwickler, Unternehmen, Entwickler und viele andere Gruppen). Ebenso halten wir durch telemetrische Datenerfassung (Customer Experience Improvement Program), Usability-Analysen und andere Studien die Erfahrungen unserer Endbenutzer fest. In einem unserer zukünftigen Beiträge werden wir auf die verschiedenen Arten eingehen, wie wir aus der Erfahrung unserer Kunden lernen, und auf welche Weise unsere Analysen das Release beeinflussen.

In diesem Herbst finden zwei wichtige Veranstaltungen für Entwickler und unsere Partner in unserem gesamten Ökosystem statt: Die Professional Developers Conference (PDC – Konferenz für Professionelle Entwickler) am 27. Oktober und die Windows Hardware Engineering Conference (WinHEC – Konferenz für Windows Hardwareentwicklung) in der darauffolgenden Woche stellen die beiden ersten Veranstaltungen dar, bei denen wir erstmals detailierte technische Informationen zu Windows 7 präsentieren. Dieser Blog wird in den nächsten zwei Monaten und darüber hinaus bis zum Release in regelmäßigen Beiträgen über die Entwicklung dieses Releases Blicke hinter die Kulissen bieten sowie Zusammenhänge darstellen.

Was uns auf die Idee zu diesem Blog gebracht hat, waren die zahlreichen Diskussionen in anderen Blogs darüber, was wir bei Microsoft damit bezwecken, wenn wir mit unseren Äußerungen über Windows 7 etwas zurückhaltend sind (manche werden dies als eine bedeutungsvolle Untertreibung betrachten). Wir alle in unserem Team haben sicherlich einige wichtige Lektionen in Bezug auf solche ‚Mitteilungen” gelernt und gesehen, wie leicht es ist, sich zu Aussagen über die neuen Features hinreißen zu lassen, bevor man ein klares Verständnis davon hat. In Bezug auf Windows 7 und unsere Äußerungen vor dem Release möchten wir sicherstellen, dass wir wissen, wovon wir reden. Wie gesagt sind wir uns der Verantwortung bewusst, dafür zu sorgen, dass wir keine vorläufigen Prioritäten hervorheben, über Änderungen an der Ressourcenverteilungen sprechen, oder Verwirrung in Bezug auf unsere Strategie unter den Zehntausenden von Partnern und Kunden stiften, denen die Entwicklung von Windows am Herzen liegt und die viel darin investiert haben.

Verbunden mit dem Thema der Mitteilungen zum Release ist der Wunsch, dafür zu sorgen, dass wir keine Erwartungen wecken, die der Release letztlich enttäuschen wird—Features, die nicht verwirklicht werden können, Behauptungen, die sich als unhaltbar erweisen, oder verbindliche Aussagen zu Unterstützung und Support, die sich als nicht zutreffend erweisen. Gleich zu Anfang unserer Arbeit an der Entwicklung von Windows 7 haben wir uns als Team vorgenommen, nur das zu versprechen, was wir auch erfüllen können. Das ist unser Ziel—Sie an dem teilhaben zu lassen, was wir uns vorgenommen haben sowie unsere Gründe dafür zu erläutern und zum angekündigten Termin mit einem Release herauszukommen, der Ihren hohen Anforderungen an die Qualität gerecht wird.

Wir haben große Erwartungen an diesen Blog. Als aktive Teilnehmer an den internen Microsoftblogs freuen wir uns darauf, unsere Aufmerksamkeit und Energie der Blog-Community außerhalb von Microsoft zuzuwenden. Wir sind wohlvertraut mit dem Prozess des Bloggens und glauben, dass wir viel Spaß haben und aufschlussreiche Informationen liefern, aber auch einige Fehler machen werden. Wir sind uns bewusst, dass wir manches vielleicht missverständlich darstellen werden, oder dass das, was wir sagen, vielleicht anders ankommt als beabsichtigt. Darüber machen wir uns keine Sorgen. Wir möchten nur, dass der Dialog auf gegenseitigem Respekt sowie dem gemeinsamen Wunsch basiert, Windows 7 zu einem großen Release zu machen.

Wir haben vor, „regelmäßige“ Beiträge zu liefern. Wir werden die Kommentare verfolgen und ganz bestimmt auch eigene Kommentare abgeben sowie gegebenenfalls in weiteren Beiträgen auf die angeschnittenen Themen zurückkommen. Wir werden dafür sorgen, dass die Mitglieder des Entwicklungsteams von Windows sich vorstellen. Obwohl wir den Dialog in aller Öffentlichkeit führen möchten, können Sie Ihre E-Mails auch direkt an steven.sinofsky@microsoft.com senden, wenn Sie möchten, besonders wenn Sie Themen vorschlagen möchten, auf die wir in diesem Blog eingehen sollten.

Damit schließen wir den Beitrag ab, der Sie bei diesem Blog willkommen heißt, und laden Sie ein, den Blog weiterzuverfolgen und am Dialog über die Technik von Windows 7 teilzunehmen.

Steven und Jon

Zum Schluss möchten wir Sie noch auf die Versionen dieses Blogs in anderen Sprachen hinweisen, die Sie mittels der Links auf der Navigationsfläche einsehen können. Diese Übersetzungen unserer Beiträge stammen ebenfalls von Mitgliedern unseres Entwicklungsteams, und wir würden uns freuen, wenn auch auf diesen Sites ein Dialog zustande kommt. Ausgehend vom Feedback, das wir erhalten, werden wir die Liste der Sprachen, in denen der Blog zur Verfügung steht, erweitern.