需求分析  需求調研  敏捷開發  專案啟動會議

很多需求分析的工作是從需求調研開始的，我們就從這裡說起吧。需求調研是需求分析最重要的一環，也最集中地體現了需求分析的特點——既是一份體力活兒，更是一份技術活兒。它既要求我們具有一種理解能力、設計能力，更要求我們具有一種與人交往、溝通的能力。

在一個陽光明媚的下午，專案經理帶領著專案組成員，參加了客戶組織的見面會，一個新的軟體研發專案就這樣開始了。雙方在一種友好的氣氛中進行，雙方相互寒暄，介紹與會人員，拉拉家常。逐漸地，會議開始進入了正題。初次接觸客戶，對於專案團隊意義重大。對方對你印象的好壞，今後如何與你交往，都在這個階段被確定下來。然而，在客戶至上的今天，與客戶保持適當的謙卑是有必要的，但過於的謙卑卻常常給專案日後的程序帶來風險。為什麼這麼說呢？過於的謙卑，處處都是諾諾諾，客戶說什麼就是什麼，就會使客戶變得非常強勢。這樣的結果就是，客戶提出了許多變態的、不太現實的、不合理的需求，而我們呢卻是一味地服從，客戶說什麼就是什麼。最後我們做得很累，結果卻不能讓客戶滿意。

正確的做法是，我們對客戶提出的需求進行深入理解以後，運用我們專業知識，提出比客戶的原始需求更加合理、可操作的解決方案，讓客戶感覺你說的正是他們想要的。如果能夠這樣，客戶不僅能夠欣然接收你提出的方案，而且會感覺你非常專業，你在客戶心目中的形象也會無形中提高，使你有更多的機會提出有利於開發的可行方案，降低開發的風險。這毫無疑問會形成一個良性迴圈，但要做到這一點並不容易，我們需要在與客戶接觸的初期，就運用自己的專業知識在客戶心目中形成威信。
也許在見面會之前我們已經做足了功課，已經對客戶提出的需求進行了一番詳細的整理，也許有了一大堆疑問急需解答。但是，在最初的見面會上，不是解答具體問題的地方，這是我們常常會犯的一個毛病。作為客戶，特別是客戶方的領導，最希望瞭解的是這個專案在巨集觀上給他們帶來的利益。因此，在這樣一個場合，我們討論的都是巨集觀上的問題：客戶在巨集觀上對這個專案所要達到的目標，我們在巨集觀上給客戶提出的解決方案，在巨集觀上能給予客戶的利益，等等。
同時，這樣的會議又是一個專案啟動會議。客戶方領導要傳達給與會代表一個清晰的訊號，就是與會代表今後要積極配合我們完成今後的工作。這時候，要清楚地弄清，客戶方有哪些角色，誰是這些角色的需求制訂人與負責人。這是什麼意思呢？在軟體專案中，特別是管理型軟體專案中，客戶都代表的是一個群體，而不是個人。他們代表的可能是一個單位、一個集團，甚至是一系列組織機構。在這樣一個群體中，他們按照職能被劃分成了不同的角色。拿一個單位來說，橫向可能劃分成不同的部門，財務部、銷售部、採購部、生產部••••••不同的部門，由於業務的不同，對軟體的需求自然是不同的；縱向又可以劃分為多個層次，如高層領導、中層領導與基層人員，高層領導關心的是巨集觀的目標，中層領導關心的是具體的效益，而基層人員關心的是細節的每一步操作。劃分清楚角色，弄清楚每個角色的需求制訂人與負責人，才能在今後的需求調研中找對正確的人，使事半功倍。
俗話說：萬事開頭難。我們以往在專案開始的時候總感覺千頭萬緒不知如何著手。在這裡我給大家的建議就是這三點：1）樹立良好的職業威信；2）從巨集觀上制訂目標與方案；3）進行角色分析，將與會各方代表對號入座。隨後的工作，就是逐一拜訪客戶代表，各個擊破。

迭代開發需求分析

我們的軟體開發存在巨大的風險，但問題到底出在哪裡呢？這對於問題的解決至關重要。

1. 我們在沒有深刻理解業務需求的情況下就必須完成需求分析；
2. 客戶在沒有弄明白自己的真正需求的情況下就被要求確定軟體的業務需求；
3. 我們在沒有與客戶再次溝通的情況下埋頭苦幹，直到完成開發並交付客戶。

既然問題出在這裡，我們就可以制訂我們的解決辦法：

1. 業務需求的分析不再是一蹴而就，而是貫穿軟體開發的始終。一方面，我們在與客戶的持續溝通中加深業務領域的理解，進而加深對業務需求的理解，另一方面，客戶也在加深對軟體的理解，進而完善自己的需求。

2. 軟體開發的過程不再是單反面的埋頭苦幹，而是雙方的良性互動。定期的使用者體驗，可使使用者及時瞭解專案進度，發現軟體問題，並及時提出來予以糾正，使軟體的開發不斷朝著正確的方向前進。

這就是迭代式開發。它是對以往開發模式的一種革新，但不是對以往開發模式的完全否定與摒棄，而是一種改造。

以往的瀑布式軟體開發模式將整個軟體開發過程分為四個階段：需求分析、設計、開發、測試。與瀑布式軟體開發不同，迭代式軟體開發首先將整個開發過程分為一個又一個的小段，每個小段大概在20個工作日左右，被稱為“迭代（Iteration）”。一個迭代就是一個小的開發過程，如同瀑布式開發一樣被分為四個階段：需求分析、設計、開發、測試。

採用迭代式開發，就是將以往的一個瀑布，變成了數個迴圈往復的瀑布，使軟體以進化的方式逐漸推進。

