[軟體工程]交換程式設計方法的深入討論（續）
: 恩，這樣的情況在行業軟體開發中也出現過，一般來說涉及到一些較大的行業是不允許使用開源軟體的，但是，2004年我的確見過有著名的電信軟體公司在給電 信某些省份公司的系統中使用了電信從未允許也從未驗證過的mysql，tomcat等中介軟體和資料庫，也就是招標的人根本不懂，
: ...................
※ 來源:•水木社群 newsmth.net•[FROM: 119.253.176.*]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
34
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Tue Aug 17 22:08:27 2010), 站內
【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: 我覺得你的理解可能與你的行業真的有很大關係
: 交換程式設計從理解上來看， 怎樣的內容才是可交換的， 人和人是可替代的
: 要滿足以下條件:
: 1. 工作技術含量不高， 技術類似
: 2. 工作業務邏輯簡單
: 3. 工作為同一模組的兩個小的子模組
: 4. 工作協同子模組之間有清晰的介面設計
您的這幾條要求都是沒有必要設定的，實際上不需要如此設定，我當年實踐的專案業務邏輯是相當複雜的，而且是各個模組之間的開發進行交換，可能從工程設計模組到商務模組，也可能到財務模組，這些交換每一個都不是簡單的業務邏輯實現，每一個模組下面都可以劃分出很多子模組。。
: 採取傳統的分工方法, 是不是就不要求程式碼結構或者文件結構清晰了呢? 從設計的
: 角度來說， 交換程式設計設計到如此詳細的 API，就很難達到。設計一般僅保證模組之
: 間大的介面， 對內部細粒度設計詳細的 API往往是畫蛇添足，這些工作應該是實現
: 者的責任，實現者應根據需求自由調整內部結構。所以要求交換時有足夠文件和清晰
: 的結構， 既不符合極限程式設計， 也是無法滿足的.
那您的設計是做到什麼程度？類，模組？還是類內部的實現細節？
您有沒有看過歐美和日本外包的設計？
: 從工作內容劃分來看，交換程式設計兩人的工作明顯應該屬於完整的一塊，強要劃分給
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~這個完全沒有必要如此假設，這個假設也是不存在的。上面剛回答過。
: 兩人完成，只能是工作量比較大 。交換程式設計帶來的溝通難度和工作量，可以類比為
: 一個人要去修正另一個人的 bug( 其實我們經常交換，呵呵 ), 交換的一方是否有
: 責任去檢查另一方的程式碼實現題，交接的一方接到程式碼後是去主動理解原有程式碼，
: 還是依葫蘆畫瓢狗尾續貂呢， 或者是對原有程式碼壓根不滿意自己另起爐灶呢， 交
: 換時發生了問題怎麼辦, 最後整合出現了問題怎麼辦, 由於交換導致的專案拖延誰
: 來負責任， 這可真是難題
: 交換程式設計和結對程式設計在本質上有所不同， 結對程式設計的兩人始終處於同一環境下，
: 同一思路， 實際上溝通量很小，溝通主要是由於技術交流引起的，屬於有效交流。
: 而交換程式設計， 溝通主要是工作切換引起的， 交流的目的很複雜， 有效性也值得懷
: 疑
您這個也是假設性的，不妨實踐一下在看看您這個評論是否合適。結對程式設計的溝通量並不小，而且也不是單一因為技術交流引起的，業務上也會引起交流，我實踐的時候就是這樣的感受。交換程式設計也是如此，為何交換程式設計的有效性就值得懷疑？
您的這段評論完全是猜測方式的評論，並沒有有效性的評論內容，我不知道您是否實踐過結對程式設計，因為交換程式設計您肯定沒有實踐過。
※ 修改:•qingrun 於 Aug 17 22:59:59 2010 修改本文•[FROM: 162.105.200.220]
※ 來源:•水木社群 http://newsmth.net•[FROM: 162.105.200.220]
[本篇全文] [回覆文章] [本篇作者：piggestbaby] [回信給作者] [進入討論區] [返回頂部]
35
發信人: piggestbaby (吃的胖胖的(~~**~~)), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 07:48:57 2010), 站內
我這恐怕是天天都在交換程式設計
因為專案很多，彼此之間相關，隨時來一個任務都可能派發到隨機的一人身上
正是這種經驗引起我對這種方式的反感
老闆的意思不僅僅是保證團隊穩定性， 還有保證每個人都任務很充足
總之目的很複雜， 開發人員機械完成， 誰也不負責任
交換程式設計試圖解決的問題，我想在傳統的管理方式中， 人才梯隊， 培訓等等能很好的解決
試圖用交換來解決這些問題， 有點吃力不討好
也許交換不交換並不重要， 也許交換的速度快了， 僅僅是兩個人配合比較流暢
也許心情高興了， 自然速度就會加快
我想並不用把交換程式設計和結對程式設計想像的如此神祕
我們每天都在和別人配合進行工作， 兩人同時討論一個問題， 一起去解決或實現一個問題
這 種經驗很普遍。 另外不要假定實現人員就不需要自己獨立設計， 實現的難度也很難大也有自由發揮性， 如果能詳細設計到你所說程度， 保留設計人員就足夠了， 交換不交換都很穩定。 結對程式設計是兩人同時完成任務，一起討論設計，一起定下實現方案，一起實現， 兩人是同一思路。 而交換程式設計是 自己設計， 自己定下實現方案， 自己實現一部分， 對方拿到程式碼， 對方觀察設計， 對方思考是否合理， 對方考慮繼續實現。 兩種方式的溝通是有本質區別的。
【 在 qingrun (青潤) 的大作中提到: 】
: 您的這幾條要求都是沒有必要設定的，實際上不需要如此設定，我當年實踐的專案業務邏輯是相當複雜的，而且是各個模組之間的開發進行交換，可能從工程設計模組到商務模組，也可能到財務模組，這些交換每一個都不是簡單的業務邏輯實現，每一個模組下面都可以劃分出很多子模
: 那您的設計是做到什麼程度？類，模組？還是類內部的實現細節？
: 您有沒有看過歐美和日本外包的設計？
: ...................
--
※ 修改:•piggestbaby 於 Aug 18 07:59:09 2010 修改本文•[FROM: 123.113.37.*]
※ 來源:•水木社群 newsmth.net•[FROM: 123.113.37.*]
[本篇全文] [回覆文章] [本篇作者：kabbesy] [回信給作者] [進入討論區] [返回頂部]
36
發信人: kabbesy (三冠王), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 08:21:22 2010), 站內
我始終認為結對比交換靠譜
而且結對也得限制頻度
【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: : 發信站: 水木社群 (Wed Aug 18 07:48:57 2010), 站內
:
: 我這恐怕是天天都在交換程式設計
: 因為專案很多，彼此之間相關，隨時來一個任務都可能派發到隨機的一人身上
: 正是這種經驗引起我對這種方式的反感
: 老闆的意思不僅僅是保證團隊穩定性， 還有保證每個人都任務很充足
: 總之目的很複雜， 開發人員機械完成， 誰也不負責任
: 交換程式設計試圖解決的問題，我想在傳統的管理方式中， 人才梯隊， 培訓等等能很好的解決
: 試圖用交換來解決這些問題， 有點吃力不討好
: 也許交換不交換並不重要， 也許交換的速度快了， 僅僅是兩個人配合比較流暢
: 也許心情高興了， 自然速度就會加快
: 我想並不用把交換程式設計和結對程式設計想像的如此神祕
: 我們每天都在和別人配合進行工作， 兩人同時討論一個問題， 一起去解決或實現一個問題
: 這種經驗很普遍。 另外不要假定實現人員就不需要自己獨立設計， 實現的難度也很難大也有自由發揮性， 如果能詳細設計到你所說程度， 保留設計人員就足夠了， 交換不交換都很穩定。 結對程式設計是兩人同時完成任務，一起討論設計，一起定下實現方案，一起實現， 兩人是同一思路。 而交換程式設計是 自己設計， 自己定下實現方案， 自己實現一部分， 對方拿到程式碼， 對方觀察設計， 對方思考是否合理， 對方考慮繼續實現。 兩種方式的溝通是有本質區別的。
:
: 【 在 qingrun (青潤) 的大作中提到: 】
: : 您的這幾條要求都是沒有必要設定的，實際上不需要如此設定，我當年實踐的專案業務邏輯是相當複雜的，而且是各個模組之間的開發進行交換，可能從工程設計模 塊到商務模組，也可能到財務模組，這些交換每一個都不是簡單的業務邏輯實現，每一個模組下面都可以劃分出很多子模
: : 那您的設計是做到什麼程度？類，模組？還是類內部的實現細節？
: : 您有沒有看過歐美和日本外包的設計？
: : ...................
:
: ※ 修改:•piggestbaby 於 Aug 18 07:59:09 2010 修改本文•[FROM: 123.113.37.*]
: ※ 來源:•水木社群 newsmth.net•[FROM: 123.113.37.*]
※ 來源:•水木社群 newsmth.net•[FROM: 124.205.138.*]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
37
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 16:08:53 2010), 站內
天天都在交換程式設計？
您能講講你們是怎麼交換的麼？你們目前的交換是怎麼產生的？當時為什麼要交換麼？
一般來說，無目的和有目的的操作效果上必然是有差異的，所以，我想了解一下你們的情況，然後再做更多地分析評論。
【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: 我這恐怕是天天都在交換程式設計
: 因為專案很多，彼此之間相關，隨時來一個任務都可能派發到隨機的一人身上
: 正是這種經驗引起我對這種方式的反感
: 老闆的意思不僅僅是保證團隊穩定性， 還有保證每個人都任務很充足
: 總之目的很複雜， 開發人員機械完成， 誰也不負責任
: 交換程式設計試圖解決的問題，我想在傳統的管理方式中， 人才梯隊， 培訓等等能很
: 好的解決
: 試圖用交換來解決這些問題， 有點吃力不討好
: 也許交換不交換並不重要， 也許交換的速度快了， 僅僅是兩個人配合比較流暢
~~~~~~~~~~~~~~~這個是結對還是交換？我怎麼看不明白了？交換不僅僅是兩個人的事情。
: 也許心情高興了， 自然速度就會加快
: 我想並不用把交換程式設計和結對程式設計想像的如此神祕
這句話我非常同意，本來就不是什麼非常神祕的事情，但是，操作上還是有差異的。
最簡單的比如說會議，都是會議，有些就是有效的，有些就是無效的，而且大量的浪費時間拖沓冗長。所以，必須瞭解清楚你們到底是如何操作的，我才能分析分析，哪怕我是錯的，至少讓我看到我錯誤的原因所在。
: 我們每天都在和別人配合進行工作， 兩人同時討論一個問題， 一起去解決或實現
: 一個問題
: 這種經驗很普遍。 另外不要假定實現人員就不需要自己獨立設計， 實現的難度也
: 很難大也有自由發揮性， 如果能詳細設計到你所說程度，保留設計人員就足夠了，
: 交換不交換都很穩定。 結對程式設計是兩人同時完成任務，一起討論設計，一起定下實
: 現方案，一起實現， 兩人是同一思路。而交換程式設計是 自己設計， 自己定下實現方
: 案， 自己實現一部分， 對方拿到程式碼， 對方觀察設計， 對方思考是否合理， 對
: 方考慮繼續實現。兩種方式的溝通是有本質區別的。
※ 來源:•水木社群 http://newsmth.net•[FROM: 162.105.200.28]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
38
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 16:25:10 2010), 站內
這個，呵呵。
【 在 kabbesy (三冠王) 的大作中提到: 】
: 我始終認為結對比交換靠譜
: 而且結對也得限制頻度
※ 來源:•水木社群 http://newsmth.net•[FROM: 162.105.200.28]
[本篇全文] [回覆文章] [本篇作者：kabbesy] [回信給作者] [進入討論區] [返回頂部]
39
發信人: kabbesy (三冠王), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 16:28:49 2010), 站內
哈哈
不是拍磚，勿怪勿怪
【 在 qingrun (青潤) 的大作中提到: 】
: 這個，呵呵。
※ 來源:•水木社群 newsmth.net•[FROM: 124.205.138.*]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
40
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 16:38:55 2010), 站內
呵呵，沒事，其實每個人都有看法才是對的，可以不同意，但是不能不讓別人發表意見。
來這裡的，如果還是糊糊塗塗模稜兩可的，那就沒意思了。
創造一個東西不容易，新的東西，大家反對的意見肯定比較多，通過反對的意見也可以收集到更多更好的正面的反饋資訊，也有助於大家判斷一個事物是否真得有用，我還是覺得，有可能的話不妨嘗試一下再下結論。
【 在 kabbesy (三冠王) 的大作中提到: 】
: 哈哈
: 不是拍磚，勿怪勿怪
※ 來源:•水木社群 http://newsmth.net•[FROM: 162.105.200.28]
[本篇全文] [回覆文章] [本篇作者：kabbesy] [回信給作者] [進入討論區] [返回頂部]
41
發信人: kabbesy (三冠王), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 16:52:36 2010), 站內
我的經歷中，team成員如果狀態從1到5的話
1-3，都得靠leader的手腕去帶領
到達4，得靠專案的成績、錢、未來發展
到達5，再開始做結對這種事情
民企流
出活是第1位的，團隊狀態是第1.1位的，程式碼質量是第1.5位的
結對這些優先順序真的太靠後了……
【 在 qingrun (青潤) 的大作中提到: 】
: : 發信站: 水木社群 (Wed Aug 18 16:38:55 2010), 站內
:
: 呵呵，沒事，其實每個人都有看法才是對的，可以不同意，但是不能不讓別人發表意見。
: 來這裡的，如果還是糊糊塗塗模稜兩可的，那就沒意思了。
: 創造一個東西不容易，新的東西，大家反對的意見肯定比較多，通過反對的意見也可以收集到更多更好的正面的反饋資訊，也有助於大家判斷一個事物是否真得有用，我還是覺得，有可能的話不妨嘗試一下再下結論。
:
: 【 在 kabbesy (三冠王) 的大作中提到: 】
: : 哈哈
: : 不是拍磚，勿怪勿怪
:
: ※ 來源:•水木社群 http://newsmth.net•[FROM: 162.105.200.28]
※ 來源:•水木社群 newsmth.net•[FROM: 124.205.138.*]
[本篇全文] [回覆文章] [本篇作者：piggestbaby] [回信給作者] [進入討論區] [返回頂部]
42
發信人: piggestbaby (吃的胖胖的(~~**~~)), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 17:02:45 2010), 站內
我 們有很多專案， 專案之間採用的技術是差不多的。 有新專案，有老專案維護， 有實驗性質的， 任務也是很飽滿的， 經常會出現一個人頭上好幾個任務的情況， 於是就出現了優先順序， 優先順序高的任務來了， 迅速切換到優先順序高的任務。 由於任務優先順序和工作量不等， 完成時間參差不齊， 於是又經常出現這個人的內容， 下一階段又切換到另外一個人那裡去的事情, 誰做完了一塊內容閒下來， 又會隨機領到不知道什麼階段的任務。
交換的原因其實就是前面提到的， 避免某項技術被個人壟斷， 讓大家任務都很飽滿。
【 在 qingrun (青潤) 的大作中提到: 】
: 天天都在交換程式設計？
: 您能講講你們是怎麼交換的麼？你們目前的交換是怎麼產生的？當時為什麼要交換麼？
: 一般來說，無目的和有目的的操作效果上必然是有差異的，所以，我想了解一下你們的情況，然後再做更多地分析評論。
: ...................
--
※ 來源:•水木社群 newsmth.net•[FROM: 119.253.176.*]
[本篇全文] [回覆文章] [本篇作者：kabbesy] [回信給作者] [進入討論區] [返回頂部]
43
發信人: kabbesy (三冠王), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 17:08:37 2010), 站內
平均薪資多少？
雖然絕對不支援
但我絕對佩服能把程式設計師當工人使的公司
【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: : 發信站: 水木社群 (Wed Aug 18 17:02:45 2010), 站內
:
: 我們有很多專案， 專案之間採用的技術是差不多的。 有新專案，有老專案維護， 有實驗性質的， 任務也是很飽滿的， 經常會出現一個人頭上好幾個任務的情況， 於是就出現了優先順序， 優先順序高的任務來了， 迅速切換到優先順序高的任務。 由於任務優先順序和工作量不等， 完成時間參差不齊， 於是又經常出現這個人的內容， 下一階段又切換到另外一個人那裡去的事情, 誰做完了一塊內容閒下來， 又會隨機領到不知道什麼階段的任務。
: 交換的原因其實就是前面提到的， 避免某項技術被個人壟斷， 讓大家任務都很飽滿。
:
: 【 在 qingrun (青潤) 的大作中提到: 】
: : 天天都在交換程式設計？
: : 您能講講你們是怎麼交換的麼？你們目前的交換是怎麼產生的？當時為什麼要交換麼？
: : 一般來說，無目的和有目的的操作效果上必然是有差異的，所以，我想了解一下你們的情況，然後再做更多地分析評論。
: : ...................
:
: --
:
: ※ 來源:•水木社群 newsmth.net•[FROM: 119.253.176.*]
※ 來源:•水木社群 newsmth.net•[FROM: 124.205.138.*]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
44
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 17:12:05 2010), 站內
【 在 kabbesy (三冠王) 的大作中提到: 】
: 我的經歷中，team成員如果狀態從1到5的話
: 1-3，都得靠leader的手腕去帶領
: 到達4，得靠專案的成績、錢、未來發展
其實4、5和1-3沒什麼差別。接近10人或者以上差別就大了。
: 到達5，再開始做結對這種事情
~~~5個人作結對，我覺得人數也太少了。一個專案經理+2個結對組？說實話，總感覺很可笑。呵呵。
: 民企流
: 出活是第1位的，團隊狀態是第1.1位的，程式碼質量是第1.5位的
: 結對這些優先順序真的太靠後了……
~~~~肯定靠後。
也 就是因為對結對的實踐，加上那時候經歷的企業對員工都不夠好，員工跳槽基本上是1年左右就比較多了，我留人雖然還可以，但是，不能讓弟兄們總為了大家相處 得面子和感情留下來，畢竟都要生活。加上當時我們這批人（分別是成都和上海兩批，只有我和這兩批人都合作過）進入電信設計院後，組內還有兩個原來設計院作 開發的弟兄，從陌生到熟悉到配合，於是，產生了交換方式的嘗試。
※ 來源:•水木社群 http://newsmth.net•[FROM: 162.105.200.28]
[本篇全文] [回覆文章] [本篇作者：piggestbaby] [回信給作者] [進入討論區] [返回頂部]
45
發信人: piggestbaby (吃的胖胖的(~~**~~)), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 17:12:16 2010), 站內
呵呵，中低水平
只要你不追求軟體質量
不追求長遠發展
騙到一個是一個
啥事都能做地
不過說實話，我們工作混日子還是滿輕鬆的
壓根沒法考核， 各種理由， 各種推卸責任
堆的多了，慢慢做就是
【 在 kabbesy (三冠王) 的大作中提到: 】
: 平均薪資多少？
: 雖然絕對不支援
: 但我絕對佩服能把程式設計師當工人使的公司
: ...................
--
※ 修改:•piggestbaby 於 Aug 18 17:15:26 2010 修改本文•[FROM: 119.253.176.*]
※ 來源:•水木社群 newsmth.net•[FROM: 119.253.176.*]
[本篇全文] [回覆文章] [本篇作者：kabbesy] [回信給作者] [進入討論區] [返回頂部]
46
發信人: kabbesy (三冠王), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 17:15:32 2010), 站內
ft.........
【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: 呵呵，中低水平
: 只要你不追求軟體質量
: 不追求長遠發展
: ...................
※ 來源:•水木社群 newsmth.net•[FROM: 124.205.138.*]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
47
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 17:15:39 2010), 站內
哦。這個原因的交換。
如果是這樣，我覺得，你們的交換目的不純，不是為了團隊的融合，而是為了真得就是前面提到的把人當機器使用。
另外，交換的方式上，你們是任務交換，並沒有形成模式，一定的模式是有必要的，也可能和這個有關係，你們的這個交換就類似於很多開發團隊開會，開到大家頭暈腦脹，效果還不好，老闆看著每個人都忙。
我的團隊開會，評審會一般30分鐘左右肯定結束，一般的會議10分鐘結束，然後就是各自分組的討論和交流，沒有必要大家都聚集起來為某一兩個人的事情而浪費時間。
所以，不同的人不同的團隊即使做同樣的事情，也一樣會帶來不同的效果，其原因應該就在這裡。
【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: 我們有很多專案， 專案之間採用的技術是差不多的。 有新專案，有老專案維護， 有實驗性質的， 任務也是很飽滿的， 經常會出現一個人頭上好幾個任務的情況， 於是就出現了優先順序， 優先順序高的任務來了， 迅速切換到優先順序高的任務。 由於任務優先順序和工作量不等， 完成時間參差不齊， 於是又經常出現這個人的內容， 下一階段又切換到另外一個人那裡去的事情, 誰做完了一塊內容閒下來， 又會隨機領到不知道什麼階段的任務。
: 交換的原因其實就是前面提到的， 避免某項技術被個人壟斷， 讓大家任務都很飽滿。
※ 來源:•水木社群 http://newsmth.net•[FROM: 162.105.200.28]
[本篇全文] [回覆文章] [本篇作者：kabbesy] [回信給作者] [進入討論區] [返回頂部]
48
發信人: kabbesy (三冠王), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 17:15:50 2010), 站內
汗死
不好意思，我說的是狀態從1分到5分，不是人數……
【 在 qingrun (青潤) 的大作中提到: 】
: : 發信站: 水木社群 (Wed Aug 18 17:12:05 2010), 站內
:
:
: 【 在 kabbesy (三冠王) 的大作中提到: 】
: : 我的經歷中，team成員如果狀態從1到5的話
: : 1-3，都得靠leader的手腕去帶領
: : 到達4，得靠專案的成績、錢、未來發展
: 其實4、5和1-3沒什麼差別。接近10人或者以上差別就大了。
: : 到達5，再開始做結對這種事情
: ~~~5個人作結對，我覺得人數也太少了。一個專案經理+2個結對組？說實話，總感覺很可笑。呵呵。
:
: : 民企流
: : 出活是第1位的，團隊狀態是第1.1位的，程式碼質量是第1.5位的
: : 結對這些優先順序真的太靠後了……
: ~~~~肯定靠後。
: 也就是因為對結對的實踐，加上那時候經歷的企業對員工都不夠好，員工跳槽基本上是1年左右就比較多了，我留人雖然還可以，但是，不能讓弟兄們總為了大家相 處得面子和感情留下來，畢竟都要生活。加上當時我們這批人（分別是成都和上海兩批，只有我和這兩批人都合作過）進入電信設計院後，組內還有兩個原來設計院 作開發的弟兄，從陌生到熟悉到配合，於是，產生了交換方式的嘗試。
:
: ※ 來源:•水木社群 http://newsmth.net•[FROM: 162.105.200.28]
※ 來源:•水木社群 newsmth.net•[FROM: 124.205.138.*]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
49
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 17:17:23 2010), 站內
呵呵，不好意思，應該是我，我看走眼了。
【 在 kabbesy (三冠王) 的大作中提到: 】
: 汗死
: 不好意思，我說的是狀態從1分到5分，不是人數……
※ 來源:•水木社群 http://newsmth.net•[FROM: 162.105.200.28]
[本篇全文] [回覆文章] [本篇作者：kabbesy] [回信給作者] [進入討論區] [返回頂部]
50
發信人: kabbesy (三冠王), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 17:19:34 2010), 站內
很支援中間對會議時間的控制
【 在 qingrun (青潤) 的大作中提到: 】
: : 發信站: 水木社群 (Wed Aug 18 17:15:39 2010), 站內
:
: 哦。這個原因的交換。
: 如果是這樣，我覺得，你們的交換目的不純，不是為了團隊的融合，而是為了真得就是前面提到的把人當機器使用。
: 另外，交換的方式上，你們是任務交換，並沒有形成模式，一定的模式是有必要的，也可能和這個有關係，你們的這個交換就類似於很多開發團隊開會，開到大家頭暈腦脹，效果還不好，老闆看著每個人都忙。
: 我的團隊開會，評審會一般30分鐘左右肯定結束，一般的會議10分鐘結束，然後就是各自分組的討論和交流，沒有必要大家都聚集起來為某一兩個人的事情而浪費時間。
: 所以，不同的人不同的團隊即使做同樣的事情，也一樣會帶來不同的效果，其原因應該就在這裡。
: 【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: : 我們有很多專案， 專案之間採用的技術是差不多的。 有新專案，有老專案維護， 有實驗性質的， 任務也是很飽滿的， 經常會出現一個人頭上好幾個任務的情況， 於是就出現了優先順序， 優先順序高的任務來了， 迅速切換到優先順序高的任務。 由於任務優先順序和工作量不等， 完成時間參差不齊， 於是又經常出現這個人的內容， 下一階段又切換到另外一個人那裡去的事情, 誰做完了一塊內容閒下來， 又會隨機領到不知道什麼階段的任務。
: : 交換的原因其實就是前面提到的， 避免某項技術被個人壟斷， 讓大家任務都很飽滿。
:
: ※ 來源:•水木社群 http://newsmth.net•[FROM: 162.105.200.28]
※ 來源:•水木社群 newsmth.net•[FROM: 124.205.138.*]
[本篇全文] [回覆文章] [本篇作者：piggestbaby] [回信給作者] [進入討論區] [返回頂部]
51
發信人: piggestbaby (吃的胖胖的(~~**~~)), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 17:26:51 2010), 站內
所以了， 我說軟體工程不重要
核心其實在管理方式上才是重要的
當然頻繁的交換引起的負面影響是不容忽視的
頻繁交換容易引起成員的心理情緒不穩定
個人成就感喪失
個人責任和利益之間不平衡
對團隊和公司的產生負面看法等
事實上我們現在工作基本不加班
但是我就覺得很累
啥也不幹都累
【 在 qingrun (青潤) 的大作中提到: 】
: 哦。這個原因的交換。
: 如果是這樣，我覺得，你們的交換目的不純，不是為了團隊的融合，而是為了真得就是前面提到的把人當機器使用。
: 另外，交換的方式上，你們是任務交換，並沒有形成模式，一定的模式是有必要的，也可能和這個有關係，你們的這個交換就類似於很多開發團隊開會，開到大家頭暈腦脹，效果還不好，老闆看著每個人都忙。
: ...................
--
※ 來源:•水木社群 newsmth.net•[FROM: 119.253.176.*]
[本篇全文] [回覆文章] [本篇作者：kabbesy] [回信給作者] [進入討論區] [返回頂部]
52
發信人: kabbesy (三冠王), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 17:29:39 2010), 站內
【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: : 發信站: 水木社群 (Wed Aug 18 17:26:51 2010), 站內
:
: 所以了， 我說軟體工程不重要
這個不能re
重要是重要的，但也有優先順序
: 核心其實在管理方式上才是重要的
這個必須sp
: 當然頻繁的交換引起的負面影響是不容忽視的
: 頻繁交換容易引起成員的心理情緒不穩定
: 個人成就感喪失
: 個人責任和利益之間不平衡
其實工作很簡單，責任和權利，平衡就行
加上好的氛圍那就錦上添花了
: 對團隊和公司的產生負面看法等
: 事實上我們現在工作基本不加班
: 但是我就覺得很累
: 啥也不幹都累
哈哈，re
:
: 【 在 qingrun (青潤) 的大作中提到: 】
: : 哦。這個原因的交換。
: : 如果是這樣，我覺得，你們的交換目的不純，不是為了團隊的融合，而是為了真得就是前面提到的把人當機器使用。
: : 另外，交換的方式上，你們是任務交換，並沒有形成模式，一定的模式是有必要的，也可能和這個有關係，你們的這個交換就類似於很多開發團隊開會，開到大家頭暈腦脹，效果還不好，老闆看著每個人都忙。
: : ...................
:
※ 來源:•水木社群 newsmth.net•[FROM: 124.205.138.*]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
53
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 17:33:44 2010), 站內
【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: 所以了， 我說軟體工程不重要
: 核心其實在管理方式上才是重要的
~~~~~~~~這其實是我定義的軟體開發方法論的內容，方法論不只是交換，結對，螺旋、迭代的概念名詞，裡面要包含具體的操作方式，如何是正確的操 作，什麼樣是錯誤的行為，這些都很重要，也有人很好的專案經理管理不好專案的情況，這並不鮮見，就是因為方法的掌握不對。
比如，top當年丟掉南京地稅後續3000多萬合同的專案，就是方法錯誤，主要管理者過於教條的執行某些著名的方法論中的內容，卻忽視了那是一個工程專案，不是自己閉門造車。
: 當然頻繁的交換引起的負面影響是不容忽視的
: 頻繁交換容易引起成員的心理情緒不穩定
~~~~~~~~ 這個要看交換的時間和時機，不是什麼時候都交換，那就不是交換開發了。所以，我文中才建議了交換的時間和方式。當然，如果某個專案就是一兩個月完成的，那 麼交換時間上就需要另外考慮了，至於是否採用交換開發的方式也需要考慮了。我從來不認為說某一個東西好就要到處都是用。類似java最初的設計考慮其實是 不太現實的。
: 個人成就感喪失
: 個人責任和利益之間不平衡
這兩條在我當年的嘗試中沒有出現這樣的負面效應，相反，我們常常會提到某個人作了哪幾個系統的開發，有什麼問題找誰誰誰詢問即可。
: 對團隊和公司的產生負面看法等
: 事實上我們現在工作基本不加班
: 但是我就覺得很累
: 啥也不幹都累
※ 來源:•水木社群 http://newsmth.net•[FROM: 162.105.200.28]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
54
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 18:20:18 2010), 站內
剛才忘記了一個事情。
您這樣的管理把團隊都放在了pm的身上，如果這個pm做得不好，反而無所謂，如果做得好，只要專案達到一個穩定階段，那麼，直接發生的結果就是，領導對這個pm有所顧忌，將這個pm開掉。這就是中國式管理對這種管理方式的最終認可形式。
除非這個pm是領導的小舅子，至親，那就沒問題了，否則，必然被開。
【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: 所以了， 我說軟體工程不重要
: 核心其實在管理方式上才是重要的
: 當然頻繁的交換引起的負面影響是不容忽視的
: ...................
※ 修改:•qingrun 於 Aug 18 18:24:54 2010 修改本文•[FROM: 162.105.200.5]
※ 來源:•水木社群 http://newsmth.net•[FROM: 162.105.200.5]
: ...................
※ 來源:•水木社群 newsmth.net•[FROM: 119.253.176.*]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
34
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Tue Aug 17 22:08:27 2010), 站內
【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: 我覺得你的理解可能與你的行業真的有很大關係
: 交換程式設計從理解上來看， 怎樣的內容才是可交換的， 人和人是可替代的
: 要滿足以下條件:
: 1. 工作技術含量不高， 技術類似
: 2. 工作業務邏輯簡單
: 3. 工作為同一模組的兩個小的子模組
: 4. 工作協同子模組之間有清晰的介面設計
您的這幾條要求都是沒有必要設定的，實際上不需要如此設定，我當年實踐的專案業務邏輯是相當複雜的，而且是各個模組之間的開發進行交換，可能從工程設計模組到商務模組，也可能到財務模組，這些交換每一個都不是簡單的業務邏輯實現，每一個模組下面都可以劃分出很多子模組。。
: 採取傳統的分工方法, 是不是就不要求程式碼結構或者文件結構清晰了呢? 從設計的
: 角度來說， 交換程式設計設計到如此詳細的 API，就很難達到。設計一般僅保證模組之
: 間大的介面， 對內部細粒度設計詳細的 API往往是畫蛇添足，這些工作應該是實現
: 者的責任，實現者應根據需求自由調整內部結構。所以要求交換時有足夠文件和清晰
: 的結構， 既不符合極限程式設計， 也是無法滿足的.
那您的設計是做到什麼程度？類，模組？還是類內部的實現細節？
您有沒有看過歐美和日本外包的設計？
: 從工作內容劃分來看，交換程式設計兩人的工作明顯應該屬於完整的一塊，強要劃分給
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~這個完全沒有必要如此假設，這個假設也是不存在的。上面剛回答過。
: 兩人完成，只能是工作量比較大 。交換程式設計帶來的溝通難度和工作量，可以類比為
: 一個人要去修正另一個人的 bug( 其實我們經常交換，呵呵 ), 交換的一方是否有
: 責任去檢查另一方的程式碼實現題，交接的一方接到程式碼後是去主動理解原有程式碼，
: 還是依葫蘆畫瓢狗尾續貂呢， 或者是對原有程式碼壓根不滿意自己另起爐灶呢， 交
: 換時發生了問題怎麼辦, 最後整合出現了問題怎麼辦, 由於交換導致的專案拖延誰
: 來負責任， 這可真是難題
: 交換程式設計和結對程式設計在本質上有所不同， 結對程式設計的兩人始終處於同一環境下，
: 同一思路， 實際上溝通量很小，溝通主要是由於技術交流引起的，屬於有效交流。
: 而交換程式設計， 溝通主要是工作切換引起的， 交流的目的很複雜， 有效性也值得懷
: 疑
您這個也是假設性的，不妨實踐一下在看看您這個評論是否合適。結對程式設計的溝通量並不小，而且也不是單一因為技術交流引起的，業務上也會引起交流，我實踐的時候就是這樣的感受。交換程式設計也是如此，為何交換程式設計的有效性就值得懷疑？
您的這段評論完全是猜測方式的評論，並沒有有效性的評論內容，我不知道您是否實踐過結對程式設計，因為交換程式設計您肯定沒有實踐過。
※ 修改:•qingrun 於 Aug 17 22:59:59 2010 修改本文•[FROM: 162.105.200.220]
※ 來源:•水木社群 http://newsmth.net•[FROM: 162.105.200.220]
[本篇全文] [回覆文章] [本篇作者：piggestbaby] [回信給作者] [進入討論區] [返回頂部]
35
發信人: piggestbaby (吃的胖胖的(~~**~~)), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 07:48:57 2010), 站內
我這恐怕是天天都在交換程式設計
因為專案很多，彼此之間相關，隨時來一個任務都可能派發到隨機的一人身上
正是這種經驗引起我對這種方式的反感
老闆的意思不僅僅是保證團隊穩定性， 還有保證每個人都任務很充足
總之目的很複雜， 開發人員機械完成， 誰也不負責任
交換程式設計試圖解決的問題，我想在傳統的管理方式中， 人才梯隊， 培訓等等能很好的解決
試圖用交換來解決這些問題， 有點吃力不討好
也許交換不交換並不重要， 也許交換的速度快了， 僅僅是兩個人配合比較流暢
也許心情高興了， 自然速度就會加快
我想並不用把交換程式設計和結對程式設計想像的如此神祕
我們每天都在和別人配合進行工作， 兩人同時討論一個問題， 一起去解決或實現一個問題
這 種經驗很普遍。 另外不要假定實現人員就不需要自己獨立設計， 實現的難度也很難大也有自由發揮性， 如果能詳細設計到你所說程度， 保留設計人員就足夠了， 交換不交換都很穩定。 結對程式設計是兩人同時完成任務，一起討論設計，一起定下實現方案，一起實現， 兩人是同一思路。 而交換程式設計是 自己設計， 自己定下實現方案， 自己實現一部分， 對方拿到程式碼， 對方觀察設計， 對方思考是否合理， 對方考慮繼續實現。 兩種方式的溝通是有本質區別的。
【 在 qingrun (青潤) 的大作中提到: 】
: 您的這幾條要求都是沒有必要設定的，實際上不需要如此設定，我當年實踐的專案業務邏輯是相當複雜的，而且是各個模組之間的開發進行交換，可能從工程設計模組到商務模組，也可能到財務模組，這些交換每一個都不是簡單的業務邏輯實現，每一個模組下面都可以劃分出很多子模
: 那您的設計是做到什麼程度？類，模組？還是類內部的實現細節？
: 您有沒有看過歐美和日本外包的設計？
: ...................
--
※ 修改:•piggestbaby 於 Aug 18 07:59:09 2010 修改本文•[FROM: 123.113.37.*]
※ 來源:•水木社群 newsmth.net•[FROM: 123.113.37.*]
[本篇全文] [回覆文章] [本篇作者：kabbesy] [回信給作者] [進入討論區] [返回頂部]
36
發信人: kabbesy (三冠王), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 08:21:22 2010), 站內
我始終認為結對比交換靠譜
而且結對也得限制頻度
【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: : 發信站: 水木社群 (Wed Aug 18 07:48:57 2010), 站內
:
: 我這恐怕是天天都在交換程式設計
: 因為專案很多，彼此之間相關，隨時來一個任務都可能派發到隨機的一人身上
: 正是這種經驗引起我對這種方式的反感
: 老闆的意思不僅僅是保證團隊穩定性， 還有保證每個人都任務很充足
: 總之目的很複雜， 開發人員機械完成， 誰也不負責任
: 交換程式設計試圖解決的問題，我想在傳統的管理方式中， 人才梯隊， 培訓等等能很好的解決
: 試圖用交換來解決這些問題， 有點吃力不討好
: 也許交換不交換並不重要， 也許交換的速度快了， 僅僅是兩個人配合比較流暢
: 也許心情高興了， 自然速度就會加快
: 我想並不用把交換程式設計和結對程式設計想像的如此神祕
: 我們每天都在和別人配合進行工作， 兩人同時討論一個問題， 一起去解決或實現一個問題
: 這種經驗很普遍。 另外不要假定實現人員就不需要自己獨立設計， 實現的難度也很難大也有自由發揮性， 如果能詳細設計到你所說程度， 保留設計人員就足夠了， 交換不交換都很穩定。 結對程式設計是兩人同時完成任務，一起討論設計，一起定下實現方案，一起實現， 兩人是同一思路。 而交換程式設計是 自己設計， 自己定下實現方案， 自己實現一部分， 對方拿到程式碼， 對方觀察設計， 對方思考是否合理， 對方考慮繼續實現。 兩種方式的溝通是有本質區別的。
:
: 【 在 qingrun (青潤) 的大作中提到: 】
: : 您的這幾條要求都是沒有必要設定的，實際上不需要如此設定，我當年實踐的專案業務邏輯是相當複雜的，而且是各個模組之間的開發進行交換，可能從工程設計模 塊到商務模組，也可能到財務模組，這些交換每一個都不是簡單的業務邏輯實現，每一個模組下面都可以劃分出很多子模
: : 那您的設計是做到什麼程度？類，模組？還是類內部的實現細節？
: : 您有沒有看過歐美和日本外包的設計？
: : ...................
:
: ※ 修改:•piggestbaby 於 Aug 18 07:59:09 2010 修改本文•[FROM: 123.113.37.*]
: ※ 來源:•水木社群 newsmth.net•[FROM: 123.113.37.*]
※ 來源:•水木社群 newsmth.net•[FROM: 124.205.138.*]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
37
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 16:08:53 2010), 站內
天天都在交換程式設計？
您能講講你們是怎麼交換的麼？你們目前的交換是怎麼產生的？當時為什麼要交換麼？
一般來說，無目的和有目的的操作效果上必然是有差異的，所以，我想了解一下你們的情況，然後再做更多地分析評論。
【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: 我這恐怕是天天都在交換程式設計
: 因為專案很多，彼此之間相關，隨時來一個任務都可能派發到隨機的一人身上
: 正是這種經驗引起我對這種方式的反感
: 老闆的意思不僅僅是保證團隊穩定性， 還有保證每個人都任務很充足
: 總之目的很複雜， 開發人員機械完成， 誰也不負責任
: 交換程式設計試圖解決的問題，我想在傳統的管理方式中， 人才梯隊， 培訓等等能很
: 好的解決
: 試圖用交換來解決這些問題， 有點吃力不討好
: 也許交換不交換並不重要， 也許交換的速度快了， 僅僅是兩個人配合比較流暢
~~~~~~~~~~~~~~~這個是結對還是交換？我怎麼看不明白了？交換不僅僅是兩個人的事情。
: 也許心情高興了， 自然速度就會加快
: 我想並不用把交換程式設計和結對程式設計想像的如此神祕
這句話我非常同意，本來就不是什麼非常神祕的事情，但是，操作上還是有差異的。
最簡單的比如說會議，都是會議，有些就是有效的，有些就是無效的，而且大量的浪費時間拖沓冗長。所以，必須瞭解清楚你們到底是如何操作的，我才能分析分析，哪怕我是錯的，至少讓我看到我錯誤的原因所在。
: 我們每天都在和別人配合進行工作， 兩人同時討論一個問題， 一起去解決或實現
: 一個問題
: 這種經驗很普遍。 另外不要假定實現人員就不需要自己獨立設計， 實現的難度也
: 很難大也有自由發揮性， 如果能詳細設計到你所說程度，保留設計人員就足夠了，
: 交換不交換都很穩定。 結對程式設計是兩人同時完成任務，一起討論設計，一起定下實
: 現方案，一起實現， 兩人是同一思路。而交換程式設計是 自己設計， 自己定下實現方
: 案， 自己實現一部分， 對方拿到程式碼， 對方觀察設計， 對方思考是否合理， 對
: 方考慮繼續實現。兩種方式的溝通是有本質區別的。
※ 來源:•水木社群 http://newsmth.net•[FROM: 162.105.200.28]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
38
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 16:25:10 2010), 站內
這個，呵呵。
【 在 kabbesy (三冠王) 的大作中提到: 】
: 我始終認為結對比交換靠譜
: 而且結對也得限制頻度
※ 來源:•水木社群 http://newsmth.net•[FROM: 162.105.200.28]
[本篇全文] [回覆文章] [本篇作者：kabbesy] [回信給作者] [進入討論區] [返回頂部]
39
發信人: kabbesy (三冠王), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 16:28:49 2010), 站內
哈哈
不是拍磚，勿怪勿怪
【 在 qingrun (青潤) 的大作中提到: 】
: 這個，呵呵。
※ 來源:•水木社群 newsmth.net•[FROM: 124.205.138.*]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
40
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 16:38:55 2010), 站內
呵呵，沒事，其實每個人都有看法才是對的，可以不同意，但是不能不讓別人發表意見。
來這裡的，如果還是糊糊塗塗模稜兩可的，那就沒意思了。
創造一個東西不容易，新的東西，大家反對的意見肯定比較多，通過反對的意見也可以收集到更多更好的正面的反饋資訊，也有助於大家判斷一個事物是否真得有用，我還是覺得，有可能的話不妨嘗試一下再下結論。
【 在 kabbesy (三冠王) 的大作中提到: 】
: 哈哈
: 不是拍磚，勿怪勿怪
※ 來源:•水木社群 http://newsmth.net•[FROM: 162.105.200.28]
[本篇全文] [回覆文章] [本篇作者：kabbesy] [回信給作者] [進入討論區] [返回頂部]
41
發信人: kabbesy (三冠王), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 16:52:36 2010), 站內
我的經歷中，team成員如果狀態從1到5的話
1-3，都得靠leader的手腕去帶領
到達4，得靠專案的成績、錢、未來發展
到達5，再開始做結對這種事情
民企流
出活是第1位的，團隊狀態是第1.1位的，程式碼質量是第1.5位的
結對這些優先順序真的太靠後了……
【 在 qingrun (青潤) 的大作中提到: 】
: : 發信站: 水木社群 (Wed Aug 18 16:38:55 2010), 站內
:
: 呵呵，沒事，其實每個人都有看法才是對的，可以不同意，但是不能不讓別人發表意見。
: 來這裡的，如果還是糊糊塗塗模稜兩可的，那就沒意思了。
: 創造一個東西不容易，新的東西，大家反對的意見肯定比較多，通過反對的意見也可以收集到更多更好的正面的反饋資訊，也有助於大家判斷一個事物是否真得有用，我還是覺得，有可能的話不妨嘗試一下再下結論。
:
: 【 在 kabbesy (三冠王) 的大作中提到: 】
: : 哈哈
: : 不是拍磚，勿怪勿怪
:
: ※ 來源:•水木社群 http://newsmth.net•[FROM: 162.105.200.28]
※ 來源:•水木社群 newsmth.net•[FROM: 124.205.138.*]
[本篇全文] [回覆文章] [本篇作者：piggestbaby] [回信給作者] [進入討論區] [返回頂部]
42
發信人: piggestbaby (吃的胖胖的(~~**~~)), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 17:02:45 2010), 站內
我 們有很多專案， 專案之間採用的技術是差不多的。 有新專案，有老專案維護， 有實驗性質的， 任務也是很飽滿的， 經常會出現一個人頭上好幾個任務的情況， 於是就出現了優先順序， 優先順序高的任務來了， 迅速切換到優先順序高的任務。 由於任務優先順序和工作量不等， 完成時間參差不齊， 於是又經常出現這個人的內容， 下一階段又切換到另外一個人那裡去的事情, 誰做完了一塊內容閒下來， 又會隨機領到不知道什麼階段的任務。
交換的原因其實就是前面提到的， 避免某項技術被個人壟斷， 讓大家任務都很飽滿。
【 在 qingrun (青潤) 的大作中提到: 】
: 天天都在交換程式設計？
: 您能講講你們是怎麼交換的麼？你們目前的交換是怎麼產生的？當時為什麼要交換麼？
: 一般來說，無目的和有目的的操作效果上必然是有差異的，所以，我想了解一下你們的情況，然後再做更多地分析評論。
: ...................
--
※ 來源:•水木社群 newsmth.net•[FROM: 119.253.176.*]
[本篇全文] [回覆文章] [本篇作者：kabbesy] [回信給作者] [進入討論區] [返回頂部]
43
發信人: kabbesy (三冠王), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 17:08:37 2010), 站內
平均薪資多少？
雖然絕對不支援
但我絕對佩服能把程式設計師當工人使的公司
【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: : 發信站: 水木社群 (Wed Aug 18 17:02:45 2010), 站內
:
: 我們有很多專案， 專案之間採用的技術是差不多的。 有新專案，有老專案維護， 有實驗性質的， 任務也是很飽滿的， 經常會出現一個人頭上好幾個任務的情況， 於是就出現了優先順序， 優先順序高的任務來了， 迅速切換到優先順序高的任務。 由於任務優先順序和工作量不等， 完成時間參差不齊， 於是又經常出現這個人的內容， 下一階段又切換到另外一個人那裡去的事情, 誰做完了一塊內容閒下來， 又會隨機領到不知道什麼階段的任務。
: 交換的原因其實就是前面提到的， 避免某項技術被個人壟斷， 讓大家任務都很飽滿。
:
: 【 在 qingrun (青潤) 的大作中提到: 】
: : 天天都在交換程式設計？
: : 您能講講你們是怎麼交換的麼？你們目前的交換是怎麼產生的？當時為什麼要交換麼？
: : 一般來說，無目的和有目的的操作效果上必然是有差異的，所以，我想了解一下你們的情況，然後再做更多地分析評論。
: : ...................
:
: --
:
: ※ 來源:•水木社群 newsmth.net•[FROM: 119.253.176.*]
※ 來源:•水木社群 newsmth.net•[FROM: 124.205.138.*]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
44
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 17:12:05 2010), 站內
【 在 kabbesy (三冠王) 的大作中提到: 】
: 我的經歷中，team成員如果狀態從1到5的話
: 1-3，都得靠leader的手腕去帶領
: 到達4，得靠專案的成績、錢、未來發展
其實4、5和1-3沒什麼差別。接近10人或者以上差別就大了。
: 到達5，再開始做結對這種事情
~~~5個人作結對，我覺得人數也太少了。一個專案經理+2個結對組？說實話，總感覺很可笑。呵呵。
: 民企流
: 出活是第1位的，團隊狀態是第1.1位的，程式碼質量是第1.5位的
: 結對這些優先順序真的太靠後了……
~~~~肯定靠後。
也 就是因為對結對的實踐，加上那時候經歷的企業對員工都不夠好，員工跳槽基本上是1年左右就比較多了，我留人雖然還可以，但是，不能讓弟兄們總為了大家相處 得面子和感情留下來，畢竟都要生活。加上當時我們這批人（分別是成都和上海兩批，只有我和這兩批人都合作過）進入電信設計院後，組內還有兩個原來設計院作 開發的弟兄，從陌生到熟悉到配合，於是，產生了交換方式的嘗試。
※ 來源:•水木社群 http://newsmth.net•[FROM: 162.105.200.28]
[本篇全文] [回覆文章] [本篇作者：piggestbaby] [回信給作者] [進入討論區] [返回頂部]
45
發信人: piggestbaby (吃的胖胖的(~~**~~)), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 17:12:16 2010), 站內
呵呵，中低水平
只要你不追求軟體質量
不追求長遠發展
騙到一個是一個
啥事都能做地
不過說實話，我們工作混日子還是滿輕鬆的
壓根沒法考核， 各種理由， 各種推卸責任
堆的多了，慢慢做就是
【 在 kabbesy (三冠王) 的大作中提到: 】
: 平均薪資多少？
: 雖然絕對不支援
: 但我絕對佩服能把程式設計師當工人使的公司
: ...................
--
※ 修改:•piggestbaby 於 Aug 18 17:15:26 2010 修改本文•[FROM: 119.253.176.*]
※ 來源:•水木社群 newsmth.net•[FROM: 119.253.176.*]
[本篇全文] [回覆文章] [本篇作者：kabbesy] [回信給作者] [進入討論區] [返回頂部]
46
發信人: kabbesy (三冠王), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 17:15:32 2010), 站內
ft.........
【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: 呵呵，中低水平
: 只要你不追求軟體質量
: 不追求長遠發展
: ...................
※ 來源:•水木社群 newsmth.net•[FROM: 124.205.138.*]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
47
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 17:15:39 2010), 站內
哦。這個原因的交換。
如果是這樣，我覺得，你們的交換目的不純，不是為了團隊的融合，而是為了真得就是前面提到的把人當機器使用。
另外，交換的方式上，你們是任務交換，並沒有形成模式，一定的模式是有必要的，也可能和這個有關係，你們的這個交換就類似於很多開發團隊開會，開到大家頭暈腦脹，效果還不好，老闆看著每個人都忙。
我的團隊開會，評審會一般30分鐘左右肯定結束，一般的會議10分鐘結束，然後就是各自分組的討論和交流，沒有必要大家都聚集起來為某一兩個人的事情而浪費時間。
所以，不同的人不同的團隊即使做同樣的事情，也一樣會帶來不同的效果，其原因應該就在這裡。
【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: 我們有很多專案， 專案之間採用的技術是差不多的。 有新專案，有老專案維護， 有實驗性質的， 任務也是很飽滿的， 經常會出現一個人頭上好幾個任務的情況， 於是就出現了優先順序， 優先順序高的任務來了， 迅速切換到優先順序高的任務。 由於任務優先順序和工作量不等， 完成時間參差不齊， 於是又經常出現這個人的內容， 下一階段又切換到另外一個人那裡去的事情, 誰做完了一塊內容閒下來， 又會隨機領到不知道什麼階段的任務。
: 交換的原因其實就是前面提到的， 避免某項技術被個人壟斷， 讓大家任務都很飽滿。
※ 來源:•水木社群 http://newsmth.net•[FROM: 162.105.200.28]
[本篇全文] [回覆文章] [本篇作者：kabbesy] [回信給作者] [進入討論區] [返回頂部]
48
發信人: kabbesy (三冠王), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 17:15:50 2010), 站內
汗死
不好意思，我說的是狀態從1分到5分，不是人數……
【 在 qingrun (青潤) 的大作中提到: 】
: : 發信站: 水木社群 (Wed Aug 18 17:12:05 2010), 站內
:
:
: 【 在 kabbesy (三冠王) 的大作中提到: 】
: : 我的經歷中，team成員如果狀態從1到5的話
: : 1-3，都得靠leader的手腕去帶領
: : 到達4，得靠專案的成績、錢、未來發展
: 其實4、5和1-3沒什麼差別。接近10人或者以上差別就大了。
: : 到達5，再開始做結對這種事情
: ~~~5個人作結對，我覺得人數也太少了。一個專案經理+2個結對組？說實話，總感覺很可笑。呵呵。
:
: : 民企流
: : 出活是第1位的，團隊狀態是第1.1位的，程式碼質量是第1.5位的
: : 結對這些優先順序真的太靠後了……
: ~~~~肯定靠後。
: 也就是因為對結對的實踐，加上那時候經歷的企業對員工都不夠好，員工跳槽基本上是1年左右就比較多了，我留人雖然還可以，但是，不能讓弟兄們總為了大家相 處得面子和感情留下來，畢竟都要生活。加上當時我們這批人（分別是成都和上海兩批，只有我和這兩批人都合作過）進入電信設計院後，組內還有兩個原來設計院 作開發的弟兄，從陌生到熟悉到配合，於是，產生了交換方式的嘗試。
:
: ※ 來源:•水木社群 http://newsmth.net•[FROM: 162.105.200.28]
※ 來源:•水木社群 newsmth.net•[FROM: 124.205.138.*]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
49
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 17:17:23 2010), 站內
呵呵，不好意思，應該是我，我看走眼了。
【 在 kabbesy (三冠王) 的大作中提到: 】
: 汗死
: 不好意思，我說的是狀態從1分到5分，不是人數……
※ 來源:•水木社群 http://newsmth.net•[FROM: 162.105.200.28]
[本篇全文] [回覆文章] [本篇作者：kabbesy] [回信給作者] [進入討論區] [返回頂部]
50
發信人: kabbesy (三冠王), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 17:19:34 2010), 站內
很支援中間對會議時間的控制
【 在 qingrun (青潤) 的大作中提到: 】
: : 發信站: 水木社群 (Wed Aug 18 17:15:39 2010), 站內
:
: 哦。這個原因的交換。
: 如果是這樣，我覺得，你們的交換目的不純，不是為了團隊的融合，而是為了真得就是前面提到的把人當機器使用。
: 另外，交換的方式上，你們是任務交換，並沒有形成模式，一定的模式是有必要的，也可能和這個有關係，你們的這個交換就類似於很多開發團隊開會，開到大家頭暈腦脹，效果還不好，老闆看著每個人都忙。
: 我的團隊開會，評審會一般30分鐘左右肯定結束，一般的會議10分鐘結束，然後就是各自分組的討論和交流，沒有必要大家都聚集起來為某一兩個人的事情而浪費時間。
: 所以，不同的人不同的團隊即使做同樣的事情，也一樣會帶來不同的效果，其原因應該就在這裡。
: 【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: : 我們有很多專案， 專案之間採用的技術是差不多的。 有新專案，有老專案維護， 有實驗性質的， 任務也是很飽滿的， 經常會出現一個人頭上好幾個任務的情況， 於是就出現了優先順序， 優先順序高的任務來了， 迅速切換到優先順序高的任務。 由於任務優先順序和工作量不等， 完成時間參差不齊， 於是又經常出現這個人的內容， 下一階段又切換到另外一個人那裡去的事情, 誰做完了一塊內容閒下來， 又會隨機領到不知道什麼階段的任務。
: : 交換的原因其實就是前面提到的， 避免某項技術被個人壟斷， 讓大家任務都很飽滿。
:
: ※ 來源:•水木社群 http://newsmth.net•[FROM: 162.105.200.28]
※ 來源:•水木社群 newsmth.net•[FROM: 124.205.138.*]
[本篇全文] [回覆文章] [本篇作者：piggestbaby] [回信給作者] [進入討論區] [返回頂部]
51
發信人: piggestbaby (吃的胖胖的(~~**~~)), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 17:26:51 2010), 站內
所以了， 我說軟體工程不重要
核心其實在管理方式上才是重要的
當然頻繁的交換引起的負面影響是不容忽視的
頻繁交換容易引起成員的心理情緒不穩定
個人成就感喪失
個人責任和利益之間不平衡
對團隊和公司的產生負面看法等
事實上我們現在工作基本不加班
但是我就覺得很累
啥也不幹都累
【 在 qingrun (青潤) 的大作中提到: 】
: 哦。這個原因的交換。
: 如果是這樣，我覺得，你們的交換目的不純，不是為了團隊的融合，而是為了真得就是前面提到的把人當機器使用。
: 另外，交換的方式上，你們是任務交換，並沒有形成模式，一定的模式是有必要的，也可能和這個有關係，你們的這個交換就類似於很多開發團隊開會，開到大家頭暈腦脹，效果還不好，老闆看著每個人都忙。
: ...................
--
※ 來源:•水木社群 newsmth.net•[FROM: 119.253.176.*]
[本篇全文] [回覆文章] [本篇作者：kabbesy] [回信給作者] [進入討論區] [返回頂部]
52
發信人: kabbesy (三冠王), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 17:29:39 2010), 站內
【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: : 發信站: 水木社群 (Wed Aug 18 17:26:51 2010), 站內
:
: 所以了， 我說軟體工程不重要
這個不能re
重要是重要的，但也有優先順序
: 核心其實在管理方式上才是重要的
這個必須sp
: 當然頻繁的交換引起的負面影響是不容忽視的
: 頻繁交換容易引起成員的心理情緒不穩定
: 個人成就感喪失
: 個人責任和利益之間不平衡
其實工作很簡單，責任和權利，平衡就行
加上好的氛圍那就錦上添花了
: 對團隊和公司的產生負面看法等
: 事實上我們現在工作基本不加班
: 但是我就覺得很累
: 啥也不幹都累
哈哈，re
:
: 【 在 qingrun (青潤) 的大作中提到: 】
: : 哦。這個原因的交換。
: : 如果是這樣，我覺得，你們的交換目的不純，不是為了團隊的融合，而是為了真得就是前面提到的把人當機器使用。
: : 另外，交換的方式上，你們是任務交換，並沒有形成模式，一定的模式是有必要的，也可能和這個有關係，你們的這個交換就類似於很多開發團隊開會，開到大家頭暈腦脹，效果還不好，老闆看著每個人都忙。
: : ...................
:
※ 來源:•水木社群 newsmth.net•[FROM: 124.205.138.*]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
53
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 17:33:44 2010), 站內
【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: 所以了， 我說軟體工程不重要
: 核心其實在管理方式上才是重要的
~~~~~~~~這其實是我定義的軟體開發方法論的內容，方法論不只是交換，結對，螺旋、迭代的概念名詞，裡面要包含具體的操作方式，如何是正確的操 作，什麼樣是錯誤的行為，這些都很重要，也有人很好的專案經理管理不好專案的情況，這並不鮮見，就是因為方法的掌握不對。
比如，top當年丟掉南京地稅後續3000多萬合同的專案，就是方法錯誤，主要管理者過於教條的執行某些著名的方法論中的內容，卻忽視了那是一個工程專案，不是自己閉門造車。
: 當然頻繁的交換引起的負面影響是不容忽視的
: 頻繁交換容易引起成員的心理情緒不穩定
~~~~~~~~ 這個要看交換的時間和時機，不是什麼時候都交換，那就不是交換開發了。所以，我文中才建議了交換的時間和方式。當然，如果某個專案就是一兩個月完成的，那 麼交換時間上就需要另外考慮了，至於是否採用交換開發的方式也需要考慮了。我從來不認為說某一個東西好就要到處都是用。類似java最初的設計考慮其實是 不太現實的。
: 個人成就感喪失
: 個人責任和利益之間不平衡
這兩條在我當年的嘗試中沒有出現這樣的負面效應，相反，我們常常會提到某個人作了哪幾個系統的開發，有什麼問題找誰誰誰詢問即可。
: 對團隊和公司的產生負面看法等
: 事實上我們現在工作基本不加班
: 但是我就覺得很累
: 啥也不幹都累
※ 來源:•水木社群 http://newsmth.net•[FROM: 162.105.200.28]
[本篇全文] [回覆文章] [本篇作者：qingrun] [回信給作者] [進入討論區] [返回頂部]
54
發信人: qingrun (青潤), 信區: SoftEng
發信站: 水木社群 (Wed Aug 18 18:20:18 2010), 站內
剛才忘記了一個事情。
您這樣的管理把團隊都放在了pm的身上，如果這個pm做得不好，反而無所謂，如果做得好，只要專案達到一個穩定階段，那麼，直接發生的結果就是，領導對這個pm有所顧忌，將這個pm開掉。這就是中國式管理對這種管理方式的最終認可形式。
除非這個pm是領導的小舅子，至親，那就沒問題了，否則，必然被開。
【 在 piggestbaby (吃的胖胖的(~~**~~)) 的大作中提到: 】
: 所以了， 我說軟體工程不重要
: 核心其實在管理方式上才是重要的
: 當然頻繁的交換引起的負面影響是不容忽視的
: ...................
※ 修改:•qingrun 於 Aug 18 18:24:54 2010 修改本文•[FROM: 162.105.200.5]
※ 來源:•水木社群 http://newsmth.net•[FROM: 162.105.200.5]
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/257598/viewspace-671872/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- [軟體工程]交換程式設計方法的深入討論軟體工程程式設計
- [技術討論]交換程式設計實踐與延續程式設計
- 軟體工程——程式導向的軟體設計方法軟體工程
- [技術討論]什麼是最好的軟體設計方法
- [技術討論]06年12月結對程式設計與交換程式設計的對話程式設計
- 程式設計師與軟體工程是永遠的矛盾嗎?(續) (轉)程式設計師軟體工程
- [軟體工程]敏捷過程模型的特性研討——源自newsmth上的討論軟體工程敏捷模型
- 【軟體工程】軟體設計之總體設計軟體工程
- [討論]“消滅”程式設計師？程式設計師
- 深入討論通用許可權元件的理論和設計實現。元件
- 軟體工程方法論對軟體開發有多大的用處？軟體工程
- C#開發的兩個基本程式設計原則的深入討論(轉)C#程式設計
- [技術討論]關於《交換程式設計——極限程式設計的延伸實踐》一文擬錄用通知程式設計
- 軟體工程——概論軟體工程
- 沒人比程式設計師更討厭軟體程式設計師
- [討論] 似是而非的程式設計觀點程式設計
- 關於程式設計風格的討論 (轉)程式設計
- 中國的頂級軟體程式設計工程師和歐美的頂級軟體程式設計工程師差距有多大？程式設計工程師
- “軟體工程版”網友行為守則(討論稿) (轉)軟體工程
- 軟體工程課程設計軟體工程
- 業務中介軟體設計方法論經驗總結
- 【軟體工程】物件導向的設計軟體工程物件
- 討論：什麼才算是真正的程式設計能力？程式設計
- 軟考論文之論軟體的可靠性設計
- 論軟體的可靠性設計
- [技術討論]軟體工程之全程建模實現適合做教材麼？軟體工程
- [圖靈程式設計叢書].持續交付：釋出可靠軟體的系統方法.pdf圖靈程式設計
- 軟體設計師：軟體工程基礎知識軟體工程
- 軟體工程--為什麼軟體開發方法論讓你覺得糟糕軟體工程
- 軟體工程方法論對我們經軟體開發有多大用處?軟體工程
- 軟體工程-論文查重軟體工程
- 軟體工程——軟體計劃軟體工程
- 表結構設計討論
- 現代軟體工程第六章【敏捷流程】練習與討論軟體工程敏捷
- 關於軟體事務記憶體(STM)的討論記憶體
- 程式設計師與軟體工程是永遠的矛盾嗎? (轉)程式設計師軟體工程
- 《軟體工程》課程設計總結軟體工程
- 討論著軟體測試發現到最後都不是在討論軟體次測試了