拖了那么久杉女，感覺不能再拖了。正好最近2018年Q1季度結(jié)束鸳吸，對Q1季度的敏捷開發(fā)實踐做了系統(tǒng)性的回顧熏挎，總結(jié)了一下經(jīng)驗教訓(xùn)，那就接著上次提到的晌砾，這次來介紹一下敏捷開發(fā)的基本概念吧坎拐。
畢竟Jira只是敏捷開發(fā)的管理工具，想要正確的使用养匈，需要具備基礎(chǔ)的理論知識哼勇。
瀑布流模型
開始介紹敏捷開發(fā)之前，先介紹一下敏捷開發(fā)方式提出之前的開發(fā)方式：瀑布流模型呕乎。
瀑布流模型將軟件開發(fā)和交付劃分為幾個相互獨立的階段：
- 需求收集
- 設(shè)計
- 編碼
- 測試
其中每一步都需要等前一步完成之后才能進(jìn)行积担，必須從上向下，也因此得名“瀑布”猬仁。瀑布流模型的理念有點“人定勝天”的意思帝璧，意圖在開發(fā)之前就確定好一切細(xì)節(jié)——有經(jīng)驗的開發(fā)者都知道這是不可能的。在傳統(tǒng)行業(yè)如建筑業(yè)中湿刽，受限于交付物的體量以及改動成本的烁，而不得不采用瀑布方式，畢竟房子蓋好了只能簡單改改格局诈闺，其他想改只能推到重建渴庆。而對于軟件開發(fā)特別是互聯(lián)網(wǎng)軟件開發(fā)來說，對已經(jīng)交付的軟件進(jìn)行改動簡直不能再簡單了雅镊。
敏捷開發(fā)
2001年襟雷，十幾位很厲害的開發(fā)者們聚在一起，經(jīng)過一翻交流之后仁烹，發(fā)起了敏捷運動耸弄，還撰寫了一份宣言——《敏捷宣言》。現(xiàn)在這份敏捷宣言還托管在GitHub Pages上晃危，有興趣的可以去http://agilemanifesto.org看一看：
圖中靠下的位置就是當(dāng)時的十幾位開發(fā)者叙赚。搜一下會發(fā)現(xiàn)他們各自寫了很多軟件開發(fā)領(lǐng)域的教科書級書目。
敏捷宣言的主要內(nèi)容僚饭，翻譯一下是：
個體和互動 高于 流程和工具
工作的軟件 高于 詳盡的文檔
客戶合作 高于 合同談判
響應(yīng)變化 高于 遵循計劃也就是說震叮，盡管右項有其價值，
我們更重視左項的價值鳍鸵。
敏捷開發(fā)也存在需求苇瓣、設(shè)計、編碼偿乖、測試4種職能击罪，不過敏捷開發(fā)并不是小型瀑布流哲嘲，4種職能之間是緊密結(jié)合、彼此交融媳禁、相互依賴的眠副，不存在瀑布流的“職能筒倉”問題。文檔竣稽、開發(fā)囱怕、測試往往是同步進(jìn)行的『帘穑基于敏捷開發(fā)的理念娃弓，衍生出來精益開發(fā)、極限編程岛宦、測試驅(qū)動開發(fā)（TDD）等等具體方法台丛，而Jira所支持的Scrum就是其中的方法之一。
Scrum在英語是橄欖球運動中列陣爭球的意思砾肺。就我看過為數(shù)不多的球賽里面挽霉，2012年歐洲杯決賽西班牙隊4：0血虐意大利隊的戰(zhàn)術(shù)，也有不少scrum的意思债沮，小步快傳炼吴，全隊皆鋒。
Scrum角色
在Scrum團(tuán)隊中有3種角色：
1疫衩、產(chǎn)品負(fù)責(zé)人Product Owner，定義需求列表及優(yōu)先級荣德、驗收標(biāo)準(zhǔn)闷煤，代表業(yè)務(wù)需求方，也就是我們常說的產(chǎn)品經(jīng)理涮瞻。不過產(chǎn)品經(jīng)理往往身兼更多職責(zé)如項目管理鲤拿、交互設(shè)計、用戶調(diào)研等署咽。
2近顷、敏捷教練Scrum Master，保證團(tuán)隊按Scrum的方式良好運轉(zhuǎn)下去宁否，在沒有專職人員的情況下窒升，一般由研發(fā)經(jīng)理擔(dān)任比較合適。如果由產(chǎn)品經(jīng)理負(fù)責(zé)慕匠，需要對軟件開發(fā)技術(shù)有一定的了解饱须，并且能夠清晰剝離出自己Product Owner與Scrum Master的職責(zé)，在正確的時機(jī)做正確的事台谊，因為這兩個角色之間的關(guān)系基本是相互對抗的蓉媳。
3譬挚、團(tuán)隊成員Team Member，真正做編碼和測試的人員酪呻，對故事和任務(wù)工作量做估算减宣，并交付最終可用的產(chǎn)品。
Sprint周期
Sprint（沖刺）周期是執(zhí)行Scrum的基本節(jié)奏玩荠。每一個Sprint周期都是一個固定的時間盒蚪腋。在這個時間盒內(nèi)，要做的故事和任務(wù)（也就是產(chǎn)品需求）是確定的姨蟋。當(dāng)周期結(jié)束時屉凯，不管需求有沒有全部完成，這個時間盒都會結(jié)束眼溶，并準(zhǔn)備啟動下一個時間盒悠砚。如此循環(huán)，通過快節(jié)奏的迭代沖刺堂飞，不斷交付有價值的產(chǎn)品并且不斷修正產(chǎn)品灌旧。
在一個Sprint周期中，有幾個主要會議：
1绰筛、Sprint規(guī)劃會議万矾，在會上產(chǎn)品負(fù)責(zé)人津滞、敏捷教練、團(tuán)隊成員會坐在一起，共同決定這次的Sprint要完成哪些用戶故事粱檀，并將故事分拆為任務(wù)，然后對任務(wù)進(jìn)行估算戚啥。
2袒啼、Scrum日會/站會，找一個每天固定的時間具被，團(tuán)隊成員站在一起玻募，每個人輪流陳述上一次日會之后已完成的內(nèi)容、下一次日會之前期望完成的內(nèi)容一姿，然后對比前一次日會的“期望”與本次例會的“完成”七咧，如果不符合，可以立即發(fā)現(xiàn)并尋找原因加以解決叮叹。
3艾栋、Sprint評審/演示，在Sprint結(jié)束的時候?qū)ν瓿傻膬?nèi)容進(jìn)行演示衬横，或者叫驗收裹粤。團(tuán)隊成員從用戶的角度演示本期Sprint交付的故事如何被使用。這里有個經(jīng)驗，對于無法演示的內(nèi)容遥诉，比如提高頁面的平均加載速度至3s以內(nèi)拇泣，拿出相應(yīng)的證據(jù)進(jìn)行“演示”即可。
4矮锈、回顧總結(jié)霉翔，可能都覺得沒什么用，甚至團(tuán)隊成員在會上不知道說什么苞笨。我拿實際經(jīng)驗告訴你债朵，堅持下去，很有用瀑凝！對團(tuán)隊來講長期收益巨大序芦！團(tuán)隊會慢慢變得更有干勁、更有效率粤咪，輸出的代碼質(zhì)量也會提高谚中。如果沒人發(fā)言，一定要逼著他們說寥枝。
Story & Task
說了這么多宪塔，終于到了跟Jira高度相關(guān)的部分了。在（一）中我們只簡單提了Story是用戶故事囊拜，現(xiàn)在是時候詳細(xì)說明一下了某筐。
用戶故事，是從業(yè)務(wù)及用戶角度出發(fā)冠跷，描述產(chǎn)品可以完成哪些事情的簡要說明南誊，每一條用戶故事都應(yīng)具備用戶價值。書寫正確的用戶故事蔽莱，是進(jìn)行敏捷開發(fā)的重要一步弟疆。缺乏經(jīng)驗的產(chǎn)品負(fù)責(zé)人往往把用戶故事當(dāng)成團(tuán)隊成員要做的事情，而不是用戶要做的事情盗冷。
舉個例子，一個不合格的用戶故事：
“在數(shù)據(jù)庫中增加一個賣家聯(lián)系方式字段并展示在前臺頁面上”
這個做了給誰用的同廉？怎么用仪糖？有什么用？
對比一下合格的寫法：
“賣家可以在管理后臺填寫聯(lián)系方式迫肖，讓使用App的買家在遇到問題時能及時聯(lián)系專家”锅劝。
在這個合格的用戶故事中，包含了3個要素：用戶蟆湖、行為故爵、目標(biāo)/價值∮缃颍“某人可以做某事以達(dá)到某種目標(biāo)”诬垂，或者“某人可以做某事以創(chuàng)造某種價值”劲室。
用戶故事言簡意賅、目標(biāo)清晰即可结窘，不需要很洋、也不應(yīng)該寫得非常詳細(xì)。只要能達(dá)到目標(biāo)/創(chuàng)建價值隧枫，在細(xì)節(jié)上采取什么方式都不重要喉磁，團(tuán)隊成員要做的是以用戶故事作為指引，協(xié)力找出投入產(chǎn)出比最高的解決方案官脓。太詳細(xì)的用戶故事协怒，只會限制團(tuán)隊的創(chuàng)造力，并把團(tuán)隊的注意力吸引到“執(zhí)行命令”而非“創(chuàng)造用戶價值”上卑笨。
Task則是將用戶故事分解之后得出的任務(wù)孕暇。比如剛剛舉的用戶故事的例子，就可以分拆成以下幾個任務(wù)：
- 后端增加聯(lián)系方式字段湾趾，并提供API供前端讀寫
- Web前端增加填寫聯(lián)系方式的表單
- App中顯示相應(yīng)賣家的聯(lián)系方式
一些不涉及用戶故事芭商，但對團(tuán)隊有價值的工作，也可以列為“技術(shù)”任務(wù)搀缠。如“編寫測試環(huán)境部署腳本铛楣，讓測試人員可以主動選擇測試分支”。
估算
把估算單獨拿出來說艺普，是因為在通過Jira實踐Scrum敏捷開發(fā)時簸州，估算是相當(dāng)重要卻又很容易被誤用的一環(huán)。
對任務(wù)做估算的目的是為了對工作量有大致的預(yù)判歧譬，從而在有限的時間內(nèi)交付盡可能多的用戶價值（而不是開發(fā)工作量）岸浑，更不是為了對項目的時間節(jié)點進(jìn)行精確的控制。團(tuán)隊的生產(chǎn)速率基本是固定的瑰步，而具體到每個開發(fā)任務(wù)的工作量也都是基本固定的矢洲，所以只要團(tuán)隊都在持續(xù)且高效的輸出價值就足夠了。妄圖以強(qiáng)制的deadline讓團(tuán)隊成員持續(xù)加班缩焦，結(jié)果只能是幸福感降低读虏，然后是效率降低，然后要么是交付物的質(zhì)量下降要么是交付物的范圍縮減袁滥，最后團(tuán)隊分崩離析盖桥。
估算一般有3種方法：小時數(shù)，點數(shù)题翻，任務(wù)數(shù)揩徊。小時數(shù)過于精細(xì)，而且容易陷入精打細(xì)算的誤區(qū)；任務(wù)數(shù)過于籠統(tǒng)塑荒，對任務(wù)分拆的粒度有較高的要求熄赡；點數(shù)即Jira中的Story Points，也是實踐下來比較推薦的估算方法袜炕。
點數(shù)的是為了比較出開發(fā)任務(wù)之間的相對大小本谜。隨便選一個看起來工作量比較小的任務(wù)作為1，然后看其他任務(wù)是這個任務(wù)的幾倍偎窘，遇到比這個任務(wù)還要小的就算0.5乌助。在估算點數(shù)的時候，只能在0.5/1/2/3/5/8/15/20/30中選擇陌知，甚至30都不應(yīng)該被使用他托，當(dāng)一個任務(wù)的工作量是另一個任務(wù)的30倍的時候，這個任務(wù)一定可以被分解成更具體的任務(wù)仆葡。這么規(guī)定的原因還是因為我們要比的是相對大小赏参，在估算時一個任務(wù)是18點還是19點，沒有什么區(qū)別沿盅。
可以看到點數(shù)只是一個相對值把篓，沒有單位。在實踐中腰涧，團(tuán)隊成員剛開始進(jìn)行估算時很容易陷入1點 = xx小時的誤區(qū)韧掩，先估計小時數(shù)，然后再把小時數(shù)換算成點數(shù)窖铡。作為Scrum Master疗锐，要么努力糾正這種誤區(qū)并引導(dǎo)建立正確的觀念，要么就讓團(tuán)隊成員用人天當(dāng)單位估算吧费彼。
關(guān)于敏捷開發(fā)的基本概念和基礎(chǔ)知識介紹的差不多了滑臊，其他一些像燃盡圖、控制圖箍铲、任務(wù)板之類的等用到再說吧雇卷。
微信公眾號：三角規(guī)（ID：coding-designer）
