【原創】老谷專案管理MSN群線上討論（2009.8.11）：談談敏捷開發

主題介紹

穀雨霖 說:
今天，我們有幸請到的是
敏捷專家王老師。他從事電信行動網路監測系統的開發與維護。在網際網路、電信、電子和鐵路等行業，在敏捷開發和專案管理等方面，具備多年實踐經驗。2006年開始將Scrum應用到專案管理實踐，致力於在中國的軟體開發業界推廣Agile理念和方法論，篤信以人為本，關注敏捷，專注Scrum和XP。
時間正好到了，下面我們請王老師給大家做敏捷的介紹，然後留些時間討論。

內容闡述

王老師說:
其實敏捷應該不是什麼新名詞了，相信大家都有所瞭解，但一開始還是羅嗦些理論吧
敏捷是針對瀑布模型而來的，大家知道，瀑布模型中，開發被認為是按照需求分析，設計，實現，測試 (確認)， 整合，和維護堅定地順暢地進行。
瀑布模型核心思想是按工序將問題化簡，將功能的實現與設計分開，便於分工協作，即採用結構化的分析與設計方法將邏輯實現與物理實現分開。將軟體生命週期劃 分為制定計劃、需求分析、軟體設計、程式編寫、軟體測試和執行維護等六個基本活動，並且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下 落。  但瀑布帶來的問題就是：
1、由於開發模型是線性的，使用者只有等到整個過程的末期才能見到開發成果，從而增加了開發的風險；   2. 在瀑布開發模式下，早期的錯誤可能要等到開發後期的測試階段才能發現，進而帶來嚴重的後果。 3. 各個階段的劃分完全固定，階段之間產生大量的文件，極大地增加了工作量；。。。。。
還有很多就不列舉了
而敏捷方法則在幾周或者幾個月的時間內完成相對較小的功能，強調的是能將盡早將盡量小的可用的功能交付使用，並在整個專案週期中持續改善和增強。
1、XP（極限程式設計） 其思想源自Kent Beck和Ward Cunningham在軟體專案中的合作經歷。XP注重的核心是溝通、簡明、反饋和勇氣。因為知道計劃永遠趕不上變化，XP無需開發人員在軟體開始初期做出很多的文件。XP提倡測試先行，為了將以後出現bug的機率降到最低。
2. SCRUM   這是一種迭代的增量化過程，用於產品開發或工作管理。它是一種可以集合各種開發實踐的經驗化過程框架。SCRUM中釋出產品的重要性高於一切。
Scrum是在十多年前由Ken Schwaber 和Jeff Sutherland 博士共同提出的，現在此方式已被眾多大中小型企業使用，其中包括Yahoo! ，Microsoft， Google， Lockheed Martin， Motorola， SAP， Cisco， GE Medical， CapitalOne 和 US Federal Reserve. 許多使用Scrum 的團隊都取得了重大的改進，其中更有個別在生產效率和職業道德方面得到了徹底地改革。
3. 水晶方法族  由Alistair Cockburn在20實際90年代末提出。之所以是個系列，是因為他相信不同型別的專案需要不同的方法。雖然水晶系列不如XP那樣的產出效率，但會有更多的人能夠接受並遵循它。 水晶方法有很多分支，包括橙色水晶、藍色水晶。。。。
4. 自適應軟體開發 ASD 由Jim Highsmith在1999年正式提出。ASD強調開發方法的適應性（Adaptive），這一思想來源於複雜系統的混沌理論。ASD不象其他方法那樣有很多具體的實踐做法，它更側重為ASD的重要性提供最根本的基礎，並從更高的組織和管理層次來闡述開發方法為什麼要具備適應性。
5 。 DSDM動態系統開發方法   這也是眾多敏捷開發方法中的一種，它倡導以業務為核心，快速而有效地進行系統開發。在英國，由於其在各種規模的軟體組織中的成功。
6. 輕量型RUP   這是從IBM發展出來的，但是即使現在在IBM內部，也有很多爭論，也開始轉向SCRUM 與 XP， 因為其流程還是較複雜
7. 精益方法  這個事從豐田的 精益生產理論發展出來的， 精益模式提倡持續不斷地改進、減少流程中的浪費。
在我們的實踐過程中，我們主要關注更多的、採用更多的是前兩個，也就是Scrum 與 XP....我覺得這兩個方法非常具備操作性，應用起來比較有效果
 Scrum 主要提倡如下敏捷原則 ：
