1? 如何避免在產(chǎn)品開發(fā)后期不斷有重大修改，導(dǎo)致其它模塊的連鎖反應(yīng)??

DCR Tell mode vs. Ask mode設(shè)計變更

在項目早期，如果大家覺得要做一個設(shè)計變更，便可以采用告知模式(Tell-mode)的形式，也就是說，修改方必須通告所有關(guān)系人：“我在這里修改了某某界面, 我在某個API 增加了一個參數(shù)。”但是修改方不必取得其他關(guān)系人(或者模塊)的事先同意，就是說可以先行設(shè)計并編碼。當然，如果其他關(guān)系人不同意，修改還是不能簽入。

當項目進行到穩(wěn)定階段，例如達到了代碼完成(CC)階段，Tell-mode 要改為請求模式(Ask-mode)，這時，修改方必須先問“我是否可以在這里修改某某界面？”(當然還要有更詳盡和充分的理由)，得到肯定的答復(fù)后，才能進行修改。這時的默認回答是“不”。

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

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

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

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

3? 如何避免詫異的反應(yīng)

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

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

問：???? 項目開發(fā)中后期，開發(fā)人員用工具一統(tǒng)計，乖乖，足足xx萬行代碼，xx千個存儲過程，可是每到給客戶演示時，卻不時出現(xiàn)程序的各個功能相互不配合，不能自圓其說的尷尬場景，Dev leader很郁悶，想想自己可是沒少加班啊，代碼量也夠多，可是問題究竟出在什么方面呢？

阿超： 一個原因是每個人都沉浸在“我要寫出最強大的某某類或某某模塊”中，不停地優(yōu)化一些沒有人用的功能，但是真正能夠為其他模塊使用的功能卻未能實現(xiàn)。他們忘了他們寫的代碼是給別人用的，而且是為了解決用戶問題的。所以這個時候我們要想想“用場景驅(qū)動”的方法，保證典型的用戶場景能夠?qū)崿F(xiàn)。如果從“場景”出發(fā)，各個模塊的互相集成就能得到充分的測試，按照場景演示起來就更有保障了。

問：???? 在項目開始之前, 有很多隊員還沒有接觸過編程語言(例如C#)，導(dǎo)致PM在分配任務(wù)時很難用時間來衡量，就拿寫一個Web Service這一模塊來說，一個熟練的程序員可能只需要兩個小時，而對于初學(xué)者來說，就得先花兩天來理解Web Service的實現(xiàn)機制和原理。在有限時間的催促下，導(dǎo)致一些緊急的任務(wù)不斷向高手集中，而初學(xué)者的任務(wù)越來越少。這時應(yīng)該怎么辦？

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

4. 在這個時候是否碰到 “團隊成員不給力” 的問題?? 請看別的同學(xué)的吐槽：

http://www.cnblogs.com/xinz/archive/2010/11/27/1889935.html?

5. 我們是在寫代碼解決問題呢，還是在搭建宏偉的架構(gòu)? 請看：http://ourjs.com/detail/53dbb5292ee109090700000c? 英文版：http://nsainsbury.svbtle.com/java-developers? 6. 好的修改/重構(gòu)是什么樣的?? 請看幾個例子： http://world.kankanews.com/w/2014-11-22/0015946771.shtml http://www.cnblogs.com/marvin/p/TalkFromReflactingCode3000To15.html?

[i] ???? VS2010以及之后的版本還提供了燃盡圖等功能，請參見相關(guān)同學(xué)的博客，例如

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

7. 不同建模工具的特點：

我們講了好幾種建模和設(shè)計工具，它們在以下的方面有什么特點呢?

1)容易理解，特別是對于非專業(yè)人士來說。

2)不僅能處理非常簡單的問題 (如計算一個文件的行數(shù))，還能擴展到處理復(fù)雜的現(xiàn)實世界的關(guān)系，實時系統(tǒng)，復(fù)雜的商業(yè)邏輯，等。

3)?能非常精確地描述問題

4)能精確地把這個模型轉(zhuǎn)換為代碼

5) 能很好地應(yīng)對變化 (如果我們改變了設(shè)計，代碼和模型能很快地跟隨變化)

8. 軟件設(shè)計的工具 創(chuàng)作需要工具，有些學(xué)科只需要簡單的紙和筆，有些需要專門的工具。 1) 請調(diào)查一下你周邊的同學(xué)在寫軟件的時候都使用什么工具 (IDE, 測試工具等) 2) 請采訪有兩年以上工作經(jīng)驗的軟件工程師在使用什么開發(fā)/測試工具 3) 請采訪有三年以上經(jīng)驗的產(chǎn)品經(jīng)理在使用什么項目管理工具，這些工具有什么優(yōu)缺點 4) 很多和信息處理相關(guān)的應(yīng)用都是 “增刪改查” 操作的組合， 那么能否抽象出這些操作， 找到規(guī)律，自動生成基本的信息應(yīng)用呢？ 請分析這個軟件工具： http://garrylachman.github.io/ElectroCRUD/? ? 9. 不同的設(shè)計方法有各自的適用范圍，OO 也是這樣 很多同學(xué)都上過 《面向?qū)ο蟮某绦蛟O(shè)計》這門課，請閱讀下列文章，談?wù)勀愕目捶?#xff1a;
????http://www.vaikan.com/object-oriented-programming-is-inherently-harmful/? http://doc.cat-v.org/programming/bad_properties_of_OO? http://harmful.cat-v.org/software/OO_programming/why_oo_sucks http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf

總結(jié)

以上是生活随笔為你收集整理的现代软件工程 第十一章 【软件设计与实现】 练习与讨论的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。