最初的迭代，開發的是軟體最基本最主要的功能，經過第一次迭代以後交付給客戶。這時候客戶看到的，不再是虛無縹緲的需求描述，而是實實在在的軟體介面。在此基礎上，客戶可能會認可我們的設計，也可能提出一些改進意見。修改這些意見，開始進入第二次迭代。第二次迭代可能是在第一次迭代的基礎上進一步豐富和完善功能，也可能是進一步實現其它第一次迭代還未實現的功能，之後再次交付客戶。

如此迴圈往復，使我們不斷在需求分析、設計、開發、測試，以及交付中，推進我們的軟體開發。這樣的開發過程，註定最終交付給客戶的是他們滿意的軟體。這就是迭代式軟體開發。

迭代開發需求分析開發風險

我們的軟體開發存在著巨大的風險，當我們經歷了數月的辛苦工作後才發現，我們的軟體並不是客戶滿意的軟體。這時候往往出現幾種情況：

1.客戶開始頻繁挑刺，大量的需求變更在很短的時間發生，加班再所難免，團隊士氣降到最低點；

2.甲乙雙方開始相互推諉，誰是誰的責任，爭吵不可避免，甚至最終談判破裂，專案失敗，雙方不歡而散。

這些都是我們不願看到的，卻不得不面對。到底問題出在哪裡呢？就在我們的開發過程中。以往的開發過程被稱為瀑布式開發，它要求我們在正式的軟體開發之前，在需求分析階段，就要把客戶的所有需求都分析清楚，確定下來。而在正式的軟體開發的數月間，我們不再與客戶交流，而是按照需求規格說明書自己埋頭開發，直到最終交付客戶。這樣的方式，最終交付客戶的風險可想而知。這種開發方式的弊端主要有這幾個方面：

1.客戶描述不清自己的需求。客戶不是專業人士，因此在起初他們描述不清自己的需求，只有一些簡單的想法。一句經典的話是這樣說的：“When I saw it, I have changed.”只有當他們看見我們製作的一個個demo版介面原型時，甚至操作著原型的模擬操作流程時，他們才開始整理，並使自己的需求逐漸清晰起來。這需要一個過程。

2.我們理解客戶的業務領域也需要一個過程。我們是技術專家，我們掌握著豐富的軟體知識，但我們不是領域專家，我們不瞭解客戶的業務領域，因而這不能讓我們的軟體獲得成功。我們只有深入理解客戶的業務領域之後，才能深刻理解客戶的業務需求，才能使我們的軟體成功。這需要一個逐漸深入的過程，因此不可能在軟體開發的初期那短短的需求分析階段完成。

一切的一切說明了一點：我們必須改變我們的開發方式。我們需要一個持續的需求分析過程，這個過程應當與我們的設計、開發、測試過程同步；我們需要不斷地向客戶展示我們的軟體成果，聽取客戶的意見，使我們開發的軟體不會偏離正確的軌道。而這就是迭代式開發，另一種軟體開發模式。

迭代開發持續整合需求分析軟體開發

前面我們提到了迭代式開發的巨大優勢，它可以降低我們軟體開發的巨大風險，它可以使我們把握使用者的真正需求，它可以使我們從錯誤與偏差中及時糾正過來，那麼我們應該如何進行迭代式開發呢？要回答這個問題，我們首先要弄清迭代式開發與傳統的瀑布式開發的差別在哪裡。

1.需求分析的差別
與傳統的軟體開發一樣，迭代式開發同樣需要與客戶進行一個充分的需求分析。但與傳統的軟體開發不一樣，迭代式開發不要求初期的需求分析是一個完全的需求分析。它承認需求分析需要一個過程，它承認需求的變化（或者說需求是一個進化的過程）。所以，在迭代式開發中，起初的需求分析只要進行到當時的階段能夠理解到的程度就可以了，而不是瀑布式開發那樣需要完成所有的需求分析並最終確認下來。至於其它還沒有分析到的內容，我們會在每個迭代的需求階段逐漸加深理解，逐漸細化，直至最終完成軟體的開發。因此，迭代式開發的需求分析始終貫穿整個軟體開發的過程。

2.軟體開發的差別
迭代式開發的軟體開發階段，與傳統軟體開發的方式存在著巨大的差異，迭代式軟體開發採用的是“持續整合（Continuous Build）”的軟體開發方式。傳統的開發方式，當需求被確認下來並開始軟體開發時，首先進行的工作是分模組進行開發，就如同車間生產一樣，不同的模組被分配到了不同的小組或個人進行分頭開發。在此期間，誰都不能拿出可執行的軟體交付物，直到開發中後期的整合階段。而迭代式開發不同，它將整個開發過程分為了數個迭代，並且在每個迭代結束時要交付可執行的軟體，正因為如此，迭代式開發採用持續整合的方式。

持續整合的基本思想就是每個人每天完成的開發工作都能立即整合為一個可執行的軟體產品。為了實現持續整合，我們必須改變我們的開發順序。傳統的開發順序，首先是開發並完善各個子模組。當各個子模組都完成開發以後，才最終組裝並整合為一個可執行的軟體。採用這種順序開發不可能保證持續整合。迭代式開發，在初次確認業務需求以後，首先開發的是軟體最主要最基本的功能，在開發這些功能時也往往只考慮主流程而忽略分支流程。採用這種方式，可以在最短時間內交付可以執行的軟體。之後我們交給客戶去體驗、去確認、給我們提意見，我們再不斷去調整和完善這些主要功能，或者開發其它次要功能，使軟體開發以一種進化式的方式進行下去。

採用持續整合的方式，使軟體開發中利益攸關的各方隨時可以瞭解軟體開發的進度，以視覺化的方式看到軟體開發的成果，及時糾正軟體開發過程中的問題。更重要的是，所有利益攸關方中最重要的一方——客戶，由於自身的侷限描述不清自己的需求，通過視覺化的方式一次一次看見可執行的軟體，更直觀地提出自己的意見，使自己的需求越來越清晰，並有效地告知開發者。而我們作為開發中，通過這種方式，使我們有更多的機會與客戶有效溝通，從而對業務領域理解越來越深刻，也使我們的開發成果始終有客戶確認，與客戶的需求保持一致。即使有時出現偏差，也能及時得到糾正。最終，我們交付的軟體必然是客戶滿意的。

