Thursday, March 10, 2005

Now I am busy with Visual Studio Team System for a while I suddenly realize that working in IT projects can become real different when working with new tool. This makes me wonder, will IT projects ever be the same?


When we have a look at an ordinary IT project there are a few things that often go wrong. First of all we have the project leader, according to the development team the project leader is most of the time a pain in the ass. He isn’t really involved in the development process and most of the time the he isn’t even aware of what the system really looks like. All he cares is his excel sheet (or ms project file) that indicates if the development team is working hard enough to meet the deadline. To gather the necessary information to update his excel sheets he drops by in the project room once ore twice a week to have a quick talk with the developers. When things go wrong all he does is blame the development team. When the project is delivered successfully it’s the project leader that gets all the credits.


To stay out of trouble, the development team informs the project leader during their weekly status meeting that development is right on schedule and everything goes as planned. “Just a few more weeks of development before we can start system testing” the lead developer says, just to make the project leader feel good. At the end of the status meeting the project leader reminds the development team about “their” motto: Work Harder!


After the project leader left the room, the developers thank the lead developer for not telling the project leader they are a bit behind on schedule. The lead developer says it is no problem but also indicates that starting from now on everybody (including himself of course) in the team has to work a little bit harder to keep the possibility to actually meet the planning. This means a little less playing darts, browsing the internet and writing blog entries during working hours. They all have a laugh while making some remarks that if they don’t meet the deadline they will do some development work during the system testing phase that is about to begin. So, no worries yet!


This is actually the moment that the eyes of the tester are opened! Till now the tester was just one of the guys in the team. While writing “his” test scripts using his own set of tools (like word, excel and some SQL scripts) he didn’t really bothered the developers so he was totally accepted. Every time the testers has a question about some functionality he is writing test scripts for, the developers told him this piece of functionality isn’t implemented yet (but, almost done!). Therefore the only option the tester has is to base his test scripts on the functional requirements that the functional designer of the team put in a special folder for him on the server.


Having heard the developers say that they will use “his” testing time to continue developing makes the tester pissed. From that moment on he realizes he isn’t a full member of the team anymore and swears to himself that he will do everything necessary to find a lot of bugs. That will force the developers to work harder to keep the all mighty project leader happy.


In the meantime, in his constant battle to keep the users happy, the functional designer is working hard on his own set of the functional specifications. Just some weeks before the deadline he sends the final version of the specs to the development team. Of course without notifying that poor tester working hard to create all kind of test cases that will definitely fail during the system test phase that is about to start. When the lead developer reads the new updated specs he starts complaining about the functional specifications include new functionality that is not part of the initial planning. Of course it is possible to include this in the release but this will affect the available testing time. After a small talk with the project leader it is decided not to change the deadline. The project leader learned never to leave his project plan so he thinks changing the deadline is evil! Feeling the pressure of the project leader and the functional designer the lead developers decides to implement the new functionality within this release. Because there is little time left he doesn’t change the class diagrams and all other related models and documentation that were initially created by the architect on the project. There will be plenty of time for this when the project is finished!


When the new functionality is finally included in the system, there is almost no time left for system testing. Some quick tests show that there are some bugs in the system but because the lack of time they are all marked as “low priority” so they can be fixed in the next release (of course this frustrated the tester even more). While some of the developers are helping the tester testing the software, others are building the install packages. When the packages are finally ready they are handed over to the operations department.


During the installation of the software all kind of problems occur. The architect decided to use some cool new framework and technology that, strange enough isn’t installed on the production environment yet. After some discussion with the operations department and some minor changes in the code the software can be successfully installed.


The very proud project leaders informs the user that the software is successfully, and of course, according to the planning, installed. This is the moment the users has his first look at the system. Because of the small delay in the development phase there was no time left for user acceptance testing. Luckily the project leader and the functional designer convinced the user (based on the functional design and some models from the architect) that the team is building exactly what the user wants. After playing a few hours with the system however the users realizes that this software isn’t what he wants. The system doesn't corresponds with his day to day job at all. One of the good things about this is that because the system isn’t very useful for the user, he will not find the bugs in the system and the project leader gets is changes to solve these issues in the next release of this beautiful piece of software.


So, what will Visual Studio Team System change in all of the above?


Unfortunately VSTS cannot change anything about the project leader. The good thing is however that VSTS brings us a totally integrated environment. This will dramatically improve communication between the different types of team members. The new set of tools will help improving the overall quality of the software.  


First of all the architect can use the different modellers available in Visual Studio Team Architect to model his applications. Together with the models provided by the operations department he can test the deployment of his applications in a very early stage of the project, which of course saves a lot of time in the end of the project.


After that the architect can use the class designer to model his classes. These models can be used by the developers to generate the code from. If the developers make changes in the structure of the classes VSTS immediately updates the models, initially created by the architect. So now the models and software are always in sink, saving a lot of time updating the models at the end of the project.


When using the MSF agile methodology within Visual Studio, all tasks are related to work items, which can be assigned to team members. The Team Foundation Server gives the project leader a way to monitor progress on work items. Also very nice report can be generated from this data giving the project leader the possibility to impress his users even more. Fortunately Microsoft will provide a separate tool for “project leaders”so they don’t need to use Visual Studio for that. This saves them from becoming a real team member.


The next good thing from MSF agile is that is provides a more flexible methodology which leaves some space for making changes during the project, for example to react on changes requests of users.


The new integrated test facilities and some support for Test Driven Development try to enforce that there is always a “working version” of the software. Maybe only a small piece of functionality is available but it works (because it is tested!). This gives the user the possibility to drop by in the project room any moment and ask for a quick demo of the software. Because the user sees what the system actually looks like in an early stage it is much easier to monitor if this is what he really wants.


Because within VSTS testing is fully integrated within the Visual Studio environment, communication between developers and tester (and all other team members) will improve. The tester might even have some .NET experience to validate or write the unit test for the software. Further, VSTS provides tools to force Unit tests to be available before it is possible to store the code in the version control system. The tester can use these unit tests to immediately start testing the software (and not wait till the end of the project).


The fully integrated version control system allows the team members to store all project related documents, code, etc. in the “project repository” which might help different team members using different versions of specifications.


So where are we?


All of these and a lot of other features of VSTS help us improve the overall quality of IT projects we are participating in the very near future. I haven’t yet real experience with this tool but I think is has enough potential.


For all the people every worked with me on a project:

Of course all of the above isn’t based on my own experiences. This is just what I heard from colleagues! I do like project leaders! For me Visual Studio doesn’t actually change anything in the projects I am participating in. The only difference is that when using Visual Studio Team System I have a totally new and cool tool to deliver these very successful projects to our clients!

posted on 3/10/2005 1:22:54 PM UTC  #