敏捷開發學習筆記

有一年多沒發博客了，離開IT行業後感受技術這塊快荒廢了，補一篇去年爲了原公司上Jira而學習敏捷開發的筆記，若有不當之處,請予指正。Jira相關的內容稍後整理髮布

PS：如下除Jira外其餘截圖均來自網絡或正版書籍，若有侵權請及時聯繫我刪除

1、先熟悉幾個敏捷概念

一、傳統和敏捷的區別（這裏的傳統開發指瀑布開發或計劃驅動開發）

（1）畫一幅畫

（2）造一輛車

（3）火炮和導彈

（4）概念性比較

二、Project（項目）

JIRA的項目是根據你的企業組織須要定製的，是問題的集合。例如一個JIRA項目能夠是:

一個軟件研發項目

一項市場推廣活動

一個技術服務/幫助臺系統

一個需求管理系統

一個網站需求調查系統

Jira裏的項目和禪道里的項目概念並不徹底相同：禪道里，產品和項目被明確的區分開。產品主要是管理需求、計劃和發佈。項目主要是管理任務開發需求。禪道里，項目對應的是敏捷開發裏的迭代。項目能夠看作產品的迭代管理，一個項目更新產品的一個新版本。一個產品可能分解成多個小項目，由一個或多個項目組去完成。

三、Version（版本）

在一個項目上，通常會有多個版本，如：1.0alpha、1.0beta、1.0、1.二、2.0。

（1）建立問題時會涉及到兩個Version（版本）字段：

影響版本：能夠清晰地反映出這個問題在哪一個版本中出現錯誤。例如, 一個軟件的缺陷可能影響了產品的1.1和1.2版。

修復版本：能夠反映出報告的問題將在哪一個版本，或已經在哪一個版本中修復了。例如, 軟件缺陷影響了產品的1.1和1.2版，這個缺陷已經在2.0版中修復了。注意沒有修復版本的問題會被歸類到'未規劃'。

（2）版本能夠有3個狀態: 已發佈,未發佈或已歸檔。版本能夠設置發佈日期,而JIRA會自動將到期而尚未發佈的版本高亮顯示出來，並標註上'超期'標誌。

後邊會詳細講解如何建立版本

下圖是禪道的版本頁面

四、Scrum

Scrum並非構建產品的一個流程或者一門技術；而是一個使用各類流程和技術開發和維持複雜產品的框架，是一個增量的、迭代的開發過程。Scrum使你更清楚地瞭解產品管理和開發實踐的相對有效性，從而能夠對其進行改進。Scrum 是一種團隊管理工做的方式，其將工做分解爲較小的工做單元，並在週期性固定的時間段內持續地交付工做單元。週期性固定的時間段，稱爲迭代（Iteration）或者衝刺（Sprint）。較小的工做單元，稱爲用戶故事（User Story）。

（1）Scrum和Kanban的區別

（2）Scrum包括3個角色、3個物件、4個活動、5個價值

3個Roles（角色）

1  Product Owner（產品負責人）

2  Scrum Master（敏捷教練）       Pig（源自火腿和雞蛋的故事）

3  Scrum Team（開發團隊）

其餘角色：Customer（用戶及相關人員）               Chicken

Executive Management（非技術管理者）     （源自火腿和雞蛋的故事）

3個Artifacts（物件）

1  Product Backlog（產品待辦列表）

2  Sprint Backlog（迭代待辦列表）

3  Product Increment（產品增量）

其餘物件：Burndown Chart（燃盡圖）：包含Sprint Burndown Chart（迭代燃盡圖）和Release Burndown Chart（發佈燃盡圖）

4個Events（活動）

1  Sprint Planning Meeting（迭代計劃會議）

2  Daily Scrum Meeting（每日站會）

3  Sprint Review Meeting（迭代評審會議）

4  Sprint Retrospective Meeting（迭代回顧會議）

其餘活動：Product Backlog Refinement（產品待辦列表梳理會議）

     Project Planning Meeting（項目計劃會議）

Product Release Planning Meeting（產品發佈計劃會議）

5個價值

1  承諾 – 願意對目標作出承諾

2  專一 – 把你的心思和能力都用到你承諾的工做上去

3  開放 – Scrum 把項目中的一切開放給每一個人看

4  尊重 – 每一個人都有他獨特的背景和經驗

5  勇氣 – 有勇氣作出承諾，履行承諾，接受別人的尊重

PS：Product Backlog（產品Backlog）和Sprint Backlog（迭代Backlog）的區別：

（3）Scrum步驟圖

（4）用代碼來描述Scrum完整框架

五、Sprint（衝刺）

