敏捷開發：不只要快，還要狠準

/ 程式設計

什麼是敏捷開發

現在每個軟體工程團隊都在討論敏捷開發，到底什麼是敏捷開發，可不可以簡單一點講？可以！

只要記住1331：一個核心行為，三個原則，三個好處，一個禁忌

我直接整理成兩張圖來解釋

深入聊聊敏捷開發

我其實蠻認同敏捷開發這個軟體方法，在這個需求快速變化的世代，速度就是一切，但是敏捷開發其實是雙面刃，聊禁忌的時候會解釋為什麼

如果是面向客戶(2B)，基本上很多情況客戶都不清楚自己的需求是什麼，描述出來也都模模糊糊，你不如先做一個DEMO給客戶看，甚至逐步完成小項就丟給客戶看，並得到客戶的回饋，若全部完工了才給客戶看，很常發生被大改或不滿意的悲劇

如果是產品開發(2C)，很多idea發想，都是想得天花亂墜，到底有沒有市場需求，即使做了詳細的市場調查和評估，都有可能失準，因此早點上線是水溫可以避免不必要的功能開發工程

敏捷開發有什麼好處

  1. 產出不會歪樓
    • 小量快速交付，取得回饋，快速確認需求，可以避免系統不符需求，或省掉很多調整需求的開發成本
    • 有時候可能只是做一個Demo畫面，可以讓客戶看一下，客戶就有一些想調整的想法，對於客戶來說，有時候需求自己都不清楚，等到整個系統做出來，才發現好多東西想改，如果是做產品也很重要，盡快將產品上線試水溫，使用者是現實與殘酷的，不好用，系統做再美再精緻，沒人要用就是沒人要用
  2. 系統穩定可用
    • 提早交付、快速交付、時刻可用，這樣的工作狀態，不只讓客戶因為高效率而心安，一個穩定的系統更要長時間不停的、大量的測試，才能提早發現問題後修改
    • 有時候系統壓線才上線，常常會在很小細節產生低級的Bug，而且是真的很難被發現，因為那些位置都不是常常會有使用者會去用到，很多很奇耙的反向操作案例，真的只能經過大量UAT才有可能發現BUG
  3. 應對快速變更
    • 敏捷開發有一套SOP去管理使用者的反饋，然後再延伸規劃出調整工項，這樣一來面對改變就能很優雅的應對 (前提是不能過度變更)

敏捷開發有什麼禁忌

談好處的相反是不是要談缺點，但敏捷開發與其談缺點，更精準來說應該要討論「是不適合導入」和「禁忌」

在遵循敏捷開發的團隊，他們交付專案很頻繁，這時候如果敏捷開發做得很到位，團隊運作會很輕鬆且產能很高，反之如果敏捷做不好，快速交付本身就是一個壓力，頻繁改動程式碼本身也會產生Bug風險，團隊處在高壓力又高風險的團隊造就的結果可能是… 敏捷離職？

而敏捷開發，執行敏捷開發的管理者是一個關鍵，因為快速交付帶來的壓力和風險到底如何消化與管理，是非常需要專業的，幾個議題可以思考：

  1. 面對需求，怎麼樣避免將客戶需求確定避免頻繁更改需求(產品面是怎麼樣讓直接消費者痛點、爽點)
  2. 面對允許需求變更的大量開發項目，敏捷開發需要有效的項目管理和優先順序管理，以確保項目保持方向和節奏。
  3. 面對突然緊急的項目要插單，要如何消化與管理
  4. 敏捷開發不一定適用於所有情境，舉例面對比較保守且比起交付價值更注重結案的客戶，其實瀑布式開發是更適合的

團隊是否要導入敏捷開發

列出下列6點評估

  1. 客戶參與度高嗎？
  2. 項目有足夠複雜到需要敏捷嗎？太簡單的項目，就直接做掉就好，不用找虐
  3. 團隊組織是否足夠開放、足夠有默契，強行導入怕是敏捷不起來，先吵起來
  4. 團隊能力夠不夠？團隊需要具備相應的敏捷開發技能，沒有的話就要先培訓
  5. 客戶需求經常變化？沒有的話也沒必要
  6. 公司高層要支持，家裡老大都不支持，會推動不了

