l         tensile: second the difference between XP and UML?(10:10)

l         有關XP及UML的不同;XP是一個軟體開發的社會(social)系統,UML是一個描述軟體的標記法(notation)。你可以在XP當中使用UML,但團隊良好的進展並不需要許多文件除了程式碼及測試外。

l         kentbeck: To answer a basic question-- XP and UMLXP is a social system for software development, UML is a notation for describing software. You can use UML inside of XP, but teams get along fine without lots of documents besides the code and tests.


l         yhufo: Is document improtant in XP? what type of document should be write(10:11)

l         你要寫的文件就是程式碼及測試。

l         kentbeck: The documents you must write are the code and tests


l         superlong: Mr beck,we can discuss a visual project,how to use XP in it?

l         XP程式設計師並不是不做視覺上的思考(think visually),他們只是一般不儲存影像(picture)。

l         It's not that XP programmers don't think visually, they just don't usually save the pictures.


l         notyy: what problem does xp resolve?

l         我將回答有關於XP可以解決的問題。當你有許多關於需求的不確定性,XP讓你快速得到一個具體、執行的系統,同時讓你在一個相當穩定的速度(pace)修改。以這種方式你無須在你開始之前知道所有的事。

l         I'll answer the one about what problem XP solves. XP is good when you have lots of uncertainty about the requirements, XP gets you a concrete, running system quickly, and lets you modify it at a fairly constant pace. That way, you don't have to know everything before you begin.


l         yhufo: but 'crc card' and 'user story' is not code or tests

l         關於CRC卡及故事—這些都不是文件。你無須永遠保存。你從CRC卡及故事獲得內容,然後把他們丟掉。

l         Regarding CRC cards and stories-- those aren't documents. You don't save them forever. You gain insight from them, then discard them.


l         yhufo: can you tell we the best web-site about XP you think !

l         目前xprogramming.comextremeprogramming.org譯文)這兩個網頁是學習XP一個不錯的起點。

l         In the meantime, xprogramming.com and extremeprogramming.org are both good places to start.


l         joe_lee: Is XP a recursive process?

l         答覆有關遞迴程序(recursive process)的問題。是的,或者我可能說『不規則碎片形(fractal)』。以一年為期的你描述你所想要的(故事)然後去做。以一分鐘為期的你描述你想要的(單元測試)然後去做(撰寫程式碼)。分解的不規則碎片形是經過相當的深思熟慮的(deliberate)。

l         Re: recursive process. Yes, or I might say fractal. At the scale of a year you say what you want (stories) and then do it. At the scale of a minute you say what you want (unit test) and do it (code). This fractal breakdown is quite deliberate.


l         xlp223: 1.Does XP somewhat over-emphasize consciousness of every contributor?

l         Can xlp223 ask his question again. I don't understand why you wouldn't want to emphasize every contributor.


l         taoxie: you mention unit test. I agree rerun all unit testing is reasonable, how is running all integrated test cases reasonable?

l         回答有關執行所有測試的問題。如果你有適當的準備而且夠快的話,你可以隨時執行測試。

l         Re: running all the tests. If you make decent coverage fast enough, you can run them all the time.


l         yhufo: if we have no document,I don't know how we can control the changes in the software.I think we must doucmentation it !

l         當你們說『控制改變』,我則說『鼓勵改變(encourage change)』。控制來自測試、雙人組設計、大家坐在一起一起討論及持續整合。XP對於受過良好訓練的程式設計師運作的很好,但是如果你們目前不覺得有良好的訓練,別擔心。你的搭擋可以幫你,或者你的整合工作無法達成你必須把你的程式碼丟棄。

l         When you say "control changes", I would say "encourage changes". Control comes from the tests, the pairing, sitting together, and continuous integration. XP works well with disciplined programmers, but if you are not feeling disciplined today, don't worry. Your pair partner might catch you, or your integration won't work and you will have to throw away your code.


l         dggh: would you talk about xp practise games?

l         答覆有關XP game。我做過一個練習讓人們描繪一個咖啡壺的圖像。從這裡顯示有更好的game。在倫敦有人建造樂高(Lego)機器人。Joshua Kerievsky有一個團隊寫了一個劇本(電影的腳本)。

l         Re: xp games. I do an exercise where people draw a picture of a coffeemaker. There are better games out there. Some folks in London build Lego robots. Joshua Kerievsky has the team write a screenplay (script for a movie).


l         gigix: Mr. Beck, I think we must carefully design at first. If we ignore the importance of design, XP(or refactoring) can't improve the whole project. How do you think about?

l         回復有關設計的問題。我知道這將被討論。我,同樣的,堅持我們需要小心的設計。我寧願等待並且在我有一些經驗後再做,而不願依據推測(speculation)做設計。前置設計是一種正向回饋的循環(positive feedback loop)。你愈有經驗,你愈可以考慮前置設計,直到你完全的無用(useless)。另一種使用設計經驗的方式是等待你好的想法直到這些想法顯然立即的有用時。

