[軟體工程]交換程式設計方法的深入討論

下面是交換程式設計方法在smth上的討論對話，其中有人提出了相當好的討論觀點。
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
1
發信人: qingrun (青潤), 信區: SoftEng
標  題: 交換程式設計方法介紹
發信站: 水木社群 (Wed Aug 11 23:07:58 2010), 站內
圖片沒有單獨做出來，需要看圖片的可以看附件中的圖片。2007年在中國軟體質量年會上的關於交換程式設計的session的ppt在青潤上傳的資源中可以下載到。
交換程式設計的相關文章連線介紹：
[技術討論]交換程式設計實踐與延續：http://blog.csdn.net/qingrun/archive/2007/01/04/1473733.aspx
[技術討論]結對程式設計與交換程式設計的對話：http://blog.csdn.net/qingrun/archive/2006/12/07/1433588.aspx
交換程式設計csdn官方blog釋出了網路版本：http://blog.csdn.net/programmer_editor/archive/2006/12/07/1433092.aspx
[技術討論]關於結對程式設計實踐的一段對話：http://blog.csdn.net/qingrun/archive/2006/12/10/1437443.aspx
[團隊管理]結對程式設計引出的話題——企業管理與程式設計師規劃的對話（修改總結稿）：http://blog.csdn.net/qingrun/archive/2006/12/12/1440190.aspx
[技術討論]關於交換程式設計實踐的交換週期問題 ：http://blog.csdn.net/qingrun/archive/2006/12/20/1450091.aspx

※ 修改:•qingrun 於 Aug 13 09:48:35 2010 修改本文•[FROM: 119.6.72.3]
※ 來源:•水木社群 http://newsmth.net•[FROM: 119.6.72.6]
附件: 敏捷開發模型實踐之交換程式設計.rar (3001KB)
此主題相關圖片如下：各個階段的交換程式設計方法.JPG (30KB)

[本篇全文] [回覆文章] [本篇作者：timshaw] [回信給作者] [進入討論區] [返回頂部]
2
發信人: timshaw (去SofeEng(軟體工程)小侃吧), 信區: SoftEng
發信站: 水木社群 (Wed Aug 11 23:34:00 2010), 站內
看到0%嚇壞了，-_-b
【 在 qingrun (青潤) 的大作中提到: 】
: 圖片沒有單獨做出來，需要看圖片的可以看附件中的圖片。附件是2007年在中國軟體質量年會上的關於交換程式設計的session的ppt。
: 1    引言
: 在傳統的開發過程中，往往是一個人從一個模組的需求調研開始，然後作分析、設計、編碼、單元測試，接著才會交給第二個人（專職測試人員）進行其他測試專案。這樣的開發過程會因為開發人員的變動而對專案的進展產生較大的影響，所以就有人提出專案中編碼人員的重要性遠比
: ...................

※ 來源:•水木社群 newsmth.net•[FROM: 183.37.152.*]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
3
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Thu Aug 12 00:02:11 2010), 站內
0%？什麼地方？
【 在 timshaw (去SofeEng(軟體工程)小侃吧) 的大作中提到: 】
: 看到0%嚇壞了，-_-b

※ 來源:•水木社群 http://newsmth.net•[FROM: 119.6.72.6]
[本篇全文] [回覆文章] [本篇作者：piggestbaby] [回信給作者] [進入討論區] [返回頂部]
4
發信人: piggestbaby (吃的胖胖的(~~**~~)), 信區: SoftEng
發信站: 水木社群 (Thu Aug 12 10:01:49 2010), 站內
同嚇
【 在 timshaw (去SofeEng(軟體工程)小侃吧) 的大作中提到: 】
: 看到0%嚇壞了，-_-b

※ 來源:•水木社群 newsmth.net•[FROM: 119.253.176.*]
[本篇全文] [回覆文章] [本篇作者：piggestbaby] [回信給作者] [進入討論區] [返回頂部]
5
發信人: piggestbaby (吃的胖胖的(~~**~~)), 信區: SoftEng
發信站: 水木社群 (Thu Aug 12 10:17:05 2010), 站內
我從幾個方面來反對交換程式設計:
1. 專案的不同階段， 需要的技術是不同的， 程式設計師切換技術需要很長的準備，來回交接工作其溝通量非常不小， 程式碼質量難以保證
2. 需要對專案整體每一部分和流程都非常清楚, 只有極其優秀的員工能適應這種切換,不符合軟體工程大生產的螺絲釘思想， 也不能保有公司的技術和商業機密
3. 交換程式設計挫傷了程式設計師的隱私， 從根本上看, 它想讓專案中的任何人都是可替代的，但是程式設計師本身都是希望自己在某個方面有深入豐富的經驗， 並且憑之成為升值加薪的砝碼，從根本利益上是與員工的個人利益相違背的， 執行時必然導致員工積極性不高，並且互相推諉
當然結對程式設計則有浪費人力資源之嫌， 同時很難對結對的兩人能力進行評估，兩人水平如果一個高一個低，則成了師傅帶徒弟， 如果兩個低， 還不如不結對， 如果兩個都高， 那老闆肯定不幹了。
另 外我想說， 不要拿實驗的資料來推斷真實工作資料， 實驗資料大家都沒利益衝突， 玩了命想弄好一個專案，真實工作大家都是老油條，對自己沒有利益的事一分心思也不想付出。軟體工程重要的是人的因素， 如果一種管理方式如果不能保證促進員工的利益，那想的再好定的再完美， 沒人願意當包身工
【 在 qingrun (青潤) 的大作中提到: 】
: 圖片沒有單獨做出來，需要看圖片的可以看附件中的圖片。附件是2007年在中國軟體質量年會上的關於交換程式設計的session的ppt。
: 1    引言
: 在傳統的開發過程中，往往是一個人從一個模組的需求調研開始，然後作分析、設計、編碼、單元測試，接著才會交給第二個人（專職測試人員）進行其他測試專案。這樣的開發過程會因為開發人員的變動而對專案的進展產生較大的影響，所以就有人提出專案中編碼人員的重要性遠比
: ...................
※ 修改:•piggestbaby 於 Aug 12 10:28:24 2010 修改本文•[FROM: 119.253.176.*]
※ 來源:•水木社群 newsmth.net•[FROM: 119.253.176.*]
[本篇全文] [回覆文章] [本篇作者：kabbesy] [回信給作者] [進入討論區] [返回頂部]
6
發信人: kabbesy (三冠王), 信區: SoftEng
發信站: 水木社群 (Thu Aug 12 10:35:56 2010), 站內
贊
完全同意
堅決不支援把軟體工程走到資料化的極端
這個大幅度背離了以人為本的核心
【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: : 發信站: 水木社群 (Thu Aug 12 10:17:05 2010), 站內
:
: 我從幾個方面來反對交換程式設計:
: 1. 專案的不同階段， 需要的技術是不同的， 程式設計師切換技術需要很長的準備，來回交接工作其溝通量非常不小， 程式碼質量難以保證
: 2. 需要對專案整體每一部分和流程都非常清楚, 只有極其優秀的員工能適應這種切換,不符合軟體工程大生產的螺絲釘思想， 也不能保有公司的技術和商業機密
: 3. 交換程式設計挫傷了程式設計師的隱私， 從根本上看, 它想讓專案中的任何人都是可替代的，但是程式設計師本身都是希望自己在某個方面有深入豐富的經驗， 並且憑之成為升值加薪的砝碼，從根本利益上是與員工的個人利益相違背的， 執行時必然導致員工積極性不高，並且互相推諉
:
: 當然結對程式設計則有浪費人力資源之嫌， 同時很難對結對的兩人能力進行評估，兩人水平如果一個高一個低，則成了師傅帶徒弟， 如果兩個低， 還不如不結對， 如果兩個都高， 那老闆肯定不幹了。
:
: 另外我想說， 不要拿實驗的資料來推斷真實工作資料， 實驗資料大家都沒利益衝突， 玩了命想弄好一個專案，真實工作大家都是老油條，對自己沒有利益的事一分心思也不想付出。軟體工程重要的是人的因素， 如果一種管理方式如果不能保證促進員工的利益，那想的再好定的再完美， 沒人願意當包身工
:
: 【 在 qingrun (青潤) 的大作中提到: 】
: : 圖片沒有單獨做出來，需要看圖片的可以看附件中的圖片。附件是2007年在中國軟體質量年會上的關於交換程式設計的session的ppt。
: : 1    引言
: : 在傳統的開發過程中，往往是一個人從一個模組的需求調研開始，然後作分析、設計、編碼、單元測試，接著才會交給第二個人（專職測試人員）進行其他測試項 目。這樣的開發過程會因為開發人員的變動而對專案的進展產生較大的影響，所以就有人提出專案中編碼人員的重要性遠比
: : ...................
:
: ※ 修改:•piggestbaby 於 Aug 12 10:28:24 2010 修改本文•[FROM: 119.253.176.*]
: ※ 來源:•水木社群 newsmth.net•[FROM: 119.253.176.*]

