1. 1. 長篇大論
    1. 1.1.
  2. 2. 糟透的軟體開發
  3. 3. 真的不可預測?
  4. 4. 控制 “不可預測”程序
  5. 5. Programmer 是有責任的專業人員?


只求軟體開發的工程方法,最近上敏捷方法,教授開始講到了始祖 …

於是上演了輪番翻譯的戲碼,讓各種同學參與這份大型工程,關於翻譯的同時,深刻地理解到這也是為什麼無法接觸國外的最新資訊啊,曲解、誤解、亂解 …


In the past few years there’s been a blossoming of a new style of software methodology - referred to as agile methods. Alternatively characterized as an antidote to bureaucracy or a license to hack they’ve stirred up interest all over the software landscape. In this essay I explore the reasons for agile methods, focusing not so much on their weight but on their adaptive nature and their people-first orientation.

Probably the most noticeable change to software process thinking in the last few years has been the appearance of the word ‘agile’. We talk of agile software methods, of how to introduce agility into a development team, or of how to resist the impending storm of agilists determined to change well-established practices.

也許在這過去幾年最引人注目對軟件過程的思考的改變 - “敏捷 agile” 一詞的出現。我們將談論如何將敏捷軟體方法(agile software method)引入到開發團隊,或者如何抗拒即將到來的敏捷提倡者所帶來的風暴,這風暴將改變原先建立的好的業界實踐方法。

This new movement grew out of the efforts of various people who dealt with software process in the 1990s, found them wanting, and looked for a new approach to software process. Most of the ideas were not new, indeed many people believed that much successful software had been built that way for a long time. There was, however, a view that these ideas had been stifled and not been treated seriously enough, particularly by people interested in software process.

這新運動來自于 1990 年起不同人對於軟體程序的努力,他們發現和找到一個新的軟體程序。大多數敏捷方法的想法並不新,大多數人認為很多成功的軟件本來就有內置這種方式很久了,的確是有的,然而有一觀點指出,這些想法對於對軟體過程感興趣的人眼中並沒有受到重視,甚至被受到抑制。

This essay was originally part of this movement. I originally published it in July 2000. I wrote it, like most of my essays, as part of trying to understand the topic. At that time I’d used Extreme Programming for several years after I was lucky enough to work with Kent Beck, Ron Jeffries, Don Wells, and above all the rest of the Chrysler C3 team in 1996. I had since had conversations and read books from other people who had similar ideas about software process, but had not necessarily wanted to take the same path as Extreme Programming. So in the essay I wanted to explore what were the similarities and differences between these methodologies.

這篇文章也是新運動的起源一部份,最初發表于 2000 年 7 月。作為嘗試了解這文章一部份,您必須知曉這篇文章的風格如同其他大多數我寫的文章。在很幸運地與 Kent Beck, Ron Jeffries, Don Wells 共事後,我已經使用極限編程 (Extreme Programming) 好幾年。從 1996 年的 Chrysler C3 team 那時。我有機會與別人互相交流資訊和書籍來得到他們對於軟體過程中的類似想法,但即使是極限編程 (Extreme Programming) 也沒有一定要採用一樣的走法,所以在這篇文章中,我想要探索這些方法間的異同。

My conclusion then, which I still believe now, is that there were some fundamental principles that united these methodologies, and these principles were a notable contrast from the assumptions of the established methodologies.


This essay has continued to be one of the most popular essays on my website, which means I feel somewhat bidden to keep it up to date. In its original form the essay both explored these differences in principles and provided a survey of agile methods as I then understood them. Too much has happened with agile methods since for me to keep up with the survey part, although I do provide some links to continue your explorations. The differences in principles still remain, and this discussion I’ve kept.


Most software development is a chaotic activity, often characterized by the phrase “code and fix”. The software is written without much of an underlying plan, and the design of the system is cobbled together from many short term decisions. This actually works pretty well as the system is small, but as the system grows it becomes increasingly difficult to add new features to the system. Furthermore bugs become increasingly prevalent and increasingly difficult to fix. A typical sign of such a system is a long test phase after the system is “feature complete”. Such a long test phase plays havoc with schedules as testing and debugging is impossible to schedule.