l         Re: design. I knew this would come up. I, too, insist that we need to carefully design. I would just rather wait and do it after I had some experience, rather than design based on speculation. Up front design is a positive feedback loop. The more experience you have, the more you can think to design up front, until you are completely useless. Another way to use that design experience is to wait with your good ideas until they are obviously, immediately useful.


l         joe_lee: If no document, how we maintain the software?

l         答覆有關文件的問題。你有兩個非常有價值的文件—程式碼及測試。如果測試總是能夠100%執行而且絕不會允許逆行(regress),你還需要甚麼?

l         Re: documents. You have two very valuable documents--the code and the tests. If the tests always run 100% and never are allowed to regress, what else do you need?


l         yhufo: At pair programming two person should often change his role?1 day or 2 day. I mean how often,one day or tow day.

l         答覆有關雙人組之間人員的移動。當我在比較大的團隊中我每天移動2-4次。在一天之中我無法維持一個雙人組6個小時以上,因為專注的程度太過激烈。

l         Re: pair switching. I switch 2-4 times per day when I'm on a bigger team. I can't pair for more than 6 hours in a day, because the concentration is so intense.


l         xlp223: Since XP has no experts,what role should XP leader play among programmers, customers, manager?

l         答覆有關專家的問題。XP是有專家,但他們的角色並不像以前一樣是固定的。專家的出現是由團隊中的每一個人依據經驗挑選出來的。促使這種專家的出現是管理者扮演的角色。

l         Re: experts. XP has experts, but their roles are not fixed from above. Expertise emerges from the experiences chosen by everyone on the team. Encouraging this emergence is the role of management.


l         yhufo: In pair programming how when one coding an other one do what,just see and talk to another!

l         雙人組設計並不是看著別人撰寫程式碼。撰寫程式碼就像是在溝通。鍵盤每幾分鐘便傳來傳去。當兩人成對時,你們討論相關的想法,試試一個,建議其他的測試,把你下一個想法畫個草圖,寫成程式碼,做些重整等等持續進行。

l         Pair programming is not watching someone else code. It is coding as a conversation. The keyboard switches back and forth at least every couple of minutes. When pairing, you'll talk about ideas, try one, suggest another test, draw a little sketch of your next idea, code that up, refactor a little and on and on.


l         dggh: Would you like to answer,how to deal with the "Programmers have little contact with customer"?

l         答覆有關程式設計師與客戶之間的接觸。我想這些接觸一般運作的不是很好。這就是為什麼我說的XP是軟體開發的社會系統。頻繁的與其生活受軟體影響的人接觸;你寫的讓每一個人都非常注意。

l         Re: programmer contact with customers. I think this is so common, and it doesn't work well. That's why I said XP is a social system for development. Hourly contact with the people whose lives are affected by the software you write makes everyone pay attention.


l         skyin: every one has it's own task,right? then how to assign the work when they pair-programming?

l         答覆有關指定任務的問題。今天早上我將與你共同做你的任務。下午你可以以你的協助我。

l         Re: task assignment. This morning we will work together on your task. This afternoon you can help me with yours.


l         yhufo: any tools for XP,Introduce some!

l         答覆有關工具的問題。我在Java使用Eclipse而且我真的很喜歡它。有時我也使用IntelliJ。JUnit或他得姊妹產品在其他的語言在單元測試及建立驗收測試基礎建設時非常有幫助

l         Re: tools. I use Eclipse for Java and I really like it. I use IntelliJ sometimes, also. JUnit or its siblings in other languages are very helpful for unit testing and building acceptance test infrastructure.


l         xlp223: Every pair programming has its unique style and level,then how can refactoring make it consistent or balance? and person or group to do refactoring need be arranged in addition.

l         答覆有關重整的問題。合唱團中的人每人都有他們的聲調。他們是如何讓這些聲音和諧?他們先決定最重要的和聲然後『以他們的方式』唱出。在程式設計團隊中也是同樣的道理。必須是對於團隊中所有人最重要的能夠成功然後是個人的閃耀。

l         Re: refactoring. Every person singing in a choir has their own voice. How do they make music together? They decide that it is more important to sound good together than to sing "their way". The same is true on teams of programmers. It must be more important to everyone for the team to be successful than for any individual to shine.


l         tensile: social system for development?

l         答覆有關與客戶接觸的問題。首先,所有的團隊成員聚集坐在一個大房間內—程式設計師、管理者、客戶、分析師、測試員、使用者文件、反覆設計。其次,『客戶團隊(customer team)』提出程式設計團隊必須通過的驗收測試(acceptance tests)。學習如何通過這些測試需要溝通。

l         Re: contact with customers. First, the whole team sits together in one big room-programmers, managers, customers, analysts, testers, user documentation, interaction design. Second, the "customer team" is producing acceptance tests that the programming team must pass. Learning how to pass those tests requires conversation.


l         notyy: its really difficult to arrange an "on site customer" in some situation.

l         答覆有關客戶無法隨時在側的問題。想辦法找到一個,否則準備接受失敗。舊的Taylorist 軟體開發社會結構無法運作。要有新的社會結構。

