[[186936]]

再論需求

在前面幾篇文章出去后，遇到不少同學(xué)問，到底我的團(tuán)隊(duì)是否合適走Scrum模式開發(fā)呢?其實(shí)我個(gè)人的建議首先是看需求管理的主導(dǎo)權(quán)是否在團(tuán)隊(duì)手里，也就是產(chǎn)品經(jīng)理是否是緊密和團(tuán)隊(duì)在一起，并且有能力拒絕不合時(shí)宜的需求，特別是來自領(lǐng)導(dǎo)、市場的壓力而來的倒排的需求。但是我們更多遇到的情況是，產(chǎn)品總是游離在團(tuán)隊(duì)之外，總是以項(xiàng)目/市場的目的要挾開發(fā)一定要在什么時(shí)間點(diǎn)做到什么。同時(shí)更多的業(yè)務(wù)型公司的產(chǎn)品對于技術(shù)的理解總是不到位，或者說沒有任何技術(shù)功底，從畢業(yè)開始就在做產(chǎn)品的事，所以無法融合到開發(fā)團(tuán)隊(duì)中。如果是這種情況，是否走Scrum需要商榷。

需求的來源

通常來講，需求來源于產(chǎn)品經(jīng)理，但是不要過于局限。從掌控角度看，產(chǎn)品只需要掌握大的產(chǎn)品特性方向以及一個(gè)迭代的關(guān)鍵需求要點(diǎn)就可，其它的需求細(xì)節(jié)應(yīng)該交由團(tuán)隊(duì)成員去發(fā)揮，讓所有人真正有對產(chǎn)品的歸屬感。特別是對于開發(fā)而言，他們有某些“需求”是心理性的，或者是“癖好”的如代碼的重構(gòu)或者某些細(xì)節(jié)的雕琢，這些不要一味的否定，而是做適當(dāng)?shù)目刂婆畔聝?yōu)先級就可。很多時(shí)候一個(gè)產(chǎn)品的優(yōu)勢往往來源于整個(gè)團(tuán)隊(duì)的“腦洞大開”，當(dāng)然也不是隨意引入這些需求，適當(dāng)很重要。不能沒有，又不能過度。好像說的有點(diǎn)啰嗦。 ：)

工作量的評估

在Planning game中，重要的一個(gè)環(huán)節(jié)就是對每一個(gè)工作項(xiàng)做工作量的評估，理論的做法是使用Planning game紙牌，用斐波那契數(shù)列數(shù)值(1 1 2 3 5 8 13 …)來給每個(gè)工作項(xiàng)做出個(gè)人的獨(dú)立估算，然后一起亮牌，如果差異比較大，則由大數(shù)值和小數(shù)值的人來說明各自的理由，然后再出牌估算。如此多輪***得出每個(gè)工作項(xiàng)的工作量。一般理論的建議是不要將一個(gè)做工作項(xiàng)估算超過2天，如果超過則需要繼續(xù)分解。實(shí)踐中，這個(gè)卻是不難么容易操作。原因主要有幾個(gè)方面：

• 因?yàn)閷τ谛庐a(chǎn)品的理解或新技術(shù)等經(jīng)驗(yàn)不足，對于工作項(xiàng)的分拆比較難，造成工作量估算比較大，***難以操作
• 團(tuán)隊(duì)成員的工作經(jīng)驗(yàn)不足特別是團(tuán)隊(duì)成員本身水平不一致的團(tuán)隊(duì)，估計(jì)離實(shí)際偏離很大，***做planning game 費(fèi)時(shí)費(fèi)力，執(zhí)行困難。

我們也實(shí)踐過程也遇到了這些問題，***大家對于planning game的估算環(huán)節(jié)總是意見頗多，為了后續(xù)真的確保能完成，總是人為的往估算中注入水分，從而每個(gè)任務(wù)都是需要很多時(shí)間哪怕再小的任務(wù)。綜合后一個(gè)迭代能做的事情有限。多次惡性循環(huán)后，有些管理者自然就認(rèn)為Scrum模式是開發(fā)團(tuán)隊(duì)的擋箭牌，從而取消了Scrum的開發(fā)模式回歸傳統(tǒng)填鴨式的倒排項(xiàng)目管理了。

對此，我們團(tuán)隊(duì)做了一些調(diào)整：