※ 來源:•水木社群 newsmth.net•[FROM: 124.205.138.*]
[本篇全文] [回覆文章] [本篇作者：kabbesy] [回信給作者] [進入討論區] [返回頂部]
7
發信人: kabbesy (三冠王), 信區: SoftEng
發信站: 水木社群 (Thu Aug 12 10:36:46 2010), 站內
不過師傅帶徒弟是可以的
但是一定要保證好頻度
不能走極端
【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: 我從幾個方面來反對交換程式設計:
: 1. 專案的不同階段， 需要的技術是不同的， 程式設計師切換技術需要很長的準備，來回交接工作其溝通量非常不小， 程式碼質量難以保證
: 2. 需要對專案整體每一部分和流程都非常清楚, 只有極其優秀的員工能適應這種切換,不符合軟體工程大生產的螺絲釘思想， 也不能保有公司的技術和商業機密
: ...................

※ 來源:•水木社群 newsmth.net•[FROM: 124.205.138.*]
[本篇全文] [回覆文章] [本篇作者：kabbesy] [回信給作者] [進入討論區] [返回頂部]
8
發信人: kabbesy (三冠王), 信區: SoftEng
發信站: 水木社群 (Thu Aug 12 10:39:40 2010), 站內
交換程式設計只能適合高薪養廉，降低成本效費比，極端追求程式質量的場景
國內大部分企業是達不到的
我認為即使是google也不可能全盤使用
而thoughtworks這種諮詢導向的it公司就更不足為據了
（它根本不是以軟體生產率為目標，而是以各種新穎的軟體理論為目標）
【 在 qingrun (青潤) 的大作中提到: 】
: 圖片沒有單獨做出來，需要看圖片的可以看附件中的圖片。附件是2007年在中國軟體質量年會上的關於交換程式設計的session的ppt。
: 1    引言
: 在傳統的開發過程中，往往是一個人從一個模組的需求調研開始，然後作分析、設計、編碼、單元測試，接著才會交給第二個人（專職測試人員）進行其他測試專案。這樣的開發過程會因為開發人員的變動而對專案的進展產生較大的影響，所以就有人提出專案中編碼人員的重要性遠比
: ...................

※ 修改:•kabbesy 於 Aug 12 10:40:28 2010 修改本文•[FROM: 124.205.138.*]
※ 來源:•水木社群 newsmth.net•[FROM: 124.205.138.*]
[本篇全文] [回覆文章] [本篇作者：timshaw] [回信給作者] [進入討論區] [返回頂部]
9
發信人: timshaw (去SofeEng(軟體工程)小侃吧), 信區: SoftEng
發信站: 水木社群 (Thu Aug 12 12:23:14 2010), 站內
原來thoughtworks是諮尋為主啊？我以前還沒注意到。
【 在 kabbesy (三冠王) 的大作中提到: 】
: : 發信站: 水木社群 (Thu Aug 12 10:39:40 2010), 站內
:
: 交換程式設計只能適合高薪養廉，降低成本效費比，極端追求程式質量的場景
:
: 國內大部分企業是達不到的
: 我認為即使是google也不可能全盤使用
: 而thoughtworks這種諮詢導向的it公司就更不足為據了
: （它根本不是以軟體生產率為目標，而是以各種新穎的軟體理論為目標）
:
: 【 在 qingrun (青潤) 的大作中提到: 】
: : 圖片沒有單獨做出來，需要看圖片的可以看附件中的圖片。附件是2007年在中國軟體質量年會上的關於交換程式設計的session的ppt。
: : 1    引言
: : 在傳統的開發過程中，往往是一個人從一個模組的需求調研開始，然後作分析、設計、編碼、單元測試，接著才會交給第二個人（專職測試人員）進行其他測試項 目。這樣的開發過程會因為開發人員的變動而對專案的進展產生較大的影響，所以就有人提出專案中編碼人員的重要性遠比
: : ...................
:
: ※ 修改:•kabbesy 於 Aug 12 10:40:28 2010 修改本文•[FROM: 124.205.138.*]
: ※ 來源:•水木社群 newsmth.net•[FROM: 124.205.138.*]

※ 來源:•水木社群 newsmth.net•[FROM: 183.37.126.*]
[本篇全文] [回覆文章] [本篇作者：raynorli] [回信給作者] [進入討論區] [返回頂部]
10
發信人: raynorli (Rey), 信區: SoftEng
發信站: 水木社群 (Thu Aug 12 14:02:08 2010), 站內
我想在電子產品設計，例如原理圖，嵌入式開發，除錯過程中使用結對開發
1個工作者，1個輔助者，隨時切換
原因：
1，更好的質量，減少錯誤
2，遇到障礙時，可以防止單個人思維鑽牛角尖，導致精疲力盡也無法解決
3，因為工作者的勞動強度更大，經常切換可以降低結對內（心理上）的疲勞感
4，輔助者可以隨時構建文件，防止在設計完成後再補
5，關鍵技術掌握在2個人手裡，人員流動影響小
6，可以以師徒關係構建結對，同時完成對新人員的培訓