由此看來，迭代式開發與傳統開發，其開發的過程差異真的不小。

迭代開發專案管理工作量評估優先順序

古人云：“運籌帷幄之中，決勝千里之外。”一次成功的軟體開發，制訂完善的專案計劃是決定性的第一步，迭代式開發更是如此。前面我們提到，迭代式開發與傳統開發方式差異不小，迭代式開發其過程更加複雜，協調各方協同工作的步驟也就更多。

迭代式開發的特點就是迭代，在每個迭代期都包含需求分析、設計、開發、測試。因此，迭代式開發從一開始就要求開發中的各方人員，需求分析員、設計師、開發人員與測試人員，幾乎同時開工。如何組織協調呢？另外，整個開發過程被劃分為一個又一個的迭代期，那麼，如何將所有的工作合理分配到每個迭代期裡呢？這些都是一個迭代式開發專案計劃必須考慮的問題。

那麼，我們應當如何制訂迭代式開發的專案計劃呢？制訂計劃前的分析是其關鍵之所在。

我們採用迭代式開發的目的就是希望我們的開發獲得成功。一次成功的軟體開發主要需要解決的是三個問題：“What is needed, on time, on budget.”也就是需求、時間與經費。客戶看待一套軟體是否成功，就是三個標準：功能是否滿足需求，是否按期交付，耗費的經費是否在預算內。功能是否滿足需求，是在迭代開發整個過程中逐步解決的問題，而開發週期與經費預算卻是軟體開發初期的專案計劃中就必須考慮清楚的問題。

工作量評估是預計開發週期與人員投入、制訂經費預算的關鍵步驟。將軟體劃分為若干模組，將模組劃分為若干功能，再將功能劃分為若干項工作，仔細評估每項工作的工作量。合計每一項工作的工作量，就是整個專案的工作量。但實際的工作量評估並非如此簡單，後面將會深入討論。

工作量評估的直接作用就是評估開發週期與人員投入。一般認為開發週期與人員投入成比例，其實是一種誤解。增加人員投入並非能夠縮短開發週期。隨著人員的增加，培訓、溝通、協調的成本都將會增大。使用者期望的開發週期與可以投入的人員是一對矛盾，最終需要尋找一個平衡點，當然這也是與客戶反覆討論的過程。有時，當這對矛盾無法協調時，分期開發也許是一個不錯的選擇，畢竟客戶始終是希望軟體系統儘可能早地上線使用。最後，當開發週期與人員投入確定下來時，經費預算也就是計算出來了。

為每一項工作評估工作量的另一個重要作用就是將工作合理分配到各個迭代期中。迭代開發，迭代期就如同一個又一個的格子，而評估後的每一項工作就如同一顆又一顆大小不一的石子，被投放到每一個格子中。而它們孰先孰後，則是由工作的優先順序決定的。靠近主營業務的、使用者使用頻率高的，優先順序高；遠離主營業務的、使用者使用頻率低的，優先順序低。優先順序決定了工作安排的順序，它是制訂計劃前分析的另一個重要內容。

總之，迭代開發始於完備的專案計劃，完備的專案計劃的關鍵在於計劃制訂前的分析，也就是分解後的工作專案列表，及其工作量評估與優先順序評估。

迭代開發工作量評估

當我問起無數人，什麼是迭代式開發時，人們總是拋來一副不屑的神情：“迭代開發！這還不清楚？就是按迭代的方式進行開發嘛，開發過程採用持續整合的方式。”但我再詳細詢問怎麼進行開發，甚至談到如何制訂計劃，以及計劃前的分析整理時，人們卻投來詫異與迷茫的神情：“啊！迭代開發這麼複雜呢？”

所有對迭代式開發的實踐與研究中，工作量評估往往是最令人頭痛、最大的難題。當人們信心滿滿地決定嘗試迭代開發時，工作量評估就讓不少人望而卻步了。工作量評估真的有這麼難嗎？我們應當怎樣進行評估呢？

毫無疑問，工作量評估的第一步應該是工作分解。將整個系統劃分為數個模組，每個模組劃分為數個功能，每個功能劃分為多項工作。再逐項分解工作，直到確保每項工作能夠正確評估為止。一項為其10天以上的工作是不能夠準確評估的，所以應當分解，直到分解為2~3天以內的小塊工作。完成工作分解以後，最終合併每項工作的工作量，就是一個功能的工作量；合併每個功能的工作量，就是一個模組的工作量；合併每個模組的工作量，就是整個系統的工作量。

但是，即使將工作量適當地進行了分解，由於每個人對需求理解的不同，對設計方式的不同，技術熟練程度的不同，對同一項工作的工作量評估也是不同的。因此，要客觀地評估工作量，應當採用多人共同完成的方式，而不是一個人全搞定。

首先，將分解好的各項工作，按模組按功能羅列在一個表格中，依次描述每項工作的業務需求和工作任務，使每一個參與評估的人都清楚每項工作。然後將工作量評估分配給多個人，保證每項工作都有2~3個人同時給予評估。

該階段的評估應當是獨立的，即每個人的評估結果都不會影響另一個人。當每個人完成了自己的評估以後，專案經理收集每個人的評估結果，組織會議進行討論。

在工作量評估討論會上，會議組織者將一項一項地討論每項工作。對某項工作，如果參與評估的每個人評估的工作量差異都不大，說明大家對該項工作的分歧不大，選取最合適的一個工作量評估；如果某個人的評估與其他人差距較大，認真聽取他的意見。也許他對該項工作的某個細節存在誤解，但也可能該細節正是需求不明確的地方。停下對該項工作的評估，聯絡客戶明確需求，之後才可以繼續該項評估。

