主题 : Windows 7 BLOG:windows7项目组织
级别: 荣誉管理员

UID: 62
精华: 0
发帖: 3364
威望: 11827 点
无痕币: 11755 WHB
贡献值: 19 点
在线时间: 5588(时)
注册时间: 2007-11-27
最后登录: 2024-03-28

0 Windows 7 BLOG:windows7项目组织

管理提醒: 本帖被 都市小星星 从 『WINDOWS 7 专区』 移动到本区(2009-04-16)
史蒂芬写了关于我们如何组织的工程团队于Windows这是一项非常重要的元素是如何工作的工作要做。另一个重要部分是,我们如何组织工程本身。

我 想开始与一对夫妇的速记。第一点是史蒂芬读取和写入约10倍,速度比我,所以不要太奇怪,如果您看到这个分布的话两者之间,我们在这里。 (放心,我们之间,我深思想家:-) 。或者,也许我只是嫉妒。 )第二点是我们希望做的要继续分享“我们如何建立的Windows 7 ”的议题以来,这使我们的共同背景,当我们潜入功能的讨论,因为我们更加贴近PDC和的WinHEC 。我们要讨论我们如何是工程的Windows 7包括汲取的经验教训,从长/ Vista的。所有这些现实进入我们的决策在Windows 7 。

确定,就向tawdry位。

史 蒂芬联系在一起的最后时间,这本书微软机密,这是一个很好的分析,我想呼吁两个版本的Microsoft工程系统。 (版本一所涉及的索引卡和“软网”和你真的不想听到有关情况。 )版本2送达微软很好远超过任何人的预期,但学习从Windows XP ,真正不同的安全环境出现了在那个时间和从Longhorn中/Vista中,很明显,这是时间,另一个世代的转型,我们如何工程的做法,我们的产品。

教训,从XP中围绕变化的安全景观在我们的行业。您可以了解我们如何把我们的学习转化为行动看在安全性开发生命周期,这是一套工程实践中建议由微软开发更安全的软件。我们使用的这些做法,内部工程师的Windows 。

评 论关于这个博客表明的质量一个完整的体系,包含了许多不同的属性,每个不同的重要性,以不同的人,而且人们有一个范围广泛的意见,关于Vista的整体素 质。我花了很多时间,对核心的可靠性,操作系统和学习,遥测,我们收集从真正的用户(仅如果他们选择-在向客户体验改善计划)我知道Vista的SP1是 一样可靠的,因为XP的整体和更可靠的,在一些重要的方法。遥测为指导,我们就什么,以解决在SP1 。我很高兴地看到,其中一个方法人士指出,在评论有关睡眠和恢复工作更好地在Vista中。我也很兴奋的前景,继续我们的努力(我们)利用遥测,以推动 Vista中成为最可靠的Windows版本。我想补充到名单Vista的素质,成功地切割的安全漏洞,只要下半相比,到Windows XP 。此博客是关于Windows七,但你应该知道,我们是工作在Windows七月与深刻的认识表现的Windows Vista在现实世界中。

在 最重要的方法,人们谁也通过电子邮件发送和评论突显了机会,为我们改善的Windows工程系统。性能,可靠性,兼容性和未能向巴勒斯坦人提供对新技术的 承诺,很受欢迎的主题,在评论。最好的方法之一,我们可以解决这些是更好的日常管理工程的Windows 7代码基地或每日建设质量。我们已采取许多具体步骤,以改善我们如何管理该项目,使我们做的好得多就这个层面。

我希望您正在阅读,这和去, “好,杜昌! ”但我的经验,与软件项目的所有大小和在许多组织中告诉我,这不是作为明显的或容易达到的,因为我们的愿望。

每日建设质量

