產品管理之敏捷之路（一）——攜手同行，走本身的敏捷之路

這是我最近在公司內部培訓所整理的資料，本篇本來是PPT，我在這裏整理成博客分享給你們。

另外，最近因事回家待了一個月，因此不少東西都耽擱了，包括Magicodes.NET，這個直到如今我都沒有時間去更新它，但願下週開始可以逐步投入少許時間。

本篇做爲開篇，在此，我先列下本系列的內容（可能有些篇章過多，會進行拆分），但願和你們探討交流：

1. 產品管理之敏捷之路（一）——攜手同行，走本身的敏捷之路
2. 產品管理之敏捷之路（二）——使用TFS生成服務+PowerShell實現持續集成
3. 產品管理之敏捷之路（三）——使用Worktile+Sharepoint進行規範梳理
4. 產品管理之敏捷之路（四）——使用LessChat進行渠道整合（反饋、開發、日誌、通知）
5. 產品管理之敏捷之路（五）——使用Worktile進行產品管理

如今開始說說本章的主題（根據我以前培訓的PPT改編而成）。

攜手同行，走本身的敏捷之路

前言

近來，我一直在思考：

• 如何在有限的資源下，開發出更可用的產品？
• 如何更有效的開發與合做，以及提高團隊的開發效率？
• 如何調動團隊中每個人的積極性，讓每個人都可以在產品的迭代中不斷成長？
• 如何使產品團隊內部協做更合理更規範，責任更明確？

 

所以，在本篇的內容中，但願更多的是引導而不是灌輸。在此開始以前，我想表達下我的觀點：

• 我從未對一種開發模式寄予所有但願。指望它能解決咱們如今固有的全部問題是不現實的，它多是甜蜜劑，固然也有多是催化劑！
  真正讓我寄予但願的是團隊中的每個人，也就是咱們在座的每個人。
• 世界一直在變，而惟一不變的是變化。咱們一路走來，從項目團隊到產品團隊，從互不相識到協同工做，咱們須要變化，咱們須要調整，咱們須要成長，以組成一個更高效更合理的產品團隊——咱們是一個總體，咱們須要攜手並進，精誠合做。
• 敏捷管理不可複製，所以咱們須要走出本身的敏捷之路。

 

書籍是人類進步的階梯

在此以前先推薦兩本書，不是我本身的。

淘寶技術這十年

這不是一本好的技術書，可是卻絕對值得作產品的人看。

引用書裏的一句話：「任何網站的發展都不是一蹴而就的，一般是在什麼階段採用什麼技術。在發展的過程當中，網站會遇到各類各樣的問題，正是這些緣由才推進着技術的進步與發展，而技術的發展反過來又會促進業務的更大提高。二者互爲因果，相互促進」。

所以，任何一個產品，都有一個從爛到好的過程，產品的完善是一步一個腳印踏踏實實作出來的，是一點一點進步起來的。從書中咱們能夠看到淘寶其實並無想象中的那麼神話，他們早期的產品也是伴隨着各類BUG，各類不穩定，各類不完善，這跟咱們目前開發的產品同樣，因此咱們無需妄自菲薄。可是，咱們須要有堅持作好產品的決心與毅力，一點一點的完善，一點一點的改進，最終咱們也同樣能開發出好的產品。

右下角爲淘寶早期風格。

精益創業

當決定作一個東西的時候，不要一開始就把目標定的很宏大很完善，一開始就要設計一個能容納多少訪問量的架構，其實計劃永遠趕不上變化，你的系統老是隨着用戶的擴大而漸進改進的。與其一開始就花費巨大的精力與時間去想之後用戶規模到多大以後咱們的系統還能不能用的問題，還不如好好知足當前用戶的需求，至於之後，那自有之後的應對策略。不然當你花費巨大的精力想要打造一個容納千萬訪問量的系統，最後卻發現你的系統連十萬訪問量都達不到。這也是敏捷開發管理的核心理念（亦是精益創業的核心思想），即先在市場中投入一個極簡的原型產品，而後經過不斷的學習和有價值的用戶反饋(通過證明的認知) ，對產品進行快速迭代優化，以期適應市場。

微軟Visual Studio團隊的敏捷之路

在討論敏捷以前，咱們先來看看Visual Studio團隊的敏捷之路。