敏捷開發的實際運作

導入階段

  1. 敏捷教育和培訓： 在導入敏捷開發之前，團隊成員需要接受相關的敏捷培訓和教育，以瞭解敏捷方法論、原則和實踐。這有助於確保所有人對敏捷流程有一個共同的理解。
  2. 選擇開發方法： 在導入階段，團隊需要選擇適合他們的敏捷開發方法，例如Scrum、Kanban、XP等。這個選擇將決定工作流程、角色和時間表。
  3. 團隊組建： 團隊成員需要確定其角色和職責，例如Scrum Master、產品負責人和開發團隊成員。這些角色在整個敏捷過程中扮演重要角色。
  4. 建立產品待辦清單： 團隊和產品負責人合作，創建一個優先級別的產品待辦清單，該清單包含要開發的功能、故事和工作項目。
  5. 選擇發布周期： 團隊需要確定其發布週期，即多久將新功能或版本交付給用戶。這有助於確保產品按時交付，並定期獲得用戶反饋。

運作階段

  1. 迭代開發： 團隊開始進行迭代開發，每個迭代通常持續2至4週。在每個迭代中，團隊從產品待辦清單中選擇一組工作項目，並致力於完成它們。每個迭代的結果應該是一個可工作的產品增量。
  2. 每日Scrum（或Daily Standup）： 團隊每天召開短暫的每日Scrum會議，通報進度、問題和障礙。這有助於確保團隊保持協調，解決問題並維持進展。
  3. 用戶回饋： 在迭代結束時，團隊展示新的功能或增量，並收集用戶反饋。這有助於調整產品待辦清單並確保產品滿足用戶需求。
  4. 迭代回顧： 在每個迭代結束時，團隊進行迭代回顧會議，討論過去迭代的表現，並提出改進建議。
  5. 持續改進： 敏捷開發強調不斷改進。團隊應該定期評估其過程，尋找機會來提高效率、品質和用戶滿意度。
  6. 追蹤和監控： 團隊應該持續追蹤工作進度、用戶反饋和產品性能，以確保目標的實現。
  7. 週期交付： 在適當的時候，團隊將產品或功能交付給用戶，進行實際使用和驗證。

敏捷開發的實踐工具

  1. 工作管理和任務分配：
    • Jira： Jira是一個知名的工作管理和項目跟蹤工具，特別適合敏捷開發團隊，支援Scrum和Kanban等敏捷方法。
    • Trello： Trello是一個視覺化的工作管理工具，可用於創建看板，追蹤任務和分配工作。
    • Asana： Asana是一個多功能的工作管理平台，適用於項目管理和協作。
  2. 代碼版本控制：
    • Git： Git是一個用於版本控制的開源工具，常與代碼托管平台如GitHub、GitLab和Bitbucket一起使用。
  3. 持續集成和持續部署（CI/CD）：
    • Jenkins： Jenkins是一個流行的CI/CD工具，用於自動化構建、測試和部署流程。
    • Travis CI： Travis CI是一個用於持續集成的在線服務，支援多種代碼庫和語言。
  4. 測試和質量保證：
    • Selenium： Selenium是一個自動化網頁測試工具，用於自動化測試Web應用程序。
    • JUnit和TestNG： 這些是Java編程語言的單元測試框架，用於測試Java應用程序。
    • Postman： Postman是一個API測試和自動化工具，用於測試和驗證API端點。
  5. 協作和通訊：
    • Slack： Slack是一個團隊協作和通訊工具，用於即時消息傳遞和文件共享。
    • Microsoft Teams： Microsoft Teams是一個整合在Microsoft 365中的協作平台，支援視頻會議、文件共享和即時通訊。

一些心得分享

我自己很喜歡敏捷開發，把敏捷開發升級成一個精神，一個以終為始、時時反思的精神，在這個變化快速的時代，很多管理領域都以這樣的精神延伸出對應的原則，就好比創業會用到精實創業(lean start-up)，職場上的目標對齊，都有避免歪樓原則在內