之前在講傳統專案管理與敏捷專案管理的比較,這篇就來介紹一下何謂敏捷。
敏捷開發大概是在20世紀末開始發展的,那時候的專案管理大都還是照傳統瀑布式的模式,也就是照著PDCA (Plan> Do> Check> Action)依序執行,但後來軟體公司發現,實務上,如果全部規格都要在一開始就確認好,這很難做到,因爲可能連使用者自己都不知道想要什麽,而且開發過程中,需求變更都要經過繁雜的過程,會非常沒效率,開發人員累,客戶也不滿意,再加上軟體產品與硬體產品的最大不同- 可分割性,因此開始討論出另一種開發模式,也就是敏捷開發,發展到最後,大家討論出幾項敏捷的基本精神,包括四大宣言和十二原則。
The Agile Manifesto (敏捷宣言)
- 獨立的工作成員與人員互動 勝於 流程與工具的管理。
- 工作產生的軟體 勝於 廣泛而全面的文件。
- 客戶的合作 勝於 契約的談判。
- 回應變動 勝於 遵循計畫。
The Agile Principles (敏捷原則)
- 最為優先的事情是透過早期與持續交付有價值的軟體來使客戶滿意。
- 歡迎需求的變動,即使是在開發的晚期。敏捷式流程駕馭變動來作為客戶的競爭優勢。
- 頻繁的交付工作產生的軟體,自數週至數月,週期越短越好。
- 領域專家與開發成員必須一同作業,並貫穿整個專案開發時期。
- 使用積極的工作成員來建構專案,給予他們環境以及支援所需的一切,然後信任他們能夠完成工作。
- 在開發團隊中最快也最有效的傳遞資訊方法就是面對面的溝通。
- 工作產生的軟體是衡量進度最主要的依據。
- 敏捷式流程倡導水平一致的軟體開發。
- 專案發起者,開發人員以及使用者都必須持續的維持專案進度。
- 持續重視技術的優勢以及設計品質。
- 最好的架構、需求以及設計會出現在能夠自我管理的團隊裡。
- 在規律的反覆之間,團隊會反省與思考如何更有效率,然後相對的來調整與修正團隊的開發方式。
簡單來説,敏捷開始爲什麽能擁抱變更?就是利用軟體產品的可切割性,以及實務上,客戶對需求的頻繁變更,將專案流程改爲快速規劃、快速產出、並分批提供客戶有價值的部分產品,藉由這樣的模式,不但可以滿足客戶頻繁變更的需求,並且因快速產出的部分產品,是馬上能替客戶帶來價值的,因此彼此都可接受這樣的模式,而因爲每間公司的文化與產品特性不同,又各自發展出不同的流派,比較知名的就是 Scrum, Extreme Programming (XP), Crystal, DSDM…等,這些手法,針對不同的產品特性、變更頻率、急迫程度,都有各自不同的優缺點,所以如果真的要學敏捷,我建議一開始不用特地學哪一種手法,先了解敏捷的基本精神,再以公司的需求,挑選一個覺得適合的手法,等應用熟練之後,還可以針對公司不同的狀況,客製化專屬的敏捷流程,能經過這樣產生出的管理流程,才是真正的量身定做。
其實不用拘泥要用哪一種敏捷手法,只要每個人一直在思考如何做到 更快、更好、更有價值,如此的思維下,所產生的行爲,就會趨近於敏捷精神了,況且天下的管理手法,沒有最好的,只有最適合的。
延伸閲讀:
如果希望能了解敏捷管理,且不侷限於某一種模型,有推薦的書籍或是課程嗎?
PS.行銷用,非軟體公司。
讚讚
可以來做一下商業思維的測試,測試完我們有提供一連串相關的書單,可以參考。
對商業思維學院有興趣的話,也可以看看我們未來一年的課程計劃。
https://bizthinking.com.tw/2019/10/30/%e5%95%86%e6%a5%ad%e6%80%9d%e7%b6%ad-%e5%88%86%e9%a1%9e%e5%b8%bd%e6%b8%ac%e9%a9%97/
讚讚
這是商業思維學院詳細的課程內容,可以參考看看:
https://www.pressplay.cc/project/about/%E5%95%86%E6%A5%AD%E6%80%9D%E7%B6%AD%E5%AD%B8%E9%99%A2%EF%BC%9A%E7%9C%9F%E5%AF%A6%E5%B8%82%E5%A0%B4%E7%9A%84~/4F939C3F6E137B8D67865F56ACDB1D64
讚讚