關於Scrum

即刻做爲一個創業公司，不論是團隊仍是產品都在快速變化。在提高每一個人自身能力的同時，團隊協做也慢慢成爲一個重要的部分，所以咱們不只引入了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. 對於一個年輕的公司，年輕的團隊來講，須要衝勁，更須要專一和執行。

---

PS: 若是你認同即刻的文化，又喜歡即刻的產品，那還等什麼？一塊兒來吧！有至關多的職位等着你。連接: 加入即刻