Scrum敏捷式開發
敏捷<>快，比較彈性的迎向變化，客戶常說這個一定變，這句話一定是假的。
Last updated
Was this helpful?
敏捷<>快，比較彈性的迎向變化，客戶常說這個一定變，這句話一定是假的。
Last updated
Was this helpful?
透過增量開發與一般傳統開發顛倒，一般傳統開發必須資料備齊，才能進行開發，否則無法進行。敏捷式是透過短反覆調整而進行開發與發展。常用技術為Event Storming、DDD、clean architecture、TDD，滿足。
使用敏捷專案所有人員都要參加，透過共通了解需求變更並共同參與分析規劃並將每項任務透過投票，來制定該項難度分數：1、2、3、5、8、13，但因為每個人應自身狀況定義該功能難度也不同，若點數太高需切開重新討論，最後透過投票來決定該分數，通常分數即時數，並定義sprint長度，一般為兩周，開發人員透過爭取工作人員滿足預定時數，兩周後進行驗收，當下於會議。中進行開發進度確認。需求討論>分配任務＞衝刺>驗收(週期)。
一般傳統開發可能僅PM與SA參與需求收集收集，將需求透過文件撰寫，讓工程師進行功能開發，但這樣常常發生某些事情，客戶提出需求跟收集者分析後，再透過文件至少最高完成度為80%，工程師再透過文件需求精準度*80%。利用Event Storming，將所有相關人員都進行專案業務討論，並透過並透過該領域下【通用語言】，例如在餐廳系統中訂單稱為ticket於購物網站系統可能成為Order，在透過多人溝通與投票決定系統定義使用名稱，
透過貼便利貼方式將所有相關人員進行開發討論，其中常用便利貼顏色為
橘色（正方形 76*76）：Event 事件
藍色（正方形）：Command 命令
紫色（長方形）: Policy/Process 商業政策/流程
黃色（小張長方形）:Actor 角色
黃色（長方形）:Aggregate 聚合
粉紅色（長方形）：System 外部系統
紅色（正方形）:Hotspot 熱點
紅色（小張長方形）:Problem 疑問
綠色（小張長方形）:Opportunity 機會
綠色（正方形）：Read Model 資料讀取模型
白色（大張正方形）：Uset Interface 使用者介面
首先可以先找一個happy use case，透過收Event domain(過去式)，例如：一個使用者案例為使用者須登入系統，選擇餐點餐點選擇完成後，其中接單時間僅12點~18點期間而餐點只少選擇一份。
TDD（Test-Driven Development）
是一種開發流程，中文是「測試驅動開發」。 用一句白話形容，就是「先寫測試再開發」。 先寫測試除了能確保測試程式的撰寫，還有一個好處：有助於在開發初期釐清程式介面如何設計，僅寫剛剛好需要的程式。
透過上述規則建立第一個成功案例1.營業時間內且至少一份餐點
將無建立物件建立，將第一個案例通過，並寫其他案例
滿足案例
重構程式碼
完成核心功能測試，並且每次調整都須通過，讓程式修改變得有信心。
一般來說，在傳統程式撰寫方法中通常，在MVC架構中，會controller service model撰寫完成後，才撰寫測試，但那時候測試都變得不容易了，在撰寫service測試時，會遇到讀寫資料庫或外部系統狀況發生，需再連結狀況下才能執行，可能會透過mock方式進行測試，進而放棄撰寫。直到服務啟動後手動操作功能進行測試，在TDD開發時候需常常搭配Clean Architecture 、六角形架構或洋蔥式架構以上都是類似概念的東西。
