2 added 1 characters in body
source | link

I have been a sole developer on a few small projects off my own and have some industrial experience working with a large team. I have noticed that the techniques that a big company uses does not necessarily work for a small team. At one point I was doing more planning and documentation rather than writing code. I suggest that you try to find a good way of working first by trying different techniques (the other answers provide some great insight) and tools, this will cost you some time and effort but you will benefit from it later on. Some tools/ techniques I found to be useful were:

Pivotal-Pivotal Tracker - Great program for keeping track of stories and encourages breaking down -tasks, it is lightening quick at entering stories and automatically deduces velocity. https://www.pivotaltracker.com/.

-Gdocs for documentation as it is easy to have multiple users editing and discussing at the same time.

-At a company I used to work for we used to have a meeting for each and every story that we initiated, this meeting had to include a senior programmer since he would be better at judging how long a task would take. He would also be better at judging what the difficult part might be in a task.

In summary I believe that the key to working in small teams is to have a solid planning regime that is fast and fluid. Also any difficulties with the story can be identified early so that planning a task will keep that in mind (this could lead to building something differently).

Hope this helps

I have been a sole developer on a few small projects off my own and have some industrial experience working with a large team. I have noticed that the techniques that a big company uses does not necessarily work for a small team. At one point I was doing more planning and documentation rather than writing code. I suggest that you try to find a good way of working first by trying different techniques (the other answers provide some great insight) and tools, this will cost you some time and effort but you will benefit from it later on. Some tools/ techniques I found to be useful were:

Pivotal Tracker - Great program for keeping track of stories and encourages breaking down -tasks, it is lightening quick at entering stories and automatically deduces velocity. https://www.pivotaltracker.com/.

-Gdocs for documentation as it is easy to have multiple users editing and discussing at the same time.

-At a company I used to work for we used to have a meeting for each and every story that we initiated, this meeting had to include a senior programmer since he would be better at judging how long a task would take. He would also be better at judging what the difficult part might be in a task.

In summary I believe that the key to working in small teams is to have a solid planning regime that is fast and fluid. Also any difficulties with the story can be identified early so that planning a task will keep that in mind (this could lead to building something differently).

Hope this helps

I have been a sole developer on a few small projects off my own and have some industrial experience working with a large team. I have noticed that the techniques that a big company uses does not necessarily work for a small team. At one point I was doing more planning and documentation rather than writing code. I suggest that you try to find a good way of working first by trying different techniques (the other answers provide some great insight) and tools, this will cost you some time and effort but you will benefit from it later on. Some tools/ techniques I found to be useful were:

-Pivotal Tracker - Great program for keeping track of stories and encourages breaking down -tasks, it is lightening quick at entering stories and automatically deduces velocity. https://www.pivotaltracker.com/.

-Gdocs for documentation as it is easy to have multiple users editing and discussing at the same time.

-At a company I used to work for we used to have a meeting for each and every story that we initiated, this meeting had to include a senior programmer since he would be better at judging how long a task would take. He would also be better at judging what the difficult part might be in a task.

In summary I believe that the key to working in small teams is to have a solid planning regime that is fast and fluid. Also any difficulties with the story can be identified early so that planning a task will keep that in mind (this could lead to building something differently).

Hope this helps

1
source | link

I have been a sole developer on a few small projects off my own and have some industrial experience working with a large team. I have noticed that the techniques that a big company uses does not necessarily work for a small team. At one point I was doing more planning and documentation rather than writing code. I suggest that you try to find a good way of working first by trying different techniques (the other answers provide some great insight) and tools, this will cost you some time and effort but you will benefit from it later on. Some tools/ techniques I found to be useful were:

Pivotal Tracker - Great program for keeping track of stories and encourages breaking down -tasks, it is lightening quick at entering stories and automatically deduces velocity. https://www.pivotaltracker.com/.

-Gdocs for documentation as it is easy to have multiple users editing and discussing at the same time.

-At a company I used to work for we used to have a meeting for each and every story that we initiated, this meeting had to include a senior programmer since he would be better at judging how long a task would take. He would also be better at judging what the difficult part might be in a task.

In summary I believe that the key to working in small teams is to have a solid planning regime that is fast and fluid. Also any difficulties with the story can be identified early so that planning a task will keep that in mind (this could lead to building something differently).

Hope this helps