雖然Sprint字面意思是短跑衝刺，但Scrum中的Sprint無對應中文翻譯，一個短的"迭代"週期稱爲一個Sprint，這個迭代能夠是一個開發階段/小開發計劃/小目標，一個個 sprint 首位相連，構成一個項目。每一個Sprint的長度最好保持一致，建議是2到4周。

（1）衝刺規劃

（2）衝刺時間

下圖是爲何要採用2到4周這個較短Time box（時間盒）的緣由：

當到達結束時間時，每一個Sprint都要完成一個潛在可發佈Product Increment（產品增量），而且要達到Scrum團隊一致認同的完成定義。

（3）關於延期

要在Sprint計劃中考慮可能延期的問題，而且制定解決方案，好比：

團隊增長人員（Scrum不建議這麼作）；

加班（Scrum不建議這麼作，違背Scrum原則）；

拆分Story（Scrum不建議這麼作）：將級別低的PBI從當前Sprint中移動到Backlog中，在以後的Sprint中完成（下邊Story Point一節會講到）；

由專人處理干擾Sprint的突發狀況（Scrum建議這麼作）。

（4）異常終止迭代

這裏須要注意一個"異常終止"的概念，當有重大的經濟事件發生時，Product Owner（產品負責人）能夠終止這次迭代，好比競爭對手的某些舉措或研發費用發生變化等緣由，但終止迭代會影響團隊士氣和以前迭代的Product Increment（產品增量）

六、Swimlane（泳道）

泳道最開始是在UML中出現，叫swimlane也有人叫partition，除了縱向的按照狀態定義的列，還可使用橫向的泳道區分，好比區分一個團隊中的多個產品

下圖是Jira中Sprint看板，用來展現Sprint（衝刺）和Swimlane（泳道），具體位置在【項目】-【活動的Sprint】中能夠查看，豎列表示泳道，可拖拽其中的PBI（產品任務列表）。這裏的【活動的Sprint】是Scrum三物件中的Sprint Backlog（迭代Backlog）

下圖是Kanban中的Swimlane（泳道），操做和Sprint相似

其實GitLab中也有相似的看板和泳道

七、Time box（時間盒）

（1）概念

Time box（時間盒）是一種管理方法，即在預算時間內對完不成的功能進行刪減或者延遲，而不是拖延預算的時間。用咱們熟悉的術語就是"後牆不倒"。 一個"Time box"是一個比較短並且固定長度的時間段。在這個時間段中，團隊成員要爲知足一個特定的目標作出努力。這個目標能夠是一批功能需求或技術需求，也能夠是知足一個發佈目標（例如，beta測試應支持150個用戶），還能夠是完成一個可運行的原型，等等。Scrum中全部用到時間的地方都適用於Time box（時間盒），好比：每次迭代必須在固定的時間內完成、每一個會議必須在規定時間內結束、會議上發現的問題作出的決策必須在必定時間內完成。

（2）克服"帕金森定律"

帕金森定律是指，"無論有多少時間，工做都會擴展，直至耗盡全部的時間"。在以產品開發階段定義里程碑的項目中，幾乎總能看到帕金森定律的做用。這也被稱爲學生綜合症 —— "必定要等到考試前一刻，才能結束功課的複習"。短的固定長度的時間盒，將迫使團隊，在一段時間，聚焦在有限的功能。相比幾個月後的里程碑，一到數週後的交付目標顯然更容易引起重視和緊迫感。一方面，這下降了項目進度風險發生的可能；另外一方面也下降了進度風險發生時的影響，項目結束時，至少能夠交付已完成迭代的內容，相對錯過最終的發佈週期，如期交付80%內容（一般也是最重要的80%），顯然是更成功的。

八、Backlog（區分優先級的功能列表）

敏捷須要維護一份詳盡的PBI。這份列表經常要求 scrum 持有人（通常是項目負責人）對全部待開發事項有深刻了解，而且可以把待開發事項分解成更爲細緻的任務。

Jira的【Backlog】頁面中存放有全部剩餘未完成的故事，包括待開發任務和任務優先級等信息，且由項目負責人維護。【Backlog】頁面下方的Backlog子類並非Scrum三物件中的Product Backlog（產品Backlog），由於Product Backlog不包含"故事"（此處有詳細解讀：https://blog.csdn.net/cpongo4/article/details/89141979）。在任何狀況下，敏捷開發中的故事是經過會話瞭解需求的一種行爲方式（故事="卡片，會話和確認"），自己並非在列表裏的一件事情。若是確實要在Jira中引入Product Backlog，須要額外使用牆貼或者Excel配合Jira使用

梳理Backlog中的PBI

九、Issue（問題）/ Epic（史詩）/ Sprint（衝刺）/ Version（版本）之間關係