實際上，工作量評估也是一個迭代的過程：客戶提出需求、評估工作量、發現需求不明確的地方、與客戶確認、再評估……如此往復數輪，不僅工作量評估出來，業務需求也能逐漸明確下來。

另外，迭代開發的每個迭代期應當包括需求分析、設計、開發、測試。因此在工作量評估時應當全面地考慮進去，而不僅僅只是開發。

最後，當所有工作量被評估出來以後，是否就可以提交客戶了呢？一個成熟的專案經理應當考慮更多。並非所有人在所有時間都能滿負荷工作，生病、接收突發任務、人事變動，都可能影響專案進度。因此，適當地為每項工作增加一個備用時間的係數，提供一些富餘的時間，可以確保專案過程更加穩健。

迭代開發優先順序專案管理

前面我們提到，迭代式開發最重要的兩項前期分析就是工作量評估和優先順序評估。工作量評估不僅能夠確定整個專案的開發週期、成本預算，而且能夠確定每項工作的開發週期，為工作的時間分配提供了依據。

但是，如此多的工作，誰先做誰後做，如何安排它們的先後順序，則是由工作優先順序來決定的。

迭代式開發的特點就是持續整合，也就是首先開發最重要、最基本的功能，而暫時忽略掉分支的、次要的功能。正因為如此，迭代式開發需求將優先順序最高的功能放到前面最先完成，然後安排次優先順序的，依此類推。總之，優先順序評估決定了迭代式開發的工作安排。

那麼，如何決定每個功能，每項工作的優先順序呢？其決定因此很多，但通常來說，有兩個因素是最基本的：是否靠近主營業務，以及使用者使用是否頻繁。

一個組織想上線一套管理系統，我們首先要分析它的主營業務。一個醫院的主營業務是門診系統，一個ERP的主營業務是進銷存。越靠近這些主營業務的功能優先順序越高。

同時，我們在需求分析過程中還應考察使用者對各項功能的使用頻率。一般來說，一個事物處理系統中，完成各項業務操作的功能必然使用頻率最高，對各項業務操作的查詢次之，而那些各種各樣的統計分析報表則是頻率最低的。頻率高的功能優先順序高，頻率低的功能優先順序低。

當然，決定優先順序的因素還有很多，比如每項功能的成本與收益、緊急程度、戰略意義等。我們可以繪製一個優先順序表，一邊羅列出所有影響因素，一邊羅列出所有的功能，一項一項地分析，最終綜合評估各項功能的優先順序。

優先順序評估的最重要的作用就是排列各項功能的開發先後順序。前面我們提到，迭代式開發的最大特點就是迭代。整個軟體開發過程被劃分為數個迭代期，每個迭代期結束時應當提交一份可獨立執行的程式，向用戶演示。按照這樣的思路，當軟體開發第一個迭代期結束的時候，我們提交的是一套完整的程式，只是不夠健壯，操作不方便，沒有那些輔助的、次要的功能而已。這些剩餘的功能，我們將在之後的迭代期逐漸完成。

根據這樣的思路我們就明白了為什麼我們需要進行優先順序評估。將主營業務的、使用頻繁的功能首先開發出來。在開發時，也主要考慮主流程而忽略分支流程。經過第一次迭代，一個可執行的、主要功能都有的軟體雛形就出來了。之後，再在此基礎上繼續豐富、完善，直到整個專案的完成。

迭代開發專案管理專案計劃

前面我們提到，當我們為軟體分解工作專案，評估了工作量，確定了優先順序。同時，整個專案的人員安排，也就是哪些人負責需求分析，哪些人負責設計，哪些人負責開發，哪些人負責測試，被確定下來，我們就可以制訂我們的迭代式開發的專案計劃了。

迭代式開發的最重要的特點就是迭代，即將整個開發過程劃分為數個迭代期，每個迭代期的時間長短並非完全一致，但卻差別不大，這就是迭代週期。迭代週期的長短視專案情況而定，過短可能會使專案的變更過於頻繁（每次迭代都需要提交交付物與客戶溝通，從而產生變更）。迭代週期過短的另一個毛病是使迭代中的每個步驟的時間過短，而使專案組成員有一種匆匆忙忙趕進度而跟不上趟的感覺，使整個專案的組織混亂。相反，迭代週期過長會使專案成員不能集中精力工作，而使組織過於鬆散而產生拖沓的現象。同時，當專案進度、業務需求的理解，以及其它方面出現偏差而脫離正常軌道時，不能得到及時的糾正。一個比較合適的迭代週期是20個工作日，即一個月時間。

當我們制訂出我們的迭代週期以後，下一步的工作就是像填空一樣，將要完成的功能，以及相應的工作專案，填入各個迭代期中。先將整個開發週期劃分為數個迭代期，將每個迭代期按開發人員劃分為數個格子，從而將整個開發過程製作成一個Excel表格。

隨後的工作就是根據優先順序和工作量，將各項功能填入到表格中。首先將優先順序最高的放置到最靠前的迭代中，然後是優先順序次高的，以此類推。同時，各個迭代可能會出現一些縫隙，如迭代週期是20個工作日，但填入的功能只有15個工作日。這是，見縫插針地選取一些時間短、難度小的功能插入期間，是一個不錯的選擇。同樣，雖然迭代週期是20個工作日，但我們也可以根據實際情況上下浮動該迭代的長短，如我們選擇了一個工作量為6日的功能，與前面的15個工作日組成了一個21日的迭代，這也是可以的。

另一個值得注意的問題是，在制定時間計劃時不要安排得太滿，應當留有一些富餘，以應對一些突發事件，如專案成員生病，或者有其它突發任務需求處理。每個迭代期結束的時候，都應當對專案進度進行一個評估，是超前了還是滯後了。一個留有富餘的專案計劃，可以使那些滯後的工作的處理擁有更多的迴旋餘地。

