建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
一、前言
1. 對(duì)時(shí)間的敬畏
需要好多年才能懂得，***不是去震驚世界，而是要像易卜生所說(shuō)的，生活在世界上。
我們都一樣，渴望著建樹(shù)功勛、改變世界?？墒前殡S著年歲的增長(zhǎng)，卻發(fā)現(xiàn)夢(mèng)想仍舊遙遠(yuǎn)，而時(shí)間卻依然殘酷的流逝著，不會(huì)僅僅因?yàn)椤改恪苟l(fā)生絲毫的改變。如《奇特的一生》當(dāng)中所言，我對(duì)時(shí)間始終充滿(mǎn)著敬畏之心，***的方式也不過(guò)是奢求時(shí)間能夠跟自己做朋友，伴隨著我這也許注定樸實(shí)無(wú)華的一生，共同成長(zhǎng)。
在我們一生所能做的事情里，睡眠占去1/3，此生只剩2/3，除去非做不可的基本生活維護(hù)成本之外，剩下的時(shí)間要么選擇浪費(fèi)而荒度此生，要么瞄準(zhǔn)目標(biāo)而奮力向前，讓這一生不留遺憾。Follow your heart，你需要找到一些愿意為其付諸終身的「目標(biāo)」，以這樣的姿態(tài)「生活在這世界上」。
2. 敏捷與個(gè)人成長(zhǎng)
就像軟件開(kāi)發(fā)一樣，一個(gè)人的成長(zhǎng)也應(yīng)該有自己的方法論。人的一生若是順風(fēng)順?biāo)?、一成不變，那未免太無(wú)趣了，正是由于世界的未知在等著我們?nèi)ヌ剿鳎灰粯拥慕?jīng)歷才會(huì)讓人感到驚喜和有趣。想做的事情永遠(yuǎn)都不會(huì)嫌多，就像柳比歇夫最開(kāi)始是研究生物學(xué)的，卻在科學(xué)的道路上越走越遠(yuǎn)，進(jìn)而研究起了數(shù)學(xué)、物理、哲學(xué)，甚至于美學(xué)，而更關(guān)鍵的是，他在每一方面都做出了很大貢獻(xiàn)并且留下了諸多著作。
時(shí)間充當(dāng)著Product Owner的角色在不斷向你提出各種各樣的需求，敏捷當(dāng)中最重要的一大前提就是「擁抱變化」，而在「記錄時(shí)間這件小事兒」里面我提到的GTD流程便可以用于處理這源源不斷的需求，即收集、整理、執(zhí)行、回顧，對(duì)應(yīng)到敏捷當(dāng)中的幾大會(huì)議，顯然也可以由個(gè)人完成，自己就是自己的IM&PM，當(dāng)然也是BA&Dev&QA(當(dāng)然不用擔(dān)心人格分裂)。
二、實(shí)踐之術(shù)
“我都沒(méi)想到怎么寫(xiě)著寫(xiě)著就把開(kāi)頭寫(xiě)成了雞湯文。但是咧，如果前面講的是「道」，那么接下來(lái)就會(huì)具體到基于GitHub的「術(shù)」，即各種實(shí)踐?！?/p>
首先，讓我們從需求出發(fā)，從市面上來(lái)尋找一款符合敏捷的學(xué)習(xí)軟件，別想了，當(dāng)然是沒(méi)有的。對(duì)于一名程序猿來(lái)說(shuō)，最理想的答案其實(shí)就是GitHub，作為全球***的程序猿網(wǎng)站，GitHub本身以及圍繞GitHub的各種插件使得其項(xiàng)目管理能力遠(yuǎn)比你所能想象的厲害得多。
- 收集：需求無(wú)時(shí)無(wú)刻，無(wú)處不在，anywhere anytime
- 整理：as BA，即分析，Elaboration&Estimation&IPM=>確定MVP&Efforts
- 執(zhí)行：as Dev&QA，Developing&Testing&Review/Sign-Off
- 回顧：Retrospection，Introspection，持續(xù)反思，持續(xù)進(jìn)步…
三、通過(guò)GitHub Issues收集需求
首先你可以給自己建一個(gè)GitHub倉(cāng)庫(kù)作為主頁(yè)，比如我的JimmyLv/jimmylv.github.io: Agile Learning based on GitHub issues ，最開(kāi)始就是從個(gè)人博客的主倉(cāng)庫(kù)發(fā)展而來(lái)。那么，如何快速收納自己的想法呢?以解決問(wèn)題為導(dǎo)向，就是有什么需求就直接給自己的repo建一個(gè)issue作為Story Card，了卻這個(gè)需求的最終形態(tài)就是close掉這個(gè)Issue，比如我要寫(xiě)這篇文章就始于這個(gè)issue：基于GitHub的敏捷學(xué)習(xí)方法總結(jié)·Issue #36。
四、GitHub issues的進(jìn)階用法
與此同時(shí)，新建issue還有更高級(jí)的用法，也就是通過(guò)ISSUE_TEMPLATE這樣一個(gè)模板來(lái)新建某個(gè)issue，從而更快地定位問(wèn)題所在和解析自己的想法，最主要的是能夠輸出更具體的TODOs，即下一步行動(dòng)的具體內(nèi)容，這個(gè)還會(huì)在后面詳細(xì)解釋。
- issue和issue之間是可以通過(guò)#相互連接，甚至可以跨倉(cāng)庫(kù)，被reference的issue也會(huì)出現(xiàn)在另外一邊的issue里面;
- 而通過(guò)#!符號(hào)是可以在comments里面直接新建一個(gè)issue ，這在思維爆炸的時(shí)候來(lái)得特別爽快;
- 你還可以隨意艾特你的小伙伴們，互相監(jiān)督、互相學(xué)習(xí)或者給出Constructive Feedback之類(lèi)的;
- 更甚至于，若是在Intellij里面關(guān)聯(lián)了GitHub，就可以在git commit信息里面直接看到你所要關(guān)聯(lián)的issues列表了。
這種方式仿佛學(xué)習(xí)中的大腦，神經(jīng)網(wǎng)絡(luò)被連通了的感覺(jué)。
五、移動(dòng)端的解決方案
而在移動(dòng)端則可以通過(guò)GitDo這個(gè)App來(lái)輕松新建和管理自己的Issues，沒(méi)錯(cuò)，就是有人把GitHub issues 做成了一個(gè)Todos類(lèi)App，還做得很漂亮功能很完善。只是不知為何這軟件最近被下架了，傷感，我就又重新把滴答清單(TickTick)作為自己的***收集箱了，之后再把比較重要的、需要進(jìn)一步追蹤的事項(xiàng)添加到GitHub issues里面來(lái)。
六、整理你的GitHub Issues
大膽地把issues作為你的個(gè)人需求列表吧，需要解決的問(wèn)題可以大到做一個(gè)開(kāi)源項(xiàng)目，或者小到讀一本書(shū)、寫(xiě)一篇文章。對(duì)于比較大的需求，你還可以將其轉(zhuǎn)化為Epic然后把拆分過(guò)后的小issues們加入到這個(gè)列表里面來(lái)。
而GitHub (with ZenHub) 強(qiáng)大的issues管理能力絕對(duì)會(huì)讓你的迭代工作變得井井有條，使用GitHub新出的Projects特性或者使用ZenHub的Boards就可以讓你瞬間擁有日常敏捷工作的感覺(jué)了吧！
七、計(jì)劃與執(zhí)行具體任務(wù)
1. 制定迭代計(jì)劃
首先，讓我們新建一個(gè)Milestone來(lái)制定計(jì)劃，也就是決定在一個(gè)Iteration里面你需要完成哪些 issues。在這里我所制定的階段性計(jì)劃周期為一個(gè)月，當(dāng)然你也可以勤快一點(diǎn)，以2周作為一個(gè)Iteration，享受一下自己的計(jì)劃要完成不了、這個(gè)Milestone就要廢了，沒(méi)法向「時(shí)間」這個(gè)一生的朋友交付所有需求的快感吧 。
當(dāng)然咯，一般我會(huì)在月初做計(jì)劃的時(shí)候給自己準(zhǔn)備專(zhuān)門(mén)的時(shí)間來(lái)做Elaboration，把Backlog里面的卡拖到Rethink/Plan這一列，經(jīng)過(guò)分析和詳細(xì)輸出TODOs 以及所對(duì)應(yīng)的估點(diǎn)points之后便可以將其拖到Ready For Todo了，一般我給自己估的點(diǎn)數(shù)就是完成這件事情所需要的時(shí)間，一小時(shí)即對(duì)應(yīng)一個(gè)point。
這樣你就可以愉快的選擇Filter Issues by Milestone 專(zhuān)注于當(dāng)前Iteration，專(zhuān)注于In Progress這一列所要做的事情，并且垂涎于Ready For Todo里面將要做的事情，每次做完還可以放到Review/SignOff，在里面寫(xiě)寫(xiě)對(duì)這件事情的總結(jié)和感想什么的，每次挪卡都充滿(mǎn)了敏捷的儀式感(認(rèn)真臉)。
2. 進(jìn)度的把控
GitHub在issues里面直接集成了Markdown的TODO語(yǔ)法，甚至于可以在渲染過(guò)后直接拖動(dòng)某個(gè)item進(jìn)行排序，而且可以在前面的勾選項(xiàng)中直接打勾 標(biāo)記為完成。不僅如此，完成之后這個(gè)issue還能直接顯示完成進(jìn)度;前面所提到的Epic也能直接顯示子issues的完成情況即closed比例，兩者結(jié)合起來(lái)簡(jiǎn)直不能再美好。
比如說(shuō)拿來(lái)作為讀書(shū)列表的記錄就很不錯(cuò)，每本書(shū)作為一個(gè)issue，還可以把章節(jié)劃分為具體的TODOs，結(jié)合估點(diǎn)追蹤自己看書(shū)的進(jìn)度和速度，順便在comments底下做個(gè)筆記也不錯(cuò)?。?/p>
3. 專(zhuān)注當(dāng)下
ZenHub還提供了一個(gè)基于GitHub Issues的To do List，你可以只關(guān)注Today這一個(gè)列表，專(zhuān)心于當(dāng)前要完成的任務(wù)。而且更有趣的是這個(gè)list可以加入GitHub的任何issues，也就是說(shuō)它是全局的，所以你可以加入很多在GitHub上通過(guò)issues寫(xiě)的blog，比如徐飛的這篇文章流動(dòng)的數(shù)據(jù)——使用RxJS構(gòu)造復(fù)雜單頁(yè)應(yīng)用的數(shù)據(jù)邏輯·Issue #38 · xufei/blog，被我加入到了Reading列表當(dāng)中。
與此同時(shí)我還會(huì)使用Toggl來(lái)記錄每個(gè)issue具體實(shí)施的時(shí)間，以便于在時(shí)間花費(fèi)上能夠獲得及時(shí)的反饋。這樣做會(huì)讓你真切地感受到時(shí)間的流逝，而在回顧記錄的時(shí)候也能夠進(jìn)行總結(jié)分析，從而在下一次的計(jì)劃當(dāng)中更精確地預(yù)估時(shí)間(點(diǎn)數(shù))。比方說(shuō)這篇文章我估了5個(gè)點(diǎn)現(xiàn)在已經(jīng)寫(xiě)了4.5 hours 了，不過(guò)這是另外一個(gè)大話(huà)題，可以參考記錄時(shí)間這件小事兒這個(gè)issue。
八、迭代回顧與總結(jié)分析
ZenHub也提供了Burndown和Velocity tracking圖，可以得出這個(gè)迭代總體的完成情況，看看跟預(yù)期有何不同;也可以跟其他迭代進(jìn)行對(duì)比，看看有何不同的地方，然后進(jìn)行下一步的具體分析。
還可以根據(jù)GitHub和Toggl里面的數(shù)據(jù)進(jìn)行匯總和分析，下面這個(gè)表格就是我在11月這個(gè)迭代完成后一部分issues的具體Estimation Points和Time Efforts，再結(jié)合issues里面所記錄下的各種筆記和references，來(lái)得到一個(gè)比較直觀(guān)的總結(jié)和復(fù)盤(pán)。
其他輔助工具
- 看板：as Jira/Trello，可視化當(dāng)前進(jìn)度 => GitHub Issues group by @Projects / 日歷in@滴答清單;如果你不想用ZenHub ，可以試試Gitlo ，可以在GitHub issues和Trello之間進(jìn)行雙向同步。
- 晨間日記/每日回顧：as Stand-Up，只用關(guān)注Timeline/Done/Todo/Blocker以及當(dāng)天的心情/天氣等等，使用@格志日記的一個(gè)特點(diǎn)就是可以通過(guò)問(wèn)答的方式對(duì)一天進(jìn)行回顧。
- 時(shí)間記錄：@時(shí)間塊的優(yōu)點(diǎn)在于記錄起來(lái)非常簡(jiǎn)單、快捷，是用戶(hù)評(píng)論中最省時(shí)間的時(shí)間記錄工具，沒(méi)有之一，推薦新手試試。但由于個(gè)人需要更加詳細(xì)的記錄細(xì)節(jié)和報(bào)告分析，以及多平臺(tái)(包括Chrome Extension)的支持，從而選擇了@Toggl。
- 白噪聲：作為一款時(shí)間記錄工具，@Toggl 本身就支持Pomodoro的25分鐘提示。而作為專(zhuān)注力輔助的白噪聲軟件我在手機(jī)上用的 @潮汐，電腦上則選擇了@Noizio。
后話(huà)
也許你很喜歡這個(gè)解決方案但又不太想公開(kāi)自己的issues列表，那可以試試GitHub 的private repo(需要付費(fèi))，免費(fèi)的可以試試GitLab，支持從GitHub一鍵導(dǎo)入，并且已經(jīng)原生支持了pipeline和看板功能。當(dāng)然，不限于工具或軟件，這一套方法論其實(shí)是可以運(yùn)用在任何地方的，甚至于我們可以來(lái)做一個(gè)結(jié)合敏捷方法論的個(gè)人學(xué)習(xí)管理軟件也不錯(cuò)。
但是于我而言，選擇在GitHub這樣一個(gè)公開(kāi)環(huán)境下記錄學(xué)習(xí)的***一個(gè)動(dòng)機(jī)就在于「開(kāi)源」，很喜歡一句話(huà)，大意是「在這個(gè)互聯(lián)網(wǎng)時(shí)代，能限制住學(xué)習(xí)的只有你的求知欲」。
當(dāng)你從互聯(lián)網(wǎng)這個(gè)廣闊的知識(shí)海洋當(dāng)中汲取知識(shí)時(shí)，也應(yīng)當(dāng)有所輸出，即反哺到整個(gè)互聯(lián)網(wǎng)當(dāng)中去。我會(huì)經(jīng)常寫(xiě)博客/筆記來(lái)總結(jié)、分享自己的所學(xué)，但是一篇文章誕生的背后往往還有很多其他知識(shí)和經(jīng)驗(yàn)的相互交融與沉淀。Issues · JimmyLv/jimmylv.github.io 這個(gè)列表里面的某個(gè)issues最終能否演變成一篇文章我不知道，但是基于GitHub開(kāi)放式的學(xué)習(xí)歷程都會(huì)被這些issues如實(shí)地記錄著，任何一個(gè)想法都能追本溯源被找出最開(kāi)始的緣由。
“相比于軟件開(kāi)發(fā)這件小事兒，健康快樂(lè)地成長(zhǎng)顯然要重要得多。—— 立青”
【本文是專(zhuān)欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號(hào)：思特沃克，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】
當(dāng)前文章：基于GitHub的敏捷學(xué)習(xí)方法之道與術(shù)
文章轉(zhuǎn)載：http://m.5511xx.com/article/dhcdjsi.html
