我會告訴他們他們是正確的，那麼我們如何在實踐中實現該目標？

原則上，這是一個值得稱讚且可以實現的目標。讓我們看一下具體情況：

如果每個開發人員都以自己的風格在自己的小島上孤立地工作，並獨立做出自己的選擇，那將是災難。他們的工作將如何與其他人融合？如果他們生病或休假怎麼辦？如果上帝禁止，他們出了事故而無法工作甚至死亡怎麼辦？如果他們是唯一知道其代碼的工作方式的人，並且他們的同事需要大量時間才能理解該人的工作，那麼這將威脅到公司的連續性！（有時稱為總線係數）

同時，每個開發人員都有自己的一套技能和專長。並非每個人都同樣精通所有內容，這沒關係！這就是為什麼您要為實現共同目標而團隊協作的原因。

那麼，為了實現可行的狀況應該怎麼做？

首先，團隊應坐在一起，選擇要採用的一組編碼準則，或將其自己組合在一起。這消除了代碼中的“混亂”因素：由於每個人都將以相同的方式來做事，所以對程序員來說，理解事情的工作方式應該容易得多。

其次，應該建立一個提供知識共享機會的系統。如果您的所有時間都花在編寫代碼上，那麼您就沒有時間共享知識，因此問題仍然存在。程序員應該有時間記錄他們的代碼，或者與其他人（或者最好是兩者）積極地分享他們的知識。還應建立代碼文檔編制準則，以防止由於文檔不完整或不足而引起的潛在問題。雖然專家可能只需短短的幾行就可以理解某項功能，但是不經常使用該功能的人將需要更多的信息以加快速度。該文檔應為第二種情況提供足夠的信息。

理想情況下，這種知識共享由對彼此工作的定期審查來支持。這為審閱者提供了增加他們對代碼的知識的機會，同時還幫助您的團隊提高了代碼的整體質量，因為額外的關注將有助於發現可能的錯誤。它還有助於團隊增進對產品整體質量的了解。如果必須以“ hacky”的方式解決很多問題，那麼顯然產品的質量將比如果使用清晰的代碼可以解決相同的問題要低得多。

類似於理髮師，理想的是所有理髮師（編碼員）都能完成彼此的工作，因為：

• 它們都使用相同的髮型

• 所有使用相同或至少等同的技術和工具進行剪裁的人

• 使用約定的系統記錄他們在理髮上的進度，注意他們做了什麼，他們如何做以及為什麼這樣做

• 他們經常花一些時間來回顧彼此的工作，從而幫助他們對此很熟悉

要解決OP對問題的“態度”，很可能是現實中，隨著程序員的時間（由於期限和對如何花費時間的期望）以及高度專業化的性質在每個程序員的工作中，這個目標在實踐中都是無法實現的。不管怎樣，幫助您的經理親自了解為何無法實現目標的方法要容易得多，然後指出這種情況，然後為之辯護。因此，如果有人提出一些您認為主要問題的建議，請嘗試以建設性的態度做出回應，即“當然，但是我們如何解決X，Y和Z？” 而不是做出消極的回應。響應，即“由於X，Y和Z，這永遠都行不通！” 。這有助於管理層以更積極的眼光看待您，最終可能會產生一個更好，更愉快的工作環境。

如果實現目標A意味著花費大量時間，精力或金錢來解決問題X，Y和Z，那麼麻煩就不值得了，但這是管理層應該做出的決定，因此作為員工，我們的工作是為他們提供必要的信息，以便他們做出明智的決定。

集體代碼所有權是敏捷開發中的一件事，通常被認為是一件好事。但是，看來您的老闆只是從適合他們的敏捷宣言中拿走了他們喜歡的一件事，而忽略了其他所有人。

要實現這一目標，您需要有一個緊密合作的團隊並經常交流。大多數作業應通過結對編程來解決，代碼審查應該是常見且早起的，應該進行高度的測試以激發對質量的信心，最好使用測試驅動的開發等進行開發。

通用的代碼標準甚至不是敏捷的東西，它只是常識。

我認為問題出在您身上，而不是您的經理。

不同的人在做事上有不同的方式

您需要製止這種權利現在，設置編碼標準，開始進行設計，並且可以互換。

當我的一位同事休假時，我們得到了他正在從事的工作，進展是什麼以及哪些突出問題的文檔。

