32

You've written down a few pointers for them, but you haven't explained why is your approach better than the one they already use. This may be problematic. If you're in a spirit “We'll do it my way, because I have six years of professional experience, and you don't” (and reading your question, it looks exactly this way), be ready to be hated by your team ...


30

The "Product backlog Item" is indeed the What, the functionality that needs to be built. The Task describes the steps that need to be taken to get there. Many teams are not used to decompose into tasks, they just build what the spec says. For these people it's hard to see them as two separate things. Maybe a simple anecdote would help: See the ...


20

As per Microsoft on Review code with pull requests: Vote on changes the suggested purpose of each class of approval is: Approve with suggestions : Agree with the pull request, but provide optional suggestions to improve the code. Waiting for the author : Do not approve the changes, and ask the author to review your comments. The author should let you ...


17

Martin Fowler's little survey says a lot about the state of TFS in previous years. 'dangerous' is quite right. (I think this refers to the way that it doesn't recognise changes made outside of VS, so you can create a WCF project, then use the external svcutil tool to create your client, then check all your changes in.. but TFS will happily ignore your client ...


16

I am using this http://visualstudiogallery.msdn.microsoft.com/f3f23845-5b1e-4811-882f-60b7181fa6d6 Updates your title to for example: Development\myproject or Main\myproject or Release\myproject Hope it helps


16

For a team of 3-4 devs, you're proposing WAY too many branches. Every branch you create is additional overhead that comes with a cost (time spent merging, keeping track of what's where, etc). You need to make sure that the benefit you get from having a branch outweighs the cost. Keep in mind that the only real benefit to a branch is code isolation. ...


12

I've moved from a company with a largely Atlassian stack (and Mercurial) to a company with a heavy TFS stack. I find two irritations. The first is Source Control. When you've got used to DVCS, switching back to a CVCS is painful. TFS is particularly painful because, for all that integration to work, it insists on being connected to the server at all times. ...


12

You should create a new repo for each independent project. Why? Someone working on project D does not have to download all the history for E and F. Git repos are cheap to initialize, so you can use as many as you like. It is painful to work with multiple projects at once when they are represented as branches in a repo: When switching from A to B to quickly ...


12

In Git, the basic model for pre-commit code review is to have a branch somewhere where it can bee reviewed, then merged with the main stream. This branch may be in the same repository as the main stream or in a completely separate one. Some ways that I've seen done are: Push a branch to origin, and have the reviewers merge the changeset in when they're ...


12

I like the other answers that say to put as much "tooling" code as you can into Iteration 0. However, sometimes, these kinds of tools come up after the project has already started. Perhaps in Iteration 3 you realize you need a generalized XML parser widget to be used on various stories going forward. In that case, the first User Story that relies on these ...


11

Important note There is no out-of-the-box feature for this, and usually I try to steer people away from generic tasks like "Test", "Deploy" and have them think about testing all the way through the work and to have them define intermediate tests they want to execute along the way. Generic stuff such a Release Notes and Deployment can be completely ...


9

We make the changes to foundation (Foundation-A) and push them out to the nuget feed as an unstable package. Here's where your problem begins... Don't do that. Any changes to Foundation v1.0 should inherently be valuable to all consumers of Foundation, otherwise it doesn't belong in Foundation. So, when creating the nuget package, do it as an official, ...


9

I think Jesse has provided a great answer. I'm simply going to try and make it, well, simpler (if possible) :) The Product Backlog Item (or User Story, if you prefer) is usually written like this: As a New Customer I want to register my details So that I get informed of new product releases In a developers head this may translate in to: Create a ...


7

The official Agile answer is that this simply should not be allowed. Unfortunately, as you are experiencing, the reality is that this often happens. Sometimes this is because business requirements change too rapidly even for short sprints. Sometimes this happens because of pure bad planning on the part of the product owner. And unfortunately sometimes ...


7

