Scrum

1.敏捷Scrum如何開(kāi)始？

為了成功實(shí)施Scrum，團(tuán)隊(duì)必須堅(jiān)持Scrum的基本要素。

• 團(tuán)隊(duì)必須理解Scrum的規(guī)則
• 團(tuán)隊(duì)成員必須學(xué)習(xí)Scrum的基本機(jī)制
• 給予足夠的時(shí)間
• 不要在項(xiàng)目中途實(shí)施Scrum
• 保證為持續(xù)學(xué)習(xí)分配時(shí)間

要知道Scrum是一個(gè)框架，提供的是一整套規(guī)則，而不是一個(gè)指南。
小婧以前覺(jué)得我可以把Scrum中的一部分拿來(lái)實(shí)施，其他的比如結(jié)對(duì)編程、重構(gòu)等不納入也就不納入了。
近些年發(fā)現(xiàn)自己錯(cuò)了。
因?yàn)镾crum框架的各個(gè)部分是相互支撐的，如果你進(jìn)行裁剪，不是倒塌就是變成了另外一個(gè)東西，不是Scrum了。
所以在實(shí)施Scrum的時(shí)候一定要先明確和學(xué)習(xí)Scrum的規(guī)則和機(jī)制。

2.如何自下而上實(shí)施？

• 取得大家的支持
• 耐心：讓其他人領(lǐng)悟你已經(jīng)理解的東西，找到其他人的動(dòng)機(jī)
• 提供信息

大部分的Scrum都是自下而上實(shí)施的，也就是領(lǐng)導(dǎo)沒(méi)有特別強(qiáng)硬的推行，而是團(tuán)隊(duì)內(nèi)部覺(jué)得這種框架很合適，于是在自己團(tuán)隊(duì)內(nèi)做嘗試。
這個(gè)時(shí)候你就要特別注意，一定要及時(shí)的向外部，特別是領(lǐng)導(dǎo)層匯報(bào)項(xiàng)目的進(jìn)展情況，使得信息透明。

3.資源沖突如何解決？

有的公司項(xiàng)目多，人力不足，特別是資深的經(jīng)驗(yàn)豐富的人比較缺乏。
當(dāng)一個(gè)項(xiàng)目出現(xiàn)問(wèn)題時(shí)，大家都想要協(xié)調(diào)多的資源，特別是那種能夠以一敵三的。
但是資源畢竟是有限的。
搞到最后就像是救火一般，哪里緊急就把資源派到哪里。
這樣不僅打亂了項(xiàng)目團(tuán)隊(duì)的節(jié)奏（團(tuán)隊(duì)不穩(wěn)定），而且也讓這些資源疲于應(yīng)對(duì)。
針對(duì)這樣的情況，Scrum提議使用團(tuán)隊(duì)顧問(wèn)。
也就是讓員工自愿是否愿意作為顧問(wèn)，服務(wù)所有團(tuán)隊(duì)。
這樣的解決方案在實(shí)施時(shí)要特別注意：

• 依賴于管理層的支持
• 長(zhǎng)時(shí)間在小范圍內(nèi)做嘗試
• 選擇核心團(tuán)隊(duì)，并決定需要哪些專家
• 小心團(tuán)隊(duì)顧問(wèn)過(guò)度承諾
• 計(jì)劃可能的空閑時(shí)間
• 顧問(wèn)團(tuán)隊(duì)不應(yīng)該替代專職團(tuán)隊(duì)，應(yīng)該是一個(gè)核心的團(tuán)隊(duì)，輔以顧問(wèn)團(tuán)隊(duì)。

4.如何確定團(tuán)隊(duì)的速率？

確定團(tuán)隊(duì)的速率一般有三種方法：歷史數(shù)據(jù)、走著瞧、猜測(cè)。