大多數軟體開發是一個混亂的開始,常常以一句話代以概括 ”撰寫!修復!“,這些軟體在撰寫時不用事先有基礎的計劃,也不用系統架構,將由短期項目討論就可以拼湊起來。這確切在系統很小時可以運作,但當系統越大時將會變得相當困難去增加新的功能。此外,BUG 也會越來越普遍見到,且越來越難除錯。這典型系統是在功能齊備後,才經由長時間的測試階段。這麼長時間的測試階段將嚴重破壞測試和除錯的行程,使得行程根本無法安排。試階段起著嚴重破壞的時間表為測試和調試是不可能的安排。

The original movement to try to change this introduced the notion of methodology. These methodologies impose a disciplined process upon software development with the aim of making software development more predictable and more efficient. They do this by developing a detailed process with a strong emphasis on planning inspired by other engineering disciplines - which is why I like to refer to them as engineering methodologies (another widely used term for them is plan-driven methodologies).

起源運動將要改變這種方法的概念,這些方法論所施加的紀律,將協助軟體開發變得更可預測和更有效率。他們將透過製定詳細的過程,這些過程特別強調設計,靈感來自于其他工程學門- 這就是為什麼我喜歡稱呼它們為 ”工程方法 enginerring methodologies“ (對於他們來說,另一個廣泛使用的術語為 “計劃驅動方法 plan-driven methodologies”)

Engineering methodologies have been around for a long time. They’ve not been noticeable for being terribly successful. They are even less noted for being popular. The most frequent criticism of these methodologies is that they are bureaucratic. There’s so much stuff to do to follow the methodology that the whole pace of development slows down.

工程方法已經存有一段歷史,它們都沒有被注目那背後可怕的成功,它們相當少被認為是受流行的,常見的批評為 ”它們是官僚政治的“ // 相當死板的 ? 。有相當多的項目都遵循這套方法論使用緩慢的發展步伐。

Agile methodologies developed as a reaction to these methodologies. For many people the appeal of these agile methodologies is their reaction to the bureaucracy of the engineering methodologies. These new methods attempt a useful compromise between no process and too much process, providing just enough process to gain a reasonable payoff.


The result of all of this is that agile methods have some significant changes in emphasis from engineering methods. The most immediate difference is that they are less document-oriented, usually emphasizing a smaller amount of documentation for a given task. In many ways they are rather code-oriented: following a route that says that the key part of documentation is source code.

這一切的結過是,敏捷方法從工程方法中有顯的改變。最明顯的差異是少寫文件(文件導向),通常強調少量文件的工作,在許多說法上,它們更偏向代碼導向(code-oriented: 文件的關鍵部分是源代碼 source code)





專家寫出來的設計草圖,要讓 programmer 看得懂,通常是非常困難的。即使是 UML 圖,雖然在紙(草圖)上看起來相當不錯,但是實作上的問題卻相當多,土木工程的設計圖可以經過數學模型去測試,但是軟體工程的設計圖只能由人腦去找到邏輯BUG,即使是設計熟練的專家,要設計出不會有實作問題的草圖也是常發生的。

接續著剛剛討論的造橋問題,設計費用只占了全部花費的十分之一,按照草圖寫 code 是相當簡單的,根據 McConnell 調查大型專案,只有 15% 的成本進行程式撰寫和測試(這裡我們需要勞力成本比例越高越好)。即使把其他成本混在一起,設計仍占了 50% 的成本比例。軟體工程只是工程分枝中之一,這其中一定有蹊蹺。


  • 軟體的建造相當便宜,甚至於免費(只淤需要電腦和編譯器,沒有實體。)
  • 軟體受設計影響,因此需要有創造力和有天賦的人。
  • 俱有創新的程序不容易去規劃,可預測的性質甚至變成不可能。
  • 我們需要不同於傳統工程的方法,來解決這詭異的軟體工程的開發程序。





在 NASA 太空軟體開發中,他們的計劃是可以預測的,但這也只是一個特別的例子,主要原因是長期時間,龐大的團隊,穩定的需求。




控制 “不可預測”程序



XP 一周或兩周,SCRUM 一個月之類的,越熟練則會越短時間。




Programmer 是有責任的專業人員?


每個 programmer 是獨特的,產出的代碼也都不同,每一個人的創意不同,把人當資源就錯了。