從去年年底開始負(fù)責(zé)APP的社區(qū)功能，技術(shù)實(shí)現(xiàn)上用可H5的形式，從APP團(tuán)隊(duì)中獨(dú)立出來(lái)。以小團(tuán)隊(duì)嘗試敏捷開發(fā)模式的探索，而我作為產(chǎn)品經(jīng)理，自然也是這個(gè)敏捷項(xiàng)目的Scrum Master。

我們團(tuán)隊(duì)的構(gòu)成為：

• 產(chǎn)品 * 2/3
• 設(shè)計(jì) * 1/3
• 測(cè)試 * 2/3
• 前端 * 1
• 服務(wù)端 * 1
• 后臺(tái) * 1/2

這應(yīng)該算是敏捷開發(fā)中最mini的團(tuán)隊(duì)，而且大部分人還不是完整的一人力投入到社區(qū)工作中，包括我自己。但好在其他人額外的工作也由我這邊管理，從需求排期上我可以靈活支配大家的工作排期，不影響到社區(qū)項(xiàng)目整體節(jié)奏。經(jīng)過(guò)這快一年的磨合，我們的迭代速度從2周變?yōu)?周，也把敏捷開發(fā)流程修改踐行到最適合我們團(tuán)隊(duì)的模式。

有一些我作為產(chǎn)品經(jīng)理對(duì)于敏捷開發(fā)的思考，將其記錄下來(lái)。

1. 坐在一起

所有講Scrum敏捷開發(fā)的文章里都很重視團(tuán)隊(duì)每日的站會(huì)，“今天做了什么，將要做什么，有什么障礙”的站會(huì)三個(gè)主題是為了團(tuán)隊(duì)每個(gè)人快讀溝通當(dāng)前的進(jìn)度與困難，促使團(tuán)隊(duì)更好的協(xié)同開發(fā)，認(rèn)為站會(huì)是敏捷開發(fā)中必不可少的環(huán)節(jié)。但是在施行中，站會(huì)的效率很難保證，經(jīng)常變成昨日熱門話題的集中閑聊會(huì)，當(dāng)然也是我這個(gè)PM組織的爛。而且因?yàn)槭菑椥怨ぷ髦?，加上北京早上糟糕的交通，召集?huì)議也花很多時(shí)間。

鑒于此，我們不再開晨會(huì)，而是直接坐在一起。每天需要同步大家進(jìn)度的時(shí)候，直接轉(zhuǎn)個(gè)椅子快速溝通就結(jié)束了，而且遇到問(wèn)題也及時(shí)讓同事提出來(lái)，大家一個(gè)轉(zhuǎn)身就去看具體問(wèn)題了。

另外這種從技術(shù)、產(chǎn)品、設(shè)計(jì)的獨(dú)立團(tuán)隊(duì)中剖離出來(lái)的獨(dú)立感，坐在一起能讓團(tuán)隊(duì)成員有項(xiàng)目團(tuán)隊(duì)的歸屬感。除工作以外，大家也更熟悉生活中的彼此，能更好分擔(dān)協(xié)助彼此完成項(xiàng)目的工作。

2. 不要用傳統(tǒng)的項(xiàng)目管理工具

在公司開發(fā)流程中最常用的項(xiàng)目協(xié)作工具是Readmine。我個(gè)人是對(duì)傳統(tǒng)的這類軟件開發(fā)時(shí)代用的協(xié)作工具Readmine、Bugzilla……抱有無(wú)限的敵意，因?yàn)檫@類工具經(jīng)過(guò)這么多年的更新，實(shí)在是太完善了，太大太全太復(fù)雜。并且傳統(tǒng)項(xiàng)目管理工具的受眾是專職的項(xiàng)目經(jīng)理，產(chǎn)品經(jīng)理用這類軟件做項(xiàng)目管理太耗費(fèi)時(shí)間，太容易掉到瑣碎的項(xiàng)目管理細(xì)節(jié)中。

