基於 GitHub 的敏捷學習方法之道與術

時間 2019-11-15

原文原文鏈接

原文首發於我的博客：基於 GitHub 的敏捷學習方法之道與術 - 呂立青的博客git

「持續行動，持續反思，持續進步。」—— via. 敏捷學習宣言github

前言

對時間的敬畏

須要好多年才能懂得，最好不是去震驚世界，而是要像易卜生所說的，生活在世界上。網絡

咱們都同樣，渴望着建樹功勳、改變世界，但是伴隨着年歲的增加，卻發現想要實現的夢想依然那麼遙遠，而時間卻依然殘酷得流逝着，不會僅僅由於「你」而發生絲毫的改變。如《奇特的一輩子》當中所言，我對時間始終充滿着敬畏之心，最好的方式也不過是奢求時間可以跟本身作朋友，伴隨着我這也許註定樸實無華的一輩子，共同成長。app

在咱們的一輩子所能作的事情裏邊兒，睡眠佔去 1/3，今生只剩 2/3，除去非作不可的基本生活維護成本事後，剩下的時間要麼選擇浪費而荒度今生，要麼選擇目標而奮力向前，讓這一輩子不留遺憾。Follow your heart，你須要找到一些願意爲其付諸終身的「目標」，以這樣的姿態「生活在這世界上」。框架

敏捷與我的成長

就像軟件開發同樣，一我的的成長也應該要有本身的方法論。人的一輩子如果順風順水一成不變的話，那未免太無趣了，正是因爲世界的未知在等着咱們去探索，不同的經歷纔會讓人感到驚喜和有趣。想作的事情永遠都不會嫌多，就像柳比歇夫最開始是研究生物學的，卻在科學的道路上越走越遠，進而研究起了數學、物理、哲學，甚至於美學，而更關鍵的是，他在每一方面都作出了很大貢獻而且留下了諸多著做。工具

時間充當着 Product Owner 的角色在不斷着向你提出各類各樣的需求，敏捷當中最重要的一大前提就是「擁抱變化」，而在「記錄時間這件小事兒」裏面我提到的 GTD 流程即可以用於處理這源源不斷的需求，即收集、整理、執行、回顧，對應到敏捷當中的幾大會議顯然也能夠由我的完成，本身就是本身的 IM & PM，固然也是 BA & Dev & QA。（固然不用擔憂人格分裂，😂）學習

實踐之術

我都沒想到寫着寫着怎麼就把開頭寫成了雞湯文，[捂臉](./wechat/emoji.jpg)。可是咧，若是說前面的講的是「道」，那麼接下來就會具體到基於 GitHub 的「術」即各類實踐了。測試

首先呢，讓咱們從需求出發，從市面上來尋找一款符合敏捷的學習軟件，別想了，固然是沒有的。對於一名程序猿來講，最理想的答案其實就是 GitHub，做爲全球最大的程序猿交友網站，GitHub 自己以及圍繞 GitHub 的各類插件使得其項目管理能力其實遠比你所能想象的厲害得多。網站

收集：需求無時無刻，無處不在，anywhere anytime
整理：as BA 即分析，Elaboration & Estimation & IPM => 肯定 MVP & Efforts
執行：as Dev & QA，Developing & Testing & Review/Sign-Off
回顧：Retrospection，Introspection，持續反思，持續進步…

經過 GitHub Issues 收集需求

首先你能夠給本身建一個 GitHub 倉庫做爲主頁，好比個人 JimmyLv/jimmylv.github.io: Agile Learning based on GitHub issues 其實最開始就是從我的博客的主倉庫發展而來。那麼，如何快速得收納本身的想法呢？以解決問題爲導向，固然就是有什麼需求就直接給本身的 repo 建一個 issue 做爲 Story Card，而後了卻這個需求的最終形態就是 close 掉這個 Issue，好比我要寫這篇文章就始於這個 issue：基於 GitHub 的敏捷學習方法總結 · Issue #36 · JimmyLv/jimmylv.github.io。插件

GitHub issues 的進階用法

