【原創】2009年8月25日老谷"專案管理MSN群"專題—敏捷生態

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

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/3433/viewspace-613146/，如需轉載，請註明出處，否則將追究法律責任。