我認為問題的核心在於，您應該開始更多地以團隊形式工作。

如果您不能以同事的身份到達那裡，那麼實現這一目標是管理層的工作，為此他們會得到報酬。

每個程序員都可以在軟件的每個部分上都能很好地工作的集體代碼所有權是一個理想，應該針對（因為好處是實實在在的），但要付出艱辛的努力。

團隊需要實施一種編程風格，以便每個人都可以立即識別代碼。團隊需要進行嚴格的代碼審查，以便在編寫代碼後就立即共享一點代碼的知識，並確保質量的通用標準。您需要使用“完成的定義”，以確保在對文檔進行記錄，測試和檢查之前，沒有任何事情稱為“完成”。團隊的新成員需要時間和培訓來掌握所使用的所有技術。

如果管理人員在沒有首先投資實施過程的情況下就要求這種過程的結果，那麼他們是不現實的

我認為您應該與同事討論您想對工作流程進行什麼樣的更改以使其更可行，例如從代碼審查或結對編程開始，或者就通用的編碼風格達成共識。 。

然後，去找您的經理，說些類似

的話，我知道您希望所有程序員都可以互換，這樣我們可以解決可能出現的任何問題。但是，我們還不存在-我們所有人實際上只知道圍繞部分代碼庫的方式，很難適應其他人的工作方式。 但是，我們確實認為這是一個好主意，因此我們建議實施X和Y以開始朝著這個目標努力。

在我看來，開發人員和管理人員在從個人代碼所有權到共同責任的頻譜上都處於極端相反的立場。

開發人員可以做更多的事情來實現管理人員的理想：

• 編碼標準。不應混亂，因為不同的人有不同的做事方式。
• 考慮對編程。這樣，至少有兩個人可以理解每個更改。
• 養成尋找根本原因的習慣，而不是在補丁上應用補丁。我認為大多數經驗豐富的程序員都必須找出他們未編寫的代碼中的錯誤。確實需要花費時間和精力。
• 文檔，審閱，文檔，審閱...。這個人已經工作了一個月的設計應該已經被一些人寫下並理解了。人。

您可能無法獲得經理想要的最大靈活性，但是您應該能夠超越所有人，只有一個可以為每個人工作的人一段代碼。您有時可能需要告訴他們“ Joe或Nancy可以更快地做到這一點”，然後讓他們決定是否支付費用讓其他人來收取。

簡短的回答： b>指出它是多麼的荒謬。

我以前確實遇到過這個問題，我只是說了些類似的話：

如果需要腦外科手術，您會去看足科醫生嗎？他們都是醫生，對嗎？！

或

您去找裁縫剪頭髮是因為裁縫就像美髮師一樣使用剪刀？

然後指出，每個專業都有非常不同的技能集。告訴他們編程是一樣的。一些開發人員在一個領域中技能很高，但是在另一個領域中卻完全不知所措。

並不是說您不能學習其他技能，但這需要時間和意願。要。

您寫道，

沒有人擁有任何東西，也沒有人負責任何事情。換句話說，每個人都擁有一切，每個人都應對一切負責。

這對於軟件公司來說是常見的嗎？

取決於程序員的數量，有各種各樣的可能性。

一種是為每個組成部分分配一個小組（由幾個組成）。期望團隊中的任何人/每個人（如有必要）對整個組件負責。一個團隊可能會或可能不會只有一個首席開發人員或團隊負責人，他們可能也可能不是團隊在外界（管理和質量保證）之間的正式聯繫點。

我建議的最低要求是代碼審查。每個人都對自己的開發負責，需要花幾天的時間來編寫一些新功能，然後一個或多個其他人要花費數小時來檢查完成，測試和簽入的內容。代碼審閱者可以提出更改建議，並可以合理地進行建議。期望（管理層）了解他們所審查的內容。例如，評論評論（在他們接受或“退出”更改之前）可能是“我不理解，您最好對其進行一些修改和/或更好地解釋”，或“這是什麼？它執行的功能是什麼（例如，在功能規範中可見），自動功能回歸測試將在其中進行測試”。

（如果有）他們會在更改後簽字，經理說：“讓鮑勃去度假和/或退出公司是很合理的；我們認為您審查的這個模塊存在問題，並且/或者我們想向其中添加新功能。看看嗎？您已經很熟悉（更不用說負責了），因為您在實現時就進行了代碼審查。”