•Visual Studio是微軟最重要的核心開發工具，到去年10月止，全球.NET開發人員近6百萬人，光是VS 2013年版本，下載次數就達到7百萬次。

•參與VS開發的人數超過4,700人，分佈在美國、瑞士、中國、印度等地的微軟研發中心。這羣人要負責190萬個開發工做項目，完成了近3,600萬個程序代碼庫，累計數據量達到15.3TB。開發團隊平均每月會組建（Build）22萬屢次。

過去——瀑布開發模式

•瀑布開發模式，開發時程約2年

•花3個月時間來定製長期計劃。其中，部門主管須要訂定5年產品計劃，而產品經理則是要想象2年後的市場需求，來擬定2年後產品上市時的功能藍圖。而後再設定多個里程碑（如圖M一、M2，會發佈一個對應的測試版本）區分開發階段，每階段內先開發程序代碼，再進行測試與功能穩定，達成里程碑後發佈一個顧客可用的版本。工程師們再依每個里程碑估算本身的工做進度，並修正產品進度，來計算出2年後的哪一天能發佈產品。

•每個里程碑階段內還得設定程序代碼開發完成的時間點（Code Complete），由於得預留時間做爲測試工做和功能穩定調校，微軟過去至少會預留兩倍的程序代碼開發所用的時間。多數狀況是，微軟工程師很快就完成程序代碼的開發，反而是花了不少時間讓功能穩定，例如整合不一樣功能間的衝突或整合。

如今——敏捷開發模式

•採用敏捷開發模式，每三週爲一個Scrum敏捷開發的Sprint（衝刺）週期，每次Sprint結束後要發佈一個VS版本，試用一週後發佈給使用者

•開發與測試工做合而爲一，轉變成持續測試、持續整合的開發模式

•微軟也再也不制訂產品的5年計劃了，而是縮短爲只訂定每6個月的計劃，也就是兩季長的計劃，並每6個月進行市場或競爭對手評估，讓產品能因應市場最新變化。另外還會訂定一個18個月後要實現的產品願景，來規劃如軟件架構調整或本質性需求調整等須要較長時間做業的目標

改變

固然還有一些其餘的改變，本篇就不一一列舉了，好比測試團隊縮小了，之前須要配備與開發團隊規模至關的測試團隊。

快魚法則

先歇一會，又到了說書時間了。

看完了Visual Studio團隊的故事，咱們再來看一個故事：

有兩我的在樹林裏過夜。早上，忽然樹林裏跑出一頭大黑熊來，兩我的中的一個忙着穿球鞋。另外一我的對他說：「你把球鞋穿上有什麼用？咱們反正跑不過熊啊！」忙着穿球鞋的人說：「我不是要跑得快過熊，我是要跑得快過你。」 這個故事給我兩點啓迪：

• 咱們面對的世界，是一個充滿變數而且競爭很是激烈的世界，比跑得快不快，極可能成爲決定成功與失敗的關鍵。
• 以往，「大魚吃小魚」以往被視爲常理，但是在信息社會的市場競爭中，每每不是大魚吃小魚，而是快魚吃慢魚。這就是快魚法則。

天下武功無堅不破，惟快不破！——火雲邪神

看完故事，咱們再看點實際的。好比下方的企業，在快魚法則中體現的淋漓盡致：

 

快魚法則在互聯網服務上的體現

• 市場在變化，有太多不肯定的因素
• 需求變化不可避免
• 搶先戰略——商機是有限的
• 追求創新
• 須要快速響應用戶的變化
• 持續關注用戶行爲以及用戶體驗

知道了快魚法則，咱們再來談談敏捷。

爲何要敏捷？

下降項目風險

• 縮短反饋週期
• 減小誤解(溝通)
• 下降修正錯誤的代價

確保正確的方向

• 可用的軟件
• 用戶驗證
• 適應變化

總的來講，就一個字——「變」，適應變化。

弱弱的說一句，對於公司來講，這玩意兒就是爲了最大限度的挖掘程序員的潛力，而且提升效率以及規避風險，最終就是節約公司成本。

什麼是敏捷？

關於Scrum和XP

