Small Team, Big Project
-
I'm on a team of two developers. We will soon be programming a large web application from scratch. Right now we're just working on the specifications. We still need to get the hardware in place for our new development, staging, and production environments. We're going to program with Microsoft Visual Studio 2005 and probably use Microsoft Visual Source Safe 2005. Would Microsoft Project be useful for us to keep track of our progress and as a bugs database? What else would anyone here recommend to a small team starting a large project? Thank you for any advice!
first, don't use Visual SourceSafe, change that to SubVersion, it's free, and it's a whole lot bettern than VSS. Project is usefull, but you need to have a 3rd person to use it, me think that if you are both doing code, estimating time; the pressure to re-evaluate and change the tasks accordingly without really thinking about it will bring a mess. As for bug tracking system, I like Mantis ( http://www.mantisbt.org/ ) or similar type of web based systems.
Maximilien Lincourt Your Head A Splode - Strong Bad
-
I'm on a team of two developers. We will soon be programming a large web application from scratch. Right now we're just working on the specifications. We still need to get the hardware in place for our new development, staging, and production environments. We're going to program with Microsoft Visual Studio 2005 and probably use Microsoft Visual Source Safe 2005. Would Microsoft Project be useful for us to keep track of our progress and as a bugs database? What else would anyone here recommend to a small team starting a large project? Thank you for any advice!
zjspeed wrote:
Would Microsoft Project be useful for us to keep track of our progress
Nope. IMHO Project comes with way too much overhead for a small team to worry about. Since you are a small team you need to use that to your advantage and manage you time fairly efficiently, and I just don't think project fits into that. For bugs look into FogBugz[^], it is pretty decent. For task management look for something simple like ToDo List[^] or Gemini[^]. I hope this helps. [EDIT] Oh, avoid SourceSafe like the bird-flu. It really shows it considerable warts when projects get big and include considerable media assets. Consider subversion or something else.
My Blog A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. - -Lazarus Long
-
I'm on a team of two developers. We will soon be programming a large web application from scratch. Right now we're just working on the specifications. We still need to get the hardware in place for our new development, staging, and production environments. We're going to program with Microsoft Visual Studio 2005 and probably use Microsoft Visual Source Safe 2005. Would Microsoft Project be useful for us to keep track of our progress and as a bugs database? What else would anyone here recommend to a small team starting a large project? Thank you for any advice!
zjspeed wrote:
What else would anyone here recommend to a small team starting a large project?
Multiply your estimates by PI. Write unit tests. Don't code to the specifications. Code to an abstraction of the specifications, so when the user changes the requirements, you don't rewrite the entire app. Document your procedures. Not the code procedures! (Well, document those too). Document how you do things, like testing, bug reporting, handling schedule slips, communicating to the client, updating source control (God, don't use VSS), moving the website to your staging area, then your production area, basically, write down your procedures for things you do all the time so they can be done consistently and so the new guys know what to do (there will be new guys) and write down your procedures for the stuff you do so infrequently you forget how. And start a journal of your daily activities, conversations with the client, internal decisions, etc. Damn. I wish I followed my own advice! Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
zjspeed wrote:
What else would anyone here recommend to a small team starting a large project?
Multiply your estimates by PI. Write unit tests. Don't code to the specifications. Code to an abstraction of the specifications, so when the user changes the requirements, you don't rewrite the entire app. Document your procedures. Not the code procedures! (Well, document those too). Document how you do things, like testing, bug reporting, handling schedule slips, communicating to the client, updating source control (God, don't use VSS), moving the website to your staging area, then your production area, basically, write down your procedures for things you do all the time so they can be done consistently and so the new guys know what to do (there will be new guys) and write down your procedures for the stuff you do so infrequently you forget how. And start a journal of your daily activities, conversations with the client, internal decisions, etc. Damn. I wish I followed my own advice! Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithMarc Clifton wrote:
Damn. I wish I followed my own advice!
;) Heck, if only it was as easy to follow as it is to give out...
---- I just want you to be happy; That's my only little wish...
-
I'm on a team of two developers. We will soon be programming a large web application from scratch. Right now we're just working on the specifications. We still need to get the hardware in place for our new development, staging, and production environments. We're going to program with Microsoft Visual Studio 2005 and probably use Microsoft Visual Source Safe 2005. Would Microsoft Project be useful for us to keep track of our progress and as a bugs database? What else would anyone here recommend to a small team starting a large project? Thank you for any advice!
I recommend using SubVersion instead of VSS. If you don't feel like managing your own SubVersion server, you can use a hosted one. I've been pretty happy with HostedProjects.com[^]. (I don't have any affiliation to them). /ravi
Just say "No" to Celcius Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com
-
zjspeed wrote:
What else would anyone here recommend to a small team starting a large project?
Multiply your estimates by PI. Write unit tests. Don't code to the specifications. Code to an abstraction of the specifications, so when the user changes the requirements, you don't rewrite the entire app. Document your procedures. Not the code procedures! (Well, document those too). Document how you do things, like testing, bug reporting, handling schedule slips, communicating to the client, updating source control (God, don't use VSS), moving the website to your staging area, then your production area, basically, write down your procedures for things you do all the time so they can be done consistently and so the new guys know what to do (there will be new guys) and write down your procedures for the stuff you do so infrequently you forget how. And start a journal of your daily activities, conversations with the client, internal decisions, etc. Damn. I wish I followed my own advice! Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithMarc Clifton wrote:
Code to an abstraction of the specifications, so when the user changes the requirements, you don't rewrite the entire app.
Thats great advice Marc! Lately I've taken to a mantra of something like: "Figure out what is going to change and abstract it." It's save me a lot of time last month dealing with a new client who was very uncertain about what they wanted to get done.
My Blog A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. - -Lazarus Long
-
zjspeed wrote:
What else would anyone here recommend to a small team starting a large project?
Multiply your estimates by PI. Write unit tests. Don't code to the specifications. Code to an abstraction of the specifications, so when the user changes the requirements, you don't rewrite the entire app. Document your procedures. Not the code procedures! (Well, document those too). Document how you do things, like testing, bug reporting, handling schedule slips, communicating to the client, updating source control (God, don't use VSS), moving the website to your staging area, then your production area, basically, write down your procedures for things you do all the time so they can be done consistently and so the new guys know what to do (there will be new guys) and write down your procedures for the stuff you do so infrequently you forget how. And start a journal of your daily activities, conversations with the client, internal decisions, etc. Damn. I wish I followed my own advice! Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
I'm on a team of two developers. We will soon be programming a large web application from scratch. Right now we're just working on the specifications. We still need to get the hardware in place for our new development, staging, and production environments. We're going to program with Microsoft Visual Studio 2005 and probably use Microsoft Visual Source Safe 2005. Would Microsoft Project be useful for us to keep track of our progress and as a bugs database? What else would anyone here recommend to a small team starting a large project? Thank you for any advice!
How muche time did you estimated from the beginning of the project to it's implementation in the production environment? This will define the sacrifice/benefits relation. If you are two persons I could suggest the application in a low level of an Agile methodology maybe? It is not a direct answer to your question, but I am absolutely sure that reading about that could tell you much more usefull tips to manage those type of projects now and for the future. It's all about beeing a better professional right? :~ Hope it helps :)
-
zjspeed wrote:
What else would anyone here recommend to a small team starting a large project?
Multiply your estimates by PI. Write unit tests. Don't code to the specifications. Code to an abstraction of the specifications, so when the user changes the requirements, you don't rewrite the entire app. Document your procedures. Not the code procedures! (Well, document those too). Document how you do things, like testing, bug reporting, handling schedule slips, communicating to the client, updating source control (God, don't use VSS), moving the website to your staging area, then your production area, basically, write down your procedures for things you do all the time so they can be done consistently and so the new guys know what to do (there will be new guys) and write down your procedures for the stuff you do so infrequently you forget how. And start a journal of your daily activities, conversations with the client, internal decisions, etc. Damn. I wish I followed my own advice! Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithMarc Clifton wrote:
Multiply your estimates by PI
It's funny because it's true. ;P
www.IconsReview.com[^] Huge list of stock icon collections (both free and commercial)
-
first, don't use Visual SourceSafe, change that to SubVersion, it's free, and it's a whole lot bettern than VSS. Project is usefull, but you need to have a 3rd person to use it, me think that if you are both doing code, estimating time; the pressure to re-evaluate and change the tasks accordingly without really thinking about it will bring a mess. As for bug tracking system, I like Mantis ( http://www.mantisbt.org/ ) or similar type of web based systems.
Maximilien Lincourt Your Head A Splode - Strong Bad
-
I'm on a team of two developers. We will soon be programming a large web application from scratch. Right now we're just working on the specifications. We still need to get the hardware in place for our new development, staging, and production environments. We're going to program with Microsoft Visual Studio 2005 and probably use Microsoft Visual Source Safe 2005. Would Microsoft Project be useful for us to keep track of our progress and as a bugs database? What else would anyone here recommend to a small team starting a large project? Thank you for any advice!
Make sure that you sleep enough. I'm not kidding. Your work will suffer (as will you) if you don't get enough shut-eye. :zzz:
:josh: My WPF Blog[^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - Aristotle -
zjspeed wrote:
What else would anyone here recommend to a small team starting a large project?
Multiply your estimates by PI. Write unit tests. Don't code to the specifications. Code to an abstraction of the specifications, so when the user changes the requirements, you don't rewrite the entire app. Document your procedures. Not the code procedures! (Well, document those too). Document how you do things, like testing, bug reporting, handling schedule slips, communicating to the client, updating source control (God, don't use VSS), moving the website to your staging area, then your production area, basically, write down your procedures for things you do all the time so they can be done consistently and so the new guys know what to do (there will be new guys) and write down your procedures for the stuff you do so infrequently you forget how. And start a journal of your daily activities, conversations with the client, internal decisions, etc. Damn. I wish I followed my own advice! Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
it's not a problem, there are some solutions available. Tortoise integrate SubVersion in Windows Explorer. Ankh integrate into VS2005
Maximilien Lincourt Your Head A Splode - Strong Bad
-
I'm on a team of two developers. We will soon be programming a large web application from scratch. Right now we're just working on the specifications. We still need to get the hardware in place for our new development, staging, and production environments. We're going to program with Microsoft Visual Studio 2005 and probably use Microsoft Visual Source Safe 2005. Would Microsoft Project be useful for us to keep track of our progress and as a bugs database? What else would anyone here recommend to a small team starting a large project? Thank you for any advice!
I'd stay away from VSS, but that's not from experience. I've just hear a lot of bad things about it. If you want a cool little project management tool that is simple to use and manage I would go with basecamp[^]. It's a free web based tool that has a todo list, tracks milestones, and has simple blog like messaging capabilities.
-
How muche time did you estimated from the beginning of the project to it's implementation in the production environment? This will define the sacrifice/benefits relation. If you are two persons I could suggest the application in a low level of an Agile methodology maybe? It is not a direct answer to your question, but I am absolutely sure that reading about that could tell you much more usefull tips to manage those type of projects now and for the future. It's all about beeing a better professional right? :~ Hope it helps :)
siskhoalanka wrote:
How muche time did you estimated from the beginning of the project to it's implementation in the production environment?
Apparently only one pith the time I should have! :)
Marc Clifton wrote:
Multiply your estimates by PI.
I estimate 2 - 3 months to production, then after that, regular improvements and feature additions indefinitely.
-
zjspeed wrote:
Would Microsoft Project be useful for us to keep track of our progress
Nope. IMHO Project comes with way too much overhead for a small team to worry about. Since you are a small team you need to use that to your advantage and manage you time fairly efficiently, and I just don't think project fits into that. For bugs look into FogBugz[^], it is pretty decent. For task management look for something simple like ToDo List[^] or Gemini[^]. I hope this helps. [EDIT] Oh, avoid SourceSafe like the bird-flu. It really shows it considerable warts when projects get big and include considerable media assets. Consider subversion or something else.
My Blog A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. - -Lazarus Long
I'll look into FogBugz.
Chris Austin wrote:
For task management look for something simple like ToDo List[^] or Gemini[^].
I have used an old version of Gemini once before and it was okay, but seemed to be lacking. Do you use ToDoList? Does it allow two (or more) people to collaborate? Can we check the progress of the other? Can we divide and assign tasks to each other? Is the data stored on a central server?
-
I'm on a team of two developers. We will soon be programming a large web application from scratch. Right now we're just working on the specifications. We still need to get the hardware in place for our new development, staging, and production environments. We're going to program with Microsoft Visual Studio 2005 and probably use Microsoft Visual Source Safe 2005. Would Microsoft Project be useful for us to keep track of our progress and as a bugs database? What else would anyone here recommend to a small team starting a large project? Thank you for any advice!
Microsft Project is a bit of an over kill for software projects. I used it once, but I ended up just doing really small project plans, then I just gradually stopped using it, as it was just as easy to use a white board and marker :-)
Kind Regards, Gary
My Website || My Blog || My Articles
-
I'm on a team of two developers. We will soon be programming a large web application from scratch. Right now we're just working on the specifications. We still need to get the hardware in place for our new development, staging, and production environments. We're going to program with Microsoft Visual Studio 2005 and probably use Microsoft Visual Source Safe 2005. Would Microsoft Project be useful for us to keep track of our progress and as a bugs database? What else would anyone here recommend to a small team starting a large project? Thank you for any advice!
I work as part of a 2 man team managing largeish web apps - previously I have managed teams of upto 10 developers, so this advice is based on experience. MS Project management software is only really useful if a project is likely to take over 6 months to complete + has lots of resources to manage, otherwise it can just add more red tape and admin nightmares... As a small team, we currently use Gemini from http://www.countersoft.com/[^] as it provides us with fault logging, version handling and resource allocation without being to formal. WE have also found implementing the dotnetnuke http://www.dotnetnuke.com/[^] framework invaluable, it provides several features which can be a real pain to implement in web apps: - User access\login - Fault logging - Page management + menu's - Portal specific skinning, so incoming companies can apply branding - Internationalisation - Is easy to implement .net classes with access to solid web classes Anyway that works for us :)
-
Make sure that you sleep enough. I'm not kidding. Your work will suffer (as will you) if you don't get enough shut-eye. :zzz:
:josh: My WPF Blog[^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - Aristotle -
I'm on a team of two developers. We will soon be programming a large web application from scratch. Right now we're just working on the specifications. We still need to get the hardware in place for our new development, staging, and production environments. We're going to program with Microsoft Visual Studio 2005 and probably use Microsoft Visual Source Safe 2005. Would Microsoft Project be useful for us to keep track of our progress and as a bugs database? What else would anyone here recommend to a small team starting a large project? Thank you for any advice!