代碼審查有許多目的，包括：

• 對哪些組件的功能以及如何實現它們進行交叉培訓
• 確保通用/一致的標準（編碼，文檔和/或測試）
• 質量控制（即“白盒”測試，尋找潛在的錯誤）

這很常見嗎？沒有那麼多。

超出此範圍的想法是避免將人員視為單點故障。當然，這是有代價的，程序員會為此付出代價。這就是為什麼您的老闆很難說服這是一個壞主意。他擁有所有優點，而您擁有所有缺點。

花費時間與其他程序員交流知識和實踐是有意義的。這可以通過查看，配對編程或其他適合您的方法來完成。我加入了22人的團隊，其中一位顧問（從那以後開始）就將大部分時間都花在了走廊上而不是編程上。他是團隊的膠水，團隊中至少有15個人可以從事我所做的程序。可能還有其他需要的東西，非正式的討論，咖啡機的知識交流.....

但這是有代價的。值得付出恕我直言，但如果每個人都在使用相同的技術，則成本不會太高。成本是沉重的通信開銷。這就是您應該與老闆交流的更多內容，因為他的想法本身並不壞。只是，他必須了解這是一項具有非即時獎勵的投資。

一旦一個人為一個新模塊準備了一個多月，然後休假，就在他離開之前，他告訴我們的老闆所有問題都解決了，它準備開始編碼。因此，在第二天的混亂中，我的老闆告訴我，下週我們必須完成這項工作，您能取下來嗎？

您那裡有個經理不理他。

是的，對於每個開發人員，在每個單獨的任務（包括對新模塊的設計進行哈希處理）上，應該至少與他緊密合作（結對編程等）。

但這與說切換中途沒有開銷的說法不同：
應該是相同的開銷，或者理想情況下要少一些，就好像原始開發人員放棄該任務時沒有綁鬆散的一端以處理緊急情況，然後在經過一周的其他工作後不得不再次加大工作量。

現在，如果您他們不是，不是他從事這項工作的人，而是只有他的筆記，無論筆記多麼好（這可能並不出色，或者考慮到您的描述更像是不存在的斑駁）， ply無法涵蓋您同事在當月制定的所有詳細信息。

這就像去醫院，花時間讓一位醫生仔細檢查您的病情並反複檢查，樣本，心電圖，放射線照相以及其他可能有用的東西，然後立即去給外科醫生治療，切勿讓兩者交流任何有用的東西。

如果您不是他的工作對象，您應該指出是哪個同事做的，並且還警告即使他接任的時間要比您容易得多，但仍然存在相當大的成本，因為他不是自己準備的人。

如果沒有其他人對此準備非常熟悉，您應該提到應該有，並且（取決於研究記錄的方式）您可能需要x％左右的價格（關於

最後，似乎是管理失敗：
團隊負責人必須與其他開發人員並製定了編碼標準，並開始實際進行結對編程，單元測試，代碼審查以及所有其他活動，以確保質量和在團隊中傳播知識。

他們的理由是，當每個人都對所有事情負責時，任何人休假時，其他人都可以/應該直接交換身分並掩蓋他/她，因此他/他可以隨時享受假期。

我知道一家公司（ Menlo Innovations）按照設定的時間表將“所有人”圍繞“每個”項目輪換。有一種方法可以使它起作用。

管理部門已將其設定為目標，但是完全放棄了進行使它起作用所需的責任。隨著更長的交貨時間，將需要雇用更多的人。他們可以通過證明長期結果來證明這一點，而不是被某個認為他是地球上唯一有能力對其特定項目進行編碼的專家的人質扣押。

真正的問題是試圖實施孤立地進行一些練習。他們應該考慮過免費的實踐，例如：團隊開發，測試，更詳盡的文檔，每日會議，以分享和使每個人都能快速了解其他人在做什麼。

我認為以下是一個平衡的結論，很不幸，有人只是不喜歡聽這個。我已收到一再要求刪除它們的請求。在民主世界中，每個聲音都應該被聽到。您不希望聽到這是一回事，但是試圖讓我保持沉默是另一回事，這不是很好的IMO。因此，我的結論又一次從我的OP中取消了。

結論