前面說了敏捷它是一種指導思想或開發方式，可是它沒有明確告訴咱們到底採用什麼樣的流程進行開發，而Scrum和XP（即極限編程，它強調把它列出的每一個方法和思想作到極限、作到最好，而它所不提倡的，則一律忽略（如開發前期的總體設計等））就是敏捷開發的具體方式了，你能夠採用Scrum方式也能夠採用XP方式；Scrum和XP的區別是，Scrum偏重於過程，XP則偏重於實踐，可是大部分狀況下，二者是結合一塊兒應用的，不過咱們側重於說Scrum。

Scrum的英文意思是橄欖球運動的一個專業術語，表示「爭球」的動做；把一個開發流程的名字取名爲Scrum，我想你必定能想象出你的開發團隊在開發一個項目時，你們像打橄欖球同樣迅速、富有戰鬥激情、人人你爭我搶地完成它，你必定會感到很是興奮的。而Scrum就是這樣的一個開發流程，運用該流程，你就能看到你團隊高效的工做。

簡單的來講：

XP說：除了編程，什麼事也不要打擾我（極限編程）！客戶甲，你的測試工做Delay了（客戶也是開發中的一員）！

Scrum說：你們都是一條船上的人啦，都利索點劃（團隊對項目負責）！上次TM才起步就翻船了，此次請你們按照咱們上次總結的劃法配合好（反思）！劃到前面那個島，你們就休息下，而後總結下此次的經驗還有看看接下來劃到哪（迭代、評審、回顧、規劃）！…

Scrum開發模型

產品開發反思

瞭解了敏捷開發，那麼，咱們如何走向本身的敏捷呢？

也就是，咱們應該如何來提升開發效率？如何來保障軟件質量？如何快速響應市場？

敏捷不是說出來的，是幹出來的！Go！

走本身的敏捷之路

如我開篇所說，敏捷管理不可複製，咱們須要走出本身的敏捷之路。每個團隊在初始階段狀況都不一樣，好比咱們團隊，存在如下問題：

1.你們對敏捷瞭解很少

2.單元測試大多還不會寫，並且當前架構並不利於單元測試，那麼測試驅動開發咱們須要根據咱們的狀況逐步漸進

3.持續集成咱們還難以作到完善，可是能夠初具規模

4.會議咱們會增長，可是更多的強調的是隨時溝通，若是有須要演示或者相對嚴謹的，咱們纔會召開會議

5.結對編程目前是不可能的

6….

總之，咱們確定沒法作到很嚴格的敏捷開發，那麼咱們就開始咱們本身的敏捷之旅吧。

改變觀念——主動接受需求的改變而不是拒絕

對於需求變動，說實話，個人內心是拒絕的——一方面，咱們儘量的在細化需求，挖掘需求，以及複雜設計，另外一方面，咱們亦是儘量的確認需求，天然是不太樂意接受這種需求變動。由於每一次的變動都須要咱們付出很大的精力。

然而，產品的方向，誰都沒法把控。咱們一次次的拒絕，實際上最終還得一次次接受。咱們必須轉變這種心態，而是應該接受合理的需求，同時歡迎並積極引導用戶反饋，來不斷的完善咱們的產品。

最後，咱們須要知道一點：改變需求是好事情，由於這些改變意味着咱們更瞭解市場需求。

快速迭代

在以前，咱們總須要很長時間（好比V1耗時大半年）才能發佈一個版本，並且這個版本仍是在遵循業務或者咱們的理解的基礎上開發的版本。而如今，咱們須要快速迭代，來不斷的交付可用的產品。

什麼是迭代？迭代是指把一個複雜且開發週期很長的開發任務，分解爲不少小週期可完成的任務，這樣的一個週期就是一次迭代的過程；同時每一次迭代均可以生產或開發出一個能夠交付的軟件產品。

敏捷測試——測試驅動開發（TDD）

咱們老是在抱怨沒有測試人員，事實上咱們如今招聘測試人員也是很不划算的，由於測試人員的工做量很難飽和，咱們並無須要持續測試的任務交給他們。可是咱們確實很須要測試，由於Bug老是層出不窮，並且很容易重複出現，尤爲是當咱們在發佈版本前集中測試時，Bug老是讓咱們改到崩潰。

確實，在傳統測試中，開發人員負責編碼，測試人員負責質量驗收，測試人員是軟件質量的最後一道防線。那麼如今起，在咱們的敏捷開發中，系統設計、編碼、單元測試、開發測試、重構等關鍵任務都須要咱們本身（開發人員）來完成，以保證持續的、快速的業務價值交付。也就是，咱們之後須要本身來作測試，除了編寫單元測試，手工測試也是咱們分內的事情。所以，後面招人也會優先考慮招聘開發人員。