與此同時，新建 issue 還有更高級的用法，也就是經過 ISSUE_TEMPLATE 這樣一個模板來新建某個 issue，從而更快地定位問題所在和解析本身的想法，最主要的是可以輸出更具體的 TODOs，即下一步行動的具體內容，這個還會在後面詳細解釋的。

issue 和 issue 之間是能夠經過 # 相互鏈接的，甚至能夠跨倉庫，被 reference 的 issue 也會出如今另一邊的 issue 裏面；
而經過 #! 符號是能夠在 comments 裏面直接新建一個 issue 的，這在思惟爆炸的時候來得特別爽快；
你還能夠隨意艾特你的小夥伴們 @linesh-simplicity @Yaowenjie ，互相監督、互相學習或者給出 Constructive Feedback 之類的，😂；
更甚至於，如果在 Intellij 裏面關聯了 GitHub，就能夠在 git commit 信息裏面直接看到你所要關聯的 issues 列表了。

這種方式彷彿學習中的大腦，神經網絡被連通了的感受。

移動端的解決方案

而在移動端則能夠經過 GitDo 這個 App 來輕鬆新建和管理本身的 Issues，沒錯，就是有人把 GitHub issues 作成了一個 Todos 類 App，還作得很漂亮功能很完善。只惋惜不知道這軟件最近爲啥被降低了，傷感，我就又從新把滴答清單（TickTick）做爲本身的萬能收集箱了，以後再把比較重要的、須要進一步追蹤的事項添加到 GitHub issues 裏面來。

整理你的 GitHub Issues

大膽地把 issues 做爲你的我的需求列表吧，須要解決的問題能夠大到作一個開源項目，或者小到讀一本書、寫一篇文章。對於比較大的需求，你還能夠將其轉化爲 Epic 而後把拆分事後的小 issues 們加入到這個列表裏面來。

而 GitHub (with ZenHub) 強大的 issues 管理能力絕對會讓你的迭代工做變得層次分明，使用 GitHub 新出的 Projects 特性或者使用 ZenHub 的 Boards 應該就可讓你瞬間有了平常敏捷工做的感受了吧！

計劃與執行具體任務

制定迭代計劃

首先呢，讓咱們來新建一個 Milestone 來制定計劃，也就是決定在一個 Iteration 裏面你須要完成哪些 issues。在這裏我所制定的階段性計劃週期爲一個月，固然你也能夠勤快一點以 2 周做爲一個 Iteration，享受一下本身的計劃要完不成了這個 Milestone 就要廢了，無法像「時間」這個一輩子的朋友交付全部需求的快感吧，🙂

固然咯，通常我會在月初作計劃的時候給本身準備專門的時間來作 Elaboration，把 Backlog 裏面的卡拖到 Rethink/Plan 這一列，而後通過分析和詳細輸出 TODOs 以及所對應的估點 points 以後即可以將其拖到 Ready For Todo 了，通常我給本身估的點數就是完成這件事情所須要的時間，一小時即對應一個 point。

這樣你就能夠愉快得選擇 Filter Issues by Milestone 專一於當前 Iteration，專一於 In Progress 這一列所要作的事情，而且垂涎於 Ready For Todo 裏面將要作的事情，每次作完還能夠放到 Review/SignOff 裏面寫寫對這件事情的總結和感想什麼的，每次挪卡都充滿了敏捷的儀式感（認真臉）。

進度的把控

GitHub 在 issues 裏面直接集成了 Markdown 的 TODO 語法，甚至於能夠在渲染事後直接拖動某個 item 進行排序，並且前面的勾選項能夠直接打勾 ☑️ 標記爲完成，並且完成以後這個 issue 還能直接顯示完成進度；前面所提到的 Epic 也能直接顯示子 issues 的完成狀況即 closed 比例，二者結合起來簡直不能再美好，😂

好比說拿來做爲讀書列表的記錄就很不錯，每本書做爲一個 issue 還能夠把章節劃分爲具體的 TODOs，結合估點能夠追蹤本身看書的進度和速度，順便在 comments 底下作個筆記也不錯啊！

專一當下