• 對(duì)于組建的團(tuán)隊(duì)，熟悉的技術(shù)：優(yōu)先選擇歷史數(shù)據(jù)，其次選擇走著瞧，最后選擇猜測(cè)
• 對(duì)于已組建的團(tuán)隊(duì)，不熟悉的技術(shù)：優(yōu)先選擇走著瞧，其次選擇歷史數(shù)據(jù)，最后選擇猜測(cè)
• 對(duì)于新成立的團(tuán)隊(duì)，熟悉的技術(shù)；以及新成立的團(tuán)隊(duì)，不熟悉的技術(shù)：優(yōu)先選擇猜測(cè)，其次選擇歷史數(shù)據(jù)，最后選擇走著瞧。其中歷史數(shù)據(jù)可以，依賴于其他團(tuán)隊(duì)的歷史數(shù)據(jù)。

5.Scrum的三大角色如何平衡？

Scrum的三大角色，包括關(guān)于Scrum Master，Product Owner以及團(tuán)隊(duì)成員。
很多公司會(huì)讓一人身兼兩職，甚至三職。
相較于讓一個(gè)團(tuán)隊(duì)成員身兼數(shù)職，有一個(gè)專職的Scrum Master要好很多。
這樣可以更好的保持三個(gè)角色所固有的檢查與平衡。

雖然有人不贊成Scrum輪值，認(rèn)為不夠?qū)Ｗ?，但是我嘗試過(guò)。
我個(gè)人覺(jué)得輪值可以提升團(tuán)隊(duì)成員的責(zé)任心。

6.如何確定Spring長(zhǎng)度？

一般建議是1~4周。而長(zhǎng)還是短是與項(xiàng)目、團(tuán)隊(duì)等多種因素決定的，各有利弊。
短周期的Sprint能使你更快地發(fā)現(xiàn)潛在的風(fēng)險(xiǎn)。
但其代價(jià)是團(tuán)隊(duì)得花更多的時(shí)間與客戶互動(dòng)，受到的干擾也更多一些。
可以嘗試一周的sprint強(qiáng)制用戶故事更小，讓團(tuán)隊(duì)有更多機(jī)會(huì)來(lái)反映和糾正問(wèn)題。

長(zhǎng)周期的Spring，意味著需要更長(zhǎng)的時(shí)間才能發(fā)現(xiàn)風(fēng)險(xiǎn)，但好處是互動(dòng)干擾會(huì)少一些。

7.Sprint完成的標(biāo)準(zhǔn)？

制定并發(fā)布一個(gè)DoD。
這里面包括團(tuán)隊(duì)一致同意的內(nèi)容清單。
比如：所有的Story都已經(jīng)接受；對(duì)應(yīng)的幫助文檔已經(jīng)更新……
這樣一份DoD：

• 有助于團(tuán)隊(duì)成員建立密切聯(lián)系
• 為項(xiàng)目干系人提供清楚的交流方式，間接降低了把技術(shù)債務(wù)推遲到項(xiàng)目后期的風(fēng)險(xiǎn)
• 使團(tuán)隊(duì)保持正確的方向，保持專注

8.Scrum Master到底做什么？

Scrum Master主要職責(zé)有：

• 消除障礙，解決問(wèn)題
• 結(jié)束爭(zhēng)論當(dāng)團(tuán)隊(duì)的保姆
• 報(bào)告團(tuán)隊(duì)的行為表現(xiàn)
• 引導(dǎo)并在必要時(shí)提供幫助
• 教育組織并驅(qū)動(dòng)組織變革

也許這也是為什么大部分人都建議Scrum Master要專職的原因吧。
別以為Scrum Master看著很輕松，其實(shí)一點(diǎn)兒也不。
要不你試試看？

9.真正的Scrum應(yīng)該包含的實(shí)踐有哪些？

我覺(jué)得如果下面這幾點(diǎn)缺少了一個(gè)，就不能稱之為Scrum了。

