4
如果這是重複的，但是問題搜索條件非常通用，我很抱歉。我的機會塑造了我們的開發流程/政策
我在一家小型（ish）開發公司工作。我說小，但公司實際上是相當大的;然而，我只是第二個全職開發人員，因爲大部分過去的工作都是圍繞承包商進行組織的。
我可以定義內部項目流程和策略 - 比如SCM和單元測試等明顯的東西。方法論超出了我正在編寫的文檔的範圍，但是我真的很想將我們推向更精簡（甚至可能是敏捷？）的方向。
我覺得我有很多很好的實踐建議，但沒有足夠的堅實動機來讓我的文檔成爲我希望的精神指南。我已將文檔分成「原則」和「建議」。建議很容易想出來。使用SCM，爭取1步，定期安排構建，首先進行單元測試，隨時閱讀文檔......但列出應該通知這些建議的原則很粗糙。
我想出了「工具爲我們工作;我們不應該爲工具工作」和一個朦朧的條款針對我們的QA（這已經過度手動），我想讀「單調乏味是根所有邪惡「。
我不想錯過這個文檔的機會給我們一個良好的內部開始，甚至可能推動我們走向敏捷。我缺少什麼原則？
編輯4/15 -
我可能已經曖昧有關本文檔的範圍。目前，我的共同開發者和計劃遵循的政策是。到目前爲止，我們已經對本地工具，源代碼控制等的選擇以及我們在開發中所遵循的一般流程（例如構建，部署，是否使用持續集成等）給予了自由的統治。
理想情況下，我還希望這個文檔是一個模型，以進一步改進流程。我主要是在考慮質量保證，也許會讓我們的項目管理朝着更輕鬆，更迭迭的方向發展。
幫助我不完全理解你的文檔的範圍，但我有一個強烈的建議：由史蒂夫·麥康奈爾「代碼大全」。我認爲這是原則和建議的寶貴來源，在那裏你可能會發現你正在尋找的原則。 – 2010-04-14 22:15:36
在元層面上，我們需要了解貴公司的穩定性/可審計性要求，然後才能爲流程提供建議。 – 2010-04-14 23:09:04
@Paul穩定性/可審計性要求？如果你的意思是我們項目的穩定性 - 那麼我們不會製造火箭。我們做企業型軟件，網站開發和其他各種事情。我們需要保持穩定，使個人客戶感到滿意，並且每個產品都會發生變化。我注意到我們有時會遇到客戶期望的問題，但有些時候我們卻沒有。我不確定可審計性，但我沒有聽說過第三方審計。如果你的意思是內部的話，我想我們有點太小了。 – 2010-04-15 18:07:36