Professional Scrum Development with Microsoft Visual Studio 2012: Effective Collaboration

Collaborative development tools

Over the years, I have met with hundreds of software development teams. In my opinion, the most productive, collaborative tools for software developers to facilitate a discussion are a whiteboard and a dry erase marker or a laptop running Visual Studio and a projector. Using tools like these implies several things: the collaborators are collocated, they each see the same thing, and they are having a discussion in real time. There are no environmental impediments blocking the flow.

In a perfect world, all discussions and brainstorming meetings would occur like this. Unfortunately, some of us work in a world that is not collocated. Our team members don’t work in the same office, or even live in the same city, state, or country. When we are in bed, our colleagues are at work, and vice versa. For environments like this, high-bandwidth collaboration tools like a whiteboard don’t have the same impact. Alternatively, electronic tools must be substituted. Fortunately, Visual Studio 2012 includes several good ones.

In this section, I will discuss some of the Visual Studio 2012 features that enable collaboration.

Team Foundation Server

Team Foundation Server is the team’s hub for coordinating development efforts on a shared code base using shared work items and shared, automated builds. TFS directly supports the first two, and Team Foundation Build (Team Build), a feature of TFS, enables automated builds. The team can use Team Build to automate the compilation, deployment, and testing of its software products. Having at least one automated build for the product should be a goal. High-performance Scrum Development Teams will have several.

TFS should be at the center of the development team at all times, especially when coding. There are challenges, however, when supporting a busy team of developers working on a shared code base. Parallel development such as this can lead to concurrency issues. In the time between a developer getting the latest version of code, making changes, and then checking it back in, one or more developers may have checked in their changes to the same folder. This means that when the original developer checks in his or her code, the probability that a conflict will occur increases with the length of time that the code is not checked in. Because these conflicts usually require a merge operation, you should check in frequently.

Merging occurs when two variants of the same file are combined in a logical way to create a new version of the file. Manually integrating files like this is a time-consuming process and should be avoided. TFS can often auto-merge for you, but not always. One way to avoid having to merge is to enable locking so that each developer locks the file(s) that he or she is working on. While this will prevent anyone else for making changes to the file until the first developer is done, it will block other developers from working on the file and being productive. There is a better way—to integrate, or merge, continuously.

Continuous integration

High-performance Scrum Development Teams have learned how to work smarter, not harder. One way that they do this is by continuously integrating their code changes with others on the team and running automated tests to verify the integration didn’t break anything. While these same automated tests can be run inside Visual Studio, Team Build can probably run them faster and they will be asynchronous, enabling the developer to work on something else. Another benefit is that the tests can be run in a controlled environment that will show any configuration management problems quickly.

A better way to avoid painful, manual merge operations is to do smaller, less painful merges throughout the day. This is the basis for continuous integration (CI). Automated CI takes this a step further. Upon a check-in, an automated build gets launched, having been triggered by a check-in event. Source code is compiled, binaries are deployed, automated tests are run, and feedback is returned to the team quickly.

CI is about reducing risk. When a developer defers integration until late in the day, the week, or the Sprint, the risk of failure (i.e., features not working, side effects, bugs) increases. By integrating code changes with others regularly throughout the day, the Development Team will identify these problems early and be able to fix them sooner because the offending code is fresh in everyone’s mind. The practice of CI is a must for any high-performance Scrum Development Team.

A Development Team shouldn’t be afraid to break the build and work together to fix it. Refactoring, restructuring classes and methods, and changing internal interfaces can be messy work. There may be times that you want to check in your not-yet-finished code so that another developer can begin working with a part of it. You may also want to see how many errors and warnings and failed tests occur when your changes are integrated with others. This is fine. You are in the middle of the Sprint. This is not production code. Just as a surgeon may need to make some cuts in order to fix a critical problem, so might you have to break some code in the development process. These cuts are temporary, and the CI build and failing tests will illuminate them until they are all healed.

Builds check-in policy

Scrum Development Teams stay busy. They will work on a design task and when it’s done, switch to a coding or testing task, and repeat, and repeat. As they finish a task, they usually check in their work. When CI builds are enabled, the check-in triggers an automated build. The developer then starts working on another task and, hopefully, remembers to go back and check that build’s status and quality. Unfortunately, the developer may become focused on the new task or get sidetracked by something else. He or she may forget to evaluate the results of that CI build. Compound several builds on top of each other, and you might have a tangle of build results to work through.

