轉(zhuǎn)載自
作者：塵中之光（簡書作者）
原文鏈接：http://www.reibang.com/p/0127f8f7b3e2
對于敏捷開發(fā)废麻，講它的價值灶似、方法的內(nèi)容已經(jīng)夠多列林。而對于需求、設(shè)計酪惭、測試這三個環(huán)節(jié)希痴，如何適配并融入敏捷開發(fā)的流程，卻著墨寥寥春感。本文主要從產(chǎn)品設(shè)計及需求表達兩個方面砌创，介紹如何在敏捷開發(fā)的背景下虏缸，保證產(chǎn)品設(shè)計不挖坑，并為開發(fā)人員提供的高效支撐嫩实。文中所述適用于中小規(guī)模的團隊寇钉，產(chǎn)品形態(tài)以web端非成熟期產(chǎn)品為最匹配。
1.遠粗近細舶赔，規(guī)劃先行
在整個敏捷流程開始之前，應(yīng)該先檢視如下幾項：
（1）BRD & roadmap
此時產(chǎn)品團隊已經(jīng)確定了所有大方向谦秧，以及達到這些方向的路徑竟纳。
（2）外部環(huán)境中的關(guān)鍵時間節(jié)點
此時應(yīng)該對接下來兩次迭代以內(nèi)的外部環(huán)境（如行業(yè)周期、市場壓力疚鲤、節(jié)假日等運營引爆點）有較為明確的把握锥累，確保版本方向不會受迫產(chǎn)生較大的變動。
（3）需求池
此時可能已經(jīng)積累有來自各方的需求集歇，以及產(chǎn)品規(guī)劃中預(yù)計要新增的模塊桶略。而每次迭代，需求來源都出自這個表格中诲宇。
根據(jù)以上际歼，首先通過關(guān)鍵時間節(jié)點來修正產(chǎn)品roadmap，細化roadmap中距離當(dāng)前最近的一段時間姑蓝，顆粒度最細須達到完成一次敏捷開發(fā)的所需要的時間鹅心。關(guān)于最終細化出來的產(chǎn)品路線，產(chǎn)品經(jīng)理的腦中一定要有非常清晰的節(jié)奏纺荧，明確每一步的整體目標(biāo)旭愧。完成后，應(yīng)該明確下一步迭代的兩個內(nèi)容宙暇，一是新增哪個模塊/欄目输枯，二是優(yōu)化哪些功能、頁面占贫。
對于新增的模塊桃熄，我們要讓它單獨進入敏捷開發(fā)流程，必須保證它是相對獨立的靶剑，不會受到另一個未開發(fā)模塊的牽制蜻拨。如果不是，那么這些模塊應(yīng)該在同一次迭代中桩引，以最基本（基本到只剩關(guān)鍵流程）的形態(tài)同時上線缎讼。
2.先加后減，解構(gòu)產(chǎn)品
確保新增模塊的獨立性后坑匠，就到了產(chǎn)品設(shè)計的環(huán)節(jié)了血崭。對于產(chǎn)品設(shè)計經(jīng)驗不是非常豐富的PM來說，此時，一定確保設(shè)計環(huán)節(jié)的完整夹纫，需求分析咽瓷、用戶任務(wù)和流程設(shè)計、產(chǎn)品結(jié)構(gòu)決不能被“敏捷”掉舰讹。直接動手做流程和原型茅姜，無論時間多緊都不應(yīng)該，反而會因為挖坑月匣，導(dǎo)致在以后浪費更多的時間去反復(fù)填坑钻洒。
我在做敏捷設(shè)計的時候，傾向于經(jīng)由完整的設(shè)計流程锄开，產(chǎn)出相對完整的產(chǎn)品設(shè)計素标，然后根據(jù)敏捷周期，來對產(chǎn)品進行精簡萍悴。這樣不會因為后期豐富該功能時头遭，由于思考不全面和先前沒有一個明確的理想解決方案，而推翻重做或者有較大改動癣诱；也保證了產(chǎn)品功能拆分后计维，各個子單元在不同版本迭代完全時的產(chǎn)品一致性。
我們需要對完整稿進行拆分和優(yōu)先級排序撕予，找出主要流程享潜、關(guān)鍵信息，先保證主線跑通嗅蔬，再考慮提升用戶體驗的輔助性功能剑按，以及提升用戶停留時長或提高轉(zhuǎn)化率的信息豐富手段。
由于這個完整稿澜术，本身就是用來試錯的艺蝴，那么，我們在細化需求的時候鸟废，可以先細化主線需求到能夠交付開發(fā)執(zhí)行的程度猜敢，而對于可能有變動甚至整體舍棄的其他分支，暫時到特性層面就可以了盒延。
基于完整稿缩擂，我們可以提出幾種拆分方案，在需求評審時添寺，與開發(fā)團隊討論確定最終的目標(biāo)方案胯盯。對于該方案，我們需要在方案內(nèi)的特性中计露，再次排出優(yōu)先級博脑。目的是憎乙，讓開發(fā)先做高優(yōu)先級特性，如果遇到不可預(yù)估的困難叉趣，可以馬上決策并削減優(yōu)先級低的特性泞边，保證主流程的完成，盡量弱化工程延期的不利后果疗杉。
3.簡短明了阵谚，文盡其用
關(guān)于產(chǎn)品設(shè)計后的需求表達，我一直以來的原則就是不參考模板烟具，靈活使用椭蹄。在敏捷開發(fā)中，我們通常不可能去寫全面啰嗦的PRD净赴，移動端更甚。我的做法是罩润，使用excel做產(chǎn)品backlog玖翅，省去所有對開發(fā)無意義的描述說明文字，從feature list直接獲得割以。審視自己寫下的每一個列首項金度，是不是對開發(fā)有用，省去所有無用項严沥。
如果團隊中沒有專職測試猜极，甚至可以將測試功能融合進backlog中，僅需增加測試結(jié)果與狀態(tài)兩列消玄，而只要需求想的透徹跟伏，特性說明完全可以做基本的功能測試用例。
同時翩瓜，該表格也可以融入項目管理的功能受扳。狀態(tài)列中，單元格為下拉菜單兔跌，分別有待開發(fā)勘高、待測試、完成三個狀態(tài)坟桅。
backlog表頭示例
適合每個團隊的文檔形式各不相同华望，有的開發(fā)喜歡原型結(jié)合文檔進行開發(fā)，有的喜歡看原型做仅乓，文檔備查赖舟，這些都需要PM提前溝通，了解PRD的用戶需求夸楣，砍掉無效的工作建蹄，制作出適合自己團隊的文檔形式碌更，并自己保證花在文檔上的時間，都是有效的洞慎。