l         如果讓軟體開發運作成功是重要的,坐在一起是絕對根本的。如果對想做好卻不認為那是重要的,或需這個專案應該取消。

l         Re: no customer. Get one, or prepare to fail. The old, Taylorist social structure for software development doesn't work. Make a new one.

l         Re: "on-site customer". If it is important for software development to work well, sitting together is absolutely essential. If it is not important for it to go well, perhaps the project should be cancelled.


l         yhufo: why xp need no document!

l         XP確切需要的兩種文件—程式碼及測試。如果你的團隊覺得需要更多的文件,那麼便去做。大多數的團隊發現他們並不需要其他的內在(internal)文件。

l         XP needs two documents for sure--code and tests. If your team discovers it needs more, then write them. Most teams discover they don't need other internal documentation.


l         taoxie: It occurs to me that you said the customer is aiming at Contract-style project, how about XP application in shrink wrapped product development?(10:39)

l         對於套裝軟體(shrink-wrap)開發公司而言。客戶團隊(行銷、測試、可用性、客戶服務)是大於使用自製型(in-house)開發。除此之外,大家都同意使用單一的需求序列(故事)可以讓軟體開發愈來愈平緩(smoothly)。

l         This is definitely a shrink-wrap company. The customer team (marketing, testing, usability, customer service) is larger than with in-house development. Other than that, everyone agrees that software development goes more smoothly with a single stream of requirements (stories).


l         tooliu: Would you mind to explain the WinDNA and XP?

l         答覆WinDNA與XP的關係。XP是Extreme Programming不是操作系統。

l         Re: WinDNA and XP. This is XP as in Extreme Programming, not the operating system.


l         xlp223: person or group to do refactoring need be arranged in addition or not?

l         答覆有關重整的問題。設計是每一個人的責任。當我們坐在一起而我們看到需要重整的地方,我們就重整。如果你還需要去安排進度,那你等待太久了。

l         Re: refactoring. Design is everyone's responsibility. When we are sitting together and we see the need to refactor, we just refactor. If you ever needed to schedule it, you would have waited too long.


l         notyy: should we educate customer first?

l         客戶需要知道XP嗎?絕對的。他們是團隊的一份子,因此他們需要知道團隊如何運作。故事及驗收測試是兩個最重要的事情需要先教導他們,然後是發行(release)(3-12個月)及反覆(iteration)(1-3週)的規劃。

l         Do customers need to know about XP? Absolutely. They are part of the team, so they need to know how the team works. Stories and acceptance tests are the two most important things to teach them first, then release (3-12 month) and iteration (1-3 week) planning.


l         smilemac: I feel that XP is very similiar to evolution process, could you explainthe difference?

l         答覆有關發展(evolution)的問題。XP確實使用發展或成長的隱喻(metaphor)。然而XP指定許多實務作法支援一個長期持續性的成長。Gilb之發展式的交付工作在概念上是類似的,但他沒有說明太多關於如何達成目標。XP說—先測試、雙人組設計、坐在一起、隨時整合然後你就能使你的軟體成長及發展。

l         Re: evolution. XP certainly uses the metaphor of evolution or growth. However, it prescribes many practices to support continued growth over a long period. The evolutionary delivery work of Gilb is similar in concept, but he doesn't say much about how to achieve his goals. XP says-- test first, pair, sit together, integrate hourly, and then you'll be able to grow and evolve your software.


l         skyin: it seems xp is more suitable for customer-oriented application software, how about other?

l         答覆有關客戶導向的問題。還有其他型態嗎?如果沒有客戶,為什麼要寫這些程式。

l         Re: customer-oriented. What other kind is there? If there are no customers, why write it?


l         fpeng: What is the difference between release planning and iteration planning?

l         答覆有關發行及反覆的問題。發行與企業循環同步,所以它們是3-12個月的時間。反覆與工程師需要的里程碑同步,所以它們是1-3週的時間。

l         Re: release and iteration. Releases synchronize with the business cycle, so they are 3-12 months long. Iterations synchronize with the need for engineers to have milestones, so they are 1-3 weeks long.


l         dggh: Does xp require everyone in teams to be a system-analyse expert?It's too difficult!

l         答覆由關是否每一個人都是專家的問題。團隊需要系統分析專家,但不意味著每一個都需要做系統分析。類似的,團隊可能需要資料庫專家,但只需3-4個人深入瞭解資料庫的知識,而其他所有的人如果需要可以協助做資料庫的任務。

l         Re: does everyone need to be an expert. The team needs systems analysis expertise, but that doesn't mean everyone needs to do it. Likewise, the team might need database expertise, but 3-4 people would choose to have deep knowledge of databases while everyone else could help with a database task if necessary.


l         Charity_Zhou: so i think XP has a more high request to the customers.

l         XP確實對於客戶有更多的要求。他們隨時可以看到同時他們也得到更多的控制,同時他們負責挑選系統的範圍。

l         XP certainly asks more of the customers. They get visibility and control, and with that goes the responsibility for choosing the scope of the system.

