Jira入門教程 敏捷開發(fā)管理（二）
拖了那么久，感覺不能再拖了飘千。正好最近2018年Q1季度結(jié)束堂鲜，對(duì)Q1季度的敏捷開發(fā)實(shí)踐做了系統(tǒng)性的回顧，總結(jié)了一下經(jīng)驗(yàn)教訓(xùn)占婉，那就接著上次提到的泡嘴，這次來介紹一下敏捷開發(fā)的基本概念吧。
畢竟Jira只是敏捷開發(fā)的管理工具逆济，想要正確的使用酌予，需要具備基礎(chǔ)的理論知識(shí)。
瀑布流模型
開始介紹敏捷開發(fā)之前奖慌，先介紹一下敏捷開發(fā)方式提出之前的開發(fā)方式：瀑布流模型抛虫。
瀑布流模型將軟件開發(fā)和交付劃分為幾個(gè)相互獨(dú)立的階段：
需求收集
設(shè)計(jì)
編碼
測(cè)試
其中每一步都需要等前一步完成之后才能進(jìn)行，必須從上向下简僧，也因此得名“瀑布”建椰。瀑布流模型的理念有點(diǎn)“人定勝天”的意思，意圖在開發(fā)之前就確定好一切細(xì)節(jié)——有經(jīng)驗(yàn)的開發(fā)者都知道這是不可能的岛马。在傳統(tǒng)行業(yè)如建筑業(yè)中棉姐，受限于交付物的體量以及改動(dòng)成本，而不得不采用瀑布方式啦逆，畢竟房子蓋好了只能簡(jiǎn)單改改格局伞矩，其他想改只能推到重建。而對(duì)于軟件開發(fā)特別是互聯(lián)網(wǎng)軟件開發(fā)來說夏志，對(duì)已經(jīng)交付的軟件進(jìn)行改動(dòng)簡(jiǎn)直不能再簡(jiǎn)單了乃坤。
敏捷開發(fā)
2001年，十幾位很厲害的開發(fā)者們聚在一起沟蔑，經(jīng)過一翻交流之后湿诊，發(fā)起了敏捷運(yùn)動(dòng)，還撰寫了一份宣言——《敏捷宣言》∈莶模現(xiàn)在這份敏捷宣言還托管在GitHub Pages上厅须，有興趣的可以去http://agilemanifesto.org看一看：
圖中靠下的位置就是當(dāng)時(shí)的十幾位開發(fā)者。搜一下會(huì)發(fā)現(xiàn)他們各自寫了很多軟件開發(fā)領(lǐng)域的教科書級(jí)書目食棕。
敏捷宣言的主要內(nèi)容九杂，翻譯一下是：
個(gè)體和互動(dòng)高于 流程和工具
工作的軟件高于 詳盡的文檔
客戶合作高于 合同談判
響應(yīng)變化高于 遵循計(jì)劃
也就是說，盡管右項(xiàng)有其價(jià)值宣蠕，
我們更重視左項(xiàng)的價(jià)值例隆。
敏捷開發(fā)也存在需求、設(shè)計(jì)抢蚀、編碼镀层、測(cè)試4種職能，不過敏捷開發(fā)并不是小型瀑布流，4種職能之間是緊密結(jié)合唱逢、彼此交融吴侦、相互依賴的，不存在瀑布流的“職能筒倉”問題坞古。文檔备韧、開發(fā)、測(cè)試往往是同步進(jìn)行的痪枫≈茫基于敏捷開發(fā)的理念，衍生出來精益開發(fā)奶陈、極限編程易阳、測(cè)試驅(qū)動(dòng)開發(fā)（TDD）等等具體方法，而Jira所支持的Scrum就是其中的方法之一吃粒。
Scrum在英語是橄欖球運(yùn)動(dòng)中列陣爭(zhēng)球的意思潦俺。就我看過為數(shù)不多的球賽里面，2012年歐洲杯決賽西班牙隊(duì)4：0血虐意大利隊(duì)的戰(zhàn)術(shù)徐勃，也有不少scrum的意思事示，小步快傳，全隊(duì)皆鋒僻肖。
Scrum角色
在Scrum團(tuán)隊(duì)中有3種角色：
1肖爵、產(chǎn)品負(fù)責(zé)人Product Owner，定義需求列表及優(yōu)先級(jí)檐涝、驗(yàn)收標(biāo)準(zhǔn)遏匆，代表業(yè)務(wù)需求方法挨，也就是我們常說的產(chǎn)品經(jīng)理谁榜。不過產(chǎn)品經(jīng)理往往身兼更多職責(zé)如項(xiàng)目管理、交互設(shè)計(jì)凡纳、用戶調(diào)研等窃植。
2、敏捷教練Scrum
Master荐糜，保證團(tuán)隊(duì)按Scrum的方式良好運(yùn)轉(zhuǎn)下去巷怜，在沒有專職人員的情況下，一般由研發(fā)經(jīng)理擔(dān)任比較合適暴氏。如果由產(chǎn)品經(jīng)理負(fù)責(zé)延塑，需要對(duì)軟件開發(fā)技術(shù)有一定的了解，并且能夠清晰剝離出自己Product
Owner與Scrum Master的職責(zé)答渔，在正確的時(shí)機(jī)做正確的事关带，因?yàn)檫@兩個(gè)角色之間的關(guān)系基本是相互對(duì)抗的。
3沼撕、團(tuán)隊(duì)成員Team Member宋雏，真正做編碼和測(cè)試的人員芜飘，對(duì)故事和任務(wù)工作量做估算，并交付最終可用的產(chǎn)品磨总。
Sprint周期
Sprint（沖刺）周期是執(zhí)行Scrum的基本節(jié)奏嗦明。每一個(gè)Sprint周期都是一個(gè)固定的時(shí)間盒。在這個(gè)時(shí)間盒內(nèi)蚪燕，要做的故事和任務(wù)（也就是產(chǎn)品需求）是確定的娶牌。當(dāng)周期結(jié)束時(shí)，不管需求有沒有全部完成邻薯，這個(gè)時(shí)間盒都會(huì)結(jié)束裙戏，并準(zhǔn)備啟動(dòng)下一個(gè)時(shí)間盒。如此循環(huán)厕诡，通過快節(jié)奏的迭代沖刺累榜，不斷交付有價(jià)值的產(chǎn)品并且不斷修正產(chǎn)品。
在一個(gè)Sprint周期中灵嫌，有幾個(gè)主要會(huì)議：
1壹罚、Sprint規(guī)劃會(huì)議，在會(huì)上產(chǎn)品負(fù)責(zé)人寿羞、敏捷教練猖凛、團(tuán)隊(duì)成員會(huì)坐在一起，共同決定這次的Sprint要完成哪些用戶故事绪穆，并將故事分拆為任務(wù)辨泳，然后對(duì)任務(wù)進(jìn)行估算。
2玖院、Scrum日會(huì)/站會(huì)菠红，找一個(gè)每天固定的時(shí)間，團(tuán)隊(duì)成員站在一起难菌，每個(gè)人輪流陳述上一次日會(huì)之后已完成的內(nèi)容试溯、下一次日會(huì)之前期望完成的內(nèi)容，然后對(duì)比前一次日會(huì)的“期望”與本次例會(huì)的“完成”郊酒，如果不符合遇绞，可以立即發(fā)現(xiàn)并尋找原因加以解決。
3燎窘、Sprint評(píng)審/演示摹闽，在Sprint結(jié)束的時(shí)候?qū)ν瓿傻膬?nèi)容進(jìn)行演示，或者叫驗(yàn)收褐健。團(tuán)隊(duì)成員從用戶的角度演示本期Sprint交付的故事如何被使用付鹿。這里有個(gè)經(jīng)驗(yàn)，對(duì)于無法演示的內(nèi)容，比如提高頁面的平均加載速度至3s以內(nèi)倘屹，拿出相應(yīng)的證據(jù)進(jìn)行“演示”即可银亲。
4、回顧總結(jié)纽匙，可能都覺得沒什么用务蝠，甚至團(tuán)隊(duì)成員在會(huì)上不知道說什么。我拿實(shí)際經(jīng)驗(yàn)告訴你烛缔，堅(jiān)持下去馏段，很有用！對(duì)團(tuán)隊(duì)來講長(zhǎng)期收益巨大践瓷！團(tuán)隊(duì)會(huì)慢慢變得更有干勁院喜、更有效率，輸出的代碼質(zhì)量也會(huì)提高晕翠。如果沒人發(fā)言喷舀，一定要逼著他們說。
Story & Task
說了這么多淋肾，終于到了跟Jira高度相關(guān)的部分了硫麻。在（一）中我們只簡(jiǎn)單提了Story是用戶故事，現(xiàn)在是時(shí)候詳細(xì)說明一下了樊卓。
用戶故事拿愧，是從業(yè)務(wù)及用戶角度出發(fā)，描述產(chǎn)品可以完成哪些事情的簡(jiǎn)要說明碌尔，每一條用戶故事都應(yīng)具備用戶價(jià)值浇辜。書寫正確的用戶故事，是進(jìn)行敏捷開發(fā)的重要一步唾戚。缺乏經(jīng)驗(yàn)的產(chǎn)品負(fù)責(zé)人往往把用戶故事當(dāng)成團(tuán)隊(duì)成員要做的事情柳洋，而不是用戶要做的事情。
舉個(gè)例子颈走，一個(gè)不合格的用戶故事：
“在數(shù)據(jù)庫中增加一個(gè)賣家聯(lián)系方式字段并展示在前臺(tái)頁面上”
這個(gè)做了給誰用的膳灶？怎么用咱士？有什么用立由？
對(duì)比一下合格的寫法：
“賣家可以在管理后臺(tái)填寫聯(lián)系方式，讓使用App的買家在遇到問題時(shí)能及時(shí)聯(lián)系專家”序厉。
在這個(gè)合格的用戶故事中锐膜，包含了3個(gè)要素：用戶、行為弛房、目標(biāo)/價(jià)值道盏。“某人可以做某事以達(dá)到某種目標(biāo)”，或者“某人可以做某事以創(chuàng)造某種價(jià)值”荷逞。
用戶故事言簡(jiǎn)意賅媒咳、目標(biāo)清晰即可，不需要种远、也不應(yīng)該寫得非常詳細(xì)涩澡。只要能達(dá)到目標(biāo)/創(chuàng)建價(jià)值，在細(xì)節(jié)上采取什么方式都不重要坠敷，團(tuán)隊(duì)成員要做的是以用戶故事作為指引妙同，協(xié)力找出投入產(chǎn)出比最高的解決方案。太詳細(xì)的用戶故事膝迎，只會(huì)限制團(tuán)隊(duì)的創(chuàng)造力粥帚，并把團(tuán)隊(duì)的注意力吸引到“執(zhí)行命令”而非“創(chuàng)造用戶價(jià)值”上。
Task則是將用戶故事分解之后得出的任務(wù)限次。比如剛剛舉的用戶故事的例子芒涡，就可以分拆成以下幾個(gè)任務(wù)：
后端增加聯(lián)系方式字段，并提供API供前端讀寫
Web前端增加填寫聯(lián)系方式的表單
App中顯示相應(yīng)賣家的聯(lián)系方式
一些不涉及用戶故事卖漫，但對(duì)團(tuán)隊(duì)有價(jià)值的工作拖陆，也可以列為“技術(shù)”任務(wù)。如“編寫測(cè)試環(huán)境部署腳本懊亡，讓測(cè)試人員可以主動(dòng)選擇測(cè)試分支”依啰。
估算
把估算單獨(dú)拿出來說，是因?yàn)樵谕ㄟ^Jira實(shí)踐Scrum敏捷開發(fā)時(shí)店枣，估算是相當(dāng)重要卻又很容易被誤用的一環(huán)速警。
對(duì)任務(wù)做估算的目的是為了對(duì)工作量有大致的預(yù)判，從而在有限的時(shí)間內(nèi)交付盡可能多的用戶價(jià)值（而不是開發(fā)工作量）鸯两，更不是為了對(duì)項(xiàng)目的時(shí)間節(jié)點(diǎn)進(jìn)行精確的控制闷旧。團(tuán)隊(duì)的生產(chǎn)速率基本是固定的，而具體到每個(gè)開發(fā)任務(wù)的工作量也都是基本固定的钧唐，所以只要團(tuán)隊(duì)都在持續(xù)且高效的輸出價(jià)值就足夠了忙灼。妄圖以強(qiáng)制的deadline讓團(tuán)隊(duì)成員持續(xù)加班，結(jié)果只能是幸福感降低钝侠，然后是效率降低该园，然后要么是交付物的質(zhì)量下降要么是交付物的范圍縮減，最后團(tuán)隊(duì)分崩離析帅韧。
估算一般有3種方法：小時(shí)數(shù)里初，點(diǎn)數(shù)，任務(wù)數(shù)忽舟。小時(shí)數(shù)過于精細(xì)双妨，而且容易陷入精打細(xì)算的誤區(qū)淮阐；任務(wù)數(shù)過于籠統(tǒng)，對(duì)任務(wù)分拆的粒度有較高的要求刁品；點(diǎn)數(shù)即Jira中的Story Points泣特，也是實(shí)踐下來比較推薦的估算方法。
點(diǎn)數(shù)的是為了比較出開發(fā)任務(wù)之間的相對(duì)大小挑随。隨便選一個(gè)看起來工作量比較小的任務(wù)作為1群扶，然后看其他任務(wù)是這個(gè)任務(wù)的幾倍，遇到比這個(gè)任務(wù)還要小的就算0.5镀裤。在估算點(diǎn)數(shù)的時(shí)候竞阐，只能在0.5/1/2/3/5/8/15/20/30中選擇，甚至30都不應(yīng)該被使用暑劝，當(dāng)一個(gè)任務(wù)的工作量是另一個(gè)任務(wù)的30倍的時(shí)候骆莹，這個(gè)任務(wù)一定可以被分解成更具體的任務(wù)。這么規(guī)定的原因還是因?yàn)槲覀円鹊氖窍鄬?duì)大小担猛，在估算時(shí)一個(gè)任務(wù)是18點(diǎn)還是19點(diǎn)幕垦，沒有什么區(qū)別。
可以看到點(diǎn)數(shù)只是一個(gè)相對(duì)值傅联，沒有單位先改。在實(shí)踐中，團(tuán)隊(duì)成員剛開始進(jìn)行估算時(shí)很容易陷入1點(diǎn) = xx小時(shí)的誤區(qū)蒸走，先估計(jì)小時(shí)數(shù)仇奶，然后再把小時(shí)數(shù)換算成點(diǎn)數(shù)。作為Scrum Master比驻，要么努力糾正這種誤區(qū)并引導(dǎo)建立正確的觀念该溯，要么就讓團(tuán)隊(duì)成員用人天當(dāng)單位估算吧。
關(guān)于敏捷開發(fā)的基本概念和基礎(chǔ)知識(shí)介紹的差不多了别惦，其他一些像燃盡圖狈茉、控制圖、任務(wù)板之類的等用到再說吧掸掸。
本文同步發(fā)表微信公眾號(hào)：
簡(jiǎn)書
微信公眾號(hào)：不寫代碼的設(shè)計(jì)師不是好PM（ID：coding-designer）
