Today I was part of the ALM RoundTable event at Microsoft via Live Meeting. It was quite fun to be part of it (thanks to Katrien, Hans, Philippe and Paul)! The software and hardware to make it all possible is really impressive.
I don’t think that the Live Meeting was recorded, so it won’t be available offline … but in that case I want to share with you the small homework I did before attending the session. We did cover some extra topics and also other questions were tackled from the audience, but at least it gives you some insight on the stuff we touched …
- Is there a team size starting from which ALM tools like VSTS makes sense?
In my opinion VSTS is currently the best solution to deliver quality enterprise software in a controlled way. Whether you are a 5 person enterprise or a 1000 person enterprise, Team Foundation Server can help by making collaboration and communication easier than ever. You need good people in a software development team, but you also need the right tools and processes in place for your people to do their work. That’s where Microsoft Visual Studio Team System comes into play. It’s an integrated Application lifecycle Management (ALM) solution comprising tools, processes, and guidance to help everyone on the team improve their skills and work more effectively together.
- I’m doing SCRUM, so I don’t need an ALM tool.
Doing SCRUM or any other new/old methodology doesn’t mean you don’t need an ALM tool. VSTS makes it possible to adapt the tooling to your process. Out-of-the-box with TFS you get 2 process templates you can use : MSF for Agile development or MSF for CMMI. On top of that you are able to install any process template you want – like the process template from Conchango to do “Scrum for Team System”. Or you can also adapt the existing templates to your needs. Go to CodePlex to find an overview of available process templates.
- You can’t do all at once. Do I start with planning or do I start with source control or elsewhere?
It all starts with creating a new Team Project in Team Foundation server but before you can create a new Team Project, you need to know which process template you will be using … So therefore it’s quite important to think upfront what you really need to enforce your way of working. After that, you can start working on a strategy for setting up a folder structure in Version Control. So, it really starts with choosing the process template : that’s the glue that keeps it all together in Team Foundation Server.
- How do I start?
Once you have defined a process template and your team has been selected, work item management will be key to start work in a controlled way. Work items are assigned to individual team members and will flow between the team members to get the work done.
- Which tool does a Project Manager use? VS?
The nice thing with VSTS and TFS is that a project manager can use the tools he wants to connect to the central Team Foundation Server. He doesn’t need to have VS installed. He may want to connect with Microsoft Project, Microsoft Excel or the Web Access edition of Visual Studio Team System. There are other 3rd party tools that even lets you connect to Team Foundation Server from Outlook (for example : Ekobit TeamCompanion)!
- How does this integrate with Sharepoint?
After the creation of a new Team Project, a SharePoint team site is installed and configured to use by the entire team. You can for example use it to publish reports or to share document libraries.
- Any best practices?
To manage work items in TFS, I’ve always found it very interesting to use Microsoft Excel instead of Visual Studio. In Excel, you can easily create work items in batch or do whatever you want to organize your workitems. It’s also fairly easy to connect to the TFS OLAP cube in TFS to pull that data in Excel and do some custom formatting and reporting.
- Who is in charge of reporting?
Everyone on the team can be in charge of reporting. The good thing about TFS is that all project-related data is stored in the SQL Server database. So, if the default reports that come with the process template are not sufficient for your specific needs, you can always create your custom reports with SQL Server Reporting Services. Or, like mentioned before, Excel proves to stay an invaluable tool to do formatting and reporting of data!
- Is there an advised way to structure branches?
First of all, it’s important to note that each branch you create brings an extra cost. So you really need to ask yourself the question if you need that branch before you actually branch. The total cost of branching is paid by merging and resolving merge conflicts and also by additional testing you need to perform on the branch. But in many cases, you really need some kind of isolation for development and branches will be your only option. The advice I can give to teams is start with a basic branch plan and eventually evolve to a more complex one if your really need. In a normal environment you could just have a main branch (stable snapshot), a development branch (changes for a next version) and a release branch (ship product). See CodePlex again for some excellent Branching Guidance.
- Continuous builds? Why would I want that?
With continuous build, we mean that each check-in is automatically followed by a build of the entire solution to check for any inconsistencies in the development solution. With continuous integration enabled development teams are certain to detect compilation or any other errors (like failing unit tests) as early as possible so that the entire team is only impacted for the least amount of time. Build errors should of course be solved as quickly as possible! It’s very bad for productivity if developers do a get latest of the solution and aren’t able to run the solution. This should be avoided at all cost. That’s why VSTS2010 goes a step further with the Gated Check-in feature …
- Do I need a dedicated build server then?
You don’t need to install Team Build on a separate server, but it’s advised to do so to not increase the load on the TFS Application Server.
- How do I decide which tests to run on which builds?
If you decide to run tests on a continuous integration build, you must make sure that those tests run fast, so ideally you should run only pure unit tests – no integration tests or other more complex testing. If you want to run the entire suite of tests, you may choose to run them on a nightly build where execution time is less important than on a continuous integration build.
See you at the next ALM event!