我認為現在是我們停止行動的時候了。討論並從此開始。經過仔細審查，我選擇了一個“建議建設性解決方案的建設性答案” 作為答案。但實際上，所有答案都很好，希望我可以選擇多個答案。

從答案中，我意識到這是一個頗具爭議的話題，這讓我大開眼界，因為在此之前，我一直以為老闆是無知的。現在我意識到我以前是一無所知。

正如帕特里夏·沙納漢（Patricia Shanahan）所說，“開發人員和管理人員在從個人代碼所有權到共同責任的頻譜上都擺出了極端對立的立場”。 /評論來自經理：

• “經理應該總是能夠要求其他人在度假時為開發者服務”
• “我認為問題的核心是，您應該開始更多地以團隊合作。”
• “您需要做的事不涉及您的經理” / em>
• “團隊需要找到一種方法來使用代碼審閱，設計審閱，結對編程以及一般的方式來共享這些知識，彼此交談”

在做出這樣的結論之前，請再次考慮以下事實， 那個傢伙準備了一個多月，但從未與其他人分享他的發現，現在我的項目經理希望我在沒有任何先驗知識的情況下拿起它，並在一周之內完成它。而且，對於我們提交休假請求，我們至少需要一個月的時間，而更經常的是，我們在休假前兩三個月提交該請求。由此，我相信每個人都會知道問題出在哪裡。我完全同意TripeHound的觀點，

可能比“團隊需要...”更重要的是“管理層需要允許團隊...”，並接受會有重大打擊

承認與否，真正的問題已由gazzz0x2z指出：”這是有代價的，程序員要為此付出代價。這就是為什麼您的老闆很難說服這是一個壞主意。他擁有所有優點，而您卻有所有缺點” ，我個人同意RemcoGerlich，“如果管理人員要求這樣一個過程的結果，沒有先投入資金來實施它，他們就變得不現實” ，因為畢竟，正如沒有人理解的那樣，“在一段時間內不看代碼甚至需要重新理解自己的代碼，因此當然，了解別人的知識也需要時間。而且，您只能將很多東西塞進腦袋：學習別人的東西不會持續很長時間，這是一個實際的限制o分擔代碼責任” ，“如果所有管理團隊也都可以交換工作，那將是件好事。” 。

好吧，我知道我把它推得太遠了，這裡的大多數經理可能不同意我的看法。因此，讓我強調一下，這些是我自己的個人觀點，讓我們結束討論並繼續前進。這也是我選擇一個“建設性答案，提出建設性解決方案” 作為答案的主要原因-經理和開發人員需要更好地相互理解，而往往是經理們需要更好地了解開發人員。有了這樣的理解和建設性的解決方案，我們將在那裡，只是不會一overnight而就。

我在這家軟件公司工作，有趣的是，到目前為止，我只經歷過兩位經理，但是這兩位經理對編程工作的看法與打磚塊沒有太大區別。他們總是強調，你們應該隨時擔任彼此的工作。

那是一個完全荒謬的概念。編程是一個高度專業化的領域，並且編程的不同方面需要千差萬別的技能。您能做的最好的就是向他們指出。儘管與其他職業的類比可能是禮貌和合體（裁縫剪頭髮等），但您的老闆可能不相信它們，因此請指出編程方面的一些巨大差異，例如，UI設計與性能測試的差異。 / p>

但是，是的，您一定要設法消除經理的想法，以免當他們發現自己有多大錯誤時，他們會感到非常刺耳。

您可以標準化編碼約定，工具，文件夾和處理方式。但是，您不能使它等同於有關某些內在函數以及某些代碼部分如何工作的知識。只有那些花費數小時思考的人才擁有。向您的老闆解釋說，它根本不是在砌磚，我必須要對付這些無知的老闆，他們來自建築領域，並嘗試在軟件行業使用相同的標準，我無法向您解釋這會導致重大災難，失敗的項目和優秀開發商的高營業額。向他們解釋。每一件作品都有其自己的工作方式，並且特定於業務需求。例如，您有一個“磚”可以執行一些加號運算，另一個可以進行除法和除法運算，有一天，有人要求微分或矩陣函數演算，您可以將這種“磚”與上一個進行比較嗎？對新矩陣演算進行編程的人有時間分享其知識，並且同時保持計劃時間？我不這麼認為。