1. Evolving test role

　　微软的正式测试工程师可以追溯到1990年左右，以后以每年大概500人递增。现在大概有1万左右的测试工程师。回顾走过的20多年，其中最为明显的特征就是微软对软件测试和质量控制的认识不是一成不变的，而是随着经验的积累，产品的演变不断演变，同时测试工程师的职责也不断在演变。最开始叫software test engineer (STE)，主要职责是设计测试用例，手工黑盒测试。2000年左右演变成Software Design Engineer in Test (SDET)，主要职责是设计测试用例，开发测试自动化代码，测试基础设施和测试工具。同时把繁琐的简单的手工测试外包给印度和中国的外包公司。2005年以前公司的测试文化基本上是：产品质量是测试人员的责任，测试人员保证产品质量，测试人员很多时候像给开发打下手为开发服务。2005年后随着敏捷和软件及服务的出现，测试的角色逐渐从依赖测试来提高产品质量转变成用测试来建立保证产品质量的具体要素。测试不再像给开发打下手，而是转变成一个独立的岗位为产品质量服务。2010后，随着软件即服务和云计算的日趋成熟，微软很多产品组转向开发服务型的产品，同时测试人员的角色为了适应新的挑战而继续演变，比如现在很多组开发也做测试，测试也做开发，两者间的界限越来越模糊。正是测试的这种灵活性和对不同时期不同产品的适应性使得每个发布产品的质量得以有效保证。

　　2. Set full-time test role

　　微软的产品一直以桌面产品为主，比如Windows, Office, SQL server, etc…。这些类型的产品的共同特点就是对发布版本的质量要求非常非常高，它要求产品在发布之前必须修复几乎所有的bug，至少不可以有关键性bug。因为万一漏掉一个关键性的bug，召回产品或发布热修复的代价太大。所以每个产品组在产品开发过程中投入大量的测试人员来全方位，反反复复测试， 包括功能测试，性能压力测试，本地化国际化测试，安全性测试，使用性和兼容性测试，等等。这些大量繁重的工作不可能都有dev来做。有了专职的测试人员不仅大大减轻了开发人员的工作量，而且通过测试人员特有的、经过专门训练的技能可以在产品发布之前找出更多、更为关键的bug。所以在这种情况下，专职测试人员不仅是有用的而且是必须的，他们对提高软件质量起到至关重要的作用。在像windows和office这两个最大的产品组，专职测试人员的数量和开发一样多，再加上大量外包公司的测试人员，可以说测试人员的数量实际上是开发的将近两倍。但是，如前所述，随着从桌面产品逐渐转向服务型的产品(软件即服务)，专职测试人员的作用在逐渐下降。主要原因是：首先产品质量不再是光光通过“测试”来提高了;其次对发布版本质量要求有所降低，因为服务型产品不是安装在用户机器上而是部署在微软自己的数据中心里，如果有bug，开发人员可以很快修复然后及时更新产品(而不是像桌面产品需要召回)，所以热修复的成本大大降低了;还有就是利用用户来做测试(我们在下面会具体再谈)。所以在服务型产品中，专职测试人员的作用不再像以前那样显得至关重要。微软现在许多组在削减测试，或者转成dev，即使保留测试的头衔，做的工作也不是严格意义上的测试了。另外一点值得说明的是，虽然专职测试人员数量有所减少，但是并不意味着测试的覆盖率就一定减少了。很多时候实际上是测试的覆盖率更多了，这主要是因为开发做越来越多的测试，同时测试的效率提高。

　　3. Heavily invest in test automation

　　测试自动化不是万能的，但是没有测试自动化是万万不能的。测试自动化可以把测试人员从枯燥重复的手工测试中解脱出来做更多更有有技术含量的工作。当然测试自动化需要前期投入，而且不稳定的测试自动化还会把测试人员拽到疲于维护的泥潭中。但是这不是否定测试自动化的理由。没有用好测试自动化并不代表它没有用。而且，敏捷测试，持续集成，快速交付，等等都是以测试自动化为基础的。公司可以根据具体情况采用逐步提高的策略，比如先自动化每日构建，再自动化部署，然后自动化最关键的测试用例，次关键的测试用例，等等。微软测试工程师有超过80%的时间是在写测试代码。它们包括测试自动化代码，开发基础设施代码以及开发测试工具。默认情况下自动化所有测试用例，除非你有合理的理由不自动化。我个人的准则是：如果手工重复运行一个过程超过3次，就是时候自动化了。通常在一个发布周期的计划阶段，PM,dev，test,根据本次发布的时间长短和内容各自做计划，然后汇总讨论，制定一个最终的符合各个角色的发布计划。Pm和dev决定本次发布中的产品新功能，测试决定本次发布中的测试有关的工作量，比如为新功能而添加的测试自动化，为修改现有功能而修改测试，需要开发或改进的测试工具或基础设施。经过讨论后大家一致同意最终计划。计划好后，大家就根据各自的计划并行工作，当然中间大家及时沟通进度，如果需要，调整计划。这个过程的好处是把与测试自动相关的所有工作都放到开始项目计划中来，包括新功能测试自动化，现有代码的维护，工具的创建和改进等等，这不仅逐步提高测试自动化覆盖率，而且使得基础设施和测试工具逐渐成熟和完善。成熟和完善的设施和工具同时极大提供了开发效率和速度，比如大部分产品组都有daily execution 和checkin quality gate：

　　× Daily execution: 每天晚上，自动生成每日构建，自动部署到测试环境，自动运行测试用例。对于失败的测试用例，系统自动报bug,并且对测试日志和产品日志进行自动分析，把相关信息放到bug中。最后自动发送测试结果到整个组。第二天早上到办公室，每个人都会看到已经运行完的测试报告。这使得测试可以有更多的时间自动化更多的用例，更多的时间分析测试缺口或做探索性测试。#p#分页标题#e#

　　× Checkin quality gate: 开发在提交代码之前通过运行一个简单命令可以把相关测试自动运行一遍。这使得开发从一开始就提交高质量的代码。

　　即使在做手工或探索性测试，测试工程师也尽可能使用测试工具来自动化其中步骤，从而使得测试人员完全专注于应该专注的地方，比如思考探索尝试，而不是在别的地方浪费时间，比如准备测试数据，搭建测试环境，分析日志，报bug等等。 打个简单的比喻，比如你要从北京到上海开会，手工测试就好像你骑自行车过去，你的目的是开会但是你结果把大量时间浪费在路上了。测试自动化就好像你乘飞机过去。还有看起来来好像飞机票很贵，成本比骑自行车要大，但实际上最后骑自行车的成本要高的很多。只不过很多成本你当时看不到罢了。

　　所以很多我给做培训的公司的经理抱怨说我们也想做单元测试，做测试自动化，但是就是成本负担不起。我就说你只看到“做”的成本，因为它很直接;而看不到“不做”的成本，因为你不能马上看到。业界无数公司，项目已经证明在单元测试和测试自动化在提高软件质量方面“不做”的成本要比“做”的成本大的多得多

　　PM常常遇到一個難題，就是有好多東西想要做，到無奈什麼事都得透過工程師，沒辦法自己動手，於是因為和工程師不太美好的關係，最後實際的產品都沒有設計時看起來好。我這邊講的是「網路公司」的狀態，PM泛指那些規劃出產品的人。其他產業也許也有類似情形，以下這些「教戰手則」，提供給正在摸索自己生存之道的PM一些參考。

　　先弄清什麼做得出來、什麼做不出來:

　　常常有PM會提出一些天馬行空的idea，以致有時候讓工程師覺得合作起來相當吃力。這是由於並不知道什麼可以做什麼不能做。以網站來說，這其實很容易知道，不需要太多的學習和知識。如果有一個功能，你在兩、三個網站都看得到，99%它是做得出來的。例如你想要有一個頁面，填地址時選完「縣市」，下一個選單就會載入你選的這個縣市的行政區。如果你做些功課，就可以發現這樣的表單在很多網站都出現過。那99%就是做得出來。如果你想出一種呈現的方式，從來沒在任何地看過，那就比較有可能是做不出來的。在對工程師溝通時，假如你想做一個像這種選「縣市」的下拉選單，你最好請工程師去看別人的那個網頁，而不是用你自己的方式描述。工程師通常有不想輸的性格，如果別的網站做得出來，他不會想要自己做不出來。

　　永遠不要和工師辯論任何和技術有關的東西:

　　當PM能學一點點網頁的概念是好的，但跟工程師合作，你可能常常會聽到「這很難做」的feedback。它可能代表幾種不同的意思。可能代表真的很難做，也可能代表他不想幫你做。如果是第二種，有很多種方法可以讓他妥協。但戳破他和找他辯論絕對是最差勁的方法。當他說這個技術上有困難時，絕對不要跟他說「這個只要… 就可以了呀!」這樣也許讓自己看起來比較聰明，但你們的關係已經完蛋了。而且工程師的性格容易有非常強的自尊心，所以千萬別這麼做。而且，technical的領域，你可能永遠也辯不贏他。很多「這個不能做」的問題，不是來自於理性，而是來自於不想、不願意、覺得這個沒意義、或真的很花時間。真的要做的話，99%的東西大概都可以做。因此當這種看起來由technical角度來拒絕你的狀況發生，如果你真的很想堅持你的想法做下去，請試著脫離technical的討論，你該了解他所提出technical的障礙，但絕對不要和他在這個領域上辯論。因為你辯贏或輸都沒有任何好處。

　　工程師喜歡你去求他:

　　工程師很容易有某一種性格，是坐在那邊希望大家都去拜託他。所以你不難想像要讓這種人幫你做事的方法就是你要放低你的姿態。你要讓他覺得是你需要他，不是他一定要幫你。即使你心裡一直想「公司付你錢來上班本來就是要做這些的…」放低姿態。也許身為PM的你，在每個project有進展的時候和卡住沒進展的時刻，拿飲料點的menu去問工程師要喝什麼是個好方法。

　　把所有credit歸給工程師:

　　在公司裡，因為很多產品是由PM規劃的。因此project的成功，大家很容易覺得是PM的功勞。請努力在任何公開的場合、email，把這些credit歸給和你一起合作的工程師。同樣一個spec，一個心情好的工程師，可以把它做成100分。一個心情不好的工程師，可以把它做成60分。兩個都可以100%符合你的spec，但是一個可以爛到有無數問題。因為軟體不是事前可以想清楚的。所以一個不開心的工程師，可以看到許多問題但「視而不見」，也不主動來跟你說，那你就完了。所以一定要讓全公司的人都覺得這些成就屬於工程師的。你把credit拿走一次，下一次你就完了，因為沒有人想為你賣命了。

　　不要輕視「工程師的project」

　　你合作的工程師可能說他現很忙，因為他正在「重寫一些function」或是「讓資料庫的速度快一點點」。很多PM在聽到這些的時候，並沒有很知道他們在做什麼，於是表現出來的會是對這些project沒那麼在乎或甚至不覺得他們重要。通常工程師最喜歡做這種隱性的project。因為他們可以不用聽PM的指揮。對於一個健康的公司來說，一定會有一定比例的資源投在這些project。要不要做通常是由老闆，或更懂得這些東西的人來決定。但你一定要在工程師的面前讓大家覺得你看起來對這些非常認同。

　　姿態放軟，但不能失去主導權

　　雖然前面說你姿態要軟，但你絕對不能把你的project交給工程師後，你就失去了主導權。因為這樣會讓你在老闆面前，看起來變得沒有太多價值。你最少要繼續掌握你project的「時程」和「內容」。也就是你一定要維持你的「主導權」，對該堅持的東西繼續堅持，對一些東西妥協，但不能全交給工程師決定。

　　不要finalize所有設計後，再交給工程師

　　絕大多數的工程師對這樣的流程很反感，所以請想辦法在設計階段，就去請教一下工程師的意見。他也許說他很忙，你想就好。即使只是得到這句話，都有很大的價值。這表示他放棄了他未來因為你在project早期沒找他先過過，以致他責怪你的權利。

　　老師教我們怎麼寫程式，但從來沒告訴我們在公司裡，會有個叫做PM的人每天分派作業給我們，還逼著我們趕快做完。這是許多軟體工程師進入職場的第一個驚喜。隔了不久，還會發現，這些可能把你壓得死死的PM，多半一行程式都不會寫。於是我們會面臨一種很矛盾的心情，有時候會是一種有點被欺負的心理。這篇文章是前一篇文章PM如何突破工程師的心防的延伸，我們討論的是工程師在這樣狀況下的生存之道。

　　(1)提高自己的能見度

　　在非常多的公司，上層的老闆或公司的大老闆只看得到一個project的PM，而看不到背後辛苦的工程師。也就是說，你的努力和成果，被遮敝了。我一直相信在職場上，讓自己在老闆或其他同事前有「能見度」是重要的。能見度除了在很多狀況下(會議發言、討論…)可以顯現出來外。提供一個我有個朋友很厲害的一招給各位參考。身為一個工程師的他，在每個大的project進行完後，都會「不經意」的寄出一封「謝謝信」給參與這個project的每個人，順便cc給本來根本不知道他在做什麼的大老闆。信裡面一一點名感謝每個人給他的指導和這個project的協助。這種信每個人看了都很高興，最重要的是最後大老闆也對他有了深刻的印象。

　　(2)不要每天只埋頭寫程式:

　　工程師大部份很喜歡埋頭寫程式，因為這是自己最擅長，也是最不花力氣的事情。但如果你每天100%時間寫程式，我保證你會自我感覺良好，但是所有人都不知道你在做什麼。所以也許該換換策略，讓自己的時間有多一點的部份是用來「表現自己」。「表現自己」不代表做一些表面功夫浪費時間。而是以你的角色，來參與討論，給出有意義的建議。工程師很喜歡只用電腦和其他人溝通，想要進度都用一個系統來追蹤，想法都用email來討論。在職場上，很重要的是你要學習少用email，多走過去和那個人說話。也許走過去多花了1分鐘，但是你和其他人互動良好，會讓你在職場上過得比較順利。

　　(3)站在老闆的角度想事情:

　　工程師由於角色的關係，非常容易會站在「技術」的角度想事情，但往往常被主管否決而覺得灰心。公司的想法通常和PM的想法比較接近，都是站在公司的利益想事情，極少用「技術」的角度想事情。你要試著跟他們想的一樣，你的日子才會過得快樂。舉例來說: 假如我們公司現在要輸入10000筆資料。有兩個方案，方案A是「手動輸入」，方案B是「用程式自動匯入」。方案A要請10個工讀生，一筆一筆輸入幾乎都沒有差太多的資料。方案B是支無敵厲害的程式，你開發一天，程式跑3秒鐘就全部完成。但評估起來方案A的總體成本比方案B還要低。我相信極大多數的公司經營者，都會願意找來10個人，做著重複的事情，一筆一筆key in資料。如果你以工程師的角度來想，你可能會覺得「這個這麼簡單，一支程式就好了」，然後開始覺得老闆選擇方案B真迂腐。你要試著讓你的大腦跟公司的利益sync，這樣會讓你好過很多。因為絕大多數的PM都知道他們的大腦要怎麼跟老闆sync。在老闆面前讓自己顯得比PM聰明的方法只有一個，那就是大腦和公司利益的sync做得比PM還徹底。

　　(4)用PM害怕的弱點有效去爭取更多開發時間

　　PM很喜歡每個東西都如期上線，如果提早上線就更好。很多人會因為deadline而跟PM翻臉，這是不智的。回到我那位工程師朋友的例子，他會和顏悅色的對PM說「我可以每天熬夜來把它做完，有可能可以如期上線，但我知道它會出現很多『我們』現在都沒想到的問題，那可能會讓老闆(或客戶)覺得我們很不仔細。但如果你可以幫我爭取多一點時間，我可以讓它品質好很多。」對PM來說，除了要「快」以外，東西如果出來很爛，也打到了他的痛點。我的工程師朋友用這個方法幫自己爭取到了比較長的開發時間，和更好的睡眠。

　　(5)用PM的語言和他溝通

　　很多工程師會習慣用自己的語言和PM溝通，於是造成溝通不良。我們得試著讓自己對他們的談話，是世界上任何一個人都聽得懂的語言。儘量少提技術的術語，儘量少讓PM覺得你用你的技術優勢在打壓他。因為PM不可能學會工程師的語言，所以你們唯一能溝通的可能，就是你學會用PM的語言。

　　(6)變成工程師團隊裡面最受PM們歡迎的人

　　你會發現，如果叫PM們投票，從最喜歡合作的工程師，排到最不喜歡合作的工程師。大家的清單常常非常一致。而且你會發現，在清單名列前矛的人，通常在職場上容易步步高升。所以，想辦法變成那個人吧! 因為PM們對你的評價，往往在公司裡，和你的工程師主管對你的評價同樣重要。

　　(7)上班前三個月，不要試著改變公司任何東西

　　公司的系統、公司的project、流程，所有的東西。會是現在這個樣子，都必定有它的原因。有理性的原因，也有不理性的原因，也可能它的原因就是沒有原因。但絕大多數的公司找你進去，是想要你把一個東西，在他「現在的架構」下開發出來。在前三個月，如果你覺得大家用的開發環境很爛、測試的流程很爛、任何平台很爛。請先忍耐一下，因為除了非常非常open minded的主管和同事，絕大多數的人不會對你剛進來就想改變一切的想法太歡迎。

　　(8)歸功給PM:

　　EQ好的PM會把project歸功給工程師。但做為工程師的你，如果EQ夠好，應該再把它歸功給PM。不要因為這是你寫的code，就認為這是你自己做出來的。因為這樣除了自己感覺良好外，對職場生存沒有幫助。想辦法「言必談PM」。把自己和PM當成一個team，這個project是我們一起做出來的。雖然很多PM會戲稱自己是在旁邊幫忙打雜的，但是他會很感謝你很體貼的把一些功勞歸於他。

　　(9)不要為了enjoy自己的成就感，浪費公司的資源

　　很多工程師喜歡把公司當lab，去試驗一些新的技術。如果這對公司「真的有幫助」的話，那當然很好。在做這些事或提議前，請試著用老闆的角度想，在公司利益最大化的前提下(而非個人學習或成就感)，他會不會打從心裡支持你做這樣的試驗。如果不會，那就千萬不要做。因為在你做的很開心的同時，別人可能覺得這只是在浪費公司資源。

　　(10)變成一個更像PM的人#p#分页标题#e#

　　在技術上你應該向你其他工程師同事看齊，但在「性格」或「行為」上，通常你應該去模仿PM team的人。請相信我，在絕大多數公司，「性格」和「行為」近似於PM的工程師，在公司裡是最吃香的。

　　寫這篇文章，也許還會再得到一些批評。但我只是單純善意的，想告訴工程師們。我們應該提高自己的能見度，適度的讓其他人看到我們的表現。以及讓自己變成一個外表看起來像PM的工程師，通常在公司裡會過得蠻好的。很多工程師會覺得自己被PM欺負，但PM通常不會欺負長得和他們一樣的人。如果你喜歡這篇文章，也許你可以再看看這篇: PM如何突破工程師心防?

　　从较高的层次来看，书写需求文档的目的就是要提供对所需行为的有效描述。该所需行为可用一个黑盒系统描述，并需要注意以下细节：

　　• 工程师可以根据系统所说进行实现

　　• 测试人员，在不与开发人员沟通的前提下，可以利用满足硬件要求的设备验证需求。

　　• 最终产生的成果满足终端用户的要求。

　　黑盒测试 书写优质的需求文档：

　　最基本的原则是：需求文档应当尽量简洁，用最易懂的描述来约束系统的预期行为。如果你遵循这个原则，剩下的那些重要因素(可测试性、避免过度设计等等)都将变得顺理成章。

　　列举一下更详细的规则，通常会更有帮助。下面是书写优质需求文档需要遵循的步骤：

　　1. 定义系统的边界。这也是黑盒系统所必要的。

　　2. 定义输入和输出。这也应当是你看待内部系统的唯一方式。

　　3. 用最易懂的方式描述系统的预期行为

　　4. 除了输入和输出之外，你的需求是不是还涉及了系统的其他部分?如果是，那么你的需求就设计过度了。重构需求，让它变得精简。

　　5. 你的需求是不是过于模棱两可?加入更多的限定规范。注意：有些模棱两可的描述并不是坏事，假设描述所包含的所有情况均可被接受，且测试的时候不需要附加的信息加以说明，那么就没关系。你不需要(也不应该)把系统的行为限制得过头。

　　6. 你的需求是否可测试?(这里指的是黑盒测试)如果不是，你最好返回到第4步。如果这种返工发生很多次，那就说明你的黑盒无法正确描述系统，或者你的测试工具不够优秀。无论是哪种情况，不可测试的需求文档几乎就是一文不值的。

　　7. 你的需求文档通俗易懂么?如果你的需求文档非常难以读懂，那就说明你写得不好，只能给那些照着你的需求负责实施的人带来无尽的痛苦。如果是这样，回到第3步。

　　8. 你是不是真的做到了第4步?你确认么?再检查一下。

　　例子：下面的例子，让我们描述一个自制的嵌入式设备的需求，这个设备能从弯曲传感器上读取弯曲的频率，并根据不同的频率值让一个LED闪烁。

　　显然，我们已经完成了步骤2和步骤3了!

　　• 输入：从弯曲传感器读取数据。

　　• 输出：LED。

　　但是我们跳过了步骤1：

　　• 在这个例子里，我们将把黑盒画到设备的微处理器上。

　　让我们继续往下进行,

　　第四步：除了输入和输出以外，我们是否还涉及了其他的系统边界?

　　• 微处理器并不关心从弯曲传感器读取什么样的数据，从处理器的角度来看，仅需要做的是测量ADC脚的电压而已。

　　• LED仅由数字输出脚控制。

　　下面，让我们来修正这个问题：

　　第0版本的需求：

　　1. 该设备应当根据ADC脚的不同频率的电压，来切换数字输出端的状态。

　　第五步: 需求写模棱两可么?

　　恩，我们的描述太模棱两可了.输出端切换的速度要多快? 跟电压的关系如何? 输入电压的范围是多少? 让我们加一些更细节的描述吧:

　　版本0.1

　　1. 输出端应当由一个自由活动的定时器进行控制

　　2. 自由运行定时器的频率最高不得高于每秒10次,不得低于每秒1次.

　　3. 自由运行定时器的触发频率应当在最高和最低值之间呈线性变化,并与ADC端的输入电压成正比.

　　4. ADC端的输入电压应当每100毫秒读取一次

　　5. 当ADC端的输入电压端被读入时,控制自由运行定时器周期时间的注册值也应当被更新.

　　6. ADC输入端的电压有效范围应当被控制在0到1伏之间.

　　第六步: 你的需求是可测试的么?

　　• 首先，自由运行的定时器在这里不需要提及. 因为对它基本上无法进行黑盒测试，它既不是输入也不是输出，而且跟这两者也没有什么联系。

　　让我们用“数字输出端变化的频率应控制在每秒10次和每秒1次之间”来代替自由运 行定时器的测试标准。

　　• 对于上述的第四条需求，可能需要一些小修改才能作为测试标准。让我们用“ADC端的输入电压应当保证在每100毫秒内至少被读取一次”来加以描述，这样的描述能让我们预期的测试行为显得更加通俗易懂。

　　• 需求的第五条也需要一些小修改。我们如何才能检测电压的输出范围是在0到1伏之间呢? 总不能给个2伏的电压，然后看看元器件有没有被烧毁吧?

　　那么，说“检验系统在ADC端输入电压为1到2伏之间的时候，工作是否正常”，这样就检验就容易多了。需求描述应当是“正面”的，应当描述设备“应该”的行为，而不是设备“不应该”的行为。否则的话，测试将会无法进行。

　　版本0.2

　　1. 数字输出端的切换频率应当控制在每秒10次到每秒1次之间

　　2. 数字输出端的切换频率应当在最大值和最小值之间呈线性变化，并与ADC端的输入电压成正比

　　3. ADC端的输入电压应当保证在每100毫秒内至少被读取一次

　　4. 检验当ADC端的输入电压范围在0到1伏之间的时候，系统工作是否正常

　　第七步：你的需求是否通俗易懂?

　　相比于我们原来的描述：“根据弯曲传感器的输出不同频率来控制LED闪烁”，我们上面的那些需求描述显得难以阅读和理解。

　　我发现，让需求文档变得通俗易懂，最简单办法莫过于，把过于细节的东西抽取出来，然后以条目的形式单独定义。

　　版本1

　　1. 弯曲传感器应当保证至少在100毫秒内读取一次数据(放到注释单独列出)

　　2. 切换LED的状态，使其与弯曲传感器的读数保持一致

　　3. 当弯曲传感器的读数为1伏特时，LED状态切换的次数应当保持在平均一秒十次;当传感器的读数为0伏特时，LED的切换次数应保持在一秒1次。

　　定义：

　　• 弯曲传感器：输入电压位于ADC的X端。安全电压范围为0到1伏特(放到注释单独列出)

　　• LED状态：数字状态由Y端输出

　　这样就好多了(尽管还不完美)。这些需求通俗易懂，不涉及到系统内部实现，且易于测试。对于系统行为的限定也仅仅限于需要做什么，点到为止。(例如，对弯曲传感器的采样频率，在实现上也可以更高，只要不产生非预期行为，一切都可以)。

　　编写需求就仿佛是在大脑中构建软件的过程。因此要重于执行操作。

　　质量这个词用得太普遍以至于混乱，有时候它表示质量这个指标，有时候它隐含质量好的意思。而且不可避免的，好的质量常常和它的反面联系在一起，就好像以前的“质量万里行”，或者现在的3.15，列出的都是质量方面的问题，好像很少宣扬质量好的产品。所以很多时候，我们看质量是从反面(缺陷，或者质量不好的地方)来看的。在下面讨论的时候我们也会用或正或反的例子来看。虽然是在探讨软件的质量，但是为了便于理解，可能也会举别的产品的例子。

　　前一篇里面也提到，在传统的关于软件缺陷的定义中，是看实际做出来的产品是否和规格说明书(spec)一致，如果不一致那就是defect或者俗称bug。如果只是从这个范围来看，这个定义本身没有问题，因为如果做出来的东西不是我们想要的，那当然不对。所以下面我们得出质量的第一个方面。

　　Quality scope #1： 实现了说明书上的功能

　　比如你下载了一个电影播放器，它宣称可以支持MP4, MOV, RMVB, AVI格式，那么它必须可以正确播放这些格式的文件。这是一个很基本的要求，就像洗衣机要能洗衣服。如果实现这样的基本功能出现的问题，那么用户会非常生气，觉得质量太差，根本不能用，直接卸载掉，或者要求退货(商业产品)。

　　正因为这样的后果很严重，所以在测试中，对于这样的基本功能我们都会反复验证。

　　OK， 如果说明书上说的功能都实现了，那么就是一款质量很好的产品了吗? 实际上可能并非如此。那么差别在哪里呢?

　　Quality scope #2： 一些不言自明的要求

　　为什么说是不言自明呢。举个例子， 还是洗衣机，客户可能会说“我想买一台洗衣机”。然后他买回去一台，价格也还不错。回去后发现确实能洗衣服(上面提到的基本功能实现了)，但是有个问题，这个洗衣机洗一次衣服需要3个小时，而且洗的时候噪音很大。

　　洗衣机是很普遍的一个商品，用户在一开始买的时候可能也不会问洗一次要多长时间或者噪音多少分贝。这并不代表他没有这方面的标准，而是“不言自明”。 如果事先没有说明，这可能会带来一些纠纷，但是最终生产这样的洗衣机的厂家一定是这些问题的受害者。因为大家都会知道这个牌子的洗衣服超慢，而且噪音大。而如果只按照第一个scope的要求，它可能是一个很合格的产品，而且或许衣服还洗得挺干净的，通过了QA的测试。

　　我相信这一类的例子还可以举出很多

　　笔记本： 发热量比较小，不会太烫

　　杀毒软件：占用系统资源不要太多，机器启动也不会变得很慢

　　网上购物系统：响应时间不能太长

　　这方面的要求有很多，比如包括safety， performance，stability，impact to other software...

　　也正因为这一类的要求是“不言自明”的，所以开发的时候反倒容易被忽视。当然也可能是故意被忽视，因为技术和成本的原因，很多山寨产品就是如此吧。

　　比较好的做法是我们把这些方面的需求明确的列出来，并尽可能的进行量化。比如前面例子中涉及的时间和噪音问题，如果在内部的设计文档中就有明确的要求，最终出来的产品就不会有这么大的问题。

　　关于这一类的需求，还有几个特点。

　　1. 这方面的要求不容易确定，也不容易评估或者验证。

　　比如performance，比单纯的某个功能点，要复杂很多，有时候甚至什么是performance够好或者很好都难以界定。所以这也要求产品的设计和开发人员对产品和用户的需求有更输入的理解，而不只是照着做。

　　2. 这方面的产品特性是难以被抄袭的。

　　国内的山寨能力想必大家都见识过，很多产品出来后很快就有了功能十分相近的仿制品。小到手机，大到汽车。iphone的山寨版长得很像哦，而且也可以全屏触摸，multi-touch，而且不到1千块。还有双环的SUV，远一点看就是BMW X5，之前一位美国同事来出差看到一辆还特意掏出手机拍照留恋，因为他是X5车主。现实中，iphone在国内依然火爆，X5也还是很多人的dream car。因为有很多看不见的特性(比如performance)在它们和抄袭者之间划清了明确的界限，质量高下立现。当然，差别也不只是这么提到的这些，还有其他，比如branding。

　　好吧，如果我们的产品连这些不言自明的要求也考虑到了，那么是不是就会被认为质量很好呢? 不一定。

　　Quality scope #3： 设计符合用户的需求

　　在scope #1中，我们提到好的质量的最起码的条件就是实现了宣称的功能。那么引伸出另一个问题是，设计本身是合理的吗?

　　如果我们把developer定位成实现所需要的功能的人，把QA定位成验证这些功能是否正确实现了的人，那么这一部门的质量我们就没有办法覆盖到。因为如果是这样的定位，大家就不会去想，这样做合理吗?是用户想要的吗?做出来用户会喜欢吗? 反正我们只要按着spec做出来就好了。

　　这样的例子其实也有很多，比如

　　1. by design，我们只支持IE浏览器。但是我们发现很多用户都在使用Firefox和Chrome。

　　2. 我们的邮件历史查找只支持按收件人，现实中有很多用户也需要按发件人来查找

　　3. 如果用户重装系统的话，需要把曾经在老系统上配置的policy一条条重新配置，包括white list和black list。

　　4. 如果中途网络断掉了，用户前面输进去的东西下次联网后要重新输入。

　　类似的例子我们还可以举出很多。这些问题有什么共同点呢，那就是用户会抱怨我们的系统质量不够好，会给售后服务部门提一个case过来，提出他们的合理(从他们的角度确实是)要求。

　　如果我们的软件测试只停留在验证功能的角度，这些问题都不是问题，因为直接被我们排除在工作范围以外。但是最终这些问题都会被用户遇到，而且形成一种印象，那就是我们的产品质量不够好，特别是当竞争对手能够做到的时候。这就会形成一个gap，我们内部测试的时候觉得质量很好很稳定，但是用户还是不满意。#p#分页标题#e#

　　要解决这样的问题，可能有两个方面的要求

　　1. 测试人员(其实也包括开发人员)应该更多的从用户的角度来考虑问题。也就是常说的customer insight，从这个角度我们不是完全被动的按着spec走，而是可以challenge它，为什么做成这样，至少要知道为什么。

　　2. 测试人员要往开发流程的更前面走，而不只是等到产品做出来了之后去装起来验证。那样太晚了，而且修改的成本比早期要高很多。测试人员一开始就应该参与到产品的设计中，并且从用户的角度给出自己的意见。当然，这一部分也依赖于domain knowledge和个人的经验。

　　以上两个方面，对测试人员来讲，是挑战，因为要求更高了，也是机会，因为工作更有value了。

　　到目前为止，看起来我们的质量范围已经比较完整了? not yet。

　　Quality scope #4： 处理异常情况的能力

　　说到这个问题，还是举个例子吧。很多人可能对nokia手机的抗摔能力印象深刻，自己遇到的或者听朋友说的。常见的情节是这样的，一不小心从桌子上，或者从楼梯上把手机摔了下来，然后盖子摔开了，甚至电池也掉出来了，这时候心里拔凉的，但是抱着侥幸心理把它们重新装到一起，按下开机键，everything is OK，然后很happy。这种故事的后续是很多人因此第二次，第三次称为诺记的用户。因为觉得他们的手机质量很好。

　　这个故事有趣的地方在于说明书上从来不会写我们的手机从楼梯上摔下来不会有问题，厂家估计一般也不敢写。从楼梯上把手机摔下来绝对是一个异常的情况，也不是产品针对的场景，严格来说摔了之后坏了也属正常。但是反过来，如果这种异常的情况下，都没有问题，就会让人觉得质量很好。所以是一个质量加分的地方，也是branding build up的地方。比如你可以(以前?)不小心把水倒在Thinkpad的键盘上，也可以踢到macbook的电源线。

　　从软件的角度，异常的情况也有很多，比如

　　1. 突然停电

　　2. 硬件故障

　　3. 操作系统故障

　　4. 网络连接意外中断

　　5. 系统资源(内存，硬盘，网络端口等)耗尽

　　6. 用户的误操作

　　通常情况下，这些情况都不会发生，但是还是会发生(墨菲法则)的。如果只是一个PC上播放MP3的软件，遇到上面的情况就出问题了，甚至不能恢复需要重装，也许还是可以接受的，毕竟不是很重要的任务，而且也不常发生。但是如果是很重要的软件系统，而且有着重要的数据，不能恢复就问题大了。

　　对于这一部分，我们都应该考虑到，不管是开发还是测试。在测试的过程中，我们也要尽量的去验证。

　　其实质量还有很多的方面，比如。

　　Quality scope #5： 易用性

　　这是一个很重要的也常常被忽视的方面。很多时候我们开发产品的人会觉得自己的产品很好用，但是用户不觉得。我想其中一个很重要的原因是我们自己对这个领域很熟悉，而且对产品的各个功能，甚至他们内在的联系很清楚，再者因为工作的原因我们已经用了几十上百遍。这样算来易用性当然不是问题。但是我们不能要求我们的用户如此，因为用户不会(很多产品也不应该)花很多的时间研究学习我们的产品，他们购买我们产品提供的功能，就是要更有效和高效的完成他的工作。如果用户为了完成一件常见的工作，比如修改一项小的设置，就需要去修改很多的地方，而且没有提示要告诉他修改对应的地方，那么这就是我们产品的问题。

　　很多时候用户错用或者误用我们产品的功能，除了用户自身知识和经验不足之外，我们也应该反思一下是不是我们的产品做得不好用，流程和界面设计得太让人困惑。

　　易用性不只是产品的UI做得比较好看，更多的时候还包括产品的流程和接口的设计。这是一个很大的领域，这里限于自己的自己的了解和篇幅就不详述了。最基本的，我们可以把自己想象成对产品了解有限的初用者，很多问题就容易暴露出来了，或者还有一个办法，找一个不太了解人的，给他一些任务，让他去操作，然后去观察，听听他的感受。

　　Quality scope #6： 可维护性

　　维护的目的有很多，比如产品升级，功能升级，打补丁等等。 对于一个正式而长期使用的系统而言，特别是服务器软件，这是很常见的工作。这些方面处理的好坏往往也非常容易影响到用户对产品的判断和印象。常见的问题包括

　　1. 产品升级不能将来的版本的数据导过来，或者数据出错

　　2. 升级后不兼容或者对硬件要求很高

　　3. 打补丁或者升级后遇到问题是否可以回滚?

　　4. 用户报过来问题，如果收集信息定位问题

　　软件质量其实是一个很复杂的东西，上面提出的其实也只是工作中常遇到的一些方面(即便如此，很多还是常被忽略)，比如用户对产品质量的看法还会受到情感因素的影响，比如产品的UI，和客服人员的沟通过程，以及公司和产品的品牌等等。

　　从软件测试的角度，针对质量的不同的方面，我们也有不同类型的测试活动来保证，比如design review，还有各种测试类型，functional，stability，performance，deployment，migration，usability，stress，compatibility 等等。

　　Ricky

　　Jun 15， 2010

　　其实在实际的软件开发中，特别是对于质量比较重视的产品，质量的保证不只是测试，还包括了很多的其他活动，比如产品 design的group review，代码的审查等等。之前读过一些文章，很多人在提Defect prevention，而不只是defect detection。今天看到一篇很有趣的文章，觉得是另一种思路，很有启发。转载如下。

　　---------------------------------------------------------

　　原始出处： http://ucdchina.com/snap/7272

　　一个伟大的应用创新：领导和工人同时下井

　　在屡屡撞破中国人心理底线的安全事故潮中，最近国务院为强化安全生产，专门出了个规定：企业领导要轮流现场带班，煤矿和非煤矿山要有矿领导带班并与工人同时下井、升井。

　　相对于N多技术、制度的硬规定，这一个微小举动也许会带来更大的安全创新改革，它是一个伟大的应用创新，因为它是站在使用者的角度考虑解决问题的。

　　这个故事让我想到了另外一个著名的应用创新：二战时期的降落伞改革。

　　二战初期，美国空军降落伞合格率为 99.9%，这意味着每一千个就有一个出事，对于这种百万级的战略性产品而言，这非常影响士气，军方要求必须达到 100%。

　　制造商认为产品复杂不可能达到要求。降落伞的制造工艺的确复杂，它们采取类似的设计：有一个白稠制成的半球形伞衣，它由近30个组件构成，表面积达 50多平方米。每个降落伞都有出厂编号，甚至有降落伞检验员的签名。但是，如果空降兵碰到那不幸的0.01%，他就会像自由落体的物体一样坠下地面，这是空降兵的梦魇。

　　最后，美军想出了一个“微小创新”：军方改变检查质量的制度，决定从厂商交货的降落伞中随机挑出一个，让厂商负责人亲自从飞机上跳下。奇迹出现了，不合格率很快降为零。

　　但是，我们的身边仍然被大量极差的用户体验所包裹，特别是我们的基础设施，一个重要的原因就在于，很多决策者很少站在使用者的角度考虑问题。

　　“领导和工人同时下井”是被逼出来的解决方案，但是，只有在被逼无奈情况下才能这样吗?主动的拥抱用户体验有那么难吗?

　　-----------------------------------------------------------

　　“相对于N多技术、制度的硬规定，这一个微小举动也许会带来更大的安全创新改革，它是一个伟大的应用创新，因为它是站在使用者的角度考虑解决问题的”

　　我觉得这是一个很有趣的例子，也会让提高质量的思考更加开阔，而不只是停留在技术，特别是测试的层面。或者如有些书上提到的，build up a quality culture。不过不得不说这是一个有中国特色的方法，不知道会不会衍生出代人签到的问题。

　　是的，quality的 culture，主观的对与quality的意愿(主动或者被动的)很强烈的话，总是能够想出提高的方法，但是如果只是应付评测或者规定的条款，其得到的结果可能相差很多。

　　如此说来，不免让人有些失望，因为这样看来，QA或者Tester在保证高质量的软件的过程中的作用只是部分的。是的，我想是这样的，因为质量很多时候被很多因素决定，商业的目标和产品的市场定位，比如Benz和QQ;材料的选择，铝镁合金还是塑料(换成软件中核心的组件也是一个道理);还有架构的设计。

　　但是尽管如此，测试在产品质量过程中还是扮演了很重要的角色，对应于上一篇(什么是质量，http://blog.csdn.net/superqa/archive/2010/06/15/5672522.aspx)中提到，测试可以保证说明书上所有的功能，包括那些不言自明的功能都被高质量的实现了，更有经验的测试人员也会验证到用户的需求和稳定性、易用性等指标，甚至往更前面影响到产品的设计。

　　总的来说，我的思路是先试图弄清楚质量包含哪些方面;然后看在哪些方面，还有方法可以保证高的质量;然后进一步来看，现在我们的测试人员做到了哪些，哪些也是我们可以去做的。这个系列的文章就是这样的一些探索和思考。

　　从较高的层次来看，书写需求文档的目的就是要提供对所需行为的有效描述。该所需行为可用一个黑盒系统描述，并需要注意以下细节：

　　• 工程师可以根据系统所说进行实现

　　• 测试人员，在不与开发人员沟通的前提下，可以利用满足硬件要求的设备验证需求。

　　• 最终产生的成果满足终端用户的要求。

　　黑盒测试 书写优质的需求文档：

　　最基本的原则是：需求文档应当尽量简洁，用最易懂的描述来约束系统的预期行为。如果你遵循这个原则，剩下的那些重要因素(可测试性、避免过度设计等等)都将变得顺理成章。

　　列举一下更详细的规则，通常会更有帮助。下面是书写优质需求文档需要遵循的步骤：

　　1. 定义系统的边界。这也是黑盒系统所必要的。

　　2. 定义输入和输出。这也应当是你看待内部系统的唯一方式。

　　3. 用最易懂的方式描述系统的预期行为

　　4. 除了输入和输出之外，你的需求是不是还涉及了系统的其他部分?如果是，那么你的需求就设计过度了。重构需求，让它变得精简。

　　5. 你的需求是不是过于模棱两可?加入更多的限定规范。注意：有些模棱两可的描述并不是坏事，假设描述所包含的所有情况均可被接受，且测试的时候不需要附加的信息加以说明，那么就没关系。你不需要(也不应该)把系统的行为限制得过头。

　　6. 你的需求是否可测试?(这里指的是黑盒测试)如果不是，你最好返回到第4步。如果这种返工发生很多次，那就说明你的黑盒无法正确描述系统，或者你的测试工具不够优秀。无论是哪种情况，不可测试的需求文档几乎就是一文不值的。

　　7. 你的需求文档通俗易懂么?如果你的需求文档非常难以读懂，那就说明你写得不好，只能给那些照着你的需求负责实施的人带来无尽的痛苦。如果是这样，回到第3步。

　　8. 你是不是真的做到了第4步?你确认么?再检查一下。

　　例子：下面的例子，让我们描述一个自制的嵌入式设备的需求，这个设备能从弯曲传感器上读取弯曲的频率，并根据不同的频率值让一个LED闪烁。

　　显然，我们已经完成了步骤2和步骤3了!

　　• 输入：从弯曲传感器读取数据。

　　• 输出：LED。

　　但是我们跳过了步骤1：

　　• 在这个例子里，我们将把黑盒画到设备的微处理器上。

　　让我们继续往下进行,

　　第四步：除了输入和输出以外，我们是否还涉及了其他的系统边界?

　　• 微处理器并不关心从弯曲传感器读取什么样的数据，从处理器的角度来看，仅需要做的是测量ADC脚的电压而已。

　　• LED仅由数字输出脚控制。

　　下面，让我们来修正这个问题：

　　第0版本的需求：

　　1. 该设备应当根据ADC脚的不同频率的电压，来切换数字输出端的状态。

　　第五步: 需求写模棱两可么?

　　恩，我们的描述太模棱两可了.输出端切换的速度要多快? 跟电压的关系如何? 输入电压的范围是多少? 让我们加一些更细节的描述吧:

　　版本0.1

　　1. 输出端应当由一个自由活动的定时器进行控制

　　2. 自由运行定时器的频率最高不得高于每秒10次,不得低于每秒1次.

　　3. 自由运行定时器的触发频率应当在最高和最低值之间呈线性变化,并与ADC端的输入电压成正比.

　　4. ADC端的输入电压应当每100毫秒读取一次

　　5. 当ADC端的输入电压端被读入时,控制自由运行定时器周期时间的注册值也应当被更新.

　　6. ADC输入端的电压有效范围应当被控制在0到1伏之间.

　　第六步: 你的需求是可测试的么?

　　• 首先，自由运行的定时器在这里不需要提及. 因为对它基本上无法进行黑盒测试，它既不是输入也不是输出，而且跟这两者也没有什么联系。

　　让我们用“数字输出端变化的频率应控制在每秒10次和每秒1次之间”来代替自由运 行定时器的测试标准。

　　• 对于上述的第四条需求，可能需要一些小修改才能作为测试标准。让我们用“ADC端的输入电压应当保证在每100毫秒内至少被读取一次”来加以描述，这样的描述能让我们预期的测试行为显得更加通俗易懂。

　　• 需求的第五条也需要一些小修改。我们如何才能检测电压的输出范围是在0到1伏之间呢? 总不能给个2伏的电压，然后看看元器件有没有被烧毁吧?

　　那么，说“检验系统在ADC端输入电压为1到2伏之间的时候，工作是否正常”，这样就检验就容易多了。需求描述应当是“正面”的，应当描述设备“应该”的行为，而不是设备“不应该”的行为。否则的话，测试将会无法进行。

　　版本0.2

　　1. 数字输出端的切换频率应当控制在每秒10次到每秒1次之间

　　2. 数字输出端的切换频率应当在最大值和最小值之间呈线性变化，并与ADC端的输入电压成正比

　　3. ADC端的输入电压应当保证在每100毫秒内至少被读取一次

　　4. 检验当ADC端的输入电压范围在0到1伏之间的时候，系统工作是否正常

　　第七步：你的需求是否通俗易懂?

　　相比于我们原来的描述：“根据弯曲传感器的输出不同频率来控制LED闪烁”，我们上面的那些需求描述显得难以阅读和理解。

　　我发现，让需求文档变得通俗易懂，最简单办法莫过于，把过于细节的东西抽取出来，然后以条目的形式单独定义。

　　版本1

　　1. 弯曲传感器应当保证至少在100毫秒内读取一次数据(放到注释单独列出)

　　2. 切换LED的状态，使其与弯曲传感器的读数保持一致

　　3. 当弯曲传感器的读数为1伏特时，LED状态切换的次数应当保持在平均一秒十次;当传感器的读数为0伏特时，LED的切换次数应保持在一秒1次。

　　定义：

　　• 弯曲传感器：输入电压位于ADC的X端。安全电压范围为0到1伏特(放到注释单独列出)

　　• LED状态：数字状态由Y端输出

　　这样就好多了(尽管还不完美)。这些需求通俗易懂，不涉及到系统内部实现，且易于测试。对于系统行为的限定也仅仅限于需要做什么，点到为止。(例如，对弯曲传感器的采样频率，在实现上也可以更高，只要不产生非预期行为，一切都可以)。

　　编写需求就仿佛是在大脑中构建软件的过程。因此要重于执行操作。

　　1.让每个队员都要参与这个过程。

　　2.讨论每一个用户故事应该如何实现。确定开发任务之前，

　　3.对于完成的标准要有明确的定义。

　　4.标识出所以需要完成的任务。

　　5.不要事先分配任务。

　　6.重新审视sprint的承诺。

　　7.不要使用过多的时间。

　　8. 在sprint过程中演化Sprint Backlog。

　　本文向你介绍测试驱动开发的概念，并用一个简单的示例项目来做示范。

　　介绍

　　开发PHP产品有很多不同的方法。我们大多数倾向于从一个简单的脚本开始，逐步向前推进。 或许我们可以预先列出我们的脚本，但是我们往往是停留在开发阶段，在需要测试的时候不会真正的去开始测试。基本上，我们是先开发后测试。

　　但是这样做或许不是最好的办法，可能会在今后带来问题。这就是为什么一些开发者提倡一种不同的开发方式，叫做测试驱动开发(TDD)的原因- 就是先测试后开发。

　　你可能会疑惑这样该怎么做，而这正是本文将讨论的。我将带领你们通过一个真实的简单项目去示范TDD如何工作。本文和示例项目都基于Noel Darlow(“McGruff”)在论坛中向另一个论坛成员演示TDD如何工作的讨论。

　　我们的示例项目是一个Biter类，它通过使用正则表达式可以“咬掉”字符串中的片段，就象这样：

　　bite ('/pattern/');?>

　　我们的类也将修改原始的字符串，把匹配的部分去除(所以我们叫它“吞噬者”)。

　　让我们从设置测试框架开始。

　　设置测试框架

　　由于我们从测试出发，我们需要有一些测试框架。我将使用SimpleTest 框架，仅仅因为我最熟悉它。

　　下载一份SimpleTest的拷贝，把它安装在你本机或者你的服务器上。然后创建一个叫做"test_biter.php"的新文件，里面写下面的代码：

　　require_once 'simpletest/unit_tester.php';

　　require_once 'simpletest/reporter.php';

　　class BiterTestCase extends UnitTestCase {

　　function testSetup () {

　　$this->assertTrue(false);

　　}

　　}

　　$test = new BiterTestCase('TDD Biter Test');

　　$test->run(new HtmlReporter());

　　?>

　　让我们分析一下这个例子。首先我们包含了一些SimpleTest框架的文件(你要确认一下路径是否和你的一样)。接着我们建立了一个叫做BiterTestCase的新类，它将用来测试我们的Biter类。象你看到的一样，BiterTestClase类继承于UnitTestCase类，这个意味着BiterTestClass是我们第一个真正意义上的测试用例。

　　BiterTestClass类只有一个方法调用叫做'testSetup'。任何以“test”开头的方法都会被SimpleTest框架自动执行，因此它们应该是被用来测试项目中的某个部分。在上面的例子中，我们通过调用assertTrue()方法来确认框架被正确设置。

　　例子中的后面两行是建立一个测试用例的实例，然后运行所有测试。如果所有设置都正确的话，你会得到下面的输出：

　　现在我们已经设置好了测试框架并正常运行。让我们开始我们的Biter类。

　　第一个测试

　　在我们测试Biter类的任何功能之前，我们必须确认这个类存在。我们当然也是写一个测试来做这件事：

　　require_once 'simpletest/unit_tester.php';

　　require_once 'simpletest/reporter.php';

　　class BiterTestCase extends UnitTestCase {

　　function testClassExists() {

　　$this->assertTrue(class_exists('Biter'), 'Biter class exists');

　　}

　　}

　　$test = new BiterTestCase('TDD Biter Test');

　　$test->run(new HtmlReporter());

　　?>

　　现在运行上面的测试。不要创建类或者包含其他内容;先运行测试。由于'Biter' 类不存在，你会看到下面的输出：

　　如你所见，我们的测试指出'Biter'类不存在。在TDD中，你总是从一个失败的测试开始工作。

　　现在我们必须让测试能够通过，做到这点需要创建Biter类。建立一个叫'biter.php'的新文件，写入如下代码：

　　Class Biter {

　　}

　　?>

　　然后把Biter类包含到我们的测试文件，加入如下行：

　　require_once 'biter.php';

　　现在再运行测试。这次它们会通过了，输出如下：

　　在创建Biter类的时候，我们走出了TDD的第一步。首先我们创建测试，然后再做实际的开发。

　　在目前我们的Biter类还没有任何功能，下面让我们开始我们的Biter类的第一部分：“开始吞噬”。

　　Biter返回正确的匹配吗?

　　我们希望第一步明确的是当我们调用bite()方法的时候Biter类将返回正确的匹配，因此，让我们就此写一个测试：

　　function testBiteReturnsAPatternMatch() {

　　$biter =& new Biter;

　　$haystack = 'foobar';

　　$this->assertEqual(

　　$biter->bite('/foo/', $haystack),

　　'foo',

　　'Biter returns correct match');

　　}

　　这个测试确认biter返回正确的匹配。它使用了assertEqual()方法，从名字我们就能知道这个方法的意思。把测试增加到我们的测试集，然后再运行测试。它会出错甚至返回一个致命错误，因为我们还没提供bite()方法。你会看到下面的输出：#p#分页标题#e#

　　就象我们在前一个测试里面做的一样，让我们设法使这个测试通过。为了达到这点，我们必须提供bite()方法，由于我们的测试定义了bite()方法需要如何工作，我们只需要开发它，不再需要思考它应该怎么样。这个是TDD的另一个核心概念：测试定义了代码行为。

　　下面的bite()方法可以使得测试通过：

　　function bite($needle, $haystack) {

　　if(preg_match($needle, $haystack, $match)) {

　　return $match['0'];

　　}

　　}

　　在你的Biter类增加bite()方法，然后再次运行测试。现在应该通过了，产生了下面的画面：

　　让我们重温一下刚才我们所做的。我们没有立刻建立bite()方法，我们先为此创建了一个测试，在那之后我们再提供bite()方法。这个就是TDD提倡的：先测试，后开发。

　　移除匹配的部分

　　我们现在还没有完全完成，因为我们的Biter类有第二个需求：它需要把匹配的部分从原始的字符串中移除。为此让我们再写一个测试：

　　function testPatternMatchIsRemovedFromHaystack() {

　　$biter =& new Biter;

　　$haystack = 'foobar';

　　$biter->bite('/foo/', $haystack);

　　$this->assertEqual($haystack, 'bar', 'Removed matched part [%s]');

　　}

　　我们还是使用assertEqual()方法去断言两个变量完全相同，只是这次我们是去检查匹配部分是否已经被移除。

　　运行上面的测试，将得到下面的输出：

　　现在我们必须使得这个测试通过。这个做起来很简单，不过假设我们不写这个测试，而是通过修改其他测试来让这个测试通过，这样可能可以少些测试代码。怎么样，听起来不错?其实是错误的!

　　永远不能为了让某一个测试更容易通过而去修改其他的测试!

　　哪些其他的测试可能是为了特定需求的结果创建的。你实际运行的脚本可能会依赖于那些测试所通过的特定函数。如果你开始修改其他的测试，你就会失去TDD的所有优势。这就是为什么你永远不能为了更容易通过某个测试而去修改其他测试的原因。

　　让我们回到我们的Biter类。我们如何能让这个测试通过?我们必须修改传递进来的字符串，就好像我们处理通过引用的方式传递的参数。修改过的bite()方法看上去象下面这样：

　　function bite($needle, &$haystack) {

　　if(preg_match($needle, $haystack, $match)) {

　　$haystack = str_replace($match['0'], '', $haystack);

　　return $match['0'];

　　}

　　}

　　把它放入你的Biter类，然后运行测试。你看到什么?全部都是绿色!

　　现在我们满足了Biter类的所有需求，我们可以开始做我们的脚本里面的其他类，开发起来和我们开发Biter类一样。同时你还能得到另一个好处，就是以后你可以再运行Biter类的测试以便确认它的功能依然正确(这将有效的避免开发过程中偶然的错误修改)。

　　结论

　　本文中我演示了测试驱动开发如何工作。我们只是构造了一个真实的简单的类，它非常容易去使用TDD方法，不过做为介绍还是不错的选择。

　　值得注意的是TDD需要主要焦点的转移，因此它很难推行，它使得开发过程完全不同以往。我可以给出的最好建议是坚持尝试TDD，最终你会迷恋它。一旦习惯了，你再也不会用其他的方法。

　　如果你想了解文中的示例项目或者想得到更多的示例，可以看看SitePoint 论坛的相关讨论。非常感谢Noel Darlow使得本文得以呈现，并且提供了本文的大部分示例和信息。

　　如果你对本文有任何问题和建议，欢迎在PHPit论坛与我们讨论。

　　我在这里列出了十条建议，可以说是戒律。虽然我会用 Subversion 和 .NET 来做示例，但这些戒律和你用的编程语言还有源码管理工具无关。

　　1. 彻底抛弃 VSS!

　　VSS 已死，就让它离去吧。它曾经很有用，但是现在其他 VCS(Version Control System)已经远远超越了它。微软也决定从明年开始不再支持 VSS 了。

　　老实说，在 1995 年，VSS 是一个伟大的工具，但是它的光环早已被它的晚辈，Subversion，Git 和 Mercurial 夺去。

　　2. 没有进入版本库，它就不存在

　　你应该每天把这条念一遍 – “工作进展的唯一标准就是代码进了版本库”。在代码进入版本库之前，它相当于不存在。

　　我承认你的代码藏在你机器的某个角落，但是对于其他人来讲，这有何意义?他们不能拿到你的最新版本，他们不能和你的版本合并，你也不能部署你的代码，一旦你的硬盘坏了，一切将烟消云散。

　　如果你坚持的执行这一条的话，你会发现其他的好习惯会随之而来。你会自觉的把任务分成小块所以你可以经常提交代码。你会更加频繁的更新，集成代码。最重要的是，经常提交代码说明了你正在做东西。

　　3. 尽早提交，尽快提交，经常提交

　　紧接上面一点，防止“幽灵代码”(只在你本地机器上能看到的代码)的唯一的方式就是把代码尽快的提交到版本库。这么做还有以下好处：

　　▲每次提交都会生成一个新的版本，给你回滚的机会。假如你把代码搞乱了，你是希望回滚到一小时前还是一个星期前?

　　▲间隔的时间越长，代码合并越困难。合并代码从来不是一件好玩的事情。当你好几天都不提交代码，你会突然发现，你已经累计了 50 个冲突要解决，你大概会疯掉。

　　当你坚持经常提交代码的习惯以后，你会发现你的工作、代码提交会呈现出一定的规律。这个规律可以用来指导你的开发工作。当你发现你的团队好几天都没有代码提交的时候，你就会意识到 “something is wrong”。

　　4. 在提交前检查你的更改

　　提交代码到版本库看起来太简单了。反正在项目的根目录往下有东西更改了，提交吧!这样会导致你提交了一堆垃圾。很多人看到下面的对话框的时候，往往是选择所有，然后搞定!于是你的代码库就被污染了，例如 debug 文件夹之类的。

　　还有一些情况是人们提交代码前不检查自己到底更改了什么。例如一个项目配置文件，你会记得你改了什么吗?也许这次修改就不应该提交呢?如下图所示，这个 Web.config 文件为什么被修改了?你可以通过 SVN 工具对比来查看更改。对于一些可能被更改但是不需要进入版本库的文件，例如 Thumbs.db，你可以用 SVN 的“ignore”功能来排除它。

　　5. 认真填写“commit messages”

　　填写 commit message(提交注释)是有一点枯燥，但是想象一下别人看你的提交注释的时候是拿着一把斧子，你把他逼疯了他就来砍你!所以不要写“更新了一段代码”这种提交注释，你会把别人逼疯掉。

　　“commit message”的目的解释你提交代码到底修改了什么。你也许不记得你一年前提交的一段代码是为什么，但是 SVN 的注释会让你想起来。

　　所以，请不要写以下这些注释：

　　▲修复了一个 bug

　　▲有一个拼写错误

　　▲更新 1024

　　▲这就是一坨屎

　　▲提交了

　　你还有见过比这个更烂的注释吗?还有，任何一个人的注释应该是不一样的，而且从逻辑上来讲永远不可能一样，因为你每次提交代码的基础一定是不一样的，所以你做的事情不可能一样。

　　6. 你必须自己提交代码，而不是让别人代劳

　　这个听起来有些奇怪。但这种事情确实存在，而且我还遇到过不止一次。有一些团队为了保证代码库的干净，让一个人专门负责审核和提交代码。这并不是一个好习惯。

　　首先，源代码管理并不是为了保持代码的纯净，起码在开发过程中不是这样。它的目的是让团队更频繁的集成各自的工作，当有问题的时候可以回退。在这个过程中，并不需要每一步都很完美。只有在版本发布的时候，我们才需要，或者尝试去达到“干净的代码”。

　　还有，从开发者的角度来看，这么做等于没有源代码管理。因为它意味着没有代码集成，没有回退，没有 blame log，什么都没有。你只是坐在那里写代码，然后在你也无法确定的时间把代码交给你的老板。

　　7. 数据库的版本控制是必须的

　　这是有很多人想做，但是觉得很困难而做不到的一点。这里的问题是，很多应用没有数据库根本无法运行。所以如果你不把数据库加入版本控制的话，你的应用是不完整的。

　　大部分的版本控制系统只针对文件系统工作，例如 HTML，CSS，图片，配置文件等等任何保存在文件系统中的东西。但是对于数据库中的数据却无能为力。

　　不过现在也有一些数据库版本控制工具，例如 Red Gate 出品的 SQL Source Control。关于这个工具我曾经写过很详细的文章 Rocking your SQL Sourc Control world with Red Gate，我在这里就不赘述了。总之，数据库的版本控制也很容易了!#p#分页标题#e#

　　8. 编译出来的文件不应该加入版本控制

　　简单的说，就是任何自动生成的东西都不应该放在版本库里面。以 .NET 为例，所有“bin”，“obj”文件夹下面的东西(.dll，.pdb 等等)都不应该加入版本库。

　　为什么?因为如果这么做了，你团队的其他人会恨死你的。每次他们更新代码都会用你的编译输出来替代他们的编译输出，会导致他们本地的很多东西不能用。另外一个原因是，你完全没有必要把这些编译输出放在版本控制里面，它们只是在浪费服务器的硬盘和带宽。

　　9. 别人不在乎你的个人配置

　　很多时候，人们没有意识到它们正在提交它们自己的个人配置到版本库。开发工具往往会生成一些配置文件，记录你的文件路径，字体设置，快捷键设置等等，这些东西只对你有用。以 .NET 项目为例：

　　10. 依赖项也需要添加到版本库

　　虽然这是最后一条，但也是很重要的。如果你的代码需要依赖第三方的类库或者文件，你需要把这些文件也添加到版本库。你不能认为程序在你的机器可以跑，就在别人的机器上也能跑。你团队的其他成员也许没有这些依赖的文件，他们更新了你的代码以后，会导致项目无法编译或者程序无法运行。

　　我今天还遇到一个这样的问题。我拉下了很久以前的一个项目，然后出现下面的编译错误：

　　这个项目也是我开发的，以前的工作环境总是有 NUnit 的，但是现在没有了，所以出现了这些错误。

　　总结

　　这十条的每一条都很简单，老实说都是很基础的东西：及时，尽早的提交代码，充分了解你提交的东西，并确认它们确实需要被提交到代码库，解释你的提交，自己提交自己的代码，不要忘记数据库版本控制，不要忘记依赖项。但请你忘记 VSS ：)

　　我会以系列文章的形式跟踪记录我现在正在做的一个完整运用Scrum管理项目的笔记，里面会有一些经验教训总结心得，以便读者与我互相学习勉励。有写的不对的或者写的不好的地方还请海涵，当然我更希望大家多多提宝贵意见，读者的支持是我最大的动力。

　　======================================================================================================================================

　　正文：

　　大家好久不见。上次说过我要继续分享Iteration Review Meeting的一点实践。从项目运行到现在我们已经开过两次Iteration Review Meeting会议，因为我们的Iteration周期比较短(一周)，所以我们采取Iteration Review和Iteration Planning两个Meeting连续开。

　　通过两次Iteration Review会议，我们吸取第一次Iteration Review的问题，在第二次Iteration Review做了很多的改进，首先在准备上我们更加的从容，我们在Iteration Review之前我们就把我们做的软件打包发布可在本机运行的版本。那么在会议上就可以马上进入Demo环节，避免浪费大家的时间。第二个改进，我们在回顾上一个Iteration我们那些做的好，那些做的不好，那些需要改进的环节，我们不再由我一个一个的点人来回答。而是用事先准备好的小字条，让大家把自己的想法写下来，每人至少要写一条好的方面，一条不好的方面。写完之后每个人依次上台来向大家分享，并且要求就每一条分享举出在上一个Iteration中的实际事例出来，这样的分享更有价值。我觉得效果非常的好。最后我会就好的方面做一个总结，让大家在下一个Iteration对好的方面继续发扬。不好的方面，我选出了其中最重要的2-3条做了一下分析，大家一起讨论提出了一些可行的解决方案，并且我要求他们在下一个Iteration进行改进。整个Iteration Review持续了2个小时，我觉得这次的效果非常的好，达到了我们预期想要的结果，给下一个Iteration建立的良好的信心和鼓舞。

　　我自己的一点点感受，我觉得不要把会议流于形式，而要真正发挥其作用，那么才有意义。不让就是浪费所有参会人员的时间，那是一件非常可怕的事情。

　　我会以系列文章的形式跟踪记录我现在正在做的一个完整运用Scrum管理项目的笔记，里面会有一些经验教训总结心得，以便读者与我互相学习勉励。有写的不对的或者写的不好的地方还请海涵，当然我更希望大家多多提宝贵意见，读者的支持是我最大的动力。

　　======================================================================================================================================

　　正文：

　　其实上一篇我有讲过一些项目初期我做过的一些工作，还有公司运用敏捷的方法。只不过到这里我才有写一个系列文章的想法。这里我还是啰嗦几句，上篇我们谈到了，我们公司真正做敏捷其实是在称之为Iteration 0(或者叫Iteration Prepare)之后，也就是我们已经有了很充足的准备，可以开足马力实施项目的时候了。其实这样做也是为了降低风险，一来我们在前期不用投入很多人力，只是投入几个金兵强将，做好构架以及在这之上完成一个Demo。然后后面的Iteration就有了参照，就可以理解大家都在做Iteration 0的复制即可。有点想开连锁店的感觉。这种方法很适合项目外包型的公司，前提投入牛人，后期在随时调入/调出不用很强也不用很固定的人力。外包公司的人力调配可是一门艺术，这里我就不多说了。

　　好，开始说项目吧，目前我的项目正在做第一个Iteration，也就是Iteration 1，前几天开过Iteration 1 Planning Meeting，个人认为非常的失败，在这几天的运行来看也确实非常糟糕，问题主要表现为，我们在Planning Meeting上面没有完全按照要求把Story分解为2-16小时的Task。或者说我们根本就没有分解。而是把完整的Stroy估算成为时间。基本上都是5天3天这样的时间。可能大家都认为一开始我们拿到的Story都非常的简单，轻视了。所以在后面的几天力，我可以说完全无法跟踪项目进展，Iteration都快要结束了，可是一个Story都还未完成，也不知道Story完成了百分之几。所以这是我在下一个Iteration首要要解决的问题。

　　还有一个很大的问题就是每日晨会的时候大家都只是说了昨天做了什么，今天要做什么，可是从来都没有人说问题，我也不知道这是好事还是坏事，我总感觉项目初期应该大家都有很多问题才对。我不知该如何引导，希望后期会有所改进。

　　目前项目还出现了一个风险，前期投入的一个人，现在临时变更了，突然替换了一人，我没有料到会这么快换人，我还未很好的考虑换人如何应对，如何能让他快速的融入到我们的团队中来。我在想是否应该整理一个项目快速入门手册，方面后面如果再有新人加入时，能快速掌握目前开发进度。

　　还有一点，也是作为项目经理的我最失败的一点。关于User Story的编写问题。因为初次尝试，写User Story的时候我只知道按照需求的方式把User Story照搬了一遍，但是这样给开发带来了不小的麻烦。首先一下子开发无法转变关联，一大堆大大小小的Story丢给开发，他们都不知道如何下手了。毕竟开发习惯了功能性的需求。不习惯完全业务的Story描述。后来我查阅一些文章才发现其实User Story也可以和MVC结合，按照大小一致的粒度去编写。分为数据(史诗级User Story)和操作(一般User Story)这样更便于与开发的沟通和理解。

　　还有一个问题，就是项目初期大家对敏捷的认识也不够。都是初试敏捷，我对这方面也没有系统的培训，而只是在项目进行中做了一些宣导，我觉得还很不够，所以我准备过两个Iteration专门对敏捷召开一次座谈会，大家一起讨论运行几个Iteration之后的心得，与大家一起分享，一起学习，如果效果不错的话，我准备每隔一个月就召开一次。当然如果是下一个项目我一定会项目开始之前就做这方面的引导培训。

　　OK，今天就到这，下个礼拜我们会召开Iteration Review会议，希望我们能总结出来更多的东西与大家分享。谢谢阅读

　　“我们的单元测试用例要半个小时才能跑完，”他说。

　　“你们这不是在做驱动测试开发，”我说。“为了让测试发挥效能，所有的测试必须在几秒钟内能跑完，否则的话，程序员不得不频繁的停下来等待测试。”

　　“可是怎样才能让它们快起来?”他问，“光连接数据库就需要30秒”

　　于是，我想他展示了一种叫做依赖注入的技术，它能让你使用一个伪造对象来模拟数据库。“你并不需要测试你数据库，”我说。“记住，测试应该是测试那些不受控制的东西，对于测试所依赖的东西，你应该使用模拟工具使它们处于控制之中。”

　　他们遇到的另外一个问题—我最近也是听到了很多次—是他们的测试程序不但没起到好的作用，反而成了一个负担。“我们三天两头的要重构程序，关联的就需要重构测试程序”，这样的话从客户那里可以经常听到。

　　这种问题是他们把TDD想成了QA。TDD不是QA。QA是来保证程序能正确的运行的。TDD是使用断言(assertion)来表现系统的关键特征。在QA里，我们用尽可能多的方法来测试系统中可能会出错的地方。在TDD里，我们用应尽可能少的测试来表现系统的关键特征。

　　我遇到的大多数开发人员都很重视代码质量，努力写出高质量的代码，程序看起来很整洁。但测试用程序也是程序，经常的我能看到测试程序就写的不是那么好。

　　例如，一些程序员会很认真的把产品程序里的冗余部分清理干净，但在测试程序中却留下大量的无用的代码。任何冗余都不是好事，冗余的测试也是如此，如果程序有变化，冗余的测试会花掉你额外的时间去重构。

　　当系统出问题时，测试程序就体现出来了它最大的价值，至少对我来说是最欣慰的时候。然而，对于系统，任何一个改动只应会让一个测试失败。换句话说，没有任何两个测试的失败原因是相同的。这说起来容易做起来难，但如果你尊重这个原则，你将会发现，当你重构代码时，重构测试程序是会容易多了。

　　目前就说这些问题。总之，测试也是程序，它们也要保持高质量。系统中的每个关键特征都用一个测试来表现，没有第二个测试会因为这同一个问题而失败。

　　你怎么看待这些问题?我很想听听你的想法和建议。不要犹豫，请在评论里分享你的观点。

　　我会以系列文章的形式跟踪记录我现在正在做的一个完整运用Scrum管理项目的笔记，里面会有一些经验教训总结心得，以便读者与我互相学习勉励。有写的不对的或者写的不好的地方还请海涵，当然我更希望大家多多提宝贵意见，读者的支持是我最大的动力。

　　======================================================================================================================================

　　正文：

　　大家好久不见。上次说过我要继续分享Iteration Review Meeting的一点实践。从项目运行到现在我们已经开过两次Iteration Review Meeting会议，因为我们的Iteration周期比较短(一周)，所以我们采取Iteration Review和Iteration Planning两个Meeting连续开。

　　通过两次Iteration Review会议，我们吸取第一次Iteration Review的问题，在第二次Iteration Review做了很多的改进，首先在准备上我们更加的从容，我们在Iteration Review之前我们就把我们做的软件打包发布可在本机运行的版本。那么在会议上就可以马上进入Demo环节，避免浪费大家的时间。第二个改进，我们在回顾上一个Iteration我们那些做的好，那些做的不好，那些需要改进的环节，我们不再由我一个一个的点人来回答。而是用事先准备好的小字条，让大家把自己的想法写下来，每人至少要写一条好的方面，一条不好的方面。写完之后每个人依次上台来向大家分享，并且要求就每一条分享举出在上一个Iteration中的实际事例出来，这样的分享更有价值。我觉得效果非常的好。最后我会就好的方面做一个总结，让大家在下一个Iteration对好的方面继续发扬。不好的方面，我选出了其中最重要的2-3条做了一下分析，大家一起讨论提出了一些可行的解决方案，并且我要求他们在下一个Iteration进行改进。整个Iteration Review持续了2个小时，我觉得这次的效果非常的好，达到了我们预期想要的结果，给下一个Iteration建立的良好的信心和鼓舞。

　　我自己的一点点感受，我觉得不要把会议流于形式，而要真正发挥其作用，那么才有意义。不让就是浪费所有参会人员的时间，那是一件非常可怕的事情。

　　谢谢大家用眼收看。

　　我会以系列文章的形式跟踪记录我现在正在做的一个完整运用Scrum管理项目的笔记，里面会有一些经验教训总结心得，以便读者与我互相学习勉励。有写的不对的或者写的不好的地方还请海涵，当然我更希望大家多多提宝贵意见，读者的支持是我最大的动力。

　　======================================================================================================================================

　　正文：

　　其实上一篇我有讲过一些项目初期我做过的一些工作，还有公司运用敏捷的方法。只不过到这里我才有写一个系列文章的想法。这里我还是啰嗦几句，上篇我们谈到了，我们公司真正做敏捷其实是在称之为Iteration 0(或者叫Iteration Prepare)之后，也就是我们已经有了很充足的准备，可以开足马力实施项目的时候了。其实这样做也是为了降低风险，一来我们在前期不用投入很多人力，只是投入几个金兵强将，做好构架以及在这之上完成一个Demo。然后后面的Iteration就有了参照，就可以理解大家都在做Iteration 0的复制即可。有点想开连锁店的感觉。这种方法很适合项目外包型的公司，前提投入牛人，后期在随时调入/调出不用很强也不用很固定的人力。外包公司的人力调配可是一门艺术，这里我就不多说了。

　　好，开始说项目吧，目前我的项目正在做第一个Iteration，也就是Iteration 1，前几天开过Iteration 1 Planning Meeting，个人认为非常的失败，在这几天的运行来看也确实非常糟糕，问题主要表现为，我们在Planning Meeting上面没有完全按照要求把Story分解为2-16小时的Task。或者说我们根本就没有分解。而是把完整的Stroy估算成为时间。基本上都是5天3天这样的时间。可能大家都认为一开始我们拿到的Story都非常的简单，轻视了。所以在后面的几天力，我可以说完全无法跟踪项目进展，Iteration都快要结束了，可是一个Story都还未完成，也不知道Story完成了百分之几。所以这是我在下一个Iteration首要要解决的问题。

　　还有一个很大的问题就是每日晨会的时候大家都只是说了昨天做了什么，今天要做什么，可是从来都没有人说问题，我也不知道这是好事还是坏事，我总感觉项目初期应该大家都有很多问题才对。我不知该如何引导，希望后期会有所改进。

　　目前项目还出现了一个风险，前期投入的一个人，现在临时变更了，突然替换了一人，我没有料到会这么快换人，我还未很好的考虑换人如何应对，如何能让他快速的融入到我们的团队中来。我在想是否应该整理一个项目快速入门手册，方面后面如果再有新人加入时，能快速掌握目前开发进度。

　　还有一点，也是作为项目经理的我最失败的一点。关于User Story的编写问题。因为初次尝试，写User Story的时候我只知道按照需求的方式把User Story照搬了一遍，但是这样给开发带来了不小的麻烦。首先一下子开发无法转变关联，一大堆大大小小的Story丢给开发，他们都不知道如何下手了。毕竟开发习惯了功能性的需求。不习惯完全业务的Story描述。后来我查阅一些文章才发现其实User Story也可以和MVC结合，按照大小一致的粒度去编写。分为数据(史诗级User Story)和操作(一般User Story)这样更便于与开发的沟通和理解。

　　还有一个问题，就是项目初期大家对敏捷的认识也不够。都是初试敏捷，我对这方面也没有系统的培训，而只是在项目进行中做了一些宣导，我觉得还很不够，所以我准备过两个Iteration专门对敏捷召开一次座谈会，大家一起讨论运行几个Iteration之后的心得，与大家一起分享，一起学习，如果效果不错的话，我准备每隔一个月就召开一次。当然如果是下一个项目我一定会项目开始之前就做这方面的引导培训。

　　OK，今天就到这，下个礼拜我们会召开Iteration Review会议，希望我们能总结出来更多的东西与大家分享。谢谢阅读

　　所以，在敏捷开发里一直都有一种说法叫“代码即文档”，而且测试代码也成了功能代码的使用文档。敏捷里强调的TDD(Test-driven developmenet, 测试驱动开发)，就主要体现了这种思想：根据设计编写测试-> 实现设计的功能 -> 用测试代码验证 -> 重构实现代码 -> 改善设计 -> 再次回到根据改善的设计编写测试。反复循环下去，就是TDD所倡导的流程。

　　TDD的好处：1. 能驱使系统最终的实现代码，都可以被测试代码所覆盖到，也即“每一行代码都可测”。2. 测试代码作为实现代码的正确导向，最终演变为正确系统的行为，能让整个开发过程更加高效。TDD的不足之处或者说还不够完善的地方，是对设计和测试的编写没有一个明确的方针。作为整个循环中的向导部分，如何保证根据设计编写的测试就是最终用户所期望的系统行为?如果这一部分模糊了，那么后续所有环节几乎都要受到影响。所以，再次基础上，敏捷社区又有人提出了BDD的概念，即“行为驱动开发”。

　　BDD(Behavior-driven development)把TDD中模糊的那一部分给明确了，强调开发、测试、BA、客户等所有项目相关人员都用自然语言来描述系统的行为。大家看到的描述一致，读到的内容一致，于是最终测试驱动开发产出的结果也应该是最符合用户期望的。所以在BDD的倡导下，介绍了一种简洁的类似自然语言叫Gherkin Language。下面看一个用Gherkin Language描述系统行为的例子：

　　[plain] view plaincopyprint?

　　As a xxx [Role]

　　I want to xxx [Feature]

　　So that I can xxx[Benefit]

　　Scenario 1: create user

　　Given a admin log into the system

　　when he create a user with name 'mike'

　　then mike should be able to log into the system

　　As a xxx [Role]

　　I want to xxx [Feature]

　　So that I can xxx[Benefit]

　　Scenario 1: create user

　　Given a admin log into the system

　　when he create a user with name 'mike'

　　then mike should be able to log into the system

　　随着BDD的出现和发展，使用大家都能轻易理解和认知的语言来描述系统的行为并创建User Story，TDD的反复循环的流程也就能更顺利的进行下去了。BDD的核心价值是体现在正确的对系统行为进行设计，所以它并非一种行之有效的测试方法。它强调的是系统最终的实现与用户期望的行为是一致的、验证代码实现是否符合设计目标。但是它本身并不强调对系统功能、性能以及边界值等的健全性做保证，无法像完整的测试一样发现系统的各种问题。

　　有种说法是BDD是TDD的进化，其实笔者看来，没有孰优孰劣，它们的本质和目标都是一致的。只是在实施方法上，进行了不同的探讨来完善整个敏捷开发的体系。如果BDD书写的User Story或者叫测试用例，不能作为开发、测试和客户等人共同参与和看到的一致性内容的话，那么它的价值也几乎得不到体现。另外一点，由于BDD不能代替完整的测试，旨在描述系统的行为，所以就像Gherkin Language的例子所体现的那样，关键是“简洁”，切忌啰嗦的想把每一步操作和任何情况都说得很清楚。

　　最后总结：TDD的迭代反复验证是敏捷开发的保障，但没有明确如何根据设计产生测试，并保障测试用例的质量，而BDD倡导大家都用简洁的自然语言描述系统行为的理念，恰好弥补了测试用例(即系统行为)的准确性。(不管以上理念是否先进，切忌盲从和滥用)

　　1、如何开始项目管理(如何入门)

　　实践练习：

　　找出自己在项目管理、人员管理和团队领导力中的短板，并想办法进行提高;找到一些经验丰富的项目经理们作为你学习的楷模，并尝试运用它们的优点;从你过去的一些上司、领导处总结哪些行为和特点是你无法忍受的，然后再你自己的管理工作中去规避这些做法。

　　2 如何知道项目已经完成(必须要定义一些完成的准则)何以知道已经完成?

　　当产品已经足够好的情况下，可以确认是否已经完成。

　　“足够好”：是指产品已经具备一些可接受的综合属性，如功能、质量、时效性、客户价值、竞争力以及支撑的基础设施已经准备就绪。

　　客户对质量的看法主要取决于可靠性(持续运行无故障)和性能(操作的响应时间)

　　内部对质量的看法主要设计如下方面：软件在未来的可修改性、可维护性、文档的可理解性等

　　如何定义产品发布准则?

　　发布准则必须要与成功准则相对应，没有放四海而皆准的发布准则，要确保项目取得最终的成功，反映产品能够上线发布的指标都必须要有一定的可信度和可测度。

　　如果指定了不符合项目业务目标的宽松的发布准则，可能会造成一种一定会可能会取得成功的假象。

　　一些宽松的发布准则：广泛的客户群体曝光率，“很高的客户满意度”

　　某些模棱两可的措辞：可接受的、足够的、恰当的、广泛的、精确地、高的、改进的、低的、合理的、健壮的、准确无误的和有效率的。这些措辞要尽量避免使用。

　　发布准则必须要满足：

　　Specific【明确的(不是空泛的)】

　　Measurable【可度量的(不是定性的或主观的)】

　　Attainable【可实现的(不是一对不可能实现的目标)】

　　Relevant【相关的(与客户要求和业务目标相关联)】

　　Trackable【可跟踪的(在整个项目过程中可以进行监控)】

　　制定准则时：

　　认真考虑不同项目干系人对团体的想法和意见，避免冲突和分歧

　　考虑用户提出的验收标准

　　于关键用户代表进行充分沟通

　　出现冲突时，全体团队成员必须要工作在共同的目标集合上，并做出适当的折中判断。

　　可能的发布准则项：

　　1)缺陷

　　质量是一系列复杂和多维度的产品特点的集合。发布一个不成熟且存在很多缺陷的产品会导致很高的运行成本、用户的失望、很差的产品评价、过高的维护成本、产品退货甚至法律纠纷。作为质量的指标之一，可以对开发和测试中发现的缺陷的数量和类型进行跟踪。

　　如果质量是项目的一个成功准则，可以参考如下与缺陷相关的发布准则：

　　在一个四级的缺陷跟踪系统中，不存在未解决的最严重的1级或2级缺陷。在过去的X周内，未解决的缺陷数量持续下降，同时估算的遗留缺陷数量是可以接受的(可以采用缺陷模型来进行预测)

　　在编译器中、源码分析与运行时分析中所报告的所有错误和警告都得到了修正。

　　前一发布版本出现的问题都已经得到了修正，在修复过程中也没有引入额外的缺陷。

　　2)测试

　　大多数软件团队都非常依赖不同类型的测试来发现缺陷，可以通过查看估算的未发现缺陷数量是否处在可接受范围内，或者在预设的测试时间内并没有发现新的缺陷时是否决定停止测试，一些主要的发布准则如下：

　　代码编译、构建和冒烟测试是否在所有平台上通过;

　　综合测试和系统测试100%通过

　　特定的功能通过了所有的系统和用户验收测试(如正常流程和相关的异常处理流程在普遍的用例中测试通过)

　　测试计划中涵盖的所有记录在案的功能需求的测试用例都得到了执行

　　达到了预先设定的代码或需求(如功能需求、测试用例流程或者产品属性)

　　综合考虑测试和缺陷相关的因素，一位学者认提出的产品发布准则：

　　完成了覆盖100%功能点和80%的回归测试

　　不存在严重等级1和等级2的缺陷;

　　已知的遗留缺陷密度少于每千行代码0.5个缺陷;

　　每1000小时的测试工作发现新缺陷的数量少于40个

　　发现缺陷的平均间隔时间少于100小时

　　完成了压力测试、配置测试、安装测试、本地化测试、可用性测试和傻瓜用户测试。

　　3)质量属性

　　质量属性是另一只哦能够用于描述产品行为的思维方式，这些属性包括可靠性、安全性、完整性、可用性、便携性、可维护性、高效性、健壮性和交互型等。一些相关的准则是：

　　在所有的平台上的定量性能目标得到满足

　　可靠性目标得到满足

　　相关公司的安全策略和需求得到了满足

　　特定的条件已经符合，可以使得产品通过必要的评审或者审计

　　4) 功能

　　在即将发布的产品版本上，所有的承诺的高优先级需求已经实现并能正常工作

　　满足特定客户的验收的标准

　　满足所有非健全人士的可访问性需求

　　如果需要软件在不同语言环境下运行，所有本地化与全球化测试都能通过

　　满足特定法规、合约、标准规范和监管目标

　　所有的功能需求都可以通过测试用例进行追踪

　　5) 配置管理

　　产品可以在所有目标平台上重复构建

　　物理配置审计确认现有的所有组件都是正确的版本

　　产品在所有的目标平台上都能成功安装

　　发布的介质和镜像文件经过了反病毒和恶意软件扫描

　　6)支持

　　这里主要指确保产品顺利安装和实施的其他关键要素。

　　发布说明已经准备完毕，包含新版本中的已修复的缺陷信息、增加的功能和删除的功能

　　受影响的项目干系人均了解软件发布和支持流程

　　已知的未修复缺陷全部记录在项目的缺陷跟踪系统中

　　支持部门已经做好了接受和回应客户问题报告的准备

　　执行软件的运行环境所需的各种基础设备已经到位#p#分页标题#e#

　　软件的生产和下发已经做好了接收产品的准备。

　　1. 文中上来开宗明义，将Scrum定位成为一个框架，需要补充其他实践才能应用，这个我一直赞同，只是因为看到许多人还有混淆，在此再啰嗦一下。原文如下：“Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques.”

　　2. 在下面，Guide中明确了Scrum框架当中的内容，“The Scrum framework consists of a set of Scrum Teams and their associated roles; Time-Boxes, Artifacts, and Rules.”，好，下面就仔细看一看内容吧

　　3. 首先看角色，“Each Scrum Team has three roles: 1) the ScrumMaster, who is responsible for ensuring the process is understood and followed; 2) the Product Owner, who is responsible for maximizing the value of the work that the Scrum Team does; and 3) the Team, which does the work. The Team consists ofdevelopers with all the skills to turn the Product Owner’s requirements into a potentially releasable piece of the product by the end of the Sprint.” 这里有几个事情要解读一下，

　　a) Developers，在Release Notes里面，作者给出了解释” The team of people performing the work of creating an Increment is the Development Team. Regardless of the work performed by individual team members, they are known as Developers.” 所以，只要参与了交付的人，都被称为了Developers，包括开发，测试，用户体验，文档等等

　　b) 另外，需要注意的是角色里面是没有Manager或者Lead，团队是自组织的，有关自组织的论述，Guide中有如下几段：

　　i. The ScrumMaster helps the Scrum Team understand and use self-organization and cross-functionality. Teams are also self-organizing.

　　ii. No one – not even the ScrumMaster - tells the Team how to turn Product Backlog into increments of shippable functionality.

　　iii. The Team self-organizes to undertake the work in the Sprint Backlog, either during the Sprint Planning meeting or just-in-time during the Sprint.

　　c) 由于Scrum框架里面没有给Manager和Lead留出位置，在Scrum框架落地过程中，就经常会走形了。Manager和Lead伪装成了Scrum Master，然后一切照旧，而真正该做Scrum Master的人反而没有位置了。这是因为，由于团队都很年轻，并不敢真正实施自组织，又想时髦地实施Scrum于是就照猫画虎了。其实，管理人是最难的一件事情，自组织只是一种可能的管理方式，而这种管理方式恰恰是在中国很难成功的管理方式。这就是为什么纯粹Scrum在中国很难落地的原因之一。

　　其实，在敏捷的另一个流派-精益(Lean)当中，就非常强调Manager发挥好Coach的作用，并且将此作为Lean的基础，我觉得这种思维很可能更适合中国的现状，因为大多数团队中的成员都非常年轻缺乏经验，因此，他们需要的很可能并不是自组织，而是真正能Coach他们的Manager或者Lead(在大多数情况下)。即使现在Manager和Lead 还不称职，那么企业的重点也更可能应该是尽快提升这些Manager和Lead的Coach能力，转变他们的思想，而并不是去推行自组织。

　　另外，最近在微博上的讨论中，大家往往将信任和自组织画上等号，其实，有Manger、Lead并不代表不信任，这种非黑即白的看法是错误的。

　　综上所述，在团队实施敏捷的过程中，要根据自己企业的自身能力和实际特点，灵活的改造相关实践，组合不同相关实践，升班硬套Scrum是没有出路的。

　　未来打算就Scrum难于落地的问题准备写一个系列，目前想到的题目如下：

　　2. Scrum与QA

　　3. Scrum与架构

　　4. Scrum与迭代规划，用户故事

　　5. Scrum的商业运作分析

　　(第一部分发布后，有人表示不喜欢这种中英文混杂的方式，个人认为这种方式最有助于大家了解到原汁原味的Scrum， 因此，我会坚持用这种方式，不喜欢的同学请绕过吧)

　　Scrum难于在中国落地的另一个原因是对架构的忽视。下面看看Scrum当中的活动，“The Time-Boxes in Scrum are the Release Planning Meeting, the Sprint, the Sprint Planning Meeting, the Sprint Review, theSprint Retrospective, and the Daily Scrum.”

　　Release Planning meeting的目的是“to establish a plan and goals that the Scrum Teams and the rest of the organizations can understand and communicate.” 基本上这个是一个目标计划会，与架构设计无关。而在每个Sprint的Planning Meeting上，会有两个部分，第一部份澄清需求，第二部分进行设计，但时间太短，往往无法承载架构设计。

　　严格的照搬Scrum框架，在一些大量应用现成框架的产品开发过程中，或在一个产品的维护阶段，还可能成功。但是，对于大型复杂产品开发而言，不进行架构设计，结果基本上是灾难性的。

　　目前，中国的现实情况基本上是设计，架构设计太少，而不是太多，而Scrum更助长了这种轻视设计的风气。当然，强调架构设计并不一定意味要写很厚的架构设计文档，或者进行复杂的UML建模，如何进行架构设计，做到什么程度，应有团队自己决定。

　　综上所述，建议团队在实施Scrum的过程中，在Release Planning Meeting之后，增加一个Release Architecture Design Workshop来进行架构设计，当然，这个Workshop和Release Planning Meeting一样，也是可选的。

　　在改造之前，同时也需要了解哪些框架是Scrum的本质，因为如果修改了这些本质内容，那么就不是改良Scrum，而是推翻Scrum了，这就好像装修不能打掉承重墙一样。Scrum 的三个支柱是透明，审视和适应。透明强调团队之间通过透明来加强新人，应对变化;审视和适应是指在过程中，通过不断审视来不断进行适应性改善 。好了，找到了承重墙，避开它们，然后就开始干吧!

　　角色定义 – Manager/Lead

　　首先，我们来看一下角色定义，Scrum当中设定了三种角色：Product Owner，Scrum Master和Team。Team当中由参与交付的Developers, Testers等角色组成，注意这里是没有给Manager和Lead留出位置，Scrum框架当中隐含了团队应该是自管理的要求。这其实和欧美的实际情况有关，在那里你能看到大把的白头发程序员，而在国内，则非常稀少。

　　而在中国，在我帮客户实施敏捷的过程中，发现在许多组织中由于研发团队都很年轻，并不敢真正实施自组织，而Manager或Lead又没有了位置，于是纷纷伪装成了Scrum Master，然后一切照旧，而真正该做Scrum Master的人反而没有位置了。这造成了许多Scrum实施的失败。其实，管理人是最难的一件事情，自组织只是一种可能的管理方式，而这种管理方式恰恰是在中国现在的软件企业里很难成功的管理方式。因此，我认为，应该改良Scrum框架剥离自组织管理方式，而去强调Manager as Coach.。

　　“Manager as Coach.”这一思想可以在敏捷的另一个流派-精益(Lean)当中找到而且是Lean的基础，我觉得这种思维很可能更适合中国的现状，因为大多数团队中的成员都非常年轻缺乏经验，因此，他们需要的很可能并不是自组织，而是真正能Coach他们的Manager或者Lead。即使现在Manager和Lead 还不称职，那么企业的重点也更可能应该是尽快提升这些Manager和Lead的Coach能力，转变他们的思想，而并不是去推行自组织。

　　还有一点需要注意，这里说的Manager/Lead，不是只哪些只管人不干活的，Lean的思想建议，Manager/Lead必须是有动手能力的领域专家，这样才能真正能做到Coach一线研发人员，否则就只能纸上谈兵了。另外，最近在微博上的讨论中，大家往往将信任和自组织画上等号，其实，有Manger、Lead并不代表不信任，这种非黑即白的看法是错误的。

　　综上所述，我建议，团队在应用Scrum框架时，如果认为应该采用Manager as Coach这种管理方式，那么就应该在Scrum框架的角色定义当中，明确加入Manager/Lead这个角色，也可以修改团队(Team)的定义，将Manager/Lead也作为团队的一部分。

　　活动 - Time Box

　　Scrum框架的另一个大问题是对架构的忽视，而在中国，现在最大的问题不是过度设计，而是设计不充分。而Scrum更助长了这种轻视设计的风气。当然，强调架构设计并不一定意味要写很厚的架构设计文档，或者进行复杂的UML建模，如何进行架构设计，做到什么程度，应有团队自己决定。下面就看一下应该如何改进Scrum框架：

　　Scrum框架当中的活动有几个：Release Planning Meeting, the Sprint, the Sprint Planning Meeting, theSprint Review, the Sprint Retrospective, and the Daily Scrum.”

　　Release Planning meeting基本上是一个目标计划会，与架构设计无关。而在每个Sprint的Planning Meeting上，会有两个部分，第一部份澄清需求，第二部分进行设计，但时间太短，往往无法承载架构设计。

　　因此，严格的照搬Scrum框架，在一些大量应用现成框架的产品开发过程中，或在一个产品的维护阶段，还可能成功。但是，对于大型复杂产品开发而言，不进行架构设计，结果基本上是灾难性的。

　　综上所述，建议团队在实施Scrum的过程中，在Release Planning Meeting之后，增加一个Release Architecture Design Workshop来进行架构设计，时间长度和Release Planning Meeting一样，当然，这个Workshop和Release Planning Meeting一样，也是可选的。

　　交付物 - Artifacts

　　Scrum框架中的交付物有四个：Product Backlog, the Release Burndown, the Sprint Backlog,和 the Sprint Burndown. Product Baclog比较简单，就是所有需要做的事情。这里特意没有明确Product Backlog Item是以什么方式定义的，以便可以集成这方面不同的实践(如用户故事，用例，FDD等)。

　　而在Spring Backlog的内容方面则有些问题，不太一致，细节就不在这里展开了，具体大家可以去看我的博客。我赞同最后在Release Notes当中的提法，Scrum Backlog就是由本迭代希望完成的Product Backlog Item组成，这些Item可以进一步拆分成任务来追踪。

　　改良总结

　　综上所述，可以将改良之后的Scrum框架总结在一张图里面，如下：

　　实施Scrum应保的态度

　　看到这里，我想读者对Scrum框架应该有一个初步的了解。在正式实施Scrum框架之前，首先需要看透Scrum框架的商业本质，对它抱一个正确的态度。

　　Scrum框架其实可以被理解成是敏捷的商标，就象一个果农要卖苹果，卖一个两个那就卖了，但是如果要卖的多，那就需要有一个商标了。Scrum框架也是一样，许多敏捷大师都有自己的敏捷理念，很难统一，于是，大家选定了这个形而上，空空的Scrum框架作为大家共同的商标，这样哪个大师也不会反对。

　　所以，你去上一节Scrum Master的培训，你得到了什么，一个证书，对Scrum框架的基本了解和许多许多培训师自己的敏捷实践经验。因此，能不能值回票价完全取决于培训师的个人能力而已，而那张证书可以肯定一定不证明你就是一个合格的Scrum Master了。

　　因此，在实施Scrum时，不要抱着过高的期望，不要期冀银弹，而要抱着务实、开放、轻松的态度，根据企业的实际情况定制或扩展Scrum框架#p#分页标题#e#

　　如何在中国成功实施改良Scrum框架

　　改良Scrum框架根据中国的实际情况已经强化了管理者的作用，强化了架构的作用，但是在中国实施改良Scrum框架还是会经常遇到一些阻碍，针对这些障碍，则必须克服才能取得成功：

　　1. 职能性组织、模块组织：由于实施CMMI的影响、团队年轻、人员流动等各种原因，许多企业都慢慢转向用职能性组织(如开发部，测试部，架构设计部，需求分析部，或者，如前端开发组，应用服务器组等等)，实施改良Scrum框架，可以暂不改变现有的职能性管理架构，但必须要求Scrum团队的成员是跨职能、跨模块的，而且是在一起办公的，这个要求不可妥协。

　　2. 客户的参与信任关系的建立：在国内，有时客户不太愿意参与到Scrum过程中，参与了有时还不太适应他们手中排优先级的权利，这个可以慢慢培养，但是，必须要求客户和开发团队一起办公，共同参与Scrum过程，这样才能逐步建立起互信的关系。这在软件开发当中非常重要，因为，所有估算方式都只是一种拍脑袋的方式而已，只有让和客户建立起较强的互信关系，才能共同面对不断变化的开发交付过程，而没有比一起办公更透明的方式了。

　　3. 变革之心与QA的正确作用：在国内，交付压力都非常大，要求团队既能交付又要不断思考可以如何优化、变革是一个非常高的要求。我认为，这里应该正确发挥QA人员的作用，QA需要放弃那种只是简单比对流程要求，不符合就开NC(Non-Compliance)的粗暴做法，而真正做到参与到Scrum流程当中，冷静旁观，不断挑战现状、发现问题、和团队一起探索解决方案。因此，在我心目中，好的QA其实是Scrum Master的理想人选，有了变革的驱动者，每个迭代的回归会议才可能真正落到实处。

　　4. 增量交付价值：在国内，看到许多号称做Scrum的团队每个Sprint都在交付功能点，但是这些功能点并不能真正运行，这其实是伪Scrum，很可能还不如不迭代。因此，做好Scrum，就必须坚持不断交付客户可见的业务价值。也就是说，交付的代码必须是可执行，可以给客户演示的。对于复杂系统而言，这对划分Backlog Item提出了很高的要求，但是，是可以解决的，本文就不在这里展开了，未来再写文章详细解释吧!

　　5. 测试的全程参与：以前看到另一种伪Scrum，号称开发在前，测试之后一个Sprint。这种做法其实完全破坏了Scrum团队，开发测试无法形成合力。因此，必须坚持A-TDD和验收测试自动化，这又是一个很大的话题。

　　因此，大家可以看到，Scrum虽然简单，但是这正做好Scrum需要在组织上，人力上，技术上有许多的储备才行，所谓功夫棋外呀!最好，愿大家掌握改良Scrum匡计的精髓，灵活应用，在实际工作取得好的效果!

　　接受了这样的事实以后，你必须小心的是学习如何管理这种不确定性—这种不确定性，是你必须接受它，才能够将它处理得最好。你不妨从重新定义项目管理入手。

　　“项目管理是一门领导人们在不确定的条件下实现目标的艺术。”

　　注意，项目管理是“艺术”，而不是“科学”。处理不确定性没有教条，也没有捷径。但是，和其他艺术一样，你可以运用原则于项目管理上，也可以从专家身上学习项目管理。

　　体育教练在每一场比赛中处理不确定性的经验，都是项目经理学习有效管理项目的绝佳榜样。鉴于这一点，作为项目经理的你，可以看看体育教练的七个值得你学习的特质。

　　特质一：直面变化

　　首先，在一个教练的观念中，不确定性是无法选择的。对手、天气、队员的伤病、其他队伍如何应对每场比赛以及其他种种因素，都存在不确定性。每个教练都清楚，虽然事先都有精心的计划，这些不确定因素还是都存在。一个优秀的教练会预料到，由于比赛中，或某段时期中发生的事情，每个计划都将有改变。

　　作为项目经理，对待项目你也要有这种思想准备。当然你必须分析风险，但也要保留在必要时改变计划的权力，你甚至需要设定阶段性的停顿，决定计划是否应如期执行。实际上，如果你在项目初始就认识到不确定性的存在，并做好应对计划，一旦不确定的事情发生，你会更加有备而战。

　　特质二：充分研究

　　虽然不确定性是无法选择的，但这并不意味着教练们在比赛来临时不加准备。相反，他们在比赛前做大量的研究工件，与他们的队员看比赛录像—自己的队伍和对手以前的比赛。他们研究哪里打得好，哪里打得不好，并且需要改进。他们分析其他队伍在不同比赛中如何应对，自己的队员又是如何做的，利用这些信息决定应该练习什么，哪些方面需要整理、提高，应该如何迎战对手等等。

　　你也应该从以往项目的教训中，分析哪些做法是有效的，哪些是无效的。同样，虽然你的对手可能不存在(尽管从组织政治的角度看你是存在对手的)，你还是需要清楚了解你的利益相关者。这包括你要清楚哪些人会受到最大的冲击，什么人的影响力最大，如何和每个利益相关群体沟通。

　　特质三：制定计划

　　做了充分的研究之后，教练可以整合利用信息形成比赛的战略方针，设计打法，为队员设定具体的目标。如果目标没有达到，或者队伍没有有效地执行—不管过程中有没有调整计划—他们会在下一场比赛之前分析原因。

　　确定目标和战略对于你的项目同样重要。你不仅要考虑功能性目标，还要考虑表现目标，(用测试的术语来说，比如产品表现，团队表现等等)。你应该从功能水平的角度、进度安排方法、团队结构及其他角度，制定如何开展项目的战略。每个项目都不尽相同，“通用”的方法是不可取的。

　　特质四：逐步实施

　　虽然体育教练制定战略和目标，甚至为具体的某场比赛做了准备，他们并不把整个比赛计划一一列出。这样做会显得很可笑，因为每场比赛都取决于赛场里的发展势态以及比赛中发生的具体情况。种种打法变成了提供多种选择的工具箱。即使计划水平非常高的教练也会根据需要调整战略和目标，保证比赛的胜利。他们会分阶段计划比赛，往往采取定时设计的方式。

　　你的项目也必须逐步实施，并不断地修正，利用滚动计划或者重复进程的方法处理无法事先准确预测的问题。通过定时回顾问题出现在哪里，你可以牢牢控制问题发生的范围(前提条件是重复的次数事先已设定，或者你有办法知道什么时候“游戏结束”)。

　　你也可以使用 “剧本”预演的方法。正如教练准备各种打法以备不时之需一样，你可以将能够形成备选方案的事情列成一个清单，放到你的工具箱里备用。这个清单一般情况下不是项目计划的一部分，但可以作为工作内容的一部分(比如，工作分解结构图中不能再分解的最低层次或最低可交付层次的工作)，与这些工作相关的人员可以在适当的时候使用这张清单，做好每个细节。

　　特质五：人尽其才

　　你不能消除不确定性，但如果你在合适的岗位上有合适的人，你就可以降低不确定性所带来的影响。这似乎是不言而喻的，但教练们特别重视这一点，将合适的人放在合适的岗位上，而且将他们留在这些岗位上。如果一个队员在一个位置上非常出色，他们会留在这个位置上，随着不断进步，他们可以享受这个岗位中更高的薪水和荣誉。当然教练会尝试去发现潜能，但队员的潜能不可以发挥得使他们离开这些岗位，比如，他们不可能优秀到可以升到教练的水平。

　　作为一个项目经理，你肩负着项目成败的责任，所以你必须保证你能将合适的人放在合适的岗位上，包括负责项目管理的岗位。转自项目管理者联盟

　　随着项目的日益复杂，越来越多的组织将项目行政和协调人员列作“项目专家”或“项目总指挥”，从而使项目经理可以有更宽裕的时间管理和领导项目，专心从事沟通这项极为重要的工作。这种将项目经理转为项目组织者的做法迅速得到广泛的效仿。教练们现在也拥有很多支持人员，包括助理教练、训练师、专项教练等等。

　　特质六：善用媒体

　　当你了解了教练最需要集中精力做好的事情是计划和沟通时，你就会明白为什么一个教练需要各种各样的管理支持人员。沟通不仅意味着和队员之间以及管理层的沟通，还包括与公众的沟通。因此一个教练不但要懂得如何塑造和领导一支队伍，还要懂得如何与媒体沟通。

　　同样，项目经理也需要集中精力做好计划和沟通。虽然不是每个项目都需要和媒体进行沟通，但大多数需要在公开的会议上和一群利益相关者进行沟通。

　　清楚这一点，聪明的项目经理就应该学习公关、沟通和演讲技巧。研究表明，对一个项目成功与否的评价往往只是基于沟通的频率与有效性，不管项目是否如期或者在预算内完成。借助有效的沟通与公关关系，你可以减少不确定性带来的影响。#p#分页标题#e#

　　特质七：重视执行

　　在《真相，危险的半真相和胡言乱语：从实证管理经验中获益》(Hard Facts, Dangerous Half-Truths, and Total Nonsense: Profiting From Evidence-Based Management)一书中，作者佩弗(Jeffrey Pfeffer )和萨顿(Robert Sutton)指出了执行的重要性。他们举出一个例子，如果比赛的关键全在于作战指引，那么谁拥有最佳打法，谁就可以赢得比赛，比赛也不用打了。而事实上，每种战术只是为了队伍离得分更近一步。如果做不到这一点，唯一原因就是对手队伍的应对，自身队伍对于战术的执行很差，或者其他的因素。这也是为什么球队总是经常练习打法的原因。没有良好的执行，再好的作战计划也不能发挥作用。

　　很多项目经理一般都会将注意力集中在计划上，包括风险管理、进度管理和预算准备。但失败率依然很高，虽然部分原因在于如何衡量成功存在不同的标准，但大部分是因为项目计划执行得不好。诸如彼此之间忘记沟通，工作分解结构没有把所有相关的人员都考虑进去，预测人员不懂得如何有效预测，以及其他种种操作上类似的错误。

　　如果你花费在培训人员如何操作的时间能和准备项目进度的时间一样多，你的项目会有更多的成功机会。毕竟，这是你所能计划并实施控制的。而对于不可控的因素你是无暇顾及的。项目经理博客

　　通过充分的研究与周全的计划，逐步实施，不断改进，面对不确定性时你会准备得更加充分。同样，在合适的岗位上安排合适的人，并且将精力集中在沟通与执行上，我们可以降低意外情况的发生和影响。

　　最后，既然你的目标是“带领团队在不确定的条件下实现目标”，那么你可以从在这方面出类拔萃的人们身上学到很多，包括军队首领、CEO和体育教练。

笔者作为IT行业的普通一员，从入行到现在也经有6个年头，各种项目管理的培训也参加过几轮，项目管理的书籍也看过几本，大大小小的项目也管理了几个，甚 至有幸亲身参与了CMMI Level2的评估全过程。项目管理之于我，已经不再是高深莫测的理论和闪闪发光的证书，已然成为了工作中不可缺少的基本元素，并且渗透到了每天的生活当 中，成为了再平凡不过的生活元素。甚至，连做饭、逛街这样的日常行为当中也会时时闪现项目管理的影子。

不相信么？没关系，请大家仔细回想一下我们每天做饭的流程，活脱脱一个项目管理的标准流程嘛。首先，按照项目的定义：“项目是为完成某一独特的产品、服务 或任务所做的一次性努力”，我们通常做一顿晚饭的过程具有独特性、一次性和不可重复性的特点, 是一个典型的项目。其次，做饭过程中的每个步骤，都在不知不觉的体现着项目管理的思想和精髓。下面我们就以“晚餐项目”为例，看看貌似深奥的PM理论是如 何在日常生活中最普通的一件事情中大显身手的。

因为项目管理的理论分成许多体系，我们就分别以主流的三种理论来进行分析。首先，我们来看看这个“晚餐项目”放到不同的PM理论模型中是怎样的。

tdir1"> 按照软件生命周期理论，“晚餐项目”可以将其分为这样几个项目阶段：

1. 立项：决定今晚在家吃饭，做出大致的时间安排

2. 需求调研：问问家人都想吃什么菜

3. 需求分析：综合考虑一下季节、天气、控制体重等因素，确定菜式

4. 系统设计：设计出每道菜的主料、配料

5. 开发：外出采购，然后开始做菜

6. 系统测试：尝一下菜的味道

7. 部署：摆桌吃饭

8. 项目收尾：收拾碗碟

按照CMMI(Level 2)的理论体系，“晚餐项目”可以分为这样几个过程域：

1. PP(项目计划)：计划晚餐的菜谱，需要采购哪些原料，做出大致的时间安排

2. PMC(项目跟踪及监控)：每完成一项工作，检查一下是否超出原定的时间计划，如果超出了则做出必要的调整

3. RM(需求管理)：对家人对菜式的要求进行管理，确保每个要求都被管理，或者被满足、或者被取消、或者被变更

4. CM(配置管理)：对晚餐准备过程中的每件制成品、半成品和其它副产品进行管理;

5. MA(度量及分析)：对原材料、工作时间、工作产品等指标进行预算、跟踪、度量和分析;

6. PPQA(过程和产品质量保证)——定期对晚餐的准备过程进行评审，保证按照原有的计划进度进行，并保证每个步骤产生的结果符合质量要求;

7. SAM(供应商管理)——如果准备过程中将部分工作外包，比如网上订购部分原材料等，我们就需要对服务提供商提供的服务和最后提交的产品进行监督和管理。

按照PMP的项目管理体系，“晚餐项目”将被划分为以下9个知识领域：

1. 范围管理：确定菜谱

2. 质量管理：保证原料新鲜，菜的味道符合家人要求

3. 采购管理：如果从网上订购了红酒或其它原料，我们就需要对送货的时间和交付的货品进行管理

4. 时间管理：在整个晚餐项目过程中，确保按照计划的进度完成

5. 人力资源管理：如果准备晚餐的不只你一个人，要对每个人的任务和分工进行管理

6. 风险管理：注意识别和监控晚餐准备过程中可能出现的各种意外情况，并拟定应对预案

7. 成本管理：保证这顿晚餐不要超支

8. 沟通管理：在晚餐准备的过程中，要向各位干系人(比如家人)及时通报进展情况，如果干系人的需求发生变化，也要及时沟通

9. 整体管理：作为晚餐准备的负责人，要对以上各个方面的工作进行监督和控制

如此看来，我们的“晚餐项目”是完全可以当作一个项目来进行管理的，接下来就是选择一个适合的项目管理方法，对项目进行计划、控制和度量了。

虽然我们平时的晚饭没有必要搞得那么复杂，但是，如果你要举办一次稍大的聚餐，或者你是一名饭店的总厨，那么，你完全可以根据具体情况，选择一种适当的项 目管理方法来准备一次聚餐或者宴会，相信一定可以事半功倍很多——比方说，如果准备一次高规格的晚宴，对各方面要求都很高，那么我们可以采用“瀑布模型法 ”，按部就班的进行，同时加强质量保证方面的力度，以确保达到预期的质量标准，避免因质量问题影响进度和饭店的声誉。但是，如果是准备一次小型的聚餐会， 准备的时间又很紧，那么我们就可以选择“快速开发法”，把那些可以并行的环节同时展开，在保证大多数人满意的前提下可以放松一些质量标准，这样可以最大程 度的节约时间，保证聚餐开始的时候来宾不必饿肚子。

可见，项目管理思想完全可以褪去其浮华的外衣，在更多领域发挥它的作用，甚至应用到日常生活中最普通的生活场景中去。作为项目管理人员，在正确使用项目管理方法进行软件开发之外，我们当然也可以利用项目管理的理论和方法，来小小的提升一下日常生活的“项目”管理水平啦。

　　如何做到代码高效无错，提高代码质量的方法有哪些?又有哪些经验和技巧呢?本文整理自知乎网，与开发者们一起探讨该话题。如果您有好的想法，欢迎在评论中列出。

　　一起来看下编程界各位大牛如何为您支招：

　　互联网评论员 孙立伟：

　　1. 代码风格和规范

　　多看看网上的一些代码规范，仔细思考一下制定这些规范的出发点是什么。例如Oracle(前SUN)公司的代码规范oracle.com，Google的代码规范googlecode。

　　2. 学习最佳实践

　　在编码中遇到的各种大大小小的问题，首先不是自己去“闭门造车”的冥思苦想，多用Google，搜搜是否已经有现成的解决方案。

　　3. 阅读优秀的开源代码

　　网上有很多优秀的开源项目，针对你自己项目中遇到的问题，找找类似的开源项目，学习、研究，最重要的是变成自己的东西。

　　4. 学好英语

　　英语是目前所有编程语言的基础。你的文件名、类名、方法名、变量名都是需要一个好的英语基础才能够起得合适。任何的业务逻辑，都需要你使用以英语为基础的计算机语言表达出来。英语不好，你的代码永远看起来不专业。

　　互联网评论员 钟声：

　　靠牛人带，靠代码Review，应该对初期成长很有帮助，不过受环境限制较大，可能并不是所有人都能有这种幸运。多看启发思路的书，多看开源代码，用辅助工具(lint、findbugs等)，都是靠谱的答案，不过我还想补充一点，在这些标准答案背后，更重要的一点：要充分利用自己的敏感，当看着一堆需要自己负责的成品、半成品代码时，哪怕只有一点点的不爽，千万不要忍，而要勇敢地——改!大刀阔斧、大张旗鼓!

　　其实道理并不复杂：重复的东西可以合并，零散的逻辑可以集中。让一切保持有条不紊，只需要拆解得当。此时，那些曾经空洞的理论开始具现化，节省了思考的时间，也成为了顺手的工具。“DRY”一个词就可以说明白原则，“技术债务”一个词就可以争取到重构时间。

　　DSP软件程序员 冯旭辉：

　　1.学会模块分割是提高代码质量的关键

　　人的精力有限，人的经验也有限，但把问题拆分成子问题，形成一个个独立的模块，这就可以让我们的精力更加集中于某个细微的问题，无论如何，都会大大提高模块的编写质量。

　　2.要从一开始就养成一个良好的编码风格

　　比如函数的头部注释的格式，函数间的分割方式，函数组的分割方式形成固定的程式。并使用编辑器的宏功能预先做好快捷方式，需要时直接生成出来这些格式化文本。

　　3.需要使用CVS之类的源代码版本管理工具

　　每完成一个小功能改进或者bug修复就提交，这样下来，你的工作就是逐步精化。

　　4.使用诸如MantisBT之类的bug管理工具

　　对每一个出现的bug，修改完成后，进行详细的处理过程描述，以备今后再犯类似的错误。

　　还有些码农认为，应该多读好的代码，比如著名开源框架的代码的写法，在保证功能、效率的基础上思考结构，回顾下自己编写的代码;反复评审代码，规范代码、改进实现方案的写法。同时还应该尽一切努力减少代码重复，将代码分解为自成体系，可测试的小块 ;最后测试，测试，再测试。

　　当然这还需要有很强的毅力。

　　但更令我印象深刻而难以忘怀的，是我亲自经历的、亲眼目睹的、道听途说的一个又一个的软件项目，它们有的获得了成功，但更多的是令人沮丧的失败。套用一下大文豪托尔斯泰体：幸福的家庭都是一样的，不幸的家庭却各有各的不幸;幸福的软件项目都是一样的，不幸的软件项目却各有各的不幸;或者说，成功的软件项目都是一样的，失败的项目却各有各的问题。我常常在想，我们的项目开发到底怎么了，进而把它们一个一个的剥开来深入分析，竟然触目惊心。它们有的是需求的问题，有的是客户关系的问题，还有设计的问题、技术的问题、时间管理的问题、人员培养的问题••••••但归根到底更多的还是需求的问题。需求分析既是一份体力活儿，更是一份技术活儿，它既是人际交往的艺术，又是逻辑分析与严密思考的产物。正是我们在需求分析过程存在的巨大隐患，最终导致了那么多项目的失败。也许你认为我在危言耸听，好吧，我来举几个典型事例分析分析吧。

　　我的第一个故事来自大名鼎鼎的东软。我在2005年接一个项目的时候，听说这个项目之前是东软做的。当时东软在做这个项目的时候，整个过程经历了10多次结构性的大变更，局部性的调整更是不计其数。据说某天早上，客户对某个功能不满意，他们不得不对几百处程序进行修改。之后客户对修改的内容还是不满意，又不得不将几百处修改重新改回来。最后这个项目导致的结果是，整个这个项目组的所有成员都离开了东软，并似乎从此不愿涉足软件开发领域。多么惨痛的教训啊!我常常听到网友抱怨客户总是对需求改来改去，但客户对需求改来改去的真正原因是什么呢?当我们对客户的需求没有真正理解清楚时，我们做出来的东西客户必然不满意。客户只知道他不满意，但怎样才能使他满意呢?他不知道，于是就在一点儿一点儿试，于是这种反复变更就这样发生了。如果我们明白了这一点，深入地去理解客户的业务，进而想到客户的心坎儿上去，最后做出来的东西必然是客户满意的。记住，当客户提出业务变更的时候，我们一定不能被客户牵着走，客户说啥就是啥。我们要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。

　　第二个故事来自我自己的项目，一个早期的项目。在这个项目中，客户扔给了我们很多他们目前正在使用的统计报表，要我们按照报表的格式做出来。这些报表都是手工报表，许多格式既不规范，又很难于被计算机实现。这些报表令我耗费了不少闹细胞，直到最终项目失败都没法完成。这件事留给我的深刻教训是，不能客户怎么说软件就怎么做。客户提出的原始需求往往是不考虑技术实现，基于非计算机管理的操作模式提出来的。他们提出的很多需求常常比较理想而不切实际，毕竟人家是非技术的。但我们作为技术人员，需求分析必须实事求是地、基于技术可以实现的角度去考虑。那种“有条件要上，没有条件创造条件”的鲁莽行事，结果必然是悲惨的。所以我们必须要基于技术实现去引导客户的需求。同时，计算机信息化管理就是一次改革，对以往手工管理模式的改革。如果我们上了信息化管理系统，采用的管理模式却依然是过去的手工模式，新系统的优势从何而来呢?因此，我们做需求就应当首先理解现有的管理模式，然后站在信息化管理的角度去审视他们的管理模式是否合理，最后一步一步地去引导他们按照更加合理的方式去操作与管理。

　　2007年，我参与了一个集团信息化建设的项目。这个项目中的客户是一个庞大的群体，他们分别扮演着各种角色。从机构层次划分，有集团领导、二级机构人员、三级机构人员;从职能角色划分，有高层领导、财务人员、生产管理员、采购人员、销售人员，等等。在这样一个复杂场景中，不同人员对这个项目的需求是各自不同的。非常遗憾的是，我们在进行需求分析的时候没有认真分析清楚所有类型人员的需求。在进行需求调研的时候，总是集团领导带领我们到基层单位，然后基层单位将各方面的人员叫来开大会。这样的大会，各类型的人员七嘴八舌各说各自的需求，还有很多基层人员在大会上因为羞涩根本就没有提出自己的需求。这样经过数次开会，需求调研就草草收场。我们拿着一个不充分的需求分析结果就开始项目开发，最终的结果可想而知。直到项目上线以后，我们才发现许多更加细节的业务需求都没能分析到，系统根本没法运行，不得不宣告失败。一个软件项目的需求调研首先必须要进行角色分析，然后对不同的角色分别进行调研。需求调研的最初需要召开项目动员大会，这是十分必要的。但真正要完成需求分析，应该是一个一个的小会，1~3个业务专家，只讨论某个领域的业务需求，并且很多问题都不是能一蹴而就完成的，我们必须与专家建立联系，反复沟通后完成。需求分析必须遵从的是一定的科学方法，而不是盲目的大上快上。

　　我的最后一个故事可能典型到几乎每个人都曾经遇到过。我们的项目从需求分析到设计、开发、测试都十分顺利。但到了项目进行的后期，快到达最后期限时，我们将我们的开发成果提交给客户看，客户却对开发不满意，提出了一大堆修改，而且这些修改工作量还不小。怎么办呢?加班、赶工，测试时间被最大限度压缩。最后项目倒是如期上线了，但大家疲惫不堪，并且上线以后才发现许多的BUG。需求分析不是一蹴而就的，它应当贯穿整个开发周期，不断的分析确认的过程。以上这个事例，如果我们提早将开发成果给客户看，提早解决问题，后面的情况就将不再发生。这就是敏捷开发倡导的需求反馈。敏捷开发认为，需求分析阶段不可能解决所有的需求问题，因此在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时获得反馈。只有这样才能及时纠正需求理解的偏差，保证项目的成功。#p#分页标题#e#

　　以上的故事各有各自的不幸，各自都在不同的开发环节出现了问题。但经过深入的分析，各自的问题最终都归结为需求分析出现了问题。为了使我们今后的软件项目不会重蹈覆辙，似乎真的有必要讨论一下我们应该怎样做需求分析。

　　很多需求分析的工作是从需求调研开始的，我们就从这里说起吧。需求调研是需求分析最重要的一环，也最集中地体现了需求分析的特点——既是一份体力活儿，更是一份技术活儿。它既要求我们具有一种理解能力、设计能力，更要求我们具有一种与人交往、沟通的能力。

　　在一个阳光明媚的下午，项目经理带领着项目组成员，参加了客户组织的见面会，一个新的软件研发项目就这样开始了。双方在一种友好的气氛中进行，双方相互寒暄，介绍与会人员，拉拉家常。逐渐地，会议开始进入了正题。初次接触客户，对于项目团队意义重大。对方对你印象的好坏，今后如何与你交往，都在这个阶段被确定下来。然而，在客户至上的今天，与客户保持适当的谦卑是有必要的，但过于的谦卑却常常给项目日后的进程带来风险。为什么这么说呢?过于的谦卑，处处都是诺诺诺，客户说什么就是什么，就会使客户变得非常强势。这样的结果就是，客户提出了许多变态的、不太现实的、不合理的需求，而我们呢却是一味地服从，客户说什么就是什么。最后我们做得很累，结果却不能让客户满意。

　　正确的做法是，我们对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。如果能够这样，客户不仅能够欣然接收你提出的方案，而且会感觉你非常专业，你在客户心目中的形象也会无形中提高，使你有更多的机会提出有利于开发的可行方案，降低开发的风险。这毫无疑问会形成一个良性循环，但要做到这一点并不容易，我们需要在与客户接触的初期，就运用自己的专业知识在客户心目中形成威信。

　　也许在见面会之前我们已经做足了功课，已经对客户提出的需求进行了一番详细的整理，也许有了一大堆疑问急需解答。但是，在最初的见面会上，不是解答具体问题的地方，这是我们常常会犯的一个毛病。作为客户，特别是客户方的领导，最希望了解的是这个项目在宏观上给他们带来的利益。因此，在这样一个场合，我们讨论的都是宏观上的问题：客户在宏观上对这个项目所要达到的目标，我们在宏观上给客户提出的解决方案，在宏观上能给予客户的利益，等等。

　　同时，这样的会议又是一个项目启动会议。客户方领导要传达给与会代表一个清晰的信号，就是与会代表今后要积极配合我们完成今后的工作。这时候，要清楚地弄清，客户方有哪些角色，谁是这些角色的需求制订人与负责人。这是什么意思呢?在软件项目中，特别是管理型软件项目中，客户都代表的是一个群体，而不是个人。他们代表的可能是一个单位、一个集团，甚至是一系列组织机构。在这样一个群体中，他们按照职能被划分成了不同的角色。拿一个单位来说，横向可能划分成不同的部门，财务部、销售部、采购部、生产部••••••不同的部门，由于业务的不同，对软件的需求自然是不同的;纵向又可以划分为多个层次，如高层领导、中层领导与基层人员，高层领导关心的是宏观的目标，中层领导关心的是具体的效益，而基层人员关心的是细节的每一步操作。划分清楚角色，弄清楚每个角色的需求制订人与负责人，才能在今后的需求调研中找对正确的人，使事半功倍。

　　俗话说：万事开头难。我们以往在项目开始的时候总感觉千头万绪不知如何着手。在这里我给大家的建议就是这三点：1)树立良好的职业威信;2)从宏观上制订目标与方案;3)进行角色分析，将与会各方代表对号入座。随后的工作，就是逐一拜访客户代表，各个击破。

　　怎样摆脱这样的困境呢?为何软件开发项目管理这么困难呢?为何我们做的计划总是不能按时完成呢?为何软件开发不能像硬件开发那样可以控制呢?原因在于软件开发完全靠人的大脑思维产生出产品，而每个人的大脑思维是不一样的，因此在软件开发过程中有太多不确定的、可以变化的因素，我们怎样把握住这些变化因素呢?就像我们题目所说的一样，软件开各阶段的成果质量管理，如果我们能够很好的控制软件生命周期每一个阶段的质量，也就很好的控制了整个软件开发的整个过程。

　　软件产品的质量是个很大的概念，因为软件产品完全是人们大脑思维的产物，就是将大脑里无形的看不见摸不着的思维变成一个可以看到的，可以解决实际问题的一组界面或者组件。这样的一个复杂的过程，质量应该如何保证呢?有人想到了ISO9000、CMM，也有人很反对，说应该用敏捷开发。其实，不管用什么样的开发过程，关键是找到这些过程的真谛，有些人说，ISO和CMM到中国来就变了味了，为什么变味儿了呢?其实我们只学到了该做什么，却不知道怎样去做，为什么要这样做?大家都知道做软件开发需要写需求规格说明书和设计文档，为什么要写，文档的重要性有多高?没有资深开发和管理经验的人员可能很难理解其重要性，如果只是简单的形式上去写一篇这样的文档，对后面的编码和测试没有实际的指导作用，甚至起了“ 误导”作用，同样会引起大量返工，那么这些文档除了负担之外就没有其他用途了，要知道写这些文档是需要消耗项目组资源的(进度、成本...)。

　　很多人又想到了测试，觉得是我们测试的力度不够，所以我们产品质量不过关，其实，软件开发的质量保证从开发最初就应该开始了，如果到了测试阶段才重视就已经晚了。软件产品开发过程，不管采用瀑布式还是迭代式，都离不开需求、设计、编码、测试这几个阶段，在迭代式开发中，这几个阶段也是周期性出现的。怎样把握好每个阶段的质量，确实不是一件容易的事，本期重点介绍一下需求、设计和编码阶段的成果质量，当然以后会共享一些过程质量方面的知识。

　　1、需求

　　我们知道人与人的交流总是会存在一些误会，同样一句话，心情不好与心情好的时候听起来的感觉可能会截然相反，正是因为人们之间存在着理解上的偏差，在描述需求的语言上就应该注意尽量避免歧义的产生。如果对UML比较熟悉的话，需求分析可以利用UML工具进行，这样可以减少一些自然语言引起的歧义，但是UML可能与用户沟通起来有一些障碍，因为并不是所有的用户都了解 UML各种图形的意思。除了工具之外，我们可以从以下几个方面来保证需求描述的质量。

　　1、看句子和段落是否简短，一个很长的句子，看起来会非常困难，因此无法弄懂真正的需求，另外过长的句子和段落容易让人忽视一些需求，所以如果一个句子不能完全描述清楚需求，应该将其拆分成多个小句子。2、句子是否有语法错误，还要注意标点符号，有时，标点符号点错了，就完全成了另外一个意思了。 3、是否存在模糊不清的需求，出现类似于可能，大概，或者等词汇表述的需求。4、另外注意引用的术语和词汇是否前后一致。5、是否存在一些形容词、比较性词语，比如：容易的、快速的、方便的、有效的、许多、很少、简单、复杂、最新的，界面友好的，减少、扩大，不小于等等，需要将描述性词语进行量化，并且给出具体值或者范围，要不然不同的人根据不同的理解就会得出不同的结果，最终可能跟用户最初的要求有偏差，那“炒回锅肉”的事情就不可避免地会发生。

　　另外保证需求质量的一个很重要的因素就是需求是否细化，如果需求不细化也会很容易造成代码的返工，于是就出现了我们的程序员尽管总是加班加点却总是不能如期的完成任务的情景。那么我们怎样才能判断需求细化的程度呢?需求细化程度确实很难把握，什么样的需求可以算是比较细了，不用再进行细化了呢?哪些需求又太粗了呢?答案是需求是否可以写出相应的测试用例，如果写不出来，就说明需求还不是很细，还需要再进行细化。

　　2、设计

　　软件架构设计在软件产品开发周期中占有很重要的位置，我们开发出来的软件产品在开发伊始到产品发布会涉及到方方面面的角色，例如：用户、项目管理人员、程序员、测试员、维护人员等等。不同的角色对架构设计的要求也不相同。例如用户关心的是需求，因此我们的设计对需求的覆盖率是多少?对于程序员来说模块是否清晰，类的功能是否单一等等，对于测试人员来说系统的是系统的可测试性。对于维护人员来讲系统的扩展性、可维护性如何?一个高质量的软件架构，应该最大限度的考虑并满足不同角色的不同要求。正是因为有这些要求，我们在进行软件设计的时候，应该进行全面的考虑。一般用来衡量软件设计质量的标准可以从以下几个方面来考虑：

　　1)、功能性：包括完全性、正确性、安全性、兼容性、互用性。完全性包括功能点覆盖率，重点功能点覆盖率，优先功能覆盖率。正确性包括需求一致度。安全性根据软件需求的不同有不同的安全性要求。项目经理圈子

　　2)、效率：包括产品运行的时间效率和利用的硬件资源两方面来考虑。

　　3)、维护性：包括架构的可改正性，可扩充性以及可测试性。如果用户的一个很小的需求变更会引起架构设计很大的变化，那么这样的架构设计的可改正性和可扩充性就比较差。

　　4)、可移植性：包括硬件的独立性、软件独立性、可安装性、可重用性。软件设计是否模块化、每个模块的可复用性如何都是应该考虑的因素。

　　5)、可靠性：包括缺陷数量、容错性、可用性。

　　6)、使用性：包括可理解性、易学习性、可操作性、易沟通性。我们软件的最终目的是让用户来使用的，如果易用性不好，可操作性不好都会影响用户对软件的接纳程度。因此在软件的可使用性也是非常重要的。#p#分页标题#e#

　　3、编码

　　代码质量的一个很重要的标准就是代码的可读性及规范性，可读性不一定是简单的代码，而是容易理解的代码，因为过于复杂的代码难以测试和维护，同时出错的几率也会更高。如果一个方法内部的代码很长，而且使用了很多令人难以理解的数据集，这样就会带来代码维护的困难，因为很少有人能够有效地分析它们，因此也就是最容易出现缺陷和错误的地方。类之间的耦合度会造成类与类之间的相互关联，当一个类发生改变时会使其他的类发生意想不到的变化，一般从导入类的个数判断类之间的耦合度，如果导入类的个数很多，每一个导入类发生变化都会影响到该类本身，另外如果该类的public方法太多也会导致类之间的高耦合性增加。

　　也许有的程序员会认为写出可读、规范的代码会影响工作进度。的确，对于程序员个体短时间来说为代码写上注释是要花费些时间，但如今软件开发是多人协作。

　　周期很长的过程，写过程序的人都知道，如果自己写了不规范的代码，随着自己所写的代码越来越多，到后来需要修改某个前期写的模块时都不知道自己当初是怎么想的了，读自己的代码也需要花很长时间才读懂。况且如果随着人员的调动等其他原因，往往维护代码的程序员已不是当初写代码的人，很多情况就是读懂了一段糟糕的代码还比重新写出一段代码花费的时间还长，严重影响工作效率(有些时候还影响维护人员的心情)，反过来，如果大家都讲究把代码写成规范可读的，无疑对于整个组织来说提高总体工作效率是非常有用的。

　　代码质量另一个非常重要的衡量手段就是测试，通过统计测试代码所产生的缺陷情况，如严重等级分布、缺陷曲线的变化等可以从一个方面来简单地评估代码质量。

　　什么是需求分析?

　　通俗的讲，对用户的意图不断揭示和验叛的过程，要对经过系统可行性分析所确定的系统目标做更为详细的描述。

　　假如你是个建筑工程师，有个客户找你建一个鸡窝，这个时候要需要与客户沟通，来确定客户到底想要一个什么样子的鸡窝。我们应该注意三点：

　　1、准确的理解和描述客户需要的功能。

　　客户说，我的鸡窝要三层的，带电梯，饮水池，厕所，饮水池要自动判断水位供水，电梯要可以同时乘坐10只鸡....客户滔滔不绝的讲了一大堆，你也都非常忠实的按照自己的理解再一一的向客户描述一遍，以便于确认客户的需求是否正确。

　　2、帮助客户挖掘需求。

　　等客户把自己的需求说完了，你发现客户没有说鸡的卧室，于是，你向客户提议说：“你看，这鸡的卧室要什么样子的?”，客户连连的拍着脑门说，我差点给忘记了，鸡们啊喜欢晚上在一起聊天，所以呢，需要一个长而大的卧室，但一定要舒适。

　　3、分析客户需求的可行性

　　客户临走时又说，最近了，黄鼠狼很多，我这个鸡窝啊，一楼就不用盖了，直接盖二楼和三楼吧!以免晚上遭遇黄鼠狼的攻击。你这么一分析，客户这要求，按照目前的技术可没法建啊，于是，你向客户提议，一楼采用坚固架子来支撑二三楼的建筑。

　　需求分析困难在哪儿?

　　有几种原因使需求分析变得困难：(1)客户说不清楚需求;(2)需求自身经常变动;(3)分析人员或客户理解有误。

　　1、客户说不清楚需求

　　有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。例如全国各地的很多政府机构在搞网络建设，这些单位的领导和办公人员大多不清楚计算机网络有什么用，反而要软件系统分析人员替他们设想需求。这类工程的需求是如此的主观，以致产生很多贪污腐败现象。

　　有些客户心里非常清楚想要什么，但却说不明白。你可能很不以为然。就举日常生活的事例吧，比如说买鞋子。我们非常了解自已的脚，但没法说清楚脚的大小和形状。只能拿鞋子去试，试穿时感觉到舒服才会买鞋(居然也有神通广大的售货员，看一眼客户的手，就知道应该穿什么样的鞋)。

　　如果客户本身就懂软件开发，能把需求说得清清楚楚，这样的需求分析将会非常轻松、愉快。如果客户全不懂软件，但信任软件开发方，这事也好办。分析人员可以引导客户，先阐述常规的需求，再由客户否定不需要的，最终确定客户真正的需求。最怕的就是“不懂装懂”或者“半懂充内行”的客户，他们会提出不切实际的需求。如果这些客户甚至觉得自己是上帝的爸爸，那么沟通和协商都会很困难。

　　2、需求自身经常变动

　　唐僧曾说：“妖要是有了仁慈之心，就不再是妖，是人妖。”(《大话西游之大圣娶亲》)

　　连妖都会变心，别说人了。所以喜新厌旧乃人之常情，世界也因此变得多姿多彩。

　　软件的需求会变化吗?

　　答：据历史记载，没有一个软件的需求改动少于三次。唯一只改动需求两次的客户是个死人。这个可怜的家伙还是在运送第三次需求的路上被车子撞死的。

　　让我们先接受“需求会变动”这个事实吧，免得在需求变动时惊慌失措。明白“需求会变动”这个道理后，在进行需求分析时就要留点神：

　　(1)尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求。以便在进行系统设计时，将软件的核心建筑在稳定的需求上，否则将会吃尽苦头。

　　(2)在合同中一定要说清楚“做什么”和“不做什么”。如果合同含含糊糊，日后扯皮的事情就多。要防止象韩复渠那样，在别人请他喝酒吃饭时他什么都点头(人家就更加献殷勤)，吃完了他就宣布刚才答应的事都不算数，便扬长而去。

　　3、分析人员和顾客理解有误

　　有个外星人间谍潜伏到地球刺探情报，它给上司写了一份报告：“主宰地球的是车。它们喝汽油，靠四个轮子滚动前进。嗓门极大，在夜里双眼能射出强光。……有趣的是，车里住着一种叫作‘人’的寄生虫，这些寄生虫完全控制了车。”

　　软件系统分析人员不可能都是全才。客户表达的需求，不同的分析人员可能有不同的理解。如果分析人员理解错了，可能会导致开发人员白干活，吃力不讨好。我读中学时候最怕写作文逃题，如果逃题了，不管作文写得多长，总是零分。所以分析人员写好需求说明书后，要请客户方的各个代表验证。如果问题很复杂，双方都不太明白，就有必要请开发人员快速构造软件的原型，双方再次论证需求说明书是否正确。

　　由于客户大多不懂软件，他们可能觉得软件是万能的，会提出一些无法实现的需求。有时客户还会把软件系统分析人员的建议或答复给想歪了。

　　有一个软件人员滔滔不绝地向客户讲解在“信息高速公路上做广告”的种种好处，客户听得津津有味。最后，心动的客户对软件人员说：“好得很，就让我们马上行动起来吧。请您决定广告牌的尺寸和放在哪条高速公路上，我立即派人去做。”

　　需求分析的分类

　　需求分析一般可分为功能需求、非功能需求和领域需求

　　1、功能需求：

　　功能需求主要说明了系统实际应做到什么。这是用户最直观也是最主要的需求，如系统的输入输出、系统能完成的功能以及其它相关处理等;

　　2、非功能需求：

　　非功能需求又称“约束”，它主要从各个角度对系统起约束和限制作用。如响应时间、存储效率、报表的规格和界面的样式等

　　3、领域需求：

　　领域需求的来源不是用户，而是系统应用的领域，其主要反映了该领域的基本问题。例如勤工俭学管理系统，其领域需求就涉及到诸如应聘合同书、酬金发放及劳工考核等相关内容，如果这些需求得不到满足，系统就无法正常运行。值得一提的是，领域需求可能是功能需求，也可能是非功能需求。

　　如何进行需求分析

　　进行需求分析不象情人之间的浪漫做法——“让我摸摸你的头发，感觉它是什么颜色。”我们需要了解需求分析的渠道和过程。#p#分页标题#e#

　　需求分析的过程

　　(1)可行性研究

　　它指明现有的软件、硬件技术能否实现用户对系统的要求，从业务角度来决定系统开发是否可行以及在预算范围内能否开发出来。可行性研究的结果是清楚的回答：该系统是否值得开发

　　(2)需求导出和分析

　　这是一个通过对现有系统分析、与潜在客户讨论、进行任务分析等导出系统需求的过程，也可能需要开发一个或多个不同的系统原型，以帮助分析员了解所要描述的系统。

　　(3)需求描述

　　需求描述就是把在分析活动中收集的信息通过分析整理之后以文档的形式确定下来。该文档中有两类需求：用户需求是从客户和最终用户角度对系统需求的抽象描述;系统需求是对系统要提供的功能的详尽描述。

　　(4)需求有效性验证

　　主要是通过评审、验证等一系列活动来找出需求文档中的错漏并加以改正。

　　(5)需求管理

　　需求管理需求管理是一种系统化方法，可用于获取、组织和记录系统需求并使用户和开发方在系统变更需求上始终保持一致

　　需求分析的方法

　　1、功能分析方法

　　那怕是天下最无能的市长或书记，都知道在作报告时要先从宏观上讲一、二、三、四、五，再从细节上讲 A、B、C、D、E;需求分析不象侦探推理那样从蛛丝马迹着手。应该先了解宏观的问题，再了解细节的问题。

　　功能分析法功能分解法以系统提供的功能为中心来组织系统。首先定义各种功能， 然后把功能分解为子功能， 同时定义功能之间的接口。数据结构是根据功能/子功能的需要设计的。 其基本策略是以分析员的经验为依据， 确定新系统所期望的处理步骤或子步骤， 然后， 将问题空间映射到功能和子功能上。

　　2、数据流方法

　　周末，小明一觉醒来突然想吃红烧肉，那想得口水直流，于起床，穿好衣服，打开钱包一看空的，好吧，先去银行取钱，然后去菜那买了一肉、各种配料，然后回家，开火，各种材料往锅里一放，开始小火慢炖，半个小时后，小明终于吃上了美味可口的红烧肉。这是一个典型的流程，如果把它看成一个系统功能的话，那么小明吃到红烧肉是这个功能的目的，那么中间要经历许多环节，起床穿衣---取钱---习材料----制作完成。而且各个功能(步骤)之间是相互联系的，小明总不能不穿衣服直接去取钱吧。

　　数据流法也叫结构化分析， 其基本策略是研究问题域中数据如何流动以及在各个环节上进行何种处理， 从而发现数据流和加工。 问题域被映射为由数据流、加工以及文件、端点等成份构成的数据流图(DFD) ， 并用数据字典对数据流和加工进行详细说明。这种方法的关键是动态跟踪数据流动。

　　3、信息建模方法

　　一个贵妇去报案，我丢了一个辆车，小明是警察，然后问贵妇，你丢的什么样的车子?贵妇噼里啪啦的给小明描述车子样子：我的车子有四个轮子，前面两个小，后面两个大，车身是流线型的，后面带尾翼，里面只一排坐位的那种，车坐上都用的真皮做套子，后面…..你听着听头大了，然后对贵妇说：等等，我给你画下来。于是，贵妇边说，你边画，然后贵妇指出画的不对的地方由你来修改。当然了这只是实体的样子。我们还需要知道汽车各个部件的功能以及各部件之间的关系。

　　信息建模法的核心概念是实体和关系， 主要工具是语义数据模型(实体关系图) ， 其基本策略是找出现实世界的对象， 然后用属性来描述对象， 增添对象与对象之间的关系， 定义父类与子类， 用父类型/子类型提炼属性的共性， 用关联对象关系作细化的描述， 最后进行规范化处理。 其实质是将问题空间直接映射成模型中的对象。

　　----下面三种方法，我还不能理解-----

　　4、面向对象方法

　　我想你如果学习过面向对象编程的话，会很容易理解。

　　面向对象分析 OOA(Object- Oriented Analysis) 的基本策略是通过信息隐藏将比较容易变化的元素隐藏起来， 分析员基于比较稳定的元素建立其思想和规格说明的总体结构。

　　面向对象分析的主要特性是加强了对问题域( Problem Domain) 和系统责任( System Responsibili-ties)的理解; 改进与分析有关的各类人员之间的交流; 对需求的变化具有较强的适应性; 支持软件复用

　　5、面向本体方法

　　面向本体的需求分析 OORA (Ontology- Oriented Require-ments Analysis) ， 是 OOA方法的有效补充和提升。 面向本体方法强调相关领域的本质概念以及这些概念之间的关联。其实质是在面向对象方法中引入对象关联， 并给出各种关联的语义语用。

　　OORA方法由 4 个阶段来完成。第一阶段： 用一种自然语言BIDL( Bisiness Information Description Language) 描述事务; 第二阶段： 确认隐含在 BIDL文本中的本体和对象; 第三阶段： 将这些本体和对象转换成另一种语言 Ononet (Ontology and Object- Ori-ented Network) ， 得到用 Ononet 书写的需求预定义; 第四阶段： 在采用 Ononet 作为知识表示形式的领域本体知识库中搜索相关的知识， 并和前面的需求预定义合并， 得到软件完整的需求定义。

　　6、形式化方法

　　形式化方法， 广义上讲， 是应用数学的手段来设计、 模拟和分析， 得到像数学公式那样精确的表示。从狭义上讲， 就是使用一种形式语言进行语言公式的形式推理， 用于检查语法的良构

　　性并证明某些属性。在需求分析阶段， 利用形式化方法得到需求规格说明书， 可以规范软件开发过程， 为获得更好的系统性能提供重要保证。

　　=============================粗俗的方法=====================

　　可能你对上面的方法看不懂，起码后三种我是看不懂的，怪我知识太少的缘故。

　　我们来看下面了解需求的方式：

　　(1)直接与客户交谈。如果分析人员生有足球评论员的那张“大嘴”，就非常容易侃出需求。#p#分页标题#e#

　　(2)有些需求客户讲不清楚，分析人员又猜不透，这时就要请教行家。有些高手真的很厉害，你还没有开始问，他就能讲出前因后果。让你感到“听君一席言，胜读十年书。”

　　(3)有很多需求可能客户与分析人员想都没有想过，或者想得太幼稚。要经常分析优秀的和蹩脚的同类软件，看到了优点就尽量吸取，看到了缺点就引以为戒。前人既然付了学费，后人就不要拒绝坐享其成。

　　IS09000质量管理系列标准具有系统性、实用性和适时性，已被全球161个国家和地区的776 608家企业采纳并实施”。但该质量体系不提供面向具体行业的标准质量流程，其复杂的规定和大量文档难以被有效管理。因此，如何建立适合具体行业的ISO质量系统，并通过信息技术提升质量管理的效率和水平，是企业管理和企业信息化研究的一个重要方向。

　　现代企业需要通过不断的产品开发活动来增强其核心竞争力，产品开发等活动多依赖项目的形式来组织并实施。现有项目质量管理研究没有系统考虑项目质量管理和企业运营过程质量管理间的关系，无法对项目质量管理进行统筹规划。针对项目管理对企业组织模型和业务过程带来的影响，本文综合考虑企业质量管理和项目质量管理的关系，建立了一种面向产品开发项目的企业级项目质量管理模型。

　　2 企业质量管理与项目质量管理

　　IS09000系列标准为企业建立质量体系提供了质量保证规定和实施原则。最新的IS09000质量标准(IS09000：2000)，强调采用面向过程的方法，使其具有更广泛的适用范围。按ISO的定义，过程是接收输入并将其转化为输出的活动。质量管理系统需要识别并管理组织的内部过程，及这些过程问的相互关系。IS09000：2000建议每个过程都基于规划、执行、检查和改进(Plan.Do—Check—Act，PDCA)模式进行管理。若采用基于面向过程的方法，则质量管理的客体是企业所有内部过程。在现代企业中，过程包括2种类型：(1)连续不断、周而复始的运营过程，如人员考核、车间生产等;(2)项目是一种特殊的过程，它是在一定时间内，满足一系列特定目标的多项相关工作的总和。项目与运营过程不同，具有不可重复性、多目标性和临时性等特点，因此，项目的质量管理更复杂。当更多企业业务活动需要通过项目的形式来组织时，必须对企业范围内的所有项目实施有效的质量管理，并在质量系统中协调项目和运营过程质量管理的关系。运营过程、项目和质量管理的关系可以通过图1来描述。在时间维，定义了基于PDCA模式的过程执行和质量管理过程，PDCA的4个阶段循环执行，实现企业质量管理的持续改进;在对象维，定义了企业质量管理的客体对象，即项目和运营过程2种类型的过程;在组织维，定义企业质量管理的组织层次，包括企业、职能部门、临时性组织和外部相关组织等企业质量管理的主体。项目作为企业质量管理的客体对象之一，其主体包括企业领导、职能部门、项目组和客户等，其过程参照PDCA模式执行。

　　图1 运营过程、项目和质量管理

　　3 产品开发项目质量管理的构建

　　为了适应不同行业的质量管理特点，IS09000：2000扩大了对质量标准进行剪裁的自由度，以符合企业实际情况。从这个意义上说，企业实施ISO质鼍系统的过程，就是企业对IS09000质量体系进行剪裁的过程。IS09000：2000是面向过程的，基于IS09000：2000的企业质量管理系统的核心内容是识别并控制企业内部的过程。

　　产品开发项目是通过使用新技术或新方法来开发一种新产品，其质量管理比其他行业的项目更复杂，具体表现在技术含量高、未知因素多和质量控制困难等方面。因此，直接基于ISO标准定义一个适合于所有产品开发项目的标准过程很困难。本文提出采用两步剪裁法来实现对项目过程的质量管理：(1)基于ISO质量体系进行剪裁，为企业内部不同类型的项目建立相应的参考过程模型;(2)项目启动后，项目经理对参考过程模型进行剪裁，形成适合于特定项目的执行过程模型。通过上述2步进行剪裁(图2)，可实现企业内部项目过程的可定义和可管理。

　　图2 项目质量控制过程

　　通过两步剪裁法可确定项目宏观过程的检查点，实现项目宏观过程的质量管理。产品开发项目还包含诸多设计过程、制造过程等微观企业运营过程，这些运营过程的执行需要遵循在企业质量管理系统中定义的标准过程。因此，产品开发项目的质量管理由项目过程质量管理、运营过程质量管理2个部分组成。

　　4 产品开发项目质量管理建模

　　面向对象方法建模采用一组面向对象的概念及图形符号进行需求分析和设计。其模型是对真实世界的抽象，与软件开发密切结合。因此，本文采用面向对象方法建立产品开发项目质量管理模型。

　　4.1 组织结构分析

　　研究表明，目前越来越多的企业采用矩阵型组织结构，即同时存在基于职能的组织结构和基于项目的组织结构。本文根据矩阵型的组织结构分析产品开发项目质量管理的组织模型。

　　为了更好地提升企业质量管理的执行能力，企业须设置专门的质量管理部门(如质量管理办公室QMO)来策划并实施企业质量管理系统。其他职能部门日常业务的执行要遵循质最管理系统的要求，如设计部门需要按照企业标准设计过程来执行设计任务。项目管理办公室PMO管理企业范围内的所有项目，包括制定企业项目管理规范、管理项目的输入输出及处理多项目资源冲突。企业须为每个产品开发项目成立相应的项目组。项目组的最高负责人是项目经理，项目经理由项目办公室管理。项目组成员从企业组织的各个职能部门调入，在参加项目期间，服从项目经理领导(强矩阵结构)，或服从项目经理和企业职能部门的双重领导(平衡矩阵结构)。综上所述，与产品开发项目质量管理直接相关的组织单元包括质量管理部门、项目管理部门和项目组。因为项目组成员同时隶属于职能部门，所以相关职能部门也会与产品开发项目间接发生关系。

　　4.2 功能模塑

　　UML采用用例描述和识别需求，根据不同应用目的，用例可分为业务用例(business case)和系统用例(system case)，分别用于识别企业业务功能和确定应用系统功能。本文采用业务用例定义支持产品开发项目质量管理的企业质量管理功能模型。

　　根据4.1节的组织结构分析，可以抽象出如下用例模型的角色：企业领导，质量管理办公室，项目管理办公室，项目经理和项目成员。如图3所示，产品开发项目质量管理分3级实现：企业级，项目管理办公室级和项目级。#p#分页标题#e#

　　图3 产品开发项目质量管理功能模型

　　企业领导和质量管理办公室负责企业级质量管理系统的实现，企业级质量管理系统包含企业项目质量管理系统。项目管理办公室参与建立企业项目质量管理系统，定义企业各种项目的参考过程模型。项目经理管理由他负责的项目，在过程剪裁的基础上制作项目质量计划，组织定义项目质量目标并管理项目质量。

　　4.3 过程模型

　　项目过程通常可分为4个阶段：启动阶段，计划阶段，执行和控制阶段，完成阶段。每个阶段又包括若干子过程。质量管理需要同时实现宏观项目过程和微观子过程的质量控制。

　　产品开发项目质量管理过程模型如图4所示，在项目启动阶段，由企业领导和质量管理办公室进行质量控制。在计划阶段，项目经理制作各种项目计划(包括质量计划、进度计划和风险管理计划等)，由项目管理办公室审批。执行和控制阶段的质量控制在企业、PMO和项目3个层次上实现。

　　(1)项目经理组织实施项目级质量控制，对整个项目所有活动的质量负责;(2)PMO级质量控制是项目管理办公室对项目执行过程中的管理活动进行审查;(3)项目执行过程中的微观设计过程受控于企业质量管理系统，需要遵循企业标准运营过程，属于企业级质量控制。企业级质量控制还包括对项目重大问题、项目誊要进展的确认和审批。在项目完成阶段，项目管理办公室分析项目执行过程中产生的质量记录，完善参考项目过程模型，实现企业项目质量管理的持续改进。

　　图4 产品开发项目质量管理过程模基

　　4.4 信息模型

　　本文通过UML实体对象类图描述产品开发项目质量管理的信息模型。根据上述分析，可将系统中的对象类分成企业组织包、文档包、企业项目质量体系包和项目包。企业组织包用于企业质量管理系统的组织和管理职责定义，是组织模型的抽象，包括各个组织单元在企业质量体系中应承担的管理职责，人员隶属于组织单元。文档包对企业质量体系中的各种文档进行自动化管理，通过企业质量文档、项目管理文档、产品技术文档3个业务对象类来描述。企业项目质量体系包定义企业内部的参考项目过程型。每个参考过程模型适用于一种或多种项目类型。在参考项目过程模型中，须定义项目执行所需划分的阶段、每个阶段需要执行的质量活动及每个质量活动须提交的管理文档。项目包定义与特定项目质量管理相关的对象。质量计划业务对象类对质量计划进行抽象并关联过程模型类。质量计划中包含若干在项目执行过程中需要完成的质量活动，每个质量活动的执行都有相应的执行记录。项目的最终目标是设计或开发一种产品，在执行项目质量管理时，需要对产品分解结构的每个节点定义质量目标。本文通过质量目标对象类描述质量目标。产品开发项目质量管理信息模型如图5所示。

　　图5 产品开发项目质量管理信息模直

　　5 企业级产品开发项目质量管理系统

　　本文采用J2EE平台开发了一种企业级产品开发项目质量管理系统。系统分为企业质量管理、企业项目质量管理和项目质量管理3个子系统。其中企业质量管理子系统管理辅助质量管理部门维护企业范围内的质量文档和支持运营过程管理的工作流;企业项目质量管理子系统辅助项目管理办公室定义项目过程模型并控制企业范围内产品开发项目的项目质量;项目质量管理模块帮助项目经理定义项目质量计划和控制项目质量。系统采用3层C/S架构，在数据层，通过SOLSever2000数据库系统管理所有关系型数据，以MS IIS的FTP服务作为文件服务器集中管理企业质量文档;在业务层，使用weblogic8.1作为EJB容器，利用会话Bean实现系统功能模型和过程模型，采用实体BEAN实现系统信息模型;在表示层，利用Java Swing技术实现表示层的客户端应用。系统集成开源工作流系统Shark2.0实现了过程的自动化管理。本文系统对项目和运营过程的质量管理分别采用了不同的处理方式，在工作流系统或程序文档中规定运营过程的过程模型;对于产品开发项目的宏观过程，则通过企业项目质量管理模块和项目质量管理模块共同实现。

　　基于IS09000：2000的企业质量管理是面向过程的质量管理。其核心内容是识别和管理企业的内部过程。本文针对产品开发项目的特点，提出采用两步剪裁法定义实现基于IS09000：2000的项目过程，实现了产品开发项目的宏观项目过程和微观运营过程的综合质量管理。采用面向过程的方法对产品开发项目的质量过程实施信息化管理，能提升质量管理的效率和水平，促进企业范围内产品开发项目质量管理的持续改进。

　　复杂性

　　如何在恰当的细节和抽象层次上为复杂的事物建模?

　　沟通——设计元素

　　服务技术架构(Service Technology Architecture，后简称STA)的基础元件是什么?

　　执行——为成功而做调整

　　如何提升STA解决方案的速度和质量?

　　在Wik看来，最重要的事情是，要记住在处理实际问题时:

　　……我们必须承认，有些问题是不需要答案的，我们也无法弄清出所有事物的本质，因为思维和符号是有限的……我们必须面对高深莫测的未知。但是，我们只能在这迷一般的世界里行动，不过我们有框架的帮助。框架是蓝图，它指引我们想象、计划、开发、测试、部署并稳固我们的架构。

　　Wik认为，面向服务技术解决方案的两个最重要的框架是开放组织服务集成成熟度模型(OSIMM)和开放组织架构框架(TOGAF)。

　　OSIMM之所以重要，是因为它一个用于创建增量SOA实施路线图的流程，而且它清晰地定义了每个阶段的业务收益。此外，它还包含一个用来评估当前及未来的SOA成熟度的量化模型。至于TOGAF ，其企业架构框架有助于回答下列问题：如何构建可达成业务目标的系统?

　　接着，Wik介绍了STA设计的两个基本元素——原则和模式。他说：

　　原则是强制性标准……他们来自于常识及人们的共识。原则又是一个先验命题，可能合理但却无法证实……即便我们未能符合某个原则，或者我们忽略了它，它一样在那里。

　　谈及指导STA的主要原则时，Wik搬出了著名的《SOA设计原则》，其中包括服务松耦合、标准化服务契约、服务自治、服务无状态化以及服务可组合性等。Wik提醒，在使用这些原则时：

　　若基于这些原则的具体应用去搭建架构，而忽视了原则本身，这样的做法是不对的。因为，它会走向追逐技术和锁定技术的境地，而非向业务目标前进。

　　谈到设计模式时，Wik再一次力荐广为接受的《SOA设计原则》。

　　最后，在谈到为成功而做调整时，Wik建议使用敏捷开发的每天的scrum改进责任划分和沟通;通过XP的结对编程改进质量和速度。他断言这些都是根本要素，因为它们支撑着那些引领STA走向成功的高层原则，如透明性、沟通、质量和速度等。

　　Wik在文章末尾说道：

　　面向服务的技术的根本是，简化系统以符合企业目标;简化流程以实现目标。我们不反对人们花精力去掌握那些有助于实施STA的工具，但是，为了实现目标，可能需要我们放弃一些旧工具。TOGAF、UML和敏捷/XP是很好的工具，然而有时候我们需要扔掉这些工具才能正确地看待这满世界的服务。

　　尽管本文不乏许多有趣的观点，但是有些想法却令人迷惑。首先，Wik为何弃用“SOA”而采用“SOT”就未交代清楚。而SOT这一词汇通常指那些诸如Web Services或SCA之类的东西，即能够简化SOA实施的技术，可是Wik把它与SOA混用。事实上，本文中的大多数引用、原则和模式都借用自SOA。再者，文中很大篇幅在关注业务目标和业务驱动力。从前，技术的主要驱动力不是它们，而是实现的简单性。

　　另一个问题来自本文的标题，我们通常无法架构技术，而是使用技术。所以，对技术的架构的含义也不是一下子就能理解的。

　　最后，尽管诸如敏捷、XP和社交工程在软件开发中都非常重要，这些东西如何直接应用于架构也不是那么显而易见。尽管有无数的出版物讨论这一话题，但这仍然没有定论。

　　此文在英文站一经发布，即引来了众多读者的回应，现摘录几篇评论以飨各位：

　　读者Roopesh Shenoy说到：

　　在我看来，这听起来像是把简单问题复杂化，可是根本不需要这么复杂。我一直认为，架构师使用OSIMM、TOGAF或其他框架就如同开发经理们执着于使用成熟的技术(如java)一样——没有人会因为使用这样的技术而被解雇。其实，我们可以从优秀的实践中学到更好的东西，比如Amazon的整个AWS基础设施。

　　读者Konstantin Ignatyev说到:

　　本文再次对IT做了错误的假设：

　　指导原则：“正确地做事”

　　目标：创新和质量

　　优势：视野和纪律

　　对于极少数IT人来说的确是这样的，但是对于大多数人来说并非这么回事。据统计，人们习惯于安于“现状”——现状会使他们感到舒服。IT比业务更抵制创新的原因也是如此。所以，使用TOGAF或其他框架的目的不仅是创造一份安定的工作，而且其真正意图是让IT变成一个受人尊敬的职业(如医生和建筑师)，有一组原则可教化从业者，使他们忠于工作，使业务人员不再因为要求走捷径和其他傻事而自毁前程。

　　本新闻编辑Boris Lublinsky认为IT是令人尊敬的工作，他回复到：

　　暂不论我是否赞同本文作者Wik的话，但是我认为IT是值得尊敬的职业，所以我现在我已经干了25年了。而且，我也相信使用合适的框架的确是件好事。 IT业中令人痛苦的一件事情是，“我比别人更懂”的态度往往导致人们一次又一次地打着“新技术”和“新方法”的旗号重复着20年前曾经犯过的错误。

　　Konstantin Ignatyev这么回复Boris Lublinsky：

　　只有当以下现象成立时，我才认为IT是一个令人尊敬的行业：

　　1. 不再出现《傻瓜式HTML》或《24小时速成c++》之类的书籍时。你见过《24小时速成外科医生》和《一星期成为摩天大楼设计师》之类的书吗?

　　2. 客户会日常地地要求底层实现和架构应该做成什么样。

　　3. IT能够为“近乎标准”的应用程序设定可预见的时间表;不再花几个月的时间完成只需数周就能完成的项目。

　　Roopesh Shenoy发表了他对Konstantin Ignatyev的不同看法：

　　我有点儿不太同意你的看法：

　　《傻瓜式HTML》类似于介绍消化系统和呼吸系统的解剖方面的少儿书。它指引孩子们在成长为医生的路上迈出第一步，同理，这样的书能带领新手们走出变成IT专家的第一步。#p#分页标题#e#

　　我不太理解你第二句话的含义，但是我猜测你所说的是客户干预太多。可这几乎是每个行业都要面临的问题。

　　大多数有价值的项目都是非标准的应用。项目的开销和价值本就不成比例，而且是复杂且难以预测的。

　　我的确同意，即便是小项目，它走向失败也可能是正常的而不是意外，但这并不意味着每个与之相关的人都有错——巨大的需求导致有新人不断地加入，不断地学习。如果有东西能够证明变得优秀不是那么容易的事，那也就意味着这是一个值得尊敬的职业。

　　当然，成为开发者并不需要像医生那样需要多年的医学院学习和住院医的过程。但这也不是生死相关的行业，不是么?

　　不管是TDD也好，传统的开发也好，肯定要先做设计，设计展开后如果采用普通方法做开发，那就是开始写代码，然后单元测试，集成测试等工作。如果用TDD，那就要先从设计中把测试列表(其实就是要实现的功能，人机交互的条目罗列出来，形成一个列表)整理出来。然后就开始开发，在TDD中，“红-绿-重构”的过程很多说明TDD的文章都要说到，本篇也不例外。

　　有了测试列后，先拿出一个条目，进行测试的开发，开发完成运行，因为被测的程序还没有编写肯定是失败的，然后实现程序，再测，可能还失败，改成，测试成功，然后重构来优化代码，再进入下一个测试条目的循环。

　　在.net平台下，怎么去实现呢?

　　本例中用VS2010行进说明，设计部分，可以用vs2010的新功能Modeling，在Modeling里，可以画类图，还可以添加其中的成员，包括返回值类型，参数个数和类型，有了这些方法的签名，对我们先构建测试就提供了依据，对测试程序来说，不关心实现的细节，只用知道参数是什么，返回是什么，拿上这个方法的返回值与给定的返回值作对比，从而来确定方法实现的功能是否正确。在Visual Studio中，可以很方便的来自动创建单元测试，这些方便要归功于“反射”这个技术。当然，一般而然，测试不是只有一个数据，可能要一系列数据，或者更多的数据，在.net平台下，也提供了相应的功能。

　　下面来做个DEMO说明一下。

　　先看一个类图，也可以把类中的主要功能，当成一个个条目添加到测试列表中。

　　我们选一个条目——GetRecord，参数是一个ID的整型，返回值是一个逻辑类型，本方法用来实现在一个库中查询输入的ID，看是否存在。

　　根据类图，可以在类库项目中生成一个类，如下

　　接下来，可以继于这个方法，来自动创建一个单元测试，右键方法，创建测试。

　　一个测试的项目就会自动创建进来，在生成的CS文件中，重点看如下代码(关于单元测试的其他知识可参照http://msdn.microsoft.com/zh-cn/library/ms182515(VS.80).aspx)

　　在这里，测试的用例只有一个id=0，返回值为false，现在测试，肯定通不过，因为被测的方法还没有实现。此时叫做“红”。

　　接下来就要实现GetRecord方法。

　　新建一个类库项目，然后添加一个LINQ To SQL的子项，把下表拖放进LINQ To SQL面板。

　　数据表结构

　　数据表中数据

　　然后在类库的CS文件中，添加入下代码：

　　当然测试是不关心我们用什么技术实现方法的，它只关系输入和输出。

　　这时我们再运行测试，会发现测试通过了，这时我们叫做“绿”。

　　可能有的人发现，在这个测试中，只能测一个数据，没有代表性，如果要测多个数据，还得一个一个换id值和expected值。是的，这是一个头痛的事，得想们办法来解决。

　　正好，微软有提供数据驱动的单元测试，什么意思呢?就是可以把id和expected的值保存在数据源中，然后批量测试。如果全通过说明这个方法实现的没问题，如果有错，也可以针对性的能找出什么数据使GetRecord方法报错的。这个东西很不错。

　　首先来构建一个数据源，XML是个不错的选择，新建一个RecordExistTestCase.xml文档，内容如下

　　当然你还可以添加你以为好的测试用例。

　　再改造一下测试方法

　　OK，现在就要以用上面xml里的数据来批量测试了。

　　测试通过来，接下来就要程序员来整理一下自写的代码了，比如书写规范问题，方法是否冗余重复，注释是否完善等。也就是所说的重构了。

　　到此，一个TDD cycle就完成了，现实的cycle可能更复杂，这里只是对单个测试条目单个方法进行说明的。

　　TDD更适合在敏捷的开发中去用，比如XP，虽然scrum是侧重管理和组织，也能很好的溶入TDD。

　　本人在企业从事SQA工作，同时兼任SEPG的工作进行基于CMM3的过程改进，在实践过程中，对SQA的工作有了较多的想法和认识。本文是个人看法，请大家指教，如果要和本人联系，请发Email到：heqingemail@163.net。

　　二、SQA的理论探索

　　2.1、过程的 认识

　　我们都知道一个项目的主要内容是：成本、进度、质量;良好的项目管理就是综合三方面的因素，平衡三方面的目标，最终依照目标完成任务。项目的这三个方面是相互制约和影响的，有时对这三方面的平衡策略甚至成为一个企业级的要求，决定了企业的行为，我们知道IBM的软件是以质量为最重要目标的，而微软的“足够好的软件”策略更是耳熟能详，这些质量目标其实立足于企业的战略目标。所以用于进行质量保证的SQA工作也应当立足于企业的战略目标，从这个角度思考SQA，形成对SQA的理论认识。

　　软件界已经达成共识的：影响软件项目进度、成本、质量的因素主要是“人、过程、技术”。首先要明确的是这三个因素中，人是第一位的。

　　现在许多实施CMM的人员沉溺于CMM的理论过于强调“过程”，这是很危险的倾向。这个思想倾向在国外受到了猛烈抨击，从某种意义上各种敏捷过程方法的提出就是对强调过程的一种反思。 “XP”中的一个思想“人比过程更重要” 是值得我们思考的。我个人的意见在进行过程改进中坚持“以人为本”，强调过程和人的和谐。

　　根据现代软件工程对众多失败项目的调查，发现管理是项目失败的主要原因。这个事实的重要性在于说明了“要保证项目不失败，我们应当更加关注管理”，注意这个事实没有说明另外一个问题“良好的管理可以保证项目的成功”。现在很多人基于一种粗糙的逻辑，从一个事实反推到的这个结论，在逻辑上是错误的，这种错误形成了更加错误的做法，这点在SQA的理解上是体现较深。

　　如果我们考证一下历史的沿革，应当更加容易理解CMM的本质。CMM首先是作为一个“评估标准”出现的，主要评估的是美国国防部供应商保证质量的能力。CMM关注的软件生产有如下特点：

　　质量重要

　　规模较大

　　这是CMM产生的原因。它引入了“全面质量管理”的思想，尤其侧重了“全面质量管理”中的“过程方法”，并且引入了“统计过程控制”的方法。可以说这两个思想是CMM背后的基础。

　　上面这些内容形成了我对软件过程地位、价值的基本理解;在这个基础上我们可以引申讨论SQA。

　　2.2、生产线的隐喻

　　如果将一个软件生产类比于一个工厂的生产。那么生产线就是过程，产品按照生产线的规定过程进行生产。SQA的职责就是保证过程的执行，也就是保证生产线的正常执行。

　　抽象出管理体系模型的如下，这个模型说明了一个过程体系至少应当包含“决策、执行、反馈”三个重要方面。

　　QA的职责就是确保过程的有效执行，监督项目按照过程进行项目活动;它不负责监管产品的质量，不负责向管理层提供项目的情况，不负责代表管理层进行管理，只是代表管理层来保证过程的执行。

　　2.3、SQA和其他工作的组合

　　在很多企业中，将SQA的工作和QC、SEPG、组织级的项目管理者的工作混合在一起了，有时甚至更加注重其他方面的工作而没有做好SQA的本职工作。

　　根据hjhza 的意见“中国现在基本有三种QA(按照工作重点不同来分)：一是过程改进型，一是配置管理型，一是测试型”。我个人认为是因为SQA工作和其他不同工作组合在一起形成的。

　　下面根据本人经验对它们之间的关系进行一个说明。

　　2.4、QA和QC

　　两者基本职责

　　QC：检验产品的质量，保证产品符合客户的需求;是产品质量检查者;

　　QA：审计过程的质量，保证过程被正确执行;是过程质量审计者;

　　注意区别检查和审计的不同

　　检查：就是我们常说的找茬，是挑毛病的;

　　审计：来确认项目按照要求进行的证据;仔细看看CMM中各个KPA中SQA的检查采用的术语大量用到了“证实”，审计的内容主要是过程的;对照CMM看一下项目经理和高级管理者的审查内容，他们更加关注具体内容。

　　对照上面的管理体系模型，QC进行质量控制，向管理层反馈质量信息;QA则确保QC按照过程进行质量控制活动，按照过程将检查结果向管理层汇报。这就是QA和QC工作的关系。

　　在这样的分工原则下，QA只要检查项目按照过程进行了某项活动没有，产出了某个产品没有;而QC来检查产品是否符合质量要求。

　　如果企业原来具有QC人员并且QA人员配备不足，可以先确定由QC兼任QA工作。但是只能是暂时的，独立的QA人员应当具备，因为QC工作也是要遵循过程要求的，也是要被审计过程的，这种混合情况，难以保证QC工作的过程质量。

　　2.5、QA和SEPG

　　两者基本职责

　　SEPG：制定过程，实施过程改进;

　　QA： 确保过程被正确执行

　　SEPG应当提供过程上的指导，帮助项目组制定项目过程，帮助项目组进行策划;从而帮助项目组有效的工作，有效的执行过程。如果项目和QA对过程的理解发生争持，SEPG作为最终仲裁者。为了进行有效过程改进，SEPG必须分析项目的数据。

　　QA本也要进行过程规范，那么所有QA中最有经验、最有能力的QA可以参加SEPG，但是要注意这两者的区别。

　　如果企业的SEPG人员具有较为深厚的开发背景，可以兼任SQA工作，这样利于过程的不断改进;但是由于立法、执法集于一身也容易造成SQA过于强势，影响项目的独立性。

　　管理过程比较成熟的企业，因为企业的文化和管理机制已经健全，SQA职责范围的工作较少，往往只是针对具体项目制定明确重点的SQA计划，这样SQA的审计工作会大大减少，从而可以同时审计较多项目。

　　另一方面，由于分工的细致化，管理体系的复杂化，往往需要专职的SEPG人员，这些人员要求了解企业的所有管理过程和运作情况，在这个基础上才能统筹全局的进行过程改进，这时了解全局的SQA人员就是专职SEPG的主要人选;这些SQA人员将逐渐的转化为SEPG人员，并且更加了解管理知识，而SQA工作渐渐成为他们的兼职工作。

　　这种情况在许多CMM5企业比较多见，往往有时看不见SQA人员在项目组出现或者很少出现，这种SEPG和SQA的融合特别有利于组织的过程改进工作。SEPG确定过程改进内容，SQA计划重点反映这些改进内容，从保证有效的改进，特别有利于达到CMM5的要求。从这个角度，国外的SQA人员为什么高薪就不难理解了，也决定了当前中国SQA人员比较被轻视的原因;因为管理过程还不完善，我们的SQA人员还没有产生这么大的价值嘛!

　　2.6、QA和组织级的监督管理

　　有的企业为了更好的监督管理项目，建立了一个角色，我取名为“组织级的监督管理者”，他们的职责是对所有项目进行统一的跟踪、监督、适当的管理，来保证管理层对所有项目的可视性、可管理性。

　　为了有效管理项目，“组织级的监督管理者”必须分析项目的数据。

　　他们的职责对照上图的模型，就是执行“反馈”职能。

　　QA本身不进行反馈工作，最多对过程执行情况的信息进行反馈。

　　SQA职责最好不要和“组织级的项目管理者”的职责混合在一起，否则容易出现SAQ困境：一方面SQA不能准确定位自己的工作，另一方面过程执行者对SQA人员抱有较大戒心。

　　如果建立了较好的管理过程，那么就会增强项目的可视性，从而保证企业对所有项目的较好管理;而QA来确保这个管理过程的运行。

　　三、SQA的工作内容和工作方法

　　3.1、 计划

　　针对具体项目制定SQA计划，确保项目组正确执行过程。制定SQA计划应当注意如下几点：

　　有重点：依据企业目标以及项目情况确定审计的重点

　　明确审计内容：明确审计哪些活动，那些产品

　　明确审计方式：确定怎样进行审计

　　明确审计结果报告的规则：审计的结果报告给谁

　　3.2、审计/证实

　　依据SQA计划进行SQA审计工作，按照规则发布审计结果报告。

　　注意审计一定要有项目组人员陪同，不能搞突然袭击。双方要开诚布公，坦诚相对。

　　审计的内容：是否按照过程要求执行了相应活动，是否按照过程要求产生了相应产品。

　　3.3、问题跟踪

　　对审计中发现的问题，要求项目组改进，并跟进直到解决。

　　四、SQA的素质

　　过程为中心：应当站在过程的角度来考虑问题，只要保证了过程，QA就尽到了责任。

　　服务精神：为项目组服务，帮助项目组确保正确执行过程

　　了解过程：深刻了解企业的工程，并具有一定的过程管理理论知识

　　了解开发：对开发工作的基本情况了解，能够理解项目的活动

　　沟通技巧：善于沟通，能够营造良好的气氛，避免审计活动成为一种找茬活动。

　　“我们的单元测试用例要半个小时才能跑完，”他说。

　　“你们这不是在做驱动测试开发，”我说。“为了让测试发挥效能，所有的测试必须在几秒钟内能跑完，否则的话，程序员不得不频繁的停下来等待测试。”

　　“可是怎样才能让它们快起来?”他问，“光连接数据库就需要30秒”

　　于是，我想他展示了一种叫做依赖注入的技术，它能让你使用一个伪造对象来模拟数据库。“你并不需要测试你数据库，”我说。“记住，测试应该是测试那些不受控制的东西，对于测试所依赖的东西，你应该使用模拟工具使它们处于控制之中。”

　　他们遇到的另外一个问题 —— 我最近也是听到了很多次 —— 是他们的测试程序不但没起到好的作用，反而成了一个负担。“我们三天两头的要重构程序，关联的就需要重构测试程序”，这样的话从客户那里可以经常听到。

　　这种问题是他们把TDD想成了QA。TDD不是QA。QA是来保证程序能正确的运行的。TDD是使用断言(assertion)来表现系统的关键特征。在QA里，我们用尽可能多的方法来测试系统中可能会出错的地方。在TDD里，我们用应尽可能少的测试来表现系统的关键特征。

　　我遇到的大多数开发人员都很重视代码质量，努力写出高质量的代码，程序看起来很整洁。但测试用程序也是程序，经常的我能看到测试程序就写的不是那么好。

　　例如，一些程序员会很认真的把产品程序里的冗余部分清理干净，但在测试程序中却留下大量的无用的代码。任何冗余都不是好事，冗余的测试也是如此，如果程序有变化，冗余的测试会花掉你额外的时间去重构。

　　当系统出问题时，测试程序就体现出来了它最大的价值，至少对我来说是最欣慰的时候。然而，对于系统，任何一个改动只应会让一个测试失败。换句话说，没有任何两个测试的失败原因是相同的。这说起来容易做起来难，但如果你尊重这个原则，你将会发现，当你重构代码时，重构测试程序是会容易多了。

　　目前就说这些问题。总之，测试也是程序，它们也要保持高质量。系统中的每个关键特征都用一个测试来表现，没有第二个测试会因为这同一个问题而失败。

　　2008年9月，我所在公司成功中标A地级市某委办局项目，项目金额约600万左右，是我们公司成立以来实施的最大项目。为了迎接国家某部委、省委的检查，客户要求于2008年年底前建设完成，实施时间要求非常短。对于此项目，由于之前没有这方面的实施经验，对业务需求的理解不是很明确，技术上我们具备实施此项目的能力。

　　作为项目实施核心人员之一，我有幸参与了此项目，我们于2008年9月29号进驻项目现场，就开始了紧张而又忙碌的实施工作，加班加点自是必不可少，每天晚上都要忙碌到第二天凌晨，工作强度之大可想而知。在高强度的工作环境下，容易出现问题，某一天，我们项目一位同事将数据库的数据表与数据全都删除了，在现在看来这或许不是一件什么较严重的问题，但是在当时环境下，是一件相当严重的问题。由于缺乏相关数据恢复经验，然后又因为担心被领导批评，我们项目组的这位同事做了一系列相关恢复操作，很遗憾的是这些恢复操作都是错误的，根本达不到恢复数据的目的，导致的结果是误删的数据彻底地被删除了。问题越来越麻烦，当我们意识到问题的严重性后，时间已经是晚上11点左右，明天客户一线操作人员还需要通过系统来采集录入相关数据，如果发现今天录入的数据不存在，抱怨、抵触的情形肯定会发生，我们能够想象得到明天客户面对此事的情形。

　　在这时，主管负责这个项目的副总作了以下几项决议：

　　1、将数据恢复到昨天备份，这样损失的只是今天录入的数据;

　　2、制定数据录入人员录入损件数据的补偿方案;

　　3、马上与客户负责人进行沟通，汇报和协商此事情，争取客户负责人的支持;

　　4、完善数据备份、恢复、管理、操作机制，避免类似问题发生;

　　经过有效沟通，事情后来也是比较顺利解决了，可是这一段经历依如昨日所发生一样，仍然历历在目，不能忘怀。我想最关键的因素是我们副总处理这件事情的方法，有值得我学习的地方。而让我最不能忘怀的是面对问题发生时，我们副总并没有对事故责任人在言辞上有一句批评，甚至在行为表达方式上也让人感觉不到因他而带来的更大压力，而是很冷静地和我们一起讨论解决方法，协调相关资源，调和项目组内工作氛围和成员心情，使事故损失降低到最低。

　　后来针对这件事情，我又总结了一些解决办法，我想能很好地解决类似这样的问题。具体如下：

　　1、项目实施前，需做好风险预防机制，即如何避免此类事情的发生，如果在项目实施前做好了相关预防机制，并对组内成员进行了相关培训，我想这样的事情有80%的概率能够完全避免;

　　2、同时需要做好风险应对解决方案，例如在项目实施前针对数据错误删除，如何恢复，如果作了相应的解决方案，完全不会造成如上的被动局面。

　　3、做好相关安全与备份处理机制;

　　4、问题发生时，批评不是好办法，如果从管理角度来分析原因，最大的责任应该是管理者本身;

　　5、在理解的基础上，团结团队成员，争取将损失减少到最低;

　　6、如果因问题而带来的损失不能避免，拿出解决方案，与客户坦承沟通，争取客户负责人的支持。

　　初始(Inception)阶段：管理业务风险

　　精化(Elaboration)阶段：管理技术风险

　　构建(Construction)阶段：管理进度风险

　　产品化(Transition)阶段：管理可接受的风险

　　测试、编码、迭代，和量度

　　总结：摇尾巴的狗是好狗

　　注释

　　本文来自于 Rational Edge：在对软件迭代开发生命周期中的测试人员的作用进行探讨的同时，作者考虑，除了 RUP 测试规程中提供的描述，测试人员还能如何对项目做出广泛的贡献。

　　从测试工程师那里听到的最普遍的抱怨是直到过程中很晚的时候才能有效地参与到软件开发项目中。此外，测试通常是在开发人员在抗争损坏一个接一个版本候选的很晚出现的缺陷时所逼出的行为。到一个合适的候选版本出现的时候，测试人员已经成为瓶颈，显然，要对进一步的延迟负责。

　　Rational Unified Process?，或 RUP?，广泛地概括了测试规程(Test Discipline)，并介绍了测试角色如何及早地参与项目生命周期。

　　我希望在本文中介绍另一种观点。代替由测试规程开始，我将依次考虑每个 RUP 阶段的风险管理原则，并询问经验丰富的测试人员，为了促进那些目标他们可能会做些什么。虽然测试工程师不能估算总的项目成本，但是他们的确可以评估对成本的测试贡献，并且提出测试风险和可行性。虽然他们不应该计划解决方案架构，但是他们可以帮忙度量。虽然测试人员不构建一系列可执行程序，但是他们可以评估每个可执行程序如何表示一个从前一个而来的进展。虽然测试人员不构建最终的候选版本，但是他们可以确保具有可接受的质量。

　　我相信在 RUP 的每个阶段，测试人员都有机会对项目做出大量贡献。该贡献远远地扩展了，例如，要求更早地测试交付内容 —— 或者更早地执行一组标准的测试 —— 比传统的瀑布驱动过程中。本文应作为面向开发团队中的测试人员的 RUP 原则的激励说明来阅读。它不应该作为 RUP 测试规程的概要或初级读物。虽然我相信许多测试人员会觉得该信息很有用，但是我还相信管理人员将会对看到测试人员的能力和经验如何在 RUP 项目的所有阶段中更有效地应用感兴趣。

　　初始(Inception)阶段：管理业务风险

　　RUP 的初始阶段是对准业务风险的管理。为了制定出自该阶段的可行或不可行的决策，我们需要了解

　　待解决问题的性质。

　　解决方案的价值，不论是就节约或收益而言，还是以一些其他的业务价值，如质量或时间性而言。

　　潜在的解决方案，因此我们至少知道问题是可解决的。

　　对解决方案的粗略成本估算。

　　危害解决方案的风险。

　　带着此信息，涉众被聚集到生命周期目标(Lifecycle Objectives，LCO)会议上。如果项目被视为是可行且值得做的，那么项目会继续进入精化阶段。

　　评估成本

　　可行性和成本是 LCO 会议上的重要因素，并且测试人员无疑可以为该决策贡献重要的数据。测试人员可以估算对成本的测试贡献，甚至有时候可以有助于可行性问题。记住，在初始阶段中，尽管我们只对球场的数字感兴趣。过高的精确度将给我们带来不真实精确度的不适当安全感。

　　也许有或也许没有实际的可执行程序作为 LCO 简报的一部分。这些可能由技术示范者、现有产品的快速出租，或者也许是更实质的东西组成。我的意见是在如此初步的阶段执行如此正式的操作是不适当的。

　　因为测试成本对总的开发成本做出贡献，所以我已经列出许多对测试成本做出贡献的行为。

　　测试风险

　　风险需要减轻计划，减轻风险需要花费金钱。测试风险是各种各样的。例如，需求可能迅速地变更，这可能会破坏可测试性或测试成本设想。后继的精化阶段可能会利用新的测试难点的解决方案来解决技术风险。可能需要遵守 MC/DC(Modified Condition/Decision Coverage)测试、ISO 标准、SEI 标准，IEEE 标准，等等这样的标准。 1 这些标准可以减少整个业务成本，但是顺应成本在某种程度上落在测试人员上，并且应该更加明显。可能存在与数据安全相关的政府规章，如保密性规章，使对“真实”数据的测试变得困难或昂贵。

　　可测试性

　　可测试性与可行性直接相关，并且很可能找到很难测试的高层次需求。一些需求是非可测试的，因为他们是主观的，或者不是有助于度量或量度的。一些是不可测试的，因为从技术上很难安排一个合适的测试。例如，一些战略防御计划(Strategic Defense Initiative，SDI)的批评家提到在美国执行其导弹防御的可接受性测试时，让苏联启动非武装的洲际弹道导弹(Intercontinental Ballistic Missile，ICBM)的困难。在软件开发项目中，这种情况发生于格外昂贵的硬件不能为了测试很容易地重新执行任务的时候，或者当独特的环境因素使测试的安排变得困难时。

　　准备测试实验室

　　通过“实验室”，我的意思是一个环境，在其中有我们测试每个需求所需要的东西，一个被提供但与产品环境有很难区分的不同。即使我们在早期的需求发现阶段，仍有可能估算您很可能需要的资源。

　　资源可能包括 1) 硬件、计算机、网络，以及由慢速管道或很长的往返传递，及防火墙所引起的瓶颈，2) 软件，包括测软件及其他必需或采用的软件，所有的都处于已知版本层(或根据所有版本进行测试!)，3) 测试软件，如测试经理，测试自动化软件，如记录或回放 GUI 测试人员，以及用于可伸缩测试的用户虚拟化，4) 数据，包括用于冒烟测试和功能测试的小型数据集，以及用于可伸缩性测试的大型数据集。

　　注意到尽管潜在的实验室特性的列表很长，我们还必须在存在相应的实际需求的地方指定实验室需求。例如，不是所有的系统都有可伸缩性需求，所以不是所有的实验室都将需要用户虚拟化工具。

　　估算需求或场景的整体测试成本

　　大多数需求将作为普通的功能需求出现。与测试相关的成本通常与编码或设计的成本大致成比例，因此测试工作一般来说将是编码和设计成本的某个比例(比方说 25%)。此系数将具体到每个组织，并且可以通过收集一两个项目量度按经验寻找。#p#分页标题#e#

　　系数将被平台的数量或所需的其他类型的测试工作副本所修改。

　　缺陷管理、构建，发布过程

　　存在与将测试人员插入开发过程中有关的成本。测试人员共享其他项目团队使用的特定开发工具，如用于缺陷跟踪的工具，以及构建和发布工具，如用于配置管理的工具。

　　精化(Elaboration)阶段：管理技术风险

　　RUP 的精化阶段是对准技术风险的管理的。为了制定出自该阶段的可行或不可行的决策，我们需要论证一个对每个鉴别出的技术风险的满意解决方案。通常，最糟的技术问题由非功能需求导致。非功能需求可以造成这样的有趣断言“系统将拥有 99.999% 的可用性，”或者“系统将支持 10,000 个同时发生的用户会话。”这些需求写起来便宜，但满足和测试起来昂贵。为了进行适当的评估，我们需要了解：

　　在完成极端的非功能目标中可能隐含的权衡。

　　当接近这些极限时各种架构退化的方式。

　　有了此数据，架构师可以选择最适当的架构，并且，当涉众面对他们需求的所有含意时，通常会更愿意调节他们的雄心，并且得到更多的回报。

　　因此，关键的评估需求是其中一个度量，并且这应该是此阶段测试人员主要的目标。

　　量度方法的评估

　　对于每个技术问题，架构团队将建立一个或多个具体表现一个解决方案方法的可执行系统。可能会有若干有竞争的解决方案(举例来说，通信中的 UDP 对 TCP)和大量的对于每个解决方案的可配置选择(举例来说，进程架构中的 10 线程 对 50 个线程)。测试人员执行对生成架构的度量所必需的步骤。

　　度量强调的是是否对解决方案有了成熟的考虑而不是功能是否被正确的实现了，因为没有人会期望生命周期中早期就实现完全正确的功能或者甚至花费大量的精力去雕琢还不成熟的系统的功能。初始阶段中指定的许多实验室环境将在精化阶段中被需要。我们将度量性能和可伸缩性，跨过通信链接和出自数据库的数据速率，随负载变化时的响应时间，并且我们将生成需求所要求的其他度量。根据所有的架构原型执行这些测试，并且测试团队将与架构师携手工作，共同设计确认或驳斥每个设计决策的测试。

　　当传统测试人员可能会参与整个基于文档的活动时，测试团队在此阶段的行为与瀑布过程中所做的惊人地不同。当项目从一个危机牵绊到下一个时，许多工作都不相关了。相反，在迭代的项目的精化阶段，测试人员在起劲的行动着，被闪光灯和不停的拨号所围绕。测试人员赞成相关的且实际的测试，使它们与架构师保持一致，并且评估并解释结果。

　　当然这是富有挑战的工作，但同时还是要大量参与的、有价值的，并令人满意的。如果对于小型的团队环境及上千行的代码的情况建立这些测试都是棘手的，那么设想一下对上百万行的代码项目的大型团队来说所受到的阻碍。

　　虽然这个阶段执行测试设计和实现，但是我们应该记住，重要的是测试结果而不是测试文档。由于将会抛弃许多架构的提议，所以相关的测试也一样。我们仅需要做足够的测试设计和实现，用以获得必需的度量。我们不像细化提议那样做太多测试，随着最主要的架构候选的出现，我们可以添加严密，如可溯性和其他文档。

　　测试设计

　　作为并行活动，精化阶段表现出一次方便的时机来考虑技术架构中的小变更如何能够更好的帮助测试设计和测试自动化。

　　通过测试自动化，我的意思是使用记录键盘和鼠标事件的 GUI 记录或回放工具，可以回放来重复测试。经验丰富的测试人员知道自动化尤其要求重要的脚本维护工作。值得考虑一下允许脚本构造的“测试架构”，这与设计人员创建“软件架构”来简化应用程序构造具有同样意义。

　　测试人员应该考虑解决方案，特别是测试可能参数化的方法或映射到需求所暗示的“组合爆炸”的结合方法的复杂性维度。例如，考虑一个指定某个需要支持的平台组合的非功能需求。根据一个平台撰写脚本，在所有平台上“回放”是有利的。这同样可以应用到数据库后端、应用程序服务器、Web 服务器和环境基础架构的其他元素，并且特别是对于这些的排列组合。手动测试每个组合将是不能忍受的痛苦。测试自动化是唯一经济的解决方案。

　　大多数应用程序为测试人员的专长提供许多应用程序专用的机会。设计人员将找到“用参数表示”问题领域的方法，并且这些经常成为类似地用参数表示测试所沿着的维度。例如，在我所工作过的一个应用程序中，有许多看起来一样的屏幕上的表格，因此设计人员将列参数化为通用的小部件，这给予测试人员类似的能力来用参数表示它们的测试。

　　针对测试的设计在精化阶段如此重要的一个原因是在构建阶段很难找出时间来适当处理这一活动。但是有一个甚至更好的理由：通过测试人员和设计人员之间的良好对话，架构中的小让步可以给测试设计添加一个大好处。总而言之，精化阶段是针对测试而设计的适当时机。

　　构建(Construction)阶段：管理进度风险

　　RUP 的构建阶段瞄准进度风险的管理。如果应用了 RUP 首选的基于用例的方法，就可以比利用传统的(瀑布)方法更快地集中于可用的(尽管不完全)系统。当达到这一可用地不完全层次，剩下的路也就不远了。

　　该方法生成了一系列客观的改进的可执行系统，并且拥有重要的优势：

　　在尽可能最早的时候给客户展示系统的功能。

　　团队可以及早地获得部署经验。生成的可执行系统可以转化为产品化阶段的子集(部分部署)。这使我们获得产品化阶段问题的经验 —— 例如，验收测试所需要的是什么，如何为部署而打包，以及一百个其他的问题(参见下面的产品化阶段)。

　　我们收集量度，这使得在迭代开发中可以立即看到项目进展。在瀑布过程中，不太可能直接比较分析活动量度和设计活动量度或编码活动量度，因为它们是完全不同的活动。但在迭代过程中，比较迭代 1 的量度与迭代 2 的量度更加容易，因为我们在重复同一组活动。

　　在几个星期内，我们就会完成一个分析——设计——编码——测试的周期，这个给我们一种明显进展的感觉。这就是构建阶段的迭代的独特之处。测试活动评估进展并验证确实有了进展。#p#分页标题#e#

　　评估进展

　　RUP 提到的迭代节奏到构建阶段还是活跃着的，并且该频率与测试人员有特别的关系。测试人员的主要目标是能够客观地描述系统的当前状态，并且能够将该状态与以前的状态进行比较。这两个状态之间的区别，简单地说，就是进展。

　　测试人员的“节奏”源于以下活动。

　　测试设计和实现

　　测试人员的一项主要任务是测试脚本的设计和实现。在迭代开发中，这是由为当前迭代安排的场景所驱动的。测试脚本必须开发成能够将应用程序推到正确的“屏幕”或其他应用程序模式。测试数据必须开发成可以在此处执行应用程序，并且验证必须设计成可以核对应用程序的行为。

　　如果使用了自动化的测试工具，那么此时会提出某种考虑，关于该测试用例是否是好的自动化候选或者是否应该手动执行。

　　测试执行

　　执行测试来确定每个验证点的通过或失败状态。执行手动测试意味着有方法地遵守测试实现提示并适当地观察和注意结果。

　　执行自动化的测试意味着安排正确的系统初始条件，然后调用脚本回放工具。在控制初始条件时，我们希望管理测试过程中什么数据处于什么状态。该需求也适用于手动测试，区别在于测试人员可以“照顾”交互并且经常让测试不工作来工作于未初始化的开始条件周围。

　　回归和测试脚本维护

　　迭代开发的一个明确的任务是需要为每个新的迭代再次运行旧的测试。这种对现有测试集的重复执行称为回归测试，是一个显露出自动化测试的好处和负担的活动。好处：因为另一种是手动测试，很明显的耗费时间的活动。负担：因为自动化的脚本经常需要仔细的修改来服务于下一个构建。测试脚本维护，和脚本回放调试器，对测试人员来说将会是非常熟悉的。测试人员将会及早并且使用减少脚本退化的测试工具，了解如何减少维护工作。

　　缺陷跟踪和分辨

　　缺陷跟踪和分辨活动是测试人员都知道的。测试行为总是揭示缺陷或问题，并且必须勤奋地跟踪每个事故来进行分辨。首先，分辨通常需要在实验室中复制的错误，但至少是处于这个原因，即 SEI Capability Maturity Model Integration (CMMI) 要求项目团队实现配置管理以达到有威信的“可重复级别, 级别 2”。只有通过将所有开发文件置于该控制下，并且用材料清单描述每个构建，开发人员才可能有许多机会重复所有已知的事件并因此能够满足该标准。

　　为了提高项目角色之间缺陷信息的共享，用开发人员使用的同样的配置管理和缺陷跟踪环境来装备测试人员是合理的。

　　针对进展的量度

　　我们已经回顾了测试人员在构建阶段所做的事情。我们如何将其转化为进展的量度呢?有多种描述恰当的技术， 3 以下的处理是可以借鉴的。

　　完成百分比

　　度量进展的一个过分简单但特别实际的方法是利用“完成百分比”作为量度。如果有人考虑通过测试的场景的流程，我们可以考虑构造一组检查点，表 1 中所显示的一个实例。

　　我们确定表 1 中每个场景和测试中所描述的每个检查点。不论完成或是没完成，它们的值都严格地报告为是或不是的值。我们合计每一层并将其表示为前一个层的某个百分比。目标是达到每一层的 100% 覆盖。总的结果相当粗略，但针对达到最高百分比的工作带来了提前测试工作的非常有意义的副加作用。

　　缺陷趋势

　　每个迭代将拥有一个开发包，一些新的特性或场景加入其中并且根据现有场景的缺陷也得到修复。当然有一个趋势，即实现新的而不修复老的，但是明智的项目经理将注意缺陷趋势并强调，至多一两个以缺陷形式的未解决的迭代工作的价值将保留。

　　无论如何，分辨缺陷无疑可以看作进展。与缺陷相关的量度也能够以有趣的方式得来，包括：

　　每个缺陷的工作、每行源代码的缺陷、每个模块或组件的缺陷、按照注入点的缺陷、按照时间的缺陷、按照状态的缺陷。

　　使用时间图表 —— 根据时间所有这些量度都可以画为图表趋势，例如，应该积极地调查表示修复缺陷工作稳定增长的趋势。

　　我们还能够通过余下的迭代的数量和平均的缺陷分辨工作来增加每个迭代的预期缺陷。这指示了显著的缺陷负担，包括在还没撰写的代码中没有发现的缺陷!这些是粗略的数字，但是是要求全部的完成百分比的重要基础。

　　对于测试人员的缺陷趋势

　　虽然上面的缺陷趋势不是具体到测试规程的，但是存在重要的缺陷量度来指导测试人员，包括每个找到的缺陷的测试工作、每个测试用例的缺陷、每个场景的缺陷，及每个迭代的缺陷。

　　这样的量度是有效的，不仅从历史的观察，还从预言能力上讲。例如，如果我们的测试揭示了一个突然的且出乎意料的缺陷密度，我们可能宣称该构建是不健全的，放弃测试，并让架构团队检查此构建。测试一个糟糕的构建以致精疲力尽，从中得不到一点好处。

　　MTBF

　　平均故障时间(mean time between failure，MTBF)是重要的“人造”量度 —— 也就是，我们不得不捏造定义，为了能够生成受控条件下的客观度量。MTBF 通常作为非功能需求出现。为了验证我们的系统，我们必须在实验室设置在测的应用程序，利用事件进行干扰，并且当不能适当处理事件时进行监测。我们将其记录为一个失败，并且继续测试或者(如果不幸的话)重新启动应用程序。我们能够以快于真实情况的节奏来生成事件流。这些手段的净效应是能够在几个星期内生成几年中才能度量出的 MTBF 数字。 因为明显的理由，可以将其认为是人造的量度。

　　这些量度证明测试人员应该看作是项目经理重要的数据来源。

　　构建迭代测试优先级

　　用例驱动的迭代方法生成了新的机会和新的负担。因为我们将已经限制阻碍完全测试的资源，所以我们应该根据以下优先级顺序执行测试：

　　运行“冒烟测试”。如果冒烟测试通过了，那么：

　　测试那些在此迭代中分辨出的缺陷。

　　测试那些在此迭代中实现的新场景。

　　上面的三项应看作是绝对极小值，并且不能实现它们的应该看作是测试过程的主要失败。我们应该继续三个步骤：

　　维护和执行的自动化测试

　　维护和执行的手动测试

　　人造量度集合

　　当然，应该优先选择不需要维护当前连编的自动化测试。随着时间的推移，我们应该能够收集从中可以预计测试工作的量度，例如，维护自动化测试要多少工作，运行手动测试要多少工作，等等。

　　每个项目团队必须分辨的一个问题是测试活动与开发活动并行的方式。从某种意义上讲，一旦对开发人员来说迭代结束了，对于测试人员迭代就开始了。

　　测试优先的方法

　　测试优先的方法在最近五年内受到了相当大的推动。简单地说，开发人员在撰写代码之前要撰写一个测试。每个分支、循环，或其他逻辑在加入源代码之前都要写出将要执行结果的自动化测试。

　　测试优先主要在构建阶段，主要由开发人员执行，而不是测试人员。可以将其尽早地引入精化阶段，但如您所见到的，强调的不是功能的完整性。

　　产品化(Transition)阶段：管理可接受的风险

　　验收测试应该已经是所有测试人员都熟悉的，因此此讨论将只涵盖验收的重点。

　　总体上我将定义验收活动包含部署，以及因此发现的所有问题和缺陷。这是 RUP 在产品化阶段所描述的内容，并且测试人员将其理解为验收的评估。

　　测试人员在支持项目经理达到项目阶段目标上起着关键作用。无疑会有大量增加的请求以及低优先级的缺陷，无论哪里，只要可能，这些都应当延迟到新的维护项目中。

　　评估可接受性

　　产品化阶段中强调的是分辨缺陷并停止项目。不允许新的功能。开发人员有时候称项目中这一点为“代码烂泥” —— 换句话说，还没有“代码冻结”，因为某些类型的变更还允许出现。

　　测试人员在发布计划中起很大作用。这包括测试工作和进度(应该源于最近的构建迭代中获得的测试工作量度)。预先应该已经确定了，构成缺陷级别和其他量度的可接收的门限是什么。这可能意味着(例如)，零关键缺陷，只有一个工作区至多一个“高优先级”缺陷，五个“中等”，及许多“低级”的。因此，测试人员可以指定并跟踪版本候选是否具有适当的质量。

　　产品化阶段将构建阶段“开发的”缺陷跟踪与外部的面对客户的及服务台的缺陷跟踪连结起来。测试版程序的许多优势之一是该支持及跟踪机制可以实行。

　　从理论上讲，如果对可交付内容做出了任何变更，都应该执行完整的测试集合。在安全至上的系统中，这很可能成为一个需求，甚至是一个规章。在一般的商业环境中，测试人员可以帮助项目经理决定运行哪个测试子集。这可能包含所有自动化测试、一些手动测试，再加上，比方说，在“实验室”中的五天时间(也就是，在 MTBF 环境中)。测试人员将使用在其上测试最可能产生失败的量度。当创建软件“补丁”时，测试人员履行类似的职责。

　　数据格式支持、数据转换，及数据迁移是产品化阶段和客户部署中的重要活动。这些都在测试人员的职责范围内。有时候，测试人员回顾用户指导和其他文档。技术作者执行此任务。

　　测试、编码、迭代，和量度

　　量度已经在我们的讨论中表现显著。测试是量度重要的来源和用户。当测试进展量度结合开发进展量度时，我们获得项目状态及其可能道路的引人注目的全面指示。这些客观的预测是管理用户期望，及能够精确地估算、请求，并防御额外的进度或资源所必要的。

　　像这些量度在传统的瀑布过程中是很难收集的。它是迭代生命周期与使收集和应用成为可能的适当测试过程的交汇点。

　　总结：摇尾巴的狗是好狗

　　在传统的开发模型中，直到预定的交付之前的最后“失败”时刻，测试人员经常作为二等公民。然后，他们成为关键的瓶颈，在其中会出现无休止的挑挑拣拣。

　　RUP 为测试人员提供了另一种观点。您在其中可以在整个项目中立即做作出贡献，并且减轻每个人的负担。

　　注释

　　1 ISO 是国际标准组织(International Organization for Standardization)的名称，SEI 是卡内基梅隆大学的软件工程学院，IEEE 是电子及电气工程师协会，它为计算行业颁布了多种标准。

　　2 参看 COCOMO II，了解在估算中应用系数的技术。

　　3参见 Walker Royce，Software Project Management: A Unified Perspective，Addison-Wesley 1998 年。

　　在敏捷中，需求的焦点常常放在用户故事上。有时，用户故事和技术任务同时是重点，但不是任何架构或者整体系统设计需求。这对于Web应用也许可以接受，因为Web应用简单、琐碎，而且基本上是事件驱动的，但它不能满足有复杂后端组件的应用的要求，比如：

　　投资组合平衡引擎

　　薪酬引擎

　　网络优化

　　规划或匹配引擎

　　有引擎的任何应用，:)

　　然而，敏捷已经把架构和设计文档的数量大大减少，因为它们数量过于庞大，而且存在浪费。我100%同意是有浪费的，但是我认为：正确的做法是创建一种新的、更精益的架构文档。放弃传统的海量被动架构文档的同时，我推荐一种新的主动架构文档，由下图中的组件对话(Component Conversation)组成:

　　传统架构文档的问题在于：它们以被动和疏离的方式定义架构，有时类似于路线图。我建议以主动方式来定义架构。文档不应该只是定义路线的地图，而应该定义路线如何前行，并以主动方式描述路线图。传统架构文档与系统的实际行为相距甚远，似乎与系统没有多少关系，而且也没有实际效果。架构文档需要定义出架构支持哪些行为，就像用户故事支持用户使用功能一样。

　　用户故事有效地捕获用户和系统之间的互动，技术任务捕获系统需要完成的底层任务。可是，在这些精简的文档中，我们如何定义系统组件之间的高层互动呢?

　　我推荐的敏捷需求记录方式包括：

　　用户故事：这些故事记录用户如何与应用交互，或是手动流程

　　组件对话：在应用组件之间的对话

　　技术任务：应用在组件内部要完成的技术任务

　　创建这些组件对话，并在整个系统层面思考思考它们，有以下效果：

　　用户故事与功能跨组件处理的方式保持一致

　　当以前完成的用户故事在后面迭代中再次遇到时，不会产生过多重复工作

　　确保整个解决方案在更高层面得到透彻思考

　　只有回过头去看以前的用户故事，才能完成某个故事——此类情况几率降低

　　技术任务在各组件之间的实现方式保持一致

　　它们可以定义复杂的后端高层需求，如果采取一个一个故事的方式，这些需求的收集会不完整，而且可能不一致

　　组件对话可以复查，以确保所有的系统功能都被覆盖到，而且不存在功能之间的缺口

　　理想状况下采取图形方式

　　这些组件对话定义了解决方案的主动架构。组件对话可以采取下面这种格式：(您也可以自定义适合您特定环境的格式)：

　　[编号]：当[事件]发生时， [组件A]完成[基本动作][对象][附加动作]通过[动作][组件B]

　　组件对话示例

　　拿几个例子来看一下，可以说明这些组件对话会是什么样子。创建组件对话的时机很重要，应该在用户故事创建完成之后，理想状态下应该是在用户故事映射(User Story Mapping)过程完成后。这些用户故事和用户故事地图能为组件对话的创建提供输入。

　　Facebook有一个浏览建议朋友的函数，是用户事件驱动系统的知名范例，它可以从组件对话中获益，我们看看如何完成：

　　声明：这些故事只是对知名接口的虚拟表示。它们不代表实际的Facebook函数。

　　如果我们已经定义好了用户故事，我们可以创建下面这些组件对话，提供更多细节和上下文：

　　[1]：当[用户登录]发生时，[SuggestedFriends组件]完成[创建][建议朋友列表]通过[在所有朋友中过滤共有联系][Connection-DB组件]

　　[2]：当[用户点击发送朋友请求]发生时，[FacebookUser组件]完成[发送][朋友邀请]通过[选择联系邀请按钮][SuggestedFriendList组件]

　　[3]：当[用户点击隐藏朋友]发生时，[FacebookUser组件]完成[更新][建议朋友列表]通过[选择联系邀请按钮][SuggestedFriendList组件][隐藏朋友列表]

　　[4]：当[用户点击接受邀请]发生时，[FacebookUser组件]完成[接受][朋友邀请]通过[选择接受邀请][PendingInvitation组件]

　　现在，这四个故事提供了非常基本的范例，但是我希望这可以展示出组件对话捕获的信息层次。即使是这些基本的例子，我认为也捕获了下面四个想法：

　　创建这些SuggestedFriendList与用户的互动是分开的，之间有个流程。

　　Connection-DB被用来创建SuggestedFriendList，而且可能还包括HideFriendList。

　　有一个对象包含PendingInvitation组件。(而且对于其他与推迟相关的对象也可能有类似概念。)

　　HideFriendList可能被持久化，以确保用户选择要隐藏的建议列表不再出现。

　　当用户故事在后面的迭代中开发时，这些想法可能终究会出现并得到讨论，但是组件对话的优势在于：提前把它们拿出来讨论，把它们想清楚，保证它们在整个应用中以一致的方式处理。及早讨论这些组件对话，还能发现重复工作的风险，比如有些工作项在一些开发工作完成后才发现。举个例子，由于要支持的对象不同，PendingInvitation对象的设计可能会变。如果我们可以使用组件对话来尽早理解高层需求和行为，以此提供一个流程，我们就能把以后迭代中重复工作的情形最小化。

　　技术任务也会从组件对话中浮现，不过只是技术任务而已，就像从用户故事中生成的功能任务。(比如：“确保Pending对象持久化，并支持朋友、事件和消息”，这可能是技术任务。)

　　小结

　　我在我当前的项目中使用了这些组件对话，并且大大改进了我和团队成员对项目的理解。很重要的一点是：这些组件对话不能占用太多精力和时间。我会用1到2天的时间盒确保对现有系统的一致理解。随着迭代的进行，组件对话可以修改和变更。关键是要保持精益，知道做到什么程度可以提供足够必要的价值。

　　这个理念为我当前的项目提供了巨大的价值。

　　关于作者：

#p#分页标题#e#

　　Terry Bunio目前是Protegra的首席咨询师。Terry以前从未想过成为项目经理，他开始时是程序员，后来发现自己对数据架构技术很有兴趣。这一路上，Terry发现自己喜欢帮助打造团队，帮助提升客户的信任度，鼓励个人的职业成长，他也享受完成项目交付物，提供解决方案指导的过程。

　　看起来有人喜欢将上面的工作称为项目管理，作为一个讲求实效的项目经理，大家都知道Terry喜欢挑战已有假设，并努力在书上的理论敏捷与现实世界的方法之间取得平衡。

　　依据精益原则实施敏捷的过程，让Terry重新享受软件开发，并相信自己可以改变世界，他将自己视为一个再获新生的敏捷人士。Terry实施敏捷时，喜欢依据精益原则、Green Bay Packers橄榄球队、Winnipeg Jets冰球队、数据架构、XML数据库，并寻找背后的原因。

　　当应用程序逐渐变得庞大和复杂后，很多面向对象建模的方法都达不到非常好的可伸缩性。上下文图是一种通用目的的技术，作为领域驱动开发大家族的一名成员，它帮助架构师和开发人员管理他们在软件开发项目中不得不面对的形形色色的复杂性。与其他广为人知的DDD模式相比，上下文图可以应用在任何软件开发的场景中，在开发者进行策略性决策时，为他们提供一个高层视图，比如是采用全套的DDD实现，还是根据项目的特定条件进行取舍等。

　　在这篇文章中，我们将探讨界限上下文，以及如何在构建上下文图时应用它们，来支持软件开发项目中的关键决策。

　　多个模型共存

　　领域驱动开发花了很大力气强调一件事，即维护应用程序模型的概念完整性。要做到这一点，需要很多因素：

　　一种敏捷的流程，确保能从用户和领域专家那里频繁地获得反馈，

　　确保有若干领域专家在场，并且与他们开展创造性的合作，

　　(在应用和测试代码中)维护单一的、可共享的模型，并用通用语言精确地进行定义它，

　　营造一种开放透明的环境，鼓励学习与探索。

　　这些对于营造一个可以让高质量的设计繁荣发展的环境至关重要。即使是这样的环境，那些常见的DDD元素，比如实体、值对象、聚合，也会逐渐地形成一个复杂领域模型。所以，如果不对模型的概念完整性进行妥协的话，传统的DDD方法也不能盲目地应用在一个无限大的领域模型中。

　　如图1所示，在DDD中，通用语言的关键责任是对模型进行完整性检查。无论是与领域专家的讨论，还是最终的实现代码，都可以通过使用相同的术语，并将领域知识清晰准确地进行定义，以此来保证团队中的每位成员可以分享都相同的领域知识和软件。

　　图1. 通用语言应该是用于表达模型的唯一语言。团队中的每位成员应该对每个特定术语达成一致。这些术语不能有歧义，也不允许在不同角色间进行翻译。

　　代码是表达模型的主要形式。虽然其他一些工件或许也能捕获需求或者局部设计，但是只有代码自身才会与应用程序的行为永远保持一致。不过这种看上去美妙的建模方式其实非常脆弱：如果满足了前面提到的四条要求，它能做到，但是不能被无限地扩展。真正让模型得以最大程度地扩展，并且不必牺牲其概念完整性的方法叫做“上下文”。

　　了解“界限上下文”

　　在领域驱动设计的世界里，“上下文”是这样定义的：

　　“一个单词或一个句子所出现的环境，这个环境会反过来影响它们的含义。”

　　这段定义初看起来相当含糊。它并没有直接告诉我们“上下文”的大小、形状或者其他什么特性。但是最后我们又发现这个定义其实非常准确地描述了“上下文”是什么，如果要想窥得其全貌的话，大概还需要一些具体的例子。

　　示例1：术语相同，含义不同

　　第一个例子很简单，它示范了在术语层面出现歧义的情况。有些词汇根据不同的使用场景，会有不同的含义。

　　假设我们正在开发一个基于Web的个人金融管理程序(PFM)。该程序可能用于管理银行帐户(Account)、股票、储蓄，未来可能用于追踪预算和开销记录等等。

　　在这个程序中，领域术语“帐户”可能是指不同的概念。谈论银行的时候，一个“帐户”在逻辑上其实是“金钱的容器”;于是我们自然而然地为相应的类加上“余额”、“帐户号”等属性。但是，在“Web应用程序”的上下文中，术语“帐户”会有非常不同的含义，它和用户的认证、可信度有关。如图2所示，相应的模型将是完全不同的。

　　图2. 一个出现歧义的简单场景：当术语“帐户”应用在不同的上下文时，它的含义可以是完全不同的。

　　这应该是我们在对应用程序建模的时候，所遇到的最简单的歧义场景了：一个术语，有两个与上下文相关的含义。这个问题的解决办法通常是在类的全名(类名或者包名)前面加一些前缀，以此来划分名字空间。但是在概念层面上，必须清楚我们在和两个上下文打交道，有时不同上下文之间的区别很大，足以防止开发人员犯错误，但有时这样的区别却非常微妙。

　　不过，在类名层面上解决问题的方式并不能用在所有的情况下：在银行的领域里，术语“银行帐户”或许已经存在了，但却有不同的含义;或者领域专家坚持使用“帐户”作为术语。此时切记不要发明一个特殊的两头这种的术语，或者在专家术语和代码之间引入一个“翻译层”。否则你将不得不面对两个独立的上下文。

　　绘制第一份上下文图

　　当歧义真的到来的时候，我们需要一种工具来让开发团队明白，应用程序中正存在着两个不同的上下文。“歧义”是通用语言的头号大敌，我们必须铲除它。消除歧义的最好办法就是在上下文图中，将领域结构分拆在多个界限上下文中。

　　图3. 包含两个领域上下文的上下文图

　　按照领域驱动设计一书的描述，上下文图是用于将上下文边界变得更清晰的重要工具。其基本的想法是在白板上画出上下文的边界，然后选择性地将相关类的领域术语填写在上面。它不是一幅绘制精美的UML图：它是一个可用的工具，允许我们描绘那种模糊不清的状况，因此它自身看上去模糊不清也就不足为其了。

　　示例2：概念相同，用法不同

　　还有一种更加令人困惑的情况，就是底层的概念相同，但是使用的方式不同，最终导致了不同的模型。银行帐户的模型是一个BankingAccount类，如图4所示。

#p#分页标题#e#

　　图4. 精简版本的BankingAccount类

　　通常，有些PFM应用也允许我们管理支付行为，并且持有一个收款人(Payee)注册器。在这个场景中，收款人可能与一个或者多个银行帐户关联，但是对于收款人来说，我们既不能获取其银行帐户的内部情况，也不能在该帐户上触发任何操作。那么将“收款人帐户”与刚刚定义的BookingAccount类关联在一起是否正确呢?

　　图5. Payee类与BankingAccount类

　　恩......这听上去有些道理：毕竟它们都是相同的概念，在现实世界中，我们的帐户和收款人的帐户甚至会处在同一个物理上的银行里。另一方面，这样做似乎又不完全正确：因为我们不允许调用收款人银行帐户的任何操作，也不能追踪他们的任何信息。更糟的是，这样做了后，可能会在我们的程序中埋下一个概念的错误。

　　我们应该如何做?我们应该再一次回到应用程序的两个不同的上下文里去：这一次我们可以采取两种不同的方式对同一个领域概念进行建模，因为对领域概念的两种使用场景明显不同，每一种都需要一个不同的模型。BankingAccount类仍然允许我们执行(或者跟踪)特定的操作(比如存款与取款)，同时另一个独立的PayeeAccount类可能有一些和BankingAccount相同的通用数据(比如accountNumber)，但是有一个简化的模型和完全不同的行为(比如我们不能访问收款人的余额信息)。图6所示的正是这种场景：尽管“银行帐户”有着清晰的含义，其底层概念也是惟一的，但是在应用程序中却以不同的方式被使用着。

　　图6. BankingAccount和PayeeAccount类

　　这看着似乎挺明显的，其实不然。当你设计类图，或者使用UML建模工具时，你可能很自然地让收款人具有一个bankingAccount属性，而且会庆幸“我刚好有一个这样的类”。Pavlovian试图去除代码中的重复，有时，它的作用会弊大于利。

　　如图7所示的上下文图，可以用于表述上面讨论的示例。注意，只要我们关于环境的知识在增加，就将它反映在图中。在这个例子中，我们将PFM的应用上下文分成了“银行”和“开销跟踪”。

　　图7. 非常简单的上下文图：画上了领域模型区域间的轮廓，可以看出在这些区域内保证了概念的完整性

　　在这个例子中，两个上下文拥有一些逻辑上重叠的区域，即“银行帐户”的概念，它在应用程序的不用区域中，使用方式也不同，这意味着我们要使用不同的模型。但是两个模型又可能有非常紧密的交互。上下文图除了能帮助我们保证模型的概念在不同上下文边界内的完整性，它还能帮助我们关注在不同上下文之间出现的情况。在这个例子中，假设同一个团队正在两个上下文上同时工作，我们就需要让团队中的每位成员的明确两个上下文的区别，并且就两个上下文中出现的术语和概念，分享同一个转换的映射关系。

　　示例3：外部系统

　　再来考虑一下PFM。很多这种应用程序都需要与某些金融在线服务进行数据交换。在这个例子中，银行会为家庭银行服务提供实时的访问。其他的例子还包括允许用户下载通用标准格式(比如Money或者Quicken格式)的银行对帐单。但是从上下文图的视角来看，无论是交互活动还是通讯的方向(单向或是双向)，并不重要。有一件事是要关注的，我们有了不同的模型。图8展示了PFM与在线银行应用程序的交互行为。

　　图8. 在上下文图中，与外部应用的交互行为很自然地需要独立的界限上下文

　　即使设计两个模型之初是让它们展现相同的数据(至少在一定程度上)，但随着时间的推移，它们还是会受到不同因素的影响，而且它们也会用于不同的目的。因此，分离上下文边界是必须的。如果假设用户档案(User profiling)模块是由第三方库实现的，那么示例1也能够归入到这一类中。

　　管理多个上下文

　　当应用程序跨越了多个上下文后，我们必须管理上下文之间的关联。不同的界限上下文之间的关系，通常是我们深入观察项目的线索。

　　有一件事情非常关键，即两个上下文之间的联系是有方向的。DDD用两个专门的术语表述它们：“上游(upstream)”和“下游(downstream)”，一个上游上下文会影响到相应的下游上下文，但是反过来就不一定了。这不仅体现在代码上(一个库依赖于另一个)，还体现在技术含义较少的因素上，比如进度、对外部请求的响应，比如，当在线银行服务更改了API或者其他什么原因，我们的PFM银行应用程序都必须要快速地更新。所以我们的PFM上下文应该是下游的，而在线银行服务很明显就是上游的了。图9演示了这两种领域上下文的关系。

　　图9. 分离的上下文之间的Upstream-downstream关系

　　如果外部系统发生变化，我们可以接受这种变化，来更新与外部系统通讯的方式。不过我们仍然需要一些保护措施隔离来自上游上下文的变化，保证我们自己的“银行”的上下文的概念完整性。DDD包含了几种组织模式，帮助我们描述和管理不同的上下文交互方式。最适合我们在这里使用的是模式叫做反腐化层(Anti-Corruption Layer，ACL)，它会在代码层面上实现显式的转换，转换可以在两个上下文之间，或者在“银行”上下文的外部边界上完成。这不仅局限于技术上的转换，比如Java转化为XML，同时也是一个很合适的机会，能够管理各个模型之间的所有微妙的不同。如下面的图10所示，我们在上下文图上添加了ACL。

#p#分页标题#e#

　　图10. PFM程序边界上的反腐化层，防止在线银行服务的变化影响到我们的边界上下文

　　很明显，一个外部系统需要一个独立的上下文。然而对于一个已有的遗留组件，通常也伴有一个非常难以修改的模型。尽管遗留组件是在我们组织内部来维护的，甚至这个模型也会受到不同因素的影响，它会被其他的上下文所使用。如果必须和遗留系统进行交付，不同模型之间的转换应该放在一个不同的界限上下文里。

　　上下文图中还有其他的关系吗?我们能够根据相关的DDD模式对它们进行分类吗?如果假设开发活动是在单一的团队内进行的，那这里的模式就不会引起太多的关注。但是，如果“银行”和“开销”是由不同的团队来维护的话，团队之间应该是一种合作关系：他们的开发会朝向一个共同的目标(这里谈论上游和下游没有意义，因为他们处于同一级别)。如果Web用户档案模块来自于外部，我们将会作为下游的上下文。

　　图11. 加入了关系模式后的上下文图

　　示例4：向组织扩展

　　到目前为止，我们只考虑了包含一个开发团队的简单场景。在这种场景下，我们可以忽略沟通的开销，假设团队中的每位开发者都很明确“模型将会如何发展”(也许有些乐观)。更复杂的场景中还可能包含下面的影响因素：

　　领域复杂度(需要很多不同的领域专家)

　　组织复杂度

　　项目跨时很长

　　项目需要大量的人天

　　涉及到很多外部的、独立的或者遗留的系统

　　大型团队，多个开发组

　　分布的、离岸的团队

　　个人因素

　　每个因素都会影响开发团队和组织的通讯方式，并最终影响到要交付的软件。

　　每个独立的团队，尤其是一个处在敏捷环境的团队，团队内的成员间有很多共享信息的方式：面对面的交谈，多人参与的设计讨论、结对编程、会议、信息散播装置(information radiator)等等。但问题在于，当团队规模、人数增加后，这些技术很难再继续使用了，跨团队地共享模型的概念完整性也非常困难。

　　毕竟，能够对模型保持统一看法，是沟通中相当成熟的方式，这涉及到对问题具有一致的理解，以及对可行解决方案大致相似的看法。在那些沟通不顺畅的场景下，“埋头干”很容易取代了“识别和确认”。这种沟通瓶颈带来的典型后果就是在同一个代码库中的不同地方散布着不同的类，它们做着基本上同样的事情。

　　总有一天PFM应用会变得更大，这样就要有另一个团队(团队B)和我们一起工作(显然我们是团队A)，他们开发一个名为“交易”的新模块。团队B可能在一个不同的房间、建筑物、城市、公司里，他们全心投入到新模块的开发工作上。如下图所示，团队A与团队B共享了一些代码，虽然他们很可能会使用彼此独立的代码。最后，团队B会写一些类(比如图12所示的A')来实现自己所需的功能，不过这些功能已经存在于类A了。

　　图12. 当不同的团队访问相同的代码库时，他们会去关心模型上的不同部分。物理上的团队分割会令信息共享的效果大打折扣

　　这是重复代码，万恶之源啊!在一个独立的、良好定义的、有界的上下文内，这是毋庸置疑的。但是由于某些原因，这种现象几乎会出现在所有复杂的项目中。这通常是个信号，告诉我们在项目的同一个区域内，或许存在没有恰当隔离的上下文。不过在有些时候，使用两个独立的上下文是组织领域模型更加有效的手段，而不会强迫两个不同的团队不断地去整合他们的模型。

　　那么，我们如何在图上画出这些呢?上下文图反映了当前我们对整个系统的理解水平。一旦我们学到了更多东西，或者环境发生了改变，还会马上更新它。现在，我们还不能准确地预知接下来会发生什么，所以这就是“我们当前的理解水平”。

　　图13. 尚未很好划分的“交易”上下文，它还需要进一步探索或更切合实际的设计决策

　　图中的危险警告符告诉我们那里有些问题：两个上下文有局部的重叠，它们的关系还不是非常清晰。这可能是需要解决的第一类问题，可以尝试着在上下文内设置一个被广泛认可的、合理的关系，比如消费者-供应者、持续集成或者共享内核(Shared Kernel)。不过，这是明天的工作。上下文图是为今天准备的工具，而问题在今天还存在着，所以我们还把警告符号留在图中。

　　不要被图中的颜色和阴影搞迷惑了。我不过是想让上下文图的打印效果更好一些。一个真实的上下文应该是很乱的，起码和你的项目一样乱。不过这个警告符提醒我们这里有一个危险区域，此处的上下文尚未被清晰地分离，事态很容易朝着“一团大泥球”发展(最有弹性的DDD组织模式)，除非我们采取行动。

　　一种非传统观点的视角

　　上下文图迫使我们将非软件的因素也包含在整体考虑中，这样我们更能识别出一些污点热区，而这些热区在传统架构分析的观点中是“不在范围内”的。

　　比如，组织内部的信息流通方式会在很大程度上影响最终的软件。通常，在小型组织中，组件自身的用途是定义上下文边界的主要因素，而在大型组织中，这个关键因素变成了沟通效率和项目组织方式。像Wiki、email或即时消息软件会给我们一种假象——团队中每位成员的知识都不断地保持着同步。但是我们都知道这只是个梦想罢了：在一个典型的大型项目中，我们不是Borg人(译注：源自《星际旅行》中的外星生物，所有Borg人的思想是互联的，可以完全共享知识)那样的智能联合体，很多人对于自己团队以外的情况知之甚少。

　　在大型组织中定义上下文边界是一项颇具挑战的任务，但回报却也相当丰厚。很多时候，各个团队并不清楚多个模型存在的事实;之所以概念的完整性会频遭破坏，是因为只有很少人或者没有人看到完整的图景。绘制上下文图是一个不断探索的过程，很多部分的内容在首次尝试时都是不正确的，边界在初期也是很模糊的，还需要很长的路要走，才能获得一个更清晰的完整图景。#p#分页标题#e#

　　图14. 上下文图的最新版本。不要指望它是“最终”的，我们总是会学到一些新的东西。

　　涉及到的上下文还可能更多，比如“交易”模块可能需要链接到一些在线股票价格服务，但这是交易模块的事!这个上下文图是关于我们(团队A)的，我们的工作内容是“银行”和“开销跟踪”模块：我们只对直接关联的、会影响到自身软件的那些上下文感兴趣。

　　一旦我们收集到更多的信息，上下文图就会变得更加清晰。正如前面提到的，只要认识到应用程序中存在着各种不同的模型，而且这些模型的完整性可以在一个良好定义的有界上下文中得以保存，这会为我们的领域建模的视角提供诸多益处。很多模型都在成长的过程中逐渐失去完整性，上下文图会在这个方面给予我们很多帮助。

　　谈谈策略性DDD模式

　　此处我们使用模式的方式略有不同：尽管定义是一样的——为一类反复出现的问题提供解决方案——但这些模式很少能展现出可供我们选择的解决方案。更可能的场景是，组织架构会决定模式，我们惟一的希望就是在事态走到死胡同以前识别出它们。有些时候我们有机会选择最好的选项，或者改变现有的状况，但是我们必须清楚的是，在组织级别的改变所需的时间可能已经远远超过了项目持续的时间，或者这个改变根本就是不可能的。

　　如果你还在犹豫应该从那里开始，那么就从开发团队开始吧。对于有效地共享模型信息来说，一个团队应该是最大的组织单元。当识别出多个上下文后，可以由一个团队管理它们，这样很大程度上将问题归结为架构的抉择。

　　每一种模式都有不同的开销：即使它们解决的是类似的问题(相近的上下文)，也不能简单地交换。比如，反腐化层会在代码层面(一个额外层)上留下痕迹，并在组织里留下很小的痕迹。尽管Partnership或者“客户-供应者”模式可能需要更少的代码和一个单独的代码库，但是如果没有有效的沟通渠道和良好的过程的话，也很难应用起来。企图在没有合作的环境下安排执行Partnership模式，无异于自寻死路。

　　结论

　　让我们在回到“上下文”最初的定义上来——“一个单词或一个句子所出现的环境，这个环境会反过来影响它们的含义”——它非常准确，而且可以应用在设计层面、架构层面乃至组织层面上，却没有损失其准确性和有效性。尽管有些“对统一性的期望”是合情合理的，但是模型不能被无限地扩张。界限上下文提供了一种非常安全的机制，它允许模型在其内部不断变得复杂，同时又不牺牲概念的完整性。

　　当把上下文图应用到大型的项目上后，它还可以显示出当前组织内的隐式边界，并提供一个来自第一手的、没有PS过的项目境况的快照。一个好的上下文图能让你看到所面对的不利条件的大致状况。可能你已经知道——但通常都是不知道——组织是否在扮演项目成功的绊脚石，即使项目还没有开始。

　　作为一名顾问，我发现上下文图能够奇迹般地让我快速获取客户项目的细节。上下文图还充当了策略决策的支持工具(毕竟，这是“图”的本意)。上下文图提供了系统的全局视图，帮助我们关注在选择那些能在你的环境中真正可行的方案，而不是把钱浪费在对系统不切实际的构想中，这是UML或者架构图所做不到的。

　　关于作者

　　Alberto是来自Avanscoperta的一名咨询顾问和培训师。他致力于帮助客户管理软件开发的复杂度。他坚信只有那种全盘考虑的软件开发方法才能开发出有用的软件。

　　项目范畴制定和管理 (Scope Development And Management)

　　很多人会自然地把这个步骤理解为用户需求的收集和制定。其实用户需求只是这个过程中的一个手段和结果。不管是自主开发，还是集成商为商业用户开放的项目，最终目的都是为用户解决工作中的问题，同时提高和改进工作的效果。

　　而技术人员最常犯的错误，是把用户当成软件设计专家。比如在BI项目里，技术人员往往会问用户，你们需要什么样的报表，什么格式，数据在哪里。而用户就拿出一叠纸面的报表说，就把这些弄到电脑上去吧。本来意在提高商业效率的BI项目，就变成了一个硬生生把纸面文件通过软件重新实现的低效率工作。

　　所以项目的范畴制定，不能只限于直接用户能够看到的。作为信息处理的专业人士，我们必须首先要了解用户的商业需求。现在在信息应用上遇到什么问题?决策者有没有必要的信息和工具?具体操作人员有没有能力最有效地进行他们的工作?所生成的信息是不是足够相关人员解决问题?用户是否可以主动地分析和发现问题及最佳方案?

　　对商业问题的解决应该是BI项目范畴的出发点。但即使在用户需求已经确定之后，对项目范畴的管理也是一个需要一直进行的工作。只有在一个明确的指导之下，才能把整个项目的工作和用户的需求完美地结合起来。

　　设立符合现实的预期(Set Realistic BI Expectations)

　　BI项目往往是一个涉及很广的工作。从数据的收集，清理，存储，到数据的计算，呈现，分析，和信息的发布和监控。根据企业不同的现状，BI的实现往往需要分成几个阶段来实现。假设一个企业还没有建立起一套相关的架构，一个BI项目就必须首先解决数据收集和存储，建立数据仓库。在数据得到了保障之后，再进行报表设计，Dashboard，及数据分析等工作。

　　在一些新引进BI概念的企业里，用户往往会产生一些过度乐观的想法。常常会把目标定得很高。这样不仅会对项目的预算和时间造成影响，在把范围扩大太多后，也常常不能有效地计划和利用人员和资源。

　　近年来敏捷(Agile)BI的概念开始被大家接受。这里的Agile和软件开发是同一个概念。但应用到BI领域，就包含了一些自己的概念。比如对数据仓库的必要与否，数据清理的方式等等，都有一些不同的理念。这些我们在下一个章节仔细描述。

　　了解架构和不同的技术选择(Understanding Architecture And Associated Options)training.ltesting.net

　　BI作为IT的一个分支，技术上的考虑也是一个很重要的方面。在这里我们讨论几个对项目成败影响最大的几个技术层面。

　　BI极少是一个独立的系统。首先，作为一个数据处理和信息呈现工具，任何BI的实现都是建立在其它系统的基础之上的。在计划一个BI项目时，我们必须对现有的软件架构有一个十分完整的理解。什么样的产品可以最好的嵌入到现有的架构里?什么接口可以最容易和高效地提取数据?BI工具是否提供了足够的集成功能?

　　在确定了架构的选择之后，第一个需要面临的是对数据仓库的选择和设计。数据的整合，清理，及存取是BI项目成功与否的决定性因素。传统上BI的最佳模式往往是建立在一个高度集中的大型数据仓库基础上的。在Agile BI的理念影响下，近年来也出现了一些其它的解决方案。比如用全内存数据处理的(Qlikview)及时汇总技术，采用云计算技术的分布式运算系统(Hadoop，StyleScope)。总体来讲，传统的数据仓库最大的优点是技术成熟，但比较复杂和昂贵。新兴的技术往往着重于快速的处理大数据量，但在系统的稳定性上可能还没有这么成熟。

　　于数据有着同等重要性的是信息呈现和互动功能。作为最终用户直接使用的界面，一个BI软件所提供的前端界面直接决定了商业用户可以得到什么信息和怎么使用信息。如果没有一个强大的客户界面，无论数据处理解决得多好，用户也不可能受益。

　　在前端功能选择方面，不仅需要考虑当前的用户需求，也应该考虑到以后的扩展。在一个BI项目实现之后，后续工作往往都集中在前端的增强。因为用户使用中会很自然提出很多建议和新的要求，而这些通常都集中在用户面对的界面。所以，在考虑BI功能时不要只是限制在传统的报表层次，同时应该考虑一些更先进的技术，比如可视化，Dashboard，数据预测(Tableau，StyleScope，SAS)等等。bbs.ltesting.net

　　准确定义和服务用户需求(Identifying And Focusing On The Needs Of The Customer)www.ltesting.net

　　用户勿庸置疑的是任何一个BI项目的中心。但明确谁是最终用户往往并不是一个容易的事情。因为BI系统往往有不同的用户群。从对日常报表使用的大众化用户，到专职进行数据分析的高端用户，大家对BI产品的要求可以说是形形色色。

　　当然，在BI项目计划中，我们不可能把所有可能的需求都涵盖住。但下面的几个方面是每一个BI项目都要考虑的功能：项目管理培训

　　报表的设计和生成效率。项目管理者联盟

　　报表作为一个最常用的信息界面，有着它不可替代的作用。在经过了二三十年的发展，在报表的设计技术上差别已经不是很大。最需要关注的是报表生成的效率。随着数据的爆炸性增长，对极大数据的处理在报表生成中并不是每个产品都可以达到的。

　　Dashboard和互动界面bbs.ltesting.net

　　数据互动界面的广泛应用是对报表的一个重大突破。当用户只能通过固定的报表接触信息的时候，信息化水平基本还是70年代打印为主导的水平。只有当用户可以随心所欲地和数据互动，BI才真正进入了网络时代。

　　可视化和丰富图表

　　可视化是一个以图表为主的信息呈现方式。当然并不是说只要图表就是可视化。BI的专业人员可以借鉴一些可视化中的佼佼者，如StyleScope，Tableau等。

　　企业级BI(EntERPrise-Class Business Intelligence)#p#分页标题#e#

　　我们开始时提到，在实施BI项目时，最好是从小到大，一步一步的进行。但BI往往最终会发展到一个企业级的应用。所以在项目的计划和技术的选择上，我们必须把眼光放得长远一点。不要只局限于当前的需求和一个部门的用户。

　　当然，一个BI项目所涉及到的远远不止这几个方面。这里所提到的只是一些BI所独有的特点。要保证一个BI项目的顺利实施，其它管理措施也是同样重要。但如果处理好了这几个方面，可以尽量降低常见的一些负面的因素和失败的可能。

　　度量有三个范畴，产品度量、项目度量和过程度量。

　　项目度量，反映项目状态，关注实际结果与计划或过程标准的偏差，用于项目监督和控制。

　　产品度量，对软件产品进行的、独立于产品生产过程的度量，通常关注重点是产品质量。

　　过程度量，量化了软件过程或开发环境的属性，对于成熟企业关注过程性能和能力的度量。

　　广义的过程度量涵盖了这三部分。我们今天讲的度量泛指广义的过程度量。

　　度量就是用数字说话。那么度量涉及什么?它涉及项目开发全过程，包括估算、需求管理、设计、编码、测试等阶段。

　　度量的第一基本法则：明确量化管理的目的及约束条件。

　　就估算来讲，“功能点”法是比较复杂而且难掌握的软件规模度量办法，有可能在研究使用的过程中，才发现不值得用“功能点”法，大家再反过来看看目标：在一定的时间成本要求内，提供估算的准确率，而不是：在一定的时间成本要求内，用功能点法提高估算的准确率。这时，大家可以选用别的办法，或者对“功能点”法进行改造。在制定目标的时候，不要把具体的方法写进去，目标是很高层次的，把办法写进去，也就是相当于限制了思路。

　　有很多软件企业，在项目过程中，须提交一些进度报告、总结报告，报告中可能会有进度情况、成本情况的一些数据。收集这些数据的目标也十分明确，就是想了解项目的进度、成本情况，并与计划的情况进行比较，采取必要的措施。

　　也就是说，度量要明确目标。以cmmi为例，3级要度量的和5级要度量的是不一样的，不能眉毛胡子一把抓。否则，就会出现过度度量。对于成熟度2级的即项目级，就是说项目交付可复制级别，可能在需求、质量方面的度量更有意义。www.ltesting.net

　　1) 初级量化管理-感知级，相当于CMMI2级。

　　2) 中级量化管理-经验级，相当于CMMI3级。项目管理者联盟

　　3) 高级量化管理-可预测级，相当于CMMI4级。

　　4) 超级量化管理-持续优化级，相当于CMMI5级。项

　　下面谈的度量，更多是面向2、3级的度量。4、5级的性能、效率离得比较远，操作往往需要IT工具支撑，回头再聊。

　　2、3级度量，哪些比较合适?下面我列一些要点。我们每做完一个项目，都要做这些要点的度量(过程中和结项后)

　　1、"项目基本信息"

　　包括开发平台、编程工具、语言、操作系统、数据库、业务单元数、架构类型、并发用户量、生命周期模型等等，是用于公司下个项目参考的基础信息。

　　2、项目规模度量

　　可以用代码行、也可以用功能点，要固定下来具备参考性。可以帮助我们在各阶段都去看自己的估算偏差。其中，包括：

　　最大团队规模项目管理培训

　　平均团队规模

　　计划阶段团队规模

　　需求阶段团队规模

　　设计阶段团队规模

　　构建阶段团队规模

　　测试阶段团队规模

　　需求阶段结束估计规模

　　设计阶段结束估计规模

　　构建阶段结束估计规模

　　测试阶段结束估计规模

　　需求评审规模

　　设计评审规模

　　编码评审规模

　　测试评审规模

　　其他评审规模

　　这些度量对你开展新项目有直接参考价值。

　　3、进度

　　需求阶段计划开始日期bbs.ltesting.net

　　需求阶段计划结束日期

　　需求阶段实际开始日期项目经理博客

　　需求阶段实际结束日期

　　设计阶段计划开始日期training.ltesting.net

　　设计阶段计划结束日期项目管理论坛

　　设计阶段实际开始日期

　　设计阶段实际结束日期

　　构建阶段计划开始日期bbs.ltesting.net

　　构建阶段计划结束日期

　　构建阶段实际开始日期training.ltesting.net

　　构建阶段实际结束日期

　　测试阶段计划开始日期blog.ltesting.net

　　测试阶段计划结束日期blog.ltesting.net

　　测试阶段实际开始日期

　　测试阶段实际结束日期

　　实施阶段计划开始日期blog.ltesting.net

　　实施阶段计划结束日期

　　实施阶段实际开始日期

　　实施阶段实际结束日期

　　这里的构建就是编码。项目管理者联盟文章

　　4、工作量(wbs分解，工时)项目经理博客

　　计划总工时

　　实际总工时转自项目管理者联盟

　　计划阶段计划工时blog.ltesting.net

　　计划阶段实际工时

　　需求阶段计划工时

　　需求阶段实际工时training.ltesting.net

　　设计阶段计划工时项目管理培训

　　设计阶段实际工时

　　构建阶段计划工时

　　构建阶段实际工时training.ltesting.net

　　测试阶段计划工时

　　测试阶段实际工时

　　实施阶段团队规模

　　实施阶段计划工时

　　实施阶段实际工时

　　项目管理计划工时

　　项目管理实际工时

　　配置管理计划工时

　　配置管理实际工时

　　质量保证计划工时

　　质量保证实际工时blog.ltesting.net

　　需求活动计划工时

　　需求活动实际工时

　　设计活动计划工时

　　设计活动实际工时training.ltesting.net

　　编码活动计划工时

　　编码活动实际工时项目管理培训

　　测试活动计划工时

　　测试活动实际工时blog.ltesting.net#p#分页标题#e#

　　实施活动计划工时项目管理者联盟

　　实施活动实际工时

　　评审计划工时项目经理圈子

　　评审实际工时项目管理者联盟

　　其他活动计划工时

　　其他活动实际工时blog.ltesting.net

　　返工总工时项目管理者联盟文章

　　需求阶段返工工时

　　设计阶段返工工时

　　构建阶段返工工时

　　测试阶段返工工时

　　实施阶段返工工时

　　计划评审工时

　　需求评审工时

　　设计评审工时www.ltesting.net

　　编码评审工时

　　测试评审工时

　　其他评审工时bbs.ltesting.net

　　这些度量，使得你能够与客户、老板要管理工时、返工工时，即，项目不仅仅是设计、开发。也帮助你分析为什么项目会delay，是哪些因素造成：评审工时省了?还是返工工时没估计到?这些都是很关键的。

　　5、很关键的--质量

　　预计缺陷总数www.ltesting.net

　　实际缺陷总数training.ltesting.net

　　预计致命缺陷

　　实际致命缺陷

　　预计主要缺陷

　　实际主要缺陷

　　预计次要缺陷

　　实际次要缺陷

　　预计遗留缺陷数

　　实际遗留缺陷数

　　需求阶段预计发现缺陷

　　需求阶段实际发现缺陷bbs.ltesting.net

　　设计阶段预计发现缺陷

　　设计阶段实际发现缺陷

　　构建阶段预计发现缺陷项目经理圈子

　　构建阶段实际发现缺陷

　　测试阶段预计发现缺陷

　　测试阶段实际发现缺陷项目管理者联盟文章

　　实施阶段预计发现缺陷项目管理者联盟文章

　　实施阶段实际发现缺陷www.ltesting.net

　　交付后1个月内发现总缺陷

　　交付后1个月内发现致命缺陷

　　交付后1个月内发现主要缺陷

　　交付后1个月内发现次要缺陷

　　需求活动预计引入缺陷

　　需求活动实际引入缺陷

　　需求活动实际引入缺陷(需求时发现)项目管理论坛

　　需求活动实际引入缺陷(设计时发现)

　　需求活动实际引入缺陷(编码时发现)

　　需求活动实际引入缺陷(测试时发现)项目经理圈子

　　需求活动实际引入缺陷(实施时发现)

　　需求活动预计清除缺陷

　　需求活动实际清除缺陷

　　设计活动预计引入缺陷

　　设计活动实际引入缺陷项目经理博客

　　设计活动实际引入缺陷(设计时发现)

　　设计活动实际引入缺陷(编码时发现)

　　设计活动实际引入缺陷(测试时发现)

　　设计活动实际引入缺陷(实施时发现)项目管理者联盟设计活动预计清除缺陷

　　设计活动实际清除缺陷

　　编码活动预计引入缺陷转自项目管理者联盟

　　编码活动实际引入缺陷

　　编码活动实际引入缺陷(编码时发现)

　　编码活动实际引入缺陷(测试时发现)项目管理者联盟文章

　　编码活动实际引入缺陷(实施时发现)

　　编码活动预计清除缺陷

　　编码活动实际清除缺陷

　　测试活动预计引入缺陷

　　测试活动实际引入缺陷项目经理圈子

　　测试活动预计清除缺陷

　　测试活动实际清除缺陷

　　实施活动预计引入缺陷

　　实施活动实际引入缺陷bbs.ltesting.net

　　实施活动预计清除缺陷

　　实施活动实际清除缺陷

　　项目在开发前就应该预估会有多少bug，根据bug的修改时间就知道要多少返工，以及测试轮次。这些数据也可以反映，因需求不清导致多少bug?引入bug的影响率?以及销售、交付后有多少bug?这些数据有了，考核都有了。

　　例如，交付后1个月返工的bug，考核测试与开发、项目经理、总监等。

　　再例如，你前面有规模估计，自然能预估会有多少bug。以代码行为例，标准如果是千行bug率在千分之3，那么你是10w行规模则会预计bug300个，测试1轮如果可以发现100个的话就要3轮测试。开发测试计划中你制定2轮就不合理了，1轮1周，那需要3周，你给2周也就不合理了。

　　综上可见，度量是项目管理的灵魂。如何根据当前阶段能力，选择最关键的度量点是qa、总监要很清醒的。不能不度量，也不能度量过度。以上5点做好了，这家公司基本是正规的公司了。其他的，一些其他高级度量点等再成熟了就再度量

　　随着信息技术的不断进步，信息系统的规模不断扩大、复杂度不断增加、造价越来越高，由此带来了信息系统投资风险的不断加大，使得信息系统造价评估的重要性越发凸显，成为影响信息系统相关各方计划、决策、实施的重要因素。良好的造价评估，对于规范信息产业发展、减少各方矛盾、提高工程质量具有重要意义。因此，学术界和工业界对信息系统造价评估开展了大量研究，提出了许多造价评估方法，比较著名的有基于功能点的分析[1]、COCOMO[2]、COCOMOⅡ[3]等等。

　　由于当前社会发展速度越来越快，人们的生产生活模式变化也越来越迅速，这对信息系统的建设也造成了重大影响。许多在信息系统开发之初制定的需求，在开发过程中就会发生变化，需求变更是信息系统开发过程中普遍存在的现象，这给信息系统的造价评估带来了新的挑战。当前的造价评估方法没有考虑到开发过程中需求变更的影响，使相关各方难以把握系统的造价，为项目的实施带来不便。

　　鉴于此，本文提出一种针对需求变更的信息系统的造价评估方法。由于该方法以功能点分析法为基础，因此本文将首先对功能点分析法做简要介绍，然后再详细阐述该方法。

　　二、基于功能点分析的造价评估方法

　　基于功能点分析的信息系统造价评估方法如下：

　　其中BC为通过该模型得到的造价评估值。

　　UFC是初步功能点数，通过功能要素换算得到。在功能点分析法中，共有五类功能要素，分别是：内部逻辑文件(Internal Logical Files，ILF)、外部接口文件(External Interface Files，EIF)、用户输入(External InPuts，EI)、用户输出(External Outputs，EO)、用户查询(External Inquiries，EQ)。

　　CRR为代码复用比率：指在软件系统中，被重复使用的代码所占的比率。

　　TFC为技术复杂度因子：是软件系统技术复杂程度的度量。其值取决于以下14个方面：数据通讯、软件性能、可配置性、事务效率、实时数据输入、用户界面复杂度、在线升级、复杂运算、代码复用性、安装简易性、操作方便性、跨平台要求、可扩展性、分布式数据处理。

　　PM为软件人员的人月成本：是指软件企业一个月平均需要的所有成本开销(包括工资、奖金、福利、办公成本、国家各种税费、管理费用等等)及软件企业合理利润的总和，除以企业员工人数。

　　SLOC是程序代码的行数，其值由语言类型L 决定，L与SLOC的对应关系，如表1所示。为了便于讨论，本文假定所研究的软件系统是单一语言的，即在系统开发过程中，L是不变的。

　　表1 L与SLOC的对应关系

　　关于UFC、CRR、TFC、PM的具体计算方法可参考文献【1】，限于篇幅，此处不再赘述。

　　三、考虑需求变更的造价评估方法

　　在信息系统项目实施过程中，需求变更对于前期的工作来说，会产生继承和破坏两重后果，即在需求变更后，前期的部分成果可以继续使用，而其余的成果将被舍弃。本文的方法就是基于这种思想展开的。

　　3.1总述

　　设S0是需求变更前的软件系统、S1是需求变更后的软件系统，则带有需求变更的信息系统的总的造价评估值BC为：

　　BC0为S0的造价评估值，有：

　　UFC0、CRR0、TFC0、PM0分别为S0的初步功能点数、代码复用比率、技术复杂度因子和软件人员的人月成本。

　　BC1是S1的造价评估值，有：

　　UFC1、CRR1、TFC1、PM1分别为S1的初步功能点数、代码复用比率、技术复杂度因子和软件人员的人月成本。

　　由于需求变更前后的软件系统会发生变化，导致UFC、CRR、TFC、PM的调整，故这些参数在BC0和BC1的评估中的取值可能不同。

　　D1和D2是在需求变更发生时，已开发工作对于S0和S1贡献因子，将在下一节讨论。

　　3.2相关参数的确定方法

　　在带有需求变更的软件系统的造价评估中，需要重点评估以下两方面的因素：

　　(1) 在需求变更发生之前得到的成果对S0的影响;

　　(2) 在需求变更发生之前得到的成果在S1中的影响。

　　在需求变更发生之前得到的成果对S0和S1的影响分别用贡献因子D1和D2来度量。

　　由于已完成的工作量并不能构成一个完整的系统，而基于功能点分析法的造价评估模型中的参数都是针对于一个完整系统进行估算的，因此本文采用补余法来估算已完成工作的造价。具体的做法是假定该系统已经完全开发完成，根据已开发完成的工作在整体中所占的比重来估算其造价。同时，又由于已完成的工作量很难用调整后的功能点(即 UFC×CRR×TFC)来表示，所以本文采用初步功能点数(即UFC)来计算工作量。

　　设UFCA是变更发生时，已经开发的功能点数(即针对S0的需求分析，开发出来的功能点数。该值可以是非整数值，因为某些功能点可能已经开始开发，但并未开发完成)，UFCB是在开发S0时完成的，且在S1中依然被保留的功能要素的功能点数(该值同样可以是非整数值)。

　　设E是从开发S0开始到需求变更发生时，已经进入开发阶段的功能要素构成的集合，e∈E， We是e的复杂度加权因子(Complexity weights Factor), Pe是e完成的比例，Qe是e在变更后的系统S1中被保留的比例，则

　　UFCA是在开发S0时得到的功能点数，但是已完成工作对S0的贡献并不仅仅是这些，因为S0中未开发的部分里，有些是可以通过复用已完成的代码得到的，已完成工作的这部分贡献记为UFCC。

　　同理，UFCB也不是已完成工作对S1的全部贡献，因为S1中除UFCB以外的其它部分里，有些是可以通过复用已完成的代码得到的，已完成工作的这部分贡献记为UFCD。

　　设F是S0中包含未完成工作的功能要素构成的集合(包括两部分：一、已进入开发阶段但未开发完成的功能要素;二、未进入开发阶段的功能要素)，f∈F，Wf是f的复杂度加权因子，Rf是f中可以通过复用已完成的代码来实现的工作占f的总工作的比例。则

　　设G是S1中含有“非S0的保留工作”的功能要素组成集合，g∈G，Wg是g的复杂度加权因子， Tg是g中可以通过复用UFCA中的代码来完成的工作占g的总工作的比例。则

　　UFCB和UFCD的区别是：UFCB代表的是在 S0中已进入开发，并且在S1中被直接保留下来的工作量;UFCD代表的是S1中其他的可以通过参考或复用中已得到代码来完成的工作量。

　　贡献因子D1和D2表征的是在变更发生时，已完成的工作量分别占S0和S1的工作量的比率，因此通过以上分析，有

　　将D1和D2代入公式(1)后，可得到展开后的造价评估值为：

　　四、结束语

　　本文对存在需求变更的信息系统的造价评估问题进行了研究，给出了一种造价评估方法的模型。引入贡献因子是该方法的主要特点，旨在描述需求变更对变更前、后两个阶段的造价的影响。由于该造价评估方法包含一定的经验成分，因此，在实践中修正方法中的各项参数、提高评估准确性、确定方法的适用范围是下一步研究工作的重点。

　　参考文献

　　[1] 李帜，林立新，曹亚波. 功能点分析方法与实践[M].北京：清华大学出版社，2005

　　[2] B W Boehm. Software Engineering Economics[ M ] . New Jersey:Prent ice Hall, 1981.

　　[3] J W Bailey, V R Basili. A Meta Model for Software Development Resources Expenditures[ A] . Proc of the 5th Int Conf on Software Engineering[ C] . 1981. 107-116.

　　曾经项目管理人员认为敏捷只是一种时尚。敏捷宣言发表10年来，这种方法已经渐趋成熟：它已经从边缘方法逐渐成为核心方法，并且从只应用于小型软件公司，发展到已应用于大多数的企业组织。敏捷不是银弹，它也需要适应复杂多变的企业环境。本文的目的正是要说明在企业环境里，项目经理怎样才能成功地在项目中应用敏捷。

　　我认为敏捷方法最好用于管理产品，不过用于管理项目也很有效。只是项目经理必须理解三条关键原则，那样才能充分发挥敏捷的力量，从而改善项目的交付成果。在本文中，我将讨论并破除关于人们通常认为“项目不是敏捷模式就是瀑布模式”的两个神话，再与大家回顾四种增量敏捷模型，并说明项目经理和其他特定的敏捷团队负责人如何使用这些模型。最后，我会推荐一个三层嵌套的“信封”模型，讲解在瀑布环境中，利用你对项目管理和产品管理的理解、结合你精心选取的管理方法，如何使用信封模型来管理敏捷项目。项目经理大可放心，在敏捷项目里他们的作用非常重要，不仅如此，对于大型项目的成功，他们也是必不可少的。

　　介绍

　　今年人们庆祝了敏捷宣言发布10周年。在这十年间，敏捷从项目管理界中的无名小卒发展成了主流的方法。2009年，在Version One的敏捷调查中，有84%(Version One，2009)的调查对象表示，他们在某种程度上使用了敏捷。2010年，这个数据跃至90%(Version One，2010)。然而，对许多企业高管、总监和经理来说，敏捷仍然让他们感到困惑、模糊并且不可信。

　　理解以下三条关键原则，每位项目经理就都可以在瀑布环境中成功地融合敏捷的价值准则和实践，从而提升项目的可预测性，促使项目最终获得成功：

　　敏捷不是用于PMI所指的那类项目的

　　敏捷中的计划工作，是一系列连续的步骤，没有明确的界限划分

　　混合使用敏捷方法和瀑布方法

　　在继续讲解前，我先介绍一下本文内容所基于的情境。我定义了两种企业类型：软件公司(独立软件供应商)和“其他公司”。由于敏捷方法能较容易地适用于“软件公司”，本文的重点放在如何在“其他公司”中使用敏捷方法。

　　软件公司的主要产品是软件，或者其产品的主要交付渠道是软件。按照这个定义，微软和Adobe公司是软件公司，亚马逊和易趣也是软件公司。我们之所以认为亚马逊和易趣是软件公司，是因为软件是他们交付产品或服务的主要渠道。与这种软件公司相对的是麦当劳和宜家。可以肯定，麦当劳和宜家也使用软件，但软件并不是它们的主要产品，也不是它们产品或服务的主要交付渠道。当然，它们确有自己的网站，但麦当劳并不通过互联网卖汉堡包。同样，虽然你可以通过网站订购宜家的产品，但是商店才是他们的主要售货渠道。

　　有一种处于灰色地带的第三类公司我也需要说明一下。这类公司在哪里都有一席之地。美国的银行和保险公司大都是此类灰色地带的公司。银行和保险公司既可以算是软件公司，也可以算是“其他公司”，这取决于他们的组织构成。如果企业按照产品或服务的业务线以水平形式构成，并且(或者)公司组织结构是由产品驱动的，软件是其产品或服务的主要交付渠道，那它就是软件公司。相反，如果组织结构基于工作职能划分，以垂直形式构成，例如分为市场营销、IT、和产品部门，那它就不是软件公司。这听起来很复杂，但在实践中，用这个定义，简单地确认公司中几个特定角色和他们的权力范围，就能较容易地判断出这家公司是不是软件公司。例如，如果公司有负责特定产品或服务的产品负责人，确认他的权力范围，看他能否为产品做所有的决策：市场营销决策、IT决策、网站用户体验决策等。如果产品负责人拥有对产品的所有控制权，并且能够做出从概念到客户的所有决策，那它就是软件公司，在这种企业环境中，推行敏捷方法会很容易。要不然，它就是非软件公司，想在这类非软件公司成功实施敏捷就需要做很多工作了。本文的重点就在于如何在这类“非软件公司”中实施敏捷。

　　敏捷不是用于PMI所指的那类项目的

　　根据美国项目管理协会(PMI)的定义：

　　项目是为了创造独特的产品、服务或成果所做的临时性工作。

　　2001年2月在美国Snowbird Utah举行的软件开发者大会上，人们第一次提出“敏捷”一词。早期，敏捷只是指一些轻量级过程的集合，是针对那时更广泛使用的“重量级的”(笨重的)方法的回应(Hunt 2010)。与会者制定并发布了敏捷宣言(Beck et al.，2001)，这成为为敏捷运动开始的里程碑。参加这次会议的所有人都是软件开发人员。他们的关注点在于创建软件产品，而不是项目管理过程。通过我的个人访谈(van Bennekum，Hunt，Cunningham，Schwaber， & Cockburn, 2010，2011)，我发现他们关注的是：重量级的过程无法适应网络公司快速变化的特性，这种情况该如何应对。为软件公司做开发工作时，人们永远不会有软件即将开发完成的想法。软件项目经常会被改进、增强或以其他形式变更，而不像建筑项目或设计洗碗机这类项目。建筑物一旦建成，或者洗碗机一旦被设计出来并交付生产，项目工作就完成了。有可能你再去做内部改进(Interior Improvement，TT)项目或再设计新型的洗碗机，但是原来的项目仍然是完成了，要做的新工作是新的独立的项目。

　　这与现行的产品管理的本质形成了鲜明的对比：

　　产品管理是控制产品从概念到推向市场或向客户交付成果和服务的规程和业务流程，用以产生最大可能的商业价值。(Ebert，2009)

　　产品管理关心的是产品的整个生命周期：从概念、发展，直到废弃。项目是关于创造事物的，当事物创造完成，项目也就结束了。项目不关心产品在整个产品生命周期的发展和改进。管理产品是敏捷能最有效地发挥作用的地方。花点儿时间思考一下敏捷的术语：产品负责人、产品需求列表、产品愿景、产品路线图，所有这些词语都关注于产品。敏捷实践能适用于需求变化的情况，也同样完全能够适用于产品管理。当你得知你将有第二个、第三个甚至第二十个发布时，它也只是简单地增加产品需求列表的范围，你知道，通过这样做，假以时日就能实现这些特性。而项目管理却不同，项目需要严密地管理范围、进度和预算，因为它们是结束项目的决定因素。#p#分页标题#e#

　　使用敏捷管理项目

　　人们无法普遍理解一些细微的区别。如果你理解了那些简单的区别，就可以成功地使用敏捷来管理项目。你需要做以下三件事情：

　　知道项目管理与产品管理的区别

　　规划好碰到项目/产品管理差异的临界点时应该做些什么

　　每一步都与管理层沟通

　　项目管理中需要管理三角约束：范围、进度、预算(有时人们把质量和/或资源也加到约束中)。产品管理也关注这些约束，只是对产品而言，它们是一些更加宽松的概念。

　　图 1

　　如果你用于开发产品的钱花完了，只要这个产品还在为客户创造价值，那么公司很可能在下一年制定一份新预算，让产品负责人去实现上一年没能实现的功能。而项目却不会如此，钱用完了，项目也就结束了。类似地，时间进度对产品也会比对项目更宽松一些。项目经常要关注时间表。项目经理要按时满足里程碑要求，并按时结束项目。产品也关注时间表，也关注满足里程碑要求，但不关注结束的时间，因为产品开发更关注下个版本中的优化工作。

　　你该做些什么?

　　使用敏捷的方式管理项目时，了解了项目管理和产品管理处理三角约束的不同，计划好下一步要做什么是非常重要的。

　　这里是一些来自于我个人经验的建议和技巧。首先，你需要确定对于你的项目什么是真正最重要的。是范围最重要?还是进度、预算?这听起来很容易判断，但在现实中，很难让项目发起人保证只有一件事情最重要。(Rob Thomsett的滑块是一种很有用的工具，通过它我们可以识别出最关键的驱动因素)不要让他们告诉你有两个。我做过美国联邦政府委托的一个健康保险公司的项目。当说出了项目日期，人们就开始站在桌子上叫喊，让我们不能误了这个日期，可实际上只有项目内容全部完成后，项目才能算完成。如果日期到了，而范围没完成，项目就会被认为失败了，而只有内容完全实现了，项目才能算完成。你知道了什么最重要，才可能知道你需要管理些什么。例如，如果你在做一个纯研发项目，那么范围、进度、预算确实不会是驱动因素。如果你做的是即将到来的假期的项目，那么进度对你就是最重要的。一旦你知道了这个问题，你就会更多地关注最重要的因素。你应该基于最重要的因素来调整你的管理方式。

　　在敏捷项目中，你仍然可以管理范围、进度和预算。然而，因为在项目管理和产品管理中，处理这些因素的方式会有根本的不同，所以我们就要仔细规划当发生冲突时我们应该做些什么。做好准备，当冲突发生或将要发生时，管理起来会更容易。

　　图 2

　　在敏捷项目中，范围管理是最常让人产生误解的问题之一。敏捷实践者会告诉你，在敏捷中，范围可以随时改变。的确如此，敏捷宣言的四条价值准则之一就是“响应变化胜过遵循计划(Beck，et al.，2001)”。对客户和市场要求的需求变化能及时响应，是组织接受敏捷的首要原因(Version One，2010)。用敏捷方式管理项目时，你会定义项目backlog和产品backlog。在项目开始前，你会就项目与产品的功能列表，与项目发起人进行讨论，如果可能的话，在整个项目生命周期中再与发起人进行多次讨论。项目backlog是项目需要做的具体的工作集合。当这些工作做完了，项目也就完成了。产品backlog是另外的一些特性，它们可能将来成为产品的一部分，但不是当前项目的一部分。在管理时，要非常清楚哪些内容在项目backlog 中、哪些内容在产品backlog中，并且需要与发起人反复沟通。如果识别出新的产品特性，就愉快地接受它们，并毫不犹豫地把它们加入到产品 backlog中——而不是项目backlog中。如果项目领导要求把它们加入到项目中，那就通过变更流程，把它们加入到项目backlog。变更流程可能像批复邮件一样简单，但是你有必要记录下来：新特性加入到了项目中、它对进度和预算将产生怎样的影响。尽管它可能是一个更简洁的流程，实际上这种做法与传统的管理范围的瀑布方式并无不同。

　　关于范围管理的最后一句话是：对产品backlog的优先级要持续地进行再评估。产品负责人可能想重新调整产品backlog，在项目或产品 backlog中加入或去除一些特性。这与管理上述的新工作没有差别。弄清楚这些变化的影响，并通过尽可能简单、轻量级的流程把它们文档化，这是我们作为项目经理的职责。注意，产品负责人不要试图增加或去除当前正在开发中的工作项，那是不可行的，因为这些工作已经被团队选走了。如果对正在进行中的工作要做的变更十分重要而且必须要做，那么就要终止(在Scrum中)当前的这次迭代，然后再去规划新的迭代。我们可以通过减少“打回”来鼓励迭代范围的稳定性。

　　对进度和预算我们也可以采用类似的处理方式。你需要清楚地界定什么是项目预算、什么是运营中的产品预算;什么是项目的进度、什么是运营中的产品生命周期的进度。然后你需要就此与项目发起人频繁且清楚地交流，这样不久后，项目发起人就能铭记这两者的区别，并且成为项目/产品 backlog、进度、预算的捍卫者。

　　沟通

　　你需要做的第三件事，是频繁地与产品负责人沟通项目与产品间的分界线。与产品负责人紧密合作，确保他们清楚地理解这个分界线。你要非常注意自己的语言，讲清楚“项目”和“产品”，清楚地描述产品backlog和项目backlog。这是你作为项目经理能最大地发挥价值的地方：你帮助公司在产品的背景下，保持对项目交付物的关注。

　　敏捷/瀑布连续体

　　“敏捷和瀑布 ——哪种方式正确?”我每天都会看到很多诸如此类标题的博客文章。这样的陈词滥调仍然有人谈论。“敏捷Vs.瀑布”制造了非此即彼的命题。把敏捷和瀑布视为战争中的敌人，只能有一个胜者。大量的文章纠缠于敏捷与瀑布辩论的两个核心问题：迭代VS.线性计划，命令式管理 VS.交互式管理。看(关于两个团队的一个故事，2008)下面的例子：#p#分页标题#e#

　　神话1：敏捷关注人/传统的项目管理是命令和控制式的。

　　从事越来越复杂的咨询和系统设计项目工作6年后，我发现自己管理别人做技术工作的时间多于我自己做设计网络工作的时间。2000年，Cisco公司的一位销售代表告诉我，我在做的事情实际上应该算是项目管理。我在2001年通过了PMP考试，现在成了“正式的”项目经理。

　　在接下来的几年里，我使用顺序式的方法，管理了大大小小很多个项目。正如古语所说，“当你只有锤子时，你就会看什么都像是钉子”。幸运的是，我这些项目都很适合顺序式的模型。我经常负责在华盛顿西雅图的Fred Hutchinson肿瘤研究中心新建筑项目中的IT工作。这些建筑物不仅要安装重要的网络基础设施和服务器，也要安装高度敏捷的技术医疗设备，在设备安装时往往并不需要我的帮助。这些项目工作是由建筑物的施工进度驱动的，是一个非常有序的过程。

　　在2005年，建筑项目放缓了，我开始做更多的软件项目。与建筑项目不同，软件基本上是无形的。传统的项目管理有一个未阐明的假设，它假设你一直可以看到一些东西，如地面上的大坑挖好了、地基打好了、钢筋也铺好了。软件项目却不是这样。如果按顺序的方法管理，软件项目直到项目结束才能看到东西。当项目结束时，你指望所有的事情都做好了软件就能运行。但是你用这种方式管理过软件项目的话，你就知道这是行不通的。

　　经历过一次特别沮丧的项目失败后，我对软件项目的发展趋势作了广泛的研究，我觉得Scrum Master课程对我会有比较大的帮助。碰巧Ken Schwaber(Schwaber，Scrum.org，2010)当时在西雅图授课。在Scrum Master课程中，我学到了与结构化的软件项目完全不同的管理方式，这种方式使人们能接受变更，并能随时清楚地显示项目进展，即使像软件这种无形的产品也不例外。并且我发现，它潜在的哲学更有趣。

　　图 3

　　我一直采用服务型领导的方式管理项目。我是技术人员，但我也知道，致力于具体的数据库、网络、程序语言的研发人员，对技术领域的了解远胜过我，他们知道怎样才能把工作做好。作为项目经理，我的工作是帮他们把工作需要的知识组织起来，使之可管理并能汇报给老板和管理层，消除障碍，识别可能发生的风险，让他们能消除或减轻风险。我总是竭尽所能来帮助项目中的技术人员，让他们可以自由地去做自己最擅长的事情，而不用被虽有必要但却会打扰工作的项目预算、报告项目状态等其他事情干扰。Scrum也分享了这个观点。像“鸡”和“猪”(Schwaber & Sutherland，2010)，由被激励的个体来建设团队，并相信他们可以做好工作、可以自组织、以平衡的速率工作，这些都表明了对人的持续的关注。

　　神话2：项目不是敏捷模式就是瀑布模式，没有中间地带。

　　既然我们已经解开了管理风格和交付方式的谜团，接下来我们再讲一下关于二元决策方法的神话。Robert K. Wysocki定义了项目交付物的五种离散的模型(Wysocki，2009)。Chri Ward和Leonardo Legorreta对Wysocki的模型进行了改进(Legorreta，2009)。

　　Wysocki和Legorreta定义的项目管理的五种类型是：

　　瀑布式

　　迭代式

　　增量式

　　自适应式

　　探索式

　　根据我的经验，自适应式和探索式的方法大致相同。大多自适应的方法都允许范围变更(随时可以向backlog增加故事卡片)，区别仅仅是理论在现实生活中的一些不同。所以在此次讨论里，我把这两个模型合为一个，称为敏捷。

　　顺序式——顺序式模型是用于中小型项目交付物的传统方法。项目工作可以按此顺序进行：明确项目目标、确定项目范围、做总体的项目计划、开发、测试、部署。这个模型适用于：小型或中型的、工作成果可以一次性有效地交付、需求非常清楚、不产生变更(如来自政府或行业法规要求的需求)的项目。

　　增量式——增量式模型是一种特殊的顺序式模型，只是它能够按阶段或者以迭加的方式交付成果。就像顺序式模型，增量式模型先确定了项目范围并提前做好计划，因此它最适合需求明确而且不易发生变更的项目。在每个增量中，团队可以选择怎样工作来满足交付要求，但不会讨论“做什么”和“为什么做”。

　　迭代式——迭代式模型与“提前做好计划”的顺序式模型、增量式模型相反。大多迭代模型实际上是迭代和增量。在迭代式模型中，随着项目的进展，项目计划也按迭代逐步细化。项目初期会为整个项目做高层次的计划，但是计划的粒度比较粗且常会变更。人们只对即将要做的工作做详细的计划。通常只对1周到1月内的短期工作做详细计划，其它的工作以后才会做详细计划。迭代式模型采用了增量式模型中延期规划的方法，并且从精益概念中借用了尽快交付的概念：尽可能晚做决定、根据流程工作(Womak & Jones，1996)。在增量式敏捷的工作中，团队从项目发起人和/或客户那里获取工作内容。在每次迭代中，团队既可以选择如何工作来满足交付需求，也会询问发起人或者客户要做什么事情。我们可以根据发起人和/或客户的输入来调整工作的优先级，完成更重要的功能特性，满足客户的交付要求。不过所有要求的特性(由于监管或遵从)最终都将被交付。

　　敏捷式——敏捷式模型允许在每次迭代开始时添加或移除工作范围。在敏捷项目中，需要客户经常反馈，以确保功能特性是按照对客户具有最高价值、对客户最有益的顺序交付的。此外，来自产品负责人或客户的任何新的想法都可以加入到backlog中。经常展示可运行的软件，其作用就如同 Heisenberg的“测不准原理”——测量的结果会影响测量(Cassidy，2002)，所以，看到的可运行的软件也会影响客户的需求，让客户产生新的更好的想法(Barry Boehm有一个首字母缩略词：IKIWISI-虽然我不知道我要什么，但是“当我看到了我就知道了”)。有的项目问题很复杂，甚至早期对问题都还没完全理解，这时去理解解决方案就更难了，因此对这类项目需要采用敏捷灵活的流程。#p#分页标题#e#

　　如果你理解了瀑布方法和敏捷方法是连续体，它们之间并没有明显的界限，那么你就能更成功地交付敏捷项目;而且，你能更成功地向你的同事介绍你所采用的项目管理方法的价值和原因，不管他们采用的是敏捷式方法还是瀑布式方法。

　　混合使用敏捷式与瀑布式方法

　　在本节中，我们要看一下，利用你对项目管理和产品管理的理解，结合你精心选取的管理方法，该如何在瀑布的背景下管理敏捷项目。

　　有些迭代或敏捷项目必须与瀑布式项目在企业中共存，这种现象并不稀奇。可能是你部门的项目正向敏捷转型，而公司里的其他项目却没有。似乎这两种项目不能很好地在企业中共存，实际上创造一种可行的并存模式并不太困难。为了与瀑布式项目团队的成员和其他合作者更好地沟通，你需要弄清楚你实际上在使用哪种项目管理模型(迭代式或敏捷式)，这有助于你制定清晰的沟通计划。

　　图 4 信封方法

　　当与没有实行迭代或敏捷方法的部门沟通时，讲清楚你的流程、程序和你对瀑布团队的期望、他们对你的期望，是很重要的。

　　我在跟他们沟通时会使用一种我称为“信封法”的方法(图4)。信封法是在同一项目中整合瀑布和敏捷模式的一种框架。这个方法由一系列嵌套的隔层或信封组成，用信封来隔离开不同层间的内容。

　　项目经理可以使用这种方法来保护敏捷团队，尤其是在迭代期间。在迭代结束前，任何事情都不应该干扰团队创建可以运行的软件。项目负责人可能要更改backlog，平台服务组可能要修改环境。这时项目经理都应该不遗余力地来保护团队,使他们能不受干扰地做他们最擅长的事。

　　第一个信封

　　最里面的信封是由敏捷团队来执行的工作：软件开发、单元测试、组件测试、集成测试和缺陷修正。敏捷团队负责人(在Scrum中是Scrum Master或迭代经理)是第一位的问题解决者。敏捷团队负责人要负责团队内部的沟通、指导开发团队、工作阻塞时帮忙区分团队工作的优先级。通常，敏捷团队负责人要负责团队的健康和快乐。敏捷团队负责人不能解决的问题会升级到项目经理那里。项目经理也像团队的保护者一样，会保护团队正常工作、免受复杂的外部组织的干扰。为了达到这种微妙的平衡，敏捷团队负责人和项目经理的工作关系要非常融洽才行。如果项目相对较小，那么敏捷团队负责人和项目经理可能就是同一个人。不过我尽量避免这样做，因为我认为敏捷团队负责人是一个非常关键的角色，他必须独立。这个角色可以由团队中负责其他事情的人员兼任，但最好不是项目经理。

　　在多团队项目中，敏捷团队负责人和项目经理会组织一些会议，一起处理团队的工作：

　　联合的迭代计划

　　迭代协调

　　联合迭代演示

　　联合回顾

　　联合的迭代计划——迭代计划应尽可能由统一的团队在同一天、同一个房间中做出。在撰写本文时，我正在协助项目团队准备迭代计划会议，它由四个敏捷团队、超过100人组成，其中包括项目发起人和外部(瀑布)成员。每隔一次迭代(两周一个迭代)，整个团队(很多人距离很远)会参加联合的迭代计划会议。会议需要8小时。前两个小时是集体讨论。每个项目团队都会分享关于他们Sprint的主题，以及关于这个主题的目标。他们也讨论所有识别出的跨团队依赖关系。其他团队可以对这个团队自由提问，以找出所有潜在的包括资源或人员的跨团队依赖关系。如果所有的团队都分享过了，并且已经识别了所有的跨团队依赖关系，这群人就在这个房间里分散成他们的小团队，每个小团队都有投影仪。而每个单周，人们不来现场，每个团队就会召开电话会议。团队开始分解他们在当前迭代中所选的工作。这是一个嘈杂却高度协作的过程，一些人为团队分享专业技能，非常活跃。此外，当他们遇到跨团队的工作任务时，他们会邀请涉及到的团队来一起计划如何开展工作。这天结束后团队一起回来，并对迭代成果互相作出承诺。最后，在当天举行简短的回顾，以找出下次可以改进的地方。

　　迭代协同——在迭代期间，敏捷团队负责人和项目经理可能会遇到许多需要跨团队协作的问题。为促进跨团队协作顺利进行，我鼓励团队在迭代计划会议上讨论并确定下来他们将会与哪些团队有协作需求：可能是由于共享了人员或资源(如服务器、共享的网络服务、或其他的技术资源)而需要协作。鼓励敏捷团队负责人去参加其他团队的关键迭代会议(如每日站立会议、同行评审等)。此外，项目经理和敏捷团队负责人常常会一起讨论已识别的跨项目依赖关系，以及敏捷团队负责人通过参加其他团队的关键迭代会议所了解到的其他新情况。项目经理参加这个会议是为了了解跨团队的依赖关系，并确定项目团队是否需要他们帮忙解决问题。

　　联合迭代演示——在每次迭代结束时，团队会向项目发起人演示可以工作的软件。演示是由几个团队联合起来做的。应该按照客户在生产系统中所需遵循的流程来演示，这样才有意义。即使流程需要在几个团队间流转，也要按照系统的正常逻辑顺序来确定迭代演示的顺序。让所有团队参加系统全程完整的演示非常重要，因为软件是所有团队共同完成的，而且也是对大家工作成果的尊重。演示是庆祝迭代成功和认可你同事们工作的好时机。在迭代演示时，项目经理的主要职责是帮忙让演示顺利进行。这是项目经理当服务型领导的时候：如果投影仪坏了，或者电话会议时电话出问题了，项目经理要负责解决这些问题，以便让团队能专注于向发起人演示他们的成果。

　　联合回顾——迭代结束后，每个团队都要回顾他们的工作过程以便于以后工作的改进。这时项目经理和敏捷团队负责人都可以当回顾会议的主持人。我发现让敏捷团队负责人当主持人是很有帮助的，因为在下次迭代中主要由他们负责帮助团队进行改进。除了单个团队的回顾外，整个团队还应该参加联合的回顾。虽然没必要每次迭代都召开这样的回顾会议，但是我建议至少每隔一个迭代要召开一次。联合的回顾关注团队内的协作情况，以及为了改善工作环境、提高工作效率、促进沟通和协作，团队能做哪些改进工作。

　　第二个信封和第三个信封#p#分页标题#e#

　　预测性的元素位于信封框架的第二层和第三层。第二层信封包含的是是项目中要计划和管理的瀑布模式中的元素。硬件部署就是一个很好的例子。第三个信封包含的是项目与企业中的其他项目组合要交互的工作内容。在这一层，项目经理需要与外部项目协调、处理企业发布计划和企业报告。

　　第二个信封 预测性元素

　　预测性元素的这个信封包含了没有在敏捷模式中管理的项目工作。一个很好的例子是为项目获取新硬件。期望新硬件在迭代一开始就采购好、并且在迭代期间就安装好，这是不合理的，尤其是当迭代非常短时，例如只有1-2周的迭代时间。按月来衡量硬件的交付周期并不罕见。采购和实施硬件的工作不先做好充分的计划，对于项目经理来说是不够专业的，预测性元素所在的信封提供了一种框架来管理这类工作。团队在做高层次的初步计划时，就应该列出迭代对预测性元素的预期要求。此外，如果是按顺序式模型管理项目的，那么企业测试是在这个信封里的。一些组织虽然能够按迭代管理企业测试，但是如果需要配合企业发布委员会来管理全部的发布时间表，那么企业测试也应该放在第二个信封里。但是，如果团队能够按迭代模式交付成果，并且按迭代模式执行单元测试/组件测试和集成测试、向最终用户演示可工作的软件，企业测试执行起来很可能会更快。我看到过给定六周时间来做的企业级用户可接受性测试，按迭代模式只用了20分钟就完成了。

　　第三个信封 企业整合

　　第三个信封包含了敏捷项目跟其它的企业项目组合、项目发起人、督导委员会、高管交互所做的工作。在信封框架的这一层，项目经理负责项目管理、解决项目和项目组合层级的问题。目的是让敏捷团队可以完全不必关注这些事情。例如，项目经理负责与职能经理一起识别并解决项目组合与项目的问题。在处理跨项目的依赖关系时，可能需要由项目经理和敏捷团队负责人一起识别依赖关系并确定它们对项目的影响，重要的是避免让正在工作的敏捷团队受到影响。如果确实需要敏捷团队参与，建议最好等到迭代计划完成了再打断他们，以便让团队能专注于执行迭代工作。

　　这一层也包含了项目经理向企业管理层汇报项目状态的工作内容。项目经理需要像翻译一样，把敏捷指标转化成可以接受的企业报告的结构。敏捷对完整、勇敢和透明的关注，使项目经理很容易就能获取所要求的任何报告结构的信息，包括挣值(Suliaman，2007)(Rusk，2009)。可能出现这种情况：随着组织中成功的敏捷项目越来越多，企业开始修改报告的结构，以包括进一些敏捷的元素。不过无论如何，项目经理都要清楚地向企业汇报项目的健康状况。这些报告可能也会用来向管理与督导委员会作汇报。在信封框架的这一层级上，项目经理和项目发起人一起来管理项目和产品的关系，并确保项目范围、进度和预算是受控的。

　　最后，第三个信封还包含部署项目交付物到企业生产系统的内容。因为目标是要限制对敏捷团队工作的影响，这可能是管理敏捷项目最棘手的部分。项目经理和敏捷团队负责人应该一起制定项目发布计划。敏捷团队的最终目标是实现无缝部署，这样就不会对工作中的团队产生影响。但是，很可能项目团队需要从迭代中分出一部分时间用于规划、部署和签出发布包。如果可能，应该从迭代中分配一小部分储备时间(减少他们的预留时间)，从团队专门抽出一个人来负责处理部署问题，以使部署中出现任何问题都能被迅速解决。

　　总结

　　在瀑布式和敏捷式项目混合的环境中使用敏捷方法是复杂的。项目经理必须高度注意产品需求和项目需求的区别，按项目发起人的委托来管理项目的范围、进度和预算。项目经理可以使用信封方法来维持三者之间的关系：敏捷团队、项目中的非敏捷元素、企业中其它因素。

　　我经常被问到在敏捷环境中，项目经理的角色是怎样的。他们害怕在敏捷项目中不再需要项目经理这个角色了。在业务背景简单(如小型或中等规模的业务)的小型敏捷项目中，项目经理是不需要的。想要指挥项目团队工作的项目经理在敏捷项目中也没有合适的角色。怀着为项目服务的心，并且愿意迎接更大型项目的挑战的项目经理，在敏捷项目中将有不止一个角色。对项目的成功他们是必不可少的。

　　关于作者

　　Joseph Flahiff是一位广受欢迎的演说家和项目交付顾问。他通过综合敏捷、精益和新兴的项目管理方法，帮助企业组织改善他们的项目交付物。作为一位在敏捷和传统项目管理方面具有15年以上经验的专家，Joseph在世界各地讲授敏捷模式和瀑布模式的整合方法。关于在企业中敏捷项目管理最新趋势的视频、文章和免费资源可以在他的Whitewater Projects博客中找到。

　　参考文献

　　A tale of two teams. (2008, April 25). Retrieved January 29, 2011, from Youtube.com

　　Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., et al. (2001, 2 11=13). The Agile Manifesto. Retrieved 1 21, 2011, from agilemanifesto.org

　　Cassidy, D. (2002, 5). Quantum Mechanics: 1925-1927 THE UNCERTANTY PRINCIPLE. Retrieved January 20, 2011, from American Institute of Physics

　　Ebert, D. C. (2009). Software Product Management. Crosstalk the Journal of Defense Software Engeneering, 15-19.

　　Hunt, A. (2010, September). The Agile Manifesto a decade later. (J. Flahiff, Interviewer)

　　Legorreta, C. W. (2009, April 2). Beyond waterfall and agile methods:Towards a new contingency model for IT Project Management. Retrieved January 30, 2011, from Social Science Research Network

　　Rusk, J. (2009). Earned Value for Agile Development. Retrieved January 30, 2011, from agilekiwi.com

　　Schwaber, K. (2010). Scrum.org. Retrieved January 30, 2011, from Scurm.org

　　Schwaber, K., & Sutherland, J. (2010). Scrum Guide. In K. Schwaber, & J. Sutherland, Scrum Guide (p. 5). scrum.org.#p#分页标题#e#

　　Suliaman, T. (2007, October 5). AgileEVM: Measuring Cost Efficiency Across the Product Lifecycle. Retrieved January 30, 2011, from InfoQ

　　van Bennekum, A., Hunt, A., Cunningham, W., Schwaber, K., & Cockburn, A. (2010, 2011). Whitewater Projects Podcasts. (J. Flahiff, Interviewer)

　　Version One. (2009). 2009 State of Agile Survey. Retrieved 1 21, 2011, from VersionOne.com

　　Version One. (2010). 2010 State of Agile Survey. Retrieved 1 21, 2011, from VersionOne.com

　　Wikipedia. (2011, 1 5). Product management. Retrieved 1 21, 2011, from wikipedia.com

　　Womak, J. P., & Jones, D. T. (1996). Lean Thinking. Simon & Schuster.

　　Wysocki, R. K. (2009). Effective Project Management: Traditional, Agile, Extreme, 5th Edition. John Wiley & Sons.

　　实际上，既然是软件开发，在所难免得面临工具的选择，而且很多优秀软件实践离开强有力的工具支持都玩不转。在如今的软件开发世界中，工具(这里谈的是软件工具)层出不穷，数不胜数，那么到底该怎么去选择适合的工具呢?

　　本文将根据我十几年的企业级软件开发经验给出一点建议，和大家一起来探讨敏捷和工具(特别是在企业实施中的工具)这个话题。

　　为了避免不必要的麻烦，文中尽量用开源软件作为介绍，但这并不是说我排斥商业软件，恰恰相反，在很多时候，只有商业软件才提供了你需要的功能(当然大部分情况下开源软件会很快迎头赶上)。

　　背景知识：应用程序生命周期管理

　　聊到软件开发中的工具，一般都会提到这个术语“应用程序生命周期管理(Application Lifecycle Management ，ALM)” ，说句老实话，有点烂，谁都想把自己往上靠，谁都有自己的一套说法，图1为我心中贯穿企业开发项目全程的ALM全局观。

　　图1中列出了ALM中的各个子系统，以及我略有研究的相对应工具的名称，让我们一起先来简单地过一遍整个过程。

　　图1 开发项目中应用程序生命周期管理及其工具

　　产品开发始于一定的需求，需求有好几个层次，从产品需求到项目需求，进而产生出用户故事(User Story)， 然后团队会分解出任务(Task)。团队开发者利用IDE(如Eclipse)去完成相应的代码，单元测试完成后，再推送到代码库(git)，这些和软件配置管理(Software Configuration Management，SCM)相关。

　　构建系统会从代码库中获取最新的代码，进行编译、打包、功能测试和系统测试，可以设置在质量系统中显示一些相关信息，如果一切顺利，甚至能直接上传到在线系统更新上线。此外不管是开发中还是运行中一般还都会有一个缺陷管理系统。

　　BugZilla大家应该很熟悉了，用Redmine的人少一些，但它实际上是一个非常灵活的项目管理系统，国内也有越来越多的公司在使用了，Nexus是一个Java软件包的管理工具，需要和Maven结合使用，Sonar是一个Java项目的质量控制工具，它集成了如单元测试、覆盖率、静态质量检查等内容。为什么任务管理下的Redmine有红叉呢?我们稍后会解释。

　　限于篇幅，本文只会谈到其中的一部分工具。作为参考，可以阅读Manning出版社的新书《Agile ALM》，它对SCM、单元测试、功能测试等话题进行了更深入的探讨。

　　敏捷中有些工具是必需的

　　如果你说敏捷实施大半年了，但持续集成 (Continuous Integration，CI)服务器却还没有架起来，那我实在是不晓得你都在敏捷些啥东西了。无论你究竟“信仰”哪种敏捷，产品开发各个方面的自动化(Automation)和持续集成都必不可少。要了解持续集成，可以看看Martin Fowler的文章，可谓白皮书级别的经典，有中文翻译版。

　　使用CI就一定会用到CI服务器，可选的有很多，其中Jenkins是现在最流行的一个，而且架设起来也很方便。它是从Hudson继承而来(自从2011年5月Oracle决定把Hudson捐献给Eclipse组织，两者的关系和将来的发展方向也可能带来更多变数)。

　　在Jenkins构建服务器中，可以定义任务(在Jenkins中叫job)，以完成一些构建步骤(如签出代码、编译、各种类型的测试、打包等)，它有极丰富的插件(plugin)资源作为支撑，可以来集成产品软件开发的各个要素，它把你所需要的一切都自动化起来。

　　图2 Jenkins项目自己的Jenkins构建服务器

　　在Jenkins构建服务器的首页，每个任务还都有一个天气图标表示其状态，非常直观，例如“太阳”就代表着一切正常(至少从构建结果来看)。它是产品项目开发的晴雨表，项目状态是否正常一目了然。不管是对Jenkins不了解还是想提高，我强烈推荐阅读John Ferguson Smart的Jenkins开源书：Jenkins: The Definitive Guide。

　　对敏捷来说，并没有“CI服务器要还是不要”一说，它就是必须的，一定要好好地实施。基于持续集成再往前走，就是持续交付(Continuous Delivery)了，这也是敏捷的一个新热点，其中加入了很多新元素(如自动化验收测试、持续部署等)。

　　别让工具牵着鼻子走

　　工具很重要，但会不会有些误区呢?当然有，我们一起来看个我经常碰到的一个例子。

　　讲到敏捷实施一直都会提到白板(Whiteboard)的使用，先得提醒大家，它也是一个“工具” ，白板的其中一种用法叫任务白板，主要是提供给团队使用的。

　　图3 每日例会用的任务白板(图来自《硝烟中的Scrum和XP 》一书)

　　图3就是常见的任务白板，团队的需求，一般是用户故事(User Story)，被放在最左边一栏“NOT CHECKED OUT”，作为团队一个迭代的输入，然后分解成任务(Task)用报事贴(俗称黄贴)贴在白板上“CHECKED OUT”那一栏，并签上自己的名字，就算是领任务啦。当做完了一个任务就把它(黄贴)挪到下一栏“DONE!:o)”，代表做完了，最右边一般还会留出部分空间，用来记录进度条和注意事项来提醒团队一些重要的事情。

　　如果说Jenkins构建服务器是产品开发的晴雨表，那么任务白板就是团队开发的晴雨表。

　　一般一大早在每日的站立会议(Daily Standup Meeting)上，整个团队所有人都会围在白板前，分享所负责任务的进度，顺便挪动一下任务到相应的状态栏，用这种方式能够减少很多不必要的汇报型会议，而且团队成员也能很快地了解开发的整体状况。相信如果某个黄贴在白板上连着三天都没动，团队里一定会有人站出来帮忙的。(没有?!那还是先组织他们参加团队合作的培训吧。)#p#分页标题#e#

　　有时候团队坐得比较分散，或者有人喜欢流行的在家办公方式，这时可能会开始使用一些图形化的电子白板来管理团队任务，大家对着屏幕介绍进度，效果似乎还不错，其他人(包括经理们)也非常高兴，因为他们可以随时从网上了解到团队的进度了。慢慢地，面对面的时间看起来也可以节省下来，只要窝在座位上点点鼠标，挪挪电子黄贴(如果支持漂亮的拖拉就更好了)就已经足够了。

　　这是敏捷的好实践吗?

　　是否嗅到了一点怪味道?它就是我想谈的工具带来的误区，电子白板会削减团队之间的沟通，降低团队的透明度，违背了敏捷重视人和团队的原则。如果你的团队成员不经常去更新电子白板上的任务时间，慢慢地你看到的都是不太准确的信息了。有人可能说我们还是面对着电子白板开每日站立会议呀，那我希望你有个很大的屏幕吧(否则这样子效果会更差)。

　　那为什么没说它不对呢，因为在一些场合下，它还是有作用的。关键是团队要能充分认识到它的局限性，因此我极力反对在团队组建初期用电子白板，可以等团队充分领会到敏捷中人与人沟通的重要性后再引入。

　　这也是在图1中特意用红叉提醒不要用Redmine来管理任务(这个白板功能的插件也很差，因为没人用)。

　　所以要了解你的需求，不要让一些工具牵着鼻子走，要了解敏捷实施的目的，否则出了问题还以为工具不到位，拼命要更强的功能，结果陷入大误区。

　　有些工具会带来意想不到的好处

　　传统的敏捷著述中通常会提到CI的部分，然而工具的运用并不限于此，例如我在实际项目中用到的Gerrit，它非常契合敏捷的宗旨，也给我们带来了意想不到的好处。

　　代码审阅是一个不错的敏捷开发实践，让人非常头疼的是实施。大企业中通常是制定出一大堆相关的规范和流程来指导代码审阅。我听说好多公司都会把代码打印出来，进行走读，这可真是累啊。这种方式会给人不信任的感觉，而且应该是挺浪费时间的。

　　结对编程(Pair Programming)也是非常好的一种代码审阅的方式，值得好好地学一学，只是我对它并不太感冒，体会是在大企业实行结对编程的难度很大，当然如果能找到合适的推动者，那还是可以尝试尝试的。

　　那看看开源社区是怎么解决这个问题的呢，使用的又是什么工具呢?Google的Android系统是现在非常热门的开源项目，它的代码审阅(包括贡献者的代码)使用的是Gerrit，非常棒的东西，在自己的企业中架设起来也非常方便，我一用就爱上它了。

　　Gerrit是一个基于Web的代码评审和项目管理的工具，面向基于Git版本控制系统的项目，所以如果你没用git(干嘛不用呢)，就没法用Gerrit了，接下来来看看在Gerrit中怎么实施代码评审的。

　　● 首先开发者(贡献者)的代码变更通过 git 命令被推送(push)到Gerrit管理下的Git 版本库，推送的提交转化为一个一个的代码审核任务(见图4)。

　　● 代码审核者可以通过Web界面查看审核任务、代码变更，通过Web界面做出通过代码审核(Review)或者拒绝(Reject)等决定。

　　● 测试者(一般可以设定为CI服务器执行)可以通过访问来获取(fetch)代码变更进行相应测试，如果测试通过，就可以把这个评审任务设置为校验通过(Verified)。

　　● 最后经过了审核(Review)和校验(Verified)的代码变更可以通过Gerrit界面中提交动作合并到版本库的对应分支。

　　相比代码走读，它的好处在于，审阅动作发生在向主干提交代码前，可以只看变更的部分显得很贴心，网上随时随地审阅起来也很方便，这也是有别于结对编程的一个好处。

　　任何人都可以审阅提交的代码，整个团队的代码都一目了然，审阅起来更方便，非常符合开放、透明的敏捷精神。使用之后能够显著提高代码质量，甚至于等到习惯了以后，代码不被审阅一下，都觉得实在是不好意思提交代码到主干上去。

　　Gerrit中，通过特定分支，任何审核任务的代码变更都能访问，所以如果需要细看或是合并到本地都异常方便。

　　Gerrit刚开始实施可能会有点不习惯，毕竟整个工作流有所变化，因此实施时需要通盘考虑。

　　如上只是近期我特别喜欢的一个工具，其实类似的工具还有许许多多，这不过是沧海一粟而已。

　　总结

　　水能载舟，也能覆舟，工具和敏捷的关系亦如此，下面我给出几点建议：

　　● 积极尝试新工具，如今的软件开发世界中，工具层出不穷，要不断与时俱进，了解最新动向和如何用有效的工具去辅助敏捷的实施，在自己的软件开发环境中去尝试和了解这些工具，尝试这一点很重要，不要只看说明或戴有色眼睛去看待这些工具，应该通过实践摸索找到最适合你的选择。

　　● 人总是第一位的，要了解你的团队，了解他们的需求，有些时候甚至可以为了团队，冒险一下采用新技术、新工具，这样可以提高团队的凝聚力(敏捷要素之一)。我待过的一些部门推动Git时，就是这么来的，很多时候过多的讨论其优缺点反而是浪费时间，不如多花点时间多试试。

　　● 实施敏捷也离不开组织的支持，特别大型企业涉及到的人很多(可能水平不一)，这时候推动者就必须用专业的手段建立一个持续渐进的工具引入过程，这样会使得实施更容易些。

　　相信不少软件开发公司都存在质量管理部门。而且，如果一个公司稍微正规的话，一定会使用一个缺陷跟踪软件系统，比如开源的Bugzilla，或是IBM的ClearQuest等等。那质量管理部门是如何跟踪和控制软件质量的呢?毫无疑问，需要通过软件缺陷跟踪系统，这倒也没有什么问题。但问题在于质量管理部门是如何看待和处理缺陷跟踪系统所提供的缺陷统计数据的。

　　有的公司质量管理部门的地位很高，可能是因为公司质量管理部门在公司地位的高低代表了公司对于产品质量的重视程度，而这种公司质量管理部门往往是向高层管理直接负责的。在现实生活中存在这么一种怪现象：质量管理部门只关心缺陷的数量，而不关心缺陷数量的上升或是下降是由什么原因造成的。也就是说，对于这种质量管理部门，缺陷只是一个数字而已。在这种操作模式下，缺陷的修复完全是开发部门的事了，那么就存在开发部门为了让数字更好看而采用一些短视的行为来减少缺陷数量，甚至于造假。

　　对于这种怪现象，你觉得质量管理部门对于公司的质量管理有意义吗?从我个人的角度来说，我觉得没有意义。表面上产品质量是掌握在质量管理部门的，或者说质量管理部门应当对产品质量负责，而实际上质量还是掌握在开发部门，也就是说质量管理部门在公司的质量组织架构中并不起作用。此外，由于方法不对，往往很容易造成质量管理部门并不了解问题的复杂性，只是一味的要求开发部门将缺陷数量在很短的时间内降下来。而开发部门也万般无奈的采用甚至是造假的方式去完成质量部门所提出的不可能完成的任务。由此看来，这种质量管理方法不但没有意义，还将大家都整得心力憔悴。

　　那质量管理部门应当如何在公司的组织架构中起作用呢?我想首要的一点是，质量管理部门应当关心缺陷数量的上升和下降。比如，当缺陷上升时，应当了解为什么上升。是因为产品的新功能开发从而引入了新的缺陷呢?还是产品以前遗留下来的缺陷现在被发现了?出现问题的模块是不是总是其中的某一个模块呢?等等。如果问题总是出现在一个模块，那么质量管理部门可能需要考虑督促开发部门对其进行重构，从而从根本上去解决问题。反之，当缺陷数量下降时，质量管理部门也应当分析是什么原因，而不是简单的乐观。我们说采用这种方式，才能使质量管理部门真正的对产品质量负责。

　　对于上面所提出的解决方法，可能有人要说，那不是对于质量管理部门人员的要求很高吗?即要懂流程，又要懂软件开发，这种人似乎很难找啊!其实，我们可以采用其它的方式。比如，公司成立一个软件专家组。这个软件专家组可以应质量管理部门之邀对某一缺陷很多的项目进行分析，从而帮助质量管理部门决策其解决方法是什么。那我们如何挑选合格的成员组成专家组呢?这个问题我就不能回答了，但从这一问题我可以看出：人才是首要的!

　　关键词：软件;质量;管理项目经理圈子

　　在软件开发团队中,由于质量被视为软件产品的生命.那么什么是软件质量?软件质量:与软件产品满足明确或隐含需求的能力有关的特征和特征的总和,它反映了三个方面的问题:1.能满足客户需求的特性之全体;2.利用各种质量标准体系,指导软件开发人员开发软件;3.是否满足用户隐含需求.软件质量管理的目的是建立对项目的软件产品质量的定量理解,和实现特定的质量目标;着重于确定软件产品的质量目标、制定达到这些目标的计划,并监控及调整软件计划、软件工作产品、活动及质量目标以满足顾客及最终用户对高质量产品的需要及期望.

　　1　软件质量管理的现状

　　在现实软件开发过程中,许多软件产品却时常陷入质量低下、甚至软件不符合用户需求的旋涡.究其根源,有以下几个方面:项目经理圈子

　　1•1　软件质量保证技术(审查、复审和测试)没有贯穿到整个软件开发全过程中去.项目管理者联盟

　　1•2　在于这些软件产品对其质量内涵的把握,仅仅停留在减少软件运行错误、加强软件测试,避免软件缺陷的一般性层面,而对整个软件开发生命周期的全过程质量管理,缺乏总体架构.转自项目管理者联盟

　　1•3　测试管理的一些误区也会导致严重的质量问题.没有按照测试原则进行尽早测试、连续测试与自动化测试.是测试本省变得的形式化.

　　1•4　质量是全过程的,不仅是测试.质量管理者应该将质量控制与保证着眼于整个软件开发生存周期内.而事实上,质量管理者仅仅认为通过严格的测试就可以保证软件质量.bbs.mypm.net

　　2　软件质量保证bbs.mypm.net

　　2•1　在软件开发中,可以采用以下措施保证软件的质量;

　　2•1•1　审查.在生命周期每个阶段结束之前,都要使用标准对该阶段生产的软件配置进行严格的技术审查.

　　2•1•2　复查和管理复审项目管理论坛

　　复查是检查已有的材料,以断定某阶段的工作是否能够开始或继续;管理复审是向开发组织或使用部门的管理人员,提供有关项目的总体状况、成本和进度等方面的情况,以便他们从管理角度对开发工作进行审查.

　　通过测试计划、测试过程与测试结果对软件质量进行保证

　　2•2　软件质量保证活动

　　以上各项活动内容都须写入质量保证计划,并由质量保证小组监督实施.由此可见,质量保证既是技术活动,也是管理活动.blog.mypm.net

　　2•3　软件评审

　　评审是以提高软件质量为目的的技术活动.要通过对软件的规格说明、可靠性、性能实现、可修改性、可扩充性、可移植性、可测试性、可复用性以及评审的实施等方面对软件项目做好严格的评审,以确保软件质量.

　　2•4　采用质量保证标准bbs.mypm.net

　　质量标准用于实现质量管理的组织结构、责任、规程、过程和资源.采用ISO质量保证模型.可以用于质量计划、质量控制、质量保证和质量改经所需的组织结构、规程、过程和资源.

　　2•5　结构化的软件测试

　　经过严格的软件测试,尽可能找出软件计划、总体设计、详细设计、软件编码的错误,并加以纠正,才能提高软件的质量.测试要覆盖整个软件的生存周期,而不限于程序的编码阶段.转自项目管理者联盟

　　2•6　软件维护转自项目管理者联盟

　　采用结构化维护,完整的软件配置为基础,通过完善性维护、纠错性维护、适应性维护及预防性维护提高软件质量.项目管理者联盟

　　3　质量管理实施

　　3•1　项目进度的质量保证转自项目管理者联盟

　　项目进度是项目进行是否顺利的最直观表现.显然在项目开始之前,项目开发计划是必须的.如果项目开发计划的制定的是完全合理的,那项目进度也就真正表达了项目与最终的交付使用之间的距离,然而要制定完全合理的项目开发计划几乎不太可能.可见要保证项目进度,首先要保证项目开发计划尽可能合理.

　　实施SQA的目的

　　软件质量保证的目标是以独立审查方式，从第三方的角度监控软件开发任务的执行,就软件项目是否正遵循已制定的计划、标准和规程给开发人员和管理层提供反映产品和过程质量的信息和数据，提高项目透明度，同时辅助软件工程组取得高质量的软件产品。主要包括以下四个方面：

　　● 通过监控软件开发过程来保证产品质量;blog.mypm.net

　　● 保证开发出来的软件和软件开发过程符合相应标准与规程;

　　● 保证软件产品、软件过程中存在的不符合问题得到处理,必要时将问题反映给高级管理者;

　　● 确保项目组制定的计划、标准和规程适合项目组需要，同时满足评审和审计需要;项目管理者联盟

　　除了以上四点之外，我们还希望SQA能作为软件工程过程小组(SEPG)在项目组中的延伸，能够收集项目中好的实施方法和发现实施不利的原因，为修改企业内部软件开发整体规范提供依据，为其他项目组的开发过程实施提供先进方法和样例。项目管理培训

　　对SQA人员的素质要求

　　1. SQA人员(有时简称SQA)要有很强的沟通能力。从实施SQA的目的中可以看出，SQA不在项目中，是独立于软件项目的第三方，但他要了解项目的开发过程和进度，捕捉到项目中不符合要求的问题，这就要求SQA能够深入项目，和软件开发经理以及项目组中的开发人员保持很好的沟通，这样才能及时获得真实的项目情况。

　　2. SQA要熟悉软件开发过程。作为SQA，既然要确保项目组制定的计划、标准和规程，要符合项目组要求，那么SQA首先自己就要了解软件项目开发过程，以及企业内部已经有的开发过程规范。

　　3. SQA本身要有很强的计划性。SQA一方面要监督软件项目组编写计划，另一方面SQA自身的工作也要有计划，并且能够按照计划开展工作。

　　4. SQA要能应对繁杂的工作。作为SQA，在跟踪项目进行过程的时候要对项目组的很多工作产品进行审计，而且会参与项目组中的多种活动。同时一个SQA还有可能会面对多个项目组，所以任务相对繁杂细碎，这就要求SQA在处理这些事物的时候要耐心细致。

　　5. SQA要客观，有责任心。作为第三方对项目过程进行监督，SQA要能保持自己的客观性，不能一味讨好项目经理，也不能成为项目组中的宪兵，否则会影响工作的开展。对于项目组中多次协调解决不了的问题，能够向项目的高层经理进言，完成SQA的使命。

　　以上五点是作为SQA应该具备的基本素质，除此之外，一个好的SQA还应该在软件开发过程中作为开发人员或测试人员参与过一个或多个环节，这样他们才能在过程监督中比较准确地抓住重点，同时他们的意见和提出的解决办法也会更贴近项目组，容易被项目组接受。

　　关键词：质量管理，质量计划，质量控制，质量保证;

　　一、研究软件项目质量管理的背景

　　提起如今的IT项目，软件工程倍受关注。而软件的质量更是众人关注的焦点，因为目前还没有一套完善的评估标准。甚至有人提出，现在的软件开发根本提不上是“工程”，因为它太稚嫩了，还没有一套成熟的标准来比照;因而软件项目极易出现失败或失误。大量实践证明，软件工程项目的成败，通常是因为管理问题(协同工作的能力)，而不是技术上的问题。要想做一盘“完美”的软件大餐，质量管理的作用是不言而喻的。

　　二、软件质量管理的主要内容

　　质量管理主要包括三个过程：质量计划制定、质量保证和质量控制。

　　质量计划：是质量管理的第一过程域，它主要指依据公司的质量方针、产品描述以及质量标准和规则等制定出来实施方略，其内容全面反应用户的要求，为质量小组成员有效工作提供了指南，为项目小组成员以及项目相关人员了解在项目进行中如何实施质量保证和控制提供依据，为确保项目质量得到保障提供坚实的基础。

　　质量保证：是贯穿整个项目全生命周期的有计划和有系统的活动，经常性地针对整个项目质量计划的执行情况进行评估、检查与改进等工作，向管理者、顾客或其他方提供信任，确保项目质量与计划保持一致。

　　质量控制：是对阶段性的成果进行测试、验证，为质量保证提供参考依据。

　　在软件实施项目中，质量保证对应于技术评审与过程检查，质量控制对应于软件测试等工作，如图1所示。

　　图1 全面软件质量管理模型blog.mypm.net

　　2.1 质量计划编制

　　现代质量管理的基本宗旨是：“质量出自计划，而非出自检查”。只有做出精准的质量计划，才能指导项目的实施、做好质量控制。www.mypm.net

　　编制项目的质量计划，首先必须确定项目的范围、中间产品和最终产品，然后明确关于中间产品和最终产品的有关规定、标准，确定可能影响产品质量的技术要点，并找出能够确保高效满足相关规定、标准的过程方法。编制质量计划通常采用流程图、因果分析图等方法对项目进行分析，确定需要监控的关键元素，设置合理的见证点(W点)、停工待检点(H点)，并制定质量标准：项目管理者联盟文章

　　1.拿下项目，需求调研分析，编写需求用例(如果客户没有要求，需求规格说明书都不写)

　　基本上需求用例就是说明什么人，做什么事情，怎么做，达到什么目的，有什么要求这些。

　　2.然后分析领域对象，分析业务流程和场景。并最终生成数据库物理模型。

　　3.概要设计，其实也没什么，就是数据库结构，还有用例描述加一些时序图。

　　4.根据需求用例，编写测试用例。

　　5.开发人员进行开发，有时项目紧的时候，单元测试都不写(这个项目没有明文要求)，主要靠开发人员个人意愿。

　　6.根据周期定期进行打包测试。我一般会每周build两次，亲自操作一下业务流程，有问题提出修改。这个过程测试人员未参与。

　　7.测试人员进入，按模块完成的先后顺序，持续的测试修改。

　　以前的项目基本上是采用领域驱动的方式进行一步步开发的。现在打算采用TDD方式，现有一些细节疑问，打算请教一下实施了TDD的各种牛。

　　1.TDD方式是不是不用写需求说明书了?

　　2.分析领域对象，分析业务流程和场景。并最终生成数据库物理模型。这一步是不是在TDD之前完成?

　　3.不写概要设计，由需求用例直接跳入TDD开发?

　　4.测试用例是不是需求用例的细化和规范?

　　5.TDD中的test是基于单元测试，还是基于需求测试?

　　6.如果是单元测试，自然由开发人员完成。如果TDD是基于需求测试，那么开发人员是否需要测试人员配合?

　　最后一个问题是：大家有结对编程的习惯吗?在实践过程中结对是否高效?反正我是觉得结对不会太高效的，主要是基于项目人员的配置本来就有成本在那里，而且人员水平也不一样。我的观点是一个经验丰富的带一两个新手共同开发一个模块，但并不需要结对的方式。

　　ok,问题完了。等大家拍砖。

　　问题补充

　　humaeks 写道

　　个人的几点愚见，有点零乱：

　　1. 首先明确unit test和功能测试不一样，参与的人也不一样。

　　2. 设计完了再入TDD阶段，写UT的过程其实也是校验测试的过程，如果测试不好写，就需要review设计。这里插播一下，既然考虑采用DDD，应该先出来CDM，然后java OO与CDM对应，剩下才是设计物理模型和持久层

　　3. 传统意义上的TDD指的是unit test。背后很重要的一个思想是先写测试有助于写出clean code that works, 或者说是just enough的代码，实践上需要权衡。对程序员的编程技巧要求高，在我的团队成员中，从零到真的能写出“单元”测试，需要每天抽一小时1 on 1 code review一个月以上。

　　需要程序员有逻辑拆分以及一些coding技巧，看implementation patterns / clean code 这两本书会有帮助，但关键还是每天的code review给及时反馈。

　　4. 100%覆盖是不切实际的东西，尤其是初次尝试TDD，可以采用以点带面的方式，让部分成员先尝试到TDD带来的好处，然后在团队中传播;

　　5. 成员水平不一样可以采取结对方式提升人员水平，但成本回收周期长，基本不会对本项目(3月内的项目)产生benefit，但遇到有好苗子要坚决培养，否则日后还是会死，留不留得住人，就是另外一个管理topic了。

有人看到这篇文章后也分享了团队实践Scrum后的心得，他觉得在他的团队里不适用Scrum有几个原因：

1.大家对技术不熟悉，因为目前主要的工作量在前端。大家以前都是做java后台的，对js不熟悉，把js当作java来面向对象。而且没有一个成熟的控件库使用。

2.没有在项目开始前做足够的技术调研。本来，应该有个architector来做这些事情。我觉得什么TDD，就是胡扯。没有前期调研，什么都是假设我们能做到，然后就去break down,然后就是估时间，只能是瞎估。估完了，真正implement的时候才发现，一堆东西stand in my way。

3.人的本性就是利己。如果一个team的performance，不和salary挂钩，大家凭什么会齐心协力，deliver更快，更好。目前情况下，scrum只是pm push developers的工具。现在，大家都想到偷懒的方法，就是尽量多估一些时间，或者implement的时候粗一些，反正都是一个个task领的，谁知道bug是谁的code导致的。以前如果一个人responsible for one module,就很容易知道谁的代码质量不高。

4.user story 拆分的不好，容易漏掉很多东西。大家现在都关注task,只想着做完就拉倒，根本不会想着各个task之间的边界和交叉影响。而且，大家现在就习惯看看task就做了，根本不会去看case,所以有些重要的flow全都漏掉了。

5.pm就是scrum master,整个team就是在一个不平等的环境下，scrum只不过是pm试验的工具，能在她的简历上添砖加瓦。我们只不过是小白鼠。

另一种观点认为，Scrum适用于一帮资深程序员组成的team，每个人都是牛人，每个人都有激情干活，这样才work。在国内大家只是干活拿工资，没什么激情，很不适合Scrum。

Scrum就是一把双刃剑，如何用、是否合适还是要看具体的情况。那么，您的团队是否采用过Scrum模式，效果如何呢？

　　因为本人经常站在Agile的风口浪尖，所以我有必要也来一个“免责声明”。Shit!其实我想来的是“不免责声明” ——下文中的九大原因是对中国的各种Agile实践者咨询师不注重实际只重方法论的批判，本人必然要和那种只以流程方法论为中心的软件开发斗争到底。其实我没有那么嚣张，我只是想说，下面的这些东西相当的现实。希望各种Scrum的实践者们认识到这些问题，从而可以让你们明白软件开发中的人的重要性。

　　Reason 1: Scrum 的基石是相信人。创造一个安全的环境，这样每个人都能相互学习，相互直言。但是，这是不行的，这世上有很多人并不关心这些，而且政治和竞争到处都是，办公室里无小事，你和别人交心，你相信他们，最终受伤的你自己。你真的以为那里有空间让你可以去犯错，去冒险吗?别天真了!你啊，too young, too simple, sometimes naive!

　　Reason 2: Scrum 认为只要给员工足够多的自由员工就能做得最好。这该死是理论是基于什么玩意?不可能，人的天性是懒惰的，他们才不会把事做好的，他们只会做相应报酬的工作量，还可能基本还达不到其相应的报酬，大多数人都在混日子啊。尤其是和经理比起来，谁不想能尽快地成为经理或Team leader啊，因为那样他们就可以即不干活，又挣得多。另外，你给他们自由，你就会发现，他们会只会做他们感兴趣的事，要么聊QQ，要么打游戏，看闲书，反正不干正事。直到你催了，他们才动一动。

　　Reason 3: 因为前面的原因，所以，我们仍然要把一个PM放在Scrum团队的上面做管理，这样才会有产出。于是，PM给团队分配任何，管得细枝末节，事无巨细，天天让你做进度汇报，等等。直至把团队拖垮。

　　Reason 4: Scrum 只不过是一个流程。这世上有太多的流程，尤其是那那些操CMMi的公司。几乎所有玩CMMi流程的公司，你都能看到的是员工都是那一副副苦逼的脸。所以，Scrum的流程同样会这样。因为这些都不是开发团队自发出来的，而是上面管你喜欢不喜欢按给你的。 Scrum 根本不可能增进你的软件质量和技术，只能是优秀的人才才可能!使用Scrum的公司都是些吝啬鬼，他们不愿花大钱招优秀的人，他们妄图使用Scrum这种东西让现有的这些廉价劳动力发挥更大的生产效率，Scrum成了push程序员最有用的工具。

　　Reason 5: Scrum delivers ‘business value’。不是这样的，实际上，Scrum不可能。这有很多原因。真正了解业务的那帮人根本不可能加入项目团队，那些人谁TMD愿意和苦逼的技术人员加班啊。 那些人喜欢和我们的用户吃吃喝喝，花天酒地的，根本不会和你们那些奇怪的东西(如：backlog)或是那堆ugly的内向古怪的技术人员打交道，更别说什么技术了。所以，你的团队就像一个客服团队或救火队一样疲于奔命。

　　Reason 6: 一个敏捷的团队应该是持续进步的。这就是为什么Scrum总是在问什么干得好，什么需要改进，并定义行动方案。你真的以为员工想进步吗?让他们不得不去想想自己和团队怎么进步，然后他们还不得不去执行行动方案。别天真了，人的天性是不喜欢改变的，人的天性是习惯于一些按部就般的事的，也许那样做令人讨厌，但是人家还是能干点东西出来。如果你逼着人家改变，你就是在压迫人家，人家自然会反抗。

　　Reason 7: Product Owner 专注于 ‘what’ 和 ‘why’ 的问题，开发团队决定 ‘how’。很不错的分工，于是可以造就一个即高速有重质量的团队。然而，这根本不行。你的Product Owner马上就想要这个功能，他才不管你的软件开发的技术难题，人家只要快，要你meet deadline，要你给我们重要的客户做出承诺。另外，你千万不要以为你们可以哄走这个初级的product owner，因为他的后台是直接汇报到高层管理。你作为一个程序员可能只是其个小部门的一个小喽啰，或者只是外包公司，你觉得可能吗?你觉得建立信任可能吗?

　　Reason 8: 软件质量和生产率成正比。也就是说，质量越高，生产率越高。如果质量不高，你开发效率就会低下，但是谁管呢?我们朝九晚五的上班，质量好了也是做8小时，质量差了也是做8小时，无所为嘛。另外，我们的 project manager (或者是Scrum master!) 总是会批评我们没有按计划完成。所以，这根本 不可能。

　　Reason 9: “是的，如果我们只做需要的功能，那么我们就会最低的成本，对吗?”，为什么这世上总是会有这些幼稚的人?这种事怎么可能啊。很多很多的银行或保险公司的项目在你还没有启动项目前就谈好了一个价格(可能还会有回扣)，为了打单子，销售什么都干得出来，让你去做项目是因为你是廉价劳动力，而且，他们会不断地加需求，因为软件合同谈好的价格时候，连需求都没有，你去做了才有，还是模糊和不确定或根本就是错的，然后需求是越来越多，越改越多。等你精疲力尽的时候，你才意识到，销售早就把你卖了。

　　爽啊，戴着黑礼帽思考问题比我想像中的要有趣得多，现在我必需要把它摘下来了。

　　看完这篇文章，你觉得是人的问题还是软件开发方法的问题?

　　(全文完)

【评论】《为什么敏捷开发Scrum方法不行？》
原文链接:http://www.ltesting.net/ceshi/ruanjianzhiliangbaozheng/zlmx/mjkf/2011/0722/202934.html

　　DragonFire公司的顾问Janet Gregory认为，对用户需求的测试尤为重要，“除非经过测试，否则不能认为任何业务需求已经完成。

　　”

　　STAREAST测试展会(STAREAST Conference andTestingExpo)上，Gregory讨论了“新晋敏捷测试员的危险行为与陷阱”，并解释了敏捷测试员所应做的工作。她指出软件测试人员经常做出的危险行为，这些危险行为可能带来的风险，以及如何规避这些危险和风险。

　　作为一名敏捷测试员，你需要能在没有正式说明文档的条件下展开软件测试、进行实时测试、测试改动代码、根据不断变化的需求进行测试、自动化大部分测试，并成为紧密合作的团队中的一员。

　　如果你想一一完成这些工作，就可能会在努力过程中遇到Gregory所说的敏捷测试的危险行为。

　　危险行为1：等待第二天的版本

　　Gregory认为，敏捷开发需要不断地进行测试。你不能等版本开发到最后阶段才开始软件测试。怎么知道你是否已经陷入这种困窘呢?对照以下几个特征：

　　成堆的“等待”测试的业务需求

　　没有在一次迭代周期中测试完所有需求

　　没有定期对部署进行软件测试

　　造成无法进行定期测试的原因包括：未对需求进行测试、软件测试人员不可靠、速度受到影响，以及利益相关人的反馈不够及时等。另外，有可能进行到下一个需求开发的时候，才发现前面未查出的漏洞，或者如Gregory所说，“所有测试都堆到最后阶段”。

　　她还说，要避免这种危险，最重要的是要采取主动。从“版本主管”那里定期拿到各版本，并规划测试的基本架构。拿到版本后要尽快测试，包括速度规划(Velocity planning)中的任务，并尽可能地在程序员的机器上进行结队测试，使程序员习惯于得到反馈。

　　Gregory说，要找到测试与程序编写之间的平衡点。“只是一味地努力提高速度是不行的。你得让你的工作速度与效率与程序员保持一致。”

　　危险行为2：你并没有真正地加入团队

　　如果软件测试人员没有被邀请参加规划讨论会，或者测试人员不喜欢发言;如果业务客户独立编写业务需求，而测试人员不明白这些需求的内容，这时就已经很明确是否存在这方面的问题了。

　　这种工作方式可能导致的后果是：

　　无法及时确定各种假设

　　不能及时发现对系统造成的影响

　　员工不能有效利用时间与技能

　　你总是感觉不对劲

　　人心分散

　　Gregory认为，要避免这种情况，你必须强调“完整团队”的重要性。与你的程序员坐在一起，这样你们会更容易交谈;参加各种会议，确保在讨论需求的时候所有三方团队都在场，并建议他们在一两个迭代周期中“尽量尝试”一些新主意。

　　你得明白作为一名测试员应发挥的作用。也就是Gregory所说的不断地进行软件测试，并提供反馈意见。

　　危险行为3：无法放弃“质量监督”的理念

　　可能你以前工作在一个质量监督(Quality Police)负责所有质量问题的环境下。即除开发团队以外，有一个单独的软件测试团队将所有的漏洞报告到缺陷跟踪系统中，测试团队甚至可以停止开发的进行。

　　然而，在敏捷开发中，整个团队都要对质量负责，而不仅仅是测试人员。Gregory说，如果没有整个团队对质量问题的一致认同，程序员就会将软件测试员看作是安全保障，从而只在bug追踪系统中与测试员沟通，那么这个团队便无法“凝聚到一起”。

　　要改变这种局面，所需要的仍然是测试人员的主动。Gregory指出，软件测试人员要与程序员建立良好的关系，向程序员展示各自的职业价值，使整个团队对产品的质量负责。

　　测试员可以在一些专业问题上帮助程序员，保证能够在迭代过程中进行测试，并解释对于整个团队来说“完成”所代表的意义。在追踪bug时，可以使用需求卡片(index card)。将需求开发中发现的bug写到卡片上并贴到墙上。

　　危险行为4：所有测试都想手工进行

　　Gregory说，如果所有测试都想手工进行，那么必然赶不上程序员的进度。如果你一直把时间用在重复进行某些测试上，而没有对新功能进行测试;或需要越来越多的软件测试人员，却无法对部署或设计上的问题产生作用，你就会明白这个问题的重要性。

　　不对测试进行自动化会导致越来越多的bug，并且无法及时响应新的需求。此外，可能无法注意到以往运行正常的功能已经受损，而软件测试人员也容易陷入陈规，无法学到新东西。

　　对此Gregory提出以下建议：

　　用自动化的方法建立回归测试集

　　设计时考虑到易测试性

　　使自动化与测试同步(让程序员也参与)

　　帮助程序员编写优良的单元测试

　　使用对整个团队都有用的自动化工具

　　展示你的技能

　　推广你的工具包

　　危险行为5：忽视大局

　　在敏捷开发中，你必须能够展望全局，而不能被一些片面的东西迷惑。如果你发现一直进行的只有单独的需求测试，在发布的版本中有集成的bug，直到最后才制作报告，而你所做的测试都是程序员告诉你去做，并且只做了探索性测试，那么你肯定是没有考虑整体规划。

　　如果确实如此，那么你的业务需求将无法联系到一起，各单元无法集成，业务流程不流畅，并且在编写程序过程中制定的决策也无法与最终目标吻合。Gregory说：“你在冒险，你的最终产品可能并不是所需要的。”

　　如果能先进行验收测试，用面向业务(business-facing)的测试进行有效的开发，充分考虑系统其它部分受到的影响，使用可以反映实际情况的测试数据，以及在编写程序之前将业务需求研究透彻，便能避免这一切。

　　还有一些可以使用的方法，包括：

　　使用电子公告栏进行规划#p#分页标题#e#

　　详细考虑业务流程

　　进行探索性测试

　　使用实例

　　先进行验收测试

　　让程序员拒绝进行没有测试的代码编写工作

　　这些危险行为看起来很可怕，但它们是可以控制的。然而，新团队可能需要一位敏捷指导员来帮助鉴别并解决这些问题。Gregory还建议参与到雅虎(Yahoo)敏捷测试小组的活动中，并研究相关文章。

　　她说：“敏捷测试中充满了危险的行为。你要认识并注意到这些危险行为，但别让它们吓倒你。” 

　　第一种境界：见山是山(代码级的质量)

　　目标：提高代码质量的成熟度;

　　驱动：如何发现更多的缺陷;

　　方法：各种测试方法遍历;

　　第二种境界：见山不是山(需求级别的质量)

　　目标：提高需求质量的成熟度

　　驱动：如何有效的挖掘需求的各种质量属性

　　方法：ISO/IEC 9126及QFD质量机能展开

　　第三种境界：见山还是山, (产品的市场质量,即产品被市场接受的程度，或受欢迎的程度)

　　目标：获得最大化产品市场质量;

　　驱动：如何帮助产品获得市场成功;

　　方法：产品定位，市场策略，使用质量，后续服务等

　　在实际的活动中，我们谈质量不能在真空中，任何时候质量都不能脱离产品，脱离市场而单独存在，从某种程度上来说，质量是人们愿意购买的程度，这不在局限于产品的稳定程度(代码质量)，或完成期望的功能(需求质量)，更多的在体现在非功能性，诸如产品的易用性，独特的用户体验等方面，如果能够正确定义产品的市场质量，并通过对需求质量进一步的挖掘和代码质量的粒度分析，这将是质量价值最大化的体现，并进而为产品的成功推广赢得先机。

　　与此同时，任何一个成功的产品或服务，都是以一定的市场利润为前提的，一般来说，技术本身是无法赚钱的，必须依托于产品这个载体,没有看到哪个消费者在为一个产品是C，或Jave开发的而愿意付更多的银子，当然需要抛开一些技术专利和培训等个案，基于此，产品成功要以利润最大化为导向，咱不是造上帝，不一定在任何时候都要追求100%的完美;时刻记住质量是为产品，为市场服务的，这样才不会顾此失彼，才能将自己的价值最大化。

　　产品的市场质量，取决其的应用范围，特定人群等，诸如游戏，医疗，企业管理和军事领域等软件产品，因用户不同，环境不同，进而对质量的需求也不同，我们若按照同一类标准来要求不同的软件产品，在代码级别上追求极限的可靠性和性能，则项目殆已，这并不是说，追求高可靠性的代码质量有什么问题，只是每种产品质量需求不同，我们需要区分对待。

　　Iphone取得了巨大的市场成功，由此来看其产品的市场质量，产品的定位是用户体验，所有的重点围绕着这个关键点展开，在功能上可以简单，以至于第一代出来时没有Wifi功能，在稳定性上也可以让步，尤其是它那可爱的闹钟让能多人耽误的航班，但并没有阻止人们对的狂热。

　　若在今后的质量活动过程中，能够从具体的代码级别的质量中上升到需求质量，并多一点对产品市场质量的关注，帮助企业推出成功的质量的产品，则必将能够让质量的价值最大化，进而实现QA价值的最大化。

　　以上个人拙见，欢迎指正。

　　应当承担敏捷Scrum Master职责。要站在全局的高度和第三方客观的角度分析项目现状、趋势和风险，并运用软件工程的理论和自己积累的实战经验指导项目解决问题、有序实施。

　　让整个项目组思路清晰，时刻强调：我们的目标是什么，当前我们处于什么阶段和位置，我们还有哪些工作要做!指导项目从混乱的状态，转而走向有条不紊，井然有序的境地。增加整个项目组工作的纵向透明度。

　　协调项目组，上下左右沟通。因为QA的客观性，能弥补项目组看不到全局的缺陷。在这点上，我觉得QA更像是牵线搭桥之人。

　　QA的位置

　　始终把自己定位成项目的一部分，我们是做服务，不是来指挥人的。所以我们的目的是协助项目组，使我们的项目团队规范专业化，更加高效。

　　QA的能力

　　QA要不断充实自己的能力，包括软技能和硬技能。

　　软技能：

　　沟通协调能力：强势是必要的，但不是做好QA工作的关键!要以德服人，以理服人。沟通要充分，更要全面。

　　分析总结能力：善于总结工作中的细节，所思考。要分析别人的经验，为我所用!

　　硬技能：

　　研究项目管理理念和软件工程方法，PMP、CMMI、敏捷、RUP等等，这些都是理论基础，触发实践的灵感。

　　质量保证的能力：产品测试技能，配置管理技能，度量分析技能。

　　了解项目框架、开发技术的原理等。以此为基础，以便更融洽地和项目流程和规范融合。

　　1. 熟悉linux系统

　　1) 熟悉系统结构和命令

　　2) 独立安装系统和软件，搭建应用环境;

　　3) 为了应用程序编写sh脚本，如备份脚本等;

　　2. 配置管理

　　1) 熟悉一种版本控制工具;

　　2) 能够独立搭建配置管理的服务和应用;

　　3) 文档化配置管理规范

　　4) 培训，制定培训材料，分别针对配置管理员和客户端使用者。培训的内容包括配置管理规范外，还有工具的维护和使用;

　　5) 配置管理工具的疑难问题解答，并注意总结经验教训，与他们分享

　　3. 持续集成

　　1) 建立并完善持续集成的实施方案，包括流程，工具和使用规范

　　4. 问题跟踪管理

　　1) 熟悉问题跟踪的工具，如trac，bugzliia、mantis等

　　2) 撰写问题跟踪管理实施方案

　　5. 文档编写能力

　　a) 熟悉工具使用：OFFICE、project、visio等

　　6. 熟悉多种系统化软件工程方法

　　a) CMMI

　　b) 敏捷

　　c) RUP

　　利用SWTO的方法加以比较和分析，有书面化的文字记录

　　能够有质量管理方面的专题记录

　　7. 了解开发和测试技术和工具

　　8. 英语听说写能力

　　QA的心态：

　　重视自己的职位，才能提升QA的地位!

　　具备勇往直前，促成好事的的心态;

　　当项目组有困难预退缩或士气消沉时，QA应充当精神领袖。

　　既然选择了做QA，就要有默默奉献的精神，我们是幕后!

　　QA工作技巧：

　　猜测或者推断是在识别风险时是必要的，但是现象和问题必须与干系人确认，反复确认!

　　所有问题(NC/疑问/纠正措施)必须书面化，找干系人确认，并落实到执行人!

　　前瞻和规划(横向与纵向)

　　心生疑问，必须求证，追根问底。

　　QA了解项目情况，必须是经过多方证实，体现客观、公正、公平!

　　多请示，多确认，多沟通，多验证，多积累!

　　QA的职业发展：

　　领导--质量经理

　　咨询顾问---过程改进、质量管理、项目管理顾问

　　专家---解决方案 

　　游戏的组成

　　超级玛丽的游戏组成非常简单，只有几个必要的概念，但是可以玩出无数的花样：

　　主角

　　一个水管工，名叫玛丽奥，某天他的公主被邪恶的大魔王抓走了，于是开始了拯救公主的征途……

　　在项目中，主角无疑是整个团队，首先保证整个团队的一致性和不可分割性，使其成为一个单独的个体，而非若干个个体组合起来的松散的组织。当团队拿到项目的这一刻，就如同站在屏幕左边的玛丽奥，一段征程就此开始。

　　关卡

　　游戏的最基本组成是一个一个的关卡，每一个关卡最后都有已知的惊喜(不是一个城堡就是一只公主)，正因为关卡这个概念的存在，才造就了游戏的多样化和挑战性。

　　相对项目来说，一个关卡可以变成一个里程碑，每一个里程碑最后也都有着预先准备的“惊喜”。每一个里程碑成功交付之时，作为管理者，必须让所有成员意识到我们又突破了一个关卡，这是值得庆祝的事，并且要让每一个成员都认可这是团队一起努力后应得的结果。

　　坑

　　出于游戏中怪物智商普遍低于平均线，“坑”这一事物反而成了游戏中的一大障碍。跑着跳着欢快着，一不小心掉进个坑里，是多么没有面子的事情。

　　对于项目，所谓的坑，自然是一个又一个的困难。在一个里程碑开始之初，就应当规划好整个头上的“场景”，整个团队有权利也有义务知道，按照小小主人公的奔跑速度，在什么时候会遇上坑，是一个怎么样的坑，以便团队事先做好应对的措施。

　　而坑也是游戏中极富多样性的一个元素，也许玩的时候并没有仔细地分析，坑的各类其实是很多的：

　　标准坑

　　大量存在于各个关卡之中，只要按标准的速度“走”过去，在适当的里面起跳就可以轻松地跃过。但是永远也不要小看这样的坑，当地形变得复杂，一个又一个的标准坑连在一起，中间只剩一个人的容身之所，就会让游戏的难度大大增加。

　　同样，在项目中，最常遇上的困难也就是如此简单的标准坑，只要团队按着计划的步调前进，在适当的时候给予一次小小的冲刺，就可以安全地度过。但是当这类不大不小的困难连续出现，在解决一个问题之后又紧接着出现另一个问题，之间只留下勉强喘息的时间之时，就是对项目组的一个考验。如果在项目开始之初就对关卡的地形了如指掌，事先做好全面的心理准备，在通过的过程中调整好自己的步调，相信绝大多数的“玩家”还是不会败在这种环境之下的。

　　大坑

　　大坑的跨度之大，足以让没有充分助跑就随意起跳的玛丽奥同志坠入无限的深渊。在初代的游戏中，最大的一个坑甚至需要足够的助跑，在平地的边缘起跑，才可以勉强地落到对岸。

　　大坑对项目来说绝对是一种挑战，在这段时间内，项目组将不可避免地出现火力全开的情况，甚至要为此加班加点。但即便如此，如果没有之前的助跑，无论你的弹跳力多么超群，在大坑面前都无法避免跌入地狱的结局。因此作为项目进度制定者，对于大坑必须有明确的标识，提前一定的时间知会整个项目组。此时项目组需要开始调整自己的节奏，为即将到来的攻坚战作好准备，以最大的冲刺速度突前，直到坑的边缘，决然地起跳。

　　每一次跃过大坑，都会给玩家带来成就和喜悦之感，往往项目也正是通过对困难的征服所带来的成就感，才得以保持整个团队的士气，一直向着最后的终点冲刺。

　　碎坑

　　碎坑是一种很特殊的坑，他由非常多但非常窄的坑组成，每2个坑之间仅容下一个身位的立足之所。

　　在项目的进行过程中，遇上这样的情况也是不可避免的。小小的麻烦总是不断地骚扰，当一个函数出现了点问题、当客户来电说需要有一个小小的修改、当有同仁身体不适需要休息……而当这些细碎的问题撞在一起时，一个典型的“碎坑地形”就出现了。

　　那么如何去应对矿坑地带呢?玩过游戏的人都知道，面对这样的地形，与其小心翼翼地从每一个坑上跳过、屏住呼吸随时注意自己的下一个落点、提心掉胆有惊无险地通过，不如在不远处开始加速，以飞奔的速度从上面通过，碎坑是可以直接跑过去的，而不需要起跳这样笨拙的动作。

　　同样映射到项目之中，当面对一个碎坑地形的时候，如果管理者可以及早地发现问题，并通告整个团队。那么团队只需要一鼓作气，加快自己的节奏，哪怕无可避免地有一些加班加点的情况，但只要拥有足够的速度，碎坑将如同平地，无法给项目的进度造成任何的阻挠。

　　砖

　　砖也是游戏场景中无处不在的重要元素，主角可以拿他那比金子还硬的拳头(绝对不明脑袋)去敲一下砖头，至于砖头里有什么，那就另当别论了。当然可以肯定的是，不会敲出一个BOSS来：)

　　在项目中，砖可以是一些起眼或者不起眼的小细节，而是不是去敲这个砖，并不会影响到项目整体，即便一个砖都不敲，项目最终也是可以交付的。只是砖作为一种额外的收益，如果花些心思去敲了，往往能得到一点什么。

　　同样的，砖也有很多种：

　　普通砖

　　普通砖遍地都是，稍微敲一下就会碎裂，但往往不会给出什么东西。当然也存在极少数的情况，会出来一个蘑菇或者一朵鲜花，当然也有敲不完的金币。总得来说，普通砖里充满了机遇，但过分追求的结果往往是失望。

　　对于项目，我们也经常能看到这样的现象，一个小小的元件摆放在那边，从各个角度看都有让人重构的冲动。但是对于管理者来说，这样的重构是不是值得，敲下这块砖会不会出现自己需要的收益，却是一个非常需要关注的事情。在大多数的情况下，我们并不反对去敲每一块砖;但是如果希望项目在绝对最短的时间内完成交付，是不是也同样可以选择忽略那些平凡的“砖”，用这一跳的时间去做更值得关注的事?

　　方砖

　　如果不是因为这东西不能拿去砸怪物的话，我很乐意称之为“板砖”。这是何等坑爹的一种砖，他就是那么一个广场，无论你怎么敲他，他都不会碎裂，也不会挤出哪怕是那么一丝的分数给你。

　　当然项目中这样的情况也不少，当你从一开始就走在一条错误的道路上尝试，无论怎么努力也得不到回报。但是请不要气馁不要绝望，正是因为有这样无数的尝试，你的团队才能确定这块砖是不是真正的方砖，是不是绝对不会产出任何的收效，这样团队才可以在日后遇上类似情况时避免进入一个无谓的圈套去挣扎不休，而是直接忽略那个看起来充满诱惑的炸弹，直接冲向目标。要相信项目中每一分投入都会有相应的回报，每一次努力都有其应有的价值。

　　问号砖

　　问号砖太显眼了，除了上面有个大大的问号，还会不断地闪烁着光芒提示你来敲。而且，问号砖是不会不给你东西的，少则一只蘑菇，甚至有可能是一个无敌的星星。唯一的遗憾是，问号砖的数量还是比较稀少的。

　　项目中，把握好每一个问号砖是非常关键的，一个砖带来的收益往往能起到决定性的作用，正如一个无敌星星能让你在以后很长的一段路程中平安无事(前提是别傻到掉坑里)。一但发现有一个如此闪亮的砖头，即刻组织一定的人力物力去敲掉，收益绝对能大于成本。这样的砖往往是一个全新进入视野的第三方组件、或者一位有意合作的资深人士、或者一款制作精良的工具，他将为项目接下去的进度提供足够的推力，不仅仅是对项目执行的帮助，也是整个团队士气振奋的关键所在。

　　最终BOSS

　　最后的BOSS，抢走我们(一点也不)可爱的公主的大魔王，库巴老乌龟，他始终那么耐心地将公主绑起来放在自己的房间里，然后站在一座桥上面等着主人公的来到。从剧情的角度看，库巴实在是无比可爱，无论是哪一个关卡，都会充满耐心地迎接剧情……

　　对项目来说的最终BOSS，那无疑就是项目的交付了，虽然说交付往往并不是终点，但是对于项目来说，至少是很大很大的一步，称其为BOSS也没有任何的过错。

　　玩游戏的都知道，库巴有2种打法，其一是慢慢地虐死他，其二是跳到他身后碰一下那个斧头，然后咔嚓一下库巴就掉火里去了……

　　相对的，项目的交付也有两种方法：

　　其一，简单地完成项目的需求，给予一个最低限度可运行的成果，完成基本的交付工作，获得项目的相应报酬。这算是一种皆大欢喜的结果，项目组使用了最合理的人力物力，完成了项目的需求;客户也拿到了其所希望的产品，并为此支付合理的报酬。

　　其二，深入地理解客户的需求，不断挖掘出潜在的需求，完成良好的设计，构架起精美的实现，最后交付一个超出客户期望的产品。也许对于项目组来说，投入了更多的人力物力，却最终只得到合同中协议的报酬，就好像费劲力气折腾死了库巴，最后也就和(一点也不)可爱的公主说上一句话。但是玩游戏的人能从中体会到更大的乐趣，项目也是一样，在收获合同规定的报酬之余，项目组也获得了客户更好的认同，以及客户的忠诚度，为未来的发展打下了一个基础，在将来的某一时机，会得到应有的回报。

　　项目过程

　　在“超级玛丽式项目管理”中，我们将游戏的元素运用到项目，让所有成员可以更直观(相信多数人玩过超级玛丽，也知道这些概念)地理解项目的整个过程，以达到更紧密的团队合作。

　　项目启动之初，项目经理必须能够根据项目的进度安排，与技术经理一起制作出“关卡”和“地图”，一个关卡即一个里程碑，在每个关卡的地图中，要明确标识出“坑”的位置以及大小。

　　随着项目的启动，我们的主角玛丽奥先生将会出现在地图之上。随着项目的推进，先生也不断前进着。从地图上可以轻松地看出，项目是不是快要遇上“坑”了，会是一个怎么样的坑，全团队都可以直观地对项目的现阶段进展进行理解，当有“大坑”出现时，提前作好冲刺准备，当“碎坑地形”出现时，鼓足干劲通往直前……

　　当然，项目并不是游戏那样有着最初静态的设定的。项目必须随着时间的推移不断地拥抱变化，地图也需要实时地进行修改，甚至加入一些通过下水道进入的特殊关卡，甚至是下水、上天等特殊情况。相信熟练玩游戏的开发者们，不会面对游戏的变化产生任何害怕的情绪，相反，也许会激起他们的好胜之心，更加投入地去解决困难。

　　最后，当我们的主角站在桥上，面对着最后的大魔王库巴老好人的时候，团队作出最后的努力，战胜BOSS，解救公主，然后是盛大的庆祝，一个项目圆满落幕……

　　如何让成员更有干劲

　　至此，一个项目的元素基本齐全，项目可以稳步地进行。但是过于稳定的环境，会逐渐让项目成员产生疲倦的心态，效率也会按一定的曲线开始下降。这对于管理者来说，自然是不愿意看到的现象，因此，必须有一定的激励机制，让成员可以随时处在一个较好的心理状态。在游戏中也有一些这样额外的元素，可以引申到项目之中，对成员士气的激励有着非常好的效果：

　　生命蘑菇

　　游戏中最充满传奇色彩的元素，怎么看都不能吃的绿色蘑菇，却有着生命+1的效果。生命蘑菇永远出现在不可见的地方，当你在特定的位置停下脚本，轻轻地起跳，突然就出现了一块砖，一只漂亮的蘑菇落在你的脚边……对于项目来说，生命蘑菇就是对成员额外的努力的奖励，每一个成员都有完成本职工作的义务，但是在义务之外，如果对项目有着卓越的贡献，自然需要给予相应的奖赏，以至最后形成一个良好的循环，每一个成员都会自发地从项目的角度寻找突破口，并自觉地给予更大的产出。生命蘑菇的哲理是“你永远看不到他，但他就在那儿”，只要自身足够努力，他不会离你太远。

　　怪物(们)

　　怪物在游戏中几乎以弱智的形态出现，对玩家没有太大的威胁，但是当一脚踩扁一只蘑菇，一下踢飞一只乌龟，这种快感也是游戏吸引人的重要因素。因此在项目中，作为项目正常进行之余，定期进行总结、交流，提出一些更具挑战性的“子项目”来“玩玩”，确实有助于保持住团队成员的状态。同时，怪物是多样性的，技术的攻关也要具备多元化的特点，让不同职位、不同专长的人都可以平均地得到表现的机会。#p#分页标题#e#

　　其他元素

　　游戏中还有很多其他的细节，每一样都能映射到项目中的某个方面，比如：

　　超级玛丽的任何一关，只要按住奔跑键和向前键，在适当的地方起跳，绝对可以毫不停留的冲到终点。但是一但有一处的停留，后面的进程反而会遇到种种麻烦，不是躲避满身是刺的怪物，就是各种大坑需要计算距离来助跑……

　　除了库巴老同志外，每一关卡的最后都有一根旗杆。其实拿到旗杆的满分非常容易，但是无数玩家为了能跑过杆子而孜孜不倦地努力着。但其实这根杆子是跳不过去的……玩家只是看到了这么一丝希望，他们就会不断去努力。

　　初代的超级玛丽不够刺激，变因不够多，用作充满变化的项目不适合?那么看看这个变态版的超级玛丽，想办法再用到项目中去?