注意：在持續集成時，會運行全部的單元測試。這實際上提升了開發者的開發效率，由於單元測試能夠有效的幫助開發人員發現代碼中的邏輯錯誤。

固然，產品達到必定規模的時候，獨立測試人員也是須要的。他們能夠來全面的驗證和檢查一個系統，以及提供自動化測試工具的支持，進行性能測試、負載測試、安全性測試等。

產品自動化測試反思

咱們目前的狀況並不適合大規模的自動化測試，咱們只能着手如下幾點：

1.簡化手工測試（好比自動造數據等等），若是須要花費不少工做量來編寫的單元測試，那目前仍是以手工測試代替

2.從架構級別增長對一些經常使用的API的單元測試，保證架構中主體API的正確，便於架構重構

3.在後續的設計中或者系統下個版本時，使用利於搭建單元測試的架構

持續集成

持續集成正是針對上述一系列問題的一種軟件開發實踐，它倡導團隊開發成員必須常常集成他們的工做，甚至天天均可能發生屢次集成。而每次的集成都是經過自動化的構建來驗證，包括自動編譯、發佈和測試，從而儘快地發現集成錯誤，讓團隊可以更快的開發內聚的軟件。

要素

1.統一的代碼庫

2.自動構建

3.自動測試

4.每一個人天天都要向代碼庫主幹提交代碼

5.每次代碼遞交後都會在持續集成服務器上觸發一次構建

6.保證快速構建

7.模擬生產環境的自動測試

8.每一個人均可以很容易的獲取最新可執行的應用程序

9.每一個人都清楚正在發生的情況

10.自動化的部署

原則

1. 全部的開發人員須要在本地機器上作本地構建，而後再提交的版本控制庫中，從而確保他們的變動不會致使持續集成失敗。

2. 開發人員天天至少向版本控制庫中提交一次代碼。

3. 開發人員天天至少須要從版本控制庫中更新一次代碼到本地機器。

4. 須要有專門的集成服務器來執行集成構建,天天要執行屢次構建。

5. 每次構建都要100%經過。

6. 每次構建均可以生成可發佈的產品。

7. 修復失敗的構建是優先級最高的事情。

8. 測試是將來，將來是測試

咱們的持續集成流程

生成列表：

失敗結果：

成功結果：

推行每日站立會議

咱們過去老是很死板的在項目經理和開發人員之間互動——這個任務你作的如何了？那麼如今，咱們須要這麼一個短會：

目的：

• 團隊成員間工做進度的溝通和協調；
• 幫助團隊聚焦於每日活動，而且便於更新任務板和燃盡圖；
• 細化任務，儘量的將任務具體到天，讓你們都明確知道今天應該作什麼！

時間：每日早晨10點，時長控制在15分鐘左右

內容：

• 從上次站立會議到如今，你完成了什麼?
• 從如今到下次站立會議，你將要作什麼?
• 你遇到什麼阻礙，須要其它人如何幫你?

注意：

1. 不要遲到，延時，或者坐下
2. 不要在會議中討論技術細節以及溝通需求。

提示：團隊成員在聆聽他人發言時，都應該想這個問題：「我該怎麼幫他作得更快？」

簡單

產品伊始，我花了一個月的時間來制定了插件式架構，實際上如今這個架構看起來已經不太適合當前的業務。需求一直在變，咱們儘量的去設計與開發，可是如今，不少設計只是當時看起來很好罷了。咱們抱怨過設計缺陷以及架構缺陷，甚至「抱憾終身」，那麼如今開始，咱們再也不過多的設計——而是注重規範與重構。

咱們不可能預期後面需求會如何變化，因此不可能一開始就構建一個完美的架構來適應之後的全部變化。所以敏捷團隊不會去構建明天的軟件，而把注意力放在如何經過最簡單的方法完成如今須要解決的問題。若是已經預計到了確定存在哪些需求擴展點，咱們在一開始是否須要考慮呢？這時咱們須要根據本身的理解去決定是否考慮，若是深信在明天發生了這個問題也能夠輕易處理的話，那麼就最好先不考慮。

