How to organize the organization of the team development process?

Question

ASP.NET

Dear colleagues!
This fate fell on my hard fate: leading a team of 3-4 people (1 designer and 2-3 ASP.NET MVC developers) to create a new SaaS project from next week.
Everything is fine, but it will be a completely new experience for me, since before I always worked as an ASP.NET MVC developer under the guidance of someone. Therefore, probably, I can be called a team leader.
Our company is small, so I, as a manager, will have to take care of everything: organizing the development process, preparing the database server for development, setting up SVN, organizing a bug tracker, knowledge bases (I want to install TikiWiki CMS Groupware), choosing a development methodology (I want to ask TDD), control of the development process and development itself. (Administrative matters are likely to get help, of course.)
There are a lot of things to think about and organize. The list above, I'm sure, is not even complete. The project is scheduled for six months.
In connection with all the above written, I ask for the help of the community. I would be very grateful to those who share their experience. Please advise any resources, articles, videos and other materials that could somehow help.
I will explain any missing details or what is not clear.
Thanks a lot!

Answer 1

The main thing to remember is that effective management is the creation of conditions, and not constant interference in operational activities.

Answer 2

Your team is very small. So no need to sweat. All issues in such a team can be resolved personally, just by talking. Your tasks as a leader:
1. So that each developer has a clear task and an understanding of how to complete it.
2. Control execution by simply reading the code that developers issue.
If you do not like something in the performance - talk to the performer. But only about specific shortcomings. No need for any theories like "this is not OOP" and "this is not how TDD is done." There are only requirements for the task and the degree of their implementation. Everything else is from the evil one. You work with people, not with theories. Use their strengths instead of forcing them to do something they obviously can't do. So if a particular developer has, for example, an individual intolerance to TDD, then ask yourself: do you need a developer or TDD?
So the choice of development tools and methodology for the team is not your sole decision. You are not the boss. You are just a coordinator. So coordinate your developers.

Answer 3

I have a similar command.
deployed Trac + Hg, jenkins autobuild server, CI,
pulling up the TDD team.
I do not recommend bringing your company's commercial project to public repositories, it's better to raise your server, business for three or four days.
On TDD and its implementation in the team, I recommend reading and listening to Roy - Roy Osherove
There is no such case when "TDD is not suitable for someone", it simply means that you, as a leader, approached the person incorrectly.
With all sorts of SCRUM, etc. I recommend not to bother, with methodologies too.
If you're new to teamleading, read the classics:
- Mythical Man-Month by Brooks (pretty boring, but necessary)
- "The Human Factor. Successful Projects and Teams" by Tom DeMarco and Timothy Lister (Required Reading)

Answer 4

I highly recommend Trello. Connect the whole team and cut tasks on the virtual board. At every moment you see what and where is. And who does what. In general, everyone sees.
As a repository, BitBucket is convenient. Take GIT. It is perfect for your needs. + on Bitbucket closed repositories and you are only 3-4 people. Plus it's free.
Knowledge base needed. Write a document - coding rules to make it easier for the guys to interact with each other.