基于GitHub的敏捷學習方法之道與術
一、前言
1. 對時間的敬畏
需要好多年才能懂得，***不是去震驚世界，而是要像易卜生所說的，生活在世界上。
我們都一樣，渴望著建樹功勛、改變世界。可是伴隨著年歲的增長，卻發現夢想仍舊遙遠，而時間卻依然殘酷的流逝著，不會僅僅因為「你」而發生絲毫的改變。如《奇特的一生》當中所言，我對時間始終充滿著敬畏之心，***的方式也不過是奢求時間能夠跟自己做朋友，伴隨著我這也許注定樸實無華的一生，共同成長。
在我們一生所能做的事情里，睡眠占去1/3，此生只剩2/3，除去非做不可的基本生活維護成本之外，剩下的時間要么選擇浪費而荒度此生，要么瞄準目標而奮力向前，讓這一生不留遺憾。Follow your heart，你需要找到一些愿意為其付諸終身的「目標」，以這樣的姿態「生活在這世界上」。
2. 敏捷與個人成長
就像軟件開發一樣，一個人的成長也應該有自己的方法論。人的一生若是順風順水、一成不變，那未免太無趣了，正是由于世界的未知在等著我們去探索，不一樣的經歷才會讓人感到驚喜和有趣。想做的事情永遠都不會嫌多，就像柳比歇夫最開始是研究生物學的，卻在科學的道路上越走越遠，進而研究起了數學、物理、哲學，甚至于美學，而更關鍵的是，他在每一方面都做出了很大貢獻并且留下了諸多著作。
時間充當著Product Owner的角色在不斷向你提出各種各樣的需求，敏捷當中最重要的一大前提就是「擁抱變化」，而在「記錄時間這件小事兒」里面我提到的GTD流程便可以用于處理這源源不斷的需求，即收集、整理、執行、回顧，對應到敏捷當中的幾大會議，顯然也可以由個人完成，自己就是自己的IM&PM，當然也是BA&Dev&QA(當然不用擔心人格分裂)。
二、實踐之術
“我都沒想到怎么寫著寫著就把開頭寫成了雞湯文。但是咧，如果前面講的是「道」，那么接下來就會具體到基于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。
四、GitHub issues的進階用法
與此同時，新建issue還有更高級的用法，也就是通過ISSUE_TEMPLATE這樣一個模板來新建某個issue，從而更快地定位問題所在和解析自己的想法，最主要的是能夠輸出更具體的TODOs，即下一步行動的具體內容，這個還會在后面詳細解釋。
- issue和issue之間是可以通過#相互連接，甚至可以跨倉庫，被reference的issue也會出現在另外一邊的issue里面;
- 而通過#!符號是可以在comments里面直接新建一個issue ，這在思維爆炸的時候來得特別爽快;
- 你還可以隨意艾特你的小伙伴們，互相監督、互相學習或者給出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就可以讓你瞬間擁有日常敏捷工作的感覺了吧！
七、計劃與執行具體任務
1. 制定迭代計劃
首先，讓我們新建一個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，在里面寫寫對這件事情的總結和感想什么的，每次挪卡都充滿了敏捷的儀式感(認真臉)。
2. 進度的把控
GitHub在issues里面直接集成了Markdown的TODO語法，甚至于可以在渲染過后直接拖動某個item進行排序，而且可以在前面的勾選項中直接打勾 ☑ 標記為完成。不僅如此，完成之后這個issue還能直接顯示完成進度;前面所提到的Epic也能直接顯示子issues的完成情況即closed比例，兩者結合起來簡直不能再美好。
比如說拿來作為讀書列表的記錄就很不錯，每本書作為一個issue，還可以把章節劃分為具體的TODOs，結合估點追蹤自己看書的進度和速度，順便在comments底下做個筆記也不錯啊！
3. 專注當下
ZenHub還提供了一個基于GitHub Issues的To do 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，來得到一個比較直觀的總結和復盤。
其他輔助工具
- 看板：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一鍵導入，并且已經原生支持了pipeline和看板功能。當然，不限于工具或軟件，這一套方法論其實是可以運用在任何地方的，甚至于我們可以來做一個結合敏捷方法論的個人學習管理軟件也不錯。
但是于我而言，選擇在GitHub這樣一個公開環境下記錄學習的***一個動機就在于「開源」，很喜歡一句話，大意是「在這個互聯網時代，能限制住學習的只有你的求知欲」。
當你從互聯網這個廣闊的知識海洋當中汲取知識時，也應當有所輸出，即反哺到整個互聯網當中去。我會經常寫博客/筆記來總結、分享自己的所學，但是一篇文章誕生的背后往往還有很多其他知識和經驗的相互交融與沉淀。Issues · JimmyLv/jimmylv.github.io 這個列表里面的某個issues最終能否演變成一篇文章我不知道，但是基于GitHub開放式的學習歷程都會被這些issues如實地記錄著，任何一個想法都能追本溯源被找出最開始的緣由。
“相比于軟件開發這件小事兒，健康快樂地成長顯然要重要得多。—— 立青”
【本文是51CTO專欄作者“ThoughtWorks”的原創稿件，微信公眾號：思特沃克，轉載請聯系原作者】
