I work for a small company. The software development arm of the company before I was hired consisted of one self-taught overworked guy. Now that I've been writing software for the company for a few years, I have been tasked with establishing formal company-wide software development practices. We currently have no guidelines, other than
Write code, test it, put it in a .zip file and send it to the client. Bonus points for TDD and version control.
My boss wants me to write a software developer's handbook which defines the general processes, protocols, tools, and guidelines we use to get things done. In other words, he wants a "This is what we do here" book to make it easier to get a new employee familiar with the way we do things, as well as to help my boss understand what his minions are doing and how they do it.
The way I see it, I'm laying a foundation and it needs to be done right. How would you go about choosing topics for such a handbook? Can you provide some example topics?
Side Note: If it matters, we are primarily a Microsoft .NET shop. And we are looking at agile practices such as XP and Scrum, but we may have to heavily modify them to make them work in our company.
Best Answer
I would break it down into sections like
Making it modular will also let you or others update pieces separately, for instance the employees names and positions will change frequently as people come and go.
For each section I'd try hard to write it from a 'newbie' point of view. Most important will be making sure it really makes sense to a newbie. Your boss obviously is not the right person to review this as he is not the intended audience. He's right to want it, just make sure the content doesn't end up being tested by him. Also a 'newbie' both only has "1 week" as being a newbie... and only has one point of view. So it's likely (and recommended) that the document will be refined with each new employee. In fact it's a pretty good task to also assign them for their first week, i.e. "Update the newbie manual".
For Agile/SCRUM:
The hardest part of doing Agile and SCRUM is 'really' doing it.
For reading I would start at http://agilemanifesto.org/ and go from there.
I would also read the well-known http://www.halfarsedagilemanifesto.org/ which adds weight to the fact that you really have to embrace all the aspects for it to work. If you have to heavily modify Agile for your organizations it's likely that people want the benefits - without using the correct processes. This fact itself should be presented to ward off any half-assyness.