【 在 kabbesy (三冠王) 的大作中提到: 】
: 不過師傅帶徒弟是可以的
: 但是一定要保證好頻度
: 不能走極端
--
※ 來源:•水木社群 http://newsmth.net•[FROM: 114.249.209.*]
[本篇全文] [回覆文章] [本篇作者：oldwatch] [回信給作者] [進入討論區] [返回頂部]
11
發信人: oldwatch (一條叫java的魚◎谷歌將死，高牆早立), 信區: SoftEng
發信站: 水木社群 (Thu Aug 12 15:13:36 2010), 站內
en，這年頭以十八摸為代表
高檔民工都走諮詢路線
【 在 timshaw (去SofeEng(軟體工程)小侃吧) 的大作中提到: 】
: 原來thoughtworks是諮尋為主啊？我以前還沒注意到。

※ 來源:•水木社群 newsmth.net•[FROM: 116.228.66.*]
[本篇全文] [回覆文章] [本篇作者：canper] [回信給作者] [進入討論區] [返回頂部]
12
發信人: canper (洗衣粉), 信區: SoftEng
發信站: 水木社群 (Thu Aug 12 15:20:39 2010), 站內

什麼時候我能走這路線就好了
【 在 oldwatch (一條叫java的魚◎谷歌將死，高牆早立) 的大作中提到: 】
: en，這年頭以十八摸為代表
: 高檔民工都走諮詢路線

※ 來源:•水木社群 newsmth.net•[FROM: 113.65.155.*]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
13
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Thu Aug 12 18:24:31 2010), 站內

【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: 我從幾個方面來反對交換程式設計:
: 1. 專案的不同階段， 需要的技術是不同的， 程式設計師切換技術需要很長的準備，來回交接工作其溝通量非常不小， 程式碼質量難以保證
中國的程式設計師哪個不是從頭幹到尾的？幾乎每個人都必須或者被迫從頭做到尾。所以，你這個理由是不充分的。
: 2. 需要對專案整體每一部分和流程都非常清楚, 只有極其優秀的員工能適應這種切換,不符合軟體工程大生產的螺絲釘思想， 也不能保有公司的技術和商業機密
這個問題，貌似你根本沒有看完全文呀。另外這個問題和1的問題是相同的。至於商業機密的問題，呵呵，不要太擴大化了，這不是交換程式設計這類開發方法要關注的內容。
: 3. 交換程式設計挫傷了程式設計師的隱私， 從根本上看, 它想讓專案中的任何人都是可替代的，但是程式設計師本身都是希望自己在某個方面有深入豐富的經驗， 並且憑之成為升值加薪的砝碼，從根本利益上是與員工的個人利益相違背的， 執行時必然導致員工積極性不高，並且互相推諉
你錯了，這裡面沒有隱私問題，如果一個人的程式碼根本不能拿給別人來做開發，他的程式碼質量根本就是無法保證的，您的這個問題和2中的安全和保密問題是直接對立衝突的，我有點不知道您到底是為程式設計師考慮還是不為程式設計師考慮了。
: 當然結對程式設計則有浪費人力資源之嫌， 同時很難對結對的兩人能力進行評估，兩人水平如果一個高一個低，則成了師傅帶徒弟， 如果兩個低， 還不如不結對， 如果兩個都高， 那老闆肯定不幹了。
結對程式設計是很明顯的浪費，即使是師傅帶徒弟效果也不如我的交換程式設計更好更合適，授人以魚不如授至於魚，企業對員工的要求往往不是一個
: 另外我想說， 不要拿實驗的資料來推斷真實工作資料， 實驗資料大家都沒利益衝突，玩了命想弄好一個專案，真實工作大家都是老油條，對自己沒有利益的事一分心思也不想付出。軟體工程重要的是人的因素，如果一種 管理方式如果不能保證促進員工的利益，那想的再好定的再完美， 沒人願意當包身工
注意：我沒有那實驗資料來推斷實際工作資料，這一點更證明您沒有仔細看我的文字，您是帶著牴觸情緒來分析我的內容了。我文中很明確的說了，只有德國人的實驗採用了有經驗的開發人員，而其他的都不是如此！我的意思應該很明白了。
所以，我覺得您提出的這幾個問題都不是問題，或者批判物件搞錯了。

※ 來源:•水木社群 http://newsmth.net•[FROM: 119.6.72.8]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
14
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Thu Aug 12 18:26:38 2010), 站內

【 在 kabbesy (三冠王) 的大作中提到: 】
: 交換程式設計只能適合高薪養廉，降低成本效費比，極端追求程式質量的場景
: 國內大部分企業是達不到的
: 我認為即使是google也不可能全盤使用
: 而thoughtworks這種諮詢導向的it公司就更不足為據了
: （它根本不是以軟體生產率為目標，而是以各種新穎的軟體理論為目標）
您似乎把結對程式設計和我這個交換程式設計搞混了吧？
結對程式設計才是如此。

※ 來源:•水木社群 http://newsmth.net•[FROM: 119.6.72.8]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
15
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Thu Aug 12 18:27:29 2010), 站內
所以後來提到的其實是交換開發方式，這個方式就可以在很多行業進行實用，可以很好的獲得高質量和較高的效率。
【 在 raynorli (Rey) 的大作中提到: 】
: 我想在電子產品設計，例如原理圖，嵌入式開發，除錯過程中使用結對開發
: 1個工作者，1個輔助者，隨時切換
: 原因：
: ...................

※ 來源:•水木社群 http://newsmth.net•[FROM: 119.6.72.8]
[本篇全文] [回覆文章] [本篇作者：zhangmike] [回信給作者] [進入討論區] [返回頂部]
16
發信人: zhangmike (克強總~~~~~~~~~~~~~~理不是偶), 信區: SoftEng
發信站: 水木社群 (Fri Aug 13 09:41:17 2010), 站內
很難有一種新的方法就能適用所有的情況
結對程式設計、交換程式設計應當都有適用的地方。
結對程式設計近年來談的比較多。也有一些組織報導了。
交換程式設計還是新說法。具體操作層面不知是否有例項？
從時間上來說。一般是多久交換一次？

【 在 qingrun (青潤) 的大作中提到: 】
: 中國的程式設計師哪個不是從頭幹到尾的？幾乎每個人都必須或者被迫從頭做到尾。所以，你這個理由是不充分的。
: 這個問題，貌似你根本沒有看完全文呀。另外這個問題和1的問題是相同的。至於商業機密的問題，呵呵，不要太擴大化了，這不是交換程式設計這類開發方法要關注的內容。
: 你錯了，這裡面沒有隱私問題，如果一個人的程式碼根本不能拿給別人來做開發，他的程式碼質量根本就是無法保證的，您的這個問題和2中的安全和保密問題是直接對立衝突的，我有點不知道您到底是為程式設計師考慮還是不為程式設計師考慮了。
: ...................