• 測(cè)試驅(qū)動(dòng)開(kāi)發(fā)TDD
  首先寫(xiě)一個(gè)新的單元測(cè)試用例，但不寫(xiě)通過(guò)這個(gè)測(cè)試所需的代碼；
  然后寫(xiě)新的代碼，使之剛好能夠通過(guò)這個(gè)用例；
  最后重構(gòu)：重構(gòu)在不改變，而是在已有意圖和行為的情況下加強(qiáng)或改善其設(shè)計(jì)。外部行為保持不變，內(nèi)部行為更流暢

• 持續(xù)集成：團(tuán)隊(duì)成員頻繁地集成他們的工作，通常每個(gè)人每天至少集成一次，這樣每天就有多次機(jī)場(chǎng)。每次集成都通過(guò)一個(gè)自動(dòng)化構(gòu)建，包括測(cè)試來(lái)盡快檢測(cè)錯(cuò)誤。團(tuán)隊(duì)可在任何時(shí)間構(gòu)建發(fā)布。

• 結(jié)對(duì)編程：一人駕駛一人導(dǎo)航，一起工作，共同完成一個(gè)任務(wù)。

• 自動(dòng)化集成與驗(yàn)收測(cè)試：集成測(cè)試是用來(lái)測(cè)試系統(tǒng)中各種集成點(diǎn)，驗(yàn)收測(cè)試用來(lái)模擬用戶行為的測(cè)試

10.團(tuán)隊(duì)成員工作時(shí)間不一致，如何處理？

現(xiàn)在很多公司為了提倡人性化，對(duì)于員工上班時(shí)間不做強(qiáng)制規(guī)定，也就是所謂的彈性制。
只要你每天工作滿8個(gè)小時(shí)即可。
而這樣對(duì)于Scrum卻是個(gè)挑戰(zhàn)。
如果團(tuán)隊(duì)沒(méi)有辦法保證一定的時(shí)間在一起辦公，如何進(jìn)行結(jié)對(duì)編程？如何開(kāi)站會(huì)？如何進(jìn)行有效溝通？
所以我們需要確保團(tuán)隊(duì)核心時(shí)間。
核心時(shí)間就是大家對(duì)各自喜歡的工作時(shí)間和工作習(xí)慣所取得的共識(shí)。
比如有的人喜歡一大早7點(diǎn)到公司，下午4點(diǎn)左右就下班回家。而有的人喜歡快到中午11點(diǎn)才來(lái)上班，然后工作到晚上7、8點(diǎn)回家。這個(gè)時(shí)候的核心時(shí)間就是除去午休時(shí)間的共同時(shí)間。
在每個(gè)項(xiàng)目開(kāi)始的時(shí)候，以及整個(gè)項(xiàng)目過(guò)程中需要的時(shí)候確定核心時(shí)間。
鼓勵(lì)團(tuán)隊(duì)保持一定的靈活性。

11.什么是發(fā)布計(jì)劃？

一般來(lái)說(shuō)Scrum都是有節(jié)奏的進(jìn)行發(fā)布。
那么為什么還需要發(fā)布計(jì)劃？
因?yàn)镾crum是為了“敏捷”的應(yīng)對(duì)，所以每次Demo或者Plan Meeting需求可能會(huì)有增加、修改、取消，那么你的發(fā)布計(jì)劃也需要隨之更新。
發(fā)布計(jì)劃的目的是：為特定功能和整個(gè)項(xiàng)目何時(shí)能夠完成提供答案。

• 溝通和交流，并且要頻繁
• 每個(gè)Sprint后都更新發(fā)布計(jì)劃
• 努力做優(yōu)先級(jí)最高的條目
• 更新對(duì)大條目的估計(jì)
• 每個(gè)Sprint都交付可工作的軟件

12.何時(shí)進(jìn)行故事分解？

我有時(shí)候會(huì)被問(wèn)及，這個(gè)故事足夠小了吧，是否還需要拆得更?。恳鸬蕉嘈〔藕线m？
要知道任何事情都有一個(gè)度，不能過(guò)度拆分，這樣會(huì)造成不必要的浪費(fèi)。
搞清楚一個(gè)故事或任務(wù)太大還是太小，可以下面的問(wèn)題幫助確定分解的級(jí)別：

