不論是在一些大型的開發(fā)團(tuán)隊(duì)，還是作為獨(dú)立開發(fā)者。我們經(jīng)常會被預(yù)算、技術(shù)迭代，以及時間限制。找到合適的工作方式去適應(yīng)這些限制, 是所有團(tuán)隊(duì)都需要去考慮的問題。

Alex Andrews 在成立 Ten Kettles 的時候花了很多了精力去考慮這個問題。直到有一天上帝把敏捷開發(fā)砸到了他的頭上，很快他就找到了適合他的敏捷開發(fā)之道。他認(rèn)為敏捷開發(fā)極大的解放了他的生產(chǎn)力。

這篇文章就會聊到他是怎么進(jìn)行敏捷開發(fā)的。

遠(yuǎn)古時代

2014年 3月 1 日，是 Ten Kettles 成立的第一天。那時候整個公司只有我一個人，沒有流程來遵循。什么時候開始工作，做什么軟件，怎么安排任務(wù)....... 都由我自己決定。

那時候，我喜歡 free style，雖然有時候會讓我不大舒服。早些時候，我在其他公司做搜索工程師, 預(yù)估工期是我最自豪的能力: 你給我一個需求，我告訴你什么時候完成，到那個時候，我把代碼拿出來?，F(xiàn)在做 app 跟那時候是一樣的，只不過設(shè)計(jì)產(chǎn)品的人換了而已，但是知道 2014 年年底，我都還沒意識到這點(diǎn)。

后來，我慢慢發(fā)現(xiàn)獨(dú)立開發(fā)者這個稱呼不是特別準(zhǔn)確。因?yàn)閷懘a甚至都不是我現(xiàn)在最主要的工作內(nèi)容，影響我工作效率的事情不是寫代碼，而是設(shè)計(jì)產(chǎn)品。

“再加一個功能... “

”不，這樣設(shè)計(jì)不對... “

”加載的時候等服務(wù)器返回了在進(jìn)入主界面....”

這些想法簡直無處不在, 我?guī)缀蹼S時都在考慮這些問題！

這讓我的工作效率嚴(yán)重低下。我的音樂類app，遠(yuǎn)遠(yuǎn)的超出了計(jì)劃。雖然最后做出了滿意的產(chǎn)品，但是現(xiàn)在回過頭去看，總想問自己，為什么那么長的時間卻只做了這么點(diǎn)事情？

結(jié)果是很好的，但是過程并不完美。我需要一個更好的工作方式。需要一個能讓我更高效，更賺錢，更幸福的工作方式！

哇，敏捷開發(fā)

一直都在重復(fù)那些無聊且進(jìn)展緩慢的工作。我決定給自己一個改變，所以我把精力放在了一些外包工作上面......

知道接觸到了一家中等規(guī)模的公司, 他們正好在使用敏捷開發(fā)來進(jìn)行項(xiàng)目管理。我開始去了解敏捷開發(fā)的, 期望她能夠讓我更高效的編程?？戳撕芏嘞嚓P(guān)的書或者文章之后，我驚喜的發(fā)現(xiàn)敏捷開發(fā)觸及到了的三個痛點(diǎn)：

• 高產(chǎn)出
• 高效率
• 更happy

于是，我開始思考在我自己的產(chǎn)品中運(yùn)用這套理論。

這家公司的項(xiàng)目做完，我去了蒙特利爾, 打算給自己放個假，也仔細(xì)的想想怎么讓這套理論給我?guī)硇б?。我重新看之前的筆記，重新讀了兩本很好的書，思考了實(shí)際情況下的一些問題，最后總結(jié)出了改革我的公司的一些辦法。

敏捷開發(fā)的基本原則

什么是敏捷開發(fā)呢？這里有一段我第一本讀到的書中的摘錄:

敏捷團(tuán)隊(duì)通常由7個左右的人組成，每個任務(wù)階段叫做一個 sprint，包括了回顧和總結(jié)的時間。敏捷開發(fā)有一個咒語"檢察和調(diào)整"。敏捷團(tuán)隊(duì)具有一個很明顯的特征：工作流程和產(chǎn)品在不斷的進(jìn)步。

獨(dú)立開發(fā)跟 5-9 人的團(tuán)隊(duì)開發(fā)還是有很多不一樣的地方的。這段話講到的內(nèi)容跟我使用的敏捷開發(fā)還是有一些區(qū)別。 我更多的是去定義整個工作流程的一些基本原則.

敏捷開發(fā)核心原則:

• 主動變化。經(jīng)常把產(chǎn)品給別人體驗(yàn)，無論是最終的用戶，測試用戶，甚至是一些懂行的朋友。這樣可以避免把資源投入到?jīng)]有必要的功能上。讓測試用去去使用 beta 版本的產(chǎn)品，及時根據(jù)反饋來調(diào)整方向，這樣能節(jié)約很多的時間。
• 效率優(yōu)先，并量化它。短期內(nèi)最大的量化指標(biāo)就是產(chǎn)出，并不是銷售或者發(fā)版數(shù)量。要知道每周完成了多少有效任務(wù), 就需要去量化它。這樣才能跟蹤進(jìn)度，并優(yōu)化它。
• 自我總結(jié)。定期去回顧總結(jié)。

如何進(jìn)行敏捷開發(fā)

知道了敏捷開發(fā)的核心原則，那么應(yīng)該怎么樣去實(shí)踐呢？

Sprint

就是在固定周期的時間里面完成特定的需求，相當(dāng)于迭代。在這個 sprint 中你應(yīng)該把全部的盡力用在完成這些需求上面。

一個 sprint 通常有一到四周，這個由你自己的風(fēng)格和產(chǎn)品決定。我自己的標(biāo)準(zhǔn)是兩周一個 sprint。我覺得這樣有足夠的時間來完成真正有意義的任務(wù)。下面是我的 sprint計(jì)劃圖：

可以看出來，每個 sprint 中都有很多時間用來做核心的任務(wù)，還有一些其他的東西:

• 每日站會 Daily Stand-up Meeting
• 每周暢想 Weekly Story Time
• 發(fā)布 Sprint Release
• 敏捷迭代回顧 Sprint Retrospective
• 敏捷迭代計(jì)劃 Sprint Plan

每日站會（5 min）

敏捷開發(fā)有一個很基礎(chǔ)的部分就是自我審查和迭代，尤其是在生產(chǎn)上面。當(dāng)我們原計(jì)劃在某一天完成某項(xiàng)任務(wù)，但是最后沒有完成，這時候就需要總結(jié)到底發(fā)生了什么，然后在去優(yōu)化你的工作流。

每日站會是敏捷開發(fā)的主要特點(diǎn)。在傳統(tǒng)的敏捷開發(fā)中，每日站會讓每個團(tuán)隊(duì)的成員都聊一下昨天的進(jìn)度，今天的計(jì)劃和存在的風(fēng)險。

• 為了簡化會議, 避免會議時間太長所以要求大家都站著開這個會。
• 讓所有成員都能跟上節(jié)奏，及時暴露出風(fēng)險和挑戰(zhàn)。

那一個人怎么搞呢？

我汲取了敏捷開發(fā)中的優(yōu)點(diǎn)。自己總結(jié)了一套適合獨(dú)立開發(fā)的每日站會: 拍短片(45 秒) 。

主要是這些內(nèi)容：

• 回顧：首先看一下昨天的短片，看看昨天定下的任務(wù)是什么。

• 總結(jié)：沒有完成昨天的目標(biāo)？想想為什么沒有完成，還有什么地方?jīng)]有做到更好。是中午開了一個會，耽誤了寫代碼的時間。還是準(zhǔn)備 App Store 的截圖花的時間超預(yù)算了。

• 準(zhǔn)備：在不到兩分鐘的時間里，思考一下今天的短片說什么，回答下面的問題：昨天做了什么？今天準(zhǔn)備做什么？什么影響了進(jìn)度。比如這樣。

  我昨天我做了 A 的 App Store截圖。今天我要寫更新日志，然后下午跟一個供應(yīng)商討論一下合作?？偨Y(jié)：在做截圖的時候花了太多的水岸，所以沒有完成本來計(jì)劃的更新日志。下次嘗試使用自動化工具。

• 拍攝：拍下這個短片，然后就好了。這些片子在最后的sprint 回顧中還會用到。

每周暢想 （30-45 min）

在每個 sprint 中，都會花很多的時間去做程序員。很少花時間去考慮公司發(fā)展這類東西，要不要做一個新的 App 、大改現(xiàn)在的 app 等燈。Story Time 這段時間就是我用來做 CEO 的時間。我建議盡量到其他環(huán)境去做這件事情，咖啡店什么的。

在 Story Time ，我會去整理一下從用戶那里收到的反饋，考慮今后加什么功能，考慮怎么運(yùn)營 app 和公司。然后把一些實(shí)際的想法加到一個列表里面我叫它需求池。

需求池里面都是一些比較大的任務(wù)。它幫助我計(jì)劃下一個 sprint。所以在 Store Time 中也需要去修改和整理需求池。比如:

在統(tǒng)計(jì)中看到了更多巴西方面的東西，這就是說，你可能需要加入葡萄牙語，而不是原計(jì)劃的西班牙語。或者可能看到了一些用戶希望的小功能。這時候也需要考慮是不是把這個需求加入這個列表。

發(fā)布