所以，在我們項(xiàng)目中采用Tower做項(xiàng)目管理工具。類似的看板類項(xiàng)目管理工具如Trello、Teambition、Phabricator、Tower……大多大同小異，找一個(gè)自己順手習(xí)慣的就好?？窗孱惖捻?xiàng)目管理工具最方便的就是拖拽任務(wù)，可以在一頁(yè)上看清該版本各個(gè)任務(wù)的進(jìn)度。另外這類項(xiàng)目管理工具有更好的擴(kuò)展性，有豐富的插件可以去選擇性集成以提高開發(fā)效率。

在敏捷開發(fā)的流程中，產(chǎn)品經(jīng)理需要做好項(xiàng)目管理的工作。而項(xiàng)目管理工具是必不可少的，至于如何選擇每個(gè)人使用習(xí)慣差異很大，可以根據(jù)自己團(tuán)隊(duì)現(xiàn)實(shí)情況去選擇?？傊灰脗鹘y(tǒng)的項(xiàng)目管理軟件，因?yàn)閭鹘y(tǒng)項(xiàng)目管理工具的受眾是項(xiàng)目經(jīng)理，而不是產(chǎn)品經(jīng)理。

3. 輕文檔、重交流

我們公司沒(méi)有UE，產(chǎn)品經(jīng)理除了出需求，還需要給出交互。如果按照正規(guī)的文檔流程規(guī)范，一個(gè)版本的文檔寫完，留給開發(fā)的時(shí)間也就不多了。至少在我們項(xiàng)目中，我不寫文檔只出交互，重要的點(diǎn)直接在圖中文字標(biāo)注。但產(chǎn)品的邏輯細(xì)節(jié)，我會(huì)在畫交互稿的同時(shí)記錄在個(gè)人的印象筆記里。好記性不如爛筆頭，盡管不輸出正式的文檔，但產(chǎn)品的邏輯必須明確。畢竟后續(xù)的需求修改、測(cè)試用例都基于原始的產(chǎn)品邏輯，產(chǎn)品經(jīng)理忘記自己設(shè)計(jì)的東西，無(wú)論如何都是說(shuō)不過(guò)去的。

輸出交互稿之后，我會(huì)單獨(dú)拉上開發(fā)、測(cè)試和視覺去開一個(gè)會(huì)，具體講一下這個(gè)需求的設(shè)計(jì)，傳達(dá)本來(lái)需要我用文字寫在文檔中的意思。當(dāng)然不寫文檔，不代表需求模糊，經(jīng)不起其他人在會(huì)上的挑戰(zhàn)。

會(huì)上說(shuō)需求設(shè)計(jì)的最大的好處是，我能明確的用口語(yǔ)傳達(dá)出對(duì)需求細(xì)節(jié)的感情色彩，哪兒是重點(diǎn)，哪兒細(xì)節(jié)體驗(yàn)要保證，哪兒做成什么樣都行……很多是無(wú)法拆分的需求細(xì)節(jié)，但是通過(guò)言語(yǔ)說(shuō)出來(lái)就很容易被拆分掉，更好地讓開發(fā)容易理解需求重點(diǎn)，加快開發(fā)速度。

4. 需求評(píng)審、總結(jié)復(fù)盤拉上所有團(tuán)隊(duì)成員

一般項(xiàng)目的需求評(píng)審一般是產(chǎn)品拉著各個(gè)老大來(lái)做需求評(píng)審，各個(gè)老大接了需求后會(huì)上評(píng)估下工期，會(huì)下再把相關(guān)的需求分給下面的人做。具體做事的人，往往是接到需求后再啃文檔，自己理解后再去開發(fā)?？偨Y(jié)復(fù)盤的郵件更是只在產(chǎn)品組內(nèi)部和leader的郵箱里呆著，根本不會(huì)給到每個(gè)開發(fā)成員

而敏捷開發(fā)從需求評(píng)審階段就必須拉上所有團(tuán)隊(duì)成員，產(chǎn)品經(jīng)理要把需求場(chǎng)景、優(yōu)先等級(jí)、用戶調(diào)研……講給所有人聽。然后要在團(tuán)隊(duì)中達(dá)成一致，讓團(tuán)隊(duì)所有的小伙伴都認(rèn)可你的需求，并且愿意主動(dòng)把這個(gè)需求做下去。版本上線后的效果也需要同步給團(tuán)隊(duì)的小伙伴，讓大家都輸出的結(jié)果都有反饋，然后也可以聽聽團(tuán)隊(duì)每個(gè)人的建議與感覺，再綜合考慮及時(shí)調(diào)整產(chǎn)品。這些能極大強(qiáng)化團(tuán)隊(duì)的凝聚力，讓每個(gè)人并非只是做自己手頭的工作，更有產(chǎn)品的主人翁意識(shí)。

