1.1 需求變化
項目的需要變化是肯定有的，而且變化一般都很頻繁，我們怎麼應對客戶的這種需求變化呢，以不變應萬變。首先在前期的需求調研要做好，儘可能的替用戶考慮，達到功能質量滿足最大化。需求調研前期的《目標與範圍》和需求調研末期的《功能規格說明書》都要跟客戶簽字確認，這樣既能保證我們所理解的需求就是客戶所要的，也使得項目末期跟客戶驗收時有據可依。在項目中期是發生需求變更是很常見的，這時要做好需求變更管理流程。需求變更表，小的變更自己掌握，客戶要求的變更有開發人員和設計人員共同商討後提交項目經理，項目經理預估變更損耗工程時間，在一定階段一起提交給客戶，大的變更直接提交客戶，並且要把需求變更對項目產生的影響讓客戶知道，把球儘可能的踢給客戶，讓客戶在進度、功能、資源三者中取捨出一個平衡來。對需求進行分類評級，關鍵部分不能改動的做特別確認（如系統架構等，如果改變等於從頭再來）。同時完成客戶簽字確認，當然如果能將這部分寫成合同細節中去是最好。以下是我認爲變更的步驟：
¢ 第一步：客戶提出變更內容
l 客戶提交的變更必須基於書面形式
l 客戶提交的變更必須有充分理由
• 如果變更被拒絕，對業務的負面影響
• 如果變更被接受，對業務的正面幫助
¢ 第二步：爲能否實現變更作評估
l 從實現方式上考慮新的變更可否實現
l 對於較複雜的情形，輔以簡單的說明。欲詳述，可作附件處理
l 對於簡單情形，例如頁面佈局更改，則無須說明
¢ 第三步：可以實現看進度
l 進度幾乎是絕大部分項目關注的第一要素
l 對於活動級別的進度影響
l 對於項目整體工期的影響
¢ 第四步：變更成本
l 人力相關的變更成本
• 是否需要額外的項目組成員
• 項目組需要增加的工時數
是否正常工時（工作日加班、節假日加班）
• 項目工數報價
l 非人力成本
• 軟硬件費用
• 資料費用等
¢ 第六步：質量和風險
l 變更對質量的多方面影響
• 分階段影響（需求、設計、編碼、測試、維護）
• 可靠性、安全性、可維護性、可用性等
l 可能對團隊士氣的負面影響
l 可能引發的間接任務對工期的負面衝擊
l 開發方的成本負擔可能超出力所能及的範圍
¢ 第六步：需求變化的確定
1.2 架構設計
撰寫詳細設計是一個逐步細化、深入的過程。沒有人能一次就設計出完美的東西，需要及時的溝通，包括與客戶的反饋，與其他項目組成員的討論，這樣有助於降低開發時偏離需求的風險。也就是說，在開發之前題，是建立在設計者的想法有客戶的確認和開發人員的理解的基礎之上設計撰寫人必須與系統分析員反覆討論，以透徹理解用戶需求；
一項需求可能有多種方式實現，設計者必須與系統分析員確定該需求將採用何種方式實現，將達到何種效果，以消除將需求映射爲設計的歧義；討論過程中還可能會發現需求有不完備甚至錯誤的地方，在需求重新確定後設計者需修正設計。設計文檔必須寫清楚各個模塊/接口/公共對象的定義，列明程序的各種執行條件與期望的運行效果，還要正確處理各種可能的異常。此外設計文檔應該遵循一定的寫作模式與版面風格，使用統一的術語或慣用語，使得小組成員很容易理解。以上這些活動綜合起來將是一個很細緻、很耗時的工作過程。就個人所知，一些公司的詳細設計通常是由程序主管或少數核心的程序員撰寫的，他們通常也是系統架構的主要作者或維護者。因爲他們在開發團隊中技術最爲精湛，對架構最爲熟悉，他們最有資格評價現有架構是否能適應新的用戶需求，採用何種方式實現需求對架構的衝擊最小。但是由少數人來負責所有的詳細設計可能造成開發過程中的瓶頸甚至是設計的錯誤。當任務比較集中的時候，設計者可能忙得透不過氣，而負責實現的同事反而在等米下鍋，比較清閒。於是爲了讓自己不成爲拖累進度的“罪人”，某些設計者就會採用一種快捷方式來交付設計：他們會與系統分析員進行初步的討論，然後撰寫一份粗糙的但仍然叫做詳細設計的文檔，把它交付給負責實現的同事，再通過討論、即時通工具、電子郵件等方式解答對方提出的疑問。但由於詳細設計本身不完備，他們不得不花費更多的時間和精力與負責實現的同事溝通；而且他們卻很可能忘了把這些交流的成果更新到詳細設計中去！（或許是他們太忙，沒有足夠的時間，又或許是他們認爲既然產品已經實現，那麼詳細設計也就不必維護了。）其結果很可能是當產品開發出來後，我們才發現它跟用戶要求的完全兩樣！原本在詳細設計階段就應該發現的需求漏洞與在那時應該確定的技術方案在實現階段甚至測試階段才暴露出來，而這時大家往往有木已成舟的感覺，改動的難度比設計階段高數倍甚至十倍以上，畢竟任何再牛的人都有自己的侷限。
對於以上問題我提出全員設計，全員設計的含義就是把詳細設計的工作進行適當地分解，把它們分攤到小組內其它同事身上，讓大家都參與設計。這可以說明如下：
當一組用戶需求基本確定下來後，程序主管需要估計需求的相關性、需求的優先級、設計的難易程度、設計的工作量等，將該組需求分解爲一或多項設計任務，並指定給適當的同事。參與設計的每個人必須負責至少一項設計的撰寫任務。設計者從系統分析員處獲得詳細的用戶需求，並與系統分析員反覆溝通以透徹理解用戶需求。他還要分析系統架構及產品的已實現與/或已規劃部分，理解架構的設計理念，理解產品不同模塊之間的協作關係，理解架構與產品之間的約束和依賴。當然對系統架構和產品的分析不可能窮盡每一個細節，只要分析與即將開發的模塊相關的內容即可。
一項設計任務，它可能需要多個程序員完成。比如用戶界面或網頁由某位或某組同事負責，而業務邏輯組件則由另一位或另一組負責，數據庫部分則又由其它同事負責。設計者必須考慮他們的立場，以各方面都相對容易理解的方式寫清楚主要的模塊/接口/對象定義，明確相應的調用規則與主要邏輯處理。如果某項設計任務所涉及的內容太專業化，設計者並不熟悉相關的內容（比如某位C#程序員並不熟悉如何編寫一個存儲過程），他可以用描述性的文字說明該部分的設計要求，並知會相關的同事補充。其它同事在補充時可以對這些描述性的文字重新整理，以更加確切地表達設計內容，更符合文檔的書寫慣例。在設計文檔完成後，設計者必須把他提交給程序主管或由程序主管指定的程序員審閱。個人推薦由其它程序員而不僅僅是程序主管來審閱。不用擔心等待多個人的審閱意見是否可能導致一份設計滯留很久。大家可以並行地工作，不必是A審閱後才能B審閱。可以交叉審閱，即A的設計由B、C審閱，B的設計由A、C審閱等。審閱意見可以用多種方式（如討論、即時通工具、電子郵件）反饋給設計者，設計者負責彙總這些意見並修正設計。以個人的經驗而言，通常設計交付審閱後半天內就可以收到反饋意見了。設計經過反覆地修正直至沒有人再提出修正意見，這時就可以由程序員實現了。以個人的經驗而言，一份設計通常兩、三輪反饋後就可以定稿了。如果多次反饋後仍不能定稿，極有可能是：
a)需求尚未明確，各個方面（包括客戶、系統分析員或設計者）對需求的看法不統一
b)技術或系統架構存在嚴重的限制，無法用較方便的方式實現
全員參與設計好處、風險與不適用的團隊如下：
1.2.1 全員設計可以帶來以下明顯的好處
1.有助於平衡工作量，加快開發進度。詳細設計的任務分解後，程序主管或核心程序員可以有更多的時間處理其它的事務，比如關注軟件的開發質量或改善系統架構。詳細設計的撰寫任務分解後它們可以並行地撰寫，這將極大地提高設計撰寫的進度，節約時間。
2.有助於培養程序員的大局觀。每位撰寫設計的程序員不再僅僅只關心自己負責實現的模塊，他必須從更高的層次考慮和理解設計。
3.有助於加強同事之間的交流與協作。設計者需要與系統分析員、其它程序員、審閱者進行反覆的交流和溝通，實際上每份設計都是多人協作的成果。更多的溝通有助於集思廣益，有助於避免一、兩個人的傾向性意見導致錯誤的設計。每位設計者都需要對自己撰寫的設計負責，他還要向其它同事的設計提供審閱意見或技術建議，彼此的工作是互相支持和依賴的，這有助於減少“只掃自家門前雪，不管他人瓦上霜”的想法。
1.2.2 推行全員設計的潛在風險
1.在某種意義上，全員設計可能增加交流的成本。兩個人之間有一條交流途徑，三個人之間最多有三條，四個人之間最多有六條。途徑越多，信息量就越大，而這些信息不見得都是有用的信息。詳細設計的任務分解後，不可避免地有更多的人蔘與交流和溝通，大家要花更多的時間來理解他人的想法，也可能要花更多的時間向他人闡述自己的觀點。特別是在並行撰寫詳細設計的過程中，系統分析員反而可能成爲另一個瓶頸了。但從總體上來看，在設計階段花費適當的代價發現更多的問題，比在實現階段或測試階段再發現問題，仍然是划算的。
2.分解後的詳細設計可能引入衝突的設計內容。由於設計由不同的程序員撰寫，他們考慮問題的角度和思維的方式不可能完全一致，這增大了不同的設計內容之間的計算口徑或交互方式不一致的可能性。這需要設計者們儘可能遵循一致的設計原則，也需要審閱者們儘可能找到這些不一致的地方。
3.並不是所有的程序員都適合參與設計。很明顯，例如剛入職的同事就不適合參與設計，他們對系統架構還缺乏足夠的認識。另外兼職的同事也不適合參與設計，他們的工作方式可能無法保證及時提交設計文檔與參與討論等。
1.3 溝通
在項目的開發過程中，在團隊中的成員之間以及和客戶之間是一個不斷的交流和溝通的過程。我們的開發過程最好是一個迭代式的開發過程（尤其是國內的項目）。這樣我們可以儘早發現開發出來的功能是不是符合客戶的需求，以免開發完了，客戶說這個不是我們需要的後果。
1.4 計劃執行控制
制定系統得整個計劃，任務的劃分以及分配工作，跟蹤任務的進度，使我們的項目進度在控制範圍之內。
1.5 風險管理
風險是隨着項目的不同階段變化的，不同的階段風險是不同的，我們必須分析我們當前面臨的風險的數量、影響程度等，以及怎麼去解決這些風險。
1.6 測試
測試工作目前在國內的中小公司做的都不太好，但是從我們做項目或者產品必須重視測試工作，把握好質量關。
1.7 驗收爲目的的思想
在開發過程中，內部管理還要注意的一點是時刻強調以驗收爲目的的思想，每個任務的最終可交付成果一定要是可以被檢查的，比如，【界面要求：美觀大方、簡潔明快】，這個要求我就不知道如何檢查。所以，給開發小組佈置任務的時候就要考慮如何檢查結果，比如我見過一個計劃，裏面有一個任務【開發人員熟悉EJB編程】，這個任務，除了讓這些人去參加一些專業認證考試，否則，結果很難被檢查。所以，時刻考慮如何檢查結果、如何向客戶交付是項目經理一直要注意的事情，我聽說有些老項目經理拿到項目是倒排計劃的，即首先看如何驗收和驗收標準，然後決定工作計劃。很多項目開始了很久，還不知道如何驗收，那麼這個項目出問題的可能性就很大了。做項目就是爲了驗收，我們的角色不是研究機構，我們的目的就是在付出那麼多勞動後得到結果
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/inshine/archive/2007/06/05/1639170.aspx
