If you want to dive right in and start exploring, this quick reference covers the key concepts, terms, and visual elements that you'll come across.
Jazz artifacts are stored in a Repository, which can be accessed only by authorized Users.
The Repository contains Project Areas which contains the artifacts for a project. Each project area has an associated Process, which governs how the project is run and customizes the way Jazz behaves. The process is defined by a process specification and a process description. The process specification defines the project's Iterations and how it behaves during these iterations. The process description corresponds to a web site explaining the process.
There are two predefined processes to choose from: Eclipse Way and OpenUP (work in progress). But you can also define your own processes or modify an existing one.
Once you are Connected to a project area, you have access to the project's artifacts.
Project Areas are decomposed into a set of Team Areas, which describe the teams that work on the project. Each team area has a list of team members and the Process Role they play within the team. A user can be a member of more than one team. Each team area can define Process Customizations of the process to tailor Jazz for the team and its subteams.
For simple projects, all activity is on a single, main Development Line with a single stream. Additional development lines can be created for things like maintenance activities. Each development line has its own team areas and process customizations.
The planned work is described by Work Items. The types of work items used in a project area are defined by the process. For example, the Eclipse Way process defines work item types for Defects, Tasks, and Enhancements. Each work item type can have its own state transitions and custom fields. Work items are filed against Categories, which allow you to organize work items by functional areas. Each project area defines the list of available categories. Each team area is Associated with the category for the functional area for which the team is responsible.
You can find work items by executing Queries. Queries can be private for you or shared with the team.
The work in a project area is done in a sequence of Iterations whose start and end dates are defined in the process' state. One of the iterations is defined as the Current one by the process. When planning the work, you Target a work item for a particular iteration. You can plan all the work that should go into an iteration by creating an Iteration Plan.
You use a personal Repository Workspace to work on project files under Source Control. You Load the repository workspace to copy the files and folders into your Eclipse workspace on your computer. Jazz tracks all changes made to source-controlled files with Change-Sets. Each change-set itemizes the changes to one or more individual files or folders, carries a comment, and references the relevant work item motivating the changes. You Check-in your change-sets to upload copies of the modified files from your Eclipse workspace to the repository workspace.
Teams use a Stream to store the master copy of project files; each repository workspace holds a copy. A repository workspace and the team's stream are connected by a Flow. You Deliver change-sets from your repository workspace to the stream to incorporate your changes into the master copy; these are Outgoing change-sets. Incoming change-sets are ones that have been delivered to the stream by other team members. You Accept incoming change-sets to incorporate their changes into your repository workspace and your Eclipse workspace.
The source-controlled file base is built up from nothing but the steady accretion of change-sets, each one building on everything that has come before it. The Change History is the sequence of change-sets for a repository workspace or stream.
The source-controlled file base can be partitioned into one or more separate Components, each with their own tree of folders and files, and their own change history. Simple repository workspaces and streams consist of a single component. Multiple components are useful for teams building layered software in which the pieces evolve semi-independently and are deployed separately.
You create a Baseline of an individual component in a repository workspace to capture an interesting point in time, or create a Snapshot to capture simultaneous baselines across all components.
Each team can have its own Build, described in a Build Definition associated with the team area. The build definition specifies the build interval, which build script to use, and which repository workspace to be used for fetching files. A build can be run on different Build Engines.
You can use Feeds to be aware of what your colleagues are working on, or what's happening on other teams. As artifacts in the repository are modified, event notices are automatically sent out to the feeds.
Team Artifacts view manages your connections to a repository and a project area. Once you are connected to a project area you can access its artifacts. The artifacts are grouped into different nodes.
Team Central view gives you a quick overview of information that is relevant for your work, including builds, work item activity, or change-set deliveries. The view has a user-configurable set of sections. There's generally a specialized view or editor associated with each section that provides more details.
Pending Changes view shows your incoming and outgoing change-sets grouped by component. You typically deliver and accept changes from this view.
My Work view shows the work that is currently assigned to you. You typically start to work on a work item from this view.
Work Items view shows you the work items returned from a work item query.
Build view shows you the summaries of build results. You can open a build result editor to inspect the build results in detail.
Team Advisor view pops-up when you execute an operation that violates a process specification. This view tells you what went wrong and often provides a quick fix for the problem.
Project Area editor gives you access to the project area's process specification, development lines, and categories.
Team Area editor gives you access to a team's members and their roles. This is also where a team customizes its process.
Work Item editor lets you create or modify a work item, change its state, to add comments, attachments, and links to other artifacts. When you save the editor, the updated work item will be transmitted to the repository.
Planning editor lets you to create or modify an iteration plan. An iteration plan is defined for a particular iteration target.
Build Result editor shows you a summary of a build, and has tabs that show the details output gathered for the different steps of the build.
Current Work shows you the current work item in the status line on the bottom right of the Eclipse workbench window. The changes you make will be collected into a change-set associated with this work item.
Work Item entry field allows you to quickly navigate to a work item by entering either a work item number or a word from the description or summary. It appears in the status line on the bottom left of the Eclipse workbench window.