�ݺ�ߣ

Editor's Notes

• #4: This new control includes a user’s full name, avatar, and email address. When you put focus on the control, it starts by giving you an MRU (most recently used) list of people to whom you’ve most recently assigned work items. If the person you’re after isn’t in the list, just click Search and the list will populate with matching results from the users in your account. You'll see avatars on cards on your work items, boards, and more.
• #5: The tasks in the sprint that do not have a parent story will now show up on the sprint backlog and task board, under an "Un-parented" category. The un-parented row is highlighted with a grey-colored bar. You can move tasks from an un-parented row to any user story, and vice versa. (Note: Drag & drop of an un-parented row is not allowed; it will always appear on the top of sprint backlog as well as the task board.)
• #6: Completed stories will be collapsed automatically when the task board is opened.All stories on the sprint backlog will be collapsed by default. Stories that are collapsed but have pending work will show a warning on the task board. Collapsed rows on the task board will also show the summary of pending work for that user story.
• #7: The teams can choose if they want to show bugs on their backlogs, regardless of process template. Teams can now choose to show bugs on the backlogs and taskboard with requirements (user stories or product backlog items), with tasks, or not at all.
• #8: From every backlog, you can drill down into more levels, all the way down to Tasks. In addition, from every backlog, you can toggle the levels above your backlog on or off by using the Parents filter. Items not owned by the team, but pulled in based on relationship, display with a hollowed-out color bar
• #9: Related to the navigation updates, you can now turn off backlog levels that your team isn’t using. Prior to this update, all backlog levels were forced on every team. Each backlog level is now “opt-in,” allowing you to configure the levels appropriate for your team. Click the gear at the top of the page, select the team you’re configuring, and then choose the backlog levels you need.
• #10: Now you can quickly filter backlogs and query results by using the new filter textbox we've placed on the toolbar. Simply type in text from the items you’re looking for and the backlog/result is immediately filtered to show only those items with matching text.
• #11: The context menu now provides an option to move an item to the top or to a specific position, even when a filter is applied on the backlog.
• #12: Not only can you customize how your cards look on your Kanban board, but you now have configuration options for the data showing up on your cards in the Customize Cards dialog box. (A similar customization dialog box is also available for the Taskboard.) You can turn the ID on or off, select how the assigned to field is displayed, and choose to show tags directly on your cards. Most people want fields like "title" and "assigned to" on every card, but it's a time saver to bring a bit more information to the cards so you can take action on them without having to open them for more details.
• #13: Kanban teams use a pull model to move work through the board. To do this effectively, each column on your board is split into two subcolumns—Doing and Done. Moving a card into the Done column provides a clear signal that work is ready to progress, and that the card can be pulled by the person/team who owns that next stage. To split any of the columns on your board, simply click the Customize Columns link on the toolbar.
• #14: We added the ability for teams to create horizontal swimlanes to track different classes of work. A classic example is the Expedite lane. So now, each team can create their own lanes, and make the board look just the way they want.
• #15: It's critical that the team are on the same page about what “done” means for each column. You can specify a definition of done for each column on your board. Markdown it’s supported, so you can format the text or include hyperlinks to other locations. Columns with a definition now include a small icon in the header that communicates the agreed-upon definition
• #16: You can now omit the first column of the Kanban board and get a more meaningful CFD chart. The first column often represents the long backlog of items a team is working on, but not the items actively on the Kanban board.
• #17: Epics are hierarchically above Features. Features are mapped to Epics, like Backlog items are mapped to Features. Full backlog and board functionality are available. You can manage the Epic backlog like any other backlog as well as customize your Kanban columns and cards to match your needs. The Epics backlog can be turned on or off at the team level.
• #18: We have added a “Value Area” field to all work items that appears on a backlog, that is: Epics, Features, and (depending on your process template), the field also appears on Product Backlog Items, User Stories, and Requirements. The Value area has two values: Business and Architectural. By default value, all Epics, Features, and Stories are Business types. To create an Architectural Epic, Feature, or Story, set the value to Architectural. With this functionality, you can define Architectural Epics, which in turn break down into Architectural Features and Stories, allowing you to track your architectural roadmap across your organization.
• #19: This feature gives you the ability to specify a token that represents the current iteration in iteration-based queries. As you know, iterations have dates associated with them. As you move from iteration to iteration, it's very tedious to update all the queries used to track work for the next iteration. This release brings the addition of a new query token, @CurrentIteration, that returns the current iteration based on today's date. There are some limitations with this new token, however. For example, it doesn't work in Excel. The token relies on understanding your team context, and unfortunately Excel doesn't have all the information needed to determine which iteration is current
• #21: All of your version control paths, work items, queries, and other team project artifacts will be updated to reflect the new name. Team projects can be renamed multiple times and older names can be reused as well.
• #22: All of your version control paths, work items, queries, and other team project artifacts will be updated to reflect the new name. Team projects can be renamed multiple times and older names can be reused as well.
• #23: allows you to execute an existing Load test project as part of your CI/CD pipeline
• #24: executes a simple load test against an App URL, with the basic load test parameters being configured in the task itself.
• #27: You'll use the Machines hub to create and manage remote machines
• #28: This tab in the Test hub acts as a a single repository for all test results in the system. You’ll not only be able to browse automated test results from VSTest and VSTestRemote tasks, but also from legacy workflows such as XAML Builds and Build- Deploy-Test workflows. Additionally, you can choose to integrate publishing test results into you custom tasks by leveraging REST APIs to publish Test Results. The ‘Runs’ hub today supports querying on test runs and test results, assigning owners to test failures, tracking their analysis, and filing bugs.
• #29: new scriptable build system that's web-based and cross-platform
• #30: new scriptable build system that's web-based and cross-platform