一、前言
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”的原创稿件，微信公众号：思特沃克，转载请联系原作者】
