最近接觸了下關於敏捷方面東西，也就順帶了解了下scrum, 訂閱了google group討論，發現國內還是有很多scrum的認識和先行者，也提出了很多關於scrum的建設性意見，我全當歸總下。
1.啥叫scrum
2.為啥要用scrum?
3.如何實施scrum?
4.scrummaster是啥角色？
5.scrum的困難所在
1.啥叫scrum?
一直以來，在軟體開發領域存在著n中軟體開發方法，最常見的就是瀑布，而從今年橫空出世了敏捷的開發方法，於是乎瀑布 vs 敏捷的爭論聲音就一直沒有消停過.而scrum又作為敏捷的乙個很傑出的代表出現了。
scrum (英式橄欖球爭球隊), 軟體開發模型是敏捷開發的一種，在最近的一兩年內逐漸流行起來。
scrum的基本假設是：開發軟體就像開發新產品，無法一開始就能定義軟體產品最終的規程，過程中需要研發、創意、嘗試錯誤，所以沒有一種固定的流程可以保證專案成功。scrum 將軟體開發團隊比擬成橄欖球隊，有明確的最高目標，熟悉開發流程中所需具備的最佳典範與技術，具有高度自主權，緊密地溝通合作，以高度彈性解決各種挑戰，確保每天、每個階段都朝向目標有明確的推進。 scrum 開發流程通常以 30 天(或者更短的一段時間)為乙個階段，由客戶提供新產品的需求規格開始，開發團隊與客戶於每乙個階段開始時挑選該完成的規格部分，開發團隊必須盡力於 30 天後交付成果，團隊每天用 15 分鐘開會檢查每個成員的進度與計畫，了解所遭遇的困難並設法排除。
下面解釋下scrum 的名詞
backlog: 可以預知的所有任務， 包括功能性的和非功能性的所有任務。
sprint:一次跌代開發的時間週期，一般最多以30天為乙個週期.在這段時間內，開發團隊需要完成乙個制定的backlog,並且最終成果是乙個增量的，可以交付的產品。
sprint backlog:乙個sprint週期內所需要完成的任務。
scrummaster: 負責監督整個scrum程序，修訂計畫的乙個團隊成員。
time-box: 乙個用於開會時間段。比如每個daily scrum meeting的time-box為15分鐘。
sprint planning meeting: 在啟動每個sprint前召開。一般為一天時間（8小時）。該會議需要制定的任務是：產品owner和團隊成員將backlog分解成小的功能模組, 決定在即將進行的sprint裡需要完成多少小功能模組，確定好這個product backlog的任務優先順序。另外，該會議還需詳細地討論如何能夠按照需求完成這些小功能模組。制定的這些模組的工作量以小時計算。
daily scrum meeting：開發團隊成員召開，一般為15分鐘。每個開發成員需要向scrummaster匯報三個專案：
今天完成了什麼？
是否遇到了障礙？
即將要做什麼？
通過該會議，團隊成員可以相互了解專案進度。
sprint review meeting：在每個sprint結束後，這個team將這個sprint的工作成果演示給product owner和其他相關的人員。一般該會議為4小時。
sprint retrospective meeting：sprint總結。會議的參與人員為團隊開發的內部人員。一般該會議為3小時。
2.為啥要用scrum?
scrum模型的乙個顯著特點就是響應變化，它能夠盡快地響應變化。所以，國內的很多做外包業務都被國外的客戶要求用這種開發方法。需求的不斷變化，今天要求是a，明天可能又完全換成了b，在這個客戶就是上帝的年代，開發人員是和客戶講不了道理的，所以，不斷的跟蹤客戶需求和及時的根據需求變更做出相應的調整和變化就是scrum的本質好處。
3.如何實施scrum ?
(1) scrummaster將整個產品的backlog分解成sprint backlog,這個sprint backlog是按照目前的人力物力條件可以完成的。
(2) scrummaster召開sprint planning meeting，劃分，確定這個sprint內需要完成的任務，標註任務的優先順序並分配給每個成員。注意這裡的任務是以小時計算的，並不是按人天計算。
(3) 進入sprint開發周期，在這個週期內，每天需要召開daily scrum meeting。
(4) 整個sprint週期結束，召開sprint review meeting，將成果演示給product owner.
(5) 團隊成員最後召開sprint retrospective meeting，總結問題和經驗。
(6) 這樣周而復始，按照同樣的步驟進行下一次sprint.
4.scrummaster是啥角色？
scrummaster 有很多的定義，但是我覺得他只是角色的定義，而不是職位的定義。
下面的定**釋也正好符合這個觀點：scrummaster 就角色來說的任務是維護scrum流程的無障礙運轉，其作用不在於領導和管理，而在於維護過程。他不是乙個管理決策者，也不參與開發的實際操作，其管轄的只是流程。
5.scrum的困難
1, sprint backlog確定依賴在團隊的經驗和實誠程度, 經驗不足可能導致選擇有大偏差，不實誠可能故意減少(也就是拿軟柿子)，如果經驗不足的話，又會對潛在的風險缺乏認識和掌握，最後造成失敗的後果。如果團隊選擇的sprint backlogs和團隊乙個sprint內的開發能力匹配，那麼scrummaster就有責任敦促開發人員的開發責任，這也是他的權責範圍：賞與罰。
2, 燃盡圖的製作沒有客觀的依據，依賴主觀判斷
3,spring backlog的規模度量沒有客觀依據，無法在多個團隊間共享度量方法。sprint backlog規模度量直接對映到人天，估計者會受到很多心理壓力（估計工作更像是開發人員的一種承諾，開發人員的性格又都各有差異，誰都不想給在很大壓力的環境下工作吧）
參考**：
google agilechina
關於DDD的認識
引用自http www.jdon.com jivejdon forum messagelist.shtml?thread 32093 count 15 start 30 什麼是dao，repository?在repository情況下，dao其實是多餘的，repository可以完全替代dao。以j...
關於粒度的認識
構建資料倉儲時，如何描述事實表的單個行？答案就是粒度。粒度定義意味著對各事實錶行實際代表的內容給出明確的說明，傳遞了同事實表度量值相聯絡的細節所達到的程度方面的資訊。實際應用中我們一般會這樣定義粒度，比如 顧客購物券上掃瞄裝置一次拾取的分列項內容 醫生開出的單據專案內容 銀行帳號的月快照 手機使用者...
關於指標的認識
在寫圖的鄰接矩陣轉化為圖的鄰接表儲存時，碰到了乙個問題，為每個節點建立好vnode之後，每個節點的arcnode無法正確建立。在除錯的過程中，發現程式有新建節點的操作，但是沒有與之前的鍊錶指標關聯，這個問題本質上是線性表的建立問題。尋找程式的錯誤，發現首先是新建操作的p節點沒有回到起始位置，也就是沒...