The Builds check-in policy was created as a solution for just such a situation. When you configure a CI build in Team Build, every check-in operation starts a build. When one of these builds breaks, it is important for the Development Team to fix the problem that broke the build before making additional, unrelated changes. You can use the Builds check-in policy as a tool to limit additional check-ins until the broken build is fixed. When this policy is enabled, it literally blocks anyone else from adding new files to any source control folder that is a working folder in/under the build definition. When the policy fails, the developer who is attempting to check in will receive a message like the one shown in Figure 8-5.

When a developer runs into this warning message, the expected behavior is that he or she can query the other team member who “broke” the build. Remember, it could just be that a single test failed, and not some catastrophic system error. Once the Development Team has been consulted, the developer who received the warning can then choose to override it by clicking the Override Warnings hyperlink on the Pending Changes page and providing a comment. All developers will be blocked like this until the CI build completes without errors and all tests pass.

Build Notifications tool

Rather than having TFS block check-ins when a build fails, some developers would rather just be notified when the build completes and then check the results manually. Fortunately, Microsoft includes a notification tool that does exactly this.

The Build Notifications tool is installed by default, but not configured. The developer will have to start it manually at first. It can be found under the Start menu by pointing to Microsoft Visual Studio 2012 > Team Foundation Server Tools. Each developer can choose the build(s) that they want to monitor. They can also choose to be notified when each build gets queued, starts, or completes. They can also choose to monitor only builds that they have started or that anyone on the team has started. You can see an example of the settings in Figure 8-6.

The notifications will appear in the system notification area (otherwise known as the system tray), in the lower-right corner of the Windows desktop. You can see an example of this in Figure 8-7. The notification will appear for a few seconds and then fade away. You can click hyperlinks on the notification to allow you to view the details of the build. If the notification has since disappeared, right-click the Build Notifications icon, in the system notification area, to view a build’s status or replay a recent notification.

Gated check-in builds

Gated check-in builds are a type of private build, triggered by a check-in, but built using shelvesets in order to ensure that there are no errors prior to checking in. The purpose of a gated check-in build is to verify that the developer’s code integrates with the other team members and that tests pass before committing the changes to the main source control repository. This feature was introduced in TFS 2010.

One of the problems plaguing the gated check-in build feature is performance. Even in TFS 2012, the slow performance of the UI notifications become apparent—very fast. Also, each gated check-in definition can have only one running build at a time. Therefore, active teams doing lots of check ins and builds are more likely to develop a large queue of gated check-in builds. Fortunately, there’s a new feature in TFS 2012 that helps with performance, which I’ll get to in a moment.

Gated check-ins are a solution to a misunderstanding. When the original authors of XP said, “Don’t break the build,” they didn’t mean it literally. They meant that if a developer ever does break the build, it is their responsibility to fix it immediately. Really, the authors should have said, “Don’t ever leave the build broken.” When I’ve seen teams use gated check-in builds, they often do so because they are unable to meet the requirement of never leaving it broken. It could be that their build takes too long or they simply don’t have the discipline to follow the practice. It also may be because the organization has a low tolerance for broken builds. We need to recognize that these are all dysfunctions of some type.

For teams running long gated check-in builds, TFS 2012 offers a helpful new feature. Gated check-in builds can now batch together multiple shelvesets into a single build. For example, a team might configure a production build to build up to three submissions simultaneously, as shown in Figure 8-8. These submissions (shelvesets) would get merged and built together on one build agent. If the build succeeds, and all tests pass, each shelveset would be committed (checked in) separately. If the build fails or any tests fail, then each shelveset is built, one at a time, to determine which one caused the failure.

Email alerts

A developer can also monitor builds by enabling an email alert. He or she can register an email address with TFS to receive an email that alerts them to the fact that a build has completed or a build’s quality has changed. In fact, alerts can be established to notify when changes occur to work items, code reviews, and source control files, as well as builds. These are just standard emails (in either plaintext or HTML format) that are sent from TFS to a user’s inbox using an intermediary Simple Mail Transfer Protocol (SMTP server). Developers can subscribe to alerts for themselves, for others, or for the entire team.

