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

: 恩，這樣的情況在行業軟體開發中也出現過，一般來說涉及到一些較大的行業是不允許使用開源軟體的，但是，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]

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