所以在後面的開發中，咱們的法則就兩個字——簡單。簡單設計，簡單架構，簡單編碼還有簡單評估。

另一點，咱們須要注意的是，數據庫咱們也再也不作過多的設計——也就是咱們須要認同一點，數據庫的設計是隨時能夠變動的，也就是咱們幾乎不進行預先設計。

微博上有人說「好的架構是進化來的，不是設計來的」。的確如此，其實還能夠再加上一句「好的功能也是進化來的，不是設計來的」 。——《淘寶技術這十年》

注意代碼規範，提升代碼的可讀性

簡單並不意味着沒有規範。簡單和規範的目的都是爲了提升代碼的可閱讀性，提升代碼的可閱讀性是爲了便於代碼修改以及重構——也就是增長代碼的可維護性。

以下圖所示，在有條件的狀況下，咱們會逐步實行如下步驟：

若是說提升代碼的可讀性是爲了便於重構，那麼自動化單元測試則是重構的保證。

利用反饋以及真實的數據來完善產品

以下圖所示，咱們已經開發了不少功能，咱們儘量的使每一個功能完善。可是實際上，咱們並不清楚用戶喜歡哪些功能，這些功能的用戶體驗具體如何，甚至是在用戶的環境下能不能用！

那麼如今開始，咱們必須以真實的反饋以及真實的使用數據來不斷的完善咱們的產品。

下面是反饋流程：

迭代規劃會議

迭代規劃會議是指在每輪迭代開始時進行的規劃會議，定義本輪迭代的目標，承諾本輪迭代中要完成的工做，提早識別和評估可能出現的風險，並經過合理的估算調整項目的迭代範圍。

目標

• 制定合理的迭代範圍和目標
• 明確迭代的開發任務

要求

• 如無特殊緣由，產品團隊利益相關者均需參加
• 會議召開前，會通知全部利益相關者具體開會時間

內容

• 這裏我要求將反饋審批與討論放在這裏進行，以減小大型會議的次數
• 會議只討論下次迭代內容以及任務優先級，並不涉及工做量的評估以及時長的評估

會議結果

明確迭代範圍與目標，明確這次迭代的開發任務

評審會議

在每次衝刺結束，咱們都須要進行一次評審會議，讓團隊向產品負責人和利益相關者展現已完成的功能。

也就是「全部的sprint（衝刺）都結束於演示」！

目標：

1.增強團隊的自我承認。

2.展現功能、回答利益相關者對展現的疑問並記錄所指望的更改與反饋。

3.評審會議能夠吸引相關利益者的關注，讓其餘人瞭解團隊在作些什麼，並獲得重要反饋。

4.作演示也會迫使開發團隊真正完成一些工做（好比那些完成了99%的功能）。

時間：每一次衝刺完成時根據狀況召開。

要求：

1.團隊成員都可主持。必須準備PPT，能夠很粗糙，可是必須有條理。

2.確保全部人員都清晰目標，若是有人對產品不知道，則花幾分鐘來進行描述。

3.團隊根據本次迭代內容，逐個地介紹此次 Sprint 的結果，和演示新功能。

4.會議過程當中，須要記錄需求變動、新想法、新需求、Bug或問題以及障礙。

5.若是功能沒法演示，則以報表或者報告甚至其餘任意形式證實。

會議結果

對此次 Sprint 的結果和整個產品的開發狀態的共識

注意：

• 讓演示關注業務層次，不要關注技術細節。注意力放在「咱們作了什麼」，而不是「咱們怎麼作的」
• 有的sprint可能會包含不少bug修復等功能，在評審會議中不要演示太多一大堆細碎的bug修復，除非這個很重要。

事實上，後續咱們還能夠加上估算會議以及sprint回顧會議，可是目前我想將這些內容在平常探討中完成。除非有必要，咱們纔會單獨召開。

常常檢討

上圖是孔子，曾經子曰….，這裏就不贅述了。

敏捷不能照抄照搬，所以，咱們須要常常在如何才能更有效地工做方面進行檢討，而後相應地對本身的行爲進行調整。

因爲不少不肯定性因素會致使計劃失效，好比項目成員增減、技術應用效果、用戶需求的改變、競爭者對咱們的影響等都會讓咱們做出不一樣的反應。而敏捷不是基於預約義的工做方式，而是基於經驗性的方式，對以上這些變化，咱們必須經過不斷的檢討調整來保持團隊的敏捷性。好比，反思會議。