The body of these email alerts contain hyperlinks that can be clicked to take the reader to the respective information in Team Web Access. Emails pertaining to source control, such as check-ins, will display information about the changeset when clicked. Emails about work items will take the reader to the respective work item when clicked. Emails about builds will direct the user to the build in question.

Before TFS can send any alert email, a TFS administrator must configure the server to use an existing SMTP server. This can be accomplished in the Team Foundation Server Administrative Console in the Application Tier section, as shown in Figure 8-9. At a minimum, the administrator must specify the SMTP Server and the Email From Address. In TFS 2012, Microsoft added the ability to specify optional advanced SMTP settings, including User, Password, Port, and additional security information directly from the console. This was a long-anticipated feature in the product.

Alert subscriptions are stored on the server and organized by team project. A developer can add different alerts for each team project or team that they are a member of. A developer can also configure a team alert, which is new in Visual Studio 2012. Team alerts simplify the administration of setting up the same alert for everyone on the team. For example, if all Scrum Team members, including the Product Owner and Scrum Master, want to be informed when a build has completed or when a PBI is “done,” someone can create a team alert such as the one shown in Figure 8-10.

For build-related alerts, there are two fields that you should be aware of: Requested By and Requested For. The Requested By field is populated by TFS and is always the account that actually queues the build. For manual builds, it contains the user that queues the build, but for CI and scheduled builds, it contains the build service account. If you are interested in knowing who requested the CI build, this won’t work. Instead, you should reference the Requested For field. Its behavior is very similar to the Requested By field, except that for CI builds it contains the user who performed the check-in.

Email alerts can also be configured to let a developer, or a whole team, know when a build has completed or failed. This would be an alternative to using the Build Notifications tool previously mentioned. In addition, by using the Requested For field, a single team alert can be created that is smart enough to only email the developer who requested the build, and nobody else. This is done by creating a team alert with the criteria Requested For = [Me], as shown in Figure 8-11. This criteria establishes a behavior which causes an email to be sent to only the person who requested the build. You’ll be happy to know that the [Me] macro, and its related behavior, is available for all types of alerts.

Shelving

Shelving lets you set aside a batch of pending changes for whatever reason. It could be that you were interrupted by some more important work, or you want to queue a private build, back up your work, or hand something off to another developer. Shelving can also be used when you want to have your code reviewed.

Shelving produces an artifact called a shelveset. Shelvesets exist outside of the normal TFS source control repository and are identified by a unique name provided by the developer who created it. Some point in time later, that developer (or another) can unshelve those pending changes into a local workspace and continue working or review the code.

When a developer shelves his or her code, anybody on the team with the appropriate permissions can view and unshelve those pending changes. In other words, to unshelve a pending change, you must have the Read and Check out permissions set to Allow. For a Scrum Development Team practicing my recommended security configuration, this means that any developer can unshelve another developer’s pending changes. This is how it should be on a high-performance Scrum Development Team. Any developer can review any other developer’s code without being limited by the tool.

If the developer reviewing the code makes any changes, he or she must create a new shelveset or check in the code. This is because the second developer cannot change the first developer’s shelveset. What I have seen happen is that the reviewer will create a second shelveset with the proposed changes and comments, and then the first developer will create a third shelveset, and so on. If the two developers are not diligent about cleaning up their shelvesets as they iterate, there will be a big housekeeping task at the end. For this reason, as well as for general efficiency reasons, code reviews should be performed in person, where all developers look at the same screen at the same time.

My Work

Visual Studio 2012 Premium and Ultimate edition users can use My Work as a way to see and manage their current, in-progress work. As a developer works through his or her tasks in the Sprint Backlog, they can be started in the My Work page. Work can also be suspended and resumed as needed. Code reviews can be requested and managed. Check-ins can be performed. It’s a very powerful page within Team Explorer, and every developer on the team should consider using it.

To begin working on a new task, drag it from the Available Work Items section to the In Progress section, as shown in Figure 8-12. You can also right-click the task and add it to In Progress or click the Start link. If the task you want to start isn’t visible, you may have to run a different query or refresh the results. It may be that you have to create the Task work item first.

