文／ThoughtWorks 呂靖
持續(xù)行動毅该，持續(xù)反思，持續(xù)進步督怜。—— via. 敏捷學習宣言
前言
對時間的敬畏
需要好多年才能懂得狠角，最好不是去震驚世界号杠，而是要像易卜生所說的，生活在世界上丰歌。
我們都一樣究流，渴望著建樹功勛辣吃、改變世界》姨剑可是伴隨著年歲的增長神得，卻發(fā)現(xiàn)夢想仍舊遙遠，而時間卻依然殘酷的流逝著偷仿，不會僅僅因為「你」而發(fā)生絲毫的改變哩簿。如《奇特的一生》當中所言，我對時間始終充滿著敬畏之心酝静，最好的方式也不過是奢求時間能夠跟自己做朋友节榜，伴隨著我這也許注定樸實無華的一生，共同成長别智。
在我們一生所能做的事情里宗苍，睡眠占去 1/3，此生只剩 2/3薄榛，除去非做不可的基本生活維護成本之外讳窟，剩下的時間要么選擇浪費而荒度此生，要么瞄準目標而奮力向前敞恋，讓這一生不留遺憾丽啡。Follow your heart，你需要找到一些愿意為其付諸終身的「目標」硬猫，以這樣的姿態(tài)「生活在這世界上」补箍。
敏捷與個人成長
就像軟件開發(fā)一樣，一個人的成長也應該有自己的方法論啸蜜。人的一生若是順風順水坑雅、一成不變，那未免太無趣了衬横，正是由于世界的未知在等著我們?nèi)ヌ剿鞴粒灰粯拥慕?jīng)歷才會讓人感到驚喜和有趣。想做的事情永遠都不會嫌多冕香，就像柳比歇夫最開始是研究生物學的蛹尝，卻在科學的道路上越走越遠后豫，進而研究起了數(shù)學悉尾、物理、哲學挫酿，甚至于美學构眯，而更關鍵的是，他在每一方面都做出了很大貢獻并且留下了諸多著作早龟。
時間充當著 Product Owner 的角色在不斷向你提出各種各樣的需求惫霸，敏捷當中最重要的一大前提就是「擁抱變化」猫缭，而在「記錄時間這件小事兒」里面我提到的GTD流程便可以用于處理這源源不斷的需求，即收集壹店、整理猜丹、執(zhí)行、回顧硅卢，對應到敏捷當中的幾大會議射窒，顯然也可以由個人完成，自己就是自己的 IM & PM将塑，當然也是 BA & Dev & QA（當然不用擔心人格分裂）脉顿。
實踐之術
我都沒想到怎么寫著寫著就把開頭寫成了雞湯文。但是咧点寥，如果前面講的是「道」艾疟，那么接下來就會具體到基于 GitHub 的「術」，即各種實踐敢辩。
首先蔽莱，讓我們從需求出發(fā)，從市面上來尋找一款符合敏捷的學習軟件责鳍，別想了碾褂，當然是沒有的。對于一名程序猿來說历葛，最理想的答案其實就是 GitHub正塌，作為全球最大的程序猿<del>（交友）</del>網(wǎng)站，GitHub 本身以及圍繞 GitHub 的各種插件使得其項目管理能力遠比你所能想象的厲害得多恤溶。
- 收集：需求無時無刻乓诽，無處不在，anywhere anytime
- 整理：as BA咒程，即分析鸠天，Elaboration & Estimation & IPM => 確定 MVP & Efforts
- 執(zhí)行：as Dev & QA，Developing & Testing & Review/Sign-Off
- 回顧：Retrospection帐姻，Introspection稠集，持續(xù)反思，持續(xù)進步…
通過 GitHub Issues 收集需求
首先你可以給自己建一個 GitHub 倉庫作為主頁饥瓷，比如我的 JimmyLv/jimmylv.github.io: Agile Learning based on GitHub issues 剥纷，最開始就是從個人博客的主倉庫發(fā)展而來。那么呢铆，如何快速收納自己的想法呢晦鞋？以解決問題為導向，就是有什么需求就直接給自己的 repo 建一個 issue 作為 Story Card，了卻這個需求的最終形態(tài)就是 close 掉這個 Issue悠垛，比如我要寫這篇文章就始于這個 issue：基于 GitHub 的敏捷學習方法總結(jié) · Issue #36线定。
GitHub issues 的進階用法
與此同時，新建 issue 還有更高級的用法确买，也就是通過 ISSUE_TEMPLATE 這樣一個模板來新建某個 issue斤讥，從而更快地定位問題所在和解析自己的想法，最主要的是能夠輸出更具體的 TODOs湾趾，即下一步行動的具體內(nèi)容周偎，這個還會在后面詳細解釋。
- issue 和 issue 之間是可以通過
#相互連接撑帖，甚至可以跨倉庫蓉坎，被 reference 的 issue 也會出現(xiàn)在另外一邊的 issue 里面； - 而通過
#!符號是可以在 comments 里面直接新建一個 issue 胡嘿，這在思維爆炸的時候來得特別爽快蛉艾； - 你還可以隨意艾特你的小伙伴們，互相監(jiān)督衷敌、互相學習或者給出 Constructive Feedback 之類的勿侯，??；
- 更甚至于缴罗，若是在 Intellij 里面關聯(lián)了 GitHub助琐，就可以在 git commit 信息里面直接看到你所要關聯(lián)的 issues 列表了。
這種方式仿佛學習中的大腦，神經(jīng)網(wǎng)絡被連通了的感覺。
移動端的解決方案
而在移動端則可以通過 GitDo 這個 App 來輕松新建和管理自己的 Issues胞皱，沒錯，就是有人把 GitHub issues 做成了一個 Todos 類 App掘譬，還做得很漂亮功能很完善。只是不知為何這軟件最近被下架了呻拌，傷感葱轩，我就又重新把滴答清單（TickTick）作為自己的萬能收集箱了，之后再把比較重要的藐握、需要進一步追蹤的事項添加到 GitHub issues 里面來靴拱。
整理你的 GitHub Issues
大膽地把 issues 作為你的個人需求列表吧，需要解決的問題可以大到做一個開源項目猾普，或者小到讀一本書袜炕、寫一篇文章。對于比較大的需求抬闷，你還可以將其轉(zhuǎn)化為 Epic 然后把拆分過后的小 issues 們加入到這個列表里面來妇蛀。
而 GitHub (with ZenHub) 強大的 issues 管理能力絕對會讓你的迭代工作變得井井有條，使用 GitHub 新出的 Projects 特性或者使用 ZenHub 的 Boards 就可以讓你瞬間擁有日常敏捷工作的感覺了吧笤成！
計劃與執(zhí)行具體任務
制定迭代計劃
首先评架，讓我們新建一個 Milestone 來制定計劃，也就是決定在一個 Iteration 里面你需要完成哪些 issues炕泳。在這里我所制定的階段性計劃周期為一個月纵诞，當然你也可以勤快一點，以2周作為一個 Iteration培遵，享受一下自己的計劃要完成不了浙芙、這個 Milestone 就要廢了，沒法向「時間」這個一生的朋友交付所有需求的快感吧 ：）
當然咯籽腕，一般我會在月初做計劃的時候給自己準備專門的時間來做 Elaboration嗡呼，把 Backlog 里面的卡拖到 Rethink/Plan 這一列，經(jīng)過分析和詳細輸出 TODOs 以及所對應的估點 points 之后便可以將其拖到 Ready For Todo 了皇耗，一般我給自己估的點數(shù)就是完成這件事情所需要的時間南窗，一小時即對應一個 point。
這樣你就可以愉快的選擇 Filter Issues by Milestone 專注于當前 Iteration郎楼，專注于 In Progress 這一列所要做的事情万伤，并且垂涎于 Ready For Todo 里面將要做的事情，每次做完還可以放到 Review/SignOff呜袁，在里面寫寫對這件事情的總結(jié)和感想什么的敌买，每次挪卡都充滿了敏捷的儀式感（認真臉）。
進度的把控
GitHub 在 issues 里面直接集成了 Markdown 的 TODO 語法阶界，甚至于可以在渲染過后直接拖動某個 item 進行排序虹钮，而且可以在前面的勾選項中直接打勾 ?? 標記為完成。不僅如此膘融，完成之后這個 issue 還能直接顯示完成進度芜抒；前面所提到的 Epic 也能直接顯示子 issues 的完成情況即 closed 比例，兩者結(jié)合起來簡直不能再美好托启。
比如說拿來作為讀書列表的記錄就很不錯宅倒，每本書作為一個 issue，還可以把章節(jié)劃分為具體的 TODOs屯耸，結(jié)合估點追蹤自己看書的進度和速度拐迁，順便在 comments 底下做個筆記也不錯啊疗绣！
專注當下
ZenHub 還提供了一個基于 GitHub Issues 的 To do List线召，你可以只關注 Today 這一個列表，專心于當前要完成的任務多矮。而且更有趣的是這個 list 可以加入 GitHub 的任何 issues缓淹，也就是說它是全局的哈打，所以你可以加入很多在 GitHub 上通過 issues 寫的 blog，比如徐飛的這篇文章流動的數(shù)據(jù)——使用 RxJS 構(gòu)造復雜單頁應用的數(shù)據(jù)邏輯 · Issue #38 · xufei/blog讯壶，被我加入到了 Reading列表當中料仗。
與此同時我還會使用 Toggl 來記錄每個 issue 具體實施的時間，以便于在時間花費上能夠獲得及時的反饋伏蚊。這樣做會讓你真切地感受到時間的流逝立轧，而在回顧記錄的時候也能夠進行總結(jié)分析，從而在下一次的計劃當中更精確地預估時間（點數(shù)）躏吊。比方說這篇文章我估了 5 個點現(xiàn)在已經(jīng)寫了 4.5 hours 了氛改，不過這是另外一個大話題，可以參考 記錄時間這件小事兒 這個 issue比伏。
迭代回顧與總結(jié)分析
ZenHub 也提供了 Burndown 和 Velocity tracking 圖胜卤，可以得出這個迭代總體的完成情況，看看跟預期有何不同赁项；也可以跟其他迭代進行對比瑰艘，看看有何不同的地方，然后進行下一步的具體分析肤舞。
還可以根據(jù) GitHub 和 Toggl 里面的數(shù)據(jù)進行匯總和分析紫新，下面這個表格就是我在 11 月這個迭代完成后一部分 issues 的具體 Estimation Points 和 Time Efforts，再結(jié)合 issues 里面所記錄下的各種筆記和 references李剖，來得到一個比較直觀的總結(jié)和復盤芒率。
<table><thead><tr><th>Number & Description</th><th>Estimation Points</th><th>Time Efforts</th></tr></thead><tbody><tr><td>#85 記錄時間這件小事兒</td><td>3</td><td>04:26:18</td></tr><tr><td>#96 如何對時間進行分類？</td><td>8</td><td>03:00:09</td></tr><tr><td>#102 建立個人 Wiki 系統(tǒng)</td><td>2</td><td>02:53:56</td></tr><tr><td>#101 技術雷達宣講：enzyme 測試框架</td><td>5</td><td>06:11:19</td></tr><tr><td>#90 Working time improvement</td><td>1</td><td>33:27 min</td></tr><tr><td>#97 如何使用 XX 的標簽系統(tǒng)篙顺？</td><td>1</td><td>25:21 min</td></tr></tbody></table>
其他輔助工具
- 看板：as Jira/Trello偶芍，可視化當前進度 => GitHub Issues group by @Projects / 日歷 in @滴答清單；如果你不想用 ZenHub 德玫，可以試試 Gitlo 匪蟀，可以在 GitHub issues 和 Trello 之間進行雙向同步。
- 晨間日記/每日回顧：as Stand-Up宰僧，只用關注 Timeline/Done/Todo/Blocker 以及當天的心情/天氣等等材彪，使用 @格志日記的一個特點就是可以通過問答的方式對一天進行回顧。
- 時間記錄：@時間塊的優(yōu)點在于記錄起來非常簡單琴儿、快捷段化，是用戶評論中最省時間的時間記錄工具，沒有之一造成，推薦新手試試显熏。但由于個人需要更加詳細的記錄細節(jié)和報告分析，以及多平臺（包括 Chrome Extension）的支持晒屎，從而選擇了 @Toggl喘蟆。
- 白噪聲：作為一款時間記錄工具缓升，@Toggl 本身就支持 Pomodoro 的 25 分鐘提示。而作為專注力輔助的白噪聲軟件我在手機上用的 @潮汐蕴轨，電腦上則選擇了 @Noizio港谊。
后話
也許你很喜歡這個解決方案但又不太想公開自己的 issues 列表，那可以試試 GitHub 的 private repo（需要付費）尺棋，免費的可以試試 GitLab，支持從 GitHub 一鍵導入绵跷，并且已經(jīng)原生支持了 pipeline 和看板功能膘螟。當然，不限于工具或軟件碾局，這一套方法論其實是可以運用在任何地方的荆残，甚至于我們可以來做一個結(jié)合敏捷方法論的個人學習管理軟件也不錯。
但是于我而言净当，選擇在 GitHub 這樣一個公開環(huán)境下記錄學習的最大一個動機就在于「開源」内斯，很喜歡一句話，大意是「在這個互聯(lián)網(wǎng)時代像啼，能限制住學習的只有你的求知欲」俘闯。
當你從互聯(lián)網(wǎng)這個廣闊的知識海洋當中汲取知識時，也應當有所輸出忽冻，即反哺到整個互聯(lián)網(wǎng)當中去真朗。我會經(jīng)常寫博客/筆記來總結(jié)、分享自己的所學僧诚，但是一篇文章誕生的背后往往還有很多其他知識和經(jīng)驗的相互交融與沉淀遮婶。Issues · JimmyLv/jimmylv.github.io 這個列表里面的某個 issues 最終能否演變成一篇文章我不知道，但是基于 GitHub 開放式的學習歷程都會被這些 issues 如實地記錄著湖笨，任何一個想法都能追本溯源被找出最開始的緣由旗扑。
相比于軟件開發(fā)這件小事兒，健康快樂地成長顯然要重要得多慈省⊥畏溃—— 立青
更多精彩洞見，請關注微信公眾號思特沃克