• 團(tuán)隊(duì)能夠用故事點(diǎn)來(lái)評(píng)估產(chǎn)品列表嗎？
• 產(chǎn)品列表中的故事是否清楚定義了？
• 故事是否精確？
• 我是否對(duì)這個(gè)故事有足夠的了解？

13.Scrum的缺陷管理方式是怎樣的？

首先和其他框架一樣，我們需要為缺陷區(qū)別等級(jí)：

• P0災(zāi)難：主功能無(wú)法使用且沒(méi)有可行的變通方案
• P1高：主功能不可用，但有變通方案
• P2中：系統(tǒng)的使用性受損
• P3低：影響較小，無(wú)關(guān)緊要或不便利，可以等到下次產(chǎn)品發(fā)布時(shí)解決

如果是P0或者P1級(jí)別，那發(fā)現(xiàn)者及其搭檔有一個(gè)小時(shí)來(lái)完成以下任務(wù)：

• 停止手上當(dāng)前任務(wù)
• 確定該缺陷的根本原因
• 修復(fù)
• 更新所有測(cè)試
• 生成或重新構(gòu)建驗(yàn)證測(cè)試
• 保證所有測(cè)試都能通過(guò)
• 提交代碼
• 向前逼近一步，至少到集成環(huán)境中驗(yàn)驗(yàn)證

如果能一個(gè)小時(shí)完成則無(wú)需記錄，如果不能完成：

• 在一個(gè)小時(shí)結(jié)束時(shí)停止
• 在缺陷管理系統(tǒng)中記錄
• 繼續(xù)修復(fù)
• 完成并關(guān)閉缺陷
• 更新Sprint列表及小時(shí)數(shù)

14.如何處理遺留系統(tǒng)的維護(hù)工作？

很多時(shí)候，我們?cè)谶M(jìn)行新功能開(kāi)發(fā)的同時(shí)，還需要兼顧遺留系統(tǒng)的維護(hù)工作。
這一部分如果不妥善安排，不僅會(huì)打亂團(tuán)隊(duì)的Sprint節(jié)奏，還會(huì)影響整體計(jì)劃。
有兩種方案可以解決這個(gè)問(wèn)題：

• 專用時(shí)間
  從現(xiàn)在進(jìn)行的Sprint中劃出專用時(shí)間來(lái)處理遺留或現(xiàn)有系統(tǒng)維護(hù)。
  比如每個(gè)Sprint20個(gè)小時(shí)。

• 專職團(tuán)隊(duì)
  劃分出專職人員進(jìn)行維護(hù)工作，而且這個(gè)團(tuán)隊(duì)的Sprint要相對(duì)的使用更短的周期。

15.為何要組織demo會(huì)？

在每個(gè)Sprint的最后一天，Scrum Master需要組織Demo會(huì)議。
其目的是：讓團(tuán)隊(duì)給客戶和項(xiàng)目干系人演示他們?cè)谶@個(gè)Sprint中完成的任務(wù)。
在這個(gè)過(guò)程中，最重要的不是演示是否順利，而是客戶和干系人的意見(jiàn)反饋，這樣才能敏捷的調(diào)整。

16.為何要組織回顧會(huì)？

我不止一次的聽(tīng)人抱怨，回顧會(huì)就是浪費(fèi)時(shí)間的檢討大會(huì)。
但是我們需要正視回顧會(huì)的重要性。
回顧會(huì)是團(tuán)隊(duì)檢視調(diào)整周期中的關(guān)鍵部分。
團(tuán)隊(duì)趁此機(jī)會(huì)學(xué)習(xí)如何提高，如何更有效工作，如何以更高的速率與優(yōu)良的品質(zhì)交付價(jià)值。
這個(gè)環(huán)節(jié)必不可少，如果你的Sprint是一周，那么可以抽15~30分鐘回顧一下，但是不可自行取消。
并且在結(jié)束會(huì)議前可以嘗試用1-5分來(lái)評(píng)估“你覺(jué)得這個(gè)Sprint如何？”

