我已經開發了幾年了，並且對我的團隊中一些較老的程序員如何進行設計和實現沒有任何一種開發哲學感到沮喪，這通常會導致問題通常由於缺乏靈活性和驗證而進一步落後於發展軌道。我向同事們提出了這個問題，他們回答說：「那麼，您建議我們使用幾百種發展哲學中的哪一種？」開發團隊的開發哲學
這是一個難以回答的問題，因爲使用開發哲學時，自己工作比在團隊中工作要容易得多。我有點偏向測試驅動開發，因爲它似乎爲我提供了我的代碼工作正常的最大安全感，然而TDD確實有其侷限性，主要是在編寫所有測試所需的開銷以及確保我們的測試框架沒有差距（在團隊中工作時很難實現）。我的一位朋友發誓敏捷統一過程（AUP）拒絕使用其他任何東西。
我的問題是
你有沒有發現哪個發展理念在團隊開發時很好地工作，而且它們又是怎樣幫助您按時按預算交付您的產品？
你遇到了什麼問題，你是如何克服它們的？
你認爲他們甚至需要嗎？
作爲承包商，您可能沒有什麼影響力來影響特定公司的發展哲學變革。這是大多數公司認爲是臨時的價格的一部分。對於作爲一個人的你來說，有時你能做的最好的事情就是學習如何適應當前的企業文化，並學習什麼在你有影響力的時候起作用，什麼不起作用。
您總是可以自己做測試驅動部件，所以至少您知道您的代碼將通過測試。我不會將它視爲開銷，它是編寫代碼來測試它的一部分，以確保它能夠正常工作。沒有編寫測試有很多開銷。
如果一個地方沒有特定的開發方法，那麼有兩種方法可以獲得一個。首先，如果開發人員大多同意使用何種哲學，並且他們開始使用它，並展示管理工作並改進產品。開發人員非常自由地找出如何完成他們的工作，而不是其他許多專業特長。使用這個你的優勢。讓一羣志同道合的人聚在一起，並開始使用你們都同意的方法。灌輸在團隊中新成員的任何人的工作。顯示真正的進展和管理將會與它相結合（管理者喜歡任何讓他們看起來不錯的東西）。
改變企業文化的第二種方式是從上到下。改變一位高級經理的想法，他可以要求使用新的方法。這並不美妙，人們會爭取做到這一點（這就是所謂的抵制改變，這是一個正常的條件，你需要期待處理它。）再次建立一些成功，它變得更容易，但你的經理必須通過讓人們使用新方法的艱難階段來堅持政策，並且對於那些不遵循新方法的人必然會有後果。有時候有志願者參加一個測試項目，首先使用這種方法可以證明其他人的價值，有時候，人們只是枯燥無味，不管怎麼樣都不會改變。
經過一段時間和多次改變，仍然拒絕接受新政策的人們，無論他們作爲個人開發者有多好，都需要放手。如果你不能遵守團隊規則，你需要繼續前進或繼續前進。沒有每個人最終加入，文化的改變都是不可能完成的。
有時您可以使用外部影響力讓經理改變經營方式。我們在這裏改變了我們的整個開發流程，以獲得我們最大的客戶之一所要求的認證。 HIPPA和薩班斯 - 奧克斯利法律也負責許多公司正式確定開發流程。如果你能夠舉一個例子來說明，爲了獲得某種形式的認證或遵守法律而正式確定流程的好處是可以讓他們獲得更多的業務，那麼他們也許會突然看到價值。
它非常主觀的，但你需要在這些方法讀了，看看你的工作以某種方式處理比賽，然後利用改進的想法從所有方法的東西。所有團隊都不同，所有方法都根據工作性質，啓動，維護和運行項目的方式而有所不同。
與團隊交談，討論他們願意做什麼/改變，而不是試圖強加給他們。你會遇到接受和改變的問題。
關於溝通的一切，是的，這是必需的。
我的客戶使用各種方法（敏捷/ Scrum/XP等）。從我的角度來看，我沒有看到它們之間的性能差異。
但是，我發現使用這些方法的不同方面的團隊之間確實存在生產率差異。特別是持續集成（CI），TDD和創建/維護測試的意願，並經常/定期發佈。我一直在使用這些方法的團隊傾向於取得成功（不管他們稱之爲方法論，站立式會議等），還有那些不傾向於掙扎的團隊。我不清楚你是否使用這樣的方法（我不認爲你是這樣做的），而不是推一個方法論，我建議你介紹一些特殊的實踐（很可能是CI/TDD），並從那裏。我認爲這對你的同事來說會是一個簡單的避孕藥，並且提供最大的好處。當然，你必須執行TDD方法，並且我會讓管理層儘早購買。
可悲的是，布賴恩，目前我正在與一家公司簽訂協議，幫助他們的內部開發團隊完成他們的項目，除了某種特定的「設計和實施」之外，他們不使用任何方法，我們的測試框架是幾乎不存在（儘管我所有的抗議！）。因此，爲什麼這個項目會隨着時間的推移而跑，而且超出預算！ – link664 2009-09-08 08:14:55
作爲承包商，我總是問潛在客戶的問題是他們做什麼。測試和發佈。這是一個最明顯的問題，並表明該合同是否會成爲一個痛苦的世界:-) – 2009-09-08 08:34:21
需要多年的經驗才能真正理解方法的全部潛力（和侷限性），甚至需要更多的時間來理解何時使用什麼。
我認爲最快的方法是閱讀幾種哲學的粗略描述，選擇一種看起來最適合這種情況的方法，並且真的是那麼做。最重要的是要保持一個軌道。不要試圖混搭。堅持一個範例，並一路使用它。
此外，培訓同事並分享您的願景非常重要，以便他們真正理解爲何每個人都必須遵循這些原則。如果您已經知道這些缺點將會發生什麼，請分享它們，並確保您清楚說明方法的好處如何超過不利方面。不過，說起來容易做起來難，最重要的是要有一個開放的對話框，讓每個人都明白爲什麼和你在做什麼。
找出威脅到你的項目成功的風險，他們的優先次序，並攻擊首先使用短迭代是客觀地證明成功通過測試執行決議最嚴重的。
明確您的項目的目標，約束和架構，並確保團隊的每個成員都瞭解他們。
在迭代過程中糾正每個缺陷。
主要障礙始終是抗拒變化。以身作則。
這應該是一個非常主觀的維基。 – AnthonyWJones 2009-09-08 07:55:53
我如何使這個wiki？ – link664 2009-09-08 08:10:18
我打勾了社區wiki框，安東尼的意思是？ – link664 2009-09-08 08:12:12