關於大鍋飯的問題很多朋友有疑問，這裡進行了一些說明，同時與結對程式設計進行了對比分析。
發信人: muser (負盡千重罪，練就不死心), 信區: softeng
標 題: re: 交換程式設計方法介紹
發信站: 水木社群 (thu mar 24 14:07:10 2011), 站內
現在的思路好象把程式設計師超頻至可以穩定的極限~~~
結對程式設計，乙個人去拉粑，另外乙個也許就得去尿尿。
最起碼，乙個人在找獵頭打**，就沒辦法向另外乙個人交待。
兩男人坐一起，你想上個網灌個水，沒興趣。很多碼農是獨語者。
兩人的精神狀態得同相。
每天8小時抖擻精神幹下來...不讀幾次博士怕是培養不出這種素養。
交換...？工作業績怎麼衡量？搞不好成了吃大鍋飯的了。
回答：這裡我先提乙個問題：
大家平時做開發的時候，如果某個人就是在吃大鍋飯，始終拖延進展或者技能不足，你怎麼辦？
難道你要等著所有的模組都開發完，然後等待這個模組的開發進展麼？
這個時候，專案管理者或者負責人自然會對這個人提出疑問，要求他加快進度，或者不能承擔就改做其他模組，這裡就出現兩個分支：
1、這個人改做其它模組開發仍然無法完成。
如此多了，我不相信領導會不考慮處理問題，比如辭退，扣除獎金等等懲罰措施。
2、改做其他模組完成了，原有模組誰來承接？承接者怎麼辦？
承接者的績效如何衡量？難道不是一樣的進行衡量計算麼？——這裡暫時不討論目前的績效管理模式的不合理的地方（如果非要合理的，參看我的可度量績效管理模型中的一些建議，應該會有一些可操作的好一些的辦法）。
既然有新的承接者，自然就會形成接近交換程式設計/開發中的績效承接計算方式。
上面問題的另乙個解決辦法：領導安排人指導這個人進行該模組的開發，指導者的績效如何計算？現有的績效管理模式中也必須提供一些辦法，哪怕是拍腦袋的方式進行的計算。
如此而來，交換程式設計/開發會形成大鍋飯模式的疑問是不是解釋清楚了？
其實，更多的人擔心的應該還是結對開發中的大鍋飯問題，因為兩個人是同乙個任務，無法衡量兩個人在這個組合中各自的貢獻問題才對，而不是交換程式設計的績效問題。
不知道是否解釋清楚這個問題，大家可以繼續討論。
【 在 loafer (狒狒) 的大作中提到: 】
: muser只是提醒我們應該盡量考慮「非理想環境」下如何去經營軟體開發的管理，
: 不要理想化工作環境，或理想化參與開發的人員結構。
: 這本身是一種務實的態度，不對吧？
: ...................
全程建模 2023年全程建模培訓的總結
這次培訓比較匆忙，但是效果還不錯。第一天從早上9點50開始到下午7點結束。因為早上我睡過了，鬧鐘沒有響。所以，中午我就請所有的人吃了頓午飯，作為賠禮。今天開始了第一天的培訓，結果早上我8點55才起來。後來才知道，因為是週日，我的鬧鐘週六日不響。中午我請所有的人吃了頓飯，有乙個人沒過來吃，就是那個小孩...
全程建模 2023年的全程建模培訓順利完成通告
培訓持續四天，這裡向過來參加的朋友表示感謝。由於 沒有發過來，過兩天我會發布培訓中的一些 培訓中使用的案例是 幼兒教育系統 屬於專家系統定位基礎的一種教育資訊系統，這個案例是參加培訓的學員在現場提出的十幾個專案中最終確定的乙個。說實話，一直到第二天，明確需求後，我才明白這個系統的作用 可能和我沒有孩...
全程建模 系統邊界和分包的問題
行路人 16 55 54 好的。謝謝。我還有乙個問題 rose的用例圖中，如何畫 系統邊界 在powerdesigner中，很好畫，但是，rose中，就是找不到。青潤 16 59 00 哦。系統邊界通過use case和actor進行標誌，非本系統內的研究物件也無和功能都不設為用例。青潤 16 59...