17.為何要組織每日站會(huì)？

同樣的一個(gè)問(wèn)題，很多人說(shuō)每日站會(huì)太浪費(fèi)時(shí)間，而且站著開(kāi)很累。
每日站會(huì)的目的就是要同步團(tuán)隊(duì)狀態(tài)，并暴露任何可能影響工作的障礙。
站著不要坐著，這樣能使團(tuán)隊(duì)更專心，更專注，更有效率。
畢竟可以有效的縮短會(huì)議時(shí)間，時(shí)間一長(zhǎng)大家都站不住了。

18.每日站會(huì)上的第四個(gè)問(wèn)題是什么？

我們都知道每日站會(huì)上需要問(wèn)三個(gè)問(wèn)題：
我昨天做了什么？
我今天要做什么？
我有什么障礙？

其實(shí)還有第四個(gè)問(wèn)題是：
對(duì)于團(tuán)隊(duì)完成Sprint目標(biāo)，如果以1~10來(lái)度量，你的信心有多少？

第四個(gè)問(wèn)題可以避免團(tuán)隊(duì)成員在不愿意面對(duì)沖突的情況下表達(dá)自己的意見(jiàn)。

19.結(jié)對(duì)編程有哪些玩法？

結(jié)對(duì)編程能夠在相對(duì)較短的時(shí)間內(nèi)產(chǎn)生高質(zhì)量的軟件。
一般的情況是一個(gè)人“駕駛”，一個(gè)人“導(dǎo)航”。
這樣其實(shí)可以做及時(shí)的Code Review。
但是一般來(lái)說(shuō)“駕駛”的人會(huì)更專注，“導(dǎo)航”不自覺(jué)得就會(huì)走神了。
所以我們可以嘗試以下兩種玩法：

• 無(wú)序結(jié)對(duì)編程

大家交換結(jié)對(duì)

圖片發(fā)自簡(jiǎn)書(shū)App

• 微結(jié)對(duì)

  
  
  圖片發(fā)自簡(jiǎn)書(shū)App
  
  
  圖片發(fā)自簡(jiǎn)書(shū)App

20.如何讓新人快速融入團(tuán)隊(duì)？

第一步，選對(duì)人。
這點(diǎn)非常重要。
這也是為什么一般來(lái)說(shuō)我面試的時(shí)候會(huì)問(wèn)：你平時(shí)有什么業(yè)余活動(dòng)？
如果團(tuán)隊(duì)本身的成員都比較open，而比較悶的人可能會(huì)比較難融入。
更復(fù)雜的情況是，對(duì)Scrum的排斥，會(huì)讓新人更難融入。

第二步，幫助新成員學(xué)習(xí)而制定測(cè)試。
比如定期讓新成員回答以下問(wèn)題：

• 描述系統(tǒng)架構(gòu)
• 為何結(jié)對(duì)和TDD很重要？
• 誰(shuí)擁有代碼所有權(quán)？

21.如何應(yīng)對(duì)與團(tuán)隊(duì)格格不入的新成員？

有的時(shí)候我們把一個(gè)人招進(jìn)來(lái)后卻發(fā)現(xiàn)這個(gè)人與團(tuán)隊(duì)格格不入，并不是說(shuō)這個(gè)人的能力有什么問(wèn)題，而是他會(huì)給團(tuán)隊(duì)帶來(lái)負(fù)面的影響。
比如無(wú)法接受敏捷，并且試圖讓大家放棄敏捷。

有一個(gè)概念叫做社會(huì)異常，就是違背以確立文化規(guī)范的行為做事方式。
敏捷和瀑布沒(méi)有誰(shuí)對(duì)誰(shuí)錯(cuò)的問(wèn)題，只有合適和不合適的問(wèn)題。
而當(dāng)一個(gè)團(tuán)隊(duì)都覺(jué)得自己按照一定的節(jié)奏前進(jìn)時(shí)，卻出現(xiàn)一個(gè)不合群的聲音，甚至影響到前進(jìn)的速度和大家的心情，那么就屬于社會(huì)異常。
對(duì)這個(gè)概念如果感興趣的話可以去搜一下。