※ 來源:•水木社群 newsmth.net•[FROM: 114.94.94.62]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
17
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Fri Aug 13 09:45:48 2010), 站內

【 在 zhangmike (克強總~~~~~~~~~~~~~~理不是偶) 的大作中提到: 】
: 很難有一種新的方法就能適用所有的情況
: 結對程式設計、交換程式設計應當都有適用的地方。
: 結對程式設計近年來談的比較多。也有一些組織報導了。
: 交換程式設計還是新說法。具體操作層面不知是否有例項？
這是我06年正式提出的，文中有介紹02-03年間就用過，此前我用過結對程式設計。
: 從時間上來說。一般是多久交換一次？
關於如何交換，文中有張圖，看附件，這裡不好文字配圖，所以，沒有嵌入圖片，圖片上寫的很清楚每個階段該做什麼操作，什麼時候做交換。
交換的兩種，亮亮交換和輪流交換，都在不同的階段使用，各有各的用處和好處。

※ 來源:•水木社群 http://newsmth.net•[FROM: 119.6.72.3]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
18
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Fri Aug 13 09:48:01 2010), 站內
上一張圖。
【 在 zhangmike (克強總~~~~~~~~~~~~~~理不是偶) 的大作中提到: 】
: 很難有一種新的方法就能適用所有的情況
: 結對程式設計、交換程式設計應當都有適用的地方。
: 結對程式設計近年來談的比較多。也有一些組織報導了。
: ...................

※ 來源:•水木社群 http://newsmth.net•[FROM: 119.6.72.3]

此主題相關圖片如下：各個階段的交換程式設計方法.JPG (30KB)

[本篇全文] [回覆文章] [本篇作者：zhangmike] [回信給作者] [進入討論區] [返回頂部]
19
發信人: zhangmike (克強總~~~~~~~~~~~~~~理不是偶), 信區: SoftEng
發信站: 水木社群 (Fri Aug 13 09:54:35 2010), 站內
thanks.
從圖中看，是在一個類似瀑布型的生命週期下，需求、設計分階段進行的。一般想來 諸
如需求階段的時間在1~3個月左右，那麼交換一次的時間就在15~30天左右？

【 在 qingrun (青潤) 的大作中提到: 】
: 上一張圖。

※ 來源:•水木社群 newsmth.net•[FROM: 114.94.94.62]
[本篇全文] [回覆文章] [本篇作者：kabbesy] [回信給作者] [進入討論區] [返回頂部]
20
發信人: kabbesy (三冠王), 信區: SoftEng
發信站: 水木社群 (Fri Aug 13 10:11:29 2010), 站內
以我的經驗——這個流程複雜了，而且缺少具體執行細節，不是個可推行的方案
如果能簡化成單線，最多一個分支，就好了
【 在 qingrun (青潤) 的大作中提到: 】
: : 發信站: 水木社群 (Fri Aug 13 09:48:01 2010), 站內
:
: 上一張圖。
: 【 在 zhangmike (克強總~~~~~~~~~~~~~~理不是偶) 的大作中提到: 】
: : 很難有一種新的方法就能適用所有的情況
: : 結對程式設計、交換程式設計應當都有適用的地方。
: : 結對程式設計近年來談的比較多。也有一些組織報導了。
: : ...................

※ 來源:•水木社群 newsmth.net•[FROM: 124.205.138.*]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
21
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Fri Aug 13 10:20:15 2010), 站內
這個圖只是建議在某個模型下的交換方式，不代表一定，你可以用任何的開發過程模型來匹配交換開發方式都可以，需要注意的就是到了編碼階段和測試階段一定選擇兩兩交換，此前採用輪流交換，這樣效果會比較好。
當然一切可以根據人員情況團隊情況調整。
【 在 zhangmike (克強總~~~~~~~~~~~~~~理不是偶) 的大作中提到: 】
: thanks.
: 從圖中看，是在一個類似瀑布型的生命週期下，需求、設計分階段進行的。一般想來 諸
: 如需求階段的時間在1~3個月左右，那麼交換一次的時間就在15~30天左右？

※ 來源:•水木社群 http://newsmth.net•[FROM: 119.6.72.3]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
22
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Fri Aug 13 10:22:57 2010), 站內
看來又被誤會了，呵呵。
這個是我一般建議的全程建模方法論下的交換程式設計的實踐方式，你用其他過程模型也可以採用，參考我前面那個帖子的內容。
不需要僵化的認定必需如何如何，關鍵是解決團隊的穩定性和可持續性的問題，降低人員變動風險。
另 外，我不是為了企業開除員工考慮，希望大家不要再把我推出的這個方法論變成了企業管理方面的js考慮，那不是我的本意。很多東西和方法論的推出都不是為了 某個目的，也可能被某個目的所利用。但是，這裡只能建議在正常的交接過程中，保持團隊穩定和開發穩定的情況下的方式。呵呵。
【 在 kabbesy (三冠王) 的大作中提到: 】
: 以我的經驗——這個流程複雜了，而且缺少具體執行細節，不是個可推行的方案
: 如果能簡化成單線，最多一個分支，就好了

※ 來源:•水木社群 http://newsmth.net•[FROM: 119.6.72.3]
[本篇全文] [回覆文章] [本篇作者：darkelf9] [回信給作者] [進入討論區] [返回頂部]
23
發信人: darkelf9 (整理屋子), 信區: SoftEng
發信站: 水木社群 (Sat Aug 14 16:52:29 2010), 站內
全程建模/交換程式設計最大的缺陷是什麼？
什麼場景最適合？
什麼樣的技術含量專案最適合？
相對於其他方式的最大優點是什麼？
感覺一種方法如果相對於其他方法真的有很大的優點
應該很容易推廣才是
不至於推廣了3年還沒有一個很明顯的成功案例

【 在 qingrun (青潤) 的大作中提到: 】
看來又被誤會了，呵呵。
這個是我一般建議的全程建模方法論下的交換程式設計的實踐方式，你用其他過程模型也可以採用，參考我前面那個帖子的內容。
不需要僵化的認定必需如何如何，關鍵是解決團隊的穩定性和可持續性的問題，降低人員變動風險。
另 外，我不是為了企業開除員工考慮，希望大家不要再把我推出的這個方法論變成了企業管理方面的js考慮，那不是我的本意。很多東西和方法論的推出都不是為了 某個目的，也可能被某個目的所利用。但是，這裡只能建議在正常的交接過程中，保持團隊穩定和開發穩定的情況下的方式。呵呵。
【 在 kabbesy (三冠王) 的大作中提到: 】
: 以我的經驗——這個流程複雜了，而且缺少具體執行細節，不是個可推行的方案
: 如果能簡化成單線，最多一個分支，就好了

