比賽的全盛時期，手邊一個月內可能同時有三到四份企畫書。
大四之後大家開始各忙各的，打工的打工、進修的進修、實習的實習，要聚在一起開會討論這些有的沒的比賽其實也是一項滿艱辛的挑戰。
因此我們後來團隊討論過是否要依循敏捷開發方式走，雖然沒有像一般企業執行得如此徹底，不過倒是也幫助我了解新興開發模式。
近年興起一種新的開發方式：敏捷開發。顧名思義，敏捷聽起來就很快 (#
沒錯，敏捷開發就是為了因應現代時代潮流改變太快。如果照傳統的開發方法走，開發產品的速度絕對遠不及時代的趨勢，因此才會有新的這種開發方式。
比起傳統會議總是強調書面的文件，敏捷開發強調的是會議中人的互動，尤其是各團隊的互動，像是工程師跟 PM 之間的溝通。
敏捷開發有多種方式，以下講的其中之一 Scrum：
Scrum 名字的由來是指橄欖球賽在爭球的過程
（圖片來自維基百科）
而敏捷開法最大的宗旨就是，以較短時間的循環做反覆式的開發
傳統的開發方式比較像直線式的
一個步驟一個步驟的前進，因此也很容易遇到前面的問題萬一沒解決，整個開發過程就停滯，造成整體時程的延誤。
而敏捷開發為了避免有前後依賴性造成開發卡關的這種問題，解決方式就是縮短開發的循環。假設上面那個開發時程要半年，那敏捷開發最重要的目標就是把半年的時程切分成更細，可能是一個月或一周等等。
以傳統來說，原先可能一個月要做完的 A 事情。敏捷開發方法會將 A 細分成 A-1、A-2、A-3、A-4...，而第一周做 A-1、每周開會看是否有在執行上遇到困難，若有，當周會議就要解決 A-1 的問題，並且在下周繼續執行 A-2，依此類推，確保每周進度不會造成整體時程延誤。
這樣細分的循環進行方式，可以避免傳統的方式：完成 A 事項以一個月為目標，但是一個月之後，發現執行上有困難，又或者是市場上已經不需要 A 這個功能了。
所以密集式的循環開發法的優勢就是能夠時刻檢查執行困難之外，也是為了因應市場上最新需求而做調整。
團隊要執行敏捷開發最重要的就是每個人都要抱著敏捷開發的心。
（如果你找了一個不想要每個禮拜跟你 update 進度的夥伴，是要怎麼跑敏捷呢 XD）
Scrum 的角色很單純，我自己分為開發組、PM 組、精神領袖組。
以資管系的畢業專題來說，開發就是負責 coding。
PM 有點籠統，比較精確是指對產品負責的人。當然這個角色主要是要洞察市場的先驅，然後去做產品的創意改善等等的。
我自己覺得這角色是非常奇妙的存在，不過到頭來想也滿重要的。其實每次開會的氣氛、節奏都不太一樣，沒有辦法每次會議都能很順利很和平，我自己覺得這時候 Scrum Master 就是來控制節奏跟氣氛的，是個讓團隊運作順暢的重要人物。當然這角色也可以同時跟其他角色重疊的。
使用者的一個需求就是一個物件或事項，假如今天有使用者說想要網頁可以記錄瀏覽次數，那麼這就是一個物件。但是若功能太龐大也要細切，免得這個 Item 太大執行上很困難。
把 Item 轉換成你要做的事情，像是網頁要多一個紀錄次數的功能。對設計師而言 Task 就是要多設計一塊位置放瀏覽次數。
我自己覺得，Item 就是使用者想要的；Task 就是開發者要去做的。
可以分為兩塊，也是使用者需求（針對整個產品）跟開發者任務（階段式完成任務）
如果一周開會一次，那個一周就是一個 Sprint（衝刺），因此這禮拜要列出下禮拜前要完成什麼，這個列出來的清單就叫 Sprint Backlog，是這個禮拜的任務清單，也同時是下次開會的議程囉。
這個詞近年來一直看到，現在這個社會有想法比有實作還重要，因為在專業分工的年代裡，你想的到的通常會有人努力想做出來，最怕的是想不到。
而潛在可交付產品的概念是，你每周的進度必須做出來保持產品的完整性。要讓產品隨時在可以上線的狀態。不是寫完了兩個功能，結果老闆說很好那就今天上線，結果你還要回家改，這樣就不是一個可交付的產品狀態。
這樣的好處是如果做得不好，你也不會有一種因為很久以前沒寫好而後面要改一堆的技術債。因為每次 Sprint 的狀態都是隨時可交付的，所以當你發現產品爆了，要檢討的也只有這周出了什麼問題。
前面講了很多敏捷開發的好，包含可以隨時調整產品需求、確保開發時程上不會因為一些卡關而延誤。不過當然也有它的缺點，最大的困難當然就是 Sprint 主打的就是切的越細越好，但是每周開會不是很累嗎？尤其是要同時召集 PM 跟開發部門一起，開會頻率又如此高，真的超級累的 RRRR，難怪大家都說現在人壓力比較大（誤）。
iThome鐵人賽
看影片追技術