那怎么辦呢？
首先，避免增加與團(tuán)隊(duì)不協(xié)調(diào)的新成員。有一些預(yù)判可以幫助你。
如果已經(jīng)加入團(tuán)隊(duì)，那么嘗試和行政主管、HR反饋這個(gè)問(wèn)題。
如果實(shí)在不行，就只能?chē)L試和他溝通，讓他主動(dòng)退出團(tuán)隊(duì)或者做一些邊緣性的工作了。

22.Sprint可以取消嗎？

當(dāng)有異味影響到團(tuán)隊(duì)實(shí)現(xiàn)Sprint目標(biāo)能力時(shí)，可以：
消除障礙
獲得幫助
縮小范圍
取消Sprint

一般我們不會(huì)建議你取消Sprint的，而是盡力去消除障礙或者獲得幫助。
如果一切都行不通，才會(huì)取消Sprint。
可能的情況是，需求突然變化，有個(gè)異常緊急的需求需要處理。
而我們知道Sprint是不能被打斷，臨時(shí)添加任務(wù)的。
所以可以采取取消的方式。
但是一定要注意的是，取消的同時(shí)要將代碼回滾到上一Sprint。

23.Scrum如何看待加班？

Scrum一致強(qiáng)調(diào)“可持續(xù)”。
而我們知道，一旦加班搶時(shí)間，團(tuán)隊(duì)在超負(fù)荷狀態(tài)下工作時(shí)間越長(zhǎng)，就需要更多時(shí)間來(lái)恢復(fù)。
這種“殉道”行為完全無(wú)法實(shí)現(xiàn)“可持續(xù)”。
所以，如果正在經(jīng)歷精疲力盡，首要任務(wù)是縮短周期時(shí)間。
這樣可以提升每次Sprint的專注力。
另外，大家都必須承認(rèn)，團(tuán)隊(duì)的完成量是有極限的。

24.如何保證每次交付可工作的軟件？

記得多年前，小婧所在的團(tuán)隊(duì)做一個(gè)模塊，計(jì)劃半年后交付。
這個(gè)模塊比較大，于是我們將所有的需求拆分成Story進(jìn)行開(kāi)發(fā)。
前幾個(gè)Sprint，我們的主要精力集中在了“業(yè)務(wù)配置”功能的開(kāi)發(fā)上。
因?yàn)槲覀儺?dāng)時(shí)的想法是，不進(jìn)行業(yè)務(wù)配置，后面的功能是無(wú)法實(shí)現(xiàn)的。
后來(lái)我們發(fā)現(xiàn)，業(yè)務(wù)配置的部分開(kāi)發(fā)完成都已經(jīng)過(guò)去了三分之一的時(shí)間了，而我們的核心功能、業(yè)務(wù)場(chǎng)景尚未開(kāi)始。

后來(lái)和公司的敏捷教練交流這件事情的時(shí)候。
她告訴我，應(yīng)該先進(jìn)行的不是業(yè)務(wù)配置，而是主業(yè)務(wù)場(chǎng)景和流程涉及的Story。
因?yàn)镾crum強(qiáng)調(diào)每個(gè)版本都可工作，可交付。
但是業(yè)務(wù)配置功能的發(fā)布并不可交付，用戶拿著脫離了模塊主業(yè)務(wù)場(chǎng)景的業(yè)務(wù)配置功能，其實(shí)價(jià)值為0。

那應(yīng)該怎么處理呢？
這里有個(gè)概念，叫做“核心故事”：最基本的需求。
我們應(yīng)該鑒別出一個(gè)核心故事，固定其他變量，讓這個(gè)核心故事貫穿于整個(gè)系統(tǒng)。