※ 來源:•水木社群 newsmth.net•[FROM: 114.243.229.*]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
24
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Sat Aug 14 17:33:41 2010), 站內
首先，多謝關心。
【 在 darkelf9 (整理屋子) 的大作中提到: 】
: 全程建模/交換程式設計最大的缺陷是什麼？
注：全程建模和交換程式設計沒有直接關係，沒有必要一起提。
交換程式設計自身沒有大的缺陷，其不足之處在文中有足夠的描述了。
: 什麼場景最適合？
: 什麼樣的技術含量專案最適合？
: 相對於其他方式的最大優點是什麼？
這幾個問題，文中的表格已經說得很清楚了。
: 感覺一種方法如果相對於其他方法真的有很大的優點
: 應該很容易推廣才是
: 不至於推廣了3年還沒有一個很明顯的成功案例
這個問題，實話實說，就是我個人在推動，也沒有做什麼宣傳和特殊的推動形勢，我沒什麼名聲，影響力也不大，所以，推不動也是正常的。呵呵。
關於是否有優點，直接看我文中的內容，和對比表格，這個表格丟失了表格框所以比較亂，去看程式設計師2006年的那一期可能會好些，也可以看附件中的圖表。然後對比反思自己開發中經歷的東西，應該很容易對比理解出來。
至少國內有一些朋友的公司在使用這個開發方法了。

※ 來源:•水木社群 http://newsmth.net•[FROM: 119.6.119.10]
[本篇全文] [回覆文章] [本篇作者：darkelf9] [回信給作者] [進入討論區] [返回頂部]
25
發信人: darkelf9 (整理屋子), 信區: SoftEng
發信站: 水木社群 (Sun Aug 15 21:20:09 2010), 站內
看了一下表格，從我的開發經驗角度出發，對我所處的情況意義不大
文件中介紹的交換程式設計的核心優點是
1.減少離職風險
2.團隊穩定性
3.增加交流
逐個來看
離職風險確實是每個團隊都遇到的問題，但是離職的人也需要做分析，並不是所有人的
離職都會對團隊造成很大影響。團隊內普通人員離職在一般情況下不會造成什麼大的影
響，找個人來接手就是了。至於說因為一個普通人員離職造成某一個模組需要重新設計
，那唯一說明的是團隊技術負責人不稱職，首先要找一個好的技術負責人，而不是去試
驗各種管理方法。
真正有影響的我感覺有兩類人
a. 團隊核心，例如技術負責人，或者有一定技術門檻，學習門檻的核心技術掌握者，或
者複雜業務邏輯掌握者
b. 長期維護某一個老系統的人
交換程式設計對這兩類的意義都不大，對於型別a, 關鍵是要找對的人，有意識的做培養和b
ackup,同時給這些人足夠的待遇，溝通，重點放在留人上面。對於b,比較不好辦，老系
統往往用的技術比較古老，而型別b的人獨一無二的是長期處理這些老系統的經驗，這個
不是靠著簡單的交換程式設計能夠替代的。
交換程式設計對於那些普通開發者之間的“可替換性”效果感覺最好，可惜從實踐上看，這
類人的離職影響是最小的
我個人覺得對於離職問題，最重要的是團隊本身技術統一，保證所有人都有最基本的技
術共識，最基礎的培訓
其次就是保證關鍵人的穩定
關於團隊穩定性問題，說句實話和開發方式關係很小，以我的經驗，離職原因主要是待
遇，工作強度，是否受重視，領導能力，家庭影響（例如搬遷)，發展前途，公司前途等
等，我還沒有見過一個主要因為開發方式離職的。
增加交流 確實有一些幫助，只不過，對於團隊來說，採用scrum的每日會議或者是定期
的技術討論也可以達到類似的效果
而且交流受團隊氛圍，工作強度，團隊人員的構成很多因素影響，交換程式設計 的幫助有限

【 在 qingrun (青潤) 的大作中提到: 】
: 首先，多謝關心。
: 注：全程建模和交換程式設計沒有直接關係，沒有必要一起提。
: 交換程式設計自身沒有大的缺陷，其不足之處在文中有足夠的描述了。
: ...................
--
※ 來源:•水木社群 newsmth.net•[FROM: 114.243.229.*]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
26
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Sun Aug 15 21:54:51 2010), 站內
多謝這樣的評價和分析。這樣的分析和爭辯是有意義的。
【 在 darkelf9 (整理屋子) 的大作中提到: 】
: 看了一下表格，從我的開發經驗角度出發，對我所處的情況意義不大
: 文件中介紹的交換程式設計的核心優點是
: 1.減少離職風險
: 2.團隊穩定性
: 3.增加交流
: 逐個來看
: 離職風險確實是每個團隊都遇到的問題，但是離職的人也需要做分析，並不是所有人的
: 離職都會對團隊造成很大影響。團隊內普通人員離職在一般情況下不會造成什麼大的影
: 響，找個人來接手就是了。至於說因為一個普通人員離職造成某一個模組需要重新設計
: ，那唯一說明的是團隊技術負責人不稱職，首先要找一個好的技術負責人，而不是去試
: 驗各種管理方法。
這個情況您分析的不全面，有些系統設計是的確存在這樣的問題的，後面你也提到因為待遇或者某些情況的原因辭職，即使辭職走人，可能矛盾只是集中在某一個人身上而不是所有人的身上。
至少對比起來，交換程式設計在這方面要比單人程式設計有效得多。
如果是單人程式設計的方法，可能這個人做的需求到設計到編碼，無論哪個階段出現問題都會帶來風險，所以，你這個分析比較片面。
當然，一個方法的推出不可能適應所有的團隊，但是同比能得到一些較好的效果就足夠了，我沒打算像結對程式設計那樣被人吹噓的如何如何，而實際上除了很少的公司以外沒有哪個真得在應用。
: 真正有影響的我感覺有兩類人
: a. 團隊核心，例如技術負責人，或者有一定技術門檻，學習門檻的核心技術掌握者，或
: 者複雜業務邏輯掌握者
: b. 長期維護某一個老系統的人
: 交換程式設計對這兩類的意義都不大，對於型別a, 關鍵是要找對的人，有意識的做培養和b
: ackup,同時給這些人足夠的待遇，溝通，重點放在留人上面。對於b,比較不好辦，老系
: 統往往用的技術比較古老，而型別b的人獨一無二的是長期處理這些老系統的經驗，這個
: 不是靠著簡單的交換程式設計能夠替代的。
: 交換程式設計對於那些普通開發者之間的“可替換性”效果感覺最好，可惜從實踐上看，這
: 類人的離職影響是最小的
這個可真得不見得，每個人都是在成長中的，剛開始也許只是普通開發者，隨著時間的延長和工作任務的不斷安排，每個人的重要性都在不斷提升，對於企業而言，為 什麼會給一些老人較高的工資即使有可能他的能力還不如某個新人，也有這方面的一些原因存在。所以，您這個分析也比較片面，只是對於專案週期少於半年的可能 更符合您所說的這個情況，一般開發半年以上的人都會涉及到多個模組和多方面的關聯關係，不是簡簡單單的可以替換或者離職影響最小就能解釋的。
只要 離職就可能帶來風險，這個人所開發的模組和過去開發的系統的維護和後續開發的風險，在國內目前企業道德不規範，員工道德也比較混亂的狀態下，不可能不以最 壞的考慮來分析每一個人或者每一個公司，當然，具體的公司有具體的情況，有些人可能在某些公司覺得很舒服，但是，同樣的環境同樣的公司對於其他人來說就是 不舒服的，所以，一切都是可能存在衝突和風險發生的。
: 我個人覺得對於離職問題，最重要的是團隊本身技術統一，保證所有人都有最基本的技
: 術共識，最基礎的培訓
: 其次就是保證關鍵人的穩定
培訓真得不能保證人的穩定性。
: 關於團隊穩定性問題，說句實話和開發方式關係很小，以我的經驗，離職原因主要是待
: 遇，工作強度，是否受重視，領導能力，家庭影響（例如搬遷)，發展前途，公司前途等
: 等，我還沒有見過一個主要因為開發方式離職的。
: 增加交流 確實有一些幫助，只不過，對於團隊來說，採用scrum的每日會議或者是定期
: 的技術討論也可以達到類似的效果
您提到了scrum，注意，我對比的是單人程式設計方式，另外，每日會議和定期交流並不一定能提高團隊氛圍，這個我在不同的專案中參與和實踐過多次，有很多時候，這樣的方式還會引起一些技術人員的反感。
: 而且交流受團隊氛圍，工作強度，團隊人員的構成很多因素影響，交換程式設計 的幫助有限
另外，你所說的會議是另一個方法的內容，和交換程式設計應用的場景是不同的，所以，他們之間是相互補充，而不是相互衝突的，所以，你這個例子並不恰當，前面您也沒有舉出足夠有力的證據說服我。

