引言
話說，幾個月前有個朋友是這麼和我說的。
但是呢，大家也知道，人很多時候往往是有心無力。所以呢，他剛好找到了我。我當時突然靈機一動，決定用敏捷開發的方式對其進行培養。
敏捷最大的特色是迭代式開發，將一個複雜且週期很長的開發任務，分解爲很多小週期可完成的任務，然後每個小週期開發出一個可以交付的產品，每個週期都需要進行總結討論可改進點。
我們的這個複雜且週期很長的開發任務是啥？
就是進入BAT
我們的這個很多小週期可完成的任務是啥？
就是各個知識點，例如
(1)消息隊列
(2)redis
(3)省略…
另外，將這些知識點再細分爲不同的用戶故事，供其學習。
但是，大家要知道敏捷開發有一個很坑的地方，因爲敏捷開發要求在每個迭代週期制定好本週期迭代的需求。然而有些需求真的是一天一個樣，根本無法準確評估出時間。
幸運的是，JAVA可以複習的知識點也就那些，每塊需要複習多少時間，我都心中有數，因此大體上可以按照我的計劃進行。
OK，開始我們的正文
正文
學習時間
OK，我和他首先要在學習時間方面達成一個共識。首先，可以明確一點，我是提倡每天學一點，積少成多。
考慮到他是一個開發，經常性加班，我們將工作日的學習時間定爲一小時。這個是完全可以落地的，他甚至在吃飯的時候，還不忘學習。
至於週末，我定的時間爲每日三小時。統計下來，一週的學習時間爲十一小時。如此堅持半年時間，效果驚人!
每日站會
在敏捷開發中，站立會議的目的是讓所有人瞭解其他人在做什麼，當前項目計劃進展如何。
在真正實踐中，不必拘泥於形式。由於我們的上班時間是一樣的，決定在工作日的早上8點15分，大家都在地鐵上刷手機的時候，利用微信匯報昨日進展。
若爲休息日，鑑於大家都有睡懶覺的習慣，我們則選擇在晚上7點左右進行彙報。彙報完畢，各自開始學習。
要求每日彙報回答出下面的問題
昨天學了啥？
遇到了啥問題？
今天打算學啥？
OK，這樣就夠了。我能做的就是及時給他排除阻礙，順利複習。
迭代週期
在敏捷開發中，非常強調穩定的迭代節奏，一次迭代的時間爲2~4周。
在真正實踐中，我會根據具體的知識點給不同的迭代週期。例如，關於Docker和jenkins這些屬於持續集成的知識點，我只給一週。因爲這些知識點純粹是會用就行，不需要給太長的迭代週期。
然而，關於j.u.c這類知識，迭代週期就需要給一個月，畢竟這種原理性的知識，還是很困難的。
待辦列表
就算我們制定了迭代週期，告訴他，我們這個週期要學spring啊。
但是，他不懂要具體學spring的哪些知識。比如，你讓他看源碼？一年時間都不一定能領悟到精髓。
因此，對於每個知識點，要列出待辦列表，例如
(1)掌握spring事務原理
(2)懂spring的bean的生命週期
(3)省略…
然後每週從中選幾個點進行學習！
需求看板
在敏捷開發中，看板目的是可視化你的工作流程。所有的任務的進度會全部顯示看板上，每一個人都可以一目瞭然瞭解進度和流程。比如下面這樣的
然而實際落地中，我們一致認爲最雞肋的就是這個。畢竟我們就兩個人，還需要弄一個看板？太畫蛇添足了。我們只弄了一個Excel表格，記錄每週的待辦列表有哪些。
回顧會
在敏捷開發中，每個迭代週期要開一次回顧會，也稱爲總結會議，以輪流發言方式進行，每個人都要發言，總結並討論改進的地方。
但是在真正落地中，我們不是以一個迭代週期爲單位。而是一週一次，我們通常會在每個週日晚上11點進行一次10分鐘的溝通，講一下學習整體情況，看看有沒有什麼整體的不足，需要改進事項！
計劃會
在敏捷開發中，迭代計劃會在每個迭代的第一天召開，目的是選擇和估算本次迭代的工作項。
我們一般把回顧會和計劃會放在一起開。在每週日開展回顧會的時候，若本週恰好迭代結束。我們會直接開始計劃會，告訴他下個迭代週期的時間，以及任務的內容。
當然，我會經常聽到他說
結對編程
有時候發現他有點懈怠了，而恰巧這個知識點，我突然想複習一下。我就會提出結對編程的方式，共同學習，當然，最後結果是下面這樣的
總結
目前大部分公司敏捷開發的落地只是一種形式。因爲很多人只會生搬硬套敏捷開發的定義，而不加以思考這種方式是否滿足現狀。
相反，我們應該善於思考，靈活運用在生活中的其他方面，對我們還是有一定幫助的。