
敏捷原則
|
77
重點提要
• 藉由避免打造不需要的功能或者太過複雜的軟體,敏捷團隊
盡其所
能讓解決方案簡單化
。( 第 10 條原則)
• 自我組織的團隊
共同承擔專案的每個部分
,從構思產品到專案管
理再到設計與實作。(第 11 條原則)
• 藉由在每次迭代之後和專案結束時都花些時間
回顧和討論團隊學
到的教訓
,敏捷團隊將可以持續在建構軟體的能力上精進。(第 12
條原則)
敏捷專案:同時運用所有的原則
在軟體工程的歷史上,敏捷是獨一無二的。敏捷與過去幾年的「萬靈丹」方法論(承諾
可以透過結合許多神奇的實踐、美妙的軟體工具以及花大錢請教顧問公司等方式,來解
決你們團隊的軟體問題)浪潮截然不同。
只獲得「只比沒做好一點」成效的團隊與獲得許多實質好處的團隊之間存在一個差異,
就是越有效採行敏捷的團隊會知道實踐不只是一份供人選擇的「菜單」而已。同時使
用這些實踐的關鍵在於團隊執行專案時的心態──而這些心態是由敏捷價值和原則所
驅動的。
敏捷很不一樣,因為敏捷是從價值和原則開始的。嘗試敏捷化的團隊不僅必須誠實看待
他們建構軟體時所採行的方法,還要觀察成員之間互動的方式。先理解原則,再實施方
法論,唯有這樣(完全理解運作方式,搭配大量評估和改進運作方式),敏捷團隊才能
夠真正找出可以讓專案執行得更好的方法。這給了他們一條增進敏捷性的真實通道,讓
他們能夠建構和交付更好的軟體。