l         我不認為推卸責任在中國是特別的問題,我認為這是任何地方的特別問題。我們從Fred Taylor獲得工作的社會結構概念,約有1900工業工程師。他假設工人是懶惰且愚笨的,因此他們需要有人為工人計畫並有人檢查工人的工作(品質保證(QA))。這個社會結構在軟體並不能良好運作,因為大部分的程式設計師既不懶惰也不愚笨。不管如何,Taylor的範例執行的非常深入以致多數人甚至不知道是來自何處。

l         I don't think shifting responsibility is especially a problem in China, I think it's especially a problem everywhere. We inherited our ideas of the social structure of work from Fred Taylor, a circa 1900 industrial engineer. He assumed workers were lazy and stupid, so they needed someone to plan for them and someone to check on them (QA). This social structure doesn't work well for software, where most programmers are neither lazy nor stupid. However, Taylor's paradigm runs so deep that most people don't even know where it came from.


l         dggh: When team velocity is too slow ,what can we do?

l         答覆有關速度的問題。我今天剛寫了一封長信到Yahoo中XP的郵件列表中中。簡單的回答就是要讓團隊進行的速度加快唯一的方式就是鼓舞團隊的士氣。

l         Re: velocity. I just posted a long message to the XP mailing list on yahoo groups today. The short answer is that the only way to get the team moving faster is to encourage greater team spirit.


l         zhujigang: Dear Beck, our team DO use pair programming, but what would a pair do if they have finished their story, but others have not yet? Do they need to wait for other peoples?

l         答覆有關雙人組程式設計的問題。在每一個反覆中每一個程式設計師簽認一些任務。如果有人完成他的任務,開始另外一個,或幫助你的同伴開始做同伴的任務之一。

l         Re: pairing. Every iteration each programmer signs up for a few tasks. If one is finished, start another one, or help your partner start one of his.


l         simplebest: I want to learn whether you use Design pattern.Thanks.

l         答覆設計樣式的問題。我絕對使用樣式。如果你檢視JUnit,到處都是設計樣式。它是我曾經做過的設計最密集的部分之一,不管如何,設計樣式在需要的時候就可以應用,而不是因為我們認為它們可能是有用的。我們應該寫一個測試,讓這個測試可以執行,然後注意程式碼如果我們使用設計樣式是否可以讓程式碼更清晰。若是我們應該重整把設計樣式放到正確的地方。4年後我們仍將做相同的事情。熟練的程式設計師可以使用設計樣式縮短設計討論的時間從幾小時到幾秒鐘之內。

l         Re: design patterns. I absolutely use them. If you look at JUnit, there are patterns everywhere. It is one of the densest pieces of design I've ever done. However, the patterns were applied as they were needed, not because we thought they might be useful. We would write a test, get it running, then notice the code would be cleaner if we introduced a pattern. We would refactor to put that pattern in place. Four years later we're still doing the same thing. Skilled designers can use the patterns to shorten design discussions from hours to seconds.


l         skyin: do you think xp is similar to 'learning organization' in managment domain?

l         答覆由關學習型組織的問題。是的。XP依賴整個團隊持續性的學習如何更良好的互動。

l         Re: learning organization. Yes. XP relies on the whole team continuously learning how better to interact.


l         yhufo: did every one(in the team) should test the software.

l         答覆有關測試的問題。如果我們要協調權力與責任,那麼每一個程式設計師,他們有權力產生缺陷,必須同時有責任去測試。我看不到其他的方式可以解決這個難題。

l         Re: testing. If we want to align authority and responsibility, then every programmer, who has the authority to create defects, must also have the responsibility of testing. I see no way out of this puzzle otherwise.


l         答覆有關軟體的問題。當我使用XP時所做的第一件事情是寫一個專案管理工具,那是浪費時間的。XP是一種新的習慣。以最簡單可能的基礎建設(幾張紙貼在牆上就不錯了)養成這個習慣。只要養成這種習慣同時團隊找到其精神,你便可以開始導入電腦而不至於破壞程序。

l         Re: software. One of the first things I did with XP was begin to write a project management tool. It was a waste of time. XP is a new set of habits. Get the habits in place with the simplest possible infrastructure (pieces of paper on the wall is good). Once the habits are in place and the team has found its spirit, you can begin to introduce computers without damaging the process.


l         adylee: what about do u think CMM vs XP?

l         答覆有關CMM的問題。CMM從製造業的係慣延伸。那是從所謂的製造業成熟模式(Manufacturing Maturity Model)的複製。軟體並不像實體的製造業。每一個軟體開發都不一樣,而有時候根本就是如此。

l         Re: CMM. CMM derives from a manufacturing mindset. It is copied from something called the Manufacturing Maturity Model. Software isn't like physical manufacturing. Every software development is different, and sometimes radically so.


l         simplebest: Which one of RUP and XP do you think more suitable for chinese programmer.

l         答覆關於RUP在中國的問題。這一點我不清楚。XP提出來自每一種文化的程式設計師的問題,其不同的部分也有提到。在中國XP最困難的部分在哪裡?