Dragging the work item to the In Progress section will also change the State to In Progress. More important, it gives you context on what you’re doing. For example, even taking 60 seconds to answer a phone call can generate a lengthy “Now where was I?” pause. Being able to see what item you are working on will help return that focus more quickly. If you exit Visual Studio without finishing an In Progress task, it will still be there later when you return.

Later, when you are done with your task, you can check in your changes and resolve (rather than associate) the task. You can also just click the Finish link in My Work. Both of these methods will transition the work item to the Done state and set any Remaining Hours to zero. If you click Finish, Visual Studio may prompt you with a warning that you haven’t checked anything in. For tasks that don’t require a check-in, you can dismiss the warning. The task will be removed from My Work, as will the pending changes when you check them in, allowing you to move to your next task.

Code reviews can also be requested and managed from the My Work page. I will discuss them later in this chapter.

Suspending and resuming work

From time to time throughout the Sprint (or the day on some dysfunctional teams), a developer will experience an interruption. In a perfect world, this never happens, but in the real world, it does. A high-performance Scrum Development Team works to marginalize this reality by either reducing the number of interruptions or making them less painful. When an interruption does occur, switching context to the new problem can be difficult and wasteful.

For example, let’s say that you are deep in thought, implementing a complex scenario within a PBI and the Product Owner drops into the team area with an emergency. It’s obvious that an urgent bug fix is required and, as this is critical to the business, you should drop what you’re doing and fix it. Forget your forecast. It’s about saving money and customers at this point. What most developers do is to shelve their code, undo pending changes, and close their solution. Others will just start a new instance of Visual Studio, get the specific version of code that’s running in production, and go about locating, verifying, and fixing the bug. Visual Studio 2012 now offers a better way.

From the My Work page, the developer can suspend the current work he or she is doing. Behind the scenes, a shelveset is created to save any pending changes to code, tests, and other files. Important elements of Visual Studio are also saved, such as open windows, breakpoints, and other debug states. The developer assigns the suspended work a friendly name in order to find it easily at some point in the future. By default, this name is the title of the In Progress work item, as you can see in Figure 8-13.

Suspending will shelve any pending changes and then undo the local changes, putting your workspace back into a clean state. It is now ready to handle the new crisis by dragging the new task into the In Progress section. You can see the suspended work listed in the Suspended & Shelved Work section of the My Work page, as shown in Figure 8-14.

Later, when the crisis has passed and the developer is able to return to the planned work, he or she can select the suspended work and click the Resume link. The original pending changes will be unshelved, and the task will be put back in the In Progress section. Other IDE settings and behaviors will be restored as well.

In the event that your interruption gets interrupted, you may want to suspend it, and return to your original work. If this is the case, then instead of a Resume link, there will be a Switch link. Clicking Switch will suspend the interruption work, and return context to the original task. Alternatively, you can choose to Merge With In Progress and bring all the pending changes from the two tasks together.

PowerPoint Storyboarding

Visualizations allow the Development Team to elicit feedback more easily. This feedback can come from other members of the Scrum Team, as well as stakeholders, especially domain experts. Shapes and lines drawn on a whiteboard to represent components and actions enable ideas to be vetted by the right people. It’s faster to sketch out the high-level concepts and their interactions than it is to try to design or code anything in Visual Studio. It’s also cheaper to fix a bug in a drawing than later in code.

As previously mentioned, feedback is important when brainstorming how to tackle a problem such as developing a particular feature or scenario. This is especially true when the developers are not familiar with the domain or the workflow is complex. Having the right people involved in the conversation is critical. The more eyes you can put on a problem, the better the chances of finding an optimal solution. Unfortunately, this is not always possible when the required people are geographically distributed.

For Development Teams that love their whiteboards, I recommend setting up a laptop with a webcam in the meeting room or team area. By aiming the webcam at the whiteboard, and then strategically standing out of the way after drawing on it, remote attendees can be part of the design session and discussion. This is less ideal than collaborating in person, but still allows for rapid design with a dry erase pen, rather than fumbling with a software design tool.

