超輕軟件開發過程

有關開發過程到目前爲止，我已經參與其中，最具有單個成員，或偶爾兩個隊。超輕軟件開發過程

我們用蟒蛇+的Django的主要研製，開發的過程實際上是非常快的，我們也有代碼審查，設計模式的討論，並不斷重構。

雖然團隊規模很小，我覺得有一些開發流程/可能被強制執行的最佳做法。例如，使用svn肯定會比普通的複製備份更好。

我讀了一些文章&關於敏捷，XP &的書不斷整合，我認爲他們很好，但對於這種情況（團隊1或2，以及快速編碼）仍然過於沉重。例如，IMHO，具有漂亮的設計圖案，並且迭代開發+重構，所述TDD可能是一個矯枉過正，或至少開銷不出重量的優點。結對編程也是如此。自動化測試是一個不錯的主意，但對於每個項目來說，在技術上似乎都不可行。

我們目前的做法是：

SVN +里程碑+代碼審查

我不知道是否有開發流程/最佳做法，專門針對這種超輕隊？

來源

2010-05-30 Walty Yeung

使用某種形式的源代碼修訂控制是強制性的（即使是1個人單獨工作） – 2010-05-30 03:30:25

唯一的情況是我可以看到TDD過度使用是快速項目，你必須在一個小時內完成或簡單的原型。單個開發人員項目可以像TDD一樣受益於大型團隊項目。 TDD與軟件設計有關，並且與團隊規模無關。 – 2010-05-30 03:39:36

嗨傑夫，感謝您的評論。我不得不承認，我從來沒有真正實施過TDD。我不使用它們的原因是： 1.用戶需求不斷變化，這明確打破了之前測試集的迴歸測試。 2.假設在重構過程中使用了不錯的設計模式，實際上在最終發佈階段可以捕獲的錯誤實際上非常有限。 TDD似乎是一種浪費。所以我認爲只有當項目足夠大並且應該在不同開發者之間轉移時才使用TDD。 – 2010-05-31 02:24:12

你想有兩個源頭控制，這樣你就可以撤消更改你現在後悔，並某種故事或工作項目或請求，或者無論你怎麼稱呼它們在您的工作流程變更的連接。隨着時間的推移，這將讓您回答爲什麼您對代碼做了特定的更改，或者探索特定決策所需的代碼更改。像這樣的探索將有助於您在未來做出更好的決策。你可能還需要管理你的積壓/待辦事項清單/客戶的請求/高見，如果直接連接到你的源代碼控制，那就更好了。

來源

2010-05-30 03:33:22

超輕軟件開發過程

回答

相關問題