?       保持簡單：Scrum本身就是很簡單輕量級的流程，它能簡化我們的開發流程。
?       接受變化：Scrum鼓勵將工作細分成小塊。它關注的是一小段一小段時間，但是隻有在這些時間段的中間，我們才可以重新調整工作的優先順序。
?       不斷迭代：Scrum需要在小於30天的一次次迭代中構建應用程式。
?       不斷的反饋和改善：在每一次迭代的末尾，Scrum流程要求我們回顧以前是怎麼做的，並且思考我們下次可以做哪些不同的事來改善流程。
?       協作：Scrum強烈鼓勵團隊成員的協作和溝通。如果沒有這些，Scrum就一點用都沒有。
?       減少浪費：Scrum幫助我們識別做那些只對客戶或者團隊有價值的事情。
這些都是跟 敏捷宣言 相一致的
Scrum其實僅僅定義了一個開發框架(Framework)，具體的程式設計實踐，完全取決於每個團隊，並且是完全基於常識進行管理的，這也是為什麼我們要採用XP的緣故
Scrum的流程 涉及如下一下概念 ：
"產品訂單" (product backlog)：這是你構建一個產品所需做的所有事情的一個高層次的列表，並按優先順序排列，這樣可以保證你總是工作在最重要的任務上。
" 衝刺訂單"（sprint backlog)：是sprint的工作任務列表。一個"衝刺"訂單來自於產品訂單上最高優先順序的一些任務，以及產生的附加任務，每一個任務都應該有一個 明確的“完成（Done）”的定義。
注意， 這裡的衝刺就是 一次迭代！！
"衝刺"（sprint）：一個sprint就是一次為完成特定目標的迭代，一般是2-4個禮拜。
此外，還有一個角色叫 "產品負責人"(Product Owner)：這個人是負責維護產品訂單內容和優先順序。
Scrum 真的很簡單， 概括講  是一個非常輕量級的流程。簡單講 "產品負責人"是先建立一個產品"訂單"(backlog)，做一個短期“衝刺”(sprint)計劃，執行這個計劃，每天開會討論計劃中的問題和進展，計劃完成後演示工作成果，再對該階段的工作做回顧、反思，接著不斷重複以上流程。
每天開一次短會，檢查sprint中每個任務的進展狀況，對未完成的任務，要求任務所有人給出新的剩餘工作量的估算。
最後後再開一次回顧會議，找出不足，持續改善
Scrum 中還有另外一個角色 ，Scrum Master    ScrumMaster 促進 Scrum過程，他的主要工作是去除那些影響團隊交付衝刺目標的障礙。ScrumMaster 並非團隊的領導（由於他們是自我組織的），而是負責遮蔽外界對開發團隊的干擾。
ScrumMaster 是規則的執行者。
“每日站立會議” 每個團隊成員需要回答三個問題：
    * 今天你完成了那些工作？
    * 明天你打算做什麼？
    * 完成你的目標是否存在什麼障礙？
需要注意的是Scrum Master需要記下這些障礙，並負責幫助解決
Scrum 的要點基本就這麼多。。。很簡單的，沒有涉及到任何實踐，所以能跟其他敏捷方法並存，還能跟其他方法論並存，譬如CMM
下面再看看 XP， 極限程式設計 。 相信這個大家應該都很熟悉的，簡單說幾句
極限程式設計實踐作業的核心 價值 是 ：
    * 溝通
    * 簡單
    * 回饋
    * 勇氣
    * 尊重
比較好的常用的XP實踐有 ：
1、結對程式設計
2.。 TDD 測試驅動開發（Test-driven development）
3. 持續整合
4. 重構與簡單設計
5. 程式碼集體所有權 與 程式設計標準
6. 增量和迭代開發， small release
7.與使用者（在場的客戶）不斷互動
XP還有實踐，較有爭議的是 8. 每週40小時工作制（40-hour Week）
嗯，就講這些吧
時間關係

問答時間

1.
王老師說:
Scrum 解決的是組織層面的敏捷問題，XP解決的是程式設計實踐層面的問題，二者正好互為補充，相得益彰
Iverson   說:
就是說要用就一起用？
王老師說:
這不見得，要看你想解決什麼問題。。。人們通常容易犯的錯誤，就是拿工具去消滅任何問題。 你拿了錘子，什麼東西都可能是釘子