When the Development Team has a need to present their ideas to (and gather feedback from) remote stakeholders, then the new PowerPoint Storyboarding feature in Visual Studio 2012 can be beneficial. Users of Visual Studio 2012 Premium, Ultimate, or Test Professional editions can install and use PowerPoint Storyboarding, which allows a developer to illustrate a PBI or a specific feature or scenario using Microsoft PowerPoint. The illustration is created by dragging and dropping predefined, inline images and adding formatted text. It can then be linked to a work item, such as the PBI that it describes, and shared with other TFS users.

To create a PowerPoint storyboard, there are a few simple steps to follow:

1. Open the PBI work item, choose the Storyboarding tab, and then choose the Start Storyboarding link. You can also start the tool from the Start menu under Microsoft Visual Studio 2012 or by starting PowerPoint directly.

2. Add slides, shapes, and text to the blank presentation to illustrate a PBI, feature, or scenario, as shown with the Customer Login storyboard in Figure 8-15.

   

   Figure 8-15 An example PowerPoint storyboard with annotations.

3. Save the storyboard presentation to a network share or Microsoft SharePoint.

4. (Optional) Link the presentation to the PBI work item that it describes, as shown in Figure 8-16.

5. Share the storyboard with others.

   

   Figure 8-16 A PBI work item with a linked PowerPoint storyboard.

6. Others may provide feedback by annotating the PowerPoint document or by using the Feedback client.

As the stakeholders review the storyboard, they can add comments or even make changes to the illustrations using the built-in features of PowerPoint. If the presentation is stored on SharePoint, it can enjoy the dual benefit of broad availability and revision control. Users can check out the presentation and check in any changes. Feedback can also be provided out-of-band, via email, voice, or using the Feedback client, which is covered in the next section.

Creating a storyboard

To create a storyboard, a developer can select from several layouts that support common user interfaces, such as web and Windows Phone backgrounds. Images can be dragged and dropped from the Storyboard Shapes pane in addition to using all the features available within PowerPoint. These features include clipping and inserting screenshots, hyperlinking from one page to another, animation, inserting images and shapes, and aligning and grouping objects. For example, a developer might create two slides to illustrate the UI for a particular PBI. She might add information about upcoming service appointments to the customer’s account page and add buttons that customers can use to schedule, reschedule, and cancel those appointments.

Before you can link a storyboard to a work item, you must save it to a shared location. The shared location can be any shared folder on the network or a SharePoint site (such as the team project portal). By linking the storyboard to a work item, you are essentially inviting the rest of your team to access this shared file, so be sure they have the appropriate permissions. They can open the presentation, review it, and add their comments. You can link storyboards only to certain types of work items based on the process template from which your team project was created. In the Visual Studio Scrum process template, you can only link storyboards to Product Backlog Item work items. It is possible to link a storyboard to more than one work item.

To create and modify storyboards by using PowerPoint Storyboarding, a developer must have installed either PowerPoint 2007 or later, and one of the following versions: Visual Studio Premium, Visual Studio Ultimate, or Visual Studio Test Professional. Storyboarding is not available in Visual Studio Professional or Express edition. To view storyboards that were created by using the PowerPoint Storyboarding template, users must have PowerPoint 2007 or later installed. They do not need Visual Studio 2012 installed.

Feedback client

As you read in the last section, the PowerPoint Storyboarding tool enables a team to create rapidly a UI mockup or illustration of a feature that can be shared with other team members or stakeholders. It’s important to close that loop by collecting rich feedback about what those users think of a feature, and whether it is still being brainstormed, under development, or has been released. Feedback should always be welcomed, and even encouraged. If the feature has been released and valid feedback is given, it can be captured in the Product Backlog to be considered for future development.

One of the new features of Visual Studio 2012 is the ability to capture rich stakeholder feedback on features being implemented and bugs being fixed. This is good for distributed organizations who want stakeholders to evaluate the emerging Increment or a design that may still be in flux. The Feedback client is used to gather this type of feedback. It is versatile enough that it can be used to provide feedback on anything the user can see and interact with on the desktop.

This type of feedback can either be formally requested via a work item and email sent from Visual Studio, or it can be provided voluntarily, without solicitation. We will look at both scenarios shortly.

Requesting feedback

The first feedback scenario occurs when a member of the Scrum Team, preferably the Product Owner, solicits feedback from one or more stakeholders. These stakeholders will receive a feedback request through an email that is constructed from the feedback request form. From the email, the stakeholders can install and launch the Feedback client tool, which guides them in providing and capturing their feedback. TFS stores this feedback as a Feedback Response work item.

