這是敏捷生態系統系列的第五篇（之一，之二，之三，之四，之五）。

本文是2009年剛剛提出敏捷生態系統的時候參與一個MSN討論組時的對話，當時的想法與現在相比尚缺少系統性，但由于有問有答，也包含了本系列所沒有包含的一些信息，僅供參考。

刪除了部分無關的對話。

文章末尾有谷雨霖老師的博客地址，也在CSDN。

?

“敏捷生態--Srcum敏捷開發”--msn群討論 2009-08-25 13:52谷雨霖 說:
時間差不多了
今天我們的主題是“敏捷生態”
有幸請到的是我的老朋友，敏捷專家陳勇先生
M群-項目管理 說:
【系統提示】AlexQin將昵稱更改為AlexQin-QC-深圳
不勝人生一場醉-N/A-海南 說:
鼓 掌
dearChloe-PM-深圳 說:
專家好
Yong CHEN 說:
大家好
M群-項目管理 說:
谷雨霖 說:
陳勇先生在9.12的敏捷中國大會有專題發言
他的介紹：
TechExcel中國區咨詢總監，具有13年軟件研發、管理和咨詢的從業經驗，擁有多年敏捷開發、CMMI、度量與基準比對等多種軟件過程管理咨詢和培訓經驗。他結合企業中大規模團隊的管理需求，成功導入并實施了面向100人左右大團隊的最佳研發管理實踐，融合了敏捷開發實踐和CMMI體系。其以敏捷開發為主要內容提供過咨詢/培訓/專題演講的企業包括Thomson CR / 廣州從興 / 金山軟件 / 盛大網絡等企業。他還在2007/2008年度中國過程改進大會及2009年中國軟件技術大會上進行了《敏捷開發中的度量》、《從交付保證看敏捷開發的價值》等敏捷主題演講。
litao 說:
陳老師好
Yong CHEN 說:
我是昨天剛來的，很高興認識大家。
現在就正式開始了
谷雨霖 說:
下面，我把時間交給陳老師。13：00聽陳老師講述
susan-pm-湖北 說:
鼓掌
xiyeqing99@hotmail.com 說:
(Y)
谷雨霖 說:
余下時間，提問交流
xiyeqing99@hotmail.com改簽名
Yong CHEN 說:
關于敏捷生態，是去年逐漸意識到的一個問題。
M群-項目管理 說:
【系統提示】AlexQin-QC-深圳將昵稱更改為AlexQin(21)-QC-深圳
Yong CHEN 說:
在做CMMI咨詢的時候，一直希望能把CMMI一點一點實施下去，而非一次到位。
這樣對企業的壓力小，還能用已經取得的成就，去鼓舞和支持剩下的工作。
但是一直沒有成功，因為大家也知道，國內做CMMi都是階段式的，直接一級
完全沒有做連續式的，也就是說重點做某些價值最高的過程域，以后再說其他的。
但在國外，基本上則是一半一半。當然原因也很明顯：政府給的補助，是針對階段式的。
所以后來逐漸轉向敏捷以后，也是很想在新的領域引入連續式
在一家南方的公司咨詢的時候，我發現他們有諸多的限制，無法整體實現敏捷。
對了備注一下：這里指的敏捷是Scrum，也就是偏管理的分支，重點內容是需求管理/項目計劃/項目跟蹤
Yong CHEN 說:
大家比較熟悉的TDD/結對編程/重構等屬于關注技術的XP分支
TonyAquarian_IT Consulting_北京 說:
--- 系統提示: 您的聯系人 aquarian - 庸人自擾已使用MSNShell 提供的加密對話功能，該功能需要雙方都安裝MSNShell(?? http://z.xiaoi.com/r?msnshell-download-6zt818.hi5i.cn%2Fmsnshell) 以提升聊天信息的安全性，防止來自網絡的偷窺行為 ---
Yong CHEN 說:
他們的限制主要在于：
1. 團隊內部有相當明確的分工，大家看到需求就知道是誰的
2. 一直是項目經理說了算
當然既然要敏捷，那么2是一定要破除的，一定要讓大家自己估算自己的任務，這樣才能實現承諾，進而激勵工作效率
但是1我當時就想將就一下，畢竟長期而言人們的專業分工已經很難破除了
培訓之后他們就用上Scrum了，過了2個多月，他們進行了兩輪迭代，我滿懷希望地前去做二次指導
結果發現：他們開計劃會議的時候，幾乎同時只有1個人在做自己的估算，別人都在聊天，直到換任務（負責人也相應地換了）
這里就出現了一個問題。我們互動一下，誰知道這種“自己估算自己的任務”的方式有什么不好的地方？
M群-項目管理 說:
【系統提示】aba21st@126.com將昵稱更改為trriger-SQA-上海
北京-QM-李晉James Li 說:
沒啥不好啊。
susan-pm-湖北 說:
缺少和其他成員之間的溝通？
北京-QM-李晉James Li 說:
自己估算，自己最熟悉自己能完成多少東西。
谷雨霖 說:
先聽
Yong CHEN 說:
比項目經理或更高的領導直接指定時間，顯然有其優越性。
谷雨霖 說:
不要打斷
liu.chsh@hotmail.com 說:
“自己估算自己的任務”，成員往往多估計
Yong CHEN 說:
呵呵我就是想互動一下，大家插兩句
打斷正常
谷雨霖 說:
ok;)
依照過去打斷很難收回的，哈哈
Yong CHEN 說:
1. 缺少溝通 2. 往往多估
哈沒事，我來控制。
liu.chsh@hotmail.com 說:
我認為還是互動比較好，老谷來控制
Yong CHEN 說:
為什么會多估呢……
litao 說:
也有可能為了冒進少估把
liu.chsh@hotmail.com 說:
沒有共識，成員不能看到全面，有時也會少估計
北京-QM-李晉James Li 說:
能否delphi一下
Yong CHEN 說:
當然有很多原因：怕完不成；怕忙（偷懶）
北京-QM-李晉James Li 說:
說明一下估算的原因？
Yong CHEN 說:
恩，這樣很多問題就冒出來了，我們可以看到：敏捷要求團隊盡量彌合分工，嘗試一起做估算。
liu.chsh@hotmail.com 說:
多估：主要是想騙PM
少估：主要是不全面
Yong CHEN 說:
好的，剩下的問題：為何要估算？
簡單的原因是：需要一個數字，知道多少天多久
dearChloe-PM-深圳 說:
排計劃呀
xiyeqing99@hotmail.com 說:
pm這么好糊弄啊
Yong CHEN 說:
復雜的原因可以分為兩種：R問題和D問題
liu.chsh@hotmail.com 說:
雖然不好，但是他們還是想這么做
北京-QM-李晉James Li 說:
我們的主要問題是怎么估
story point
Yong CHEN 說:
一個PM或高級領導是容易糊弄的，下面我們馬上會發現有一些人是不能糊弄的：同行，隊員，伙伴
liu.chsh@hotmail.com 說:
做WBS，評價自己多年的經驗
Yong CHEN 說:
這是敏捷計劃的精髓。Scrum計劃嘗試解決R問題和D問題
liu.chsh@hotmail.com 說:
在影響整體進度的情況下，參考一下 資深 成員
Yong CHEN 說:
所謂R問題就是：這個需求說的是什么？實現到何種程度？標準如何？0缺陷嗎？等等
這個是需求問題
在Scrum計劃會議的上半截，Product Owner要給大家統一講解需求，有問題的人隨時提問。
剩下的事情是：誰會有問題？當然是任務的負責人。而我這個客戶由于前面說的原因，提問的人就一個人
自然也只有他徹底明白了任務的需求，而其他人事不關己，高高掛起。
有時其他人也聽到了一些有有疑惑的東西，但既然負責人都說明白了，我還要問什么呢……也就不問了，就埋下了隱患
計劃的第二個問題，是D問題（設計問題）：這個需求用什么方法實現最好？有沒有現成的代碼可以復用？完全復用，還是需要改動一下，還是改動也沒用因為留有后遺癥？
很可惜，D問題不是那么好解決的。
比如如果我是一個高手，來了一個新手，我想知道他怎樣實現“排行榜”功能，怎么辦？
當然我可以讓他說說他打算干什么，可惜程序員都不擅長言談:D
Yong CHEN 說:
計劃會議上也難以讓他把整個實現思路講一遍
這時候，就需要用別的方法了，那就是“CRC32”校驗
不知道大家了解CRC32校驗不
dearChloe-PM-深圳 說:
不了解
Yong CHEN 說:
要想了解一個文件（或某短信息）是否是完整無損的，最簡單的方法是把文件存兩份（或發送兩份），比較一下有無差別。
(R)(L)China_Iverson(R)(L) 說:
程序員都不擅長言談？至少能說清楚吧
Yong CHEN 說:
但這樣實在太費空間時間了，所以科學家們發明了一種方法：
先說個簡單的：就是把文件所有字節加起來（溢出超過256的不要了),把這個校驗和放在末尾。
收到文件后，重新計算一下文件的校驗和，如果一樣，“多半”表明沒有錯誤。
CRC32比校驗和厲害一些，但原理相同。
估算就是這個目的！
03年我做項目經理的時候就是這樣
每天早上20分鐘給大家講講需求和設計，然后挨個問一個問題：
你今天聽了需求和設計，打算寫多少代碼？
他們就用手比劃：2個屏幕，還是5個屏幕
如果我感覺和我想的差不多，就過；如果差別很大，就問問屏幕里邊有什么
用這種方法，只要幾秒鐘，就能對上暗號，“多半”他沒有聽錯想錯，也不會做錯。
說的太多了，有沒有說的不清楚的地方？
chinamath(海茶)-Sr.SE-北京 說:
這個方法好。
dearChloe-PM-深圳 說:
恩
Yong CHEN 說:
當年也是個編程高手，我說說曾經“殺代碼”的經歷，大家就知道估算的重要性了
01年，110行殺到50，第一次殺，上癮了
還是01年，4000行殺到400行
02年，4000行殺到50行（那個程序員干了一個月了，一個下午被殺到50行）
04年，別人殺代碼的記錄：10萬行殺到1.3萬
在4000殺50那次后，我在想：怎樣讓這個程序員干活之前，他的項目經理就知道他要做錯事呢……（當時我是EPG的)
所以在03年我又重新管理項目，實踐出了上面那種方法。
好了，R問題和D問題都解決了，剩下的是：剛才說過，任務都有一個負責人，別人怎么才能替他關心他的R和D問題呢？
在那個客戶那里，采取了兩次步驟
前幾個迭代，小組長（手底下有3/4個人）和那個人一起打牌（計劃撲克，不知道大家了解不？）
我閃屏就是有問題啦，呵呵
也就是讓小組長和手下具體負責人一起計劃
后幾個迭代：先把任務分配到小組（3/4個人）不指定具體負責人，先估算，再分配。
這樣大家不確定是否是自己的事情，不敢怠慢，都會用心得提問需求問題，用心地討論實現方法
討論過程中很快發現，有些需求沒有想到，有些方法是錯誤的
比如有個程序員低估了任務，因為他說有個庫拿過來就能用，另外一個程序員就告訴他：那個庫很難用，自己試過，還不如重新寫一個。等等。
當然，大家用計劃撲克的方法，如果大家數字相同，不會討論直接通過，有人太多或者太少，才會討論。
這樣大大節約了時間，又達到了目的。
好了說了這么多，回到主題：敏捷生態
通過剛才的例子，我們會發現敏捷這里就直接說Scrum把：是一個經過實踐總結出來的方法
他們當年也一定遇到過類似的問題，所以才說：盡量不分工，而是建立跨職能團隊，“所有人干所有事”，才能取得良好的計劃效果
如果把跨職能團隊去掉，仍然開計劃會，仍然有PO，仍然讓大家自己估算自己的任務，效果就很差了。
這就如一個生態系統，各個部分是聯動的，不能輕易去掉其中一個。
哦對了解釋一下另外一個問題：如果有3個人一起估算，這時候就會產生“同行壓力”，沒有人想證明自己是“笨蛋”，所以他們不會故意高估任務，因為自己的同事（技術背景/職位相同）在和自己一起估算
dearChloe-PM-深圳 說:
那怎么辦呢？
Yong CHEN 說:
別人說2天能完，自己偏說4天，顯然有問題。要知道這個工作還沒有分配，未必是自己的工作。
這種同行壓力效果比領導壓力好，因為領導不懂，很容易糊弄，呵呵。
什么怎么辦？如何對待生態系統？
dearChloe-PM-深圳 說:
我是說，因為同行壓力，大家會不會都少估呢？
Yong CHEN 說:
了解了生態系統，就會知道：要上敏捷，盡量完整地接受敏捷，而不要卡在中間，效果不會很好的。
谷雨霖 說:
嗯
Yong CHEN 說:
不會的，無論高估還是低估，都要給大家解釋原因。
dearChloe-PM-深圳 說:
恩
Yong CHEN 說:
敏捷中計劃撲克的玩法是這樣的：
(R)(L)China_Iverson(R)(L) 說:
我覺得應該不會少估吧，因為有可能是自己會開發的
Yong CHEN 說:
1. 講解需求和提問，直到沒有問題
2. 幾個人一起扣著出牌
3. 翻牌，最多的和最少的PK，除非他們差別很小
4. 大家聽他們兩位PK（一般一位會“占理”一些），回到2
5. 中間有任何對需求的分歧，PO解釋（有時候PO也解釋不清楚，這個需求顯然還太模糊）
在這個過程里邊，人們顯然不愿意故意高估或低估（PK中很難給大家一個滿意的答案的）
而尋求真是結果的愿望會占據上風。
(R)(L)China_Iverson(R)(L) 說:
估算的時候是是不公開的嗎？
就是說扣著牌的？
Yong CHEN 說:
對，先扣著出牌，然后一起亮牌
susan-pm-湖北 說:
是怕從眾嗎
Yong CHEN 說:
對啊
xiyeqing99@hotmail.com 說:
這方法好？
(R)(L)China_Iverson(R)(L) 說:
就像評委打分一樣？
xiyeqing99@hotmail.com 說:
Yong CHEN大哥 怎么被你想到的啊
Yong CHEN 說:
這其實就是Delphi的變形，Delphi也是匿名的，但是太慢了。
暈，不是我想到的
谷雨霖 說:
對 delphi增強版
xiyeqing99@hotmail.com 說:
哪位牛人想出來的啊
這么好的主意
Yong CHEN 說:
http://z.xiaoi.com/r?www.planningpoker.com%2F
xiyeqing99@hotmail.com 說:
哈哈
Yong CHEN 說:
老外想到的
敏捷生態是我想到的
xiyeqing99@hotmail.com 說:
老外確實有2把刷子啊
你也有幾把刷子 呵呵
litao 說:
不過還是有問題的,如果時間長了大家都可能在自己的基礎上面高估的
谷雨霖 說:
繼續說生態，沒深入說這個理念
Yong CHEN 說:
對了我們公司要印刷敏捷撲克了，等15天就出來。誰要，給我發郵件，寫個快遞地址
谷雨霖 說:
怎么叫全生態
Yong CHEN 說:
cheny@cheny.com
xiyeqing99@hotmail.com 說:
我要
Yong CHEN 說:
寫郵件
(R)(L)China_Iverson(R)(L) 說:
我也要
Yong CHEN 說:
好，全生態很復雜，但是局部生態是存在的。
比如Scrum在國外其實比XP熱很多，原因就是他的生態系統相對簡單，比較容易建立起來。
xiyeqing99@hotmail.com 說:
恩 Scrum確實簡單點
Yong CHEN 說:
我已經畫好了Scrum生態圖，回頭發給大家。
xiyeqing99@hotmail.com 說:
上次買了本xp的書 看了一頁就看不下去了
Yong CHEN 說:
如果大家用了Scrum，但感覺有件事情怎么也沒做好，就看看與之相連接的生物是否有紕漏。
xiyeqing99@hotmail.com 說:
哦
Yong CHEN 說:
但XP的生態相對復雜，關鍵需要一些技術方法 。
比如你想TDD和持續集成，就需要一些自動化測試工具的支持。
如果老板說：太復雜了或太貴了別買了，你先用用別的條目吧……結果生態系統就被破壞了
chinamath(海茶)-Sr.SE-北京 說:
敏捷撲克太好了，請陳老師留個郵件地址。
Yong CHEN 說:
cheny@cheny.com
chinamath(海茶)-Sr.SE-北京 說:
OK，謝謝！
liu.chsh@hotmail.com 說:
怎么給你錢
Yong CHEN 說:
公司市場部給我錢，呵呵。免費的。
參加敏捷大會的人手一個。
liu.chsh@hotmail.com 說:
但是我不在北京，不能參加，
Yong CHEN 說:
好了回到生態系統：由于Scrum只涉及需求管理/計劃/跟蹤（比CMMI對應內容少），所以存在整體部署的可能。如果要用Scrum，一定要用全！
liu.chsh@hotmail.com 說:
外地，你們幫忙郵寄嗎
Yong CHEN 說:
沒事，給我郵件說清楚地址收件人，快遞過去。
M群-項目管理 說:
Yong CHEN 說:
好了基本結束了，呵呵。
谷雨霖 說:
歡迎“打鬼子”加入;)
S(F)m(F)a(F)l(F)t-梅春 - 打鬼子- 說:
hi
Yong CHEN 說:
會上我會用3～4個例子更詳細地解釋敏捷生態系統，但這里太慢了就不多說了：D
dearChloe-PM-深圳 說:
哎，可惜
Yong CHEN 說:
回頭大會或許有錄像。
剛才是其中一個例子。
S(F)m(F)a(F)l(F)t-梅春 - 打鬼子- 說:
//all
Yong CHEN 說:
打鬼子你好，呵呵
S(F)m(F)a(F)l(F)t-梅春 - 打鬼子- 說:
呵呵。
我來晚了。
谷雨霖 說:
梅總也是很優秀的專家
S(F)m(F)a(F)l(F)t-梅春 - 打鬼子- 說:
大家都這么客氣。。
susan-pm-湖北 說:
歡迎
xiyeqing99@hotmail.com 說:
(F)
谷雨霖 說:
陳老師，你今天講了敏捷，非常打動我。讓我第一次有了推行敏捷的沖動
xiyeqing99@hotmail.com 說:
哈哈
陳老師的msn多少啊
litao 說:
陳老師,我還有問題,如何判斷所有扣牌的人都高估呢?
suzerain1983@hotmail.com 說:
敏捷，英文是什么？
AlexQin(21)-QC-深圳 說:
Agile
susan-pm-湖北 說:
agile?
xiyeqing99@hotmail.com 說:
對
suzerain1983@hotmail.com 說:
謝謝，忘了怎么拼了
Yong CHEN 說:
哈哈以前你沒有推動敏捷的沖動啊，呵呵。
AlexQin(21)-QC-深圳 說:
呵呵
chinamath(海茶)-Sr.SE-北京 說:
實際一般怎么PK？能再講點細節嗎？
Yong CHEN 說:
哦，PO有權利挑戰大家的結果，如果他感覺太高或者太低。
谷雨霖 說:
有沖動，但在全公司推行有阻力和顧慮
Yong CHEN 說:
所以可以防止整體高估或者低估。
liu.chsh@hotmail.com 說:
可以拿項目做示范
Yong CHEN 說:
PK舉個例子：1 2 2 5，1和5PK
1：這個很簡單的啊，就調用個函數，上次小X已經編好后臺了。大家：是嘛？汗～然后，二輪全部變成1
也可能是：
dearChloe-PM-深圳 說:
我想問：　就憑需求，就可以做到那么細致的工作估算？
Yong CHEN 說:
1： 這個……后臺了。5說：但我們不只在游戲里邊做排行榜，還要在網站上做，兩邊同步。
122問：要嗎？
PO：……應該要，網站不是你們做的吧？你們先看你們做要多久，我的記下來，得告訴網站部門也要干活……（寫字）
上面PK的例子是在盛大真實發生的情況，上次剛給他們做過咨詢。
susan-pm-湖北 說:
老師，制定產品清單的過程是誰來做，也需要一個或多個迭代過程嗎
Yong CHEN 說:
只憑借寫出來的需求是不行的，因為寫需求的人也不知道大家想知道什么，不知道什么。
ddv731731-SSE-上海 說:
是SDG,還是SDO
liu.chsh@hotmail.com 說:
開會討論前，讓所有成員都自己準備一下，注意一定要后分工，不要討論前分配工作，不然他們就只管自己的估算了
北京-QM-李晉James Li 說:
今天公司網絡不好。
精彩的部分煤看到。
沒看到。
Yong CHEN 說:
所以一般需求可以寫簡單點，但講解的時候多講點（說話速度比打字快多啦），并且跟著大家的提問講。
北京-QM-李晉James Li 說:
陳老師，放出msn吧。
chinamath(海茶)-Sr.SE-北京 說:
是不是還得有個記錄？否則PK那么多，誰能全記住。
Yong CHEN 說:
當然，講完后，根據大家的提問，把需求補充一下。
liu: 對，討論前要看的，特別是比較大的需求。
SE: 對，有個會議秘書，打字高手（輪流的），記錄一個草稿紙。
北京-QM-李晉James Li 說:
陳老師，重構在什么時候做。
作為一個backlog嗎？
Yong CHEN 說:
我本人的草稿紙現在264頁，從去年7.15到現在。
susan-pm-湖北 說:
老師，制定產品清單的過程是誰來做，也需要一個或多個迭代過程嗎
Yong CHEN 說:
用簡單條目化的文字把PK中發現的問題記錄下來，發送給大家。
Li: 重構經常作為Backlog的一項做。
Susan：是PO在做，他任何時候都可以碰Product Backlog，每個迭代需求都在變多。
說說重構。重構是個很危險的工作，如果用敏捷，一定要有一個高級的設計人員，否則以后全重構了。
北京-QM-李晉James Li 說:
是啊。
另外重構的point也很難估算。
Yong CHEN 說:
所以敏捷原則中有一個，就是要有優秀的設計。
xiyeqing99@hotmail.com 說:
重構是個很危險的工作？
怎么會呢
北京-QM-李晉James Li 說:
還有Springt0與其他sprintx有啥區別
Yong CHEN 說:
恩，Point不好算，當然重構的任務多了，可以參考以前的。
Xiyeqing:因為有些代碼編的很爛，不好改動。
北京-QM-李晉James Li 說:
好像sprint0就是專門確定架構的。
谷雨霖 說:
重構必須要系統級的工程師才能碰，特別是對產品開發
S(F)m(F)a(F)l(F)t-梅春 - 打鬼子- 說:
msn抽風？
Yong CHEN 說:
Sprint0常常指那個做整體計劃的Sprint
xiyeqing99@hotmail.com 說:
是呀 我就是看的重構這本書
覺得越是爛的代碼才越是要重構
否則以后完全沒法維護的
等于要重新寫一個
所以我現在review他們代碼的時候 寫的爛的我都要他們改掉的
Yong CHEN 說:
其實很少有公司實行純粹的迭代開發，那系統架構肯定崩潰。還是要有一系列的Sprint0（而不是1次！）來重新整理一下思路。
北京-QM-李晉James Li 說:
哦？這個思路挺好的。
谷雨霖 說:
時間差不多了，陳老師，你看延長到13：50？別太多打擾了
Yong CHEN 說:
012340123401234，這樣規劃，當然不一定是四次。
恩，重構是必需的，但是“避免重構”也是必需的。高手寫的代碼，即使需求變化了，也不太需要改動太多。
新手的能氣死，只能重寫。要在計劃時就發現這一點，每天做代碼評審，而非最后發現不好才重構。
xiyeqing99@hotmail.com 說:
恩
Yong CHEN 說:
好的，我這邊還有個PPT晚上要交工，呵呵。
xiyeqing99@hotmail.com 說:
重構確實需要一次一小步的
一旦都寫完了 已經好久了 往往沒人肯再花時間去重構了
Yong CHEN 說:
我們公司也在用Scrum，但是我們每半年左右就有一次Release，集中消除BUG，確定下一步方向，等等。
是。
xiyeqing99@hotmail.com 說:
是。 是回答了哪個問題？
Yong CHEN 說:
Xiyeqing:我03年半天進行一次代碼審查，中午就的看看大家的代碼，免得晚上集成不了抓瞎。
回答你的“往往沒人肯……”
xiyeqing99@hotmail.com 說:
啊。。。半天就進行一次代碼審查樂了啊
那頻率很高了哦
呵呵 看來你是個很認真負責的pm啊
Yong CHEN 說:
總歸有站起來走走的時間，就去看看別人的代碼，非正式的。
xiyeqing99@hotmail.com 說:
怪不得混的這么好啊
呵呵
Yong CHEN 說:
每人每天寫100行左右C++，半天50行，2屏幕多點。5分鐘看完。
xiyeqing99@hotmail.com 說:
他們知道你一直要看 肯定沒人敢偷懶
現在我就發現很多人喜歡偷懶
不管了 他就不幫你做東西
Yong CHEN 說:
偷懶不好，到老了就后悔了。
xiyeqing99@hotmail.com 說:
呵呵
其實他們不肯做工作 想學點別的
Yong CHEN 說:
好，基本結束。還有什么集中的問題沒有？
dearChloe-PM-深圳 說:
　學啥？
xiyeqing99@hotmail.com 說:
但是上班時間不可能一直讓你看別的啊
chinamath(海茶)-Sr.SE-北京 說:
謝謝陳老師，今天講的非常好！
xiyeqing99@hotmail.com 說:
他們自己看書
谷雨霖 說:
好了
Yong CHEN 說:
看代碼別太認真，看全局不看細節。差代碼全體換成*我也能看出是壞代碼。
xiyeqing99@hotmail.com 說:
(F)
谷雨霖 說:
非常感謝陳老師的介紹，非常生動易懂。

谷雨霖老師的地址：http://blog.csdn.net/cabinhome/

?

點擊下載免費的敏捷開發教材：《火星人敏捷開發手冊》

轉載于:https://www.cnblogs.com/dairongle97/archive/2011/08/17/2402009.html

總結

以上是生活随笔為你收集整理的敏捷开发生态系统系列之五：关于敏捷生态系统的一次聊天记录（敏捷估算，同行压力，估算扑克）...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。