在團隊和/或大型項目中工作時，我是敏捷方法的主要倡導者。獨立工作小項目：牛仔編碼的方式去？
但是，我發現，對於較小的項目，單獨工作時，我通常會開始編寫單元測試項目，廣泛記錄重構。隨着時間的流逝，我停下來，因爲我覺得我在浪費時間。我發現牛仔編碼敏捷（經常測試，編寫人類可讀代碼）對我來說非常適合小型獨立項目，我不希望其他人需要使用這些項目。
其他人分享我的感受？或者你認爲那個人不應該堅持他們的槍（得到它？牛仔）？
所以真正的問題：是否有任何敏捷的方法是特別適合獨奏項目？ （除了我上面的「敏捷牛仔」方法）
敏捷是一種哲學而不是處方。您使用符合您的開發風格，項目和業務需求的作品。
我認爲你的「經常測試，寫出人類可讀代碼」的建議是一個非常適合在小型項目的獨奏團隊中製作優秀軟件的方法。
牛仔編碼和敏捷過程是不一樣的。
至於小型個人項目，當然有很多東西會過度殺傷。敏捷開發，簡短的迭代，頻繁的代碼審查和自我記錄代碼是最好的選擇。
我承認，當我進入這種模式時，我犯了很長的迭代。我通常趕在自己之前，爲時已晚。 – snicker 2009-08-21 21:35:40
你可能想看看c2.com的Solo Programming Xp Workarounds。 Cardboard Programmer是由於某種原因，我覺得特別有趣。你也許可以用旁邊的紙板Jon Skeet編碼？
我在這裏聞到美妙的商機。誰是第一個與Jon達成獨家協議的人？ ;） – 2009-08-21 21:18:48
不要忘了橡皮鴨：http://c2.com/cgi/wiki?RubberDucking – 2009-08-21 21:33:00
我曾經和狗談過，實際上，所以我覺得這是有效的。 – snicker 2009-08-21 21:34:37
我目前正在獨立ASP.NET項目（雖然不是一個小）。我使用TDD相當多，而且我發現開發TDD的時間並不長，實際上我節省了時間。
這主要是因爲擁有一套單元測試可以非常快速地測試和調試系統。例如。當一個功能沒有按照預期工作時，將調試器附加到NUnit進程上要快得多，而不是以調試模式啓動Web服務器，導航到正確的頁面（首先通過登錄屏幕）等。所以沒有單元測試，我會花費更多的時間進行測試和調試。
單元測試還幫助我創建一個設計良好的系統，因爲它迫使我創建更鬆散耦合的設計。
我會說在項目中工作的人數不是唯一需要考慮的因素。我認爲你找到完整的敏捷（文檔，重構，單元測試..........這些可能不是真的敏捷，但他們已經存在了很長時間）的原因是時間浪費是因爲獨立項目往往是小項目。
對於跨越半年以上的大型項目，我真的希望正確的過程能夠真正幫助自己。你可能會訪問你5個月前寫的一些代碼。沒有文件，就和其他人的工作一樣。如果沒有測試，你就像改變其他人的代碼一樣害怕改變它。
雖然它必須有一定的靈活性，但遺漏掉某些敏捷是完全瘋狂的。如果你不重構，你只是把所有的設計都扔出窗外。如果你不測試你不能正確重構。敏捷就像一個輪子，其中一種做法經常使下一個 - 打破鏈條，它全部崩潰 - 然後敏捷被指責。 – 2009-08-21 23:20:58
我不同意你的說法：「遺漏某些敏捷是完全瘋狂的」。事實上，我認爲這種看法在某種程度上是有害的。每個組織和項目都會有特定的需求，評估哪些工具和技術可以幫助您達到目標很重要。幸運的是，重構是更容易選擇的方法之一（這也許就是爲什麼你認爲把它放在一邊是愚蠢的原因），所以大多數敏捷項目確實爲某種定期重構工作騰出時間。 – 2009-08-22 10:42:40