2.
Iverson   說:
其他都好辦，說說你們TDD 測試驅動開發是怎麼做的吧
王老師說:
測試驅動的。也就是說是在開發功能程式碼之前，先編寫單元測試用例程式碼，測試程式碼確定需要編寫什麼產品程式碼。
通常可以這樣來做
(1) 明確當前要完成的功能。可以記錄成一個 TODO 列表。
(2) 快速完成針對一個功能的測試用例編寫。
(3) 測試程式碼編譯通過，但測試用例通不過。
(4) 編寫對應的功能程式碼。
(5) 測試通過。
  對程式碼進行重構，並保證測試通過。
(7) 迴圈完成所有功能的開發。
Iverson   說:
理論我知道，我想知道你們實際是怎麼做的阿
特別是與資料庫有關的開發
還有gui的測試做嗎？
王老師說:
你需要有個UT框架,  這是針對白盒測試而言的，也是最常見的TDD。 另外測試人員也要早點介入， 從系統的功能的角度進行考慮
x99說:
UT框架 一般java的話 就是junit?
Iverson   說:
wang_lj9057，你能不能把你們公司tdd開發的詳細做法給大家介紹一下阿，或者寫個專題，供我們大家學習一下，呵呵
x99說:
老王的意思 是不是開發人員管開發人員開發 測試人員管測試人員寫測試程式碼啊
王老師說:
每個產品不同，平臺不同，人員不同， 採用的TDD方式與工具也不一樣

3.
Cruiser 說:
請問對於分散式開發的專案（開發團隊不在一個地點）可以採用敏捷方法嗎？如可以要點是什麼？
王老師說:
關於分散式開發，完全可以採用敏捷方法， 關鍵還是在人上，在人與人的溝通上
穀雨霖 說:
每天standing up meeting視訊會議是可以取代的
王老師說:
首先你要決定哪方負責需求，這個很關鍵，一定是挨著客戶最近的那方負責需求
Cruiser 說:
關於分散式開發，關鍵肯定在溝通上，我的意思是專家是否參與過分散式專案組並採用敏捷開發方法獲得成功？因為我看到很多專案即使採用視訊會議系統，在分散式開發時溝通效率還是很低的。
Cruiser 說:
在保證溝通效率方面有什麼好的實踐嗎？
王老師說:
我們現在的專案出問題也就是出在分散式開發的溝通上，效率的確是個問題。不僅僅是一個視訊會議的問題，還有時差。跟印度很好說，相差不大， 跟歐洲就是6-7個小時，跟美國就更多了

4.
x99說:
測試用例 寫程式碼？還是文件？
王老師說:
測試用例， 主要是寫程式碼！！

5.
caixd說:
專案團隊平均工作年限2年左右的情況，可以應用XP嗎？我們比較經常碰到的情況，是新專案組有一定比例經驗不是很豐富的新員工。
王老師說:
可以。我們的新員工進來都要
譬如說我們有結對，但在實踐過程中，不會真正的結對程式設計
而是更多的結對設計、結對評審，幫助新員工迅速掌握產品，掌握TDD開發等
因為實際過程中，真正的結對 1+1 >1  是肯定的， 但不一定就是 1+1 > 2的
caixd說:
補充說明下第三個問題。之所以提到專案組平均工作只有2年，主要是針對於個人技能的不全面，很多時候，即便用瀑布模型，開發人員對於實際任務完全要多少時間，會遇到什麼困難都不知道，而用XP，會不會更難以預測和管理進度？
王老師說:
關於如果員工工作經驗不夠，這個我們的實踐是這樣的
王老師說:
做任務估算時，所有人都參與估算，結果按照DELPHI法則進行。 進行任務認領時，每個認領到該任務的人，可以對該估算做一個調整，調整按照10%進行，就是正負10%， 新人可以增加，有經驗的可以減
這樣，計劃出來後，就充分考慮到了員工差異性，減少了 個人的工作進度對專案組整體進度的影響

