How to work with a team?

Hi all!

I've never worked with someone on a project before. Can anyone tell me how to add people to a project, and how to use the team explorer? I know this is a very general question, so I'd appreciate any help I can get!

Thanks.

Nic

I moved this over to General Developer from .NET because I think you'll get better answers here. For one thing, the General Developer forum gets less churn, so the question stays prominent longer. Furthermore, it really is a general question. Team Explorer isn't so general, as it is VS, but I expect that the question is about more than just that.

Eyes front, mouth shut, dream of cool water and lean into the harness.

Attachment 137945

Teamwork!

How strange that you would post that picture. It appears to be a picture of a 20-mule train pulling borax from the mines in Death Valley. I was just down there.

Quote:

---

I've never worked with someone on a project before. Can anyone tell me how to add people to a project, and how to use the team explorer? I know this is a very general question, so I'd appreciate any help I can get!

---

You really need to be using some sort of source control to have multiple users working on the same project.

If all of you are on the same network then there are a number of source control providers you can use, for instance TFS, Subversion & GIT to name but a few

If you are all working in separate places then maybe GitHub which is a free web based source control maybe the answer.

Just some of the reasons you absolutely need to have Source Control to work on a shared team project are, firstly it ensures that everyone is working from a single set of source code which you are all making changes to, secondly it allows all the users to check in changes centrally to that same single source code, so any changes made by any team member can then be pulled down by the other team members.

Without it you will all be working on different sets of source code and you would find it incredibly difficult (to the point of being neigh on impossible the longer you are working on your project) to merge the changes you do together into a single project further down the line.

I thought GitHub was moving to a paid model with multiple pricing tiers? Did I read that wrong?

GitHub is a mix of strategies. In this case, I think you are right that it would end up being paid. It's still free for open source and in some other scenarios. We can use it for free for some things because they are not for profit or free, but we also have a commercial version for some other software....though I'm only on the periphery of that one, so I'm not sure what is free and what is not. It's not as simple a model as it used to be, though.

Ah i didn't know they had changed the payment model.

So public repos (which anyone can see) are still free but private repos now cost a monthly fee.

BitBucket is however still free for small teams of up to 5 people for both public & private repositories.

GitHub has always used a paid model. Nothing* has changed.

Public, open-source repositories: free
Private, non-open-source repositories: monthly fee

* In the past, they charged on a per-private-repository basis, but they've recently moved to an unlimited repository model, so you can pay a flat rate for unlimited private repositories. (Note that enterprises also benefit from the new move to unlimited repositories, but they still have per-user fees.) This is actually a simplification of their previous model.

Well, if you want to manage a team with TFS, buy some good single malt, or whatever else helps you dull the pain. Here's the process we went through at my last job to adopt it. It was really painless.

1. Pay for a consultant to spend several days with us, evaluating our needs and examining our development process to determine if the product can fit our needs.
2. When he agrees we look like a perfect fit, negotiate MSDN Universal licenses for every developer. It used to be about $10k/seat, but the price has dropped dramatically.
3. Buy some new servers so they can host TFS. Pay for training so IT can install and administrate our TFS servers.
4. Hire a consultant to train employees.
5. Have a lot of issues and growing pains. Hire consultants to help customize TFS to fit our development process.
6. 2 weeks and a few ten thousand dollars later: "Uh, well, TFS isn't compatible with your development process. This is how Microsoft uses it, we think if you switch to that process you'll stop having issues."

A few million dollars later, it sort of worked.

Everything else tends to be a bit easier. You have two choices when it comes to source control, and several implementations of each choice.

Centralized models include TFS, Perforce, SVN, and CVS. These are most popular with Microsoft, small single-office businesses, and developers in the early 1990s. In these source control models, you need one specific machine to be "the server". Clients download small bits of what exists on the server, make their updates independently, then have to get in sync with the server and send changes back. This works OK with small teams in one location. It gets tough if some people work remotely, as any loss of connectivity with the server can mean those people can't commit code.

Distributed models include Mercurial, Git, and a handful of others. These are more popular with everyone who isn't a VB developer. In this model, each machine has a full history, and each machine is a 'server' in its own right. You still tend to pick one machine to be "the" server for sanity, but if it breaks or goes down, you can very quickly shift development to another one. If someone works remotely, and only visits the office once a week, they can still easily sync up and get work done detached from the main database.

I don't suggest you take any advice further than that from an internet forum, especially a VB forum. There's books about team management with source control, and if you look really hard you can find training consultants who are worth the money. You have to find a process that works for you, and some systems are better suited for certain processes.