• 首先從工作項(xiàng)的分解交給開發(fā)的Team Leader負(fù)責(zé)，他的經(jīng)驗(yàn)比較足偏離性小，并在planning game時(shí)和大家說明拆解的理由，如果還是不夠細(xì)則可以繼續(xù)拆解。
• 不再真對某一項(xiàng)任務(wù)進(jìn)行評估，而是對所有任務(wù)做整體評估，只要整體團(tuán)隊(duì)認(rèn)為可以實(shí)現(xiàn)這個(gè)需求范圍就可。同時(shí)產(chǎn)品需要掌控每個(gè)任務(wù)的優(yōu)先級，便于后期砍需求。
• 還有就是對于技術(shù)難點(diǎn)，提前要求開發(fā)的Team Leader或者架構(gòu)師做好PoC (Proof of Concept)，提前踩踩坑。
• 對于實(shí)現(xiàn)上的重點(diǎn)問題做些設(shè)計(jì)，并對團(tuán)隊(duì)成員宣講，讓開發(fā)和測試都理解。這個(gè)不用局限是開發(fā)的Team Leader或者架構(gòu)師，只要做好review就可。具體如何做設(shè)計(jì)我下面講。

敏捷中如何做設(shè)計(jì)

這是個(gè)很容易遇到的問題，有些團(tuán)隊(duì)做敏捷(無論是否是Scrum)的一個(gè)目的就是為了避免去寫繁重的設(shè)計(jì)文檔。而有些傳統(tǒng)開發(fā)的團(tuán)隊(duì)，則仍然在做概要設(shè)計(jì)，然后詳細(xì)設(shè)計(jì)，有時(shí)有又有UI設(shè)計(jì)等等。我們的做法呢?Case by case!!!

首先我在前面blog講過，在Backlog的review的時(shí)候，需要多方一起確定是否需要做需求/系統(tǒng)分析(涵蓋什么內(nèi)容，我后面講)以及架構(gòu)設(shè)計(jì)和實(shí)現(xiàn)設(shè)計(jì)(或許和概要設(shè)計(jì)/詳細(xì)設(shè)計(jì)只是換一個(gè)名字)

需求分析 / 系統(tǒng)設(shè)計(jì)

這個(gè)主要是針對新feature的情況，目的是分析用戶故事場景，分析系統(tǒng)對外接口的變化等，主要包含一下內(nèi)容但是不局限：

• 原始需求列表，盡可能保留原始的需求描述，以便于讀者更好的去理解。但是如果是技術(shù)人給的需求，這個(gè)就要小心了，通常他們都是根據(jù)自己的理解加工過的需求，從而掩蓋了需求的本質(zhì)，而是直接給了你方案性的需求。這些在技術(shù)人建的溝通一定要小心這個(gè)。
• 需求分析整理。這個(gè)是針對原始的需求做出的整理、歸類、抽像等。
• 用戶故事User Story的描述，或者是use case的描述，取決設(shè)計(jì)者的偏好。這里面需要定位出Actors，并畫出不同場景的序列圖
• 領(lǐng)域模型分析， 根據(jù)新feature的變化，對領(lǐng)域模型進(jìn)行修正和描述。如何畫好一個(gè)清洗的領(lǐng)域模型，這個(gè)是個(gè)大課題，容以后再表
• 系統(tǒng)的Layer 2的接口分析。Layer 2的意思是系統(tǒng)間的接口，這個(gè)是我的老東家Rick同學(xué)教的，一直用到現(xiàn)在。
• 系統(tǒng)的Layer 3的模塊分析。Layer 3通常指這個(gè)系統(tǒng)內(nèi)的模塊組成關(guān)系。這個(gè)可以由技術(shù)產(chǎn)品給，也可以交給架構(gòu)師做，取決于團(tuán)隊(duì)的情況

架構(gòu)設(shè)計(jì)/實(shí)現(xiàn)設(shè)計(jì)

這個(gè)通常由架構(gòu)師負(fù)責(zé)，描述整體系統(tǒng)的架構(gòu)。這塊我就不細(xì)講了。交由江南白衣去講吧，他整理一個(gè)架構(gòu)設(shè)計(jì)的要點(diǎn)指南，就看他什么時(shí)候出這篇文章了。后面有他的微信公眾號。

實(shí)現(xiàn)設(shè)計(jì)

這個(gè)針對實(shí)現(xiàn)過程的每個(gè)要點(diǎn)的詳細(xì)描述，一般我們是在實(shí)現(xiàn)中發(fā)現(xiàn)開發(fā)中有疑惑的地方，或者實(shí)現(xiàn)起來比較別扭的時(shí)候，就交由開發(fā)Leader來出這個(gè)設(shè)計(jì)，并落到WIKI上。這個(gè)可能涵蓋的內(nèi)容有：

• 具體算法
• 具體的參數(shù)配置
• 實(shí)現(xiàn)的類、接口等關(guān)系

總結(jié)

不要為了設(shè)計(jì)而設(shè)計(jì)，也不要一切都不設(shè)計(jì)。這個(gè)需要產(chǎn)品和開發(fā)leader一起把握。切實(shí)根據(jù)需要來做設(shè)計(jì)。

【本文是51CTO專欄作者“VIPDOCKER-了哥 ”的原創(chuàng)文章，如需轉(zhuǎn)載請通過51CTO與作者聯(lián)系】

戳這里，看該作者更多好文