l         Re: RUP in China. I have no idea. XP poses problems for programmers from every culture, but different parts of it are appealing as well. What is hardest about XP in China?


l         tensile: XP is rely on software or people?

l         XP絕對是依賴人的,好的人傾向於做好的事情,功力差的人做的比較差。

l         XP absolutely relies on people. Good people tend to do good things. Less skilled people do less well.


l         dggh: Proxy customers don't know customer needs,how to do?

l         當我上次在日本,他們說他們無法誠實的面對客戶,因為客戶是神。我問如果一個即時(just-in-time)供應商誠實的對待他們的客戶。「喔,是的,當然。除此之外那將無法完成。」我想這就像XP。我們需要對我們的客戶誠實並且向他們保證。他們一開始並不喜歡這樣,但結果將會是如此的棒他們將會學習去要求這種新層次的投入。

l         When I was last in Japan, they said they couldn't be honest with their customers, because the customer was God. I asked if a just-in-time supplier was honest with their customers. "Oh, yes, of course. It wouldn't work otherwise." I think this is like XP. We need to be honest with our customers and engage them. They may not like it at first, but the results will be so much better that they will learn to demand this new level of involvement.


l         notyy: kent,you should know a word"no one is punished because using IBM",so many company manager would like to use rup or cmm.

l         答覆有關RUP與CMM的問題。在沒有人因使用XP而被解雇成真之前會如何?我們將使得這種情況發生。「喔,你的團隊以三個月沒有交付任何體了。怎麼辦?你被解雇了。」我將舉一個技術問題為例—樣式產生架構。問題的根本是「樣式與架構之間的關連是甚麼?」這是當設計樣式是新的時候。因此Ralph與我跑進一家旅館的房間並嘗試回答這個問題。我們找到的答案就像有一個原則(theorem)可以從第一個原理(principles)導出,因此一個架構可以從第一個原理(樣式)被導出。這個論點,沒有人能夠證明是或不是,亦即任何架構可以從一部份樣式的後續應用推導出來。

l         Re: RUP and CMM. What will it take before it is true that no one is fired for using XP? We should work to make that happen. "Oh, your team didn't deliver any software for three whole months. How could that work? You're fired." I'll take a technical question- patterns generate architectures. The original question was, "What is the relationship between patterns and architectures." This was when design patterns were new. So Ralph and I got in a hotel room and tried to answer the question. The answer we found was that just as a theorem can be derived from first principles, so an architecture can be derived from first principles (the patterns). The thesis, which no one has really proven or disproven, is that any architecture can be derived from the successive application of a small set of patterns.


l         dggh: QA department wants detailed requirements,but we team only have simple document!God save us?

l         答覆品質保證(QA)的問題。在XP,QA有一個前置的角色。在每一個反覆中,在技術團隊開始切割故事成為任務之前最好的團隊隨著他們的故事交付驗收測試。你需要測試員撰寫這些測試,同時有基礎建設支援他們。對於一個程式設計師最重要的事是勇氣—勇於冒險找尋愚笨之處,勇於嘗試不同新的技術,勇於清楚的與別人溝通既使當那是很難支援他們時。

l         Re: QA. In XP, QA has an up-front role. Every iteration, the best teams deliver acceptance tests along with their stories before the technical team starts breaking the stories into tasks. You need testers to write these tests, and the infrastructure to The most important thing for a programmer to have is courage--courage to risk looking stupid, courage to try difficult and new techniques, courage to communicate clearly with others even when that is hard support them.


l         simplebest: In china, most of excellent programmer don't like others sit side by side, how to practise XP?

l         答覆有關傑出程式設計師的問題。在我們的團隊中,多數傑出程式設計師是最會溝通的人。或許我們對於『傑出』的定義不同。

l         Re: excellent programmers. On my teams, the most excellent programmers are those that communicate the most. Perhaps we have a different definition of "excellent".


l         阿樓: oh,my god.I think my manager can't using xp because he like control everything.what can I do for it?

l         答覆有關管理者控制的問題。管理者想要為你決定就不是管理者。你可能需要移動,或可能是他們。在XP你想要從管理者得到的是建立及維護社會網路的能力。這個網路斷裂,他們便應該去修復。客戶可以指定甚麼工作量(load)的層次需要支援,同時他們撰寫測試以決定這個層次是否已被支援。如果未通過測試,技術團隊修復這個系統。

l         Re: managers in control. Managers who want to decide for you should not be managers. You might have to move, or they might. What you want from a manager in XP is the ability to build and maintain social networks. broke, then they would fix it. The customers can specify what level of load needs to be supported, and they write tests to determine if that level is supported. If the tests fail, the technical team fixes the system.


l         fdu_se01: Mr. Beck. What is the characteristics of XP projects? Such as domain involved, size of development team, size of software product. CMM's data(esp.in US) is based on DoD..

l         團隊大小3-40個人(包括整個團隊)。領域—可想到的任何事。產品大小—任何30生產人員可以在幾年內生產的。

l         Size--4-30 people (including the whole team). Domain--everything imaginable. Size of product--whatever 30 productive people can produce in a few years.


