Search the Library Catalogue
Software Engineering With Microsoft Visual Studio Team System
Guckenheimer
Software Engineering With Microsoft Visual Studio Team System Guckenheimer - New Jersey Pearson Addison Wesley, 2007 - XXX; 255 P. 23 CM.
Includes index
Ml version="1.0" encoding="iso-8859-1"?>PrefaceWhy I Wrote This BookI joined Microsoft in 2003 to work on Visual Studio Team System VSTS, the new product line that was just released at the end of 2005. As the group product planner, I have played chief customer advocate, a role that I have loved. I have been in the IT industry for twenty-some years, spending most of my career as a tester, project manager, analyst, and developer.As a tester, Ive always understood the theoretical value of advanced developer practices, such as unit testing, code coverage, static analysis, and memory and performance profiling. At the same time, I never understood how anyone had the patience to learn the obscure tools that you needed to follow the right practices.As a project manager, I was always troubled that the only decent data we could get was about bugs. Driving a project from bug data alone is like driving a car with your eyes closed and only turning the wheel when you hit something. You really want to see the right indicators that you are on course, not just feel the bumps when you stray off it. Here too, I always understood the value of metrics, such as code coverage and project velocity, but I never understood how anyone could realistically collect all that stuff.As an analyst, I fell in love with modeling. I think visually, and I found graphical models compelling ways to document and communicate. But the models always got out of date as soon as it came time to implement anything. And the models just didnt handle the key concerns of developers, testers, and operations.And in all these cases, I was frustrated by how hard it was to connect the dots for the whole team. I loved the idea in Scrum one of the agile processes of a "single product backlog"one place where you could see all the workbut the tools people could actually use would fragment the work every which way. What do these requirements have to do with those tasks, and the model elements here, and the tests over there? And wheres the source code in that mix?From a historical perspective, I think IT turned the corner when it stopped trying to automate manual processes and instead asked the question, "With automation, how can we reengineer our core business processes?" Thats when IT started to deliver real business value.They say the cobblers children go shoeless. Thats true for IT, too. While weve been busy automating other business processes, weve largely neglected our own. Virtually all tools targeted for IT professionals and teams seem to still be automating the old manual processes. Those processes required high overhead before automation, and with automation, they still have high overhead. How many times have you gone to a one-hour project meeting where the first ninety minutes were an argument about whose numbers were right?Now, with Visual Studio Team System, we are seriously asking, "With automation, how can we reengineer our core IT processes? How can we remove the overhead from following good process? How can we make all these different roles individually more productive while integrating them
9780321278722
Microsoft .Net Framework Microsoft Visual Studio Software Engineering
005.1 / GUC
Software Engineering With Microsoft Visual Studio Team System Guckenheimer - New Jersey Pearson Addison Wesley, 2007 - XXX; 255 P. 23 CM.
Includes index
Ml version="1.0" encoding="iso-8859-1"?>PrefaceWhy I Wrote This BookI joined Microsoft in 2003 to work on Visual Studio Team System VSTS, the new product line that was just released at the end of 2005. As the group product planner, I have played chief customer advocate, a role that I have loved. I have been in the IT industry for twenty-some years, spending most of my career as a tester, project manager, analyst, and developer.As a tester, Ive always understood the theoretical value of advanced developer practices, such as unit testing, code coverage, static analysis, and memory and performance profiling. At the same time, I never understood how anyone had the patience to learn the obscure tools that you needed to follow the right practices.As a project manager, I was always troubled that the only decent data we could get was about bugs. Driving a project from bug data alone is like driving a car with your eyes closed and only turning the wheel when you hit something. You really want to see the right indicators that you are on course, not just feel the bumps when you stray off it. Here too, I always understood the value of metrics, such as code coverage and project velocity, but I never understood how anyone could realistically collect all that stuff.As an analyst, I fell in love with modeling. I think visually, and I found graphical models compelling ways to document and communicate. But the models always got out of date as soon as it came time to implement anything. And the models just didnt handle the key concerns of developers, testers, and operations.And in all these cases, I was frustrated by how hard it was to connect the dots for the whole team. I loved the idea in Scrum one of the agile processes of a "single product backlog"one place where you could see all the workbut the tools people could actually use would fragment the work every which way. What do these requirements have to do with those tasks, and the model elements here, and the tests over there? And wheres the source code in that mix?From a historical perspective, I think IT turned the corner when it stopped trying to automate manual processes and instead asked the question, "With automation, how can we reengineer our core business processes?" Thats when IT started to deliver real business value.They say the cobblers children go shoeless. Thats true for IT, too. While weve been busy automating other business processes, weve largely neglected our own. Virtually all tools targeted for IT professionals and teams seem to still be automating the old manual processes. Those processes required high overhead before automation, and with automation, they still have high overhead. How many times have you gone to a one-hour project meeting where the first ninety minutes were an argument about whose numbers were right?Now, with Visual Studio Team System, we are seriously asking, "With automation, how can we reengineer our core IT processes? How can we remove the overhead from following good process? How can we make all these different roles individually more productive while integrating them
9780321278722
Microsoft .Net Framework Microsoft Visual Studio Software Engineering
005.1 / GUC