需求又要改？

項目上線時間又提前了？

老板還嫌增長不夠？

團隊都開始灰心喪氣了？

來看看京東內部是如何解決這些讓人焦頭爛額的棘手問題。

1

兩次失敗之后成功支持雙11活動

京東每年兩次大的的促銷活動中都會邀請第三方商家來加入京東的促銷活動。在沒有新系統之前，執行的方式簡直是慘不忍睹啊。全部人工線下組織并手動要求第三方來報名，一個運營人員面對幾百個商家通過電話確認商家是否參與本次促銷，有怎樣的商品參加促銷，并要求對方商家發送一份Excel表格給京東再做統計。

于是就產生了一個很自然的需求，所有的商家如想要參加京東的活動，只需要在這套系統上提交一下自己的信息和商品就可完成——即活動管理系統。

你以為就這么一番風順的投入研發，上線產品，成功支持雙11活動了？

Too Young！Naive！?

▍一波三折

為了配合促銷活動，項目從開發到上線被要求在兩個月內完成，于是研發們開始了瘋狂的加班之旅。但運營人員在使用系統進行活動發布的時候，發現只能解決一半的問題，剩下的很多工作還是需要手動去完成，甚至根本沒法使用（連續兩次出現）。而研發團隊也在反思為什么自己做的系統，無法達到運營人員的要求呢？這該怎么辦？

▍盲人摸象的教訓

團隊第一步首先要做的就是分析一下這個系統——到底是誰在用。而解決這個問題的前提是：需要了解你的用戶是怎樣操作，怎么使用，怎么工作的。經過研究之后，會發現前兩次的研發都是接到用戶需求之后，就開始著手進行了。雖然辛苦工作，但是沒有了解業務場景，沒有了解用戶怎么使用軟件。

▍痛苦蛻變后的成長

得到了敏捷開發的指點之后，團隊開始聽痛點，分析誰在用，了解使用場景。并采用小版本迭代，邊做邊調整，提高和促成團隊的高度合作，并且還想了一個對策：把具體操作人員（如運營人員，業務人員）聚在一起，并找了其中幾個代表，讓研發人員坐到他們旁邊，看他們一天是如何進行手動操作的，如何收集第三方的活動，如何和第三方聯系等等。

?

▍成功支持雙11大促

為了杜絕類似的失敗再次重演，我們又勸說運營人員派出一個代表來到研發部門，坐到研發人員當中去。這樣的好處是能實時定位問題，比如，商家是需要提交這些字段或者數據的，并且研發剛一開發完的功能，馬上就可以讓運營部門的代表當即操作測試，檢測看看是否是運營人員想要的。后來項目圓滿完成，極大促進了促銷活動的效率。

秀一張劉老板的郵件來證明一下哈哈。

2

90天內兩個上市公司順利融合，業務同步增長10倍

今年5月份，京東發布了一條重磅消息：戰略入股途牛。因為途牛在OTA這塊拿的代理折扣都很低并且服務完善，所以用戶在購買這方面東西的時候，都愿意在他們的網站上進行。合作的結果就是大家在京東上搜索度假或者旅游產品，大部分都來自于途牛。

?

▍三步迭代，快速開發

因為開發時間只有兩個月，團隊開始嘗試增量開發的方式。時間上劃分成3個迭代加上1-2周的回歸測試，我們將需求劃分為三個等級，在第一個迭代階段重點解決重要緊急的需求；第二迭代處理或優化一些功能上的需求；而其他需求擺放在第三迭代里。

?

具體來說第一個迭代我們只完成了商品詳情，下單和支付功能，而第二個迭代里，我們加入了列表頁功能，價格日歷功能；而在第三個迭代里，我們加入了搜索功能。團隊協作上引入了Scrum的模式：每天幾個團隊的leader或者項目負責人就當天出現的問題進行過濾，進行到什么階段，該項目或內容誰應該跟進，出現的問題什么時候給出反饋等等。這使得團隊的狀態十分的透明化。

美劇《硅谷》中也提到了Scrum敏捷開發

▍上線時間被提前？當機立斷砍需求

?

在第二次迭代進行的時候，出于配合大促銷活動的考慮，上線日期被提前了，項目開發周期被縮短兩周左右時間。因為第二階段的迭代已經開始，且無法進行變更了，于是團隊開始迅速調整，看第三個迭代的事情有哪些是可以拿掉的。最后砍掉了一些不太重要的需求（如一些優化、一些操作方便性的東西），從而保障了促銷活動順利進行。90天里完成了多項業務分支的融合，并且GMV（商品交易總額）同步增長超過10倍！

?

根據上面親身經歷的兩個例子，我總結出一套轉型模型來分享給大家：

3

轉型模型：一個核心價值，四個基本點

講模型之前需要提醒大家的是：不管做什么都會有一個模型，模型就是我們從實踐中總結出來的，可能是有效的但也可能是無效的套路，且需要不斷的去驗證不同的場景下的可行性。

▍如何定位最關鍵最有價值的事情？

軟件開發中最關鍵的地方在于【要解決最核心的問題】，而找對用戶最核心的問題是什么就是最有價值的事情。這里提供給大家一個非常方便的方法——產品待辦列表。