l         notyy: a good metaphor is very difficult to discover,how to solve it ?

l         答覆有關隱喻(metaphor)的問題。找尋好的隱喻需要軟體相關的經驗。真正強大的隱喻並不會立即浮現。我曾經有一個大的隱喻是在處理一個程式片段12年之後獲得。我希望我現在應該比較厲害,但我懷疑:-(

l         Re: metaphor. Finding good metaphor requires experience with the software. The really powerful metaphors won't emerge instantly. I had a great metaphor come to me after 12 years of working on a piece of software once. I hope I would be smarter now, but I doubt it :-(


l         simplebest: About definition of excellent: it means you can resolve problems which the others can't.

l         我對於傑出的定義是結合他人解決他們不認為他們可以解決的問題。也就是一個團隊可以共同做的有多少。

l         My definition of excellent is getting other to resolve problems which they don't think they can resolve. It's about how much the team can do together.


l         zer: As a PM,if someone is out of your team,(he's a higher),what will you do ?

l         kentbeck: zer what do you mean "out of your team"?

l         zer對kentbeck說: he is fired.

l         如果團隊中有人離開,那一般不是大問題。速度可能下降(也可能提升)。規劃的實務已經可以良好的控制速度改變。

l         If someone leaves a team, it usually is not a big problem. Velocity might drop (or it might rise). The planning practices handle changing velocity nicely already.


l         xlp223: linus is one of there excellent programmer. but he has a little timidness sometimes. what should i do?

l         答覆有關害羞的程式設計師的問題。雙人組程式設計的方式可以幫助人們變的更社會化。

l         Re: timid programmers. Pairing really works well to help people become more social.


l         skyin: direction of XP's evolvement?

l         XP的下一步是更加擁抱整個團隊—如何把一個巨大的故事切割成合理的小故事?在團隊中彼此如何溝通及協調。

l         The next step for XP is to embrace more of the whole team--how do you take a giant story and break into reasonable small stories? How do you communicate and coordinate between teams.


l         adylee對: do u think that XP is perfect now ?

l         答覆有關完美的問題。你一定是在開玩笑。一般而言自然界的緊急系統使用3-5規則。很可悲的XP似乎需要太多的規則。我一直在找尋簡化XP的方法。你是否可以維持可視性及控制而無須先撰寫測試?我不認為如此,但我也積極的投入以便瞭解。

l         Re:perfection. You must be joking. Emergent systems in nature use 3-5 rules, typically. I'm sad that XP seems to require so many rules. I'm always looking for ways to simplify it. Could you maintain visibility and control without test-first? I don't think so, but I'm too emotionally involved to know.


l         notyy: do u mean xp will be more simple,but I think agile process is more complex.

l         I want XP to become simpler, but I don't see how to do that at the moment.

l         我希望XP變的更簡單,但此時我不知道如何做。


l         tooliu: So you mean it's more important to be good in social than to be hard coding?

l         答覆有關社會化及撰寫程式的問題。我比較喜歡有些人是可以包括這兩方面。沒一個團隊中的成員應該持續學習新的社會及技術技能。

l         Re: social and coding. I'd rather have someone who can do both. Everyone on the team is constantly learning new skills socially and technically.


l         simplebest: I want to learn whether we can adjust XP's practices to fit our software team? especially according our chinese team member's character?

l         答覆有關調整的問題?你必須調整任何程序。你必須對你的結果承擔責任,因此在你的作法上你必須有權力。不管如何,我希望人們依據經驗調整,不是丟掉一些重要的東西只是因為他們害怕去嘗試這些東西。

l         Re: adjusting. You must adjust any process. You will be held responsible for your results, so you must have authority over your practices. However, I want people to adjust based on experience, not just throw out something important because they are afraid to try it.


l         tooliu: Do you have any unsatisfied point to XP?

l         XP Explained這本書是在1999年發行。(其中有許多是我現在想要改變的,但此時我在做別的專案。)

l         XP Explained was published in 1999. (There's a lot I would change now, but I'm working on other projects at the moment).


l         fdu_se01: How long can XP be applied in a team? (learning curve? I'm not sure about how to explain ^_^))

l         一般團隊在幾週或幾個越後都能獲得好的結果。一般約9-12個月後明確的變的有效率。我在Iona輔導的一個團隊花了將近一年的時間才真正覺得滿意,同時他們仍然變的更有效率。

l         Teams usually get good results after weeks or months. They usually become dramatically more effective after 9-12 months. A team I coach at Iona took almost a year to really get comfortable, and they can still become much more effective.


l         xlp223: now there is agile software development.but can you say the relation between it and XP?

l         『輕快(agile)』來自一個研討會,其中有許多趣味相投的方法論者集合討論他們的軟體的開發程序。我們之間共通點多於差異點,因此我們決定使用『輕快』這個字來描述我們的共通點。

l         "Agile" came out of a workshop where many like-minded methodologists got together to talk about their software processes. We had more in common than we had differences, so we decided to use the word "agile" to describe what we have in common.


l         Email-- mailto:kent@threeriversinstitute.org.


l         notyy: will you come to china to coach some chinese company?

l         我非常希望能訪問中國。我輔導的團隊包括整個美國及歐洲許多地方。現在我開始在亞洲工作。我發現在不同文化當中找尋甚麼是比較困難或者甚麼是比較容易是滿有趣的。瑞士日耳曼人喜歡撰寫測試,墨西哥人喜歡雙人組程式設計,重整在美國中西部非常流行。

l         Re: visiting China. I would love to. I have coached teams all over America and several places in Europe. Now I'm beginning to work on Asia. I find it fascinating what is difficult and what is easy in different cultures. Swiss Germans like writing tests. Mexicans like pair programming. Refactoring is popular in the mid-west of America.


l         lovelybug28: kent,sorry,i am new to xp.does xp has maneuverability? i dont like the abstract concept.

l         答覆有關可操作性(maneuverability)的問題。假設你可以將你對一個大型軟體專案的期望切割成一週可以完成的細部。我們每週可以會面而你告訴我哪一個細節是你認為在下一週是最有價值的部分。我不在乎你挑選哪一個部分,所以你可以徹底的改變對於軟體的整個概念而從我這邊聽到任何怨言。是否這就是可操作性?

l         Re: maneuverability. Suppose you could break down your desires for a large software project into one week pieces. Every week we would meet and you would tell me what piece you would think is most valuable to have next. I don't care what piece you pick, so you can radically change your overall concept of the software without hearing any complaints from me. Is that manuverability?


l         taoxie: Is there any academic research work going on around XP? Only it is just industry-oriented?

l         答覆有關XP及學術性的問題。我們一些進度。有一些傑出的教授像Ralph Johnson有開設XP的課程。XP有許多教育上的優點。反覆式開發讓學生有機會嘗試許多不同的變化。

l         Re: XP and academics. We are making some progress. There are prominent professors, like Ralph Johnson, that teach XP in their courses. XP has many pedagogical advantages. Iterations give students the chance to try many different variations.


l         答覆有關實際範例的問題。有一本不錯的書『XP in Practice』其中討論一個實際的(如果是小的)專案。

l         Re: real examples. There is an excellent book, XP In Practice, that talks about a real (if small) project.


l         skyin: Mr. Beck, tell us your personal toolbox for programming in XP,ok?

l         我的工具箱?我以Smalltalk寫程式時使用VisualWorks而如果我自己撰寫程式碼時使用Refactoring Browser,如果我使用Java撰寫程式碼時使用Eclipse及JUnit。我只使用兩種語言。

l         My toolbox? VisualWorks for Smalltalk and the Refactoring Browser if I'm coding for myself, Eclipse and JUnit if I'm coding in Java. Those are the only two languages I use a lot.


l         lovelybug28: about maneuverability, but we do so before xp appears...

l         答覆由關可操作性的問題。如果你已知道如何做,XP可以從你身上學到一些東西。

l         Re: maneuverability. If you already know how to do this, then XP has something to learn from you.


l         notyy: is OOAD a must in xp?

l         答覆OOAD的問題。你必須做分析及設計決策。問題是何時及你如何以符號表示(notate)。詳細分析決策在每一個反覆中決定,而符號表示就是自動測試。設計決策是在故事評估、反覆規劃、及撰寫程式碼中決定而符號表示就是程式碼及單元測試。

l         Re: OOAD. You must make analysis and design decisions, of course. The question is when and how to you notate them. Detailed analysis decisions are made iteration by iteration, and notated as automated tests. Design decisions are made during story estimation, during iteration planning, and during coding, and are notated as code and unit tests


l         tensile: Mr. Kent, how to execute XP in Company?

l         答覆有關如何在一家200人的公司導入XP的問題。我發現你需要一個技術高手(champion),他願意深入學習並且教導這個技術,一個企業高手去說服企業溝通以嘗試故事及反覆,及一個執行高手以讓每一個人不會異常而導致第一次要做的事背離。所有的改變一次完成。在XP中game的目的是在給定的任何的日期盡可能的交付最有價值的軟體。要能夠如此,團隊中的每一個人必須放棄絕對的符號表示法(notions of absolutes)並且持續的學習。

l         Re: starting XP in a 200 person company. What I have found is you need a technical champion, who is willing to deeply learn and then teach the techniques, a business champion to convince the business community to try stories and iterations, and an executive champion to keep everyone from freaking out the first time things go wrong. All change is accompanied by chaos. The goal of the game in XP is to get as much of the most valuable software delivered as possible by any given date. To do this, everyone on the team must give up notions of absolutes and live with constant learning.


l         notyy: Are there any real projects that are implemented with XP process? How about the effect.

l         答覆有關實際專案的問題。在XP信件列表中我猜有超過100個實際專案。全世界可能不超過1000個專案使用XP。

l         Re: real projects. The XP mailing list has representatives from more than a hundred real projects, I would guess. There probably aren't 1000 projects in the world using XP yet, though.


l         charles_y: Why XP called xp?

l         『終極(extreme)』就像終極運動員,這些人事前有周密的準備並且達到他們最大的可能性。『程式設計(programming)』是因為最後我們從執行的系統獲得我們的報酬。

l         "extreme" is like extreme sports, where people prepare carefully and then achieve the impossible. "programming" because at the end of the day what we get paid for is running systems.


l         adylee: why do u call "extreme" programing rathan than other words ?

l         答覆有關『終極』的問題。名稱是準確的、可記憶的及可辯護的(defensible)。可辯護的是最重要的。我要名稱是我的『敵人』絕不會說他們是正在做的。

l         Re: "extreme". You want names to be accurate, memorable, and defensible. This last is most important. I wanted a name that my "enemies" would never say they were doing.


l         lovelybug28:can you give me one sentence which summarize the essential of xp?

l         答覆有關開始使用XP的問題:這裡有一些練習。寫下你需要做的任何事。說明每一件事需要花多少的時間。累積這些數字。決定哪些不做。

l         Re: starting to use XP. Here's a simple exercise. Write down everything you need to do. Say how long each will take. Add up the numbers. Decide what not to do.


l         xlp223:  what are your enemies?

l         答覆有關『敵人』的問題。我不是真相使用這個字眼,我只是嘗試打字快一點。當我命名XP的時候我的心中有Grady Booch這個名字。他對於軟體開發程序與我有不同的概念(不完全是錯誤,只是不同)如果我要建立一個流行的事物,將會對Rational有一些壓力說他們也在做這件事。他們不曾說過他們是『終極』,既使他們說他們是『輕快(agile)』

l         Re: "enemies" I didn't really want to use that word, but I'm trying to type fast. When I named XP, I had Grady Booch in mind. He has a different concept of software development than I do (not wholly wrong, just different). If I created something popular, there would be pressure for Rational to say they were doing it, too. They have never said they were "extreme", although they do say they are "agile".


l         zer: before code,we must design everything in SE.

l         Zer為什麼你要設計所有的東西,如果你設計前面一半回如何?

l         Zer- why must you design everything. What would happen if you only design for the first half?


l         xlp223: there is very different in mind between rup and xp?

l         答覆有關RUP與XP的問題。XP是一種開發程序,RUP是開發程序的架構,RUP有預設的舉例說明(instantiation)看起來非常類似製造業(manufacturing)。

l         Re: RUP and XP. XP is a process. RUP is a process framework, with a default instantiation that looks a lot like manufacturing.


l         morenew: can you tell me about the rule of planning XP? and the keys of XP?

l         答覆有關規劃的問題。協商的範圍。時間、品質及成本是固定的。這是XP的方式。

l         Re: planning. Negotiate scope. Time, quality, and cost are fixed. That's the XP way.


l         fdu_se01: Does XP promote the idea that "everyone is differently important in the organization"? if it's the case, how do you deal with fluctuation of human resource?

l         答覆有關變動的問題。XP規劃中的規則是每一個反覆(1-3週)你規劃要完成的與你實際在上個反覆當中完成的一樣,如果你提早完成,你可以要求更多的工作。如果你快要來不及了,你要求你要延遲的。這個簡單的規則優雅的控制休假、人力的成長、雇用、及專案間的移動。

l         Re: fluctuation. The rule in XP planning is that every iteration (1-3 weeks) you plan to accomplish as much as you actually accomplished in the previous iteration. If you get done early, you ask for more work. If you are going to be late, you ask what you should defer. This simple rules elegantly handles vacations, personal growth, hiring, and shuffling between projects.


l         這裡有許多問題是關於「我們應如何在中國恰當的實施」。我建議你們由小的區域性的團體自行回答這個問題。你們的答案應該會比我的好。全世界有約20個這類的團體,而他們實際上幫助參與者。XP長期的未來將變得脆弱及老舊並且這些將有某些更好的東西來替換。介於50年間,不管如何,我期望許多XP實作者接受「只要以正確的方式做事情」。先寫測試、重整、快速具體的可交付性(quick concrete deliverables)、團隊結合商業(teams combining business)及技術才能(technical talent)。

l         There are lots of questions about "exactly how do we do this in China". I recommend that you form small, geographically localized groups to answer these questions for yourselves. Your answers will be much better than mine. There are probably 20 of these groups worldwide, and they really help the attendees. The long-term future of XP is that it will get brittle and senile and be replaced by something better. In the intervening 50 years, however, I expect many of its practices to be accepted as "just the right way to do things". Test-first, refactoring, quick concrete deliverables, teams combining business and technical talent.


l         fdu_se01: 2 ways to show a pic.First, show it as a whole from light to dark. Second, show it from part to part.Which way do you prefer?(Did I explain my question clearly?))

l         答覆有關顯示一個圖片的兩種方式。我不確定我瞭解你的意思。我偏向於從具體到抽象,資料到理論。這是你的意思嗎?

l         Re: 2 ways to show a pic. I'm not sure I understand. I tend to work from concrete to abstract, data to theory. Is this what you mean?

整理翻譯:Areca Chen