也就是說(shuō)，之前我們應(yīng)該一上來(lái)就規(guī)劃開(kāi)發(fā)核心故事，而不支持可配置的功能。
然后逐步的在隨后的Sprint中不斷的錦上添花。

還有一種方式，可能會(huì)適合于互聯(lián)網(wǎng)軟件，就是控制用戶數(shù)。
限制使用者或訪問(wèn)系統(tǒng)用戶數(shù)。

無(wú)論如何都應(yīng)該從風(fēng)險(xiǎn)最大的功能開(kāi)始，避免后續(xù)發(fā)生風(fēng)險(xiǎn)后失控。

25.如何優(yōu)化Scrum的效率？

我們都知道在時(shí)間管理的話題中有一項(xiàng)非常重要的工作是：時(shí)間記錄。
也就是你要想省錢(qián)，那就必須先知道你錢(qián)都花哪里去了。

對(duì)于Scrum提升效率也是如此，你需要知道自己每類工作的花費(fèi)，才能更好的提升效率。
有這樣幾類工作，大家可以嘗試來(lái)進(jìn)行觀察和記錄。

• 功能工作：向用戶交付商業(yè)價(jià)值的功能
• 額外工作：企業(yè)服務(wù)或強(qiáng)制要求，比如審核或會(huì)議
• Spike穿刺：研究類工作
• 必要性工作：要達(dá)到完成標(biāo)準(zhǔn)需要做的工作

26.利用Scrum如何進(jìn)行項(xiàng)目成本估算？

一般來(lái)說(shuō)我們估算一個(gè)項(xiàng)目的成本有幾種方式：人天、功能數(shù)。
而Scrum會(huì)提供給你一個(gè)更準(zhǔn)確的評(píng)估方式。

• 生成用戶故事：列出帶評(píng)估項(xiàng)目的所有用戶故事。
• 確定用戶故事的優(yōu)先級(jí)：按照優(yōu)先級(jí)由高到低，逐一排列。
• 估算用戶故事的大?。褐饕菫榱耸谴_定速率。計(jì)算所有用戶故事的總點(diǎn)數(shù)。以以往的速率計(jì)算需要多少人在規(guī)定時(shí)間內(nèi)能完成。
• 確定團(tuán)隊(duì)的成本：上一步得到的人數(shù)，乘以團(tuán)隊(duì)平均工資等成本。
• 計(jì)算項(xiàng)目的成本
• 承諾是否能做

27.Scrum后就不用寫(xiě)文檔了嗎？

有好多人說(shuō)，我們是Scrum，我們不需要寫(xiě)文檔，只有你們瀑布才會(huì)要寫(xiě)那么多文檔。
對(duì)不起，我沒(méi)聽(tīng)清。
誰(shuí)告訴你Scrum可以不寫(xiě)文檔的？
Scrum只是說(shuō)，不寫(xiě)沒(méi)用的文檔。

也就是說(shuō)，首先我們需要決定，項(xiàng)目需要什么什么文檔以及什么時(shí)候做文檔最有意義。
然后，按計(jì)劃交付承諾的文檔及及時(shí)匯報(bào)項(xiàng)目狀態(tài)和白板照片。
并且，最好是投入自動(dòng)化，部分文檔可以通過(guò)自動(dòng)化工具來(lái)生成。
比如我們以前寫(xiě)Online Help文檔，后來(lái)就自動(dòng)化轉(zhuǎn)成操作手冊(cè)進(jìn)行交付。

28.外包與離岸開(kāi)發(fā)要注意什么？

不管相距多遠(yuǎn)都要營(yíng)造出一種氛圍，讓大家覺(jué)得是在同一個(gè)地方，工作的同一個(gè)團(tuán)隊(duì)。
以下幾點(diǎn)要特別注意：