※ 來源:•水木社群 http://newsmth.net•[FROM: 119.6.72.4]
[本篇全文] [回覆文章] [本篇作者：darkelf9] [回信給作者] [進入討論區] [返回頂部]
27
發信人: darkelf9 (整理屋子), 信區: SoftEng
發信站: 水木社群 (Mon Aug 16 23:01:09 2010), 站內
我感覺是不是我們的行業有一定差別？
我做過的行業包括網際網路行業和遊戲行業，沒有接觸過ERP行業
在我6、7年呆過的團隊，見過的團隊，帶過的團隊，見過兩位數以上的人員離職
對於那種單個非核心員工離職，真的沒有看到過非常大的影響
按照勞動法，員工離職要有1個月的交接時間，這個基本能保證一般員工所負責的工作交
接了
造成比較大影響的例子見過幾個
例子1：
部門原來的技術老大自己寫了一套底層，用這套底層搭建系統。後來這個老大離開了，
這個底層在使用中遇到了效能問題，沒有人能夠解決。最終是用一套開源系統代替了這
套底層。
這個案例用交換程式設計似乎沒什麼幫助，這套底層本身的技術含量很高（在當年環境下)，
實現相當的精巧，並不是隨便一個人就能交換的。而後面幾年中出現的效能問題，從以
後和這位老大的溝通看，是因為他當時沒有想到這套系統會遇到那麼大的規模，設計的
時候沒有考慮。
     最後用開源系統代替這個底層，原因也是因為這套底層落後了，有類似開源系統開
發人員的專注程度，社群的反饋、文件、熟悉的開發人員數目要遠遠強於自己公司一個
閉門造車的底層。如果技術方向出了問題，任何管理方法都沒有意義。
例子2：
網遊開發，接近內部測試，還有不少bug沒有解決，還有新功能要開發，開發團隊核心成
員全體跳巢。當時立馬從其他部門緊急調了2個能力強一點的，然後大批招聘，很多人都
是剛畢業的或者只有1、2年工作經驗的新手。雖然後續的開發、運維遇到了很多困難，
但是最終還是撐過去了。有一句老話說的好，地球離開誰都能轉，人員的離職當然會造
成影響，但是也沒有必要去誇大，特別是對於普通員工的離職

我回帖裡面 保證基礎的培訓的 目標 本質是不是保證員工的穩定性，而是提高在員工離
職的時候其他同事接手的速度

【 在 qingrun (青潤) 的大作中提到: 】
: 多謝這樣的評價和分析。這樣的分析和爭辯是有意義的。
: 這個情況您分析的不全面，有些系統設計是的確存在這樣的問題的，後面你也提到因為待遇或者某些情況的原因辭職，即使辭職走人，可能矛盾只是集中在某一個人身上而不是所有人的身上。
: 至少對比起來，交換程式設計在這方面要比單人程式設計有效得多。
: ...................
※ 來源:•水木社群 newsmth.net•[FROM: 114.243.229.*]
[本篇全文] [回覆文章] [本篇作者：darkelf9] [回信給作者] [進入討論區] [返回頂部]
28
發信人: darkelf9 (整理屋子), 信區: SoftEng
發信站: 水木社群 (Mon Aug 16 23:12:53 2010), 站內
另外，讀了一下交換程式設計的實際操作，感覺實踐中操作有一定難度
最直接的，這些人的績效如何評估？如果某一個模組出了問題，是設計的問題還是實現
的問題？
從開發實踐上看，我經歷的團隊不一定有超級高手，但是總會有層次性的人員梯隊
某一個模組大框架的設計至少要和技術頭或者小組長來溝通，
很多時候一個模組或者一個部分都是分給某個小組來做，具體實現可能不瞭解，但是大
體的設計小組內部都還比較清楚
很少存在某一個模組的設計完完全全一個人做，其他人一點都瞭解的情況
我感覺PPT裡面舉的例子事實上也有問題，沒有區分核心模組的設計和普通模組/簡單模
塊的設計
對於普通模組/簡單模組，即使完完全全都是一個人在弄，以後的切換成本也很低，交換
程式設計也許會帶來好處，但是意義並不大
而對於核心模組，一般情況下要麼是幾個老程式設計師一起討論，要麼是技術老大出手，似
乎交換程式設計對這種模組的設計和維護也沒有什麼意義