最後，一個迭代式開發的專案計劃就制訂出來了。這個專案計劃實際上就是一個表，詳細標註哪些功能，應當由誰在哪個迭代期完成開發，各迭代期什麼時間結束。它將成為一個航標，指引我們成功地完成我們的軟體開發。

迭代開發極限程式設計專案管理

我們經過以上一系列的分析，工作量評估與優先順序評估，制訂出一個迭代式的專案計劃，再經過一系統使用者確認與公司評審以後，終於可以開始我們真正的開發工作。
其實，迭代式開發的執行過程，也就是製作和不斷去關注與評估專案進度表的過程。因此，當專案進入執行開發過程時，專案經理應當首先製作專案進度表。現在我們看看專案進度表長得啥樣兒。
在一個專案進度表中，首先被縱向劃分為三個區域：未開始任務區、正在進行任務區和已完成任務區，當然還可以增加其它區域，如下階段完成任務區，以及工作進度、費用成本的統計圖等。
同時，專案進度表又被橫向地劃分為數個區域，每個區域就是一個迭代期。在專案初始的狀態下，所有的功能以及從中分解出來的工作，按照專案計劃被分配到了對應的迭代期、未開始任務的區域。
另外，另一個統計表對整個開發進度的監控比較重要，它被稱作Burn-Down Table（暫時翻譯為剩餘工作量統計表吧）。這個統計表的橫軸是專案進行的時間，縱軸是剩餘的工作量。專案開始時，橫軸應當是0，而縱軸，按照專案計劃，應當是該專案的總工作量。每完成一項工作，就減去該項工作的工作量，直到所有工作完成，縱軸為0。如果專案是正常而平穩地進行的，整個統計表就應當是一個平滑下降的直線，直到最後在計劃交付時間（Deadline）結束，這跟直線被稱作基準線，但它是理想的、實際情況往往不會是這樣的。在整個專案的每天都記錄下當天的剩餘工作量，那麼這個表就呈現出一副實際工作進度曲線圖。當專案因各方面原因被延後時，該曲線就會高於基準線；當專案因進展順利而超前時，該曲線就會低於基準線。所以Burn-Down Table可以為專案經理及其成員隨時掌握專案進度，及時調整專案偏差，提供方便。
當專案進入第一個迭代期時，專案經理將第一個迭代期的功能及其任務描述清楚，填入到正在進行任務區，同時不要忘記填寫各項任務的負責人。眾所周知，迭代開發的每個迭代期分為需求分析、設計、開發、測試幾個部分，但在這個表中監控的內容可詳可簡。如果希望更精細化管理，可以將每個任務再分解為需求分析、設計、開發、測試幾個部分分別進行監控；如果專案不是非常複雜則不用劃分如此精細，可以劃分為開發與測試，或者不劃分開。每天早上，專案成員召開一個簡短的例會，或者通過其它方式，向專案經理彙報各項任務的工作進度。專案經理收集各項任務的工作進度，在這張表中詳細記錄下來。如果一項任務全部完成，則將其放置到已完成任務區域，再將其它剛剛開始的任務放置到正在進行任務區。最後，專案經理計算專案剩餘工作量，並將其填寫到Burn-Down Table中。
記得極限程式設計（XP）的其中一項重要的思想就是及時發現專案進行過程中的進度偏差，並及時進行糾正，而Burn-Down Table的使用正是體現了這種思想。通過整理和繪製Burn-Down Table，為專案經理及其成員提供了一個清晰的視覺化圖表，表明專案當前的進度是超前還是延後。如果是超前，專案組可以進行更多的檢查與測試，進一步保證專案質量；如果是延後，則不得不通過趕工、加班等方式，加快進度。

迭代開發需求變更專案管理

前面我們已經詳細描述了一次迭代式開發的完整過程，首先是專案計劃的前期分析——工作量評估和優先順序評估，然後是制訂迭代式的專案計劃，最後是按照專案計劃執行專案。每天，運用Burn-Down Table監控專案程序，隨時掌握專案進度的偏差（是滯後還是超前），然後制訂相應的應對方案予以調整，直到最後的專案結束，一切似乎進行得比較順利。但真實的情況往往不是這樣，這裡忽略了一個最重要的因素，那就是需求變更。

如果沒有需求變更，我們就不需要採用迭代式開發了，瀑布模型足矣。正如我在第一章談到的，我們的軟體開發存在著風險，這個風險就是需求變更。需求變更無處不在，就如同我們人類面對的浩瀚無垠的宇宙，必須得有防護措施應對可能的風險。需求變更的防護措施是什麼呢？那就是採用迭代式開發。那麼，迭代式開發是怎樣防護來自使用者的需求變更呢？我們用一個情景劇來詳細解讀。

A先生是一個專案經理，他準備開始一個新的軟體開發專案。他首先組織需求人員與客戶一起進行了深入的需求調研，進行了詳細的需求分析，最後制定出一份需求規格說明書，與客戶進行簽字確認。同時，他又組織了設計人員，與需求人員進行討論，將所有的需求進行任務分解、工作量評估，以及優先順序評估。隨後與公司領導討論，與客戶領導協商，確定專案需要配備的人員、花費的資金，以及所需的時間。最後，一個迭代式的專案計劃制訂出來。

萬事俱備之後，專案開始進入執行階段。A先生製作了一個Burn-Down Table監控專案進度，開始了第一個迭代期。一切進行得比較順利，專案順利地完成了第一個迭代期的所有任務，順利提交第一份交付物。正當大家認為專案會一直這樣順利地進行而喜笑顏開時，事情發生了——客戶看到第一份交付物時，對一些功能不太滿意，對這樣那樣的功能提出了修改意見，甚至還提出了新的功能——需求變更發生了。