6.
Alex 說:
對於Scrum，我的理解是：如果是用瀑布式的話，我們做的就是一個專案；如果是用Scrum的話，就相當於將這一個專案拆成很多很多的小專案；這樣的話，是不是在一定程度上增加了工作量呢？
王老師說:
Scrum 不能簡單的說吧一個專案拆成很多的小專案，只是說把原來一個大的專案，分成多次迭代來實現。
穀雨霖 說:
實際經驗看工作量是否增加？
王老師說:
對於工作量， 是否增加這個我也沒有定論，因為沒做過這個實驗，同時兩種方法做同一個專案。。。個人認為，不會增加

7.
不勝人生一場醉(2009年春節，茫然中...) 說:
Scrum 更適合做產品開發，XP適用的場合是那些？
從專案總的流程來看還是瀑布模型多些，XP和Scrum能否與瀑布模型搭配使用?
王老師說:
總體來講， 瀑布模型 跟敏捷模型、迭代模型相沖突的。。。前面提到了，瀑布模型只有在整個生命週期結束後，才會有一次釋出，才會有真正的產品， 而敏捷，可以在很早期就有一個可以工作的版本。。。這個概念是不一樣的
王老師說:
另外，敏捷模型、迭代模型的每次迭代也看以看成是一個 小瀑布  :)
在SCRUM 與 XP 的早期階段，還是需要瀑布模型的。。。就是需求分析與高階設計
只是說要做的很輕量，不要很重，譬如我們可以花1-2個迭代專門做需求分析於 高階設計
從專案總的流程來看，如果是採用敏捷方法的，一定迭代模型多
XP和Scrum能與瀑布模型搭配使用，但一定要杜絕“瀑布式敏捷”
chinamathman@hotmail.com說:
什麼叫”瀑布式敏捷“?
王老師說:
”瀑布式敏捷“----- 簡單講， 你還是按照瀑布模型來做事， 譬如 分成 需求分析 3個月， 高階設計2個月， 編碼6個月， 測試 3個月，整合測試3個月，然後釋出。。。其中的每個階段做成幾個milestone, 似乎是按照迭代來做

8.
sue說:
我的問題：會不會導致變更劇增，如：一次迭代完成就發現需要變更上一次迭代的結果
王老師說:
需要變更上一次迭代的結果？ 是說需求？
王老師說:
還是說自己的實現？
sue說:
對，就是發現上一次迭代的結果不合理，需要變更實現
王老師說:
哦，這樣，我覺得這個應該是 總體設計或者 高階設計做的不好。 譬如你從.net平臺轉到 linux 去，或者CS轉向BS.
這時候應該停下來，自己考慮一下設計與架構

9.
x99說:
迭代+功能分+每天一次15分鐘左右的會議 屬於Scrum了嗎？
王老師說:
呵呵，關於什麼是Scrum的標準，Nokia有一個。。我轉一下吧
王老師說:
不能簡單就說 ： 迭代+功能分解+每天一次15分鐘左右的會議 == Scrum
x99說:
是Scrum一部分了嗎？
王老師說:
對，是一部分
王老師說:
因為還會有演示、回顧
王老師說:
這是非常關鍵的，這樣不斷回顧總結，才能提高

未解決問題

10.
caixd說:
軟體專案組的上級單位，一般是一個軟體研發部門，管理很多專案組，這時候就期望每個專案組的工作是可預期的。如果員工工作經驗不夠，如何預期每個人的工作進度和專案組整體進度？
x99說:
同問 如果員工工作經驗不夠，如何預期每個人的工作進度和專案組整體進度？

11.
chinamathman@hotmail.com說:
結對程式設計有什麼要求或者前提條件嗎？我在實踐中覺得結對程式設計難度挺大的，對結對的雙方其實都有一定的要求。如果任意一方某些方面做的不合適，都會影響結對的效率，反而適得其反。

12.
Cruiser 說:
對於敏捷開發Delphi法是不是太複雜了？DELPHI法要求背靠背，而且對估算結果要多輪討論直到達成一致。
Cruiser 說:
不過我猜如何準確估算應該已經不是敏捷方法的範疇了吧
liyizhou88@hotmail.com說:
DELPHI最後是要收斂的，也就是說大家都認可了這個估算結果，那怎麼還會需要根據個人情況再次調整呢？或者說，這不是調整，只是正常的估值區間？

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/3433/viewspace-611909/，如需轉載，請註明出處，否則將追究法律責任。