【 在 qingrun (青潤) 的大作中提到: 】
: 多謝這樣的評價和分析。這樣的分析和爭辯是有意義的。
: 這個情況您分析的不全面，有些系統設計是的確存在這樣的問題的，後面你也提到因為待遇或者某些情況的原因辭職，即使辭職走人，可能矛盾只是集中在某一個人身上而不是所有人的身上。
: 至少對比起來，交換程式設計在這方面要比單人程式設計有效得多。
: ...................
--
※ 來源:•水木社群 newsmth.net•[FROM: 114.243.229.*]
[本篇全文] [回覆文章] [本篇作者：piggestbaby] [回信給作者] [進入討論區] [返回頂部]
29
發信人: piggestbaby (吃的胖胖的(~~**~~)), 信區: SoftEng
發信站: 水木社群 (Mon Aug 16 23:39:00 2010), 站內
我的看法，好的軟體工程方法應該符合以下原則:
1. 有效配合傳統的管理方法， 而不是試圖取代或改變原有流程
   傳統的管理方法有上千年的經驗累積， 它的核心缺點軟體工程基本不能避免, 也並非只有軟體行業才會出現這些問題， 軟體工程只能起到輔助的作用， 不能與傳統管理基本原則相違背
2. 注重個人發展和權責分明，只有充分尊重員工， 給予員工長久發展的潛力，才能夠吸引人才， 團隊的發展就是個人的發展，要重視人的因素， 試圖以犧牲個人利益來維護集體利益是不可取的。
3. 注重長遠發展而不是短期突擊, 而極限程式設計往往注重於短期的效率而忽視長遠利益，如果長久突擊必然導致人心惶惶，效率低下。我覺得這也是大型企業很少採用極限程式設計的原因。

【 在 darkelf9 (整理屋子) 的大作中提到: 】
: 另外，讀了一下交換程式設計的實際操作，感覺實踐中操作有一定難度
: 最直接的，這些人的績效如何評估？如果某一個模組出了問題，是設計的問題還是實現
: 的問題？
: ...................
--
※ 來源:•水木社群 newsmth.net•[FROM: 123.113.40.*]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
30
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Tue Aug 17 07:34:53 2010), 站內
這個問題比較獨立，我先回答這個，今天中午的飛機，另一個話題就只能回到北京後再回復了。
關於績效管理的問題，我08年出了一個可度量績效模型，您可以去看看，我覺得，不僅針對新方法的績效，對於原來的績效評估也有比較好的效果，我那套方法雖然前期週期長，但是真正實施起來效果還是不錯的，至少比目前那些常規的績效方法對於軟體開發來說更適合或者更務實一些。
某 個模組的問題，這個應該是比較容易評估出來的，因為每一步都有評審的配合，如果是設計的問題，只需要驗證設計到程式碼是否沒有被變更過設計框架即可，我建議 的UML模型從設計匯出程式碼，如果是程式碼編寫人員擅自變更了程式碼框架，出了問題就是編碼人員的責任，如果不是這個原因，而且程式碼通過了單元測試，那麼問題 就肯定是設計的問題。這個應該市不難確定的。
【 在 darkelf9 (整理屋子) 的大作中提到: 】
: 另外，讀了一下交換程式設計的實際操作，感覺實踐中操作有一定難度
: 最直接的，這些人的績效如何評估？如果某一個模組出了問題，是設計的問題還是實現
: 的問題？
: ...................

※ 來源:•水木社群 http://newsmth.net•[FROM: 119.6.72.8]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
31
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Tue Aug 17 07:45:12 2010), 站內

【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: 我的看法，好的軟體工程方法應該符合以下原則:
: 1. 有效配合傳統的管理方法， 而不是試圖取代或改變原有流程
:    傳統的管理方法有上千年的經驗累積， 它的核心缺點軟體工程基本不能避免, 也
: 並非只有軟體行業才會出現這些問題， 軟體工程只能起到輔助的作用， 不能與傳統管
: 理基本原則相違背
這一條我認為不一定。
傳統管理方式上千年的積累，未必適合新的方法和新技術的發展，比如說，如果你按照漢朝軍隊的管理模式來管理宋朝，那明顯是不合適的。同樣，很多其他例子也是比較好找到的。
新技術必然帶來新的革命性的進步，每一步都是需要流血需要付出一定代價的，只要這一步代價付出之後真得起到了進步的作用，那就是值得的。
如果沒有一定的驗證性結果，是可以堅持原有的管理辦法，這個並沒有錯，畢竟人的意識和理解都是需要過程的，不是一個跨越式的，而大部分人應該是漸進式的。所以，在推動新方法的過程中，需要的是一種理解，相互的理解，相互的尊重，在這個基礎上探討討論爭論都是有意義的。
: 2. 注重個人發展和權責分明，只有充分尊重員工， 給予員工長久發展的潛力，才能
: 夠吸引人才， 團隊的發展就是個人的發展，要重視人的因素， 試圖以犧牲個人利益
: 來維護集體利益是不可取的。
這個我完全同意。
現在的問題是大部分企業不尊重員工，不考慮長遠發展，所以，很多時候是無奈的。
另外，交換程式設計的最大的目的是同一個模組可以有多人商議，這樣可以避免一個人從頭幹到尾，結果思路陷入某個牛角中而無法出來的境地，這種情況並不鮮見。
: 3. 注重長遠發展而不是短期突擊, 而極限程式設計往往注重於短期的效率而忽視長遠利
: 益，如果長久突擊必然導致人心惶惶，效率低下。我覺得這也是大型企業很少採用極
: 限程式設計的原因。
極限程式設計其實不是短期效率的提升，比如結對程式設計的前三個月適應期就不短了，國內很多專案甚至就是一個月兩個月的，甚至客戶要求一兩個星期的都有。
這 也是社會發展的必然，國內軟體業承接了國外90年代初期的起步點開始了自己的發展，每一步發展都被國外企業的商業利益所推動，往往被他們利用。而國內的老 板和客戶往往被國外幾個快速發展的企業的經歷所吸引，認為軟體業也是一個快速暴富的行業，很少有企業能夠靜下心來一步一步推動，意識上產生的問題其實是十 分嚴重的，只是大家往往忽略了這一層的現象對我們專案進展和開發過程產生的影響。
我覺得，這個分支繼續深入有點接近國家發展階段甚至資本積累階段的內容，就不適合這裡討論了。

※ 來源:•水木社群 http://newsmth.net•[FROM: 119.6.72.8]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
32
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Tue Aug 17 08:46:52 2010), 站內

