Sorry if this is a duplicate, but the search terms for the questions are pretty general.
I work in a small (ish) development company. I say a little, but the company is actually fair. however, I am only the second full-time developer, since most of the past work has been organized around contractors.
I am able to define the internal project process and policies - the obvious things, such as SCM and unit testing. The methodology is beyond the scope of the document that I am compiling, but I would really like to push us in a more compact (and perhaps even Agile?) Direction.
I feel that I have many recommendations for good practice, but not enough motivation to make my document a guide to the spirit that I would like. I divided the document into “principles” and “recommendations”. The recommendations were easy to make. Use SCM, aim for one-stage, regularly scheduled assemblies, unit test first, document how you go ... Listing the principles that should have provided these recommendations, however, was rude.
I came up with “tools for us, we should never work on tools” and a vague article aimed at our QA (which was too tame), which I would like to read “tedium is the root of all evil”.
I do not want to miss an opportunity with this document to give us a good start and even push us to Agile. What principles am I missing?
EDIT 4/15 -
Perhaps I was ambivalent about the scope of this document. At the moment, this is a policy with which I will cooperate, and I plan to follow. Until now, we have been given free possession of the choice of a local tool, source control, etc., as well as the general process that we carry out during the development process (for example, assembly, deployment, use of continuous integration ...).
Ideally, I would also like this document to be a model on which further improvements to the process could be improved. I mainly think about QA and maybe push our project management to something easier and more iterative.