硝煙中的 Scrum 和 XP

scrum的關鍵之一是時間盒，scrum關注生產(chǎn)率

scrum的理論和框架其實很簡單，我們更多的關注是如何進行scrum的實踐，每種實踐的方法和方式。

本書名字的定語“硝煙中的”，這個非常貼切，我這短短一兩個月的敏捷導入充分體現(xiàn)到了“戰(zhàn)爭”無處不在。理念的灌輸，工程實踐的落地，在制品的限制，DoD的規(guī)則沒有任何一點能夠很順利進行的。

還好我自己深信敏捷的理念，我相信能夠帶來一定的價值，否則是真的做不下去了。

書中對scrum和xp的定義，scrum更多的是管理和組織實踐，而xp更多的關注的是工程實踐（編程實踐）。

scrum僅僅定義了我們要做哪些事，以及如何開展和實施，但具體質量如何達到內(nèi)建的效果主要是通過編程實踐。

下面是書中介紹的scrum各主要的活動實踐方法：

我們怎樣編寫產(chǎn)品 backlog

PS：我們的不足，產(chǎn)品的backlog編寫的很不完善，尤其是演示標準，其實也就是驗收標準沒有被細化，我們會有具體的請求者以及上線后的驗證環(huán)節(jié)。

注意：產(chǎn)品負責人之外的人也可以向產(chǎn)品 backlog 中添加故事，但 是他們不能說這個故事有多重要，這是產(chǎn)品負責人獨有的權利。他 們也不能添加時間估算，這是開發(fā)團隊獨有的權利。

PS：雖然看板不明確規(guī)要對故事進行估算，但還是推薦進行基本的估算，估算的方式有很多種，后面有介紹

我們怎樣制定 sprint 計劃

? sprint 目標。

? 團隊成員名單（以及他們的投入程度，如果不是 100%的 話）。

? sprint backlog（即 sprint 中包括的故事列表）。

? 確定好 sprint 演示日期。

? 確定好時間地點，供舉行每日 scrum 會議

PS：對于Scrum來說，迭代會議非常重要，團隊要能夠明確此次迭代的目標，對迭代故事有清晰的了解和估算，在前期可能會出現(xiàn)會議時間不好把控，方式方法不太準確，所以tw的需求梳理會有一定的必要，并且兩個會議之間要留一點點空窗期，使得大家對故事背景場景以及故事基本設計方式能夠稍微有一點思考，使得計劃會議更加有效。

PS：敏捷我們說不要再質量上讓步，我非常贊同這個觀點。不過還有一點，對于用戶來說什么是質量，質量體現(xiàn)在什么方面；不同的產(chǎn)品看待質量的方式不同，我們投入的側重點應該也不同。對于一個SNS它的事務的強一致性要求不高，但是對交互體現(xiàn)要求很高。對于我們boss系統(tǒng)和銀行的系統(tǒng)和錢相關，事務強一致性是第一要求，所以ui和ux上的質量妥協(xié)也是正常范圍。

Scrum有一個很重要的活動規(guī)則是，節(jié)奏。節(jié)奏對于工作和生活都是這樣，穩(wěn)定的節(jié)奏使得人工踏實，更利于穩(wěn)定的輸出產(chǎn)能。所以迭代長度一定要盡量穩(wěn)定。同時要保持相對較短的迭代周期。更短的迭代周期管控風險，快速交付獲得反饋等等好處，也能夠消除“潛規(guī)則”下的遺忘。

指定scrum的計劃是要根據(jù)歷史產(chǎn)能（生產(chǎn)率），并留出一部分富余時間，要給團隊和個人思考和改進的時間。

定義完成非常重要，2:8原則，沒有清楚的定義會使得估算和計劃沒有意義。

時間估算的方法：

紙牌估算（團隊相互備份非常的）

資深和普通開發(fā)者一起近似取平均（團隊中絕大多數(shù)還是以專人專模塊負責方式運作的，看板推薦的方法，現(xiàn)階段我也比較認同）

故事拆分和故事拆分為任務：

對于故事的拆分我們團隊訂的規(guī)則是，如果可以拆分為可交付的單元那么拆，否則不予拆分。任務呢，盡量拆一下，否則時間估算和風險預警都不好做，如果團隊內(nèi)還有明確的測試和開發(fā)環(huán)節(jié)，如果不進行基本的拆分會導致迭代前期測試“無事可做”，后期擠壓。當然別的工程實踐可以解決此類問題如XDD，測試前移等。

技術故事：