21.如何應(yīng)對(duì)與團(tuán)隊(duì)格格不入的新成員？
有的時(shí)候我們把一個(gè)人招進(jìn)來后卻發(fā)現(xiàn)這個(gè)人與團(tuán)隊(duì)格格不入，并不是說這個(gè)人的能力有什么問題，而是他會(huì)給團(tuán)隊(duì)帶來負(fù)面的影響。
比如無法接受敏捷，并且試圖讓大家放棄敏捷。
有一個(gè)概念叫做社會(huì)異常，就是違背以確立文化規(guī)范的行為做事方式。
敏捷和瀑布沒有誰對(duì)誰錯(cuò)的問題，只有合適和不合適的問題。
而當(dāng)一個(gè)團(tuán)隊(duì)都覺得自己按照一定的節(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è)問題。
如果實(shí)在不行，就只能嘗試和他溝通，讓他主動(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í)間來恢復(fù)。
這種“殉道”行為完全無法實(shí)現(xiàn)“可持續(xù)”。
所以，如果正在經(jīng)歷精疲力盡，首要任務(wù)是縮短周期時(shí)間。
這樣可以提升每次Sprint的專注力。
另外，大家都必須承認(rèn)，團(tuán)隊(duì)的完成量是有極限的。
24.如何保證每次交付可工作的軟件？
記得多年前，小婧所在的團(tuán)隊(duì)做一個(gè)模塊，計(jì)劃半年后交付。
這個(gè)模塊比較大，于是我們將所有的需求拆分成Story進(jìn)行開發(fā)。
前幾個(gè)Sprint，我們的主要精力集中在了“業(yè)務(wù)配置”功能的開發(fā)上。
因?yàn)槲覀儺?dāng)時(shí)的想法是，不進(jìn)行業(yè)務(wù)配置，后面的功能是無法實(shí)現(xiàn)的。
后來我們發(fā)現(xiàn)，業(yè)務(wù)配置的部分開發(fā)完成都已經(jīng)過去了三分之一的時(shí)間了，而我們的核心功能、業(yè)務(wù)場(chǎng)景尚未開始。
后來和公司的敏捷教練交流這件事情的時(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)。
也就是說，之前我們應(yīng)該一上來就規(guī)劃開發(fā)核心故事，而不支持可配置的功能。
然后逐步的在隨后的Sprint中不斷的錦上添花。
還有一種方式，可能會(huì)適合于互聯(lián)網(wǎng)軟件，就是控制用戶數(shù)。
限制使用者或訪問系統(tǒng)用戶數(shù)。
無論如何都應(yīng)該從風(fēng)險(xiǎn)最大的功能開始，避免后續(xù)發(fā)生風(fēng)險(xiǎn)后失控。
25.如何優(yōu)化Scrum的效率？
我們都知道在時(shí)間管理的話題中有一項(xiàng)非常重要的工作是：時(shí)間記錄。
也就是你要想省錢，那就必須先知道你錢都花哪里去了。
對(duì)于Scrum提升效率也是如此，你需要知道自己每類工作的花費(fèi)，才能更好的提升效率。
有這樣幾類工作，大家可以嘗試來進(jìn)行觀察和記錄。
- 功能工作：向用戶交付商業(yè)價(jià)值的功能
- 額外工作：企業(yè)服務(wù)或強(qiáng)制要求，比如審核或會(huì)議
- Spike穿刺：研究類工作
- 必要性工作：要達(dá)到完成標(biāo)準(zhǔn)需要做的工作
26.利用Scrum如何進(jìn)行項(xiàng)目成本估算？
一般來說我們估算一個(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后就不用寫文檔了嗎？
有好多人說，我們是Scrum，我們不需要寫文檔，只有你們瀑布才會(huì)要寫那么多文檔。
對(duì)不起，我沒聽清。
誰告訴你Scrum可以不寫文檔的？
Scrum只是說，不寫沒用的文檔。
也就是說，首先我們需要決定，項(xiàng)目需要什么什么文檔以及什么時(shí)候做文檔最有意義。
然后，按計(jì)劃交付承諾的文檔及及時(shí)匯報(bào)項(xiàng)目狀態(tài)和白板照片。
并且，最好是投入自動(dòng)化，部分文檔可以通過自動(dòng)化工具來生成。
比如我們以前寫Online Help文檔，后來就自動(dòng)化轉(zhuǎn)成操作手冊(cè)進(jìn)行交付。
28.外包與離岸開發(fā)要注意什么？
不管相距多遠(yuǎn)都要營(yíng)造出一種氛圍，讓大家覺得是在同一個(gè)地方，工作的同一個(gè)團(tuán)隊(duì)。
以下幾點(diǎn)要特別注意：
- 選擇合適的離岸團(tuán)隊(duì)：雇傭敏捷團(tuán)隊(duì)，并且時(shí)差小于三個(gè)小時(shí)
- 以痛苦最小的方式分配工作：
讓團(tuán)隊(duì)按工作包交付
讓多個(gè)團(tuán)隊(duì)在同一代碼機(jī)上工作
把特定的開發(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ì)還在掙扎于開發(fā)實(shí)踐如TDD等，或缺乏紀(jì)律
- 公司沒有成功必備的差旅預(yù)算和遠(yuǎn)程溝通技術(shù)的預(yù)算
29.大型列表如何進(jìn)行優(yōu)先級(jí)評(píng)定和估算？
像一般開發(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à)合同和人天合同。
固定總價(jià)合同很好理解，就一筆錢，做多做少都這么多錢。
一般對(duì)需求比較明確的項(xiàng)目建議使用固定總價(jià)合同。
人天合同更多見于軟件咨詢類的合同。
顧問來多少天就給多少錢。
當(dāng)然還有一些合同的變形，我這里就不展開講了。
而Scrum給了我們另外一種合同的可能。
主要是兩部分組成：調(diào)研合同和項(xiàng)目合同。
首先，簽訂的是調(diào)研合同。
由團(tuán)隊(duì)業(yè)務(wù)人員進(jìn)行業(yè)務(wù)調(diào)研，并進(jìn)行分析后給出Story清單和評(píng)估。
如果甲方覺得滿意可以繼續(xù)簽項(xiàng)目合同，如果覺得不滿意可以找別人來進(jìn)行開發(fā)。
這個(gè)合同基本上會(huì)以“人天”合同為主。
接下來如果簽“項(xiàng)目合同”，則是分Sprint簽訂、給錢。
如果甲方對(duì)這個(gè)Sprint的交付不滿意，可以拒付。
也可以在幾個(gè)Sprint后隨時(shí)喊停。只需要提前通知即可。
但是我覺得要做到這點(diǎn)，真的是需要使用Scrum框架的每個(gè)實(shí)踐，保證每次交付都是可用的軟件。
小婧是一名行走在產(chǎn)品路上的資深業(yè)務(wù)分析師（BA），如果想與我同行，就請(qǐng)關(guān)注我吧！