• 選擇合適的離岸團(tuán)隊(duì)：雇傭敏捷團(tuán)隊(duì)，并且時(shí)差小于三個(gè)小時(shí)
• 以痛苦最小的方式分配工作：
  讓團(tuán)隊(duì)按工作包交付
  讓多個(gè)團(tuán)隊(duì)在同一代碼機(jī)上工作
  把特定的開(kāi)發(fā)功能外包，如，測(cè)試、UI
• 堅(jiān)持Scrum框架
• 建立團(tuán)隊(duì)文化
• 持續(xù)集成
• 準(zhǔn)備差旅
• 配合一個(gè)項(xiàng)目或團(tuán)隊(duì)協(xié)調(diào)人

以下情況建議絕不考慮離岸：

• 高度復(fù)雜技術(shù)高風(fēng)險(xiǎn)的第一個(gè)發(fā)布
• 本地團(tuán)隊(duì)還在掙扎于開(kāi)發(fā)實(shí)踐如TDD等，或缺乏紀(jì)律
• 公司沒(méi)有成功必備的差旅預(yù)算和遠(yuǎn)程溝通技術(shù)的預(yù)算

29.大型列表如何進(jìn)行優(yōu)先級(jí)評(píng)定和估算？

像一般開(kāi)發(fā)周期在3個(gè)月以上，涉及三類以上干系人的項(xiàng)目，其Story的數(shù)量和復(fù)雜度是非?？捎^的。
我們不可能逐一評(píng)判優(yōu)先級(jí)，這個(gè)工作量太大了，需要協(xié)調(diào)的干洗人也會(huì)非常多。
這里有一個(gè)辦法，可以快速的（一天內(nèi)）完成Story列表的優(yōu)先級(jí)評(píng)定和估算。
首先，你需要將所有的Story都準(zhǔn)備好。
然后，讓團(tuán)隊(duì)先大致將所有的Story按照大小排序：小的、中等的、大的、超大的。
這種排序是模糊的，不精確的。
接著組織所有干系人對(duì)同一區(qū)域內(nèi)的Story進(jìn)行優(yōu)先級(jí)高低調(diào)整。
最后，Scrum Master一定要記錄干系人討論的內(nèi)容及有爭(zhēng)議的地方，以便后續(xù)進(jìn)行進(jìn)一步的跟蹤。

30.你見(jiàn)過(guò)這樣的合同嗎？

一般來(lái)說(shuō)，軟件合同分成：固定總價(jià)合同和人天合同。
固定總價(jià)合同很好理解，就一筆錢(qián)，做多做少都這么多錢(qián)。
一般對(duì)需求比較明確的項(xiàng)目建議使用固定總價(jià)合同。
人天合同更多見(jiàn)于軟件咨詢類的合同。
顧問(wèn)來(lái)多少天就給多少錢(qián)。
當(dāng)然還有一些合同的變形，我這里就不展開(kāi)講了。

而Scrum給了我們另外一種合同的可能。
主要是兩部分組成：調(diào)研合同和項(xiàng)目合同。
首先，簽訂的是調(diào)研合同。
由團(tuán)隊(duì)業(yè)務(wù)人員進(jìn)行業(yè)務(wù)調(diào)研，并進(jìn)行分析后給出Story清單和評(píng)估。
如果甲方覺(jué)得滿意可以繼續(xù)簽項(xiàng)目合同，如果覺(jué)得不滿意可以找別人來(lái)進(jìn)行開(kāi)發(fā)。
這個(gè)合同基本上會(huì)以“人天”合同為主。

接下來(lái)如果簽“項(xiàng)目合同”，則是分Sprint簽訂、給錢(qián)。
如果甲方對(duì)這個(gè)Sprint的交付不滿意，可以拒付。
也可以在幾個(gè)Sprint后隨時(shí)喊停。只需要提前通知即可。

但是我覺(jué)得要做到這點(diǎn)，真的是需要使用Scrum框架的每個(gè)實(shí)踐，保證每次交付都是可用的軟件。

小婧是一名行走在產(chǎn)品路上的資深業(yè)務(wù)分析師（BA），如果想與我同行，就請(qǐng)關(guān)注我吧！