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.

Initial Prototyping

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.

Summary

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.

I've mentioned here and here about the brown bag meetings we have at EPS. We're taking this idea to the next level so that we can push the knowledge transferring further and quicker. The main idea is that we will be meeting also on Saturday mornings, for about 3 hours, and therefore get more things done.

The final product of this idea is to have a .NET application to replace the process and tools that we currently use for timesheet, travel expenses report, and billing. However, the ultimate objective is to increase/improve the developers' knowledge on the different areas involved with software development, from tools and frameworks through processes and architecture.

Below is a little more detail around this project. We've already had a few meetings, and tomorrow I'll post another entry here with a summary of the meetings we've had so far. I'll try to keep posting updates every week so to keep track of our progress. I want to somehow document this experiment.

I've already tried this on a small scale with Milton, a new developer we've hired, where we've built a new project on the evenings during a 3-week period when he was visiting Houston, and we both agreed I was able to have a lot of knowledge transferred to him on such timeframe, so I'm really looking forward to see the results when applied to a larger project with more people involved.

So here goes a little more detail about this project...

The Requirements

• Every developer should contribute writing/designing the app;
• The app should be built following all best practices/design possible. The code should look pristine (as good as we can given our knowledge at hand);
• The app should showcase both Milos (our framework), best practices, clean design, etc.
• Elements of an Agile process should be used (I say "elements" because we'll introduce those elements as we feel comfortable, and as we them fit inside of our organization);
• The app should be written following Test-Driven Development (TDD) principles;
• VSTS should be used to keep track of work items, progress, iterations, etc.;
• Every code should be written pair-programming;
• A Continuous Integration process must be used (which includes auto-generating ClickOnce manifests for the app)
• The app should be built in a way so that we could easily create different front-ends to it (WinForms, WPF, Web, Silverlight, compact device, etc.).

The Ultimate goals

Besides the goal of having a working application that we'll use in-house, we have other actually bigger (or more important) goals in mind:

• Get all our developers to master Milos;
• Make sure that everybody is familiar with the most important OOD principles and best practices;
• Get everybody to get used to TDD;
• Developers would eventually get more concise in the way they write code. That’d help with people jumping between projects and maintaining somebody else’s code;
• Since the app would have full test coverage, the integration tests will improve the code quality of Milos as we can include those tests into the main framework's automated tests list;
• We'll increase our knowledge of using VSTS to track progress, iterations, etc, on projects;
• Pair programming is a great way for developers to learn (knowledge transferring);
• We get everybody to learn more about things such as continous integration, ClickOnce, etc.
• We get a great sample application for Milos.

How do we implement this idea?

This is what we have in mind in order to implement this idea. There's nothing written in stone, so we'll be constantly evaluating what's working and what's not and then improve the things that need to be improved. We'll definitely inject our experience gathered from the other projects we've worked on into this project, and the experience we gain from this one project will certainly spread into the other projects.

• Have weekly 1-hour meetings (on weekdays), and another 3-hour meetings on Saturday mornings. Nobody should do anything single-handed, since that'd defeat the main purpose of this project. Everything must be done either in pairs or bigger groups;
• On each meeting, requirements would be gathered, mockups will be created, code will be designed, written, and validated by the end-users (that’d be whoever uses the product of our project, that is, both developers and non-developers);
• When designing/writing, developers would alternate control over the computer every 10 minutes. That is, one developer takes control of the computer, and say, writes the code. After 10 minutes, another developer takes over. This goes on until the meeting is over;
• On the beginning, it is better if every developer could be in the same meeting room. Once we’ve got things rolling, we will split things up into 2-person teams. For instance, maybe Joe (fake names are used here) could team up with Mary to validate requirements for the app and write up some more specs, while Michael and Gene work on implement some of the requirements gathered previously. The teams would alternate every week, or even within the same meeting (maybe a meeting would start with Gene and Mary working on requirements for the first half of the meeting, and then they each would go join a separate team to work on implementing the requirements);
• Developers should not go on their own implementing parts of the application by themselves. One could go on his own trying something out outside of the app, but when it comes to actually implementing it into the app, it must be done in pairs, so that others can both learn from the solution, or bounce ideas back and forth to analyze whether the developer isn’t missing something important.
• We have developers working remotely, from distant locations such as Brazil and Austria, so we'll be using a mix of Live Meeting and Skype in order for them to participate in the project.

Coming up on the next post...

Like I mentioned, soon (I guess tomorrow), I'll be posting a summary of the meetings we've already had, and what our experiences have been so far. Of course, that's going to be mostly from my point of view, of my interpretation of somebody else's point of view, so we may get my fellow co-workers jumping in and helping me out with that.  :)