Solve the issue at deployment time. As in, your production branch has all the dev configs and such. When you have a tool building and deploying your code, that re-configures your application to run in production. This avoids merge conflicts (your production configs aren't in the same file, the build tool overwrites it), and gives you a ton of control over ...


6

It largely depends on what fields you would want, as 17 of 26 indicated: TFS is highly customisable. The reason I would want to do this as opposed to use something like JIRA is that you get a single view of what your developers are working on, as opposed to having to aggregate two systems. TFS also has resource capacity planning, and if you're not showing ...


6

That is not one requirement, but 4 requirements. One of the characteristics is of a good requirement is that it is cohesive: it addresses one, and only one, functional or non-functional characteristic of the system. I'd enumerate each of these as separate requirements or user stories to promote traceability and verification: - Users can open content from ...


6

Looks like you are completely borked with that lack of branching. At the very least you should be developing on a Dev branch and merging completed code onto Main when your code is working and 'releasable'. This would stop the stupidity of reverting committed work if you failed to meet your deadline and re-committing it afterward. The days of using VSS are ...


6

Basically, a build would be limited to: Check out, Compilation (or more generally, build, which includes more tasks, such as setting up proper configuration), Unit testing, while continuous integration will walk through the same three steps, plus: Integration of the project within the larger system, Integration testing, (Eventually system testing). ...


6

The bits of this question that aren't around tooling are well answered in this question that @MichaelT already pointed to. Agile is opposed to over-planning As far as tooling to support long-range planning, though, the key point is that Agile recognizes that business conditions always change, and that long-range plans rarely make it to the end without ...


6

If it's infrastructure it's typically put into Iteration Zero. What's Iteration Zero? It's typically the time between kickoff and planning before actual iterations start. An example, say we need a new web service. So, I need to create the project, set up continuous integration, set up a source control repository, set up build script and automated ...


6

Test features separately and in order, that's really the best way to do it. Usually whichever one is done first gets tested first, but business needs could change that priority. When FeatureA is accepted, it's merged into the main branch (dev, UAT, or master in your case, as applicable), that branch is merged into FeatureB and then feature B is tested. A is ...


5

I have a very positive experience of using TFS 2012. It is quite easy to set your TFS server up and running, CI build automation is very simple and straightforward (and the Gated check-in build is just awesome. We failed to achieve same functionality with Team City). Team interaction is very transparent and straightforward too. You can easily associate your ...


5

How to reorganize If you do the reorganization wrong, you'll eventually have to deal with the angry team. In the best case, they will just revert your changes; in the worst case, they will have to deal with the new organization, even if they find it highly irrational. You can easily avoid this. creating unnecessary churn, and insulting my co-workers Don'...


5

Ahh. Congratulations! You’ve destroyed one bottleneck and discovered the next one! Now it’s time to look at actually continuously integrating your code. As you’ve found out, it’s hard to continuously deliver when your code under dev isn’t being continuously integrated, but how do you make this work? No more feature branches. No. Seriously. No more feature ...


5

(1) What is the difference between "work items" and "backlogs" A work item is the generic term for an entry that describes and tracks activity, such as a product backlog item, a task, a bug, or a test. Work items also have a hierarchy -- a task is a work item, but it is owned by a product backlog item, which is itself a work item. A backlog is a collection ...


5

In my experience doing development in this way, there are a few places this should get caught: 1) It should get caught in planning or daily scrum. Some sort of conversation like "I'm going to be working on X" "Oh, I was also going to work on X, we should talk" will likely happen. 2) Even if that gets missed somehow, step 1 of TDD (or BDD) is to write a ...


5

There are two techniques that work together to avoid this type of scenario from occurring: Step 1: write a failing test before fixing the bug When the bug has been found, the first thing to do is to write a test that will pass when the bug is fixed and thus it fails whilst the bug still exists. The dev then fixes the bug and in the process makes the test ...


4

No, that's right - Microsoft's premier ALM isn't really useful outside of Visual Studio and the dev teams. You can access the work items using the Team Explorer (which is a very cut down version of VS) or access it via the TFS web site. Neither are particularly good options as the bug fields are reminiscent of ancient 'enterprise' bug trackers I had the ...


4

Code Reuse There have been several approaches to code reuse that have found favour over the years. Each approach has it's place, and more importantly its issues, but the viable ways to reuse code in .NET are: Common Library. The code that is needed in more than one place is put into a common library, and all other parts of the code base then have a ...


Only top voted, non community-wiki answers of a minimum length are eligible