Epic是Issue的一種，Sprint是一期迭代開發計劃，相似PRD（產品需求文檔）的做用，每期Sprint裏會放各類Issue。某些Issue一塊兒發佈時，能夠添加到一個Version用來管理這一次部署的實際內容。若是開發週期和發版週期徹底一致的話，Sprint和Version裏就會有相同的Issue。一個Sprint能夠屬於多個Version，一個Version也能夠屬於多個Sprint

十、Story（用戶故事）

用戶故事是從須要該新功能的用戶角度來說述的短小簡單的描述。當一個故事很是龐大時就會變成Epic（史詩），在Jira中史詩是不會直接放入Sprint中進行開發的。故事的下一級別是任務。舉個例子：拿微信產品來講的話，用戶的分享行爲就是一個 Story，這個 Story 還能夠被拆分爲分享到朋友圈、分享給好友兩個Task（任務）。

經過經典的"三段論"（見下方）描述和漸進的細節探索，用戶故事實現了需求描述的敏捷化；

經過優先級排序和故事點的有效應用，用戶故事實現了需求到開發的鏈接；

經過驗收標準的漸進明確，用戶故事實現了需求與測試的鏈接。

一個Sprint中Story不要太多，但一個Story儘可能在一個Sprint中完成，如沒法完成則須要拆分這個Story

（2）故事和需求的區別

（3）用戶故事三要素（"三段論"描述）

下圖是一個故事模板

舉個例子：做爲一個"網站管理員"，我想要"統計天天有多少人訪問了個人網站"，以便於"個人贊助商瞭解個人網站會給他們帶來什麼收益。"

（4）3C原則（出自Ron Jeffries 2001）

卡片（Card）：用戶故事通常在小卡片上寫着故事的簡短描述，工做量估算等。

交談（Conversation）：用戶故事背後的細節來源於和客戶或者產品負責人的交流溝通。

確認（Confirmation）：經過驗收測試確認用戶故事被正確完成。

（5）用戶故事的標準：INVEST原則（出自《User Stories Applied For Agile Software Development》-Mike Cohn 2004）

在現實工做中，會存在一小部分很是複雜的用戶需求，很難同時徹底知足這6個原則，但至少要知足可估算、規模小、可驗證，即EST>INV

（6）故事拆分方法：

路徑拆分法：例如微信支付方式和過程

按接觸點拆分：例如IE內核瀏覽器和非IE內核瀏覽器

按數據類型或格式拆分：例如經過CSV、XML、Excel格式導入數據

按規則拆分：例如導航分爲時間最短和距離最短

按探索路徑拆分：例如用原有技術和探索新技術開發用戶故事

（7）可視化故事牆

就是咱們在Jira的【項目】-【活動的Sprint】中看到的【泳道】

默認只有3個狀態：To Do、Doing、Done

能夠根據實際狀況改成：待開發、開發中、待測試、測試中、測試完成

更完善的狀態：需求池、初稿、評審稿、待開發、開發中、待測試、測試中、待上線、已上線

十一、Story Point（故事點）

故事點是一個度量單位，用於表示完成一個產品待辦項或者其餘任何某項工做所需的全部工做量的估算結果。影響工做量的全部因素包括：要開展的工做的數量、工做的複雜度、要開展的工做中存在的任何風險或不肯定性。在用故事點估算時，必需要考慮以上每個因素。

在某些教材中故事點用於生產能力的分配：

Jira中的故事點

（1）下邊是一種估算一個Sprint週期全部故事點的方式：

因爲Srum團隊有時會受到外界因素的干擾，好比須要處理客戶反饋的一些BUG，這樣就要使用"Yesterday's weather（昨日天氣）"從新計算故事點：

這樣得出一個合理的故事點，須要注意的是前一個迭代產生的BUG要放在最優先級解決，因此要謹慎估算目前迭代的故事點

咱們從Jira的Backlog中取出知足故事點的故事放入到本次Sprint迭代中去， 注意：從上到下優先級從高到低

具體操做是在【項目】-【Backlog】頁面中將下方Backlog中的PBI拖動到上方Sprint中

（2）下邊是一種估算單個故事故事點的方式：計劃紙牌

計劃紙牌是基於Wide band Delphi（寬帶德爾菲）法的估算技能、也是以共識爲基礎的工做量估算技能。有時候也稱爲 Scrum 撲克，每每在故事點和開發用戶故事中用來估算相對工做量。

斐波那契數列經常使用來衡量計劃撲克的價值（即 0、一、二、三、五、8…，這個數列從第3項開始，每一項都等於前兩項之和），這裏會用另外一種更常見數列（?、0、1/二、一、二、三、五、八、1三、20、40、100）。

具體使用實例見這裏：http://www.uml.org.cn/SoftWareProcess/201108264.asp

如下是大概描述：

當一個故事估算出故事點後，再用"相對估算法"估算其餘故事的故事點