敏捷開發(fā)還有個原則就是要讓你做的工作能夠產(chǎn)出成品。這就是在 Sprint Release 中需要做的事情。不一定需要是一個完整的 app，但是把這段時間的工作拿給其他人試一下也是很重要的。讓測試用戶體驗(yàn)，從他們那兒得到一些反饋。

在敏捷開發(fā)的過程中，發(fā)布的范圍會逐漸的擴(kuò)大。比如說，最開始你可能只需要發(fā)布一個只有一兩個新功能的 beta 版。這時候可以優(yōu)先的去考慮最重要的功能，這樣能夠盡快的拿到測試反饋。如果你的測試用戶根本都沒有提到過某個功能，這就是說這沒那么重要。這也能幫你決定下個 sprint 中任務(wù)的優(yōu)先級。

Last Day of the Sprint

已經(jīng)花了9天來完成這個 sprint 的目標(biāo)，終于到了最后一天了。這一天可能是最輕松的一天，因?yàn)榻裉炜赡懿恍枰鲩_發(fā)工作。今天是用來回顧這個 sprint，計(jì)劃下一個 sprint 的一天，然后還可以休息休息。

這可能會讓人覺得奇怪，在截止日期做這樣的事情？上學(xué)的時候，我經(jīng)常會在回家的路上看書。但是這樣我會走偏方向，然后摔倒。敏捷開發(fā)也一樣，如果不經(jīng)常抬頭看看方向，可能方向就錯了。

確保方向正確，這就是 sprint 最后一天做的事情。這是一整天，或者是在是時間緊迫，半天也可以。這一天，抬頭看看周圍，確保做的事最重要的事情。因?yàn)榧幢隳惴浅５母弋a(chǎn)出，在不重要的事情上花時間也是不值得的。

現(xiàn)在來看看這天要做什么吧！

Retrospective(回顧) （小于2h）

打開一個新的文檔，或者是在筆記本上翻開新的一頁，寫下你對剛剛過去的兩個星期的總結(jié)。這是你發(fā)現(xiàn)是什么阻礙你的效率的好機(jī)會。

這寫是一些簡單的問題：

• 我完成了什么？
• 我達(dá)成了我 sprint 的目標(biāo)了嗎？
• 這個 sprint 最的好的是什么？還有什么地方可以做到更好？
• 有什么影響效率的因素？回顧每天的短片來找到這個問題的答案。
• 有什么沒什么必要的事情讓你焦慮了，或者讓你覺得很爽？

如果你發(fā)現(xiàn)出去走走比在桌子邊上回顧，那就出去走走吧！然后回來迅速的寫下你的總結(jié)。我發(fā)現(xiàn)這樣確實(shí)更有效果。

Sprint 計(jì)劃 （小于2h）

在回顧兩次 Story Time 和需求池之間，你應(yīng)該好好想想下一個 sprint 要做什么。把需求池整理一下，然后挑幾個最重要的！

下面是一個簡單的例子。說你現(xiàn)在有個快完成了的 app ，你計(jì)劃下個 sprint 加入最后一個功能，然后做一些自測工作，最后把 Beta 版發(fā)布出去。在你的計(jì)劃文檔中，就是下面的內(nèi)容：

在兩個星期的 sprint 中，可能還會有更多的任務(wù)需要完成。這只是簡單的舉個例子。

看每個任務(wù)后面的數(shù)字，這些都是任務(wù)評分。比如說，一個 1 分的任務(wù)，需要花 2 分任務(wù)一半的時間去完成。這個標(biāo)準(zhǔn)需要你自己來定。就我來說，我還是喜歡用1，2，3，5，8這樣的數(shù)字，這樣可以糾正我們低估大任務(wù)的傾向。沒有4，所以我必須得用5這個數(shù)字。

當(dāng)你完成所有任務(wù)的時候，去想想每一個任務(wù)相對于其他的任務(wù)需要花費(fèi)的時間。冷靜下來，去預(yù)測每一項(xiàng)任務(wù)需要花費(fèi)的時間。

如果某一項(xiàng)任務(wù)很復(fù)雜，但是你已經(jīng)做過很多次了，那就可以少估計(jì)一點(diǎn)時間，也就是說可以減少這個分值。如果某個任務(wù)很簡單，但是你還不熟悉。就可以多估計(jì)一點(diǎn)時間，也就是加點(diǎn)這個分值。

當(dāng)你完成任務(wù)的時候，只需要把所有分值都加起來，然后跟上個 sprint 做一個比較。如果你經(jīng)常得到 80-100分的總分，那么下個 sprint 的總分應(yīng)該就差不多是80的樣子了。

這可以說是敏捷開發(fā)中最有效的事情了，也是我任務(wù)最難做的一部分了，我經(jīng)常發(fā)現(xiàn)，我總是減少我想做的事情的評分，給重要的任務(wù)更多的評分。有了 sprint 計(jì)劃，就擦掉你上個 sprint 的任務(wù)板，然后為下個 sprint 做準(zhǔn)備！

