close
很多人想從瀑布式開發, 轉換到敏捷開發, 他們很擔心是否過去學的東西要丟掉, 變成要重新學習新的東西. 另一方面, 又覺得怎麼可能舊的東西都沒用, 會被完全推翻.
我想這應該是很多人的困擾. 沒錯, 實施敏捷不代表舊的東西就完全沒用, 敏捷只是在某些地方想法不同, 因此只要你能夠掌握好這些地方, 相信你的轉型會有好的開始.
1. 專案管理鐵三角轉換
在傳統專案管理有個鐵三角 (Iron Triangle), 強調的是要做的範圍或是功能是固定的, 在一開始的時候就知道的很清楚, 因此, 你要決定的是時程和成本. 也就是說時程和成本是變動的.
但是, 在敏捷開發中想法是不一樣的, 他認為大多數的功能可能對 user 是沒用的(Standish report, 見下圖), 只是做來心酸的. 但是你可能只有有限的時間和金錢. 所以, 敏捷認為要時間和金錢是固定, 在這個限制下, 作出你最需要的功能, 而不是很多功能.
2. 湧現式需求管理
在傳統的方法中, 認為要做的功能是一開始可以先詳細定義的, 使用者很清楚知道他們要什麼. 可惜是根據歷史教訓, 最後產品所交付的功能, 往往跟一開始的有落差, 或者是照的做出來卻不是使用者要的.
因此, 敏捷認為一開始應該著重於願景, 確認客戶想要的價值為何, 藉由迭代的威力, 交付部分高價值的東西給客戶, 快點得到回饋, 然後再修正腳步, 去做下一部分功能. 這樣最後即使時間到了, 所交付的東西一方面會比較是客戶要的, 並且也比較容易說到做到.
3. 從專案經理到團隊為主
以前傳統中, 專案是以專案經理為主, 他主導專案的進行, 指派誰要做什麼事情, 團隊的存在是在來支持他把專案搞定, 這是很標準的 command and control 的架構.
但是在敏捷中, 尤其是 Scrum 流程裡, 專案經理這個角色不再是主角. 多了一個叫 Scrum Master 的人, 他主要是來支持團隊, 幫助團隊成功的. 團隊才是主角, 並且團隊成員是跨功能的, 然後會以自組織的方式來運作. 完全打破 command and control 的框架.
全站熱搜
留言列表