PS：幾個問題

Q：修 Bug 算不算工做量？

A：這點不一樣團隊的處理不一樣。比較激進的 Scrum 團隊認爲修 Bug 不該該算點數（Point），由於 Bug 原本是不該該存在的，是開發的失誤致使了 Bug。而在評估一個功能點時，所給出的點數，是指將此功能點開發至正確提交時的所有投入，修 Bug 已經包括在裏面了。這樣說雖然有必定道理，不過在實際操做中很難實現。具體是否算點數，是否把修 Bug 放在每一個 Sprint 的計劃中，還要團隊本身定奪。

十二、Definition of Done（完成的定義或標準）

"完成"的定義通常在在Sprint Planning Meeting中由整個團隊肯定。"完成"涉及到Scrum的方方面面。下邊大致說明一下"完成"的定義。

（1）Sprint的DoD：

全部完成的用戶故事獲得PO的內部驗收

全部代碼獲得靜態分析，糾正最高級別的不符合項

全部新增代碼獲得人工評審

全部完成的用戶故事都有對應的測試用例

（2）每日的DoD：

搭建每日構建環境，晚上自動靜態代碼檢查、編譯、部署和測試，每日修復前一日構建和測試發現的缺陷和問題。

天天下班前，至少checkin代碼一次，checkin的change-log要填寫清晰

當天的代碼必須在當天或者第2天進行人工評審

checkin的代碼有通過自動化單元用例

當天持續集成、構建環境中的問題，請當天解決

（3）Story的DoD

用戶故事最終的描述符合INVEST

用戶故事獲得測試用例的對應覆蓋

用戶故事獲得對應的自動化測試用例

用戶故事獲得用戶表明試用並初步承認

用戶故事獲得PO的內部驗收

（4）項目的DoD：

注意看下邊的Sprint看板，綠色的Story（故事）TEST-6已經被劃掉，由於其中的Sub Task（子任務）TEST-7已經處於完成狀態，而故事TEST-10因爲其中的子任務沒有所有完成，因此還處在迭代中

DoD總結成三條：

代碼寫完了沒？

Bug除光了沒？

產品能夠上線了沒？

1三、Burndown Chart（燃盡圖）

Scrum三物件中的一個，是在項目完成以前，對須要完成的工做的一種可視化表示。燃盡圖有一個Y軸（工做）和X軸（時間）。理想狀況下，該圖表（這裏使用了Story Point做爲參考值）是一個向下的曲線，隨着剩餘工做的完成，"燒盡"至零。

以衝刺燃盡圖爲例：燃盡圖的元素有

橫座標：sprint的工期（以天計算）。

縱座標：sprint 內剩餘任務的總預計工時（以小時標記）。

計劃曲線：理想狀況下的任務進展曲線（圖中的黑色線），做爲參考之用。

實際曲線：任務的實際進展曲線（圖中的紅色線）。

燃盡圖就是天天將項目中全部任務剩餘工時的總和計算一下，造成座標（圖中的紅色點），而後逐次把點鏈接起來，造成剩餘工做量的趨勢線。

燃盡圖的解讀規則：

（1）若是實際曲線在計劃曲線如下，說明進展順利，有比較大的機率定期完工；

（2）若是實際曲線在計劃曲線以上，說明有比較大的機率延期，這是就須要關注進度了。

Burndown Chart（燃盡圖）和Gantt（甘特圖）的區別：

甘特圖須要嚴格的設置過任務的起止時間和前置關係，是一種控制式的管理，因此非敏捷項目也可使用甘特圖。而燃盡圖則更關注於作完總體的項目還剩下多少時間，因此燃盡圖是敏捷獨有的概念。甘特圖適用於項目初期和中期，用於計劃和檢查進度的完成狀況。燃盡圖用於項目開始到項目結束，用於提醒你們項目進度和要完成的任務。

1四、Information Radiator（信息發射源）

在現實中，敏捷團隊工做空間的各類顏色的便箋，白板，各類圖表等，稱爲信息發射源 Information Radiator，它能夠很好的用於項目的溝通、展現項目的狀態。在Jira中的表現形式就是Sprint中的泳道（見前述）、項目的報告（以下圖）

1五、鬆散敏捷

"鬆散敏捷"並不是一個術語，它用來形容那種"非純"敏捷團隊。因爲"純度"不一樣，不一樣團隊從 Scrum 中汲取的內容不一樣。不過通常而言，只要聲稱 Scrum 的團隊，必定會有站會（Stand Up Meeting）。配合站會，就會有 Backlog 和 Dashboard。其餘的會議、工具，甚至角色分配，就不必定了。不少"鬆散 Scrum"團隊，根本沒有 PO，SM 概念，也不關心豬和雞的區別。