當客戶對需求提出變更時，我們往往第一反應就是記錄，然後回去照著做，但很多經驗證明這樣是不對的。不加分析而草率地修改客戶提出的變更需求，是造成客戶頻繁變更需求的根本原因。我們前面提過，客戶提出需求的一個重要特點就是，當軟體沒有真正設計出來時，客戶往往是說不清楚自己的真正需求的。因此，當他再次看到上次提出變更以後修改的內容，很有可能還不滿意，這就意味著還要繼續改，直到他滿意為止。這樣，反覆修改是再所難免。

當客戶提出需求變更時，我們首先應當弄明白的是客戶為什麼要提出這樣的需求。這時候，需求分析員應當站在使用者角度，站在業務角度，去理解這樣的需求，理解其提出來的動機。也許客戶在做這個操作時要檢視一些相關資訊，也許這個資料和那個資料有邏輯關係，甚至其原因就是一個非計算機專業的人看到這個介面不容易理解、有誤解，或者操作就有困難。

當理解了使用者提出變更的真實動機以後，隨後分析的就是這樣的變更有沒有必要，可不可實現，或者是否有更合理的解決方案。每次我們都會將一些客戶提出的不合理的，或者無法實現的需求變更退回去，並且提出我們的理由。只要遣詞得當、理由充分，客戶往往能接受我們的建議而取消這些需求（多用建議的語氣，少用命令的口吻）。而另一些變更需求，我們常常從使用者表面的語言中分析出他們真實的需求，並提出一個更加合理的建議。這樣做，客戶不僅會欣然接收你的建議，而且會有一種你就是他肚裡的蛔蟲那種感覺，對你更加信任，你在客戶心裡的威信也就隨之增加。

當客戶提出變更需求，並且經過分析已經確定出修改方案以後，A先生就馬上回去組織人員進行設計和開發了，殊不知這將是專案後期出現巨大隱患的重要原因。迭代式開發的正確做法應當是怎樣呢？這個問題我們下回詳細分解吧。

專案管理迭代開發需求變更變更管理

前面我們提到了需求變更。當客戶提出了需求變更，經過與我們的需求人員的詳細討論與分析，最後確定下來了變更內容和修改方案。但這時草率地開始進行設計和開發是不正確的，它將成為專案後期的一個巨大的風險，一顆定時炸彈，為什麼呢？我們來詳細分析分析。

每當發生需求變更的時候，不管是大是小，專案的許多因素都會相應地發生變化。首先發生變化的是工作量。每次的變更必然造成工作量的增加，到底增加了多少呢？我們需要對其進行評估。同時，我們還要對增加的工作進行優先順序評估。一般來說，新增加的工作往往優先順序都是最高的，是客戶急切想看到結果的部分，那麼其它的工作的優先順序就會收到影響，優先順序就會有所下降。當工作量的增加與優先順序的調整完成後，隨後的工作就是專案計劃的調整。

前面我們說過，迭代式開發的專案計劃與傳統的專案計劃是存在巨大差異的。迭代式開發的專案計劃其核心，就是如何將各項任務合理分配到各個迭代期中去。任務就像一個個大小不一的石子，迭代期就如同一個個網格，專案計劃就是將石子分發到各個網格中，雖然有一些空隙，但大體是滿的。現在新任務來了，就如同要將新的石子放到已滿的網格中，有幾種可能：石子很小，利用網格的空隙就可以填滿了；石子太大了，如果要把這個石子放進這個網格中，就必須將裡面的某個石子取出來，放到別的網格里。現在專案計劃的變更就是這樣。

如果新的工作量很小，往下一個迭代期擠一擠，即使超了1、2天也能擠下，那就擠擠吧，但這個迭代期可能會延期，後面工作的時間節點也必然隨之調整；如果新的工作量還不小，優先順序還比較高，那麼只能將下一個迭代期中已有的任務取出，調整到其它迭代期中，這可能會導致後面整個的工作計劃都將調整。不論怎樣調整，我們都應當將調整後的工作計劃告知客戶。

不論業務需求怎樣變更，不論專案計劃怎樣調整，通知客戶，讓客戶理解，並與我們共同承擔專案延期的風險，這是從無數失敗的專案中總結出來的血的教訓。一定要讓客戶明白，你們可以改需求，可以提出修改意見，但必須與我們一同承擔風險。當客戶意識到這一點時，也許他們就會慎重考慮了，甚至一下變更需求就會被取消。

在變更專案計劃的同時，另一項重要的工作就是變更我們的產品需求說明書。在專案管理中，需求文件往往分為兩個：原始需求和產品需求說明書。原始需求是客戶編寫的，站在客戶角度描述的業務需求，而產品需求說明書是我們在對原始需求分析、理解、調研以後，剔除那些技術無法實現的內容，最後形成的文件，是我們的軟體最終做成什麼樣的依據性文件（需求文件其實很多，如需求規格說明書、產品規格說明書等等，但都大同小異）。產品需求說明書是程式開發的依據，軟體測試的依據，使用者驗收的依據，貫穿整個軟體開發的核心。因此，當業務需求發生變更之後，產品需求說明書一定要進行相應的變更，並做好變更的記錄，與客戶簽字確認。這樣做的另一個好處就是防止客戶隨意變更需求，使客戶對變更的提出更加慎重。

另外一個需求變更中常常出現的尷尬局面就是，當所有情況都清楚告訴客戶以後，客戶提出需求必須要變更，但最終交付時間卻不能改變。這著實是一個相當矛盾的問題，變更必然造成工作量增加，工作量增加必然影響最終交付時間，但交付時間又不能變，這聽起來既不合情又不合理，但在現實的專案中經常發生，而且各有個的充分理由，我們這怎麼辦呢？其實解決這種情況的辦法就是在制訂專案計劃之初就提前考慮到。記得我們前面提到，我們在制訂專案計劃時應當在時間上留有一定的富餘。如何制訂專案計劃，《越獄》這部電影給了我們很多的啟示。如何成功越獄，主人公在越獄過程中的每個風險點都制訂了風險規避和補救的辦法，專案計劃也是這樣。專案需求變更就是一個風險點，因此專案經理應當在制訂計劃之初就應當做好準備，並提前預留出相應的時間，當專案進行過程中風險出現時才能從容應對。

