現代軟體工程 第十一章 練習與討論

標籤：blog   http   使用   width   io   art   

1  如何避免在產品開發後期不斷有重大修改，導致其它模組的連鎖反應? DCR Tell mode vs. Ask mode設計變更

在項目早期，如果大家覺得要做一個設計變更，便可以採用告知模式（Tell-mode）的形式，也就是說，修改方必須通告所有關係人：“我在這裡修改了某某介面, 我在某個API 增加了一個參數。”但是修改方不必取得其他關係人（或者模組）的事先同意，就是說可以先行設計並編碼。當然，如果其他關係人不同意，修改還是不能簽入。

當項目進行到穩定階段，例如達到了程式碼完成（CC）階段，Tell-mode 要改為請求模式（Ask-mode），這時，修改方必須先問“我是否可以在這裡修改某某介面？”（當然還要有更詳盡和充分的理由），得到肯定的回覆後，才能進行修改。這時的預設回答是“不”。

2  每周進度報告——還有多少事沒做完

小飛： 我們每天都在簽入新的代碼，每人都很忙，但是我總覺得不太對勁。感覺事情越做越多，我們離最終目標到底是更接近了，還是更遠了呢？

阿超： 這時我們可以看看各種報表，首要推薦的是TFS 的“Remaining Work”，可以看敏捷流程的“燃盡圖 (burndown chart)”（Burn down chart）。如果你看到每個人每天花費的時間在不斷增加，但是真正需要解決的任務（Task）和缺陷（Bug）都沒有變化，甚至緩慢增加，這意味著團隊離最後目標越來越遠了。

可以在TFS報表設定的控制板中，進一步選擇你要報告的內容，如：Iteration，選擇裡程碑；Area，選擇項目的不同部分，也可以修改報告的起始和終止日期等[i]。

3  如何避免詫異的反應

問：     每次裡程碑結束後，我們向客戶彙報的時候，客戶總是會驚訝地說，某某功能不是我們當初商量的那樣啊，而PM卻也同樣一臉詫異地說，不對啊，當時咱們就是這麼說好的啊，有文檔為證。客戶不幹了，威脅不加/不改xx功能就如何如何，這時PM該怎麼辦?

阿超： 我們在合約裡要寫明到底我們要交付的是什麼，這就要看PM的分析和說明能力了。有時要對客戶說“不”。同時，我們在需求說明中也要從使用者的角度去描述問題和解決方案，這樣使用者才能瞭解他們最終會得到什麼，另一個方面是，當你給使用者示範一些介面的時候，要說明哪些介面只是樣本而已，哪些介面是大家同意的最終設計。敏捷的開發流程鼓勵使用者經常參與設計和計劃，如果有條件這麼做，那當然很好。

問：     項目開發中後期，開發人員用工具一統計，乖乖，足足xx萬行代碼，xx千個預存程序，可是每到給客戶示範時，卻不時出現程式的各個功能相互不配合，不能自圓其說的尷尬情境，Dev leader很鬱悶，想想自己可是沒少加班啊，代碼量也夠多，可是問題究竟出在什麼方面呢？

阿超： 一個原因是每個人都沉浸在“我要寫出最強大的某某類或某某模組”中，不停地最佳化一些沒有人用的功能，但是真正能夠為其他模組使用的功能卻未能實現。他們忘了他們寫的代碼是給別人用的，而且是為瞭解決使用者問題的。所以這個時候我們要想想“用情境驅動”的方法，保證典型的使用者情境能夠實現。如果從“情境”出發，各個模組的互相整合就能得到充分的測試，按照情境示範起來就更有保障了。

問：     在項目開始之前, 有很多隊員還沒有接觸過程式設計語言（例如C#），導致PM在分配任務時很難用時間來衡量，就拿寫一個Web Service這一模組來說，一個熟練的程式員可能只需要兩個小時，而對於初學者來說，就得先花兩天來理解Web Service的實現機制和原理。在有限時間的催促下，導致一些緊急的任務不斷向高手集中，而初學者的任務越來越少。這時應該怎麼辦？

阿超： 對於這些隊員，可以考慮在他們自己的任務估計值之上再乘以4。另外，如果你是寫一個商業項目，請不要讓連開發語言都沒有接觸過的隊員進行開發工作。並不是非得 “寫” 程式才是對項目有貢獻，有時不寫也有很好的貢獻。如果他們有熱情，就從測試開始學習吧。請參看前面提到的“大馬哈魚洄遊模型“

 

[i]      VS2010以及之後的版本還提供了燃盡圖 (burndown chart)等功能，請參見相關同學的部落格，例如

http://www.cnblogs.com/OMG-Team/archive/2011/09/30/2196150.html