反思會議

根據項目須要舉行。其目的不是爲了找到治癒方案，而是要發現哪些方面須要改進。項目成員都可召開與推動。

要求：

1.從過去中學習，指導未來。

2.改進團隊的生產力。

3.輪流發言。每一個人都有機會在不被人打斷的狀況下講出本身的想法，他認爲何是好的，哪些能夠作的更好，哪些須要改變。

注意：

1.不要讓管理層人員參與會議。

2.不要在團隊以外討論找到的東西。

會議內容：

1.過去哪些作的不錯？哪些應該改進？

2.咱們能作什麼？哪些不在咱們掌控以內？

3.意見交流

始終保持讓團隊坐在一塊兒

如今，咱們都是坐在一塊兒的，可是從此咱們會始終保持這種狀態。

「一塊兒」意味着：

• 互相聽到：全部人均可以彼此交談，沒必要大聲喊，沒必要離開座位。
• 互相看到：全部人均可以看到彼此，便於協做。後續還能夠考慮放置一個實體的任務板，便於團隊隨時可以看到進度。
• 隔離：若是大家整個團隊忽然站起來，自發造成一個激烈的設計討論，團隊外的任何人都不會被打擾到。反之亦然。
• 隨時溝通：好比我須要協助
• 不過於依賴文檔和工具：好比任務在Worktile上分配完畢，也給他們打個招呼吧。

保持可持續的開發速度/精力充沛的工做

敏捷開發講究的是高效工做，並且是持續的高效工做。那麼咱們須要注意如下幾點：

1.儘量避免加班（幾乎全部的敏捷開發模式都反對加班，由於加班工做在軟件開發中會下降生產率，並且會下降產品質量。咱們目前還沒法保障不加班，可是咱們要儘量的避免加班——將當天的事情在工做時間內完成）。

2.上班時間保持充沛的精力（好比早睡早起，喝點咖啡等等）

3.集中精力

精誠合做的團隊理念

• 產品不屬於我我的，整個團隊都必須對其負責。那麼在需求評審、需求評估、迭代規劃、開發交流的時候，你們都應該積極參與
• 必須達成共識，必須明確每次迭代的內容，並且知曉本身的和整個產品的進度
• 每一個人再也不是單獨的個體，在交流的時候，你不只僅只關心本身相關的模塊，你還得爲你們出謀劃策，甚至是幫忙
• 積極溝通，固然文檔不是必須的，可是有準備的溝通是必須的！

不斷的提高本身

就如上篇所說，系統設計、編碼、單元測試、開發測試、重構等關鍵任務都須要咱們本身（開發人員）來完成，也就是咱們必須得肩負起更多的使命——咱們再也不是隻關注開發，只專一於本身的開發任務，咱們是全能的（測試、開發、設計甚至管理）。

每週講座

目的：鼓勵你們交流、分享、學習甚至是反思。

講座內容：技術、經驗、心得、建議、產品與團隊思考都可，亦可召開反思會議。

機制：每週一次，一次僅限一人，輪流講座，次序能夠根據須要調整。

時間：每週週四下午，時間和日期能夠更改，可是須要提早通知。如非客觀緣由，不然不能取消。

要求：必須準備PPT以及演講素材。

時長：半小時左右。

講師：團隊成員。

參與人：無限制，自願參加 
講座完成，須要將PPT和相關資料附加到相關任務，後續統一歸檔到Sharepoint相關文檔庫。

規範以及梳理意識

不管是本身，仍是針對整個產品，咱們都必需要有規範以及梳理意識，這個意識不能單靠我我的來推進，須要你們自發的來遵照以及完善。目前咱們作到了如下幾點，可是我但願你們在遵照的前提下，反過來推進這些機制的完善，而且相互監督：

    

無規矩不成方圓，團隊還將試行行爲規範和準則，實行扣分制。具體請查看相關文檔說明。（後續會介紹）

最後，嗯，好比長期提供咖啡

其實說了這麼多，仍是這句比較實在。

最後

敏捷開發之路，咱們還需不斷摸索前進。

我知道個人將來不是夢
我認真的過每一分鐘
個人將來不是夢
個人心跟着但願在動

——張雨生《個人將來不是夢》