長篇大論
只求軟體開發的工程方法，最近上敏捷方法，教授開始講到了始祖 …
於是上演了輪番翻譯的戲碼，讓各種同學參與這份大型工程，關於翻譯的同時，深刻地理解到這也是為什麼無法接觸國外的最新資訊啊，曲解、誤解、亂解 …
我的語言記憶體如此小，卻搭載世界最複雜的語言。
序
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 太空軟體開發中，他們的計劃是可以預測的，但這也只是一個特別的例子，主要原因是長期時間，龐大的團隊，穩定的需求。
更可怕的是，如果客戶需求不穩定，卻告知有可預測的計劃，這樣自欺欺人的行為相當令人詬病。
”可預測“是令人相當渴望的，這導致一開始擬定的計劃越飄越遠，最後計劃將會分崩離析。
按照方法論運行總是美好的，但是在軟體開發上必須要捨棄掉，但這樣的舉動相當困難，要捨棄一直以來處理事情的方式，但也並不是讓事情處理變得無法控制的混沌，捨棄“預測”吧！
控制 “不可預測”程序
使用迭代方式，並且將計劃越短越好，看起來就是多方面失敗的開始，但卻有機會看來進步的地方，當計劃越短，就能越早知道反饋(feedback)。
文件可以隱藏缺失，沒有經過測試將會有更多的缺失。
XP 一周或兩周，SCRUM 一個月之類的，越熟練則會越短時間。
=====
並不是每個工程師都像零件，換個人就可以繼續運行。
不可更換的人零件都跑了，也就是最有創意的人力都走了，可更換的人卻留下了。
Programmer 是有責任的專業人員？
早期是工廠的運行模式，希望能讓工人多做一點事情，來讓成本降低。
每個 programmer 是獨特的，產出的代碼也都不同，每一個人的創意不同，把人當資源就錯了。
施工和設計能不能分開？施工只是由編譯器來，因此軟體全是文創業，算是設計類型的職業。