In order to request feedback, TFS must be configured to use an existing SMTP server in order to send emails. This requirement was mentioned earlier in the chapter in the context of setting up email alerts and, hopefully, it is already configured. To begin, click the Request Feedback link on the Team Web Access home page, as shown in Figure 8-17.

Feedback can be requested on any aspect of the product, from the entire application down to a specific scenario within a feature. Because the feedback request is essentially an email, the requester can be as ambiguous or as specific as he or she wants to be. In addition, one request can be partitioned to ask for feedback on up to five discrete items. For example, if the Development Team is code-complete on three scenarios within a PBI, a request could be created that contains three items—one for each scenario the Product Owner desires feedback on.

When creating the feedback request, one or more stakeholders must be selected. These users must have an email address associated with their user name. Users without email addresses won’t be sent a request. The stakeholders should also be told how to access the application in question. An address and instructions can be provided for a web application, (rich) client application, or a remote machine. Finally, the item(s) to be evaluated and any related notes are added to the request. Figure 8-18 shows a feedback request ready to be sent to a stakeholder to evaluate the Customer Login feature of a web application.

As the feedback requester, you will receive a copy of the email submission automatically when you send it. You can also add other email addresses in the To box when previewing the email. Figure 8-19 shows a sample email requesting feedback. If an administrator has not granted permissions to the accounts of those stakeholders that you add, they will not be able to provide feedback through the Feedback client.

Providing feedback

When the stakeholder receives the request, he or she should first make sure that the Feedback client is installed. If this is the first time providing feedback, it will need to be installed. The email contains a hyperlink to download it, if necessary. Next, the stakeholder starts the feedback session by clicking the large hyperlink in the email, or copying and pasting the supplemental URL into the web browser.

As the stakeholder reviews the new feature, he or she is able to perform the following tasks using the Feedback client:

• Record video of the interaction with the application.

• Record voice comments.

• Capture a screenshot.

• Annotate a screenshot using a program such as Microsoft Paint.

• Type comments.

• Attach a file.

• Rate each item of feedback on a scale of 1–5 stars.

On the Provide page of the Feedback client, one or more items appear for the user to provide feedback. For each item, he or she can get context on what’s being asked and then provide free-form feedback through any of the aforementioned methods of input. Figure 8-20 shows the various recording options. If there are multiple items, clicking Next will advance to the next item for which to provide feedback. Recordings appear as images within the Feedback client’s text box.

By annotating screenshots, the reviewer can indicate corrections or improvements by adding text or images to the screenshot that was captured. By default, Paint opens automatically when the user opens a screenshot image that was captured within the Feedback client. Another annotation tool, such as Paint.NET or Snagit, can be configured instead by clicking on the cog icon at the top of the feedback tool, as shown in Figure 8-21. After feedback has been provided for each item, the user can review, make corrections or additions, and then submit the feedback to the requesting user via TFS.

In order for stakeholders to be able to provide feedback, an administrator must grant them specific permissions in TFS. They can either be added to the Limited license group in Team Web Access or a custom group with specific permissions. The Limited group is provided specifically to support access to TFS for users who do not need a CAL. If the stakeholders have a CAL and you are not going to use the Limited group, then make sure to grant the minimum permissions required, which are project-level permissions to create and view test runs and view project-level information, as well as area path permissions to view and edit work items in the respective nodes.

Regardless of which permissions approach you take, you should try to group the feedback stakeholders together in their own Windows group. Because providing feedback is probably the only way that they will interact with TFS, keeping them grouped together will simplify management and allow the Scrum Team to know exactly who their feedback stakeholders are.

Feedback requests generate a Feedback Request work item assigned to the creator of the request. The Description field contains the body of the email that was sent. Feedback Response work items are created to hold the feedback provided by the stakeholder using the tool. Remember that both Feedback Request and Feedback Response work item types are designated as Hidden types. This means that they cannot be created directly from Visual Studio or Team Web Access. Instead, they are created using the appropriate tool, such as the Request Feedback link and Feedback client respectively.

Voluntary feedback

Another way to use the Feedback client to provide feedback is for a stakeholder to start it directly. It can be found on the Start menu under Visual Studio 2012. If it’s missing, it can be downloaded from Microsoft.