▍教你使用一份好的產品待辦列表

唯一排序（?Ordered）

還在使用傳統的方式（根據重要和緊急程度劃分）搞需求的優先級？一旦出現異常情況，就會立馬完蛋。分來分去其實仍舊不知道該【先】做哪個！因此記住一個重要的原則！即【唯一排序】，一定要排列出唯一的先后順序。而遵循的排列準則第一個就是：價值。按照價值高低來排序，這樣就會使得優先完成的一定是價值最高。

詳略得當（Detailed Rightly）

需求也要分詳略。對于開發成本只有兩三天的需求，應該拆分到比較小而詳細，對于需要一個月或者更長時間的需求，則不需要那么詳細。不要求把所有需求都寫入需求文檔中——這樣的做法是無用的，快速迭代的當下，很多東西是在變化的，因此需要詳略得當。

動態可變（Dynamic）

突然又要加需求了怎么辦？很簡單，直接加入當前的代辦列表中。由于后面的代辦事宜還沒開始制作，加入一個新需求并不會有任何影響，后續的需求排序是可以隨時調整，哪個價值更高，可以調整前置。簡而言之，內容方面發生的變化，要對其進行估算；驗收條件發生變化，要對其進行更新。除了當前正在執行的需求是不能改變的之外，往后的需求都是可以改變的。

大小可估算（Estimated）

需求怎么估算大小？根據實現成本和價值兩個維度來估算，相同價值的需求當然先去消耗人月少的需求，如果很難估算的話就要考慮是不是需求沒有想清楚，沒有進行拆分，拿出你想清楚的部分，再將其拿到前置位置。 成本也很重要，如果沒有將核心和需求處理好，后期的敏捷實踐很可能僅僅是皮毛。

▍牢記四個基本點

透明——暴露團隊的所有細節

軟件開發很多東西不是透明的，舉個例子：你問程序猿任務完成了多少？假設他自己計劃這個任務需要2天時間。今天是第一天，當晚你問他這個任務完成的如何，他告訴你他現在完成了90%，你一定很興奮，心想才兩天時間，第一天就完成了90%，十分的不錯。然而，第二天下班的時候，你再去問程序猿做完了么？他告訴你他完成了95%，這說明什么問題？完成的百分比根本不可靠！甚至毫無用處，很多細節藏于其中是你無法察覺和發現的。

所以，我們希望要透明。透明怎么去實踐呢？很簡單：任務板

用任務板把所有團隊認為應該展現出來的信息都展示出來，都暴露出來。將所有需求及拆分出來的任務（開發的，測試的，待上線的等等），根據自己團隊的實際情況，做一個任務板。

?

假如自己有一個便簽貼在一個位置，三天都不動，那么團隊其他人看見了，自然而然會來問你什么情況，你在做什么，三天你的任務都沒有進展。用這種形式將團隊進度都透明化。

▍迭代——盲目重復不可取

敏捷開發最重要的特點應該是：【迭代增量式軟件開發】。迭代的字面意思就是重復，但同時要警惕盲目的重復，給大家提供一個盒子理論作為指導：

?一個是時間盒：重復一件事情，要在時間限定的范圍內，比如建議為2周的迭代形式進行，2周后就結束，并進行回顧和反思，并要拿出潛在可交付的軟件。

另一個就是資源盒，即限定資源，相當于不要把所有的雞蛋都一次性全部放在一個籃子里，小成本試錯，快速迭代。

▍反饋——三個實踐方法教你如何正確的反饋

在案例1中我們為什么把運營人員放到開發團隊當中去？就是要實時的反饋。 Scrum之父Ken Schwaber說：Scrum就像你的丈母娘，不斷指出你的問題在哪，錯在哪，Scrum只是不斷的暴露你的問題。反饋在敏捷中可以有三個實踐方法：

?

（1）每日站會——每日站會中，每個成員都應該回答三個問題：昨天我完成了什么，今天我打算完成什么，工作中是否遇到什么問題并且不超過15分鐘。

?

（2）評審會議——評審會議最重要的是有人給你反饋而不是無聊的演示demo然后鼓掌散會。產品經理在觀察和獲取到用戶在使用自己產品的過程中的反饋才是有意義的，才是值得評審的。

?

（3）回顧會議——要定期開回顧會議，且還要在會后產生一個行動計劃。建議是每周二、每周四展開產品負責人和團隊有30分鐘的碰頭會，這就是在解決問題和分歧的會議。

▍教練——團隊里需要懂敏捷的成員

如果想做一個成功的敏捷開發轉型，不管是內部教練還是外部教練，一定要有一個人需要知道：什么樣叫真正的敏捷軟件開發？什么樣是形式的？什么樣的算是對付對付？——要能夠真正理解這些東西，需要有一個教練來理解。

歡迎大家到PMCAFF社區和我一起討論交流關于Scrum敏捷開發的問題。

點擊?閱讀原文?與產品經理們探討問題

總結

以上是生活随笔為你收集整理的京东业务增长10倍背后的敏捷开发秘籍【案例+分析】的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。