iT邦幫忙

2022 iThome 鐵人賽

DAY 2
2
IT管理

第一次使用Jira就上手系列 第 2

[Day2]瀑布式 vs 敏捷式-第一次使用Jira就上手

  • 分享至 

  • xImage
  •  

在開始使用Jira前,我們先來了解瀑布式與敏捷式開發的差別。
這章節你將學會

  • 瀑布式開發
  • 敏捷式開發
    • 四大價值觀
    • 12項原則
    • 敏捷方法
    • 敏捷鐵三角

瀑布式開發

瀑布式開發遵循著SDLC 的流程,需事先詳細的規劃所有細節,從需求、設計、開發及測試,除了個別完成每個階段所定義的任務之外,每個階段結束後,都要經過嚴格的審核,確認該階段的開發結果正確,才能進行下一個階段,如同瀑布從上到下。

好處是開發人員可以專注做好自己的本職,提高工作效率;壞處是專案無法對應變化,花費的時間很長,質量不高,沒有迭代與反饋,所以只要一個環節出錯,需要付出很大的代價,可能需要返回到上一個階段,甚至会延遲下一個階段。
https://ithelp.ithome.com.tw/upload/images/20220916/20112053dnyQ2YXwmJ.jpg

敏捷式開發

敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。
與傳統方法相比,它是一種時間限制的迭代方法,以增量的方式開發產品,而不是一次性提交所有產品所有功能,在開發的每個階段都讓客戶看到雛形,根據使用反饋,確認產品是否符合需求,並提出建議與校正方向,不但縮短了交給用戶的時間,提高更高的生產力及降低成本,且創造出符合客戶需求的產品。因此敏捷方法比較適合需求變化大或者開發前期對需求不是很清晰的項目。
https://ithelp.ithome.com.tw/upload/images/20220916/20112053C6M1s17AIm.jpg
在2021年,由17位著名的軟件開發專家共同發表《敏捷宣言》,成立了敏捷聯盟,正式宣佈了對四大價值觀和十二項原則

四大價值觀

  • 人員交流重於過程與工具
    強調「人」,人才知道如何完成任務
  • 工作軟體高於詳細文檔
    強調重點放在工作軟體上,而不是把工作焦點放在文件上
  • 客戶合作高於合同談判
    與客戶建立良好的合作關係,共同解決問題
  • 隨機應變重於循規蹈矩
    專案有變化必須要隨時調整

也就是說,雖然右側項目有其價值,但我們更重視左側項目

12項原則

  1. 我們最優先的任務,是透過及早並持續地交付有價值的軟體來滿足客戶需求。
  2. 竭誠歡迎改變需求,甚至已處開發後期亦然。敏捷流程掌控變更,以維護客戶的競爭優勢。
  3. 經常交付可用的軟體,頻率可以從數週到數個月,以較短時間間隔為佳。
  4. 業務人員與開發者必須在專案全程中天天一起工作。
  5. 以積極的個人來建構專案,給予他們所需的環境與支援,並信任他們可以完成工作。
  6. 面對面的溝通是傳遞資訊給開發團隊及團隊成員之間效率最高且效果最佳的方法。
  7. 可用的軟體是最主要的進度量測方法。
  8. 敏捷程序提倡可持續的開發。贊助者、開發者及使用者應當能不斷地維持穩定的步調。
  9. 持續追求優越的技術與優良的設計,以強化敏捷性。
  10. 精簡──或最大化未完成工作量之技藝──是不可或缺的。
  11. 最佳的架構、需求與設計皆來自於能自我組織的團隊。
  12. 團隊定期自省如何更有效率,並據之適當地調整與修正自己的行為。

敏捷方法

敏捷僅是一個框架,在具體執行敏捷開發時,會使用到不同類型的敏捷框架,有管理工作流程的Scrum、Kanban,實踐方法XP(極限編程)、FDD(特徵驅動開發),多個方法來協調多個敏捷團的的工作(如Scrum-of-Scrums、LeSS、SAFe等),其中最廣泛應用的兩種框架是Scrum和Kanban。在敏捷方法中,首要任務是持續交付有價值的產品給客戶,並達成更好的上線成果。
https://ithelp.ithome.com.tw/upload/images/20220916/20112053wtaFZcQVjh.png
圖片來源

敏捷鐵三角

敏捷三角指:價值、質量和約束條件(資源、時間、成本)。
https://ithelp.ithome.com.tw/upload/images/20220916/20112053Karv2eYSwx.jpg
在傳統專案管理,功能是固定的,時間和資源是可變動的,在一開始就要對需求很清楚,因此,你要決定的是時程和成本。而敏捷認為時間是固定的,功能和資源是可變動的,做出來的東西是客戶最需要的功能,而不是很多功能。

總結

介紹了傳統的瀑布式開發與敏捷式開發,下表總結了兩者差異

分類 傳統 敏捷
重點在於 流程
模式 由上而下 迭代式增量
需求 是先定義需求 藉由反饋獲取真正的需求
文件 需要有詳細的說明書 依實際情況
變更 避免變更,避免重工 可以不斷變更,創造有價值的產品
客戶參與 需求收集和交付 全程參與
風險評估 因為需求一次完成,可事先預期 每次迭代交付的功能,所以難以事先預期
最終產品 事先預期的結果 不斷修正逐漸展現

傳統方式比較適合不太複雜的、需求明確、規範嚴謹的系統;敏捷適合需求不明確、容易變更的系統,不管是敏捷開發還是傳統的瀑布開發,最終還是用戶提出的需求。
選擇一個好方法沒有唯一的方式,只看哪種方法適合當前專案的需求。

參考資料:
https://agilemanifesto.org/iso/zhcht/manifesto.html
https://veracityconsultant.com.tw/what-is-agile-management/
https://kojenchieh.pixnet.net/blog/post/438675019
https://zhuanlan.zhihu.com/p/76296053
https://tangmaster.com/agile_manifesto/
https://www.archimetric.com/传统项目管理-vs-敏捷项目管理/


上一篇
[Day1]第一次使用Jira就上手
下一篇
[Day3]什麼是Scrum-第一次使用Jira就上手
系列文
第一次使用Jira就上手30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言