即刻作為一個創業公司，不管是團隊還是產品都在快速變化。在提升每個人自身能力的同時，團隊協作也慢慢成為一個重要的部分，因此我們不僅引入了Scrum，也在其基礎上根據自身情況不停的調整。
先看下沒有Scrum時的問題
- 產品釋出週期不穩定，迭代缺乏節奏感。
- 開發缺乏明確任務時間表，時間安排全憑自己。對於工程方面的工作比較有利，想做的可以馬上做，但是對於團隊協作開發的需求效率較低
- 產品需求不夠明確（只有idea，缺乏具體細節）時就開始動工。不可否認這樣的好處是小功能可以快速試錯，但是隨著專案發展，當多team協同開發大功能時，會極大地增加溝通成本。比如由於文件不夠清晰，客戶端A去跟產品經理B確認一個細節，完成了以後還需要通知其他產品經理C、客戶端D、後端E、測試F等等，有時候還會推翻之前的結論。這樣一來雖然看起來大家都在熱火朝天地討論，但是效率其實不高。
- 產品和開發對於工期的預期不一致，時常會互相pending，客戶端等後端介面，後端等具體需求等等。
- 經常會因為事先未考慮到的突發情況（產品活動、技術上的障礙）而delay。
- 在開發中途遇到新的需求或者idea，經常會猶豫是加到當前開發中的版本，趕一下工稍微推遲釋出時間，還是順延到下一版本？如果在趕的過程中還有另外的調整怎麼辦？
一些假設
- 就像團隊開發需要制定程式碼規範、模組呼叫需要呼叫規範一樣，團隊協作也需要敏捷開發流程規範，確保團隊間互相預期一致，減少低效溝通和互相推鍋。當出現問題，定責（不是為了blame某個人，而是找到原因）和改進就相對容易。
- 在高速變化的創業公司，流程本身應該隨著公司和產品情況不斷迭代的（元迭代？），如果某個環節大家都不滿意，應該立即優化並在下一個sprint中執行。
- 對於team leader來說，提高流程和團隊的效率比提升自己的效率更重要，尤其是對於專案環節越來越多的時候，需要儘量避免個人英雄主義。（一個大工程，光靠某一個好模組是不夠的。只有當每個模組間的資料流通暢時，工程本身才能運作良好）
- “改需求”是無法完全消滅的（在創業公司可能也不應該），但是可以通過合理的流程限制在一個可以接受的水平（好比bug無法完全消滅，但是code review流程可以讓工程師自我監督，有效減少bug）。過於靈活的調整會降低開發效率，反過來死板的流程也會傷害產品。需要不停地在兩者間做出平衡。
- 產品經理永遠是希望加入更多的功能的，而且一定能給出一些合理的理由來支撐，但是並不一定考慮實際的工作量。Scrum master謹慎評估，在必要時果斷拒絕一些短期看似合理，但其實傷害長期效率的需求，防止Scope Creep發生從而破壞團隊間的信任。
- 工程師大多傾向於在自己的領域裡單打獨鬥，天生反感開會等低效而耗時的溝通流程。如果能夠減少被打斷的次數，可以大幅提高工作效率（就像減少執行緒/上下文切換可以提高程式碼執行效率）
- 功能開發不應該佔用工程師全部的時間，敏捷流程應與工程師文化相輔相成。產品迭代、流程迭代和技術迭代、工具迭代一樣重要。
- 工程師應該參與到產品設計中去，從技術和自身角度出發提供建議，提升ownership。儘量在功能正式開發開始之前充分討論，因此這對產品需求計劃的前瞻性也提出了很高的要求。
- 對於一個功能，如果花費1個小時時間可以做到70分，但是75分需要2個小時，那麼優先選擇1個小時的做法，在下個迭代中再看情況優化。
- 一個重要的大前提是，公司能夠招到足夠優秀的人，且維持足夠好的工程師文化。這一點也是即刻一直重點努力的方向之一，在這方面不管是產品、測試、開發至少都能做到“擱置爭議，共同開發”。
執行
- 確定一個穩定的Scrum週期，如兩週。當產品的需求週期也是兩週時，那麼可以做到每兩週發一個新版本。
- Sprint planning前，產品需求應該到一個相當清晰的水平，否則每個team估算的時間成本可能與實際相比有大幅偏差，影響本次sprint計劃的制定。
- 在Sprint planning時，產品開發一起進行任務拆解，估算時間後，決定哪些功能放入本sprint，哪些延後。注意planning meeting不是需求討論或者brainstorming，不應無休止的爭論每個需求的細節。整個會議儘量控制在1小時以內。
- 當planning完成時，每個小團隊內部分配task。當分配完成時，整個sprint來自外部的任務就確定了，接下來工程師有權自主分配開發時間。大家只需要在sprint結束那天達到task完成，並開始beta測試的預期目標。
- 大家共同的預期是，在Scrum結束時，必須要有一個準release版本進行beta測試。
- 每天Daily standup meeting與大家分享目前進度，並提出可能遇到的問題（如被誰block，或者工期delay等）。一般每個人只需要十幾秒時間就能說完，因此整個meeting最多不超過10分鐘。
- 如果遇到改需求，需要team leader一起評估：類似改字型或者圖示，那可以隨時改。如果大家認為是較大功能改動（如需要花費1天以上）會影響已有的工作安排，順延到下個sprint。這對於產品team是一個負反饋，能夠促使下一次的需求計劃更加合理。
- 當遇到重大突發情況（如突如其來的流量增長、critical bug fix等）同樣需要大家一起溝通，可以延後一些相對不重要的task，但儘量不影響sprint的節奏。
快速迭代，快速反饋，快速改進，不管是產品、開發還是Scrum本身。Facebook（曾經）說Move fast and break things. 對於一個年輕的公司，年輕的團隊來說，需要衝勁，更需要專注和執行。