什么是任務(wù)板(Task Board)呢？

譯者: 在之前的敏捷開發(fā)實(shí)踐中，都會有一個白板，清晰的寫上這些東西。下個部分會講到。

任務(wù)板

現(xiàn)在我們就來說說任務(wù)板。即使我在我的筆記本或者其他地方已經(jīng)了我這個 sprint 的計(jì)劃，我每天的任務(wù)還是會在任務(wù)板上組織。我把這個任務(wù)板放在辦公室的墻上。上面會寫一些東西，主要是：TODO、DOING、DONE。

每天下班的之前，我都把第二天的任務(wù)寫在一個便簽上，然后把它們貼在TODO這一塊。假如我上個 sprint 平均每天拿到了10分，我就會給下一天貼上10分的任務(wù)。

第二天早上，我就會把 TODO 上的第一個便簽?zāi)玫?DOING 這邊。這樣做能夠讓我更容易集中精力。

任務(wù)完成的時候，把這個便簽?zāi)玫?DONE 這邊?？吹?DONE 越來越多，是一件很有成就感的事情。

Rest and Explore

回到 sprint 中間來。現(xiàn)在你到了 sprint 的最后一個下午了。這個下午就好好的放松一下吧！我經(jīng)常都是坐在沙發(fā)上，看看 Raywenderlich.com 上的教程，或者學(xué)點(diǎn)新的知識。

不要把這件事情當(dāng)作例行工作那樣做。只需要做一些跟工作有關(guān)，由能讓你放松的工作。喝一杯飲料，聽聽音樂，慶祝慶祝這個 sprint 你完成的工作，多好！

一些建議

對獨(dú)立開發(fā)者來說選擇正確的工作方式是很個人的事情。這跟你的精力相關(guān)。同時也需要要激勵你，讓你成長。以這個為核心原則，就能夠找到適合你自己的敏捷開發(fā)之道了。

額外的建議：

• 在剛剛開始的時候，不要因?yàn)閷?shí)際完成的任務(wù)比計(jì)劃完成的任務(wù)差很多而感到不好。在下個 sprint 中調(diào)整就好了。不斷的調(diào)整正是敏捷開發(fā)的意義。
• 每隔一兩天就調(diào)整一下這個 sprint 的計(jì)劃。review 每一個任務(wù)，調(diào)整他的分值。如果分值變得很高，就需要把一些低優(yōu)先級的任務(wù)移除掉了。
• 計(jì)劃細(xì)節(jié)是一件很麻煩的事情。如果你跟我一樣也是兩周一個 sprint。第二個星期的計(jì)劃沒有那么詳細(xì)也是可以的。每天的調(diào)整能夠慢慢的豐富它。
• 對公司來說，有一個長期計(jì)劃是必要的，但是不要死咬住這個計(jì)劃不放。保持一個流動的需求池來適應(yīng)改變。
• 即便這是我在做 Ten Kettles 的 app 的時候總結(jié)的東西。他們在做外包的時候也是很好用的這只需要做一些很小的改動。比如說任務(wù)板，可能就需要做成虛擬的了，這樣才能讓甲方知道你現(xiàn)在是什么情況。
• 別樣了買馬克筆還有標(biāo)簽紙。

我第一次意識到作為獨(dú)立開發(fā)者，我需要更好的工作方式的時候，我想到了三個需求。更高效的產(chǎn)出，從 app 中獲得更多的收入，更多的幸福感。我也很高興這樣的改變確實(shí)帶來了這些東西。app 的迭代頻率大大的上升，每個月的平均收入增長了 18%，用戶也更滿意(在 App Store中平均分 4.75)，而且工作和生活找到了更好的平衡點(diǎn)。有了周末，一切都更好了。

結(jié)束語

這是一篇最近的采訪，關(guān)于我最近在 Ten Kettles 的的細(xì)節(jié)。

記住下面三個敏捷開發(fā)的基本原則

• 主動改變
• 效率優(yōu)先
• 不斷的總結(jié)

看起來很簡單，但是有很好工作流程，這幾點(diǎn)能夠明顯的影響你的工作。

如果你想要學(xué)習(xí)更多關(guān)于敏捷開發(fā)，尤其是在團(tuán)隊(duì)中的敏捷開發(fā)的話，這有一些資料。

我最開始看的兩本書是：

• Scrum: The Art of Doing Twice the Work in Half the Time (Sutherland, Sutherland)
• Scrum: a Breathtakingly Brief and Agile Introduction (Sims, Johnson)

這篇文章翻譯自Ray wenderlich Scrum Of One: How to Bring Scrum into your One-Person Operation