對現在的互聯網產品設計來說，尤其是對創業公司，是一個快速開發、快速驗證的時代。團隊工作方式如何應付快速開發和調整的節奏？敏捷開發（Scrum）給了答案。我們可以看看京東內部是如何進行敏捷開發的（內容根據pmcaff公開課整理而來）。

       價值為核心，透明、迭代、反饋和教練為基本點

       京東的Scrum模型中，有一個核心、四個基本點。分別是堅持以為用戶提供價值為最核心、保持研發團隊的狀態和進度透明、控制對每個迭代周期的時間/資源限制、快速獲取反饋、在敏捷轉型初期，必須要有敏捷教練輔導。

      核心：價值--用戶的問題是什么？

      時時刻刻思考用戶的問題是什么？我為什么要做這個功能。目的就是在工作中一定要做有價值的事情。

      在實踐時，為了保證這個問題，產品必須使用好產品待辦列表的工具，好的產品待辦列表有以下4個特征：

      排序的（Orderd）

      這里不同于日常工作中常規優先級排序，常規的優先級排序有個弊端就是對需求的先后定義比較模糊。比如有三個需求都定義為P0級重要需求，這三個需求哪個在前，哪個在后？

       但是在Scrum中，要求產品經理對每個需求根據價值進行排序，每一個需求都有一個唯一順序。若是兩者價值差不多，就以實現難度參考，越簡單的越靠前。

       詳略得當的（Detailed rightly）

       當前的迭代和下個版本的迭代需求必須很詳細，再之后的迭代可以相對顆粒粗一些，最往后，顆粒可以越粗。

       每個需求的大小要得當，有個標準值是：一個需求一般是一個團隊2-3天的量。

       動態的（Dynamic）

       待辦列表內，除了當前正在迭代的需求外，其他所有需求都是可變的

       估算過的（Estimated）

       代辦列表內所有需求都是團隊一起估算過的。

       基本點一：研發團隊的透明

       必須保證對研發團隊的狀態和進度透明，為此任務板是個很好的工具，尤其推薦物理的任務板。優點是所有人時時刻刻都能看到，成本低，操作起來靈活簡單

       基本點二：對迭代時間和資源的控制

       對資源進行限制，達到低成本的進行產品驗證。同時對每個迭代周期的時間也進行嚴格限制，一般以兩周為一個迭代。兩周后不管完成與否，迭代結束，結束后大家一起回顧和總結。

       對迭代周期的限制好處是每個周期內團隊可以拿出真正的成果。

       基本點三：快速獲得反饋

       在Scrum中，反饋是至關重要，因此推薦三個會議：

       每日站會：
       每日開始工作前，花出不超過15分鐘的時間大家站一起開個小會。要點是：昨日完成了什么？今天做什么？工作中有什么問題？

      目的是讓團隊的所有人都了解其他人的進展，及時發現問題并解決。

      評審會議：
      迭代結束后，把所有利益相關人員聚在一起，讓其他人體驗并指出問題。可以的話，可以邀請最終用戶，讓用戶操作，產品一旁拿紙筆記錄細節。比如：用戶操作時，在哪不順暢，在哪用戶表情有變化等

      回顧會議：
      定期團隊開一次回顧會議，整頓工作，反思工作流程能否優化，最終產出可操作性的行動計劃。

      注意行動計劃必須是定義清晰，可操作性強的。不能抽象，比如出現類似“改善”之類的。

      基本點四：Scrum初期必須要有教練指導

      Scrum初期從內部或者外部尋找教練，指出日常工作中，哪些是敏捷、哪些是非敏捷、哪些才是正確做法等