【 在 darkelf9 (整理屋子) 的大作中提到: 】
: 我感覺是不是我們的行業有一定差別？
: 我做過的行業包括網際網路行業和遊戲行業，沒有接觸過ERP行業
: 在我6、7年呆過的團隊，見過的團隊，帶過的團隊，見過兩位數以上的人員離職
: 對於那種單個非核心員工離職，真的沒有看到過非常大的影響
應 該是有一些行業差異的，業務系統開發其中一點是對使用者業務的理解，如果對使用者業務不熟悉，哪怕你技術水平高，企業也很難接受你。這個和遊戲開發是不同的， 遊戲開發本身來說除了技術以外，沒有太多的業務層的差異，遊戲本身就是讓大家玩得，基本上來做軟體開發的人玩遊戲應該都不是需要什麼特殊學習的，應該說， 遊戲的業務邏輯上的實現會比較為複雜的行業業務邏輯要簡單一些。
: 按照勞動法，員工離職要有1個月的交接時間，這個基本能保證一般員工所負責的工
: 作交接了
而 且，如果是做遊戲開發的，基本上術語相差不大。我02年在上海的時候的弟兄，後來有四個人進入了巨人，一個是技術總監，一個是技術副總，這兩個哥們應該都 身價過億了。他們也都是從行業軟體開發過去的。至少我02年8月份離開上海的時候，其中三個都還在原來的公司，並沒有離開。
: 造成比較大影響的例子見過幾個
: 例子1：
: 部門原來的技術老大自己寫了一套底層，用這套底層搭建系統。後來這個老大離開
: 了，這個底層在使用中遇到了效能問題，沒有人能夠解決。最終是用一套開源系統代
: 替了這套底層。
: 這個案例用交換程式設計似乎沒什麼幫助，這套底層本身的技術含量很高（在當年環境
: 下)，實現相當的精巧，並不是隨便一個人就能交換的。而後面幾年中出現的效能問
: 題，從以後和這位老大的溝通看，是因為他當時沒有想到這套系統會遇到那麼大的規
: 模，設計的時候沒有考慮。
:      最後用開源系統代替這個底層，原因也是因為這套底層落後了，有類似開源系
: 統開發人員的專注程度，社群的反饋、文件、熟悉的開發人員數目要遠遠強於自己公
: 司一個閉門造車的底層。如果技術方向出了問題，任何管理方法都沒有意義。
恩， 這樣的情況在行業軟體開發中也出現過，一般來說涉及到一些較大的行業是不允許使用開源軟體的，但是，2004年我的確見過有著名的電信軟體公司在給電信某 些省份公司的系統中使用了電信從未允許也從未驗證過的mysql，tomcat等中介軟體和資料庫，也就是招標的人根本不懂，所以，就被糊弄過去了，說實 話，這些系統的上線讓我感到關係的強大和電信內部it技術人員和技術知識的匱乏。
: 例子2：
: 網遊開發，接近內部測試，還有不少bug沒有解決，還有新功能要開發，開發團隊核
: 心成員全體跳巢。當時立馬從其他部門緊急調了2個能力強一點的，然後大批招聘，
: 很多人都是剛畢業的或者只有1、2年工作經驗的新手。雖然後續的開發、運維遇到了
: 很多困難，但是最終還是撐過去了。有一句老話說的好，地球離開誰都能轉，人員的
: 離職當然會造成影響，但是也沒有必要去誇大，特別是對於普通員工的離職
這 個情況行業軟體中也遇到過，而且很常見。2003年我們開發的系統，一下子上線十多個省+集團公司，我們當時忍受只有13人，根本不夠，大量的bug和需 求的變更以及新需求的提出，我記得當時的集團公司的需求變更/新需求提出/bug管理的文件達到了500多頁，每頁平均至少兩個以上，也就是兩個多月的時 間。如果不是非典給我們爭取了3個多月的時間，5月份正式上線被推遲到了8月份，我們當時就死菜了。
: 我回帖裡面 保證基礎的培訓的 目標 本質是不是保證員工的穩定性，而是提高在員
: 工離職的時候其他同事接手的速度
恩，理解了。
其實交換程式設計的方式也可以在一定程度上提高接手速度，因為你必須做到你開發的程式碼和文件都能讓其他人看懂看明白，否則，評審和接手過程都會受到較大的影響。
至少在一定程度上比單人開發要好一些，當然，在接手的過程中必然會產生一定的時間延遲，不過，這樣的延遲卻可以提高內部對這個模組多方面的分析。
一個人如果要把自己的模組交給另一個人，一方面是要程式碼結構或者文件結構清晰，描述準確，另一方面接手的人的問題他也必須能夠解答，這樣的過程就能使得他不斷反思前面是否做得有問題或者是否可能出現一些問題。這樣的交流過程和方式肯定比單人開發要好得多，有效得多。

※ 來源:•水木社群 http://newsmth.net•[FROM: 119.6.72.8]
[本篇全文] [回覆文章] [本篇作者：piggestbaby] [回信給作者] [進入討論區] [返回頂部]
33
發信人: piggestbaby (吃的胖胖的(~~**~~)), 信區: SoftEng
發信站: 水木社群 (Tue Aug 17 10:44:25 2010), 站內
我覺得你的理解可能與你的行業真的有很大關係
交換程式設計從理解上來看， 怎樣的內容才是可交換的， 人和人是可替代的
要滿足以下條件:
   1. 工作技術含量不高， 技術類似
   2. 工作業務邏輯簡單
   3. 工作為同一模組的兩個小的子模組
   4. 工作協同子模組之間有清晰的介面設計

採 取傳統的分工方法, 是不是就不要求程式碼結構或者文件結構清晰了呢? 從設計的角度來說， 交換程式設計設計到如此詳細的 API， 就很難達到。設計一般僅保證模組之間大的介面， 對內部細粒度設計詳細的 API往往是畫蛇添足，這些工作應該是實現者的責任， 實現者應根據需求自由調整內部結構。所以要求交換時有足夠文件和清晰的結構， 既不符合極限程式設計， 也是無法滿足的.

從工作 內容劃分來看，交換程式設計兩人的工作明顯應該屬於完整的一塊，強要劃分給兩人完成，只能是工作量比較大  。交換程式設計帶來的溝通難度和工作量， 可以類比為一個人要去修正另一個人的 bug( 其實我們經常交換，呵呵 ),  交換的一方是否有責任去檢查另一方的程式碼實現題， 交接的一方接到程式碼後是去主動理解原有程式碼， 還是依葫蘆畫瓢狗尾續貂呢， 或者是對原有程式碼壓根不滿意自己另起爐灶呢， 交換時發生了問題怎麼辦,  最後整合出現了問題怎麼辦, 由於交換導致的專案拖延誰來負責任， 這可真是難題
交換程式設計和結對程式設計在本質上有所不同， 結對程式設計的兩人始終處於同一環境下， 同一思路， 實際上溝通量很小，溝通主要是由於技術交流引起的，屬於有效交流。 而交換程式設計， 溝通主要是工作切換引起的， 交流的目的很複雜， 有效性也值得懷疑

【 在 qingrun (青潤) 的大作中提到: 】
: 應該是有一些行業差異的，業務系統開發其中一點是對使用者業務的理解，如果對使用者業務不熟悉，哪怕你技術水平高，企業也很難接受你。這個和遊戲開發是不同的，遊戲開發本身來說除了技術以外，沒有太多的業務層的差異，遊戲本身就是讓大家玩得，基本上來做軟體開發的人玩遊
: 而且，如果是做遊戲開發的，基本上術語相差不大。我02年在上海的時候的弟兄，後來有四個人進入了巨人，一個是技術總監，一個是技術副總，這兩個哥們應該 都身價過億了。他們也都是從行業軟體開發過去的。至少我02年8月份離開上海的時候，其中三個都還在原來的公司，並沒

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