XAP 是 Xunlei Acount&Payment 的簡稱，是帳號支付項目組碍庵，通過不斷實踐探索得出的一套敏捷項目管理方法拔稳。此方法根據(jù)項目本身的特點，對 XP 和 Scrum 理論選擇性吸收和改進(jìn)两波，經(jīng)項目反復(fù)實踐瞳步，驗證了其有效性，供參考腰奋。
作為基礎(chǔ)服務(wù)團隊单起，我們的敏捷始于敏捷開發(fā)，并延伸到測試劣坊。組織內(nèi)部為平衡矩陣型嘀倒，5 種角色分屬不同的部門或團隊。經(jīng)過 5 年多的嘗試和實踐局冰，將「快速迭代测蘑，小步快跑」的思想貫穿于開發(fā)的上下游，逐漸發(fā)展為全項目敏捷管理锐想。
雖然敏捷開發(fā) Agile Development 一度被視為 敏捷管理 Agile Managment帮寻，但我們認(rèn)為不完全等同乍狐。敏捷開發(fā)主要是指從開發(fā)到上線赠摇，敏捷測試，敏捷產(chǎn)品設(shè)計等也應(yīng)該囊括到整個過程中浅蚪。所以藕帜，我們將敏捷中的代表 Scrum 視為敏捷管理，指導(dǎo)從需求拆分到任務(wù)完成的敏捷項目管理流程惜傲。
首先介紹一下我們團隊角色組成洽故，全文用簡稱指代：用圖代替
PM: Project Manager 項目經(jīng)理
PD: Product Designer 產(chǎn)品分析師，也是產(chǎn)品經(jīng)理或產(chǎn)品工程師
SE: Software Engnieer 軟件開發(fā)工程師盗誊，但是 DEV 更常用
QA: Quality Assurance 質(zhì)量保證工程師时甚，通常也代指測試工程師
文中常用的/表示或，&表示與哈踱。
敏捷思想
整體框架如下圖
- 需求提出方(PD/DEV )提交需求荒适，PM 按照 2~6 周能完成的工作量拆分為 N 個 milestone/sprint，指定master开镣。
- DEV&QA 在 kanban 中添加 1~2 天工作量能完成的 issue刀诬，需求提出方(PD/DEV ) 對 issue 進(jìn)行排序。
- 任務(wù)正式開始后邪财，DEV&QA 移動 issue 更新其狀態(tài)陕壹，并生成實時 burndown。由 mater 負(fù)責(zé) daily scrum树埠，問題匯總于 PM糠馆。
- 項目完成后，由 master 發(fā)起項目總結(jié)怎憋，并開始執(zhí)行下一個 milestone/sprint榨惠。
項目管理
角色和會議
角色主要有3個「」：Product Owner，Scrum Master，team member赠橙。
會議主要有4類[ ]：需求說明會耽装，排期立項會，每日站立會期揪，總結(jié)會掉奄。
工具有3個{ }：需求池管理，看板凤薛，燃盡圖姓建。
流程中涉及的角色，工作內(nèi)容和產(chǎn)出按時間順序整理如下缤苫。
1. 需求提出方 PD「1」
我們的需求提出方自來于兩方速兔，PD 和 DEV，因此產(chǎn)品負(fù)責(zé)人會有兩種角色活玲。他們的需求必須提前規(guī)劃至項目指定版本中涣狗，以文檔的形式存于需求池中。每個需求的提出遵循「28原則」舒憾，首先評估實現(xiàn)最重要的 20% 的需求镀钓。提出的需求是經(jīng)過拆分后的需求，通常是短小的镀迂，但同時丁溅，也允許大型需求的存在(一般是來自 PD 的需求)。文檔的作用是為后續(xù)工作提供指導(dǎo)探遵，也是組織過程資產(chǎn)窟赏，文檔中撰寫必要信息，一般 1~2 頁箱季，60分鐘內(nèi)可以說清楚涯穷，杜絕冗雜長達(dá)幾十頁的需求文檔。
2. 團隊team「2」
針對以上需求规哪，DEV&QA leader 提前預(yù)先了解求豫，派遣執(zhí)行小伙伴參與，執(zhí)行團隊宜小不宜大诉稍，一般為2~7人蝠嘉，以不超過7個人為宜。
3. 需求說明會[1]
需求提出方 PD/DEV 必須發(fā)起需求說明會杯巨，這也是需求評審會蚤告，通常是挑戰(zhàn)不合理的需求，增減需求或調(diào)整優(yōu)先級服爷。若有更新杜恰，則要求次日更新完畢获诈。
4. 立項排期 schedule[2]
由 PM 發(fā)起排期會議，正式會議前 DEV&QA 需要做出預(yù)估工時心褐，給出任務(wù)預(yù)期工時(不需要給出詳細(xì)的執(zhí)行日期)舔涎。PM 結(jié)合優(yōu)先級，整理工時逗爹，給出排期初稿亡嫌，同時附帶資源沖突意見。資源沖突交予 DEV&QA leader 解決后掘而，再重新修正排期挟冠。同時，我們需要確認(rèn)發(fā)版的頻次袍睡。
如果涉及重大技術(shù)方案更改知染，則需要 DEV 單獨召開方案討論會。
DEV 的工時評估包含了方案設(shè)計斑胜，執(zhí)行控淡，文檔撰寫和聯(lián)調(diào)過程；QA 的工時包含了測試用例設(shè)計伪窖，執(zhí)行和上線過程逸寓。整個周期不超過3天居兆，會面臨不斷修正和更改覆山。
簡單說來就是，預(yù)估工時 -> 排期 -> 調(diào)整沖突/技術(shù)方案 -> 重新排期泥栖。
此處簇宽，我們并未采用「點數(shù)」，即難易程度來估算工時吧享。雖然覺得這種估算方式很巧妙魏割，值得一試，但是同樣的钢颂，我們不擅于做這樣的評估钞它。但是，我們能將任務(wù)拆成一個可執(zhí)行的單元來操作殊鞭。而這一個單元遭垛，可稱為一個user story，user 則是自己操灿。
5. 沖刺和負(fù)責(zé)人 MS&Master「3」
MS 是指 milestone锯仪，本質(zhì)上是 sprint，一個 MS 即為一個 sprint趾盐。
一個項目分為一個還是多個 MS庶喜，由 PM 決定小腊。一般以 2 ~ 6 周 為一個 MS。少于 2 周的項目統(tǒng)一作為臨時項目久窟，不需要以 MS 來進(jìn)行管理秩冈。PM 拆分MS后，隨即確認(rèn)生個 MS 的起止日期斥扛。在確定好交付日期后漩仙，才能指定 master。
在整個沖刺期間犹赖，交付終期是不能變更的队他。如果出現(xiàn)了需要變更的情況，采取縮減需求或延長工期的方式來應(yīng)對變更峻村。前者需要 PD 縮減需求麸折，后者需要三方同意才可進(jìn)行變更，PM 需作好相應(yīng)記錄粘昨。
MS 有對應(yīng)的命名規(guī)范垢啼，需求-版本號-MS簡述 @master
6. 工作透明化 board&burndown {1}{2}
board是一個包含了 backlog，to do 张肾，doing 芭析，close 四種狀態(tài)的看板。
DEV/QA 將工作量以 issue 的形式提交于已建立的 MS 下面吞瞪，此時 issue 存于 backlog 中馁启。issue 有固定的命名格式，[優(yōu)先級-工作量 任務(wù)詳情]芍秆。所有 isse 添加完畢后惯疙，可進(jìn)行上下拖動排序。本周即將做的工作妖啥，全部拖入 to do list霉颠，在做的任務(wù) 拖入 doing，完成的任務(wù)拖入 close荆虱。
如何添加任務(wù)蒿偎，和拖動任務(wù)，制定了專門的操作手冊怀读，此處略诉位。
7. 站立會 daily scrum[3]
不同項目采取不同的策略，有些是daily scrum 愿吹，有些是 weekly scrum不从。同樣是三個問題：昨天做了什么，遇到什么困難犁跪，今天將要做什么椿息。
站立會需要 master 通過現(xiàn)象發(fā)現(xiàn)潛在的問題歹袁，有些問題未暴露，可能是困難擺在面前寝优，當(dāng)事不能正確識別出來条舔。
8. 高頻上線 push online
通常我們一周會確認(rèn)一個發(fā)版的日期，例如周二乏矾，在每周二發(fā)一次版本族壳。
9. 總結(jié) summary&next MS[4]
在項目完全上線后沽瘦，進(jìn)行一次集體的驗收和問題總結(jié)舅世，并規(guī)劃下一次MS孕讳。
需求管理
需求池管理{3}
需求用需求池進(jìn)行管理。至少具備以下功能：
- 能夠進(jìn)行任務(wù)指派捷沸，接力棒的傳遞
- 能夠支持附件摊沉，圖片必須能夠預(yù)覽
- 能夠有歷史記錄
- 具有全員參與的條件
- 支持主流編寫格式markdown，表格等痒给。
敏捷管理的源頭说墨，鼓勵需求的提出也是敏捷的，需求以用戶故事的方式提交苍柏。而我作為 PM 在中間作了一層轉(zhuǎn)化尼斧，將需求轉(zhuǎn)化為可執(zhí)行的，可實現(xiàn)的單元试吁。
PD 提交的需求分為兩類棺棵，一類是敏捷需求，一類是傳統(tǒng)需求潘悼。
敏捷需求在 6 周內(nèi)能完成律秃。而傳統(tǒng)需求爬橡，工期會在 2 個月以上治唤，甚至一年半載。現(xiàn)行組織結(jié)構(gòu)下糙申，不可避免會有傳統(tǒng)需求提出宾添，PM 在將需求拆分為 MS 的過程中，扮演著重要的角色柜裸。
對于一個 PD 和 DEV 都會提出需求的團隊缕陕，如何做好兩者之間的版本管理控制？
理想情況疙挺，項目的劃分應(yīng)該是與角色無關(guān)的扛邑，所有人都為共同的項目努力。換個角度講铐然，我們將這種并存的形態(tài)看作兩個不同的產(chǎn)品線蔬崩，相當(dāng)于有兩波人向我們項目組提出需求恶座，那項目形態(tài)就是不同的，需要按不同的項目來進(jìn)行管理沥阳。經(jīng)過梳理跨琳，PD 給出了3大產(chǎn)品16 個項目，而 DEV 給出了7大產(chǎn)品17個項目桐罕，總共33個項目脉让。兩類產(chǎn)品之間有完全不相關(guān)的關(guān)系，也有相互交疊的關(guān)系功炮。根據(jù)項目與角色可能存在的一對一溅潜，一對多的關(guān)系，將版本規(guī)范定義如下：
1. 各自為政：P線和D線各自管理自己版本號薪伏，雙方項目不會出現(xiàn)交叉
2. P線為主：P線主管版本號伟恶，D線向P線申請版本號，例如websdk
3. D線為主：D線主管版本號毅该，P線向D線申請版本號博秫，例如熊盾
一對多的項目，則是項目出現(xiàn)交叉之處眶掌，需要向版本持有者申請版本號挡育。
- 如何管理出現(xiàn)延期交付的需求，例如v2.1比v2.0先上線朴爬？
正確的做法是將需求前移即寒。兩份需求重新劃分，屬于本次上線的就是v2.0召噩，不上線的需求擱置到v2.1
一個D線更新母赵，會影響到多個被應(yīng)用的產(chǎn)品形態(tài)P線時，如何處理具滴？
以最主要的凹嘲，或最先實施的P線項目的版本為規(guī)劃起點來規(guī)劃版本，其余算產(chǎn)品接入构韵。一個P線更新周蹭，涉及多個D線更改時，如何處理疲恢？
這與上面有所區(qū)別凶朗，P線的版本號迭代更新，D線對應(yīng)的版本號需要分別作更新显拳，主要以技術(shù)方案更新的方式存于技術(shù)需求池棚愤。版本號對應(yīng)為：P線項目-版本 : D線項目-版本。
版本管理
項目內(nèi)部長年有一個有趣的現(xiàn)象：某項目重構(gòu)時杂数，都習(xí)慣性的稱之為新某項目宛畦，某新項目矛绘。一年之后，在此基礎(chǔ)上刃永，又成立一個項目货矮，為新某項目。再過一年斯够，又重構(gòu)囚玫，還是新某項目。幾年下來读规，我們項目換代了多次抓督，大家都搞不清，究竟哪個才是新束亏，哪個才是舊铃在。
版本管理從開始規(guī)劃到落實，遇到了不少阻礙碍遍，前后花了一年半定铜。下面講一講我們項目組內(nèi)的版本進(jìn)化過程。
項目內(nèi)版本有3種：產(chǎn)品版本號怕敬，代碼版本號TAG揣炕，文檔版本號。產(chǎn)品版本號與代碼版本號一定程度上有關(guān)聯(lián)东跪，并非完全一一對應(yīng)畸陡。
代碼版本管理
由于環(huán)境原因，我們首先推動改進(jìn)的是代碼版本號虽填，利用 gitlab 中的 TAG 功能丁恭，對每個上線的版本打上標(biāo)簽。TAG 在概念推廣期間遇到阻力斋日，大家都沒有這樣的習(xí)慣牲览，打不打 tag 對工作造成不了任何影響，代碼可以照樣提交桑驱，部署竭恬。執(zhí)行時，大家反而會認(rèn)為 leader 的一句話增加了工作負(fù)擔(dān)熬的。但是，當(dāng)逐步推行到將此 TAG 作為代碼交付赊级、上線的「唯一標(biāo)識」時押框，大家才真在開始普遍運用，因為在 TAG 缺失的情況下理逊，是不可能完發(fā)布動作的橡伞。我們將此作為一個核心的思想盒揉，而圍繞此 TAG，我們能精確的做到發(fā)布兑徘、灰度和回滾刚盈。
這里稍提及分支開發(fā)的思想：開發(fā)時，采用分支開發(fā)挂脑，多人同時開發(fā)時藕漱，會拉取不同的分支開發(fā)。如果不同分支存在先后版本關(guān)系崭闲，則測試時肋联，也可以測試分支 branch，不測試 master 版本刁俭。最終被測試通過的代碼合并到 master橄仍，版本則迭代為需求版本號，打 TAG 進(jìn)行封版牍戚，將 TAG 交付于運維推到生產(chǎn)環(huán)境侮繁。
當(dāng)某個版本出現(xiàn) bug 時，則從某版本處重新拉取一個分支修復(fù) bug如孝，而不影響主分支鼎天，且最終的 tag 修得也是針對分支打 tag。
TAG 版本是開發(fā)過程中對代碼做版本管理的一個手段暑竟，與需求版本號部分關(guān)聯(lián)斋射，與文檔版本號無關(guān)。只有將所需要推廣的內(nèi)容作為日常工作中必可少的一部分但荤，才有可能真正全面實施罗岖。
有效的解決了開發(fā)測試運維之間溝通問題的效率。
需求版本管理
通常腹躁，敏捷管理下的產(chǎn)品版本號桑包，并沒有傳統(tǒng)項目那么好管理，PD 往往忽視提交需求的版本區(qū)分纺非，給下游工作帶來很大的麻煩哑了。我們需要將各業(yè)務(wù)線，和與之相關(guān)聯(lián)的業(yè)務(wù)以版本迭代的形式進(jìn)行管理烧颖。便于下游同事以以版本為基準(zhǔn)進(jìn)行sprint 規(guī)劃弱左，測試用例建立等。
文檔版本管理
文檔版本號炕淮，一般針對協(xié)議文檔拆火，需要說明版本迭代的歷史與目前的版本號，以便調(diào)用方區(qū)分線上使用何種協(xié)議。
敏捷的一些思考和質(zhì)疑
我們的過程是敏捷嗎们镜？
scrum中典型的幾個特點币叹，如點數(shù)我們并未采納，對于工作的評估我們依然是基于時間來的模狭，與scrum中強調(diào)的「我們對時間的估算是最不準(zhǔn)確的」相悖颈抚。
我們角色與角色之間有明顯的交付日期，這與沖刺階段自主工作也是相悖的嚼鹉。哪些是敏捷一定不能有的贩汉？
短期看不到效果的項目
我們團隊的宗旨「最大限度提升人的自由和創(chuàng)造力」，從何而談反砌？敏捷沒有文檔
我們團隊的敏捷與傳統(tǒng)瀑布V模型的小型瀑布模式有什么區(qū)別雾鬼？
理解一個概念，擁有完整流程的過程宴树，是不是就一定不是敏捷策菜？
同樣是要經(jīng)過完整的需求設(shè)計、需求評審酒贬、方案評審又憨，到用例設(shè)計與評審，最后到執(zhí)行的環(huán)節(jié)锭吨。
我們所采用的敏捷蠢莺，是否只是概念上的敏捷，而本質(zhì)上仍然還是V模型零如？形似而神不似躏将。什么樣的迭代頻次可以稱得上是敏捷？
敏捷的精髓是否掌握完全考蕾？
遇到一個問題一直阻塞不能解時祸憋，怎么辦？
-
團隊目前存在的問題
某個時間段某個 DEV 在做些技術(shù)攻堅肖卧，PD是否知道需要避開這個時間段提測需求蚯窥。PM 一個人承擔(dān)了master的角色，在各個項目中保證流程正常流轉(zhuǎn)塞帐，若PM離開拦赠，此流程還是否迭代下去？2018-05-29
