文
/一覺亮天
2010-10-24
這篇文章之所以叫第二眼看
scrum
，是因為我曾寫過一篇文章名為
first sight at scrum
。寫第一篇文章時我剛用
scrum
不久，對
scrum
的理解還不深。
大約乙個多月前，公司出錢，我參加了一次
scrum master
認證培訓。據說培訓費是
500美金，培訓過後還發了乙個
scrumalliance
的證書，
pdf格式的。
從初識scrum
到如今用
scrum
大約十個月，再加上參加完這個培訓，感覺還是有些心得和體會，就以
recipe
的形式記錄下來。
scrum
是敏捷開發的一種管理流程。
scrum
中包括三種角色，
product owner
，scrum master
，team
，而且只有這三種角色。維護兩份
backlog
，product backlog
和sprint backlog
。一張圖，
burning down chart
（燃盡圖）。
傳統軟體開發中專案經理的角色，一部分任務劃歸了
product owner
，一部分任務劃給了
scrum master。
和傳統軟體開發相比，
scrum
更適合於變化比較多比較快的軟體的開發。
scrum
的每個sprint
的長度一般
2-4周。在
scrum
的每個sprint
，都會產出潛在的可交付的軟體。那可交付的軟體所具有的特徵，它都應該有，比如使用者手冊文件，比如軟體是測試過的可執行的，等。這也對設計提出了更高的要求，軟體設計更多地要按
feature
設計，最重要的
feature
在早期sprint
完成。如果
sprint
失敗，損失就是乙個
sprint
的投入，不會像傳統瀑布模型軟體開發到最後交付一刻才知道成功失敗。
scrum
流程不怕失敗，如果注定失敗，期待失敗早點來臨早點發現。
如果軟體的需求變化不多，或難度不大，不一定要採用
scrum
的方式。
scrum
更適合於難的，變的。對於維護型別的專案，沒有辦法預料有哪些問題會來臨的，類似於救火的這種專案，
scrum
可能也不適合。
product backlog
由product owner
維護，其中的
product backlog item(pbi)
一定按優先順序排序的，也一定有初始
effort
的估計。
po關注投入產出比
(return of investiment, roi)
，也就是
effort/priority
。只有po
有權增減
pbi。
effort
的估計需要
team
完成，因為是
team
做事。
不是。優先順序排在前面的
pbi，設計得比較詳細，優先順序排在後面的
pbi，開始可能沒有設計，但隨著專案的推進，隨著
product backlog
中優先順序高的
pbi的完成，隨著低優先順序
pbi優先順序的提公升，設計逐步細化。也許低優先順序的
pbi最終不做了，如果前期就詳細的設計，最終不做了就會浪費時間。
通常，在銷售那裡什麼承諾都是可以做的，保證如期保質保量地完成需求。但是現實中，軟體開發專案鮮有不超期，也有很多最終是失敗的。我們要讓客戶知道風險，
team
只承諾每個
sprint
能夠交付的目標。
scrum master
不是管理者（
manager
），也不是決策者
(decision maker)
。scrum master
的任務是確保
scrum
按流程進行，排除障礙
( remove impediment)
。scrum
強調時間限制（
time box
）。sprint planing
花費時間是有規定的，
daily scrum meeting
的時間也是有規定的（
15minutes
），scrum master
要確保行為在時間限制內完成。
po隨意變動
sprint backlog
，scrum master
要制止。
sprint backlog
一旦確定下來，就不要隨便變動，因為這是
team對po
的承諾，如果
sprint backlog
不穩定，如何能保證承諾的實現呢？ 最好
scrum master
由非team
成員擔任。
scrum master
也是team
一員，有好處也有壞處。好處是，
scrum master
更了解team
，更了解
sprint
的進展。壞處是，大家會分不清角色。
sprint planing part 1
，選擇。選擇
pbi，一定是按照優先順序選。
sprint planing part 2,
承諾。把
pbi轉化為
sprint backlog item (sbi)
。定義definition of done
。包括設計。如果
pbi過大，需要
break down。
scrum
強調team
的自我管理，不是
scrum master
，也不是
po來管理
team
。commitment
沒有完成，是整個
team
的失敗。
scrum team
中的每一員最好是多面手，這樣才能保證按優先順序來選擇任務，而不是按每個人擅長的領域來選擇任務。在
sprint
的結束，
team
會自省(retrospective)
，哪些是做得好的方面，以保持，哪些是不好的方面，以改進。
scrum
強調迭代（
iterative
）開發，有一些方法，比如測試驅動開發
(test driven development
，tdd)
。要知道
tdd是一種設計方法方面的實踐，而不是一種測試。例如基於
unit test
的測試驅動開發，要實現乙個功能，先寫測試**，然後寫實現**，每次都要保證編譯通過，測試用例通過。測試**和功能**一樣要進行配置管理，版本控制。迭代開發與測試自動化往往也分不開。比如你新增加了
feature
，為了確保不影響舊有
feature
，以前的測試用例需要執行一遍。但是如果執行這些測試用例用手動的方式，則是一件繁瑣耗時的事情。如果有測試自動化，則事情簡單許多。
第二週 SCRUM站立會議
站立會議是成員間每個人面對面站立著說出自己的進展，不是會議，不是寫報告。是為了更好的溝通和協調，本質上是為了工程方面的團隊交流。scrum站立會議的要求如下 1.成員間都是平等的，發言沒有經理和程式設計師之間的差別，每個人都需將發言控制在15分鐘內。2.發言的內容是 之前做了什麼，進度如何。今天要做...
Scrum 衝刺第二天
張博愉 昨天已完成的工作 制定測試計畫 部落格編寫 工作中遇到的困難 對測試接觸得較少 張潤柏 昨天已完成的工作 建立管理員模組一部分的實體類 今日工作計畫 把管理員模組剩下的實體類和表建好 工作中遇到的困難 自己實戰經驗太少，學習的知識也不夠全面 鄭堉涵 昨天已完成的工作 上網查詢部落格，積累知識...
第二眼美女 IEO 和區分 FIND
創新演算法 triz 中的 stc 演算法是 尺度 size 時間 time 和成本 cost 的首字母縮寫。來做題 航海過程中需要用船錨來牽引大船。船錨的重量和船的體積之間有乙個計算比例，比如說一艘船的重量是一噸，這艘船錨的牽引力在 10 噸左右。在硬泥環境下，船錨的牽引力沒問題。一旦碰到有淤泥或...