Scrum實施情況調查之案例分析

導讀：
　　社區Agile主題敏捷實施,企業級敏捷標籤Scrum作者李劍，在InfoQ中文站上發表了一篇"Scrum在中國——企業實施情況調查實錄"。這份調查實錄，分別調查了五個實施SCRUM的公司，其中三家公司實施成功，二家公司失敗。我建議所有準備或者正在實施SCRUM 的人們都能來讀一下。
　　在此，我們會對這篇文章中的案例分類進行分析、診斷。並探討什麼是敏捷開發方法、什麼是SCRUM、使用敏捷方法需要什麼條件、它可以解決什麼問題以及如何在團隊中合理的使用敏捷方法。
　　什麼是敏捷開發方法？什麼是SCRUM？有人在這個字面上下功夫，說敏捷就是反應要靈敏，動作要快捷；有人還在字面上進行延伸，說敏捷就是又好又快，或者就是多快好省；有人說敏捷就是光寫代碼不寫文檔；有人覺得敏捷就是沒有制度，管理鬆散的工作方式；有人覺得只要敏捷了，就代表高軟件交付水平。
　　那麼，敏捷這個詞到底由何而來呢？在九十世紀中期，涌現了一批軟件行業的激進人士，他們反對那些以過程爲本的重型軟件開發方法（例如：傳統的瀑布開發方 法）。在2001年，17位軟件業界的專家們齊聚一堂，討論正在興起的輕量級開發方法（Lightweight methods）。專家們給這類輕量級的方法學起了一個新的名字叫做敏捷，併發布了敏捷開發者宣言。
　　敏捷方法強調以人爲本，專注於交付對客戶有價值的軟件。在高度協作的開環境中，使用迭代式的方式進行增量開發，經常使用反饋進行思考、反省和總結，不停的進行自我調整和完善。
　　敏捷開發方法是這些輕量級方法的總稱，它旗下有很多具體的開發過程和方法。主要的有：極限編程（XP）、特徵驅動軟件開發（FDD）、SCRUM開發方法 等等。SCRUM開發方法是由Jeff Sutherland在1993年創立，Jeff也是制定敏捷宣言的17位專家之一。SCRUM借用了橄欖球運動中的術語——一個團隊拿球向前衝。
　　嚴格的說，SCRUM是遵循敏捷方法的一個軟件開發框架。在SCRUM框架中，融入敏捷開發的精神和思想，就被稱作SCRUM開發方法。SCRUM是一個 什麼樣的開發框架呢？簡單說，它由三個角色（Role），三種會議（Ceremonie），三項工件（Artifact）組成。
　　角色（Role）：產品主管（Procuct Owner），他負責項目的商業價值；SCRUM師傅（ScrumMaster），他負責團隊的運轉和生產；以及自組織的團隊。
　　會議（Ceremonie）：迭代計劃會議，每日晨會（daily scrum meetings），迭代回顧會議。
　　工件（Artifact）：用來排列任務的優先級和跟蹤任務。待開發任務列表（product backlog），迭代任務列表（the sprint backlog），進度圖（burndown chart）
　　在敏捷剛出現的時候，極限編程（XP）一直是主流。但是，在敏捷方法開始在全世界流行的今天，爲什麼最紅火的卻是SCRUM？這是因爲SCRUM更容易普 及和推廣。其實極限編程包容了SCRUM方法。我們從工程學的角度，可以把軟件開發分成兩部分：過程（分解任務，排列優先級和迭代計劃）和代碼實現（高質 量的代碼和自動化的代碼保障體系）。其中最難的就是代碼，最有直接商業價值的是過程。SCRUM則迴避了最難的部分，加強和創新了最能直接體現商業價值的 過程部分。
　　這就是SCRUM！
　　現在，我們就開始對案例進行分析和診斷。
　　失敗案例分析我們這裏借用SCRUM實施調查中的兩個詞“成功”和“失敗”。其實，我們很難定義成功和失敗。在實施調查中，失敗可以理解爲使用SCRUM不當，沒有到 達預先的期望，直至最後團隊放棄了SCRUM。成功是意味着大家還在繼續使用SCRUM，從某種程度上說，就是SCRUM達到了團隊的預先期望，至少是可 以接受的期望。
　　我們先看第一失敗案例：某知名大型互聯網公司，被採訪者是一個叫David的工程師。
　　他是這樣總結失敗的原因：“有些高層錯誤理解了Scrum和Agile，導致歪曲了某些東西，使得Agile變得形式化”
　　他們在項目中嘗試使用了SCRUM中的一個實踐：每日SCRUM會議。下面是David描述不瞭解SCRUM的項目經理，如何使用這個實踐的：“項目經理髮現這個東西挺好，就單獨把Daily Scrum拿來進行推廣；結果，這個經理並不理解什麼是Scrum，他把Daily Scrum變成了Daily Report：每個員工都要在早上固定時間開Daily Scrum，然後把當天的任務告訴給他，讓他來決定工作是不是飽滿。而其他Scrum的精華部分都沒有推廣。”
　　有的網友分析，得出結論說失敗是因爲“這家大型互聯網公司的制度和文化的問題”。當然，失敗肯定是跟這有關係，但我覺得還沒有直接上升到整個公司的制度和文化。
　　瞭解SCRUM的人，都會很清楚。他們對SCRUM的應用很初級，也只用了一個SCRUM中提到的晨會（其實，在其它很多的軟件開發方法中都有這個實 踐）。我們可以看出，他們的問題就是：項目經理根本不知道什麼是SCRUM。也許連自己在開發中遇到了主要問題是什麼都還不清楚？就四處尋藥，甚至就給自 己下了一個處方。
　　我們就以每日晨會爲例，在SCRUM中，明顯的提到，在會議中每個人只可以說三件事情：
　　1. 我昨天做了什麼
　　2. 我今天準備做什麼
　　3. 我在工作中遇到了什麼障礙。
　　每日晨會，目的有二點：
　　1. 加強團隊交流和信息共享。互相瞭解彼此都在做什麼工作，完成了什麼任務。這樣，每日的信息傳遞，可以讓每個人可以更多的瞭解整個項目的業務和技術狀況。並 且如果在工作中遇到障礙或問題，也可以在這時候提出來，請求大家的幫助（其實，一般在敏捷團隊中，遇到問題，都會當場就提出來，或直接去找相關的同事，問 他們有沒有處理過類似的問題，或者有沒有一些建議）。
　　2. 促使每個人在早上做好一天的工作計劃。這樣，每個人一天的工作就會有明確具體的目標。這會直接提高一天的工作效率。
　　所以，上面的這個失敗項目根本談不上是在使用SCRUM。連基本的SCRUM框架還沒有弄明白，就更談不上敏捷的精神和思想了。
　　第二個失敗案例是一個離岸開發的某創業型公司。雖然團隊比較特殊（離岸開發團隊），但這個失敗案例卻非常典型和普遍。“某一天，國外的PM突然發來幾個鏈接，一看講的是一個聞所未聞的詞，就是Scrum了。好像就給了一兩天的時間去看Scrum的介紹文檔，然後就開Stand-up Meeting（站立會議）。”
　　和第一個案例相比，這個案例的團隊是真真的在推行SCRUM。從表明看，大家也是在按照SCRUM框架的方式工作：有相應劃分的角色，有具體的分解任務，有會議，也有迭代（Sprint）。那又怎麼會失敗呢？
　　顯然，他們是在照搬照套了SCRUM的框架。他們是兩個離岸的開發團隊，因爲地點、時區和語言的差異，很容易就會導致溝通和交流不暢，這時候再生硬的引入SCRUM，無異是火上澆油。
　　下面我們來看看他們是如何使用SCRUM。
　　1. 每日晨會
　　“其 實大家都知道溝通進度的重要性，但我們雙方7、8個小時時差，那邊一上班這邊就快收拾東西走人了，就這樣還要講自己今天要做些啥，遇到啥困難，一點意思都 沒有。很快Stand-up Meeting就成了形式。後來，我們又間歇性地在自己團隊內部做Standup，但最後還是因爲不能帶給我們太大價值，流於形式，就放棄了。”其實，在敏捷的實踐中，每日晨會是最容易做，也是最有效果的實踐之一。那爲什麼最後會流於形式，而放棄了呢？
　　一、 會議的時間不好。中國團隊快下班了，準備收拾回家。通過我們的實踐，發現站立會議最佳的時間是早上。比如：9點上班，會議時間可以定在9：30。早上到公 司之後，大家收個郵件，處理一下個人的事務。到點了，按時的舉行晨會，然後全身心的投入到一天的工作中。這樣，很自然，開發節奏很暢快。
　　二、從上面的描述，明顯可以看出來。大家對它是有牴觸心理。或許是在牴觸會議，或許是在牴觸SCRUM，或許本來就已經上火，只是藉此宣泄。
　　三、 這是最重要最重要的一點：團隊的文化氛圍。說具體一點，晨會不是每天的工作報告，更不是項目經理進行工作檢查，甚至考覈。項目經理有責任營造一個安全 （Safe）的會議氛圍，讓每個人都樂意說出真正發生的事情，就算是昨天遇到技術問題，沒有任何的工作成果，也能得到諒解，而不是膽顫心驚。比如：我們在 每天早上做站立會議的時候，可以端杯飲料，很輕鬆的圍成一圈，說說笑笑，然後會議結束，就開始一天的工作。
　　2. 迭代任務
　　
　　“在 第一次使用ScrumWorks的時候，好歹Product Owner還能來設置優先級，我們估算時間，最後決定哪些故事放到下一個Sprint裏面。到後來就只要是人，就能往Scrumworks上扔任務，也不 知道哪些重要哪些不重要，我們自己開發人員看着辦，最後剩下幾百個小時完不成再扔到下一個Sprint裏面去”顯 然，大家的迭代過程很隨意，鬆鬆散散，沒有任何的約束。有的網友說這是公司制度的問題。那無疑是在“頭痛醫頭，腳痛醫腳”。如果，這時還拿制度說事，明顯 是在和敏捷精神相悖。敏捷方法，表明看上去管理鬆散，沒有規章制度。其實不然，它有很多的準則，要求每個人能夠自覺遵守，養成工作習慣，成爲一種職業素 質，最終目標是要形成一個自組織的團隊。例如，誰可以往Scrumworks上扔任務？這明顯是產品主管的職責。就算是開發人員想往上扔任務，也應該和產 品主管以及整個團隊討論，明確任務的價值和優先級之後，再決定是否可以把任務放到當前的Scrumworks上。這是最的基本要求，這是每個團隊成員默認 遵守的原則，甚至可以認爲這是一個開發者最起碼的職業素質要求。
　　我們從上面的描述可以再次看出，大家是在對SCRUM有牴觸的。如果，到現在，推廣者到還不能讓大家理解、認可和接受SCRUM方法。那麼，引入SCRUM，也絕不可能獲得成功，甚至會直接拖垮整個項目。
　　敏捷方法，需要有一個英明的領導（也許就是Scrum Master），以身作則，帶領着團隊向前衝鋒，大家齊心協力，以項目的成功作爲最高奮鬥目標。只有這樣，才能發揮敏捷方法的威力，只有這樣項目纔可能獲得成功。
　　再回到迭代開發，它能給我們帶來什麼樣的好處呢？
　　一、 明確的短期目標。如果讓一個團隊做半年的詳細工作計劃，一定非常困難，但如果是2周，那就完全不一樣。假設，客戶有100個東西要做，但團隊在一個迭代 （一般是2周左右）中，只能完成20個東西。那麼就明確的告訴客戶，一個迭代的時間，我們只可以完成20個東西，那麼我們先開發其中20個最有價值的東西 好嗎？
　　二、如何知道團隊在一個迭代可以完成多少任務呢？顯然，迭代只有兩週的時間，相對的計劃會很準確，而且前面一個迭代的工作量，是這個迭代最好的參照。如果是第一個迭代，根據團隊的經驗做好一個合理的2周計劃應該不難。
　　三、迭代結束之後，給客戶演示工作成果，及早獲得用戶反饋。同時團隊在一個迭代結束之後，也會對整個開發的狀況進行思考和反省，舉行一個回顧會議，客觀的討論前一段時間的工作，哪些地方做的好，哪些地方做得不夠好，對不好的地方，要能討論出具體可行的解決辦法。
　　敏捷的團隊就是用這種迭代的方式，增量的進行工作。小步前進，不停的思考、反省和總結，不停的進行自我調整和完善。讓自己一步一步的變得優秀，走向卓越。
　　總而言之，如果只是學了SCRUM的形，卻沒有敏捷的意，沒有掌握敏捷的思想和精神，那麼再怎麼使用SCRUM，仍然只是在東施效顰。
　　成功案例分析到此，也許你會吸取上面兩個失敗案例的教訓，也認同文中的分析，覺得敏捷很實用、很有價值；也許此時，你卻在緊縮雙眉，因爲敏捷的思想和精神，讓你覺得有點理想化，不切實際。
　　是的，思想和精神只可意會不可言傳。這些只可以在每天的工作和問題中去領悟、體會和沉澱。在學習敏捷方法的時候，我們 應該儘可能多和深入的學習，並融會貫通。在具體工作的時候，我們先要忘掉學到的條條框框。首先分析自己的上下文環境，找出最主要的矛盾，然後根據團隊狀 況，通過學到的經驗和方法將這些問題進行平衡和解決。
　　下面我們看一下瓔珞天色是如何在項目引入SCRUM的。他們路線是這樣：“我們不是採用純粹的Scrum，而是將Agile中的很多理念，包括XP的部分做法，然後結合現有的開發環境與要求，用Scrum的回顧不斷地做改進， 從而趟出自己的一條路。如果這個Sprint我們回顧時覺得自己代碼Review（審查）做的不好，下個Sprint就會引入新的代碼Review機制。 這個Sprint覺得重複性的bug較多，下個Sprint就會引入缺陷預防機制。我們是自底向上，先做小範圍試點，再全面推廣，中間對過程進行不斷改進”
　　他們的具體做法如下：“其實我們一開始並沒有把Scrum這個說法拿出來。就是首先和業務一起商量什麼時候上線，商量出來的結果是每個月定期上線。於是就有了一月一個項目的進 度（我們是線上服務，沒有版本的概念，有一堆需求過來，對技術來說就是在這一個月以內完成這些需求，把這一個月以內的工作叫一個項目）。然後爲了管理，我 們開始開晨會。然後爲了改進，我們開始開項目總結會，把Product review和Team retrospective放在一起，既有產品經理介紹現狀，也有大家討論成績，不足和挑戰。後來總結會上覺得質量不好，我們加入了單元測試和代碼 Review機制。至於計劃會議，一開始我們就採用的Scrum的方法。項目小，MS Project太難調。我們就更換了Scrum的Excel計劃表，後來又換了Xplanner。”
　　無獨有偶，這些成功案例的團隊，就是通過這樣的方式進行一步一步推進，把SCRUM成功的引入到了各自的項目中。其中三個成功實施SCRUM的公司，無疑是瓔珞天色的團隊最能深入敏捷的精髓。
　　小結敏捷就是一個團隊持續不斷的自我改進過程，直到那些優秀的品質成爲大家的一種職業習慣——一個自組織的團隊。敏捷沒有終點，我們一直在路上。
　　參考資料 * 《敏捷開發者修煉之道》
　　* "Scrum在中國——企業實施情況調查實錄"
　　* http://www.scrumalliance.org
　　作者介紹
　　錢安川，ThoughtWorks公司－軟件諮詢師、敏捷過程教練、開發者。敏捷項目管理工具Mingle的團隊成員之一。關注中國傳統文化知識。
　　38條回覆
　　Nice!發表人 Myhui Zhang 發表於 2008年5月7日 下午8時24分
　　Re: Nice!發表人 涼粉 小刀 發表於 2008年5月7日 下午11時0分
　　關於敏捷的基本含義 與 打破西式敏捷的話語壟斷髮表人 Charlie Zhang 發表於 2008年5月7日 下午9時21分
　　Re: 關於敏捷的基本含義 與 打破西式敏捷的話語壟斷髮表人 涼粉 小刀 發表於 2008年5月7日 下午9時55分
　　Re: 其實所有人都在盲人摸象發表人 Charlie Zhang 發表於 2008年5月7日 下午10時1分
　　Re: 關於敏捷的基本含義 與 打破西式敏捷的話語壟斷髮表人 樂 田 發表於 2008年5月7日 下午10時10分
　　Re: 熊節不是文青？發表人 Charlie Zhang 發表於 2008年5月7日 下午10時29分
　　Re: 熊節不是文青？發表人 樂 田 發表於 2008年5月7日 下午10時45分
　　Re: 熊節不是文青？發表人 涼粉 小刀 發表於 2008年5月7日 下午10時56分
　　Re: 關於敏捷的基本含義 與 打破西式敏捷的話語壟斷髮表人 qian anchuan 發表於 2008年5月7日 下午10時21分
　　Re: 關於敏捷的基本含義 與 打破西式敏捷的話語壟斷髮表人 Kaijin Lv 發表於 2008年5月7日 下午10時40分
　　Re: 關於敏捷的基本含義 與 打破西式敏捷的話語壟斷髮表人 ozzzzzz liu 發表於 2008年5月8日 上午12時39分
　　少了sprint review？發表人 Yi Xu 發表於 2008年5月7日 下午10時36分
　　Re: FAQ: 少了sprint review？發表人 Charlie Zhang 發表於 2008年5月7日 下午11時11分
　　質疑本文作者對 Scrum 的理解發表人 Charlie Zhang 發表於 2008年5月7日 下午11時1分
　　Re: 質疑本文作者對 Scrum 的理解發表人 柳 輕眉 發表於 2008年5月7日 下午11時6分
　　Re: 質疑本文作者對 Scrum 的理解發表人 柳 輕眉 發表於 2008年5月7日 下午11時9分
　　Re: 質疑本文作者對 Scrum 的理解發表人 qian anchuan 發表於 2008年5月8日 上午1時16分
　　哦，原來你也只是在字面上理解敏捷和 Scrum發表人 Charlie Zhang 發表於 2008年5月8日 下午11時3分
　　軟件開發=過程+代碼實現，荒唐，作者好像不懂軟件工程？！發表人 Charlie Zhang 發表於 2008年5月8日 上午2時59分
　　Re: 軟件開發=過程+代碼實現，荒唐，作者好像不懂軟件工程？！發表人 qian anchuan 發表於 2008年5月8日 上午4時17分
　　Re: 軟件開發=過程+代碼實現，荒唐，作者好像不懂軟件工程？！發表人 YONG LIN 發表於 2008年5月8日 上午5時44分
　　Re: 軟件開發=過程+代碼實現，荒唐，作者好像不懂軟件工程？！發表人 qian anchuan 發表於 2008年5月8日 上午6時36分
　　Re: 不用管作者的狡辯發表人 Charlie Zhang 發表於 2008年5月8日 上午6時44分
　　Re: 設計就是代碼？發表人 Charlie Zhang 發表於 2008年5月8日 上午6時16分
　　Re: 設計就是代碼？發表人 qian anchuan 發表於 2008年5月8日 上午7時10分
　　Re: 設計就是代碼？發表人 涼粉 小刀 發表於 2008年5月8日 上午7時36分
　　支持！曬曬熊節的人身攻擊，供大家參考發表人 Charlie Zhang 發表於 2008年5月9日 上午3時50分
　　Re: 支持！曬曬熊節的人身攻擊，供大家參考發表人 li dapeng 發表於 2008年5月9日 上午4時32分
　　Re: 支持！曬曬熊節的人身攻擊，供大家參考發表人 Charlie Zhang 發表於 2008年5月12日 上午4時33分
　　Re: 支持！曬曬熊節的人身攻擊，供大家參考發表人 li dapeng 發表於 2008年5月14日 上午1時38分
　　Re: 支持！曬曬熊節的人身攻擊，供大家參考發表人 涼粉 小刀 發表於 2008年5月9日 上午4時40分
　　你錯了，任何人都有權評價你和其他 ThoughtWorks 諮詢師發表人 Charlie Zhang 發表於 2008年5月8日 下午10時33分
　　Re: 你錯了，任何人都有權評價你和其他 ThoughtWorks 諮詢師發表人 qian anchuan 發表於 2008年5月8日 下午11時39分
　　眼前所見的喧譁難道就是百家爭鳴！？發表人 li dapeng 發表於 2008年5月9日 上午1時20分
　　Re: 眼前所見的喧譁難道就是百家爭鳴！？發表人 rick chen 發表於 2008年5月9日 上午2時33分
　　Re: 爭吵不是張恂的本意發表人 Charlie Zhang 發表於 2008年5月9日 上午3時40分
　　Re: 眼前所見的喧譁難道就是百家爭鳴！？發表人 sheng wang 發表於 2008年5月15日 上午4時35分
　　Nice!
　　2008年5月7日 下午8時24分 發表人 Myhui Zhang
　　最喜歡這句話敏捷沒有終點，我們一直在路上。關注scrum的還可以參考一下這個mini book,非常好的實踐總結。http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
　　關於敏捷的基本含義 與 打破西式敏捷的話語壟斷
　　2008年5月7日 下午9時21分 發表人 Charlie Zhang
　　作者 錢安川 發佈於 2008年5月7日 下午7時29分：
　　有人在這個字面上下功夫，說敏捷就是反應要靈敏，動作要快捷；有人還在字面上進行延伸，說敏捷就是又好又快，或者就是多快好省
　　這個“有人”大概就是指張恂吧。沒錯，這些就是我們中式太極敏捷的主張，除了只“在字面上下功夫”。要真正理解敏捷，從基本概念、字面含義開始不啻爲一種好方法。
　　“敏捷就是反應要靈敏，動作要快捷；敏捷就是又好又快，或者就是多快好省”，不但是我們中式敏捷的基本主張，也符合西式 Agile、light-weight 過程的基本含義。當然，Agile 的含義不止於迭代和輕載。
　　如果一種方法不具有英文單詞 Agile 的基本含義，怎麼會叫 Agile？難道西方的敏捷大師們也都是些文盲？不會吧。作爲一名本土中國人，我也始終弄不明白，爲什麼一種方法不能做到起碼的“敏”和“捷”，可以叫“敏捷”？作爲知識分子、知識青年的我國程序員們，邏輯思維不能這樣差吧。
　　當然，張恂的文章《Agile 與太極敏捷：到底啥是敏捷？》只是初初開了個頭，從敏捷這個單詞的基本含義講起（實在看不慣國內一些文盲型的程序員老是在那裏忽悠），敏捷的含義當然非常豐富，不僅如此。
　　張恂差不多有 8 年以上的敏捷實踐經驗，可能是國內最早採用敏捷實踐的程序員之一（早於 2001 年），因此決不是在玩字面，比 ThoughtWorks 諮詢師熊節（Jeff Xiong）那一派的弄文青年要好得多。
　　我覺得，在中國推廣敏捷，首先要打破 ThoughtWorks 和西式敏捷的“話語壟斷”（如果這種壟斷存在的話），尤其要警惕某些人片面打着 ThoughtWorks 或者西方敏捷大師的旗號、話語來誤導。
　　敏捷 OO 教練 張恂
　　www.zhangxun.com
　　Re: 關於敏捷的基本含義 與 打破西式敏捷的話語壟斷
　　2008年5月7日 下午9時55分 發表人 涼粉 小刀
　　瞎子只摸到大象的尾巴，所以覺得大象跟蛇長得一樣。
　　“敏捷就是反應要靈敏，動作要快捷；敏捷就是又好又快，或者就是多快好省”。這種說法跟盲人摸象有什麼區別？
　　玩“窺一斑而知全豹”也沒這麼玩的啊
　　Re: 其實所有人都在盲人摸象
　　2008年5月7日 下午10時1分 發表人 Charlie Zhang
　　你說的很對，搞科學技術，其實所有人都在盲人摸象。
　　把大家的意見拼起來，就接近全豹了。
　　要不，你給我弄只全豹來看看 ...
　　2008年5月7日 下午9時55分 發表人 涼粉 小刀
　　瞎子只摸到大象的尾巴，所以覺得大象跟蛇長得一樣。
　　“敏捷就是反應要靈敏，動作要快捷；敏捷就是又好又快，或者就是多快好省”。這種說法跟盲人摸象有什麼區別？
　　玩“窺一斑而知全豹”也沒這麼玩的啊
　　Re: 關於敏捷的基本含義 與 打破西式敏捷的話語壟斷
　　2008年5月7日 下午10時10分 發表人 樂 田
　　根本沒有必要去攻擊熊節，因爲他不是文青，在引導大家接受敏捷的過程中他還貢獻了不少開源項目，是實踐與講授相結合的。不寫代碼瞎白話那纔是亂來。敏捷不分國界，沒有必要有中外之分。敏捷是以團隊爲單位的實踐，在使用的過程中是混合的。我覺得非要提出所謂太極敏捷這樣一個口號，真的是無聊。敏捷開發者通過交流可以不斷的改進自己使用的過程！所以說永遠是在路上的。這個年代方法不應該分國界，開口閉口西方怎麼樣，中國怎麼樣，這才叫欺騙和利用民族感情而實現自己的不可告人的目的。
　　Re: 關於敏捷的基本含義 與 打破西式敏捷的話語壟斷
　　2008年5月7日 下午10時21分 發表人 qian anchuan
　　這個“有人”大概就是指張恂吧。沒錯，這些就是我們中式太極敏捷的主張，除了只“在字面上下功夫”。要真正理解敏捷，從基本概念、字面含義開始不啻爲一種好方法。 當然，這是貴教派的理解和教義，你有權利執意把敏捷理解爲：敏捷就是反應要靈敏，動作要快捷；敏捷就是又好又快，或者就是多快好省但，這只是一些文字面的解釋，並不是敏捷開發方法的真正內涵。別以爲自己把‘敏捷’的中文含義弄明白了，就不是文盲了。
　　如果教主想討論scrum，討論敏捷，討論軟件技術；非常歡迎。別把話題扯那麼遠。文章發在社區，就是社區的聲音。
　　Re: 熊節不是文青？
　　2008年5月7日 下午10時29分 發表人 Charlie Zhang
　　2008年5月7日 下午10時10分 發表人 樂 田
　　根本沒有必要去攻擊熊節，因爲他不是文青 ...他不是文青？我看你太無知了，一點不瞭解歷史。新來的？
　　熊節早在 2005 年之前就成爲名家了，難得的 CSDN、《程序員》雜誌高產技術作家，數一數二的以文筆著稱的文青，麥克盧漢的忠實擁躉者 ...
　　而且，早在 2004 年就侮辱自己的批評者爲褲腿追咬者，現在不但給 ThoughtWorks 丟臉，還給 InfoQ 的中文編輯團隊丟臉。
　　你好像也是 TW 員工吧，熊節的同事？我看你的基本價值觀也有問題。請告訴我什麼是 ThoughtWorks values？您應該參加過新員工培訓吧。
　　作爲專業程序員，請你記住：沒有調查，就沒有發言權。
　　少了sprint review？
　　2008年5月7日 下午10時36分 發表人 Yi Xu
　　會議（Ceremonie）：迭代計劃會議，每日晨會（daily scrum meetings），迭代回顧會議。是不是少了sprint review？
　　Re: 關於敏捷的基本含義 與 打破西式敏捷的話語壟斷
　　2008年5月7日 下午10時40分 發表人 Kaijin Lv
　　中式敏捷是什麼意思，敏捷分中外嗎？還加上太極，搞得跟什麼似的。前一陣，看到有人千里迢迢去清華學習所謂的“周易管理學”。那個所謂的“周易管理學”跟你的“中式太極敏捷”有異曲同工之妙啊！我說，最值得警惕的不是ThoughtWorks那幫人，而是像你這樣，把別人的好東西拿來，加上點中國人自己發明的”糟粕“，然後自以爲可以自成一派，掛羊頭賣狗肉，到處忽悠錢財的人。
　　Re: 熊節不是文青？
　　2008年5月7日 下午10時45分 發表人 樂 田
　　我瞭解歷史，我也瞭解你的事情，沒有什麼奇怪的。作爲程序員你應該知道技術推動的價值！不要隨便攻擊別人寫的東西。 InfoQ和ThoughtWorks都是我工作中的團隊，我瞭解我的同事們。而且作爲一個沒事總是出來職責別人的人，我不知道你給社區貢獻了什麼呢？如果你堅信你的觀點，請你來參加Beijing Open Party，歡迎和我們面對面的討論問題，不要用你流暢的文筆來散佈這種沒有意義的言論。
　　Re: 熊節不是文青？
　　2008年5月7日 下午10時56分 發表人 涼粉 小刀
　　贊。
　　我們正在討論在Beijing OpenParty中添加新的活動形式，包括pk挑戰賽等。如果掌門願意自降身價跟我們這些草莽見面的話，不妨過來玩玩
　　Re: Nice!
　　2008年5月7日 下午11時0分 發表人 涼粉 小刀
　　感謝關注，這本書即將翻譯完成。中文版會很快跟大家見面的。
　　質疑本文作者對 Scrum 的理解
　　2008年5月7日 下午11時1分 發表人 Charlie Zhang
　　作者 錢安川 發佈於 2008年5月7日 下午7時29分
　　嚴格的說，SCRUM是遵循敏捷方法的一個軟件開發框架。在SCRUM框架中，融入敏捷開發的精神和思想，就被稱作SCRUM開發方法。SCRUM是一個 什麼樣的開發框架呢？簡單說，它由三個角色（Role），三種會議（Ceremonie），三項工件（Artifact）組成。
　　作者所謂的“嚴格的說”，一點兒不嚴格。
　　嚴格地說，Scrum 原本是一個敏捷、迭代的項目管理框架，並不是什麼軟件開發框架。management 與 development、engineering 的含義不同吧。
　　正是因爲 Scrum 是一個靈活、輕量的項目管理框架，缺少了具體的工程做法（engineering practices），它纔可以與其它許多更爲具體的軟件工程方法、開發框架互爲補充，纔會出現 Scrum + XP、Scrum + UP 等等集成/組合。
　　正是因爲這個特點，Scrum 纔有了比 XP 更爲廣泛的適用範圍。實際上，Scrum 不但可用於軟件工程的敏捷項目管理，還可以應用到其它領域的項目管理。
　　顯然，作者並沒有真正地理解、把握 Scrum 的本質。
　　敏捷 OO 教練 張恂
　　www.zhangxun.com
　　Re: 質疑本文作者對 Scrum 的理解
　　2008年5月7日 下午11時6分 發表人 柳 輕眉
　　終於看到不是嗷嗷的掐架的了……
　　Re: 質疑本文作者對 Scrum 的理解
　　2008年5月7日 下午11時9分 發表人 柳 輕眉
　　8過偶也粉贊同Charlie滴觀點，把Scrum說是軟件開發框架有點偏離鳥Scrum滴本質
　　Re: FAQ: 少了sprint review？
　　2008年5月7日 下午11時11分 發表人 Charlie Zhang
　　會議（Ceremonie）：迭代計劃會議，每日晨會（daily scrum meetings），迭代回顧會議。 是不是少了sprint review？sprint = iteration
　　Re: 關於敏捷的基本含義 與 打破西式敏捷的話語壟斷
　　2008年5月8日 上午12時39分 發表人 ozzzzzz liu
　　其實你可以去問問拉曼，看看當初是不是差點就把敏捷命名爲輕型。是不是如果叫了輕型，就又如何如何了。而且你也知道Cockburn的水晶方法，是不是就真的水晶了。我覺得你這個人真的有得時候太那個了。當然你要說敏捷裏面有隨機應變，反應迅速的內涵，這個是正確的。但是你要是敏捷就是，如何如何，自然就有邏輯上的問題吧。其實對於敏捷究竟是什麼最明確也是最統一的表述，就是敏捷宣言。其實我想你回到這個大背景下，未必不是一件好事情。而且既然你跟拉曼那麼熟悉，你也可以去跟他們好好交流交流，把你的思想完全表達給他聽聽，看看你們是不是也可以達成共識。當然你希望在敏捷的基礎上發展敏捷，造就有中國特色的敏捷方法，也是可以理解的。但是我覺得你應該光明正大的把你的觀點全面亮出來，也就是你的這個敏捷是你自己發展出來的，同我們現在所說的敏捷不完全是一回事。而且你也別動不動就說你幾年幾年前就實施敏捷了，這樣的話說出來，對你沒啥好作用。你也是三十幾歲，奔四十去的人了，這個道理不應該叫我給你講。
　　Re: 質疑本文作者對 Scrum 的理解
　　2008年5月8日 上午1時16分 發表人 qian anchuan
　　嚴格地說，Scrum 原本是一個敏捷、迭代的項目管理框架，並不是什麼軟件開發框架。management 與 development、engineering 的含義不同吧
　　很明顯軟件開發，包括了軟件的項目管理。建議您先去scrumalliance好好閱讀一下，弄清楚SCRUM,再過來討論
　　http://www.scrumalliance.org/pages/what_is_scrumA lean approach to software development
　　Scrum is an agile software development framework. Work is structured in cycles of work called sprints, iterations of work that are typically two to four weeks in duration. During each sprint, teams pull from a prioritized list of customer requirements, called user stories, so that the features that are developed first are of the highest value to the customer. At the end of each sprint, a potentially shippable product is delivered.
　　A simple framework
　　Scrum is made up of three roles, three ceremonies, and three artifacts.
　　Three roles: the Product Owner, who is responsible for the business value of the project; the ScrumMaster, who ensures that the team is functional and productive; and the self-organized team.
　　Three ceremonies: the sprint planning meeting, daily scrum meetings, and sprint review meetings.
　　Three artifacts for prioritizing and tracking tasks: the product backlog, the sprint backlog, and a burndown chart.
　　關於SCRUM和XP的關係。我認爲，可以說XP就是SCRUM的高級階段。當然，你也可以XP + SCRUM。但，這些並不重要。因爲，敏捷方法學的核心都是不可生搬硬套的。最重要的是，如何通過敏捷的方式，改進你的團隊和項目，提高項目的交付質量。
　　軟件開發=過程+代碼實現，荒唐，作者好像不懂軟件工程？！
　　2008年5月8日 上午2時59分 發表人 Charlie Zhang
　　作者 錢安川 發佈於 2008年5月7日 下午7時29分
　　我們從工程學的角度，可以把軟件開發分成兩部分：過程（分解任務，排列優先級和迭代計劃）和代碼實現（高質 量的代碼和自動化的代碼保障體系）。其中最難的就是代碼，最有直接商業價值的是過程。SCRUM則迴避了最難的部分，加強和創新了最能直接體現商業價值的 過程部分。這裏明明說，軟件開發 = 過程（分解任務，排列優先級和迭代計劃） + 代碼實現（XPer 的腦子裏大概只有代碼實現）
　　可是後面又說：2008年5月8日 上午1時16分 發表人 qian anchuan
　　... 很明顯軟件開發，包括了軟件的項目管理 ...好了，怎麼又冒出一個項目管理，那麼請作者解釋一下，你說的項目管理到底是屬於過程，還是代碼實現？你的軟件工程等式有問題吧，真是一筆糊塗帳。
　　我想，作爲一名職業軟件工程師，通常的理解大概是這樣的：
　　軟件開發 = 需求 + 設計 + 實現 + 測試 + 過程 + 項目管理 ...
　　作者所說的過程（分解任務，排列優先級和迭代計劃），其實通常屬於軟件項目管理範疇，而作者在這裏把項目管理、過程混爲一談，而且大大縮減了軟件開發的內涵。所以，絕不是作者所說的，軟件開發只有兩部分，過程和代碼實現！而且還說什麼，“其中最難的就是代碼”。
　　作者分得清什麼是 design 和 implementaion 嗎？請到 Martin Fowler、Kent Beck 的著作裏找找 design、implementation 這兩個詞的區別，看看設計有多麼普遍。
　　設計是因，代碼（實現）是果。好的軟件是靠設計出來的，軟件開發中，最難的部分當然是設計（包括算法設計、數據結構設計、軟件架構設計等等）了。
　　我覺得這段文字，反映出來的完全是作者對於 XP 和軟件工程內涵的彎曲、片面理解和錯亂的邏輯，屬於 XPer 的 bad smells。我都懷疑你有沒有經過正規的 XP 培訓，怎麼到您這兒，軟件開發就只剩過程和代碼實現了？這種分類一點兒不科學。
　　敏捷 OO 教練 張恂
　　www.zhangxun.com
　　Re: 軟件開發=過程+代碼實現，荒唐，作者好像不懂軟件工程？！
　　2008年5月8日 上午4時17分 發表人 qian anchuan
　　你說的項目管理到底是屬於過程，還是代碼實現？你的軟件工程等式有問題吧，真是一筆糊塗帳。 我明確回答你，我的過程指的是除了程序技術之外的項目活動，包括了項目管理部分。比如：分解任務，排列優先級、迭代計劃，還有相關的會議部分。
　　我們最後交付給客戶的是什麼？可運行的軟件（當然，如果客戶願意花錢買文檔也可以），那就是你的代碼相關的部分，所有活動的目的都在此。如果有人覺得有了需求和設計，剩下編碼就是一幫軟件藍領的活，那就脫離了一切討論的前提。
　　設計是因，代碼（實現）是果。好的軟件是靠設計出來的，軟件開發中，最難的部分當然是設計不好意思，在所有的敏捷開發方法中，從沒有你這樣的說法。相反，是反對單純的設計，這很容易過渡設計，造成浪費，設計不合實際的東西。所以，爲了消除以過程爲主的軟件開發方法帶來的大量浪費，才發起了敏捷運動。所以，你說的設計，估計這又是你的中國特色，又是中國式敏捷了。
　　設計很重要。但更重要的是設計出來的東西必須是可以實現的（在允許的成本之內）。所以，最好的設計就是最好的代碼，最好的代碼，也就會是最好的設計。
　　軟件開發 = 需求 + 設計 + 實現 + 測試 + 過程 + 項目管理這個公式，怎麼我又面熟又陌生呢。原來：瀑布開發模型 ＝ 需求分析＋設計＋實現＋測試＋安裝＋維護我都懷疑你有沒有經過正規的 XP 培訓請問，你經過正規的XP 培訓了？哪個培訓機構給你做的培訓，又是哪一個講師給你傳授了XP。
　　Re: 軟件開發=過程+代碼實現，荒唐，作者好像不懂軟件工程？！
　　2008年5月8日 上午5時44分 發表人 YONG LIN
　　設計很重要。但更重要的是設計出來的東西必須是可以實現的（在允許的成本之內）這句話100%贊同。 但是最好的設計就是最好的代碼，最好的代碼，也就會是最好的設計就不完全太苟同了。 在我們的開發團隊中，“設計”至少包含兩種：第一種是針對需求和業務做出的high-level design，比如業務上的流程設計，業務之間的接口設計等，這是需要對用戶業務非常熟悉的分析師來做的（我們的分析師都是有多年編程經驗，對用戶業務非常熟悉的高級工程師慢慢培養出來的），這些設計是需要詳細的文檔的，必要時候，還需要和用戶溝通；第二種是具體代碼編寫時候，對模塊劃分，類的設計，算法，邏輯控制的detail-level design，做這種design時，通常也會設計和編寫unit test case，對這種design，一般就沒有非常規格化的文檔了，代碼就是設計了。 這兩種design，都會隨着編碼和開發的深入不斷的review和修正，改進（代碼一級可能就是重構了）。如果把代碼直接理解爲設計，我覺得有點太極端了。
　　Re: 設計就是代碼？
　　2008年5月8日 上午6時16分 發表人 Charlie Zhang
　　2008年5月8日 上午4時17分 發表人 qian anchuan
　　設計很重要。但更重要的是設計出來的東西必須是可以實現的（在允許的成本之內）。所以，最好的設計就是最好的代碼，最好的代碼，也就會是最好的設計。第一句“設計很重要。但更重要的是設計出來的東西必須是可以實現的（在允許的成本之內）”，我同意，設計應該通過編碼和測試的檢驗，但這並得不出後面的結論，或者可以在軟件開發中把設計抹掉。
　　design 是 design，source codes 是 source codes；OOD 是 OOD，OOP 是 OOP。設計是代碼的抽象（比代碼高一層），代碼是設計的具體實現，兩者雖然有聯繫，但顯然不是一碼事，不能混爲一談。
　　算法設計當然是一種設計，模式設計也是一種設計。你能說算法就是代碼？同樣的設計、算法、模式、數據結構等抽象，可以有不同的代碼實現。最好的設計未必有最好的實現（代碼）。
　　軟件工程大師、你們公司 ThoughtWorks 首席科學家 Martin Fowler 就是一位 OOAD 大師。如果你連什麼是 OOA、OOD、OOP，什麼是設計，什麼是實現，什麼是抽象和具象，都分不清，我覺得你沒有什麼臉面做 ThoughtWorks 諮詢師。你所理解的 XP 是片面的。
　　我不知道，爲什麼到了你們這一批國內的 XPers 嘴裏，design 就消失了，即便在 Kent Beck 那裏 design 和 coding 也是分得清楚的吧（當然 XP 的設計可能更多是 implicit design activities，存於頭腦中或白板上的輕便設計）。
　　2008年5月8日 上午4時17分 發表人 qian anchuan
　　我明確回答你，我的過程指的是除了程序技術之外的項目活動，包括了項目管理部分。比如：分解任務，排列優先級、迭代計劃，還有相關的會議部分。Ok，你說的 process 包括“除了程序技術之外的項目活動”，而你的等式是軟件開發 = 過程 + 代碼實現，那麼軟件設計在哪裏？因爲代碼比設計重要，所以就刻意抹掉設計？
　　你怎麼自圓其說？發現我們之間完全是兩個邏輯系統。
　　張恂
　　Re: 軟件開發=過程+代碼實現，荒唐，作者好像不懂軟件工程？！
　　2008年5月8日 上午6時36分 發表人 qian anchuan
　　設計很重要。但更重要的是設計出來的東西必須是可以實現的（在允許的成本之內）這句話100%贊同。 但是最好的設計就是最好的代碼，最好的代碼，也就會是最好的設計就不完全太苟同了。 在我們的開發團隊中，“設計”至少包含兩種：第一種是針對需求和業務做出的high-level design。。。。。第二種是具體代碼編寫時候，對模塊劃分，類的設計，算法，邏輯控制的detail-level design，做這種design時，通常也會設計和編寫unit test case，對這種design，一般就沒有非常規格化的文檔了，代碼就是設計了。如果把代碼直接理解爲設計，我覺得有點太極端了。我覺得YONG LIN說的對。關於你說的，我和一些朋友也激烈討論過。我的那句話，主要是對後面的一種情況完全成立。那句話是用來批判這個的：設計是因，代碼（實現）是果。好的軟件是靠設計出來的，軟件開發中，最難的部分當然是設計
　　Re: 不用管作者的狡辯
　　2008年5月8日 上午6時44分 發表人 Charlie Zhang
　　大致同意，你們做得不錯。
　　2008年5月8日 上午5時44分 發表人 YONG LIN
　　在我們的開發團隊中，“設計”至少包含兩種：第一種是針對需求和業務做出的high-level design，比如業務上的流程設計，業務之間的接口設計等，這是需要對用戶業務非常熟悉的分析師來做的（我們的分析師都是有多年編程經驗，對用戶業務非常熟悉的高級工程師慢慢培養出來的），這些設計是需要詳細的文檔的，必要時候，還需要和用戶溝通；第二種是具體代碼編寫時候，對模塊劃分，類的設計，算法，邏輯控制的detail-level design，做這種design時，通常也會設計和編寫unit test case，對這種design，一般就沒有非常規格化的文檔了，代碼就是設計了。 這兩種design，都會隨着編碼和開發的深入不斷的review和修正，改進（代碼一級可能就是重構了）。 如果把代碼直接理解爲設計，我覺得有點太極端了。 即便在 detailed level design，代碼仍然不是設計。代碼只是設計的一種結果和表現，設計的內容要比代碼多。
　　對於同一個複雜問題的 design，需要考慮各種 forces、constrains、alternative solutions 和 tradeoffs 等等，這些都能在代碼上反映嗎？不能吧，也就是說 design 的內容很可能要多於 implementaion，而且 design 和 codes 本來就不在一個抽象層次上。
　　作者分不清設計和代碼實現，是一個軟件工程基本功的問題。
　　OOAD*UML 專家 張恂
　　www.zhangxun.com
　　Re: 設計就是代碼？
　　2008年5月8日 上午7時10分 發表人 qian anchuan
　　我覺得你沒有什麼臉面做 ThoughtWorks 諮詢師我有沒有臉面做 ThoughtWorks 諮詢師，你張詢有什麼資格在這裏評論？你就覺得，自己有臉面自封所謂的中國式太極敏捷的太極掌門人。
　　我嚴重申明:社區是用來討論技術問題。可以有不同的意見和觀點。我已經跟你說的很清楚了，我在社區發表的文章就代表了社區的聲音。而且，文章中沒有一個字提及和ThoughtWorks相關的字眼。希望你不要再有這樣類似的句子出現。否則，我就有理由對你作爲人的屬性提出質疑。我不會也沒有必要跟這樣一個人進行任何的技術討論。
　　我不知道，爲什麼到了你們這一批國內的 XPers 嘴裏，design 就消失了別給我按個頭銜之類的，我不是XPer，我也從沒有這樣自封過。軟件開發 = 過程 + 代碼你的這個等式是很不嚴格的。不是我的觀點。我認爲，後面兩項是軟件開發最主要的部分。關於代碼和設計哪個重要，很顯然它們不是你死我亡的關係。這是兩個不同類的東西，而且設計是無形的，代碼是有形的載體，是最終的產物，代碼是驗證一個設計好壞的最佳方式。我沒有提及設計，並不表示就不要設計，當然，現在提及了也並不是說就一定要有單純的設計。我同意上面YONG LIN的說法。
　　Re: 設計就是代碼？
　　2008年5月8日 上午7時36分 發表人 涼粉 小刀
　　讓我們在爭論技術問題的時候，少一些人身攻擊吧……
　　你錯了，任何人都有權評價你和其他 ThoughtWorks 諮詢師
　　2008年5月8日 下午10時33分 發表人 Charlie Zhang
　　2008年5月8日 上午7時10分 發表人 qian anchuan
　　我覺得你沒有什麼臉面做 ThoughtWorks 諮詢師
　　我有沒有臉面做 ThoughtWorks 諮詢師，你張詢有什麼資格在這裏評論？你就覺得，自己有臉面自封所謂的中國式太極敏捷的太極掌門人。
　　我嚴重申明:社區是用來討論技術問題。 可以有不同的意見和觀點。我已經跟你說的很清楚了，我在社區發表的文章就代表了社區的聲音。而且，文章中沒有一個字提及和ThoughtWorks相關的字眼。你在作者簡介中寫道：作者介紹
　　錢安川，ThoughtWorks公司－軟件諮詢師、敏捷過程教練、開發者。敏捷項目管理工具Mingle的團隊成員之一。關注中國傳統文化知識。我想，ThoughtWorks 公司這一點做得很好，在網站上公佈了 ThoughtWorks Values 和行爲準則，其中一個作用就是便於大家的監督。
　　希望你和其他 ThoughtWorks 諮詢師都應該明白，不要以爲帶了 ThoughtWorks 諮詢師的頭銜，獲得的只有風光和利益。如果你們的言行不符合 ThoughtWorks 員工的行爲規範，達不到職業軟件工程師該有的水準，就會遭到大家的批評。
　　此外，我的原話是：軟件工程大師、你們公司 ThoughtWorks 首席科學家 Martin Fowler 就是一位 OOAD 大師。如果你連什麼是 OOA、OOD、OOP，什麼是設計，什麼是實現，什麼是抽象和具象，都分不清，我覺得你沒有什麼臉面做 ThoughtWorks 諮詢師。我說的是假設，是有前提的，希望你不要誤解和誤導。有沒有臉面做，應該由你本人作出判斷。斷章取義是很拙劣的辯論技巧。
　　關於太極敏捷派的“掌門”之稱謂，只是我的一句玩笑話，既然引發了這麼多人的不安、焦躁和紅眼，那麼以後我不叫就是了。
　　張恂
　　哦，原來你也只是在字面上理解敏捷和 Scrum
　　2008年5月8日 下午11時3分 發表人 Charlie Zhang
　　作者 錢安川 發佈於 2008年5月7日 下午7時29分
　　嚴格的說，SCRUM是遵循敏捷方法的一個軟件開發框架。ScrumAlliance：“Scrum is an agile software development framework.”
　　並不是一種嚴格的說法，請注意，關鍵詞在“嚴格”。如果讓“開發”包含了“項目管理”，那麼說 Scrum 是開發框架，也算 ok，不是什麼大錯，但並不嚴格。
　　作爲開發框架，Scrum 與 RUP、XP 顯然有明顯的區別，因爲 Scrum 中並不包含如何做需求，如何做設計、編碼，如何做測試 ... 的指導，需要填補其它的開發方法（工程實踐）。Scrum is made up of three roles, three ceremonies, and three artifacts.
　　Three roles: the Product Owner, who is responsible for the business value of the project; the ScrumMaster, who ensures that the team is functional and productive; and the self-organized team.
　　Three ceremonies: the sprint planning meeting, daily scrum meetings, and sprint review meetings.
　　Three artifacts for prioritizing and tracking tasks: the product backlog, the sprint backlog, and a burndown chart. 看了 ScrumAlliance 定義的內容就知道，本質上，Scrum 就是一個簡約的敏捷、迭代項目管理框架，它不但適用於軟件開發、軟件工程，還可以用在其它管理領域，顯然這是更爲準確和嚴格的說法。
　　如果 Scrum 只是一個軟件開發框架的話，那麼原案例中的：張漢東：我們整個公司現在採用Scrum式的管理，如開發部門，銷售部門及HR部都會遵守Scrum規則。因爲我們也是初次嘗試使用Scrum，所以大家都嚴格遵守規則。有新人進來的時候，也沒有立即給新人講解Scrum的概念，只是讓他在日常的工作中，慢慢習慣Scrum規則。公司暫時完成了兩個Sprint嘗試，收益不敢說有多大，起碼讓我們每個人每天的工作都很有目標感，讓我們在客戶所規定的期限裏完成了那個迭代。我們正在準備啓動下一個Scrum開發項目。總的來說，一句話，我們也是在Scrum的嘗試中。怎麼解釋？銷售、HR 不會也屬於“軟件開發”吧？
　　顯然，我覺得張漢東及其同事們比你更懂 Scrum，他們領會了 Scrum 作爲迭代式管理框架的精髓。
　　敏捷 OO 教練 張恂
　　www.zhangxun.com
　　Re: 你錯了，任何人都有權評價你和其他 ThoughtWorks 諮詢師
　　2008年5月8日 下午11時39分 發表人 qian anchuan
　　你在作者簡介中寫道： 作者介紹 錢安川，ThoughtWorks公司－軟件諮詢師、敏捷過程教練、開發者。敏捷項目管理工具Mingle的團隊成員之一。關注中國傳統文化知識。 我是隻文章的內容中沒有提及ThoughtWorks，這是作者介紹。是InfoQ要求我提供的。你發表一篇文章，然後雜誌社讓你提供作者介紹，對這個教主也有非議。我真不明白，我作爲一個ThoughtWorker已經幾年了，現在發表一篇文章，有個署名，就讓某些人心理這麼不安嗎？而且，在公司我只是一個普通的員工，一個普通的諮詢師，一個普通的敏捷過程教練，一個普通的開發者。不要以爲帶了 ThoughtWorks 諮詢師的頭銜，獲得的只有風光和利益如果你非要說風光和利益。那就告訴你，我以作爲一個ThoughtWorker而自豪；我以同很多優秀的人一起共事而自豪；我以交付高質量的項目和產品而自豪；我以有機會能把國外先進的技術和開發方法帶到中國而自豪。我得到的利益，就是每天可以開心的工作，做自己喜歡的事情，並把我所學傳授給別人！
　　眼前所見的喧譁難道就是百家爭鳴！？
　　2008年5月9日 上午1時20分 發表人 li dapeng
　　回覆中最多出現的竟然是：教主、熊節、TW。
　　不知道大家是喜歡敏捷還是PK的感覺！？
　　Re: 眼前所見的喧譁難道就是百家爭鳴！？
　　2008年5月9日 上午2時33分 發表人 rick chen
　　有張恂的地方就會有爭吵，而且這麼多年了一直讓人覺得厭煩，你累不累啊。
　　Re: 爭吵不是張恂的本意
　　2008年5月9日 上午3時40分 發表人 Charlie Zhang
　　首先真理不辯不明，我的本意並非和誰爭吵。
　　可能很多 80 後、90 後不知道，我們國內的（民用）軟件工程與美歐相比，在許多地方其實還相當落後，主要是因爲講科學、有科學信仰的科學家、工程師出來講話的人太少，而市面上混混、逢迎拍馬、投機取巧之類的業餘草莽太多，這是大的背景。
　　所以，只要媒體上、輿論圈裏還活躍着這些僞專家、錯誤的觀點和言論，只要在張恂的本職工作力所能及範圍之內，我會堅持批評下去（當然，也歡迎大家對我的批評），不管花多少年，我把這個當成終生的事業，因爲我有科學的信仰，所以不會累的。
　　張恂
　　支持！曬曬熊節的人身攻擊，供大家參考
　　2008年5月9日 上午3時50分 發表人 Charlie Zhang
　　2008年5月8日 上午7時36分 發表人 涼粉 小刀
　　讓我們在爭論技術問題的時候，少一些人身攻擊吧……支持！曬曬熊節（Jeff Xiong）的人身攻擊，供大家參考，引以爲戒。檔次最高的褲腿追咬者
　　http://gigix.blogdriver.com/gigix/199515.html
　　所謂“褲腿追咬者”，是指“不以實用或審美爲目的，專爲駁倒某個特定對手的辯論者”。擁有褲腿追咬者是件值得驕傲的事情，因爲褲腿追咬者的邏輯總是“扳倒了xxx就證明我很NB”，既然如此，這個“被扳倒”的對象無疑已經在褲腿追咬者眼中具有崇高地位了。曾經有一次和Jacques聊起，就像膠片和照片的關係一樣，褲腿追咬者和搞偶像崇拜的fans其實是同一回事。所以，擁有一位迄今爲止檔次最高的褲腿追咬者，我的虛榮心得到了極大的滿足。
　　http://www.iturls.com/~xzhang/reviews/scrafts.htm
　　虛榮心滿足一下就好。還是Kent Beck那句話：“我要去寫程序了。”前一陣沒啥好玩的，隨手寫了點文字；最近又找到了好玩的東東，讓這位褲腿追咬者自己玩去吧，不陪他了。
　　作者： gigix 2004年06月14日, 星期一 15:30
　　Re: 支持！曬曬熊節的人身攻擊，供大家參考
　　2008年5月9日 上午4時32分 發表人 li dapeng
　　真心祝願兩位可以早日握手言和，一起來推動我國軟件工程發展！
　　Re: 支持！曬曬熊節的人身攻擊，供大家參考
　　2008年5月9日 上午4時40分 發表人 涼粉 小刀
　　大家的過往恩怨，希望可以不要在InfoQ上中文站繼續。無論從前的事情在何時何地發生，大家都可以到事件發生的地點繼續做想做的事情，沒有必要滿地開花。
　　最近一段時間在敏捷社區上發生的討論，已經遠遠超出了技術話題爭論的範疇。正如前面一位讀者所說，難道這樣的喧囂就是百家爭鳴麼？
　　希望每個人都可以保持一點冷靜，這是對讀者的尊重，也是對自己的尊重！多謝！
　　Re: 支持！曬曬熊節的人身攻擊，供大家參考
　　2008年5月12日 上午4時33分 發表人 Charlie Zhang
　　2008年5月9日 上午4時32分 發表人 li dapeng
　　真心祝願兩位可以早日握手言和，一起來推動我國軟件工程發展！Dapeng，謝謝你的理解和好意！
　　不過在 Jeff Xiong 正式地向我公開書面道歉之前，我想，談和解還爲時過早。
　　Re: 支持！曬曬熊節的人身攻擊，供大家參考
　　2008年5月14日 上午1時38分 發表人 li dapeng
　　世界上最寬闊的是海洋，比海洋更寬闊的是天空，比天空更寬闊的是人的胸懷。
　　不責人小過，不發人陰私，不念人舊惡。三者可養德，亦可以遠害。
　　以上兩句與君共勉！！！
　　Re: 眼前所見的喧譁難道就是百家爭鳴！？
　　2008年5月15日 上午4時35分 發表人 sheng wang
　　有張恂的地方就會有爭吵，而且這麼多年了一直讓人覺得厭煩，你累不累啊。不同意你這樣不分青紅皁白的說法，作爲一個程序員，邏輯和客觀是很重要的兩個思考特性。有爭吵不假，但要看爭吵是怎麼來的。就學術角度來說，我同意張洵的觀點。只是我建議張洵表達自己的觀點時應該注意方式方法，注意自己的口氣，畢竟文人都是自尊心很強的，激烈的言辭容易導致反感和對立。

本文轉自
http://www.infoq.com/cn/articles/scrum_investigation_case_study