總之，需求變更不是什麼洪水猛獸，也不是一個專案可以完全規避得了的。我們提前準備好，從容應對之，就不是什麼大不了的事情。

迭代開發專案管理需求管理進度管理

其實做一個專案經理真不是一個好的職業，它需要太多的千錘百煉才能修煉出來。這不僅需要反覆經歷“失敗-總結-再失敗”的輪迴，而且需要有一顆無比堅強的心，能夠在無數次經歷無比艱難並且令人沮喪的時刻而能堅持不懈、毫不氣餒。一個專案經理就像一位將軍。將軍百戰死，而專案經理呢，經歷無數專案以後沉澱下來的，更多的是疲憊與滄桑。

但凡一個好的專案經理都是要經過一次又一次專案失敗的教訓，似乎只有失敗才能留給他們更深刻的教訓與更巨大的提升。當然，這種失敗可大可小。即使一些專案最終是成功了，也只是結果的成功，而專案進行過程中的失誤，以及因此帶來的成本的提高，過程的曲折，同樣是一種失敗。專案管理之難，作專案經理之難可見一斑。

專案管理之難，其真正的難處就在於，要將其做好，需要注意的地方實在太多。任何一個方面沒有做好，都會造成專案的失敗。文章之初提出的軟體開發的風險，實質就是軟體需求的風險，在專案管理中就是需求管理。需求管理的失敗是大多數專案失敗的根本原因，這其中包括需求理解的準確性、需求變更的管理，等等。這篇文章討論迭代式開發，就是給大家需求管理帶來一種思路。

而另一個非常重要的方面就是專案進度管理。當專案計劃制訂出來以後，就必須按照專案計劃進行，任何的專案延期都會是一種巨大的風險。如何避免專案延期，是專案成功的關鍵因素。作為專案經理，如何避免專案延期呢？那就是在專案進行的任何時刻都要清楚地知道“where you are”，讓使用者清楚地知道“where you are”。

where you are，對於我們來說就是專案進行到什麼程度了。我們要隨時問我們這個問題，隨時評估專案進度的偏差，及時進行調整，才可能使專案如期交付。如何做到這一點呢？我們制訂了詳細的專案計劃，計劃中將每一項工作的進行時間都制訂出來。這個計劃就是我們的航標，將計劃與進度比較，就可以隨時清楚專案進度的偏差。同時，製作Burn-Down Table，隨時關注還有多少工作沒有完成，還剩多少時間，就可以從另一個角度直觀地認識專案的進度。

當需求發生變更時，必然造成工作量的增加。重新調整我們的專案計劃，就如同重新調整我們的航線。這還包括重新調整我們的人員、我們的分工，以及我們的工期，使其符合實際情況。然後我們就可以按照新的航線前進了（以往很多專案的失敗，正是因為發生變更以後還是按照原有的航線前進，其風險可想而知）。

完成專案計劃修改的同時，不要忘了我們的Burn-Down Table。我們要重新評估我們的剩餘工作量和剩餘時間，繪製到當前的時間上。只有這樣，我們才能隨時知道“where you are”，才能有效地監控專案程序。

那麼，為什麼要讓使用者清楚地知道“where you are”呢？一個軟體專案的進行其實不光是我們自己的事情，也是客戶的事情。專案一旦進行，其實客戶與我們是綁在一根樹上的螞蚱。讓客戶知道我們的進度，能增加客戶對我們的信任感；讓客戶知道我們的難處，會讓客戶與我們共同想辦法去解決問題，去規避專案風險。這樣做，其實對大家都有好處，何樂而不為呢？

所以，迭代式開發對有效避免軟體開發的風險，作用是巨大的。但問題是，如何在專案中實際運用起來，挑戰也是巨大的，很多難題需要解決，我們只有不斷上下而求索，總結、總結、再總結••••••

持續整合  研發管理  極限程式設計  敏捷開發  迭代開發

