As I mentioned a few days ago, here’s a summary of things we’ve done so far in our new in-house project…
Customizing Team System project templates
We’re going to try to use as much as we can out of VSTS, so that we can explore more of what’s available there.
One of the things want to do is to customize the states available for work items; we want to remove some of the existing ones, and adding other ones, so to make it fit better the way we’re structuring the workflow for this project. We have some experience in that area that we can use, but we’re also doing some researching to see what kind of customizations other people are doing.
Another thing we’re doing is to research and discuss the better way to tailor the Areas and Iterations in VSTS to better fit our project. Again, we’re leveraging what we’ve experienced in other projects, and evaluating what did and did not work so that we can fine tune our process.
Assessing what we currently have, and open brainstorming sessions
The product produced out of this project will replace some in-house tools and processes that we currently have. We’ve had a few discussions where we’ve assessed what our current tools and processes are, things we like about it, things we don’t like about it, things we’d like to have, etc. Everything was pretty open, without any discussion on specific implementation details or anything like that.
We’ve made notes and decided what areas we were going to concentrate on first, that is, which small area we are going to prototype, design, and implement first.
Based on the small (but probably most important) part of the application that we decided to tackle first, we started collecting more concrete ideas as to what features we’ll need, what screens, etc.
At first we’d do the process of mocking up screens by drawing on the whiteboard, but since we have people participating remotely, we decided to give a shot at MockupScreens. So far it seems like we’re really digging this tool. It helps us with the online collaboration, and it’s simple enough to mockup screens in a productive and effective way.
Here’s an example of one of the mockups we created:
The idea is to capture both what of information and what type of UI elements we want on the screen. The labels and types of controls are just for a general idea and are likely to change to something more appropriate. For instance, instead of buttons being located at the bottom of the screen, they’re likely to go up into a Ribbon control.
The important thing here is to NOT spend anytime in Visual Studio, getting stuck with finding the right controls, maintaining files that are going to be deleted, etc. There may be cases where we don’t even have the more appropriate control available in .NET and we’ll end up creating our own from scratch, therefore it’s much more productive to use a tool such as MockupScreens and not get tied up by implementation details. These mockups will help us identifying what controls or UI elements we will need.
This post was really just a quick summary of the important pieces we’ve gone through so far. I have personally been enjoying the meetings and what we’ve accomplished so far. The discussions we’ve had have been producing good things.