
74
|
第三章
重點提要
• 溝通專案進度的最有效方法,就是
交付可用的軟體
,讓用戶實際
操作。(第 7 條原則)
• 當團隊
維持穩定步調在工作
,而且避免緊急救火、不走捷徑、不
加班,這時候他們的生產力最好。(第 8 條原則)
•
良好設計和實作
的軟體交付的速度最快,因為最容易修改。(第 9
條原則)
持續改善專案與團隊
最基本的設計原則之一(不限於軟體,整個工程界都適用),就是 KISS(Keep It
Simple, Stupid ;「保持簡單和愚蠢」)。敏捷團隊賴以為生的就是這條原則,他們在規劃
專案、建構軟體以及經營團隊時都會盡量 KISS。
第 10 條原則:精簡(或最大化未完成工作量之技藝)是不
可或缺的。
在現有專案中加入程式,通常會讓專案變得更複雜,尤其是之後又加入了更多相依的程
式碼時。系統、物件和服務等之間的相依性會使程式變得更複雜、更難變更:相依性增
加了某項變更串聯到系統的其他部分的可能性,於是必須一併修改系統的其他部分,變
成每次變更都會產生骨牌效應,增加複雜度。在專案初期使用迭代和撰寫最少文件,可
以幫助團隊避免交付不需要的軟體。
但是很多開發人員在頭一次聽到像是「使用迭代式開發」和「只做專案動工所需的最少
量規劃工作」這類的說法時,都覺得有點不自在。他們覺得太早開始寫程式了,因為還
沒有做太多的設計和架構決定,也還沒有寫成文件──團隊反而覺得他們今天所寫的程
式碼,在明天就會因為設計變更而被拋棄。
這樣的反應是可以理解的,因為對於許多不是軟體開發領域的專案而言,這是沒有意義
的。敏捷新手開發人員很常提出異議 ...