When started, the client will be in voluntary feedback mode. There won’t be any associated request or instructions, as you can see in Figure 8-22. Hopefully, the stakeholder will already know what application to start, what features or scenarios to evaluate and provide feedback on, and what team project to submit the feedback response to.

Feedback that has been submitted voluntarily like this can be found in TFS by running the Feedback shared query. This query returns work items that are in the Microsoft.FeedbackResponse Category work item type category. In the Visual Studio Scrum process template, this would only include Feedback Response work items.

When viewing a Feedback Response work item, you will see many of the standard fields, such as title, created by, state, rating, area, and iteration. The more interesting data will be in the Notes field, as it contains the comments typed by the stakeholder and any references to audio, video, screenshots, or attached files. There won’t be any linked stories (PBIs), but the developer can add them as needed. Be aware that any files attached in the Feedback client will appear as Result Attachments links on the All Links tab and not as true work item attachments.

Code reviews

As we discussed earlier in this chapter, code reviews and pair programming are two ways that developers can collaborate to help assure higher code quality. These practices also reduce the risk of creating bugs, technical debt, and gold plating. Visual Studio Premium and Ultimate edition users can use Visual Studio to facilitate code reviews.

From the My Work page, you can request a code review of work that currently has a state of In Progress or that has been suspended. You can also request a code review on a shelveset or changeset. Code reviews can be requested from various other pages and menus as well. Let’s focus on the scenario where we want another developer to review some code that is currently In Progress. Assuming that there are pending changes on one or more files, the coder will click the Request Review link from the My Work page. Next, he or she selects one or more reviewers to send the request to. He or she can specify a friendly name for the code review, the area path, and a helpful comment, as shown in Figure 8-23. Unlike sending a request for feedback, this feature just assigns work items to the other TFS users. No email is sent.

When the request is submitted, a Code Review Request work item is created and assigned to the requester. In addition, one or more Code Review Response work items are created and assigned to the individual developers being asked to review the code. All of these work items are in the Requested state. Code Review Request and Code Review Response work item types are designated as Hidden types. This means that they cannot be created directly from Visual Studio or Team Web Access. Instead, they are created and managed using the appropriate tooling in Team Explorer. While you can query and open one of these work item types in Team Explorer or Team Web Access, the data in the form is read only.

The prospective reviewers will see the incoming request in the Code Reviews & Requests section of their My Work window. You can see an example of this in Figure 8-24. A number in parentheses shows, at a glance, how many code reviews are being displayed in the view. This is a quick way to see if any code reviews need your attention. There are several available views that can be selected to show code reviews in different ways. If you are curious, you can click the Open Query link to see the work item query (WIQ) behind any of the views.

Here is a list of the built-in views:

• Incoming Requests Shows active code reviews in which you are a reviewer.

• Outgoing Requests Shows active code reviews that you have requested.

• Incoming & Outgoing Shows both incoming and outgoing code reviews. This is the default view.

• Recently Finished Shows code reviews that have been completed in the last seven days.

  

  Figure 8-24 My Work page showing an incoming code review request.

When a request appears, the prospective code reviewer should open it to learn more. This opens the Code Review page in Team Explorer, as you can see in Figure 8-25. On this page, the reviewer can accept or decline the request by clicking the respective link towards the top. If the developer chooses to decline the request, he or she can provide a reason for declining the request.

Reviewing code within Visual Studio consists of performing one or more of the following activities:

• View the associated shelveset or changeset that contains the code.

• Open and review the associated Task work items.

• Add additional reviewers or remove current reviewers.

• Add overall comments.

• Comment on another’s overall comment.

• Review the individual files and add inline comments (as shown in Figure 8-26).

• Check the boxes next to each file to ensure everything is reviewed.

• Finish the review.

Once the reviewer is done with the review, he or she can complete and send it with an overall opinion. The opinion choices are Looks Good, With Comments, or Needs Work. At this point, the work item will be closed and the person named in the Assigned-To field will be removed. At any time, the code review requester can expand the outbound request in his or her My Work page and see if the prospective reviewers have accepted, declined, ignored, or finished the request. The requester can also complete the code review as a whole at any time by closing it or abandoning it.