每 日质量的事项了大量在一个软件项目,因为每天你的基础上做出决定您最好的了解有多少工作是离开。当平均每日建立了低质量,是不可能知道有多少工作是左,你 作出了很多不好的工程的决定。至于有多少贡献的工程师增加(因为我们希望做更多的) ,每天的重要性,质量迅速上升,因为一体化的负担增加,根据概率的任何单一的程序员的错误。这个问题不止,不知道什么数目的错误在该产品是。如果这一切带 来的麻烦,然后至少每个开发人员将他们的命运掌握在他们自己手中。该更为阴险的副作用是,当发展商缺乏信心,整合所有的每日变动纳入其个人的工作。遇到这 种情况时有很多错误,不兼容,和其他问题,我们不能知道,因为该守则的变化,从来没有聚集在一起的任何计算机上。

我已经准备了一份图 表,以说明使用的现象,一个简单的公式预测建立休息,所造成的1 100个错误率,对部分个人程序员超过频谱组的大小(蓝线) 。一%的错误率是好的。如果一用一个典型的利率,这将是一个小不如。我已经列入其他两个线,显示建立打破的概率,如果我们削减个人平均错误率的一半(红 线)和由第十届(绿线) 。你可以看到,机制,改善日常的质量,每个工程师的影响,整体每日建设质量相当大的金额。
 
为一组大小的Windows ,它是一个相当的壮举为每日要建立可靠的。

我 们的改善在Windows 7杠杆的一大进步,在Vista的工程系统,投资在一个共同的测试自动化基础设施,全国所有功能团队的Windows 。 (你会看到这里有是一个必然之间的联系,设计过程,自己和组织的团队,一个链接,很多人不承认。 )利用这一基础设施,我们可以验证码的变化,供应的每一个功能团队之前,他们是并入每日建设。内该功能的团队,这基础设施,可以用来验证码的变化,所有的 程序员,每天。你可以看到在图表中如何平均40 %的功能,程序员团队结余建立打破的概率,使里面的一个特点团队建设相对很少休息。

对 于Windows 7月,我们已大致成功地在保持建立在一个较高的质量水平每一天。虽然我们偶尔休息,因为我们整合的工作,所有发展商,自动化,让我们找到并修复任何问题和 问题,高品质的建设,几乎每天都有。我一直使用的是Windows 7月对我每天的生活开始以来,该项目相对较少的困难。 (我知道很多乡亲现正急欲与我一起使用的是Windows 7月建立,每天航在那里! )

为乐趣我已经包括一对夫妇的照片从我们的实验室建设,建立和确认检验,为服务器和客户端的是全天候不打烊:
   
结论

呼〜这似乎像一个风短跑通过了深刻的话题,我花了很多时间,对,但 我希望你发现它有趣。我希望你开始得到的想法,我们一直非常全面的思想,通过新的工作方式和改善我们如何工程师的Windows通过这个例子。最终的考验 我们的思想,将产品质量本身。什么是您的角度来看,对这一重要的软件工程问题?
 原文如下:

Hi Jon DeVaan here.

Steven wrote about how we organize the engineering team on Windows which is a very important element of how work is done. Another important part is how we organize the engineering project itself.

I’d like to start with a couple of quick notes. First is that Steven reads and writes about ten times faster than I do, so don’t be too surprised if you see about that distribution of words between the two of us here. (Be assured that between us I am the deep thinker :-). Or maybe I am just jealous.) Second is that we want do want to keep sharing the “how we build Windows 7” topics since that gives us a shared context for when we dive into feature discussion as we get closer to the PDC and WinHEC. We want to discuss how we are engineering Windows 7 including the lessons learned from Longhorn/Vista. All of these realities go into our decision making on Windows 7.

OK, on to the tawdry bits.

Steven linked last time to the book Microsoft Secrets, which is an excellent analysis of what I like to call version two of the Microsoft Engineering System. (Version one involved index cards and “floppy net” and you really don’t want to hear about it.) Version two served Microsoft very well for far longer than anyone anticipated, but learning from Windows XP, the truly different security environment that emerged at that time and from Longhorn/Vista, it became clear that it was time for another generational transformation in how we approach engineering our products.

The lessons from XP revolve around the changed security landscape in our industry. You can learn about how we put our learning into action by looking at the Security Development Lifecycle, which is the set of engineering practices recommended by Microsoft to develop more secure software. We use these practices internally to engineer Windows.

