基于 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 如实地记录着，任何一个想法都能追本溯源被找出最开始的原因。

相比于软件开发这件小事儿，健康快乐地成长显然要重要得多。—— 立青