「天天開會開到天昏地暗且沒有針對性？」小程序
「團隊的任務混亂作不到責任到人？」網絡
「工做中緊急任務總得不到第一時間解決？」框架
不知道什麼時候，低效率的開會、無休止的討論、不合理的流程已成爲團隊協做看得見的殺手。協做中，你們心知肚明，深受其害，卻始終得不到好的解決。也許你該換個思路，從「敏捷開發」的方法論中找一些解決辦法了。工具
8月6日，沙拉大學邀請Ruby on Rails 和敏捷開發的重要推進者蔡望勤分享《如何實現產品的敏捷開發》，不只深刻淺出爲咱們揭開了產品從0到1的實現方法，更爲咱們全面展示了一套團隊協做的做戰方案，幫在場的成員解決以上團隊低效的困擾。post
8月講者：蔡望勤測試
參與建立時尚社交網絡公司 P1（探探軟件前身），並擔任首席技術官。後前往美國硅谷工做並深造。2016年建立深圳市百分之八十網絡技術有限公司，在給客戶開發創業型項目的同時，孵化過多個開源框架和產品，如：八十二十（80post），單麥小程序。3d
1、什麼是敏捷開發orm
簡單的說，敏捷開發是一種以人爲核心、迭代、按部就班的開發方法。在敏捷開發中，軟件項目的構建被切分紅多個子項目，各個子項目的成果都通過測試，具有集成和可運行的特徵。blog
換言之，就是把一個大項目分爲多個相互聯繫，但也可獨立運行的小項目，並分別完成，在此過程當中軟件一直處於可以使用狀態。排序
通俗地講，你去餐廳點10個菜，餐廳不是一次性給你上齊十盤菜，而是一盤盤作好後就給你上，讓你先吃着，不至於乾等過久。
2、相比傳統開發流程有什麼優點？
傳統開發流程
敏捷開發流程
若是要把兩者進行對比，不妨把傳統開發方式比喻成普通火炮，而把敏捷開發比喻成導彈。兩種武器打擊目標的過程很形象地說明了兩種軟件開發過程的區別。火炮打擊目標時，要想打得準，則要寄但願於一開始瞄得夠準，並且對目標運動軌跡估計得夠準。一旦炮彈發射出去，就沒法對速度、方向進行控制了。任何瞄準誤差，沒有預料到的目標移動軌跡變化，甚至風向的變化都會致使炮彈打偏。
而導彈就不同了，只要設定好目標方位，並不須要一開始就精確瞄準。導彈發射出去後，會持續地收集本身的位置、方向、速度並按照目標的方位不斷地調整，最終可以較準確地長距離命中目標。
而這一切的根源在於軟件開發是一個複雜的過程，所以在敏捷開發中，團隊的流程管理和團隊成員的自發協做更重要。
3、具體怎麼操做
敏捷是一種指導思想或開發方式，可是它沒有明確告訴咱們到底採用什麼樣的流程進行開發，而Scrum就是敏捷開發的具體方式了。
【什麼是Scrum？】
Scrum的英文意思是橄欖球運動的一個專業術語，表示「爭球」的動做；把一個開發流程的名字取名爲Scrum，我想你必定能想象出你的開發團隊在開發一個項目時，你們像打橄欖球同樣迅速、富有戰鬥激情、人人你爭我搶地完成它，你必定會感到很是興奮的。
而Scrum就是這樣的一個開發流程，運用該流程，你就能看到你團隊高效的工做。
首先，明確各自職責
【Scrum的三個主要角色】
產品負責人（Product Owner）：主要負責肯定產品的功能和達到要求的標準，指定軟件的發佈權力和交付的內容，同權力權力接受或拒絕開發團隊的工做成果。
流程管理員（Scrum Master）：主要負責整個Scrum流程在項目中的順利實施和進行，以及清除擋在客戶和開發工做之間的溝通障礙，使得客戶能夠直接驅動開發。
開發團隊（Scrum Team）：主要負責軟件產品在Scrum規定流程下進行開發工做，人數控制在5~10人左右，每一個成員可能負責不一樣的技術方面，但要求每成員必需要有很強的自我管理能力。
其次，弄清楚團隊協做流程
scrum開發流程
具體而言，
Step 1. 產品負責人整理需求，按照優先級列出產品條目即product backlog
產品backlog示例
產品 backlog 是 Scrum 的核心，也是一切的起源。從根本上說，它就是一個個子任務，按照重要性的級別進行了排序。它裏面包含的是客戶想要的東西，並用客戶的術語加以描述。
Step2. 產品負責人與團隊召開sprint計劃會議
Sprint是「短距離賽跑」的意思，這裏指的是一次迭代，也就是咱們要把一次迭代的開發內容以最快的速度完成它，這個過程咱們稱它爲Sprint。一個 Sprint 包含團隊一次迭代週期中須要完成的各類子任務。一樣地，把每一個Sprint中的子任務排序就是Sprint計劃會議的主要活動。
Step3. 每日站立會議
爲了保持團隊的高效溝通，團隊天天進行1個不超過15分鐘的例會。圍繞着每日例會，主要彙報三件事：昨天完成了什麼？今天計劃完成什麼？以及你遇到的困難？是的，這裏彙報的不是作了什麼，而是完成了什麼。
Step4. Sprint 回顧會議
當全部的Sprint Backlog被完成，也就表示一次Sprint完成，這時，咱們要進行 Srpint 回顧會議。在回顧會議上，每一個人均可以貢獻和討論想法。若是沒有回顧，你就會發現團隊在不斷重犯一樣的錯誤。主要討論三個點：
1） 若是咱們能夠重作同一個 sprint，有哪些作得比較好的點，須要繼續保持
2） 若是咱們能夠重作同一個 sprint，有哪些須要改變
3） 有關未來如何改進的具體想法
再次，學會運用一些工具
1）任務看板模版
任務看板包含 未完成、正在作、已完成 的工做狀態，假設你今天把一個未完成的工做已經完成，那麼你要把小卡片從未完成區域貼到已完成區域。
任務看板實例：
每一個人的工做進度和完成狀況都是公開的，若是有一我的的工做任務在某一個位置放了好幾天，你們都能發現他的工做進度出現了什麼問題（成員人數最好是5~7個，這樣每人可使用一種專用顏色的標籤紙，一眼就能夠從任務版看出誰的工做進度快，誰的工做進度慢）
2）計劃紙牌
每一個人都會獲得這13 張卡片。在估算用戶故事的時候，每一個人都選出一張卡片來表示他的時間估算(以故事點的方式表示)，並把它正面朝下扣在桌上。全部人都完成之後，桌上的紙牌會被同時揭開。這樣每一個人都會被迫進行自我思考，而不是依賴於其餘人 估算的結果。
最後，知道細節不決定成敗
咱們以往總強調「細節決定成敗」，但在敏捷開發的語境中，首先是把產品框架作出來，再在這基礎上不斷地迭代，若是連框架都沒有打好，卻一味深究細節是敏捷開發的大忌。
4、從新理解敏捷開發
敏捷開發是一種過程控制論，通俗的說，就是一種作事情的方法。
敏捷開發是一套工具集，裏面有形形色色的工具，你能夠不搞敏捷，但能夠用那麼一兩個來提升工做效率。
敏捷開發是一種企業管理方式。
5、講者推薦相關書籍
《敏捷戰事--硝煙中的Scrum和XP(咱們如何實施Scrum)》做者：Henrik Knibery