The comments on this blog show that the quality of a complete system contains many different attributes, each of varying importance to different people, and that people have a wide range of opinions about Vista’s overall quality. I spend a lot of time on core reliability of the OS and in studying the telemetry we collect from real users (only if they opt-in to the Customer Experience Improvement Program) I know that Vista SP1 is just as reliable as XP overall and more reliable in some important ways. The telemetry guided us on what to address in SP1. I was glad to see one way pointed out by people commenting about sleep and resume working better in Vista. I am also excited by the prospect of continuing our efforts (we are) using the telemetry to drive Vista to be the most reliable version of Windows ever. I add to the list of Vista’s qualities successfully cutting security vulnerabilities by just under half compared to XP.This blog is about Windows 7, but you should know that we are working on Windows 7 with a deep understanding of the performance of Windows Vista in the real world.

In the most important ways, people who have emailed and commented have highlighted opportunities for us to improve the Windows engineering system. Performance, reliability, compatibility, and failing to deliver on new technology promises are popular themes in the comments. One of the best ways we can address these is by better day-to-day management of the engineering of the Windows 7 code base—or the daily build quality. We have taken many concrete steps to improve how we manage the project so that we do much better on this dimension.

I hope you are reading this and going, “Well, duh!” but my experience with software projects of all sizes and in many organizations tells me this is not as obvious or easily attainable as we wish.

Daily Build Quality

Daily quality matters a great deal in a software project because every day you make decisions based on your best understanding of how much work is left. When the average daily build has low quality, it is impossible to know how much work is left, and you make a lot of bad engineering decisions. As the number of contributing engineers increases (because we want to do more), the importance of daily quality rises rapidly because the integration burden increases according to the probability of any single programmer’s error. This problem is more than just not knowing what the number of bugs in the product is. If that were all the trouble caused then at least each developer would have their fate in their own hands. The much more insidious side-effect is when developers lack the confidence to integrate all of the daily changes into their personal work. When this happens there are many bugs, incompatibilities, and other issues that we can’t know because the code changes have never been brought together on any machine.

I’ve prepared a graph to illustrate the phenomenon using a simple formula predicting the build breaks caused by a 1 in 100 error rate on the part of individual programmers over a spectrum of group sizes (blue line). A one percent error rate is good. If one used a typical rate it would be a little worse than that. I’ve included two other lines showing the build break probability if we cut the average individual error rate by half (red line) and by a tenth (green line). You can see that mechanisms that improve the daily quality of each engineer impacts the overall daily build quality by quite a large amount.

For a team the size of Windows, it is quite a feat for the daily builds to be reliable.

Our improvement in Windows 7 leveraged a big improvement in the Vista engineering system, an investment in a common test automation infrastructure across all the feature teams of Windows. (You will see here that there is an inevitable link between the engineering processes themselves and the organization of the team, a link many people don’t recognize.) Using this infrastructure, we can verify the code changes supplied by every feature team before they are merged into the daily build. Inside of the feature team this infrastructure can be used to verify the code changes of all of the programmers every day. You can see in the chart how the average of 40 programmers per feature team balances the build break probability so that inside of a feature team the build breaks relatively infrequently.

For Windows 7 we have largely succeeded at keeping the build at a high level of quality every day. While we have occasional breaks as we integrate the work of all the developers, the automation allows us to find and repair any issues and issue a high quality build virtually every day. I have been using Windows 7 for my daily life since the start of the project with relatively few difficulties. (I know many folks are anxious to join me in using Windows 7 builds every day—hang in there!)

For fun I’ve included a couple pictures from our build lab where builds and verification tests for servers and clients are running 24x7:

Conclusion

Whew! That seems like a wind sprint through a deep topic that I spend a lot of time on, but I hope you found it interesting. I hope you start to get the idea that we have been very holistic in thinking through new ways of working and improvements to how we engineer Windows through this example. The ultimate test of our thinking will be the quality of product itself. What is your point of view on this important software engineering issue?

Total 0.218261(s) query 3, Time now is:03-28 22:24, Gzip enabled 粤ICP备07514325号-1
Powered by PHPWind v7.3.2 Certificate Code © 2003-13 秋无痕论坛