並且 ZenHub 還提供了一個基於 GitHub Issues 的 Todo List，你能夠只用關注 Today 這一個列表，專心於當前要完成的任務。並且更有趣的是這個 list 能夠加入 GitHub 的任何 issues，也就是說是全局的，因此你就能夠加入不少在 GitHub 上經過 issues 寫的 blog，好比徐飛的這篇文章流動的數據——使用 RxJS 構造複雜單頁應用的數據邏輯 · Issue #38 · xufei/blog，被我加入到了 Reading 的列表當中。

與此同時我還會使用 Toggl 來記錄每一個 issue 具體實施的時間，以便於在時間花費上可以得到及時的反饋。這樣作會讓你真切地感覺到時間的流逝，而在回顧記錄的時候也可以進行總結分析，從而在下一次的計劃當中可以更精確地預估時間（點數）。比方說這篇文章我估了 5 個點如今已經寫了 4.5 hours 了，不過這是另一個大話題，能夠參考記錄時間這件小事兒這個 issue。

迭代回顧與總結分析

ZenHub 也提供了 Burndown 和 Velocity tracking 圖，能夠得出這個迭代整體的完成狀況，看看跟預期有何不一樣；也能夠跟其餘迭代進行對比，看看有何不一樣的地方，而後進行下一步的具體分析。

還能夠根據 GitHub 和 Toggl 裏面的數據進行彙總和分析，下面這個表格就是我在 11 月這個迭代完成後一部分 issues 的具體 Estimation Points 和 Time Efforts，再結合 issues 裏面所記錄下的各類筆記和 references，就能夠有一個比較直觀的總結和覆盤了。

Number & Description	Estimation Points	Time Efforts
#85 記錄時間這件小事兒	3	04:26:18
#96 如何對時間進行分類？	8	03:00:09
#102 創建我的 Wiki 系統	2	02:53:56
#101 技術雷達宣講：enzyme 測試框架	5	06:11:19
#90 Working time improvement	1	33:27 min
#97 如何使用 XX 的標籤系統？	1	25:21 min

其餘輔助工具

看板：as Jira/Trello，可視化當前進度 => GitHub Issues group by @Projects / 日曆 in @滴答清單；若是你不想用 ZenHub 能夠試試 Gitlo 能夠在 GitHub issues 和 Trello 之間進行雙向同步。
晨間日記/每日回顧：as Stand-Up，只用關注 Timeline/Done/Todo/Blocker 以及當天的心情/天氣等等，使用 @格志日記的一個特色就是能夠經過問答的方式對一天進行回顧。
時間記錄：@時間塊的優勢在於記錄很是得簡單、快捷，用戶評論最省時間的時間記錄工具沒有之一，推薦新手能夠試試。但因爲我的須要更加詳細的記錄細節和報告分析，以及多平臺（包括 Chrome Extension）的支持，從而選擇了 @Toggl。
白噪聲：做爲一款時間記錄工具，@Toggl 自己就支持 Pomodoro 的 25 分鐘提示，而做爲專一力輔助的白噪聲軟件我在手機上用的 @潮汐，電腦上則選擇了 @Noizio。

後話

也許你很喜歡這個解決方案但又不太想公開本身的 issues 列表，那能夠試試 GitHub 的 private repo（須要付費），免費的能夠試試 GitLab，支持從 GitHub 一鍵導入，而且已經原生支持了 pipline 和 kanban 功能。固然咯，不限於工具或軟件，這一套方法論實際上是能夠運用在任何地方的，甚至於咱們能夠來作一個結合敏捷方法論的我的學習管理軟件也不錯嘛！

可是於我而言，選擇在 GitHub 這樣一個公開環境下記錄學習的最大一個動機就在於「開源」，很喜歡一句話，大意是「在這個互聯網時代，能限制住學習的只有你的求知慾」。當你從互聯網這個廣闊的知識海洋當中汲取知識的時候，也應當有所輸出到即反哺到整個互聯網當中去。我會常常寫博客/筆記來總結分享本身的所學，可是一篇文章誕生的背後每每還有不少其餘知識和經驗的相互交融與沉澱。Issues · JimmyLv/jimmylv.github.io 這個列表裏面的某個 issues 最終可否演變成一篇文章我不知道，可是基於 GitHub 開放式的學習歷程都會被這些 issues 如實地記錄着，任何一個想法都能追本溯源被找出最開始的原因。