隨著軟體業的不斷髮展，軟體專案的規模越來越大，軟體結構越來越複雜，技術要求越來越高，參與人員越來越多，管理也變得越來越難。在這樣一個大背景下，如何提高軟體研發質量，相信是所有軟體公司都在關注的話題。但是，如何提供研發質量，這決不僅僅是一個口號，我們必須有一套行之有效的方法加以管理。然而有效的管理帶來的負面影響往往是成本的提高，這包括時間的成本、人力的成本、資金的成本。在大多數軟體研發專案中，時間總是很緊，人力和資金也是有限的。這樣，管理者往往步入一種兩難的境地：一方面為了提高研發質量而需要加大對時間、人力、資金的投入，另一方面現實情況卻不允許我們這樣做，這也是很多管理制度不能真正實施下去的原因。難倒沒有第三種方案能兼顧二者嗎？時下正流行的持續整合技術為我們提供了一個答案。
持續整合（Continuous Integration，簡稱CI），又被稱為持續構建（Continuous Build），最初是以一種研發管理的思想被提出來。1996年，持續整合的思想首先在Kent Beck的極限程式設計中被提了出來。Kent Beck在他的書中是這樣描述的：“團隊程式設計就是先分而治之地解決問題，然後整合。但整合的過程是不可預知的，你等待整合的時間越長，付出的代價就可能越高。因此，每完成一段時間程式設計，系統就應當進行一次整合，並進行相應的測試。”Kent Beck先生將這裡的“一段時間”設定在幾個小時，並提出了整合的同時應當進行測試的思想（這就是敏捷開發中的測試驅動設計）。
後來，持續整合的思想被敏捷開發所吸收，並進一步提出了增量開發的思想。過去，我們解決複雜軟體系統問題的程式設計思想是分而治之。所謂分而治之，就是將大系統劃分成若干小模組，再劃分為一個個小問題，分別予以解決，最後再整合。運用這樣的思想，整合的週期必然很長，可能是數週甚至數月，其風險不言而喻。
增量開發改變了這樣的思想。雖然它依然是將大系統劃分為無數的小模組、小問題，但它不是一股腦地立即去解決所有問題，而是有選擇性地解決最核心、最主要的問題，然後再以進化的方式增量開發、逐漸完善，進而解決其它問題。在這樣一個過程中，每進化一次就整合一次，產生一個可執行的成果，以此迴圈往復，直到最終完成。這樣一個過程就是迭代式軟體開發的過程（詳見《一次迭代式開發的研究：怎樣進行迭代式開發》）。
然而，採用持續整合的方式固然好，但每幾個小時就要整合一次、測試一次，如果人為地去完成，成本依然是巨大的。因而，在敏捷開發大師Martin Fowler的推動下，持續整合工具誕生了。
持續整合工具，就是將程式設計師提交的程式碼，定期從配置管理庫（如svn、vss）中下載下來，整合、編譯、測試，最後釋出到應用伺服器（如weblogic）中，同時打包形成一個版本的釋出產品。一個持續整合工具，需要一個配置管理庫，一個構建工具（如Ant、Maven）。同時，它還可以整合一些靜態程式碼檢查工具（如CodeStyle、PMD、FindBugs），進行自動化的程式碼規範性檢查，以提高程式碼編寫質量。最後，它還需求我們提供JUnit測試用例程式，進行自動化測試，雖然這並不是必選專案。
持續整合工具將不可靠的人為操作，轉變成了機械自動化操作，使不提高專案成本的前提下提高了研發質量成為了可能。

2001年2月，在軟體開發各領域有所建樹的17位大師聯合發表了《敏捷軟體開發宣言》，提出了敏捷開發這一概念，至此敏捷軟體開發風靡世界，為無數軟體開發專案所採用。而在所有這些運用敏捷開發獲得成功的軟體專案中，運用持續整合工具無疑成為一項最重要的最佳實踐，因為它集中體現了敏捷開發的各項思想。

持續整合工具的意義

首先，它促進了專案團隊的溝通與反饋。想想看，持續整合工具使每個人每天的勞動成功及時釋出到應用伺服器上。你只要登陸伺服器，就可以執行和檢視整個專案的每項功能。開發人員可以相互學習各自的設計，需求人員可以確認開發成功是否符合需求，測試人員可以及時測試各項功能。再這樣一個平臺下，溝通變得簡便，反饋也因而變得及時。如果需要，專案組可以隨時拿出最新開發成果向客戶展示，以便獲得他們的反饋。

其次，它促使專案開發過程中的許多工作變得簡單。每天都要無數次地下載最新程式碼、整合、編譯、釋出，還要檢查程式碼是否規範，測試各項功能是否正常執行，這是多麼巨大而繁瑣的工作啊！因為持續整合工具的存在，你只需要及時上傳程式碼，時不時看看反饋結果，多麼easy的事情。它使我們騰出了大量時間去做更重要的事情——程式應當怎樣設計，這無疑提高了團隊工作效率。

另外，它使得增量與迭代的開發模式成為了可能。需求人員可以儘早地看到開發成果，以便儘早地與客戶確認需求，糾正需求方面的問題；測試人員可以與開發過程並行，使測試工作更加充分，時間更加充足；專案經理則可以更加實時地掌握專案進度，保證專案順利完成。

最後，它為開發團隊提供了機會和勇氣去及時糾正他們的錯誤。這一點可能不太能讓人理解，但卻是極度重要的。再有經驗的需求分析師也有理解不到位的分析，再有經驗的開發工程師也有設計不到位的程式程式碼。每天整合的工作，為我們及時發現問題提供了條件（問題發現得越晚，付出的代價就越大）。發現問題以後怎麼辦呢？也許就需要及時的摒棄有問題的程式碼，及時進行重構。但在過去，我們常常沒有這樣的勇氣去重構，因為害怕它影響其它的程式。這是一個誰多說不清的潛在威脅。而現在，有了持續整合和自動化測試過程，我們可以勇敢地重構程式碼、徹底地解決問題。

主流的持續整合工具

目前，比較主流的持續整合工具很多，最著名的當數CruiseControl，而當下的新銳則是Hudson。CruiseControl（http://cruisecontrol.sourceforge.net/）是敏捷大師Martin Flowler旗下的產品，又是免費和開源產品。憑藉大師與開源產品的號召力，當仁不讓成為持續整合領域的巨無霸。它提供了與幾乎所有主流配置管理工具的整合，包括CVS、SVN、VSS、CM Synergy等等，（CruiseControl沒有提供對SourceAnyWhere for VSS的支援，但SAWV 5.4以上提供了對CruiseControl.Net的支援）。同時，它提供了對最主流的Ant與Maven構建工具的整合，提供了對.Net和Ruby的支援，功能不可謂不強大。

雖然CruiseControl功能強大，但隨著後起之秀的一個個出現，它的劣勢被凸顯出來，如安裝配置過於複雜、功能擴充套件能力不足等。在眾多後起之秀中，Hudson無疑是最耀眼的一個。Hudson（http://java.net/projects/hudson/）最吸引人的特性是它很容易配置：很難找到如此容易設定的 CI 伺服器，也很難找到開箱即用特性如此豐富的CI 伺服器。而Hudson 容易使用的另一個原因是它具有強大的外掛框架 ，所以很容易新增特性。例如，一個 Hudson 外掛可以隨時間的推移不斷跟蹤FindBugs 和程式碼覆蓋。但Hudson只能執行在JDK1.5以上版本，這對於一些老專案來說只能是望洋興嘆。

持續整合  配置管理  構建工具 

相關推薦