5. 所有人都是測(cè)試

這點(diǎn)經(jīng)驗(yàn)與我們項(xiàng)目類型有關(guān)，因?yàn)槲覀冏龅氖巧鐓^(qū)類產(chǎn)品，很多測(cè)試的case流程必須要帳號(hào)間的互動(dòng)，久而久之我們團(tuán)隊(duì)在測(cè)試階段每個(gè)人都演變成了測(cè)試。

測(cè)試同事寫完測(cè)試用例，等提測(cè)之后，我們所有人都匯聚在一個(gè)小會(huì)議室里。每個(gè)人分工其中的一些流程測(cè)試，快速協(xié)助測(cè)試走完case，然后快速將bug記在白板上發(fā)到群里備份，一部分需要專業(yè)手段的測(cè)試還需要測(cè)試同事專業(yè)的方法，大家協(xié)助測(cè)試的部分主要還是流程測(cè)試。快速過(guò)完之后，開發(fā)回去解bug，測(cè)試同事整理測(cè)試報(bào)告。遇到重大的bug block版本，大家就直接在會(huì)議室里討論預(yù)案。

這種快速的團(tuán)隊(duì)測(cè)試能極大的提升測(cè)試效率，往往測(cè)試同事花一天才能跑完的用例，我們四個(gè)人在會(huì)議室一小時(shí)就搞定了，而且因?yàn)殚_發(fā)也參與了測(cè)試流程，連問(wèn)題描述、復(fù)現(xiàn)步驟都不用寫就可以直接定位問(wèn)題。

6. 每個(gè)Sprint間要注意重要功能的穿插

這點(diǎn)其實(shí)是所有開發(fā)排期的都需要注意的問(wèn)題，只是敏捷開發(fā)更容易暴露這個(gè)問(wèn)題。這里的重要功能，并不是產(chǎn)品優(yōu)先級(jí)上的重要，而是開發(fā)難度上的定義。因?yàn)槊艚蓍_發(fā)的周期很短，每個(gè)重要功能上線后往往需要一定時(shí)間進(jìn)行穩(wěn)定。如果在排期上每個(gè)Sprint都有重要的功能，穩(wěn)定上個(gè)版本與開發(fā)下個(gè)版本交叉，基本上會(huì)造成下個(gè)版本的delay。

所以在需求排期中，臨近的Sprint要注意功能上的間隔。有的功能干脆就在需求排期中強(qiáng)制拆開，留足穩(wěn)定的buffer。另外，有時(shí)候版本發(fā)不出去就不要發(fā)，不要為了敏捷而發(fā)版，那樣就本末倒置啦！我們團(tuán)隊(duì)還有一個(gè)約定俗成的事，如果大家齊力克服困難將一個(gè)眼看需要delay的版本弄上線了，上線后必須tb大吃一頓作為獎(jiǎng)勵(lì)刺激，23333~

總結(jié)

我們項(xiàng)目經(jīng)過(guò)大半年的敏捷開發(fā)，無(wú)論是團(tuán)隊(duì)氣氛還是產(chǎn)品數(shù)據(jù)都取得了比較好的結(jié)果。與其說(shuō)敏捷開發(fā)是一種項(xiàng)目管理的方法，不如說(shuō)是一種切換大家工作角色的方式。讓大家拋開原來(lái)的螺絲釘角色，全方位的參與到整個(gè)項(xiàng)目的流程中，強(qiáng)化主人翁意識(shí)。讓團(tuán)隊(duì)的每個(gè)人切實(shí)地認(rèn)識(shí)到自己就是這個(gè)產(chǎn)品的主人，主動(dòng)為產(chǎn)品考慮，主動(dòng)協(xié)助上下游更好地完成目標(biāo)。